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 Wed, 28 Mar 2007 23:28:04 GMT
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 <gnodet@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 <matthieu.riou@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 <boisvert@intalio.com> wrote:
> > >
> > > On 3/28/07, Matthieu Riou <matthieu.riou@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/
>

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