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? :)) alex On 3/28/07, Guillaume Nodet <[EMAIL PROTECTED]> 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 :-)
