cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Dinn <ad...@redhat.com>
Subject Re: WS-Addressing asynch MEP, CXF-2167 and WSTF tests
Date Wed, 29 Sep 2010 15:51:04 GMT
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.

> 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.

> 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.

> Hope that helps a bit.

Yes, thank you very much for your help.

regards,


Andrew Dinn
-----------

Mime
View raw message