On 11/19/2011 10:55 AM, Daniel Kulp wrote: > ... > How about something along the lines of: create some sort of response message > thing in the ServiceModel to make sure it's not treated as a one-way. Then > likely add an interceptor on the out chain (at the very beginning) that would > grab the content that should be returned and the associated > BindingOperationInfo and such from the original service and reset the values > on the Exchange to those and such. > > Actually, the make connection stuff, when ready, could just create the > MessageContentsList and such like normal, set the binding and service stuff > on > the exchange, and let the normal OutgoingChainInterceptor handle the entire > setup of everything. I think. > > That all said, I don't really know enough about the MakeConnection stuff to > really know what it's trying to do.
I've tried looking into the approach you suggested, but I'm having a hard time getting anywhere. Here's a quick overview of WS-MC to clarify the concerns. Mostly what WS-MakeConnection does is allow you to use asynchronous responses without exposing a client endpoint. It does this by having the client supply the server with a unique anonymous endpoint identifier (of the form http://docs.oasis-open.org/ws-rx/wsmc/200702/anonymous?id={unique-String}) for the ReplyTo on the request, then poll the server for responses using the MakeConnection operation. This MakeConnection looks like a normal one-way SOAP operation, but the back channel from the request will be used for the first message waiting for that client, if any (as identified by the unique endpoint identifier). WS-MakeConnection is composable with WS-RM, WS-Security/WS-SecureConversation, or both. Although the common use case is as described above, where it is used to handle asynchronous responses, it can also be used for other cases (at least in theory) - for instance, as the endpoint for a pub/sub subscriber. On the management of messages awaiting delivery, the specification notes that "these messages form a class of asynchronous messages that is not dissimilar from “ordinary” asynchronous messages that are waiting for the establishment of a connection to their destination Endpoints." It looks like OutgoingChainInterceptor is what sets up the conduit for an asynchronous message in CXF, so it seems reasonable to implement the WS-MC wait queue at that same point (with an interceptor just prior to OutgoingChainInterceptor, I'd guess). This interceptor would suspend the processing of the message after invocation of the service, only resuming the processing when a MakeConnection request has established a back channel connection for the response message. This would be prior to WS-Security and WS-RM message mangling, so when the processing is resumed these other technologies should just do their stuff as normal. Does that sound about right? On the client side, this should also use the same sort of handling as an asynchronous response. The difference is just that polling with WS-MC will be used rather than a separate listener. - Dennis
