ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cory <cory.har...@gmail.com>
Subject Re: Integration API
Date Wed, 31 May 2006 22:34:38 GMT
Hello All,

See my comments below.

Cheers,

-cory

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

Is the PartnerRoleMessageExchange.replyAsync() call back needed?  Is
it just a hint to the process that the transaction is going to be
committed in the middle of an out-in <invoke>?

What is driving the need for the MessageExchange stuff in the BPEL
engine API?  Is it just the ability to implement synchronous
request/response operations asynchronously.  We did spend sometime
thinking about this when building the BPE.  We eventually decided that
this was provide for by a one-way <invoke> and a <recieve>.  It feels
like some bus like functionality is creeping into the engine.


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

Mime
View raw message