You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ode.apache.org by Guillaume Nodet <gn...@gmail.com> on 2007/03/05 19:00:50 UTC

JBI and correlation of MessageExchange

Hi guys !

In ServiceMix, there is a property named "
org.apache.servicemix.correlationId"
that is used to correlate MessageExchanges.
For example, if a JBI endpoint receives a JBI exchange, and send another
jbi exchange while processing it, the components will forward this property
from the inbound exchange to the outbound exchange (or create it with a
unique
id if none was set).  This enables tracking of a "JBI process".  I think ODE
would benefit of such a behavior when deployed inside ServiceMix, so I'm
trying
to implement it.

However, I'm not sure what the best way to do that.  I would say that the
best way
is to use properties defined on org.apache.ode.bpel.iapi.MessageExchange,
but I haven't been able to find a way to retrieve these properties from
a MessageExchangeContext.invokePartner call.

Any hints on how to do that ?

Cheers,
Guillaume Nodet
------------------------
Architect, LogicBlaze (http://www.logicblaze.com/)
Blog: http://gnodet.blogspot.com/

Re: JBI and correlation of MessageExchange

Posted by Guillaume Nodet <gn...@gmail.com>.
On 3/28/07, Roger Menday <r....@fz-juelich.de> wrote:
>
> Hi,
> > Well, I'm not sure where the best place would be to
> > store such properties.  Hopefully someone with
> > more knowledge of Ode internals can help here.
> I hope so.
> > I think the IAPI may give a slot for the integration
> > layer to store something in the database.  And this
> > will be a definite need if we want to be able to not
> > keep the JBI exchange in memory (I don't think
> > the JBI exchange is stored somewhere).
> >
> > The exchanges ( org.apache.ode.bpel.iapi.MessageExchagne)
> > has some placeholders for properties but afaik, they are specific
> > to a given exchange, so that there is no way to link an
> > outgoing exchange to the MyRoleExhcange that created
> > the process instance.
> Some other issues we have with the JBI integration of ODE.
>
> * interface based routing


There is a JIRA about that.  If not endpoint information is set
for the partner, maybe Ode could default to interface based routing ...

* getting the WSDL automatically from JBI


Hum, I'm not sure about this one ...  This may be more of a tooling problem
?

* management stuff


Yeah, the management interface could be exposed as a JBI endpoint easily.

* correlation id (above)


This one is important imho ...

Am I correct with assuming this is currently missing ?
>
> I wish I had the time (and probably the ability) to do something
> pro-active about these, rather than just complaining ... :)


I will try too when time permits ...
Would you mind raising JIRA issues for the missing ones ?

Regards,
>
> Roger
> >
> > On 3/28/07, Roger Menday <r....@fz-juelich.de> wrote:
> >>
> >>
> >> Hi Guillaume,
> >>
> >> I am also interested in seeing such a feature, i.e. allowing the
> >> properties of the initiating JBI exchange to be copied into the
> messages
> >> leaving the process. Do you think it's a big thing to add ?
> >>
> >> regards,
> >>
> >> Roger
> >>
> >> > Hum, not sure if it will really help me.
> >> > Let me restate what I need:  the incoming JBI exchange
> >> > contain a known property and I want to store it with the
> >> > process instance somehow (in a variable or any other way).
> >> > Then, when an invocation is performed, I meed to set this
> >> > property on the newly created JBI exchange.
> >> >
> >> > This is not about correlation for the BPEL process itself.
> >> > And I can't reuse something generated by Ode as the property
> >> > value is usually already set on the incoming exchange.
> >> >
> >> > So I'm not sure if the session ids can be used, especially
> >> > because i need to use existing values and not let Ode
> >> > generate those.  And it seems there is no way to override that
> >> > currently: see BpelRuntimeContextImpl.initializePartnerLinks
> >> >
> >> > I was thinking about using the MessageExchange DAO to set
> >> > the property, but my problem is that I haven't found a way
> >> > to retrieve the MyRoleMessageExchange that was used
> >> > to create the process when inside an
> >> MessageExchangeContext.invokePartner
> >> > call.
> >> >
> >> > On 3/7/07, Matthieu Riou <ma...@gmail.com> wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> I think you'll just need to do something like:
> >> >>
> >> >>       String mySess = mex.getProperty(
> >> >> PartnerRoleMessageExchange.PROPERTY_SEP_MYROLE_SESSIONID);
> >> >>       String partnerSess = mex.getProperty(
> >> >> PartnerRoleMessageExchange.PROPERTY_SEP_PARTNERROLE_EPR);
> >> >>
> >> >> For more information on how we handle the correlations this way:
> >> >>
> >> >> http://incubator.apache.org/ode/implicit-correlations.html
> >> >> http://incubator.apache.org/ode/stateful-exchange-protocol.html
> >> >>
> >> >> Cheers,
> >> >> Matthieu
> >> >>
> >> >> On 3/5/07, Guillaume Nodet <gn...@gmail.com> wrote:
> >> >> >
> >> >> > Hi guys !
> >> >> >
> >> >> > In ServiceMix, there is a property named "
> >> >> > org.apache.servicemix.correlationId"
> >> >> > that is used to correlate MessageExchanges.
> >> >> > For example, if a JBI endpoint receives a JBI exchange, and send
> >> >> another
> >> >> > jbi exchange while processing it, the components will forward this
> >> >> > property
> >> >> > from the inbound exchange to the outbound exchange (or create it
> >> >> with a
> >> >> > unique
> >> >> > id if none was set).  This enables tracking of a "JBI process".  I
> >> >> think
> >> >> > ODE
> >> >> > would benefit of such a behavior when deployed inside ServiceMix,
> >> >> so I'm
> >> >> > trying
> >> >> > to implement it.
> >> >> >
> >> >> > However, I'm not sure what the best way to do that.  I would say
> >> that
> >> >> the
> >> >> > best way
> >> >> > is to use properties defined on
> >> >> org.apache.ode.bpel.iapi.MessageExchange
> >> >> ,
> >> >> > but I haven't been able to find a way to retrieve these properties
> >> >> from
> >> >> > a MessageExchangeContext.invokePartner call.
> >> >> >
> >> >> > Any hints on how to do that ?
> >> >> >
> >> >> > Cheers,
> >> >> > Guillaume Nodet
> >> >> > ------------------------
> >> >> > Architect, LogicBlaze (http://www.logicblaze.com/)
> >> >> > Blog: http://gnodet.blogspot.com/
> >> >> >
> >> >>
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >
> >
>
>


-- 
Cheers,
Guillaume Nodet
------------------------
Architect, LogicBlaze (http://www.logicblaze.com/)
Blog: http://gnodet.blogspot.com/

Re: JBI and correlation of MessageExchange

Posted by Roger Menday <r....@fz-juelich.de>.
Hi,
> Well, I'm not sure where the best place would be to
> store such properties.  Hopefully someone with
> more knowledge of Ode internals can help here.
I hope so.
> I think the IAPI may give a slot for the integration
> layer to store something in the database.  And this
> will be a definite need if we want to be able to not
> keep the JBI exchange in memory (I don't think
> the JBI exchange is stored somewhere).
>
> The exchanges ( org.apache.ode.bpel.iapi.MessageExchagne)
> has some placeholders for properties but afaik, they are specific
> to a given exchange, so that there is no way to link an
> outgoing exchange to the MyRoleExhcange that created
> the process instance.
Some other issues we have with the JBI integration of ODE.

* interface based routing
* getting the WSDL automatically from JBI
* management stuff
* correlation id (above)

Am I correct with assuming this is currently missing ?

I wish I had the time (and probably the ability) to do something 
pro-active about these, rather than just complaining ... :)

Regards,

Roger
>
> On 3/28/07, Roger Menday <r....@fz-juelich.de> wrote:
>>
>>
>> Hi Guillaume,
>>
>> I am also interested in seeing such a feature, i.e. allowing the
>> properties of the initiating JBI exchange to be copied into the messages
>> leaving the process. Do you think it's a big thing to add ?
>>
>> regards,
>>
>> Roger
>>
>> > Hum, not sure if it will really help me.
>> > Let me restate what I need:  the incoming JBI exchange
>> > contain a known property and I want to store it with the
>> > process instance somehow (in a variable or any other way).
>> > Then, when an invocation is performed, I meed to set this
>> > property on the newly created JBI exchange.
>> >
>> > This is not about correlation for the BPEL process itself.
>> > And I can't reuse something generated by Ode as the property
>> > value is usually already set on the incoming exchange.
>> >
>> > So I'm not sure if the session ids can be used, especially
>> > because i need to use existing values and not let Ode
>> > generate those.  And it seems there is no way to override that
>> > currently: see BpelRuntimeContextImpl.initializePartnerLinks
>> >
>> > I was thinking about using the MessageExchange DAO to set
>> > the property, but my problem is that I haven't found a way
>> > to retrieve the MyRoleMessageExchange that was used
>> > to create the process when inside an
>> MessageExchangeContext.invokePartner
>> > call.
>> >
>> > On 3/7/07, Matthieu Riou <ma...@gmail.com> wrote:
>> >>
>> >> Hi,
>> >>
>> >> I think you'll just need to do something like:
>> >>
>> >>       String mySess = mex.getProperty(
>> >> PartnerRoleMessageExchange.PROPERTY_SEP_MYROLE_SESSIONID);
>> >>       String partnerSess = mex.getProperty(
>> >> PartnerRoleMessageExchange.PROPERTY_SEP_PARTNERROLE_EPR);
>> >>
>> >> For more information on how we handle the correlations this way:
>> >>
>> >> http://incubator.apache.org/ode/implicit-correlations.html
>> >> http://incubator.apache.org/ode/stateful-exchange-protocol.html
>> >>
>> >> Cheers,
>> >> Matthieu
>> >>
>> >> On 3/5/07, Guillaume Nodet <gn...@gmail.com> wrote:
>> >> >
>> >> > Hi guys !
>> >> >
>> >> > In ServiceMix, there is a property named "
>> >> > org.apache.servicemix.correlationId"
>> >> > that is used to correlate MessageExchanges.
>> >> > For example, if a JBI endpoint receives a JBI exchange, and send
>> >> another
>> >> > jbi exchange while processing it, the components will forward this
>> >> > property
>> >> > from the inbound exchange to the outbound exchange (or create it
>> >> with a
>> >> > unique
>> >> > id if none was set).  This enables tracking of a "JBI process".  I
>> >> think
>> >> > ODE
>> >> > would benefit of such a behavior when deployed inside ServiceMix,
>> >> so I'm
>> >> > trying
>> >> > to implement it.
>> >> >
>> >> > However, I'm not sure what the best way to do that.  I would say 
>> that
>> >> the
>> >> > best way
>> >> > is to use properties defined on
>> >> org.apache.ode.bpel.iapi.MessageExchange
>> >> ,
>> >> > but I haven't been able to find a way to retrieve these properties
>> >> from
>> >> > a MessageExchangeContext.invokePartner call.
>> >> >
>> >> > Any hints on how to do that ?
>> >> >
>> >> > Cheers,
>> >> > Guillaume Nodet
>> >> > ------------------------
>> >> > Architect, LogicBlaze (http://www.logicblaze.com/)
>> >> > Blog: http://gnodet.blogspot.com/
>> >> >
>> >>
>> >
>> >
>> >
>>
>>
>>
>
>

Re: JBI and correlation of MessageExchange

Posted by Guillaume Nodet <gn...@gmail.com>.
Yeah, that would solve the problem :-)

On 3/28/07, Matthieu Riou <ma...@gmail.com> wrote:
>
> Sorry for letting this on the sideI think I just got diverted at some
> point.
> Anyway looking into this a bit more the correct mechanism would be, as you
> first mentioned, to set the servicemix correlation id as an ODE message
> exchange property for the MyRoleMex created in OdeService.invokeOde(). Now
> the problem is to retrieve it in MessageExchangeContextImpl.invokePartner
> ()
> which is virtually impossible as is as you only have the parner mex
> created
> for the invocation and lost track of the myrole mex.
>
> So I guess it would make sense to have the engine copy the mex properties
> from myrole mex to partnerrole mex when it's invoking. Some sort of
> property
> propagation feature. The only place where this is possible is when the
> partner role mex is created, right where the invocation is triggered in
> BpelRuntimeContextImpl.invoke(). Here you have the partner mex that is
> being
> created and also the my role mex that originated the exchange
> (_instantiatingMessageExchange). So copying properties from the latter to
> the former wouldn't be so hard I guess.
>
> And then it would be easy in MessageExchangeContextImpl.invokePartner() to
> get the properties from the partner mex and and set them on the jbi mex.
> Makes sense?
>
> Matthieu
>
> On 3/28/07, Guillaume Nodet <gn...@gmail.com> wrote:
> >
> > Well, I'm not sure where the best place would be to
> > store such properties.  Hopefully someone with
> > more knowledge of Ode internals can help here.
> > I think the IAPI may give a slot for the integration
> > layer to store something in the database.  And this
> > will be a definite need if we want to be able to not
> > keep the JBI exchange in memory (I don't think
> > the JBI exchange is stored somewhere).
> >
> > The exchanges ( org.apache.ode.bpel.iapi.MessageExchagne)
> > has some placeholders for properties but afaik, they are specific
> > to a given exchange, so that there is no way to link an
> > outgoing exchange to the MyRoleExhcange that created
> > the process instance.
> >
> > On 3/28/07, Roger Menday <r....@fz-juelich.de> wrote:
> > >
> > >
> > > Hi Guillaume,
> > >
> > > I am also interested in seeing such a feature, i.e. allowing the
> > > properties of the initiating JBI exchange to be copied into the
> messages
> > > leaving the process. Do you think it's a big thing to add ?
> > >
> > > regards,
> > >
> > > Roger
> > >
> > > > Hum, not sure if it will really help me.
> > > > Let me restate what I need:  the incoming JBI exchange
> > > > contain a known property and I want to store it with the
> > > > process instance somehow (in a variable or any other way).
> > > > Then, when an invocation is performed, I meed to set this
> > > > property on the newly created JBI exchange.
> > > >
> > > > This is not about correlation for the BPEL process itself.
> > > > And I can't reuse something generated by Ode as the property
> > > > value is usually already set on the incoming exchange.
> > > >
> > > > So I'm not sure if the session ids can be used, especially
> > > > because i need to use existing values and not let Ode
> > > > generate those.  And it seems there is no way to override that
> > > > currently: see BpelRuntimeContextImpl.initializePartnerLinks
> > > >
> > > > I was thinking about using the MessageExchange DAO to set
> > > > the property, but my problem is that I haven't found a way
> > > > to retrieve the MyRoleMessageExchange that was used
> > > > to create the process when inside an
> > > MessageExchangeContext.invokePartner
> > > > call.
> > > >
> > > > On 3/7/07, Matthieu Riou <ma...@gmail.com> wrote:
> > > >>
> > > >> Hi,
> > > >>
> > > >> I think you'll just need to do something like:
> > > >>
> > > >>       String mySess = mex.getProperty(
> > > >> PartnerRoleMessageExchange.PROPERTY_SEP_MYROLE_SESSIONID);
> > > >>       String partnerSess = mex.getProperty(
> > > >> PartnerRoleMessageExchange.PROPERTY_SEP_PARTNERROLE_EPR);
> > > >>
> > > >> For more information on how we handle the correlations this way:
> > > >>
> > > >> http://incubator.apache.org/ode/implicit-correlations.html
> > > >> http://incubator.apache.org/ode/stateful-exchange-protocol.html
> > > >>
> > > >> Cheers,
> > > >> Matthieu
> > > >>
> > > >> On 3/5/07, Guillaume Nodet <gn...@gmail.com> wrote:
> > > >> >
> > > >> > Hi guys !
> > > >> >
> > > >> > In ServiceMix, there is a property named "
> > > >> > org.apache.servicemix.correlationId"
> > > >> > that is used to correlate MessageExchanges.
> > > >> > For example, if a JBI endpoint receives a JBI exchange, and send
> > > >> another
> > > >> > jbi exchange while processing it, the components will forward
> this
> > > >> > property
> > > >> > from the inbound exchange to the outbound exchange (or create it
> > > >> with a
> > > >> > unique
> > > >> > id if none was set).  This enables tracking of a "JBI
> process".  I
> > > >> think
> > > >> > ODE
> > > >> > would benefit of such a behavior when deployed inside ServiceMix,
> > > >> so I'm
> > > >> > trying
> > > >> > to implement it.
> > > >> >
> > > >> > However, I'm not sure what the best way to do that.  I would say
> > that
> > > >> the
> > > >> > best way
> > > >> > is to use properties defined on
> > > >> org.apache.ode.bpel.iapi.MessageExchange
> > > >> ,
> > > >> > but I haven't been able to find a way to retrieve these
> properties
> > > >> from
> > > >> > a MessageExchangeContext.invokePartner call.
> > > >> >
> > > >> > Any hints on how to do that ?
> > > >> >
> > > >> > Cheers,
> > > >> > Guillaume Nodet
> > > >> > ------------------------
> > > >> > Architect, LogicBlaze (http://www.logicblaze.com/)
> > > >> > Blog: http://gnodet.blogspot.com/
> > > >> >
> > > >>
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Architect, LogicBlaze (http://www.logicblaze.com/)
> > Blog: http://gnodet.blogspot.com/
> >
>



-- 
Cheers,
Guillaume Nodet
------------------------
Architect, LogicBlaze (http://www.logicblaze.com/)
Blog: http://gnodet.blogspot.com/

Re: JBI and correlation of MessageExchange

Posted by Assaf Arkin <ar...@intalio.com>.
On 3/28/07, Alex Boisvert <bo...@intalio.com> wrote:
>
> On 3/28/07, Matthieu Riou <ma...@gmail.com> wrote:
> >
> > So I guess it would make sense to have the engine copy the mex
> properties
> > from myrole mex to partnerrole mex when it's invoking. Some sort of
> > property
> > propagation feature. The only place where this is possible is when the
> > partner role mex is created, right where the invocation is triggered in
> > BpelRuntimeContextImpl.invoke(). Here you have the partner mex that is
> > being
> > created and also the my role mex that originated the exchange
> > (_instantiatingMessageExchange). So copying properties from the latter
> to
> > the former wouldn't be so hard I guess.
> >
> > And then it would be easy in MessageExchangeContextImpl.invokePartner()
> to
> > get the properties from the partner mex and and set them on the jbi mex.
> > Makes sense?
>
>
>
> This isn't entirely clear to me.    The mex that originated the exchange
> isn't necessarily the instantiating mex.  That's what held me from
> commenting on this thread so far.   Implementing the feature for the
> instantiating mex is interesting but doesn't cover the general case.


I'm sure everyone will agree that a partner with two roles is begging for
some linkage between these two ports. The only question is what.

Do you copy all the properties? What if some properties must not be copied?
What it some must be copied only on the first interaction, and retained
afterwards? What if the absense of some should signal a fault? What about
assymetrical properties (sender becomes receiver, ID becomes reference)?

Sounds to me like a protocol where you get to say "send me back the
correlation set I sent you, send me back the message ID but call it
reference, and don't send me back my callback address, that's yours to
keep".

Sans any prescribed behavior for a particular protocol we want to support,
this is just creating something that works some times and may horrible break
in other times.

Assaf


To locate the mex you would have to look in the outstanding mex map and
> probably use the scope hierarchy to determine which is the eldest.  I
> think
> we would need to provide a new API method to the engine to enable this.
>
> alex
>



-- 
CTO, Intalio
http://www.intalio.com

Re: JBI and correlation of MessageExchange

Posted by Assaf Arkin <ar...@intalio.com>.
Alternatively, we can open up the engine to add event listeners that are
executed in the context of the process. That way, you can experiment with
enhancements without having to build new APIs, modify the engine, etc.
Places less burden on the core code, and gives you more room to try out new
ideas.

Assaf

On 4/24/07, Maciej Szefler <mb...@intalio.com> wrote:
>
> 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 < boisvert@intalio.com> 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 <gn...@gmail.com> 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 < r.menday@fz-juelich.de> 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 <bo...@intalio.com> 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 <gn...@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
> >
> > > :-)
> > > > >> >
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Cheers,
> > > Guillaume Nodet
> > > ------------------------
> > > Principal Engineer, IONA
> > > Blog: http://gnodet.blogspot.com/
> > >
> >
>

Re: JBI and correlation of MessageExchange

Posted by Maciej Szefler <mb...@intalio.com>.
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 < boisvert@intalio.com> 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 <gn...@gmail.com> 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 < r.menday@fz-juelich.de> 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 <bo...@intalio.com> 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 <gn...@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
>
> > :-)
> > > >> >
> > > >> >
> > > >>
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Principal Engineer, IONA
> > Blog: http://gnodet.blogspot.com/
> >
>

Re: JBI and correlation of MessageExchange

Posted by Alex Boisvert <bo...@intalio.com>.
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 <gn...@gmail.com> 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 <r....@fz-juelich.de> 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 <bo...@intalio.com> 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 <gn...@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
> :-)
> > >> >
> > >> >
> > >>
> > >
> > >
> > >
> >
> >
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Principal Engineer, IONA
> Blog: http://gnodet.blogspot.com/
>

Re: JBI and correlation of MessageExchange

Posted by Guillaume Nodet <gn...@gmail.com>.
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 <r....@fz-juelich.de> 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 <bo...@intalio.com> 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 <gn...@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 :-)
> >> >
> >> >
> >>
> >
> >
> >
>
>


