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