cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: WS-Addressing asynch MEP, CXF-2167 and WSTF tests
Date Wed, 29 Sep 2010 17:28:21 GMT
On Wednesday 29 September 2010 11:51:04 am Andrew Dinn wrote:
> Hi Dan,
> Thanks for the explanation. I have a few comments inline.
> On 09/29/2010 02:54 PM, Daniel Kulp wrote:
> > 1) JAX-WS async client callbacks.   We need to correlate the incoming
> > message with the outgoing request so we can figure out which call back
> > object to call. This correlation could potentially be pushed into the
> > ClientImpl after the soap processing and everything is done, but it
> > still needs some way to correlate.
> Hmm, I had not ever considered combining async requests with response
> redirection via WSA ReplyTo/FaultTo (you probably need to be slightly
> out of your mind to do so :-). I guess it might be possible to do this
> to a degree, depending on where the response is redirected to. However,
> it has to be limited to some extent e.g. registering an async callback
> in the requester JVM cannot seriously be expected to work if the
> response is redirected to a different JVM.

Yea.  I think MUCH of the JAX-WS style stuff won't work correctly in the cases 
where ReplyTo/FaultTo doesn't come back to the same place as where the message 
originated.     If you don't use the async stuff, the calls will likely 
timeout and the client would get timeout exceptions.   If you do use async, 
you're likely to have memory leaks or similar.

> > 2) JAX-WS handlers - if I remember correctly, if a Handler on the
> > outgoing side sets a property on the context, it needs to be available
> > when the handler on the incoming side.   Thus, we would need some level
> > of correlation prior to handlers being called.   Our own interceptors
> > have the same issue.  For example, the Logging interceptors stick an ID
> > # on the exchange so you can visually correlate the messages in the logs
> > (although the logging interceptors run prior to the MAPCodec, so this
> > probably doesn't work in this case anyway). WS-SecurityPolicy also
> > requires this if signature confirmation is enabled.  We need to record
> > the signatures that were sent so we can make sure they are properly
> > confirmed on the response.  (although, thinking about this, I also don't
> > know if that works in the decoupled case)
> The handler spec also seems to be written on the assumption that a
> request response MEP has the response coming back to where it was sent
> from. But then again in the code I have written which relies on async
> FaultTo (or rather is speced so that it has to rely on it) I ensure that
> the handlers at the FaultTo end point know what to do on the basis of
> messageId/relatesTo values and shared JVM state (the client and FaultTo
> endpoint handler are not just in the same  JVM but also part of the same
> app with a common classloader/class space). I don't expect the JaxWS
> layer to manage that context sharing for me. Once again, it might be
> possible for the JaxWS layer to support this sharing of context data for
> outgoing request and incoming response handlers to some degree but it
> clearly cannot be extended to the inter-JVM case.

Right.  Again, this is kind of outside the scope of what JAX-WS really targets 
for it's usecases.

> > 3) WS-RM - but I don't really know all the details
> I am not sure either since I only glanced at this code a couple of years
> ago. However, I thought it was adding explicit message header data to do
> its correlation.
> > 4) Mapping to the correct Operation for the response - by correlating, we
> > have the OperationInfo and such that was used for the request so the
> > response can be properly unmarshalled and such based on that
> > OperationInfo.   Without the correlation, we'd have to do extra
> > processing to use the body contents to figure out the OperationInfo and
> > such.   The problem is that that wouldn't be reliable as you can have
> > multiple operations with the same return message (but different request
> > messages) and still be compliant.
> That's an interesting point you raise here. When a response gets
> redirected how *is* it supposed to be processed. My own code only
> provides limited input here since I only use FaultTo redirection for
> OneWay messages. But with a redirected request-response exchange the
> question arises as to what sort of processing the ReplyTo endpoint is
> supposed  to perform when and what sort of response handling the
> requester is supposed to  perform. Is the ReplyTo endpoint supposed to
> handle the incoming message as though it was a response to a 2 way
> exchange? Or is it meant to handle it as a self-contained incoming
> message and ignore the fact that it was dispatched in reply to a RPC
> style request.
> I had always assumed the latter. So, for example, if the response has an
> associated WSA action I assumed it would be directed to a operation
> implementation method on the ReplyTo endpoint bean which was identified
> by that action. Ditto  if there is a soap action. In the absence of an
> action I would have expected the usual rule to apply -- identify the
> type of the argument and direct to an operation using the type name as
> an identifier.
> I also assumed that the thread which made the original RPC style request
> would not be expecting to deserialise a reply because the ReplyTo was
> not null/anonymous/noreply.

Since this usecase really is way outside the JAX-WS spec things, I think we 
can kind of figure out for ourselves what makes sense from a CXF standpoint.   
You're description definitely seems fine by me.  :-)

Daniel Kulp

View raw message