The one flow-type per container was an ease of implementation thing
originally - but the intention from the start was to make the flow's
distributed, and that is what we have done (the hard part first).
This makes it more difficult to implement a flow strategy per
component/or endpoint, because the logic is more complex. We've also
optimized behavior of some of the flow types recently to route
differently based on the direction the MessageExchange is flowing -
which adds to the complexity.
We will provide a flow type per Component in the future - but that
will only be applicable for in-container delivery.
cheers,
Rob
At a later stage
On 15 Nov 2005, at 00:31, Peter Smith wrote:
I raised a JIRA issue about SM-163 about different NMR-Flow types
within a single ServiceMix container instance.
But my manager is asking me for more details about the current
architecture that I am unable to answer :-(
His question to me is "what is the BACKGROUND of the one-flow-per
container architecture? eg WHY did they choose this strategy?"
I really have no idea - I figured maybe there is no reason other
than it was just the easiest/quickest thing to do for the 1st
release....
Anyway I said at least I would pass his question to the dev list.
So if anybody knows the history of the one-flow-type-per-container
architecture or some sort of justification for it being this way
can you please let me know.
Thanks
Peter.
