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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > >
