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