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:19:18 GMT
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