Does CXF offer support option #2? via wsa for all supported transport? How does this work in the case that the server itself goes down - the task would have to be handled in an asynchronous manner by the server anyways so perhaps option #3 is the most robust option i.e. decoupled requests and responses?
On Tue, Aug 19, 2008 at 10:50 AM, Eoghan Glynn <[EMAIL PROTECTED]>wrote: > > Adrian, > > There are art least two orthongonal issues here: > > 1. Whether the client application code is written in an async style using > the JAX-WS AsyncCallback facility. > > 2. Whether the transport-level interactions for the request and response > delivery are decoupled (so that a client->server connection does not have to > be held open for the duration of the request lifetime, and instead the > response when ready is pushed out to the client via a new server->client > connection) > > If option #1 *only* is chosen (i.e. asycn code gen is used, but not a > decoupled transport), then the asynchrony is limited to the client runtime. > The server does not act any differently in this case, and is not aware that > the client app is structured in this way. The response callback is made from > a client runtime thread into the application code. But the server just > delivers the response in the normal way on the back-channel of the original > client->server transport. > > So option #1 alone just gives asynchrony in the application application > layer, but not in the transport layer. > > In order to layer some asynchrony over an inherently synchronous transport > like HTTP, then a non-anonymous wsa:replyTo is required (i.e. option #2). > > Yet another option would be to model the asynchrony via coupled oneways > .... e.g. server exposes void doSomething(), client exposes void > acceptReponse(response). Maybe this is what you're thinking of? Note though > this is a quite a different pattern, in the sense that the MEP is hard-wired > into explicit client & server side endpoints (whereas in option #2, the > client-side decoupled response endpoint is transparent to the application > code). > > /Eoghan > > > > Adrian Corcoran wrote: > >> I think that the important bit here is >> >> "I've tested the CXF ws-addressing example, and configured it for >> asynchronous code generation" >> >> Why do you need to client call to be asynchronous? You are submitting an >> asynchronous request and expecting to get back a 202 ( or should it be >> 204) >> immediately - in essence a void doSomething() call. >> >> The next call is a callback from the server to the client when the >> processing is complete. >> >> These are straight synchronous calls from the client point of view - 2 >> separate calls, but the server is working in an asynchronous manner. >> >> On Tue, Aug 19, 2008 at 10:20 AM, Eoghan Glynn <[EMAIL PROTECTED] >> >wrote: >> >> nicolas de loof wrote: >>> >>> Hello, >>>> >>>> I have a requirement to setup a WS client to do some asynchronous call, >>>> based on ws-addressing : the idea is to set the "replyTo" wsa property >>>> so >>>> that the client just send the request and just wait for the HTTP 202 >>>> (accepted), and not for the entire response that will come far latter. >>>> >>>> I've tested the CXF ws-addressing example, and configured it for >>>> asynchronous code generation - this works fine, but I'm not convinced my >>>> client waited for the HTTP 202 transport-level reponse, and have no idea >>>> how >>>> I could check this. >>>> >>>> >>> One way to test it would be to inject a sleep into the server-side >>> dispatch >>> of the partial respones (i.e. the 202). >>> >>> You could do this by implementing a very simple interceptor that did >>> nothing expect sleep for say 10 seconds. Add this interceptor to the out >>> chain on the server side. Then it would be immediately apparent whether >>> the >>> client runtime is blocking until the 202 arrives. >>> >>> Alternatively run the server under the control of a debugger, and place a >>> break point in >>> org.apache.cxf.ws.addresssing.ContextUtils.rebaseResponse(). >>> If you delay before resuming execution, again it should be apparent >>> whether >>> the client runtime is waiting for the 202. >>> >>> BTW if your server is running standalone, for example the ws_addressing >>> demo server launched from ant, its easy to attach to this JVM from >>> Eclipse >>> in order to debug. Just add something like the following properties to >>> the >>> server launch: >>> >>> -Xdebug -Xnoagent -Djava.compiler=NONE >>> -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005 >>> >>> /Eoghan >>> >>> >>> Could someone confirm this, and give me an idea how to implement this >>> >>>> half-asynchronous scenario : >>>> >>>> client >>>> | ------------------------> Request <wsa:replyTo="X"> >>>> | Server >>>> | <------------- HTTP 202 accepted ---------------- | >>>> | >>>> does some other work (asynchronously) | process... >>>> | >>>> | <------------- Response ------------------------- | >>>> AsyncHandler<Response> >>>> | ------------- HTTP 200 -------------------------> | >>>> >>>> >>>> Cheers, >>>> >>>> Nicolas >>>> >>>> >>>> ---------------------------- >>> IONA Technologies PLC (registered in Ireland) >>> Registered Number: 171387 >>> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland >>> >>> >> > ---------------------------- > IONA Technologies PLC (registered in Ireland) > Registered Number: 171387 > Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland >
