Hi Fillip, I am going to try your scenario today. I also want to use the same scenario. I'll let you know the progress.
Thanks Milinda. On Fri, Oct 9, 2009 at 9:54 PM, Filip Majernik <[email protected]>wrote: > Hi everybody, > first of all thank you all guys for helping and sorry for the delay. I've > been testing the behavior with asynchronous Web Services and got this > results. > > 1.) The first solution I tried with copying the endpoint references to the > partnerlink didn't work (as mentioned in the first email), but according to > the WS-Addressing recommodation, it's not even supposed to, as there is no > such element like wsa:ReplyTo in the EPR definition. > > 2.) Then I tried to somehow implement the solution from Mark (thanks again > for that idea). However, I haven't found anything about that in docs. So > this is what I've tried: > - the web service should have two operations: one for invoke and > another one for callback > - However, I haven't managed to implement a service like that for > axis2. According to this > http://www.ibm.com/developerworks/webservices/library/ws-axis2/ you just > have to change the message receiver in service.xml in order for that > service to act asynchronously (in that article, they say it's supposed to > be > org.apache.axis2.async.AsyncMessageReceiver, but that cannot be > instantiated, you have to use this one > org.apache.axis2.rpc.receivers.RPCInOutAsyncMessageReceiver). > - so I implemented a service with one operation, with asynchronous > message receiver, tested that web service with soapUI and wsa:ReplyTo > header > set up to some address and the asynchronous call worked > - I set up a new portType 'serviceCallbackPT' with an operation > 'processServiceCallback' in my BPEL process > - I changed the partnerLinkType to have two roles > > <plnk:partnerLinkType name="MyServicePLT"> > <plnk:role name="serviceProvider" portType="remoteServicePortType"/> > <plnk:role name="serviceConsumer" portType="serviceCallbackPT"/> > </plnk:partnerLinkType> > > - I changed the partnerLink to have following roles > > <bpel:partnerLink name="RemoteServicePartner" > partnerLinkType="MyServicePLT" partnerRole="serviceProvider" > myRole="serviceConsumer" /> > > - I changed the invoke operation to invoke the webservice without > specifying output variable > - invoke was then followed by receive from the portType defined for > myRole 'serviceConsumer' from the partnerLink > > I runned the process, but wsa:ReplyTo header was still set to > http://www.w3.org/2005/08/addressing/none. So I looked in the ode source > code (ode 1.3.2) and found out following. In the class > org.apache.ode.axis2.SoapExternalService in the method**** writeHeader() > the > wsa:ReplyTo header is being set up. The url from the EPR for myRole is set > to wsa:ReplyTo only when jms.reply.destination property for that EPR is > user > defined (and in that case it looks like > 'jms:/user-defined-destination-address') or the url contains (or starts > with) 'jms:/'. I have no idea why (and actually I don't know what jms is > :)). So I've changed the code to set up the url from EPR also in the other > case and it worked. The service was invoked with the wsa:ReplyTo header > being set up to the address of the 'serviceCallbackPT' (portType for > myRole). > > However, ode wasn't able to process the response message, because he > couldn't find the operation for the response message (that actually happens > in axis message processing, so ode didn't even get the message), but I > think > it is ws-addressing issue, as the wsa:Action in the message was indeed set > to false name. > > So my result is, that in ode 1.3.2 (release version) it is not possible to > invoke an asynchronous service, beacuse the wsa:ReplyTo header is not set > correctly. If anyone knows something more about this issue, please let me > know. > > Bye and thank you again, > Filip > > 2009/10/9 Håkon Sagehaug <[email protected]> > > > Hi Mark, > > > > I wanted to try your approach, but I'm not getting the hole picture I > think > > . My test setup is very easy. I've got a echo service, echos the users > > output back, this is of course not a long running task but I sleep it > for > > lets say 1 minute. Here is my wsdl > > > > <message name="SayHiRequestMsg"> > > <part name="parameters" element="tns:SayHi"> > > </part> > > </message> > > <message name="SayHiResponseMsg"> > > <part name="parameters" element="tns:SayHiResponse"> > > </part> > > </message> > > <portType name="EchoServicePortType"> > > <operation name="SayHi"> > > <documentation>Just a simple echo operation that returns the > > same > > string that is given to it.</documentation> > > <input message="tns:SayHiRequestMsg"> > > </input> > > </operation> > > </portType> > > > > <portType name="EchoServiceCallbackPortType"> > > <operation name="onResult"> > > <input message="tns:SayHiResponseMsg"> > > </input> > > </operation> > > </portType> > > > > > > <binding name="EchoServiceBinding" type="tns:EchoServicePortType"> > > <soap:binding style="document" > > transport="http://schemas.xmlsoap.org/soap/http"; /> > > <operation name="SayHi"> > > <soap:operation > > soapAction="http://www.bccs.uib.no/EchoService.wsdl/SayHi > " > > /> > > <input> > > <soap:body use="literal" /> > > </input> > > <output> > > <soap:body use="literal" /> > > </output> > > </operation> > > </binding> > > > > <binding name="EchoServiceCallBackBinding" > > type="tns:EchoServiceCallbackPortType"> > > <soap:binding style="document" > > transport="http://schemas.xmlsoap.org/soap/http"; /> > > <operation name="onResult"> > > <soap:operation > > soapAction=" > > http://www.bccs.uib.no/EchoService.wsdl/onResult"; > > /> > > <input> > > <soap:body use="literal" /> > > </input> > > </operation> > > </binding> > > <service name="EchoService"> > > <documentation>This WSDL file describes a simple Echo Service that > > echoes a string sendt to it. This service is intended > primarily > > for > > testing purposes.</documentation> > > <port name="EchoServiceLocal" binding="tns:EchoServiceBinding"> > > <soap:address location=" > > http://129.177.20.77:8080/axis2/services/EchoService"; /> > > </port> > > </service> > > > > > > I've got a schema that defines the messages. As you see I've got two > ports, > > one starting the ws and the other for the callback. So now I'm not sure > > what > > to do now. Should the service only bind to the binding for the sayhi > > operation, not the call back? I now want to model this in BPEL I guess > it > > would look something like this > > > > <invoke operation="ech:SayHi" portType="ech:EchoServicePortType" > > variable="ech:SayHiRequest" /> > > > > and receive like this > > > > <receice operation="ech:onResult" > > portType="ech:EchoServiceCallbackPortType" > > variable="ech:SayHiResonse" /> > > > > My questions is then, does ode send ws-addressing header so that the ws > > knows where to respond(1)? What would the service then respond with(2)? > > Since the sayHi operation does not return the actual result, just empty > or > > a > > message id. How should the service be implemented, should it implement > > onResult? > > > > Hope you can help with this? I also wanted to first model this with > > "normal" > > java client. > > > > cheers, Håkon > > > > Then my question is > > 2009/10/8 Ford, Mark <[email protected]> > > > > > With respect to your comment: > > > > > > “the invoke will be called and waits and times out” > > > > > > It sounds like you’re trying to model a long running operation as a > > > request/response operation within WSDL. If you do this, then you’ll > most > > > likely experience timeouts at the transport layer. A better > > implementation > > > is to split this long running operation into two port types. One to > make > > the > > > request to start the work for the service and the other to provide an > > > operation for the service to call you back with the response. The start > > > operation would be a one-way operation or a request-response with a > > simple > > > ACK as the response (perhaps with some values to use for correlation). > > This > > > would be modeled in BPEL by an invoke followed by a receive activity. > > > > > > You can create a partnerLinkType to model this by having a partner role > > for > > > the service you’re invoking and a myRole for your callback point. In > this > > > way, the relationship between the two port types is made explicit. > > > > > > As for ODE, I have not tested this but I would think that there might > be > > a > > > facility whereby you could have the endpoint reference for the > > partnerlink’s > > > myRole automatically populate as the reply-to header when invoking a > > > service. It seems reasonable that the service invocation layer would > > support > > > this but you’d have to check the docs or the source code to be sure. > > > > > > > > > On 10/8/09 4:18 AM, "Michael Dondrup" <[email protected]> > > wrote: > > > > > > Dear Filip, > > > we are currently working on exactly the same problem, because it would > > > be simple and neat solution. > > > However we didn't get there so far, so maybe it could be interesting > > > to have closer look at what it is exactly that doesn't work. > > > Do you have a process defined, that fails? Then maybe you could send > > > the process files so we could have a look it? > > > > > > We found that the WS-addressing did not seem to work with axis2 1.4.1 > > > and you should try axis2 1.5 on the service side. > > > To enable wsa support and asynchronous invocation add the following to > > > your services.xml within the service tags: > > > > > > <module ref="addressing" /> > > > <parameter name="messageReceiver.invokeOnSeparateThread">true</ > > > parameter> > > > > > > There will be other problems however: > > > - providing the correct port, role and partnerlink type, in the bpel > > > process for the service to reply to > > > - If I try to use a <invoke> and <receive> secence for invoking the > > > service, the invoke waits for the service to reply even though the > > > wsa:replyto works and the invoke will be called and waits and times > > > out. > > > The documentation on this topic is unfortunately totally incomplete. > > > Maybe we can try to resolve this together. > > > Best > > > Michael > > > > > > Am 07.10.2009 um 20:40 schrieb Filip Majernik: > > > > > > > Hi, > > > > I want to invoke an asynchronous Web Service from ode, but I cannot > > > > figure > > > > out how to change wsa:ReplyTo header. I've read about the EPR > > > > configuration > > > > on the ode website and tried something like this: > > > > > > > > <bpel:assign> > > > > <bpel:copy> > > > > <bpel:from> > > > > <bpel:literal> > > > > <wsa:EndpointReference xmlns:wsa=" > > > > http://www.w3.org/2005/08/addressing";< > > http://www.w3.org/2005/08/addressing%22> > > > > > > > > <wsa:Address> > > > > http://localhost:8080/axis2/services/MyService</wsa:Address>< > > http://localhost:8080/axis2/services/MyService%3C/wsa:Address%3E> > > > > <wsa:ReplyTo><wsa:Address> > > > > http://localhost:8080/axis2/services/ReplyToService > > > > </wsa:Address></wsa:ReplyTo> > > > > </wsa:EndpointReference> > > > > </bpel:literal> > > > > </bpel:from> > > > > <bpel:to partnerLink="testPartnerLink"/> > > > > </bpel:copy> > > > > </bpel:assign> > > > > > > > > but it isn't working. Does anyone maybe have a working example of > > > > changing > > > > the wsa:ReplyTo header (and invoking and asynchronous service) when > > > > invoking > > > > a service??? Or is it possible at all? > > > > > > > > Btw. my configuration is: > > > > apache ode 1.3.2 > > > > the webservice I am invoking is running on apache axis 1.4 > > > > > > > > Thank you guys in advance. > > > > Filip > > > > > > > > > > > > > > > > > > > > > -- > > > Mark Ford > > > MIT Lincoln Laboratory > > > 244 Wood Street > > > Lexington MA 02420 > > > (781) 981-1843 > > > > > > > > > > > -- > > Håkon Sagehaug, Scientific Programmer > > Parallab, Bergen Center for Computational Science (BCCS) > > UNIFOB AS (University of Bergen Research Company) > > > -- Milinda Pathirage Senior Software Engineer & Product Manager WSO2 BPS; http://wso2.org/bps WSO2 Inc.; http://wso2.com E-mail: [email protected], [email protected] Web: http://mpathirage.com Blog: http://blog.mpathirage.com
