I want the class to be non-blocking for the application, BUT ensure the server got accepted the request. So I need some intermediate response, that WS-addressing on HTTP can provide using the HTTP 20x response on request post.
But now that I had to clearly expose my requirement, I consider this to be transport dependant and not WS fully compliant ... 2008/8/19 Adrian Corcoran <[EMAIL PROTECTED]> > ok my mis-understanding - so this is one synchronous call, however you want > it to be treated asynchronously over the http transport? > > 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 > > >