-- 
Cheers,
Guillaume Nodet
------------------------
Principal Engineer, IONA
Blog: http://gnodet.blogspot.com/

Re: JBI and correlation of MessageExchange

Posted by Roger Menday <r....@fz-juelich.de>.
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 <bo...@intalio.com> 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 <gn...@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 :-)
>> >
>> >
>>
>
>
>

Re: JBI and correlation of MessageExchange

Posted by Guillaume Nodet <gn...@gmail.com>.
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 <bo...@intalio.com> 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 <gn...@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 :-)
> >
> >
>



-- 
Cheers,
Guillaume Nodet
------------------------
Architect, LogicBlaze (http://www.logicblaze.com/)
Blog: http://gnodet.blogspot.com/

Re: JBI and correlation of MessageExchange

Posted by Alex Boisvert <bo...@intalio.com>.
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 <gn...@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 :-)
>
>

Re: JBI and correlation of MessageExchange

Posted by Guillaume Nodet <gn...@gmail.com>.
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 :-)

On 3/29/07, Alex Boisvert <bo...@intalio.com> wrote:
>
> Guillaume,
>
> Could you better describe what's expected for the handling of the
> ServiceMix
> correlation id?
>
> I was under the assumption that a service that obtains the correlation id
> from a JBI mex should copy it onto all other mex within the scope of the
> operation.  But now I'm wondering what happens for the case of a one-way
> invoke triggering a set of mex since one-way operation don't really have a
> scope beyond the initial message.
>
> Attaching a correlation id to the instance (via properties) doesn't seem
> to
> solve the general tracking issue since one might want to separately track
> independent interactions within the same process.
>
> alex
>
>
> On 3/28/07, Guillaume Nodet <gn...@gmail.com> wrote:
> >
> > The original need is to access a set of persistent properties for a
> > given instance of a process and *controlled by the integration layer*.
> > The use of the MEX has a place holder was just an idea.
> > I guess if there is a place for a global set of properties for a given
> > process instance, it would solve the need easily without going into
> > all these problems.
> >
> > Passing user defined properties from a mex to another is another
> > problem that may need another solution.
> >
> > On 3/29/07, Matthieu Riou <ma...@gmail.com> wrote:
> > >
> > > Yeah, that's what I was going to reply but you've been quicker :)
> After
> > > thinking of it a bit more I remembered that the instantiating mex is
> > > mostly
> > > null. I think the outstanding mex map wouldn't work either as you'd
> find
> > > something only for request / response scenarios and not for async.
> > >
> > > On 3/28/07, Alex Boisvert <bo...@intalio.com> wrote:
> > > >
> > > > On 3/28/07, Matthieu Riou <ma...@gmail.com> wrote:
> > > > >
> > > > > So I guess it would make sense to have the engine copy the mex
> > > > > properties
> > > > > from myrole mex to partnerrole mex when it's invoking. Some sort
> of
> > > > > property
> > > > > propagation feature. The only place where this is possible is when
> > the
> > > > > partner role mex is created, right where the invocation is
> triggered
> > > in
> > > > > BpelRuntimeContextImpl.invoke(). Here you have the partner mex
> that
> > is
> > > > > being
> > > > > created and also the my role mex that originated the exchange
> > > > > (_instantiatingMessageExchange). So copying properties from the
> > latter
> > > > > to
> > > > > the former wouldn't be so hard I guess.
> > > > >
> > > > > And then it would be easy in
> > MessageExchangeContextImpl.invokePartner
> > > ()
> > > > > to
> > > > > get the properties from the partner mex and and set them on the
> jbi
> > > mex.
> > > > >
> > > > > Makes sense?
> > > >
> > > >
> > > >
> > > > This isn't entirely clear to me.    The mex that originated the
> > exchange
> > > > isn't necessarily the instantiating mex.  That's what held me from
> > > > commenting on this thread so far.   Implementing the feature for the
> > > > instantiating mex is interesting but doesn't cover the general case.
> > > >
> > > > To locate the mex you would have to look in the outstanding mex map
> > and
> > > > probably use the scope hierarchy to determine which is the
> eldest.  I
> > > think
> > > > we would need to provide a new API method to the engine to enable
> > this.
> > > >
> > > > alex
> > > >
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Architect, LogicBlaze (http://www.logicblaze.com/)
> > Blog: http://gnodet.blogspot.com/
> >
>



-- 
Cheers,
Guillaume Nodet
------------------------
Architect, LogicBlaze (http://www.logicblaze.com/)
Blog: http://gnodet.blogspot.com/

Re: JBI and correlation of MessageExchange

Posted by Alex Boisvert <bo...@intalio.com>.
Guillaume,

Could you better describe what's expected for the handling of the ServiceMix
correlation id?

I was under the assumption that a service that obtains the correlation id
from a JBI mex should copy it onto all other mex within the scope of the
operation.  But now I'm wondering what happens for the case of a one-way
invoke triggering a set of mex since one-way operation don't really have a
scope beyond the initial message.

Attaching a correlation id to the instance (via properties) doesn't seem to
solve the general tracking issue since one might want to separately track
independent interactions within the same process.

alex


On 3/28/07, Guillaume Nodet <gn...@gmail.com> wrote:
>
> The original need is to access a set of persistent properties for a
> given instance of a process and *controlled by the integration layer*.
> The use of the MEX has a place holder was just an idea.
> I guess if there is a place for a global set of properties for a given
> process instance, it would solve the need easily without going into
> all these problems.
>
> Passing user defined properties from a mex to another is another
> problem that may need another solution.
>
> On 3/29/07, Matthieu Riou <ma...@gmail.com> wrote:
> >
> > Yeah, that's what I was going to reply but you've been quicker :) After
> > thinking of it a bit more I remembered that the instantiating mex is
> > mostly
> > null. I think the outstanding mex map wouldn't work either as you'd find
> > something only for request / response scenarios and not for async.
> >
> > On 3/28/07, Alex Boisvert <bo...@intalio.com> wrote:
> > >
> > > On 3/28/07, Matthieu Riou <ma...@gmail.com> wrote:
> > > >
> > > > So I guess it would make sense to have the engine copy the mex
> > > > properties
> > > > from myrole mex to partnerrole mex when it's invoking. Some sort of
> > > > property
> > > > propagation feature. The only place where this is possible is when
> the
> > > > partner role mex is created, right where the invocation is triggered
> > in
> > > > BpelRuntimeContextImpl.invoke(). Here you have the partner mex that
> is
> > > > being
> > > > created and also the my role mex that originated the exchange
> > > > (_instantiatingMessageExchange). So copying properties from the
> latter
> > > > to
> > > > the former wouldn't be so hard I guess.
> > > >
> > > > And then it would be easy in
> MessageExchangeContextImpl.invokePartner
> > ()
> > > > to
> > > > get the properties from the partner mex and and set them on the jbi
> > mex.
> > > >
> > > > Makes sense?
> > >
> > >
> > >
> > > This isn't entirely clear to me.    The mex that originated the
> exchange
> > > isn't necessarily the instantiating mex.  That's what held me from
> > > commenting on this thread so far.   Implementing the feature for the
> > > instantiating mex is interesting but doesn't cover the general case.
> > >
> > > To locate the mex you would have to look in the outstanding mex map
> and
> > > probably use the scope hierarchy to determine which is the eldest.  I
> > think
> > > we would need to provide a new API method to the engine to enable
> this.
> > >
> > > alex
> > >
> > >
> > >
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Architect, LogicBlaze (http://www.logicblaze.com/)
> Blog: http://gnodet.blogspot.com/
>

Re: JBI and correlation of MessageExchange

Posted by Guillaume Nodet <gn...@gmail.com>.
The original need is to access a set of persistent properties for a
given instance of a process and *controlled by the integration layer*.
The use of the MEX has a place holder was just an idea.
I guess if there is a place for a global set of properties for a given
process instance, it would solve the need easily without going into
all these problems.

Passing user defined properties from a mex to another is another
problem that may need another solution.

On 3/29/07, Matthieu Riou <ma...@gmail.com> wrote:
>
> Yeah, that's what I was going to reply but you've been quicker :) After
> thinking of it a bit more I remembered that the instantiating mex is
> mostly
> null. I think the outstanding mex map wouldn't work either as you'd find
> something only for request / response scenarios and not for async.
>
> On 3/28/07, Alex Boisvert <bo...@intalio.com> wrote:
> >
> > On 3/28/07, Matthieu Riou <ma...@gmail.com> wrote:
> > >
> > > So I guess it would make sense to have the engine copy the mex
> > > properties
> > > from myrole mex to partnerrole mex when it's invoking. Some sort of
> > > property
> > > propagation feature. The only place where this is possible is when the
> > > partner role mex is created, right where the invocation is triggered
> in
> > > BpelRuntimeContextImpl.invoke(). Here you have the partner mex that is
> > > being
> > > created and also the my role mex that originated the exchange
> > > (_instantiatingMessageExchange). So copying properties from the latter
> > > to
> > > the former wouldn't be so hard I guess.
> > >
> > > And then it would be easy in MessageExchangeContextImpl.invokePartner
> ()
> > > to
> > > get the properties from the partner mex and and set them on the jbi
> mex.
> > >
> > > Makes sense?
> >
> >
> >
> > This isn't entirely clear to me.    The mex that originated the exchange
> > isn't necessarily the instantiating mex.  That's what held me from
> > commenting on this thread so far.   Implementing the feature for the
> > instantiating mex is interesting but doesn't cover the general case.
> >
> > To locate the mex you would have to look in the outstanding mex map and
> > probably use the scope hierarchy to determine which is the eldest.  I
> think
> > we would need to provide a new API method to the engine to enable this.
> >
> > alex
> >
> >
> >
>



-- 
Cheers,
Guillaume Nodet
------------------------
Architect, LogicBlaze (http://www.logicblaze.com/)
Blog: http://gnodet.blogspot.com/

Re: JBI and correlation of MessageExchange

Posted by Matthieu Riou <ma...@gmail.com>.
The properties copying solution certainly has a hacky smell. And when
invoking several partner in one interaction it's also not clear (at least to
me) on which partner mex the correlation id should be propagated (same
partner link? all?).

On 3/28/07, Matthieu Riou <ma...@gmail.com> wrote:
>
> Yeah, that's what I was going to reply but you've been quicker :) After
> thinking of it a bit more I remembered that the instantiating mex is mostly
> null. I think the outstanding mex map wouldn't work either as you'd find
> something only for request / response scenarios and not for async.
>
> On 3/28/07, Alex Boisvert <bo...@intalio.com> wrote:
> >
> > On 3/28/07, Matthieu Riou <ma...@gmail.com> wrote:
> > >
> > > So I guess it would make sense to have the engine copy the mex
> > > properties
> > > from myrole mex to partnerrole mex when it's invoking. Some sort of
> > > property
> > > propagation feature. The only place where this is possible is when the
> > >
> > > partner role mex is created, right where the invocation is triggered
> > > in
> > > BpelRuntimeContextImpl.invoke(). Here you have the partner mex that is
> > > being
> > > created and also the my role mex that originated the exchange
> > > (_instantiatingMessageExchange). So copying properties from the latter
> > > to
> > > the former wouldn't be so hard I guess.
> > >
> > > And then it would be easy in MessageExchangeContextImpl.invokePartner()
> > > to
> > > get the properties from the partner mex and and set them on the jbi
> > > mex.
> > > Makes sense?
> >
> >
> >
> > This isn't entirely clear to me.    The mex that originated the exchange
> > isn't necessarily the instantiating mex.  That's what held me from
> > commenting on this thread so far.   Implementing the feature for the
> > instantiating mex is interesting but doesn't cover the general case.
> >
> > To locate the mex you would have to look in the outstanding mex map and
> > probably use the scope hierarchy to determine which is the eldest.  I think
> > we would need to provide a new API method to the engine to enable this.
> >
> > alex
> >
> >
> >
>

