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
