This is an interesting topic. Personally I favour option #3 where the message is written to an internal datastore for processing on the server side. The reason being - interoperability, its a simpler approach, no need to start pulling in ws-*. Interoperability is bad enough at the payload level without having to get into the world of all the ws standards.
On Tue, Aug 19, 2008 at 11:33 AM, Eoghan Glynn <[EMAIL PROTECTED]>wrote: > 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 >