Re: JBI and correlation of MessageExchange

Posted by Matthieu Riou <ma...@gmail.com>.
Yeah, that's what I was going to reply but you've been quicker :) After
thinking of it a bit more I remembered that the instantiating mex is mostly
null. I think the outstanding mex map wouldn't work either as you'd find
something only for request / response scenarios and not for async.

On 3/28/07, Alex Boisvert <bo...@intalio.com> wrote:
>
> On 3/28/07, Matthieu Riou <ma...@gmail.com> wrote:
> >
> > So I guess it would make sense to have the engine copy the mex
> > properties
> > from myrole mex to partnerrole mex when it's invoking. Some sort of
> > property
> > propagation feature. The only place where this is possible is when the
> > partner role mex is created, right where the invocation is triggered in
> > BpelRuntimeContextImpl.invoke(). Here you have the partner mex that is
> > being
> > created and also the my role mex that originated the exchange
> > (_instantiatingMessageExchange). So copying properties from the latter
> > to
> > the former wouldn't be so hard I guess.
> >
> > And then it would be easy in MessageExchangeContextImpl.invokePartner()
> > to
> > get the properties from the partner mex and and set them on the jbi mex.
> >
> > Makes sense?
>
>
>
> This isn't entirely clear to me.    The mex that originated the exchange
> isn't necessarily the instantiating mex.  That's what held me from
> commenting on this thread so far.   Implementing the feature for the
> instantiating mex is interesting but doesn't cover the general case.
>
> To locate the mex you would have to look in the outstanding mex map and
> probably use the scope hierarchy to determine which is the eldest.  I think
> we would need to provide a new API method to the engine to enable this.
>
> alex
>
>
>

