See http://fusesf.fusesource.org/docs/2.2/bind_trans/HTTPDecoupled.html for a discussion of decoupled endpoints.
http://iona.com/support/docs/artix/5.5/jaxrpc_pguide/references12.html talks about using a WSDL callback pattern. The code examples are all from JAX-RPC, but it should be an OK starting point. -----Original Message----- From: EVENO Manuel [mailto:[email protected]] Sent: Thursday, August 06, 2009 10:39 AM To: [email protected] Subject: RE: Asynchronous Invocation and connection keep alive on the TCP level Do you have example or documentation of a "decoupled response endpoint" or the callbacks-tyle mecanism you wrote about ? I can find anything on the CXF Wiki ... Manuel -----Message d'origine----- De : Eoghan Glynn [mailto:[email protected]] Envoyé : jeudi 6 août 2009 16:04 À : [email protected] Objet : Re: Asynchronous Invocation and connection keep alive on the TCP level Andrew is correct. JAX-WS async is purely a convenience mechanism to allow the application avoid creating a separate thread to manage the invocation direction. What you really need to avoid is tying up the client->server connection for the duration of the long-running invocation. This could be achieved via WS-Addressing with a decoupled response endpoint , so that the client->server may be torn down once the request has been transmitted and the response when ready is sent over a separate server->client connection. Though it sounds like WS-A is not an option server->for you. Otherwise you can model a polling-style (as suggested by Glen) or callback-style of interaction in the WSDL. Cheers, Eoghan 2009/8/6 Andrew Clegg <[email protected]> > 2009/8/5 conficio <[email protected]>: > > > My question is: Does the asynchronous Web service some active > > polling > across > > the TCP connection to keep it alive? Is that the solution I'm > > looking > for, > > Asynchronous invocation? > > I'm happy to be corrected if wrong, but I believe the actual TCP > conversation is basically the same for CXF sync/async service > invocation, it just *appears* to work asynchronously from the POV of > the client code. > > For really long-running jobs you are probably better off doing proper > server-side asynchronous services with persistent state, like this: > > http://www.jroller.com/gmazza/entry/creating_service_side_asynchronous > _web > > Andrew. > > -- > :: http://biotext.org.uk/ :: >
