Actually with BPEL correlation (the first option mentioned by Alex), there's theoretically no work to do from the web service implementer standpoint. The work is done on the process side.
On 3/1/07, Jiang Liu <[EMAIL PROTECTED]> wrote:
Thanks Alex, it really a lot more clear. It seems like eventhough "callback" is defined as "myRole" in service orchestration scenario, the logic still has to be concerned/implemented at consumer service side. Really hope this could be done automatically without any extra works. -----Original Message----- From: "Alex Boisvert" <[EMAIL PROTECTED]> To: [email protected] Date: Thu, 1 Mar 2007 20:48:05 -0800 Subject: Re: Re: Re: Re: Re: Asynchronous service invocation question Hi Jiang, In your example, you would also generate stubs from the callback portType. That way, in your implementation of the "call" portType you can call back the process. class ExternalServiceSkeleton { void simpleMethodFromCallPT(String input) { // .. // implement your service logic here // .. Callback cb = new Callback( url ); parameters = ...; cb.methodfromCallback( parameters ); } //... } You can also do the callback later (outside of your skeleton) using a different thread, etc. To achieve correlation with the original call, you several options, in order of increasing complexity: 1) use BPEL correlations (e.g. pass around token in message body) 2) pass "session" SOAP headers element (from the stateful exchange protocol) 3) pass full EPR in SOAP header (again from stateful exchnage protocol) #1 is the most standard and achievable using any SOAP stack. It has the benefit of being "business-friendly" as well, so when you look at the message you know exactly which process it corresponds to. cheers, alex On 2/28/07, Jiang Liu <[EMAIL PROTECTED]> wrote: > Hi Alex, > Thanks for your reply. For example, I have a external service WSDL: > > <definition ...> > <schema ...> > ... > <portType name="call" ...> > ... > <portType name="callback"> > ... > <binding> > ... > <service> > <port name="callEPR" ...> > <port name="callbackEPR" ...> > > <partnerLink name="servicePL> > <role name="call_PL" ...> > <role name="callback_PL" ...> > ... > </definition> > > A simple BPEL consume this service: > > <process ...> > <partnerLinkTypes> > ... > <partnerLinkType> > <myRole ="callback_PL" ...> > <partnerRole="call_PL" ...> > </partnerLinkTypes> > ... > <invoke partnerLinkType="call_PL" ...> > ... > <receive partnerLinkType="callback_PL" ...> > ... > ... > </process> > > Sorry the grammar is not strictly followed. :) > > Suppose that i implement the external service by using Axis2, when using > WSDL2Java to generate service skeleton, what i have to do is filling in the > "call" portType's business logic, for example: > > class ExternalServiceSkeleton { > //... > void simpleMethodFromCallPT(String input) { > //just say input is a String > //here do some work, e.g. database functions > /* > *now the work is done. should i implement callback? > *if its not and BPEL is "receving" at the other side, how > *could the callback be performed? > */ > } > //... > } > > You see the problem is at external service's skeleton, since its not > required to implement "callback" portType, then how the BPEL can receive > callback message? > > WS-Addressing covers reply-to address which helps for stateful EPR, but I > am not quite sure about the internal stateful connection mechanisms between > BPEL and partner services. > > Thanks so much for giving me so many advices :) > > > > ------------------------------ > Jiang Liu > Student Number: 3075163 > CS/Yallara Name: ljiang > RMIT, Melbourne > ------------------------------ Jiang Liu Student Number: 3075163 CS/Yallara Name: ljiang RMIT, Melbourne