Re: JBI and correlation of MessageExchange

Posted by Alex Boisvert <bo...@intalio.com>.
On 3/28/07, Matthieu Riou <ma...@gmail.com> wrote:
>
> So I guess it would make sense to have the engine copy the mex properties
> from myrole mex to partnerrole mex when it's invoking. Some sort of
> property
> propagation feature. The only place where this is possible is when the
> partner role mex is created, right where the invocation is triggered in
> BpelRuntimeContextImpl.invoke(). Here you have the partner mex that is
> being
> created and also the my role mex that originated the exchange
> (_instantiatingMessageExchange). So copying properties from the latter to
> the former wouldn't be so hard I guess.
>
> And then it would be easy in MessageExchangeContextImpl.invokePartner() to
> get the properties from the partner mex and and set them on the jbi mex.
> Makes sense?



This isn't entirely clear to me.    The mex that originated the exchange
isn't necessarily the instantiating mex.  That's what held me from
commenting on this thread so far.   Implementing the feature for the
instantiating mex is interesting but doesn't cover the general case.

To locate the mex you would have to look in the outstanding mex map and
probably use the scope hierarchy to determine which is the eldest.  I think
we would need to provide a new API method to the engine to enable this.

alex

Re: JBI and correlation of MessageExchange

Posted by Matthieu Riou <ma...@gmail.com>.
Sorry for letting this on the sideI think I just got diverted at some point.
Anyway looking into this a bit more the correct mechanism would be, as you
first mentioned, to set the servicemix correlation id as an ODE message
exchange property for the MyRoleMex created in OdeService.invokeOde(). Now
the problem is to retrieve it in MessageExchangeContextImpl.invokePartner()
which is virtually impossible as is as you only have the parner mex created
for the invocation and lost track of the myrole mex.

