ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Assaf Arkin" <ar...@intalio.com>
Subject Re: JBI and correlation of MessageExchange
Date Wed, 25 Apr 2007 19:47:28 GMT
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 <mbs@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 <gnodet@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 <boisvert@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 <gnodet@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/
> > >
> >
>

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