ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance Waterman" <lance.water...@gmail.com>
Subject Re: Integration API
Date Mon, 05 Jun 2006 15:44:10 GMT
Maciej,

So what I hear you saying is that sometimes
PartnerRoleMessageExchange.reply(Message)
behaves as a "setter" and sometimes it behaves identical to
MyRoleMessageExchange.invoke(Message). And this behavior is predicated on
what order the client calls the .replyXXX() methods.

In either case it appears to me that the IL controls thread resources and I
don't see the engine doing any type of thread acquisition. Given an IL
thread, the engine simply executes a process instance until there is nothing
left to do for that given thread/message. That's not to say more than one IL
thread may be required to complete the process. Is this your understanding?

Lance

On 6/1/06, Maciej Szefler <mbs@intalio.com> wrote:
>
> To the engine replyAsync means:
> "Integration layer here, I know you (Bpel engine) asked me to invoke a
> two way (sychronous) operation on the partner, but as it happens, I
> can't get the answer from him just this moment, but I will provide it to
> you as soon as I have it --- trust me -- and don't wait up it may be a
> while, I don't want to leave you (or your transaction) hanging. When I
> do get it, I'll tell you about it by calling the
> PartnerRoleMessageExchange.replyXXX(...) method.
>
> As Assaf points out the idea of synchronous operations is a bit
> slippery. If you have request/response operations mapped on any sort of
> reliable transport (such as JMS or WS-RM) you need a way to break up the
> invocation into two phases.
>
> -mbs
>
> On Thu, 2006-06-01 at 13:24 -0600, Lance Waterman wrote:
> > I agree the problem is confusing and I understand the distinctions. What
> I'm
> > trying to understand is what this "hint" means to the engine. For the
> case
> > we are talking about it appears that a logical service interface is
> > advertising the fact that it is a request/response ( an <invoke>,
> however
> > this "hint" seems to imply  the engine should really treat this as a (
> > oneway <invoke> with <receive> ) and hence my questions about what the
> API
> > is doing. ( Is the engine polling for the response? Why not just block
> for
> > the response? ).
> >
> > Lance
> >
> > On 6/1/06, Assaf Arkin <arkin@intalio.com> wrote:
> > >
> > > This is probably the most confusing part of messaging.
> > >
> > > When you're doing a synchronous (request/response) operation using an
> > > asynchronous (JMS) API, that communicates on a synchronous (TCP)
> > > protocol which passes packes on an asynchronous (IP) protocol.
> > >
> > > Is it synchronous or asynchronous?
> > >
> > > Turns out it's never "synchronous all the way down"  (or
> > > asynchronous). It depends on which layer of the stack you're looking
> > > for.
> > >
> > > In BPEL you distinguish between a two-way operation (invoke, or
> > > receive/reply) and two separate one-way operations (invoke/receive, or
> > > receive/invoke).
> > >
> > > The bus (going back to our favorite topic) is where the one-way
> > > operation gets carried by a synchronous protocol, or the two-way
> > > operation by an asynchronous protocol, or any other combination.
> > >
> > > The only requirement on the engine is that it can support the two
> > > operation MEPs, without imposing a protocol selection on the bus, to
> > > allow for reasonable combinations.
> > >
> > > Assaf
> > >
> > >
> > > On 6/1/06, Lance Waterman <lance.waterman@gmail.com> wrote:
> > > > So the "hint" means the engine needs to poll the MessageExchange to
> find
> > > out
> > > > when the response is there?
> > > >
> > > > When does the burden of modeling an async pattern fall to the
> process
> > > > designer and/or service designer? Where BPEL allows for this to be
> > > > explicitly modeled as ( oneway <invoke> plus <receive> )?
> > > >
> > > > Lance
> > > >
> > > >
> > > > On 6/1/06, Maciej Szefler <mbs@intalio.com> wrote:
> > > > >
> > > > > These are "setters". The engine will expect one of them to be
> called.
> > > > > replyAsync is a "hint" for the engine that is used in the case
> when a
> > > > > synchronous operation is implemented by the integration layer in
> such
> > > a
> > > > > way such a way that the response is not immediately available.
> This
> > > > > would happen in at least two scenarios:
> > > > > 1) request / reply are delivered using a transactional transport
> such
> > > as
> > > > > JMS.
> > > > > 2) integration layer is an asynchronous bus.
> > > > > -mbs
> > > > >
> > > > > On Thu, 2006-06-01 at 09:09 -0600, Lance Waterman wrote:
> > > > > > So should the the .reply*() methods on
> PartnerRoleMessageExchange be
> > > > > viewed
> > > > > > as setters or callbacks? Is the expectation that the engine
> calls
> > > > > > MessageExchangeContext.invokePartner() the call returns and
then
> the
> > > > > engine
> > > > > > checks status PartnerRoleMessageExchange.getStatus() for a
> response?
> > > Or
> > > > > is
> > > > > > the expectation that PartnerRoleMessageExchange.reply(Message)
> is
> > > > > > implemented as a callback such that it has hooks into the
> process
> > > engine
> > > > > to
> > > > > > start "phase 2 invoke" and anything after?
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Lance
> > > > > >
> > > > > > On 5/31/06, Guillaume Nodet <guillaume.nodet@worldonline.fr>
> wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Lance Waterman wrote:
> > > > > > >
> > > > > > > > Thanks guys, I like this API. A couple of questions:
> > > > > > > >
> > > > > > > > 1) Not quite sure I follow how "
> > > > > PartnerRoleMessageExchange.replyAsync()"
> > > > > > > > works? This seems to imply the partner is dynamically
> changing
> > > the
> > > > > > > > signature
> > > > > > > > of the service interface.
> > > > > > >
> > > > > > >
> > > > > > > I guess it does not mean that the response will be provided
> with a
> > > > > > > callback, but rather
> > > > > > > that the underlying transport is asynchronous and that
the
> > > response is
> > > > > > > not available at the
> > > > > > > moment.  This may happen when using JMS for example.  If
using
> > > JMS,
> > > > > > > synchronous
> > > > > > > transactional request / response is not possible, because
the
> > > request
> > > > > > > can only be received
> > > > > > > when the transaction is commited.
> > > > > > > From my understanding, when the BPEL engine invokes a partner,
> you
> > > > > have
> > > > > > > to call one
> > > > > > > of the method defined on PartnerRoleMessageExchange.  If
you
> call
> > > > > > > replyAsync, it
> > > > > > > just means that you will have to call another method later
> when
> > > the
> > > > > > > response is received.
> > > > > > >
> > > > > > > > 2) MyRoleMessageExchange.setClientData() - is this
used to
> set
> > > > > > > > "out-of-band"/partnerLink data (i.e. EPR,JMS properties,
etc
> ...
> > > )?
> > > > > I
> > > > > > > can
> > > > > > > > get to this data from within a BPEL process using
> partnerLink in
> > > a
> > > > > > > <from>
> > > > > > > > clause - correct?
> > > > > > >
> > > > > > > I think this was one of my concern.  If the integration
layer
> > > receives
> > > > > a
> > > > > > > request from jms for example,
> > > > > > > it may need to store the replyTo jms destination in a reliable
> way
> > > so
> > > > > > > that when the process response
> > > > > > > is available, the integration layer can retrieve it to
send
> the
> > > > > response
> > > > > > > (this would also be the case
> > > > > > > for JBI).   I thought it would be easier to put the burden
of
> > > storing
> > > > > > > this data to the bpel engine rather
> > > > > > > than on the integration layer, because the bpel engine
already
> > > needs
> > > > > to
> > > > > > > store data, so it's just
> > > > > > > another field to store.
> > > > > > >
> > > > > > > > 3) I'm trying to correlate how an EPR fits into deployment.
> I'm
> > > > > assuming
> > > > > > > > that the EPR required for BpelEngine.createMessageExchange()
> is
> > > > > > > > produced/queried by deploying a BPEL document. The
> deployment
> > > API
> > > > > > > > produces
> > > > > > > > an EPR for each registered BPEL <process> definition.
In
> your
> > > API it
> > > > > > > > looks
> > > > > > > > like you have a stub for deployment "BpelServer.deploy()"
> that
> > > > > returns a
> > > > > > > > QName. Is the assumption that the client translates
the
> QName
> > > into
> > > > > an
> > > > > > > > EPR?
> > > > > > >
> > > > > > >
> > > > > > > Maybe one thing missing / implied, is that the deployment
API
> is
> > > > > > > reponsible for
> > > > > > > creating EPR for all receive operations (my role) and invoke
> > > > > operations.
> > > > > > > Else I do not really see how the BPEL engine could know
the
> EPR to
> > > use
> > > > > > > when invoking a partner, how to process the
> > > > > BpelEngine.isMyRoleEndpoint
> > > > > > > or how to route the message to the right BPEL process when
> using
> > > the
> > > > > > > BpelEngine.createMessageExchange.
> > > > > > >
> > > > > > > And I still do not understand why the operation name is
the
> only
> > > > > > > attribute available
> > > > > > > on message exchange.  Either put all attributes in the
EPR or
> put
> > > all
> > > > > > > available
> > > > > > > attributes on the exchange (imho we should at least have
the
> > > PortType
> > > > > > > QName).
> > > > > > >
> > > > > > > Cheers,
> > > > > > > Guillaume Nodet
> > > > > > >
> > > > > > > >
> > > > > > > > Lance
> > > > > > > >
> > > > > > > > On 5/25/06, Matthieu Riou <matthieu.riou@gmail.com>
wrote:
> > > > > > > >
> > > > > > > >>
> > > > > > > >> Hi all,
> > > > > > > >>
> > > > > > > >> I've just imported the revised version of the
integration
> API
> > > > > > > >> specified by Maciej (if somebody with the necessary
karma
> reads
> > > > > this,
> > > > > > > >> Maciej's CLA has been received but he's the last
one
> without an
> > > > > > > >> account) for review. He also brushed up the javadoc.
> > > > > > > >>
> > > > > > > >> Comments are welcome (even just to say "Good job
Maciej!"
> :-)
> > > ).
> > > > > > > >>
> > > > > > > >> Cheers,
> > > > > > > >>
> > > > > > > >> Matthieu.
> > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > CTO, Intalio
> > > http://www.intalio.com
> > >
>
>

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