Hi Dennis, Thanks for the suggestion! I agree WS-ReliableMessaging can be used to solve the problem, but it requires the client to support the WS-RM protocol as well.
I was thinking that with regular asynchronous messaging that once the client got their HTTP 202 ack back, that they could count on getting a callback if the server side had some sort of storage to persist the relationship between message ids and ReplyTo URLs. You are saying this is not possible (or maybe even desirable) and solving this problem requires using WS-RM? Thanks, Jesse -----Original Message----- From: Dennis Sosnoski [mailto:[email protected]] Sent: Wednesday, November 20, 2013 12:06 PM To: [email protected] Subject: Re: long running asynchronous service provider You can use WS-ReliableMessaging for this: http://cxf.apache.org/docs/ws-reliablemessaging.html - Dennis Dennis M. Sosnoski Java Web Services Consulting <http://www.sosnoski.com/consult.html> CXF and Web Services Security Training <http://www.sosnoski.com/training.html> Web Services Jump-Start <http://www.sosnoski.com/jumpstart.html> On 11/21/2013 07:34 AM, Jesse Pangburn wrote: > Hi, > I use the jax-ws Provider mechanism to implement a service provider: > @WebServiceProvider > @ServiceMode(value = Service.Mode.MESSAGE) public class SOAPProvider > implements Provider<StreamSource> > > If WS-Addressing is enabled and I receive a message with a ReplyTo address, > then the server will automatically send back an immediate HTTP 202 to the > request. When I finish computing a reply message and return it in a > StreamSource (in this case), then CXF automatically makes a new HTTP request > to the ReplyTo address and sends the reply there. This is the normal (and > expected) asynchronous processing flow. > > It works, but it's not practical for a service that needs to reliably send > reply messages to requests that it received. Suppose the service even > processed the request for a minute- it's quite likely that a service will be > interrupted by a server restart or something. The caller will never get > their callback. Worse, what if the transactions run for days? And there are > lots of them? This mechanism works for testing but is not production quality > for anything that needs reliable responses. > > Is there a mechanism I'm missing for storing these transactions to a database > or something, and putting the response processing in a separate thread as > well? Some way to make asynchronous transactions reliable? > > Thanks, > Jesse >
