Sounds to me like there is no real simple solution for this problem. My read is that what is wanted is a general mechanism to associate smix /jbi identifers with an ode process.
The solution would have to address several questions: 1. how to associate the identifer 2. how to get the associated identiifer 3. rules for propagating the identifer 4. rules for disassociating the identifier 5. devilish details point 1 and 2 can be handled either with extension to the iapi, or through some magic ode mex property. point 3: seems like there are use cases for propagating the identifer on any communication on the same partner link, or propagating the identiefier on all future communications. point 4: does the association end when the mex is completed (replied to), or does it persist point 5: how to support multiple identifiers, etc.. One possible solution: * New first-class concept "conversation identifier", basically a client's identifier for the session/conversation. * Two new methods on the ODE MessageExchange: void MessageExchange.setConversationId(String key, String value, flags) String MessageExchange.getConversationId(String key) flags would be a bitmask-like thing with the following ALL_PARTNERS - conversation id will be sent to all partner's THIS_PARTNER - conversation id will be sent only to this partner UNTIL_REPLY - conversation id will be sent until the process replies to this mex FOREVER - conversation id will forever be associated with this process Alternative solution would be refactor IAPI to expose more of the internals (i.e. partnerlinks, process instnaces) and allow IL to implement this functionality more directly. The latter would certainly have to wait until after 1.0. the former could potentially be implemented without much trouble. I'd suggest opening a new feature issue if there is interest, it would be good to get the requirements flushed out in a less ephemeral medium. -mbs On 4/21/07, Alex Boisvert < [EMAIL PROTECTED]> wrote:
Maciej, Do you have any thoughts on extending the IAPI to allow the retrieval of the process instance, and partnerLink instance from the message exchange? alex On 4/20/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > > I think it should be easy if there is a way to retrieve the process id > from the JBI component when sending an exchange. However > for the same reason, it may not be easy, as there is not much > information available when sending a new message. > > On 4/19/07, Roger Menday < [EMAIL PROTECTED]> wrote: > > > > > > Hi, > > > > This is related to the same issue ... > > > > Can the bpel process instance id be inserted an a message exchange > > property on each message exchange coming from a single process instance > ? > > > > it does'nt solve all the issues I have (and it's different from > > propagating the id coming from the JBI client of the bpel process) ... > > > > is that sensible ? > > > > Roger > > > This is exactly what I meant. > > > Sorry if this has not been very clear ;-) > > > > > > The only problem was I have no idea where / how > > > to store / retrieve this correlation id ... > > > > > > On 3/29/07, Alex Boisvert <[EMAIL PROTECTED]> wrote: > > >> > > >> 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 > :-) > > >> > > > >> > > > >> > > > > > > > > > > > > > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Principal Engineer, IONA > Blog: http://gnodet.blogspot.com/ >