So I guess it would make sense to have the engine copy the mex properties
from myrole mex to partnerrole mex when it's invoking. Some sort of property
propagation feature. The only place where this is possible is when the
partner role mex is created, right where the invocation is triggered in
BpelRuntimeContextImpl.invoke(). Here you have the partner mex that is being
created and also the my role mex that originated the exchange
(_instantiatingMessageExchange). So copying properties from the latter to
the former wouldn't be so hard I guess.

And then it would be easy in MessageExchangeContextImpl.invokePartner() to
get the properties from the partner mex and and set them on the jbi mex.
Makes sense?

Matthieu

On 3/28/07, Guillaume Nodet <gn...@gmail.com> wrote:
>
> Well, I'm not sure where the best place would be to
> store such properties.  Hopefully someone with
> more knowledge of Ode internals can help here.
> I think the IAPI may give a slot for the integration
> layer to store something in the database.  And this
> will be a definite need if we want to be able to not
> keep the JBI exchange in memory (I don't think
> the JBI exchange is stored somewhere).
>
> The exchanges ( org.apache.ode.bpel.iapi.MessageExchagne)
> has some placeholders for properties but afaik, they are specific
> to a given exchange, so that there is no way to link an
> outgoing exchange to the MyRoleExhcange that created
> the process instance.
>
> On 3/28/07, Roger Menday <r....@fz-juelich.de> wrote:
> >
> >
> > Hi Guillaume,
> >
> > I am also interested in seeing such a feature, i.e. allowing the
> > properties of the initiating JBI exchange to be copied into the messages
> > leaving the process. Do you think it's a big thing to add ?
> >
> > regards,
> >
> > Roger
> >
> > > Hum, not sure if it will really help me.
> > > Let me restate what I need:  the incoming JBI exchange
> > > contain a known property and I want to store it with the
> > > process instance somehow (in a variable or any other way).
> > > Then, when an invocation is performed, I meed to set this
> > > property on the newly created JBI exchange.
> > >
> > > This is not about correlation for the BPEL process itself.
> > > And I can't reuse something generated by Ode as the property
> > > value is usually already set on the incoming exchange.
> > >
> > > So I'm not sure if the session ids can be used, especially
> > > because i need to use existing values and not let Ode
> > > generate those.  And it seems there is no way to override that
> > > currently: see BpelRuntimeContextImpl.initializePartnerLinks
> > >
> > > I was thinking about using the MessageExchange DAO to set
> > > the property, but my problem is that I haven't found a way
> > > to retrieve the MyRoleMessageExchange that was used
> > > to create the process when inside an
> > MessageExchangeContext.invokePartner
> > > call.
> > >
> > > On 3/7/07, Matthieu Riou <ma...@gmail.com> wrote:
> > >>
> > >> Hi,
> > >>
> > >> I think you'll just need to do something like:
> > >>
> > >>       String mySess = mex.getProperty(
> > >> PartnerRoleMessageExchange.PROPERTY_SEP_MYROLE_SESSIONID);
> > >>       String partnerSess = mex.getProperty(
> > >> PartnerRoleMessageExchange.PROPERTY_SEP_PARTNERROLE_EPR);
> > >>
> > >> For more information on how we handle the correlations this way:
> > >>
> > >> http://incubator.apache.org/ode/implicit-correlations.html
> > >> http://incubator.apache.org/ode/stateful-exchange-protocol.html
> > >>
> > >> Cheers,
> > >> Matthieu
> > >>
> > >> On 3/5/07, Guillaume Nodet <gn...@gmail.com> wrote:
> > >> >
> > >> > Hi guys !
> > >> >
> > >> > In ServiceMix, there is a property named "
> > >> > org.apache.servicemix.correlationId"
> > >> > that is used to correlate MessageExchanges.
> > >> > For example, if a JBI endpoint receives a JBI exchange, and send
> > >> another
> > >> > jbi exchange while processing it, the components will forward this
> > >> > property
> > >> > from the inbound exchange to the outbound exchange (or create it
> > >> with a
> > >> > unique
> > >> > id if none was set).  This enables tracking of a "JBI process".  I
> > >> think
> > >> > ODE
> > >> > would benefit of such a behavior when deployed inside ServiceMix,
> > >> so I'm
> > >> > trying
> > >> > to implement it.
> > >> >
> > >> > However, I'm not sure what the best way to do that.  I would say
> that
> > >> the
> > >> > best way
> > >> > is to use properties defined on
> > >> org.apache.ode.bpel.iapi.MessageExchange
> > >> ,
> > >> > but I haven't been able to find a way to retrieve these properties
> > >> from
> > >> > a MessageExchangeContext.invokePartner call.
> > >> >
> > >> > Any hints on how to do that ?
> > >> >
> > >> > Cheers,
> > >> > Guillaume Nodet
> > >> > ------------------------
> > >> > Architect, LogicBlaze (http://www.logicblaze.com/)
> > >> > Blog: http://gnodet.blogspot.com/
> > >> >
> > >>
> > >
> > >
> > >
> >
> >
> >
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Architect, LogicBlaze (http://www.logicblaze.com/)
> Blog: http://gnodet.blogspot.com/
>

Re: JBI and correlation of MessageExchange

Posted by Guillaume Nodet <gn...@gmail.com>.
Well, I'm not sure where the best place would be to
store such properties.  Hopefully someone with
more knowledge of Ode internals can help here.
I think the IAPI may give a slot for the integration
layer to store something in the database.  And this
will be a definite need if we want to be able to not
keep the JBI exchange in memory (I don't think
the JBI exchange is stored somewhere).

The exchanges ( org.apache.ode.bpel.iapi.MessageExchagne)
has some placeholders for properties but afaik, they are specific
to a given exchange, so that there is no way to link an
outgoing exchange to the MyRoleExhcange that created
the process instance.

On 3/28/07, Roger Menday <r....@fz-juelich.de> wrote:
>
>
> Hi Guillaume,
>
> I am also interested in seeing such a feature, i.e. allowing the
> properties of the initiating JBI exchange to be copied into the messages
> leaving the process. Do you think it's a big thing to add ?
>
> regards,
>
> Roger
>
> > Hum, not sure if it will really help me.
> > Let me restate what I need:  the incoming JBI exchange
> > contain a known property and I want to store it with the
> > process instance somehow (in a variable or any other way).
> > Then, when an invocation is performed, I meed to set this
> > property on the newly created JBI exchange.
> >
> > This is not about correlation for the BPEL process itself.
> > And I can't reuse something generated by Ode as the property
> > value is usually already set on the incoming exchange.
> >
> > So I'm not sure if the session ids can be used, especially
> > because i need to use existing values and not let Ode
> > generate those.  And it seems there is no way to override that
> > currently: see BpelRuntimeContextImpl.initializePartnerLinks
> >
> > I was thinking about using the MessageExchange DAO to set
> > the property, but my problem is that I haven't found a way
> > to retrieve the MyRoleMessageExchange that was used
> > to create the process when inside an
> MessageExchangeContext.invokePartner
> > call.
> >
> > On 3/7/07, Matthieu Riou <ma...@gmail.com> wrote:
> >>
> >> Hi,
> >>
> >> I think you'll just need to do something like:
> >>
> >>       String mySess = mex.getProperty(
> >> PartnerRoleMessageExchange.PROPERTY_SEP_MYROLE_SESSIONID);
> >>       String partnerSess = mex.getProperty(
> >> PartnerRoleMessageExchange.PROPERTY_SEP_PARTNERROLE_EPR);
> >>
> >> For more information on how we handle the correlations this way:
> >>
> >> http://incubator.apache.org/ode/implicit-correlations.html
> >> http://incubator.apache.org/ode/stateful-exchange-protocol.html
> >>
> >> Cheers,
> >> Matthieu
> >>
> >> On 3/5/07, Guillaume Nodet <gn...@gmail.com> wrote:
> >> >
> >> > Hi guys !
> >> >
> >> > In ServiceMix, there is a property named "
> >> > org.apache.servicemix.correlationId"
> >> > that is used to correlate MessageExchanges.
> >> > For example, if a JBI endpoint receives a JBI exchange, and send
> >> another
> >> > jbi exchange while processing it, the components will forward this
> >> > property
> >> > from the inbound exchange to the outbound exchange (or create it
> >> with a
> >> > unique
> >> > id if none was set).  This enables tracking of a "JBI process".  I
> >> think
> >> > ODE
> >> > would benefit of such a behavior when deployed inside ServiceMix,
> >> so I'm
> >> > trying
> >> > to implement it.
> >> >
> >> > However, I'm not sure what the best way to do that.  I would say that
> >> the
> >> > best way
> >> > is to use properties defined on
> >> org.apache.ode.bpel.iapi.MessageExchange
> >> ,
> >> > but I haven't been able to find a way to retrieve these properties
> >> from
> >> > a MessageExchangeContext.invokePartner call.
> >> >
> >> > Any hints on how to do that ?
> >> >
> >> > Cheers,
> >> > Guillaume Nodet
> >> > ------------------------
> >> > Architect, LogicBlaze (http://www.logicblaze.com/)
> >> > Blog: http://gnodet.blogspot.com/
> >> >
> >>
> >
> >
> >
>
>
>


-- 
Cheers,
Guillaume Nodet
------------------------
Architect, LogicBlaze (http://www.logicblaze.com/)
Blog: http://gnodet.blogspot.com/

Re: JBI and correlation of MessageExchange

Posted by Roger Menday <r....@fz-juelich.de>.
Hi Guillaume,

I am also interested in seeing such a feature, i.e. allowing the 
properties of the initiating JBI exchange to be copied into the messages 
leaving the process. Do you think it's a big thing to add ?

regards,

Roger

> Hum, not sure if it will really help me.
> Let me restate what I need:  the incoming JBI exchange
> contain a known property and I want to store it with the
> process instance somehow (in a variable or any other way).
> Then, when an invocation is performed, I meed to set this
> property on the newly created JBI exchange.
>
> This is not about correlation for the BPEL process itself.
> And I can't reuse something generated by Ode as the property
> value is usually already set on the incoming exchange.
>
> So I'm not sure if the session ids can be used, especially
> because i need to use existing values and not let Ode
> generate those.  And it seems there is no way to override that
> currently: see BpelRuntimeContextImpl.initializePartnerLinks
>
> I was thinking about using the MessageExchange DAO to set
> the property, but my problem is that I haven't found a way
> to retrieve the MyRoleMessageExchange that was used
> to create the process when inside an MessageExchangeContext.invokePartner
> call.
>
> On 3/7/07, Matthieu Riou <ma...@gmail.com> wrote:
>>
>> Hi,
>>
>> I think you'll just need to do something like:
>>
>>       String mySess = mex.getProperty(
>> PartnerRoleMessageExchange.PROPERTY_SEP_MYROLE_SESSIONID);
>>       String partnerSess = mex.getProperty(
>> PartnerRoleMessageExchange.PROPERTY_SEP_PARTNERROLE_EPR);
>>
>> For more information on how we handle the correlations this way:
>>
>> http://incubator.apache.org/ode/implicit-correlations.html
>> http://incubator.apache.org/ode/stateful-exchange-protocol.html
>>
>> Cheers,
>> Matthieu
>>
>> On 3/5/07, Guillaume Nodet <gn...@gmail.com> wrote:
>> >
>> > Hi guys !
>> >
>> > In ServiceMix, there is a property named "
>> > org.apache.servicemix.correlationId"
>> > that is used to correlate MessageExchanges.
>> > For example, if a JBI endpoint receives a JBI exchange, and send 
>> another
>> > jbi exchange while processing it, the components will forward this
>> > property
>> > from the inbound exchange to the outbound exchange (or create it 
>> with a
>> > unique
>> > id if none was set).  This enables tracking of a "JBI process".  I 
>> think
>> > ODE
>> > would benefit of such a behavior when deployed inside ServiceMix, 
>> so I'm
>> > trying
>> > to implement it.
>> >
>> > However, I'm not sure what the best way to do that.  I would say that
>> the
>> > best way
>> > is to use properties defined on 
>> org.apache.ode.bpel.iapi.MessageExchange
>> ,
>> > but I haven't been able to find a way to retrieve these properties 
>> from
>> > a MessageExchangeContext.invokePartner call.
>> >
>> > Any hints on how to do that ?
>> >
>> > Cheers,
>> > Guillaume Nodet
>> > ------------------------
>> > Architect, LogicBlaze (http://www.logicblaze.com/)
>> > Blog: http://gnodet.blogspot.com/
>> >
>>
>
>
>

Re: JBI and correlation of MessageExchange

Posted by Guillaume Nodet <gn...@gmail.com>.
Hum, not sure if it will really help me.
Let me restate what I need:  the incoming JBI exchange
contain a known property and I want to store it with the
process instance somehow (in a variable or any other way).
Then, when an invocation is performed, I meed to set this
property on the newly created JBI exchange.

This is not about correlation for the BPEL process itself.
And I can't reuse something generated by Ode as the property
value is usually already set on the incoming exchange.

So I'm not sure if the session ids can be used, especially
because i need to use existing values and not let Ode
generate those.  And it seems there is no way to override that
currently: see BpelRuntimeContextImpl.initializePartnerLinks

I was thinking about using the MessageExchange DAO to set
the property, but my problem is that I haven't found a way
to retrieve the MyRoleMessageExchange that was used
to create the process when inside an MessageExchangeContext.invokePartner
call.

On 3/7/07, Matthieu Riou <ma...@gmail.com> wrote:
>
> Hi,
>
> I think you'll just need to do something like:
>
>       String mySess = mex.getProperty(
> PartnerRoleMessageExchange.PROPERTY_SEP_MYROLE_SESSIONID);
>       String partnerSess = mex.getProperty(
> PartnerRoleMessageExchange.PROPERTY_SEP_PARTNERROLE_EPR);
>
> For more information on how we handle the correlations this way:
>
> http://incubator.apache.org/ode/implicit-correlations.html
> http://incubator.apache.org/ode/stateful-exchange-protocol.html
>
> Cheers,
> Matthieu
>
> On 3/5/07, Guillaume Nodet <gn...@gmail.com> wrote:
> >
> > Hi guys !
> >
> > In ServiceMix, there is a property named "
> > org.apache.servicemix.correlationId"
> > that is used to correlate MessageExchanges.
> > For example, if a JBI endpoint receives a JBI exchange, and send another
> > jbi exchange while processing it, the components will forward this
> > property
> > from the inbound exchange to the outbound exchange (or create it with a
> > unique
> > id if none was set).  This enables tracking of a "JBI process".  I think
> > ODE
> > would benefit of such a behavior when deployed inside ServiceMix, so I'm
> > trying
> > to implement it.
> >
> > However, I'm not sure what the best way to do that.  I would say that
> the
> > best way
> > is to use properties defined on org.apache.ode.bpel.iapi.MessageExchange
> ,
> > but I haven't been able to find a way to retrieve these properties from
> > a MessageExchangeContext.invokePartner call.
> >
> > Any hints on how to do that ?
> >
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Architect, LogicBlaze (http://www.logicblaze.com/)
> > Blog: http://gnodet.blogspot.com/
> >
>



-- 
Cheers,
Guillaume Nodet
------------------------
Architect, LogicBlaze (http://www.logicblaze.com/)
Blog: http://gnodet.blogspot.com/

Re: JBI and correlation of MessageExchange

Posted by Matthieu Riou <ma...@gmail.com>.
Hi,

I think you'll just need to do something like:

      String mySess = mex.getProperty(
PartnerRoleMessageExchange.PROPERTY_SEP_MYROLE_SESSIONID);
      String partnerSess = mex.getProperty(
PartnerRoleMessageExchange.PROPERTY_SEP_PARTNERROLE_EPR);

For more information on how we handle the correlations this way:

http://incubator.apache.org/ode/implicit-correlations.html
http://incubator.apache.org/ode/stateful-exchange-protocol.html

Cheers,
Matthieu

On 3/5/07, Guillaume Nodet <gn...@gmail.com> wrote:
>
> Hi guys !
>
> In ServiceMix, there is a property named "
> org.apache.servicemix.correlationId"
> that is used to correlate MessageExchanges.
> For example, if a JBI endpoint receives a JBI exchange, and send another
> jbi exchange while processing it, the components will forward this
> property
> from the inbound exchange to the outbound exchange (or create it with a
> unique
> id if none was set).  This enables tracking of a "JBI process".  I think
> ODE
> would benefit of such a behavior when deployed inside ServiceMix, so I'm
> trying
> to implement it.
>
> However, I'm not sure what the best way to do that.  I would say that the
> best way
> is to use properties defined on org.apache.ode.bpel.iapi.MessageExchange,
> but I haven't been able to find a way to retrieve these properties from
> a MessageExchangeContext.invokePartner call.
>
> Any hints on how to do that ?
>
> Cheers,
> Guillaume Nodet
> ------------------------
> Architect, LogicBlaze (http://www.logicblaze.com/)
> Blog: http://gnodet.blogspot.com/
>