ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Nodet" <gno...@gmail.com>
Subject Re: JBI and correlation of MessageExchange
Date Wed, 28 Mar 2007 23:51:27 GMT
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 <boisvert@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 <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/
> >
>



-- 
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