ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Assaf Arkin" <ar...@intalio.com>
Subject Re: Integration API
Date Fri, 02 Jun 2006 00:16:55 GMT
On 6/1/06, Lance Waterman <lance.waterman@gmail.com> 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? ).

On top of the sync/async multi-layer protocol stack we have the actual
application API. This one can be synchronous, asynchronous or both. A
modern service bus would offer you both.

The synchronous API is easier to code for, so the default option if
you're writing a lot of code. You can always optimize it better. But
when you're designing a process you don't have that level of control
to optimize it later, so the engine needs to decide. And it needs to
consider management and performance.

Separating a limited pool of process engine threads that only block
for local resources (CPU, memory, database) and an unlimited pool of
messaging threads that block for external resources (services you
invoke, possibly out there on separate machines) gives you better
performance and the right amount of control to tune the engine. It
also means that when one process invokes the other, only one process
engine thread is actually busy doing any work. If you have three
processes in that chain, it's still only one active process engine
thread.

It's easier to scale the engine when it doesn't itself block waiting
for other services to respond. The IAPI doesn't change how the engine
works right now, it simply gives it the ability to utilize the
asynchronous API offered by the message bus.

assaf


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


-- 
CTO, Intalio
http://www.intalio.com

Mime
View raw message