cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Pangburn <>
Subject RE: long running asynchronous service provider
Date Wed, 20 Nov 2013 21:27:54 GMT
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?


-----Original Message-----
From: Dennis Sosnoski [] 
Sent: Wednesday, November 20, 2013 12:06 PM
Subject: Re: long running asynchronous service provider

You can use WS-ReliableMessaging for this:

   - Dennis

Dennis M. Sosnoski
Java Web Services Consulting <>
CXF and Web Services Security Training
Web Services Jump-Start <>

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

View raw message