Re: WS-MakeConnection operation structuring

[Dennis Sosnoski <dm...@sosnoski.com>]

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