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