On 12/8/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
On 12/7/06, Roger Menday <[EMAIL PROTECTED]> wrote: > > I get the impression that the servicemix-bpe component is not using the > latest ode code - however, as it is today, this component *doesn't* seem > to be sticking the correlationID, into exchanges it is making. This > would be useful here too. I guess this will also be a problem with any > non-servicemix components too :) ? servicemix-bpe also doesn't add the > senderEndpoint as a property into the exchanges it makes. servicemix-bpe is based on a donation to the ODE project which is not maintained. You should try the ODE Service Engine provided by the ODE project itself.
Unfortunately BPEL is fundamentally driven at the message level and although the new ODE code is integrated with all the joys of MessageExchanges (both JBI and Persistable ODE ones) there is still a basic disconnect between the input to a BPEL process and any invokes that may occur during that BPEL process. At the point where an invoke is called a new MessageExchange is created without deriving any properties from the initiating exchange. That is not to say initiating message exchange's properties couldn't be copied but that it may lead to other side-effects. There is some code in ODE that allows for the use of InvocationInterceptors which may be a lead towards providing a configurable correlation mechanism (as distinct from BPEL correlation sets) - the ODE guys should be able to shed some light on this. The reason why your solution didn't work for the current BPE component was because it has two main external interfaces: BPEEndpoint which is a consumer and JbiInvokeAction which is a provider. I'm not sure how you'd go about using thread local storage across two classes and I'm not sure if there is even a guarantee that the JbiInvokeAction will be called in the same thread. I faced a similar situation with needing to correlate messages coming in to BPE and invokes leaving BPE from the same initiating exchange and the only easily implementable solution was to wrap an aspect around both classes to generate a correlation id to be added to the incoming message xml in a configurable manner.