Adrian Corcoran wrote:
Does CXF offer support option #2? via wsa for all supported transport?
Its supported for HTTP.
It doesn't make a great deal of sense for JMS, as this provides its own
native form of asynchrony.
Similarly for the local transport, as there's no real connection involved.
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?
If the server goes down, option #2 in itself doesn't help much.
Configuring WS-RM alongside option #2 will give you some survivability
across server failures - i.e. any unacknowledged requests will be
transparently re-sent by the client. Similarly any complete but
unsent/unACKed responses will be re-sent by the retsrated server if
WS-RM is configured with message persistence.
But there's still a window for loss when the invocation is is in-flight
in the server-side implementation code, if the ACK for the original
request was sent eagerly.
Also I don't think option #3 would be any more robust, unless the
server-side app explicitly persists the state of in-flight invocation to
some store that survives across server failure/restart.
Note also that CXF supports transparent failover of requests across a
cluster of replicated endpoints, but this depends on the server-side
failure being reported by the transport, so it doesn't really help in
either case #2 or #3. See[1] for to get a flavour of this clustering
feature.
Cheers,
Eoghan
[1]
http://svn.apache.org/viewvc/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/clustering/
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
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
