Asynch Webservice and Routing

[jplenhart]

Hi,

I have a use-case that I am working on with a couple other developers.

Essentially we are looking to do the following:

1) Send a message via an asynch webservice - this would be our gateway
2) Drop off the message anywhere (say a directory for simplicity)
3) Have a listener listen for a processed message in that directory
4) Route it back to the original sender

I did not see any examples of configuring an asynchrounous webservice - should we follow the synchronous example for now?

Also, what is the preferred manner to do something like WS-Addressing? In other words, how do I have the esb re-associate the message in the directory back to the original sender - perhaps jBPM comes in here.

Any direction is greatly appreciated.

--Jason

[jplenhart]

To add a further clarification - we are embarking on attempting to integrate a bunch of other attributes to this use-case but for now just trying to get a simple end to end working right now.

We use JAX-WS 2.x for our webservices - wondering if it is possible to use the WSAdapter for JAX-WS based webservices?

Thanks,

Jason

[tfennelly]

So as far as exposing Webservice endpoints are concerned, we have the SOAPProcessor action, which is basically a back door into the JBossWS container. You deploy a webservice on JBossWS (can be bundled inside a .esb) and you can invoke it over any channel supported by the ESB (HTTP, JMS, FTP etc). The SOAPProcessor action is actually very simple at the moment. It just receives the SOAP payload from the listener and hooks it directly into the JBossWS endpoint. So at the moment we don't do any of the following within the SOAPProcessor:

1. Interpret the SOAP payload in any way => we don't pull out any WS-A info from the incoming message.
2. Provide any automation around Webservice endpoint generation e.g. we'd like to be able to auto-generate a webservice endpoint for exposing a backend EJB service etc. This way you might not have to manually create the webserive impl (jsr181 etc), as you do at the moment.

On the other side (consuming webservices), we have the SOAPClient action.

If you haven't already done so... check out these docs: http://wiki.jboss.org/wiki/Wiki.jsp?page=WebservicesSupport

There are a number of Webservice related quickstarts that you may have seen. The one that sounds most like your usecase is the webservice_bpel quickstart. There's a flash demo available online (on the wiki - link above) that walks through this quickstart.

[burrsutter]

Review the webservice_producer example and at @OneWay to the methods you wish to be "async". I've not tested it recently.

The WSDL is generated so that it has a request but no expected reply.

Please give that a try and tell us what you think.

Another thing to keep in mind, how will you get back to the "client" in a async mode? What kind of "client" is it? If my client is an ASP.NET application I can easily provide a "call back" WS. If my client is a VB.NET WinFrom app then that is a different animal.

[jplenhart]

You are a step ahead of me Burr ... I posted a separate post outlining how I might be able to get a message back. But I am not sure if I am on the right track:

http://www.jboss.com/index.html?module=bb&op=viewtopic&t=116635

Thanks,

Jason

[jplenhart]

The problem I have is routing the message back - I would need to reassociate a message that came back to the original message in the message store.

Cannot readily do this - even if I could change the UID - I still cannot determine where in the process I am. For example the 'DELIVERED' column would be for which leg of the trip?

I got something working with the current database - but I would not want to support it as I am not proud of my code that I strung together :-)

The use case we were trying to solve is a prominent one for us - there is not quick start for it so we really struggled end to end. I figure most folks would not have the blind sort of send-back from a service that I have. Most services that send a response would probably publish to a topic or something - not throw it on a queue for anyone to get.

[marklittle]

Any chance you can use the RelatesTo and MessageID parts of the Message header? They're there for correlation.

[jplenhart]

Hi Mark,

The worked through it last nigh - and concluded that this type use case is best served by implementing in a BPEL process and correlating through the BPEL constructs of correlate and alias properties into that correlation.

Any thoughts,

Jason

[marklittle]

Yes, BPEL correlation sets will do it too.