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 Fri, 02 Jun 2006 14:14:36 GMT
Comments inline ...

Lance

On 6/1/06, Assaf Arkin <arkin@intalio.com> wrote:
>
> 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.


Agreed!

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)


I was under the impression that the ODE engine would not be managing any
thread resources.

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.


Per Maciej's response ( "their setters" ) I'm not seeing this in the API.

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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message