ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Boisvert" <boisv...@intalio.com>
Subject Re: JBI and correlation of MessageExchange
Date Thu, 29 Mar 2007 00:11:29 GMT
So how about this:
-set the JBI correlation id on the instance when the engine receives a
one-way message or a request (overwrite if already present)
-copy JBI correlation id on all outgoing mex

Does that meet your simple-problem-simple-solution criteria?   (Maybe that's
what you meant all along? :))


On 3/28/07, Guillaume Nodet <gnodet@gmail.com> wrote:
> You're quite true when you imply that the actual ServiceMix
> correlation id does not cover all the possible cases.
> I'm quite sure that for rather complex scenarios, this
> very limited feature will be unusable.
> The aim is to provide a basic feature that can provide meaningful
> information in the most common cases.  The idea is that all JBI exchanges
> that are related together will have the same correlation id.  This id is
> usually
> set by the first component sending the JBI exchange (usually a BC acting
> as a consumer in the JBI meaning of the term).  The most obvious
> cases where this will fail is when a component aggregates several
> unrelated
> messages to produce another message (be it a bpel process or another
> component).
> As there is no way to do that in a pure JBI way, ServiceMix relies on its
> components to behave correctly and set the correlation id on related
> exchanges.  So, for simple components, everything will work
> transparently and no additional code is required.  But Ode is
> a complex component ...
> As for a global tracking system, this will certainly fail at some point
> as I said earlier, but things can always be improved ...  For example
> a JBI exchange could have a list of exchange ids that were directly used
> to create an exchange (in case of an aggregation), so that we could
> go up the chain of exchanges to the first one(s) ...
> So in short, this feature is a basic implementation that certainly does
> not
> cover all the possibles cases and thus requires a simple solution :-)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message