Flow-based Programming vs Message passing/message oriented architecture?

[Hendy Irawan]

Dear friends,

How does Flow-based Programming compare/relate to message passing/message oriented architecture?

Is it the same thing? Or there's no connection at all?

Thank you.

Hendy

[Ged Byrne]

Hi Hendry,

When you say message passing, do you mean like Woolf and Hohpe's Enterprise Integration Patterns?

http://www.eaipatterns.com/

Regards,

Ged

--
You received this message because you are subscribed to the Google Groups "Flow Based Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-progra...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Hendy Irawan]

Yup,pretty much... along the realms of message queue and to some extent ESB'...

Hendy

[David Koontz]

I'm quite positive there will not be agreement on the answer to this question, but I'll give you my perspective.  FBP looks and at some level even acts similar to a message passing system / actor system / etc. but actually has some pretty fundamental differences (conceptually).  The two main features of FBP that I do not see in other similar systems are:

1. FBP uses data to trigger the next step in the graph instead of relying on a signal that explicitly fires when a node is complete.  This is not unique to FBP but it seems pretty rare in FBP to rely on the "auto port" concept to trigger flow control (although it is very useful when appropriate).  This helps frame your thinking about the graph to be about moving data through your components and not triggering components for side effects, encourages more functional'ish components that don't hold a lot of state, etc.

2. FBP only talks IPs at the graph level.  We are so used to talking about specific types when discussing the functionality of any given part of an application that I find this a really nice abstraction.  The benefit comes when you can take a lot of the repetitive logic you would otherwise have embedded in a particular component, and instead can represent it generically (usually with some sort of configuration options), at the IP level.  It feels to me much the same way that LINQ in C# or the Enumerable mixin in Ruby does.  Once you have the basic data slicing and dicing components written, you find yourself applying those same components to all sorts of different data streams as they're all just IPs.  Of course lots of components will need to operate on the data held by your IPs and that is certainly not a generic operation, but around those components lots of control flow type operations can be done much more generically.

[Hendy Irawan]

Thanks David.

Noted: http://sprng.me/ipuk3

--
You received this message because you are subscribed to a topic in the Google Groups "Flow Based Programming" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/flow-based-programming/S1MZzFXYQFQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to flow-based-progra...@googlegroups.com.

[Ged Byrne]

Hi Hendry,

You can think of Flow Based Programming as Messaging Systems applied at the component level rather than application level.

If you read the basic concepts in the FBP book you will be able to see these correlations easily: http://www.jpaulmorrison.com/fbp/concepts.shtml

The basic difference is that the FBP book is talking about a finer level of abstraction.  Each component is at the level of abstraction you would normally find in functions or objects.  Rather than linking together large, complex applications the Flow Graph is routing messages through components that serve a simple, single purpose. 

Traditional EIPs are applied with Message Oriented Middleware, with channels allowing messages to pass between applications.

In Flow Based Programming the same architecture is applied at a finer level of granularity.  Applications are built up from components.

It's the application of the Pipes and Filters architectural style at a component level: http://www.eaipatterns.com/PipesAndFilters.html

The components are the filters.   Each component has ports for input and output that can be linked together by bounded queues.  These are the Channels: http://www.eaipatterns.com/MessageChannel.html

Theses ports are used to transmit Information Packets (IPs) across the Flow Graph.  These IPs are the Messages: http://www.eaipatterns.com/Message.html

A component may have multiple output ports.  Sending the IPs to different output ports allows for Message Routing: http://www.eaipatterns.com/MessageRouter.html

A component may also make changes to the IP.  This allows for Message Translation: http://www.eaipatterns.com/MessageTranslator.html

Some components will provide access to external resources, such as a file or a service.  These acts as the endpoints:http://www.eaipatterns.com/MessageEndpoint.html

All of the other patterns are just elaborations on these basic concepts: http://www.eaipatterns.com/MessagingComponentsIntro.html

Regards, 

Ged

On 9 September 2013 17:54, Hendy Irawan <ceefo...@gmail.com> wrote:

Yup,pretty much... along the realms of message queue and to some extent ESB'...

Hendy

[Hendy Irawan]

Wow!

Thanks a lot Ged. That's a really clear explanation of the correlation :-)

Hendy Irawan - on Twitter - on LinkedIn

Web Developer | Bippo Indonesia | Akselerator Bisnis | Bandung

--
You received this message because you are subscribed to a topic in the Google Groups "Flow Based Programming" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/flow-based-programming/S1MZzFXYQFQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to flow-based-progra...@googlegroups.com.

[Hendy Irawan]

Updated my note: http://sprng.me/ipuk3

Hendy Irawan - on Twitter - on LinkedIn

Web Developer | Bippo Indonesia | Akselerator Bisnis | Bandung

[Paul Morrison]

Hi Ged, that's an excellent summary!  I've never seen it put that succinctly before!  Thanks for posting this - and Hendy, thanks for your question!

Regards,

Paul

[Hendy Irawan]

Thanks Paul for noticing. :)

Hendy

PS. BTW you look awesome in the video :)

Hendy Irawan - on Twitter - on LinkedIn

Web Developer | Bippo Indonesia | Akselerator Bisnis | Bandung

--
You received this message because you are subscribed to a topic in the Google Groups "Flow Based Programming" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/flow-based-programming/S1MZzFXYQFQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to flow-based-progra...@googlegroups.com.

[Paul Morrison]

On 09/09/2013 2:58 PM, David Koontz wrote:
> FBP only talks IPs at the graph level. We are so used to talking
> about specific types when discussing the functionality of any given
> part of an application that I find this a really nice abstraction.
> The benefit comes when you can take a lot of the repetitive logic you
> would otherwise have embedded in a particular component, and instead
> can represent it generically (usually with some sort of configuration
> options), at the IP level. It feels to me much the same way that LINQ
> in C# or the Enumerable mixin in Ruby does. Once you have the basic
> data slicing and dicing components written, you find yourself applying
> those same components to all sorts of different data streams as
> they're all just IPs. Of course lots of components will need to
> operate on the data held by your IPs and that is certainly not a
> generic operation, but around those components lots of control flow
> type operations can be done much more generically.

Hi David, I think you make an important point here. I'm not quite sure
how to parse the first sentence ( :-) ) but this para verbalizes
something I've felt for a long time, without actually having put it into
words! When everything is an IP, you find yourself coming up with quite
a few components that don't care what the IP contents are (or only care
slightly, like a Sort).

[Raoul Duke]

please tell me you've all spent at least a little bit of time with
functional programming languages? or even an oo one with 'generics'?
:-) :-)

> --
> You received this message because you are subscribed to the Google Groups
> "Flow Based Programming" group.
> To unsubscribe from this group and stop receiving emails from it, send an

[Matthew Lai]

And if someone has never spent his/her time with functional languages,
then ... what?

I spent some time in scheme and reading SICP (great book, even though I
never used functional languages in my work) back in 80s. Does that count ? :)

Matt

[Raoul Duke]

> And if someone has never spent his/her time with functional languages,
> then ... what?

i was just (obtusely) getting at the fact that FBP isn't the only
thing that can abstract 'signatures' in some way. filter/map/reduce.
generics in java/c#. typeclasses in haskell. etc. etc. etc.