On Thu August 6 2009 10:03:57 am Eoghan Glynn wrote: > 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 for > you. > > Otherwise you can model a polling-style (as suggested by Glen) or > callback-style of interaction in the WSDL.
Just a point of note: both the WS-Addressing decoupled response thing and the callback style thing would require that the server be able to open a port BACK to the client. Obviously, that requires the client to have their firewall and such configured to allow that which may not be the case. (On a side note: I would be kind of cool if the ws-addressing decoupled stuff could be configured to use upnp to negotiate with a router/firewall for a port. Just a thought. :-) In that case, the polling style is definitely the best option. Basically, your "doWorkThatTakesALongTime" method would return some sort of identifier immediately. You would add a "getResult(id)" method that would actually retrieve the result (or a status message if not done yet). Actually, you COULD even have getResult "wait" for the result for a period of time (like 10 minutes) and if it hasn't gotten the result, send back a "timed out, please retry" type thing and have the client loop on that call. On there server side, the getResult call could use the continuations stuff we added (providing you are using our Jetty stuff) to not even consume threads there. Dan > > 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_we > >b > > > > Andrew. > > > > -- > > > > :: http://biotext.org.uk/ :: -- Daniel Kulp [email protected] http://www.dankulp.com/blog
