cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Sosnoski <...@sosnoski.com>
Subject Re: long running asynchronous service provider
Date Wed, 20 Nov 2013 20:06:04 GMT
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
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message