Please Eoghan, just listen to me for a moment. Of course I know that RM is
protocol independent. I was referring to partial responses, not RM itself.
Has anyone ever implemented partial response piggybacking on a transport
other than HTTP? Yes, RM can happen over SMTP, FTP, TCP, XMPP, etc, but
those are all really asynchronous transports.
Look - if there's a good reason things are this way, thats fine. Just please
help me understand. Maybe I started off the discussion a long while a bit
too naive, and I'm still not an RM expert, but I would like to have a real
discussion and carry it to its conclusion. This conclusion can be its a lot
easier to do decoupled partial responses the current way or it has to be
this way, but I want to understand why first.
So I want to ask: do we have to have a dependency on the server side code in
the client code? The main reason we're doing this it seems is that
HTTPConduit.getBackChannel() looks to autocorrelate the decoupled
destination. This is what I'm arguing that we take out of the transport
layer though. Once the Destination receives a message, it should be capable
of correlating the reply itself, no? Is there a reason why this has to
happen there? Or why its at least better suited in the transport than out?
- Dan
On 1/4/07, Glynn, Eoghan <[EMAIL PROTECTED]> wrote:
> > Remember that the creation/sending of the partial response and the
> > rebase on the decoupled response endpoint is already driven from
> > within the WS-A layer. No matter how we slice the dice the
> API used to
> > achieve this, we still need to interact with the transport,
> either by
> > necessity (e.g. as only the transport knows that the
> partial response
> > should have a "202 Accepted" status in the HTTP case), or for
> > convenience (e.g. as the transport knows what
> ConduitInitiator to use
> > to create the decoupled backchannel conduit, whereas WS-A
> would need
> > to do some figuring to relate a HTTP Destination to a HTTP
> ConduitInitiator).
>
>
> So your concern is putting the HTTP 202 accepted on the
> partial response?
> Other than that, the code in JettyHTTPDestination is a pretty
> simple if
> statement:
>
> if (replyToEPR == null) {
> return httpBackChannel;
> else {
> if (partialResponse != null) return httpBackChannel;
> else return newConduit(replyToEPR);
> }
>
> Seeing that the HTTP partial response stuff is an RM
> "feature" anyway which is *specific* to HTTP, whats the harm
> in putting the message.put(RESPONSE_CODE,
> HTTP_ACCEPTED) in RM code? We've already coded in a HTTP
> specific feature into RM (partial responses), so we might as
> well finish it off and put in the HTTP_ACCEPTED code there too IMO.
No, No, and thrice No!
First, WS-RM is *not* specific to HTTP.
In theory it could run over many other transports, e.g. SMTP, or FTP, or
some simple TCP-based protocol we cook up ourselves (à la the SonicMQ
"tcp://localhost:2506" approach).
At least that was the intention of the spec writers ... to quote from the
WS-RM spec abstract: "The protocol is described in this specification in a
**transport-independent** manner allowing it to be implemented using
different network technologies."
So our RM implementation should not be explicitly tied to HTTP by setting
the response code directly to 202. In any transport where the synchronous
back-channel worked differently, this would obviously be inappropriate.
Hence my argument that this detail is best kept encapsulated within the
transport.
Even if in practice HTTP is likely to be the only the transport that WS-RM
is deployed over, it would be just silly to burn a restriction to HTTP right
into the WS-RM code.
Second, the concept of a partial response is not necessarily specific to
HTTP ... it could be modeled in any transport with a synchronous
back-channel.
Finally, your pseudo-code summary of the
JettyHTTPDestination.getBackChannel() logic glosses over an important
point from my previous mail ... creating the decoupled back-channel is not
done via:
return new Conduit(replyToEPR);
rather its more like:
return myHTTPConduitInitiator.getConduit(endpointInfo, replyToEPR);
It trivial for the JettyHTTPDestination to have a reference to the
appropriate ConduitInitiator in order to create this Conduit. Not so for the
WS-A or WS-RM layers.
/Eoghan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
