> -----Original Message-----
> From: Dan Diephouse [mailto:[EMAIL PROTECTED]
> Sent: 04 January 2007 17:06
> To: [email protected]
> Subject: Re: Proposal for Decoupling and Issues with CXFServlet
>
> 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.
OK, I see the distinction, I should have read your previous mail more closely
before firing off a reply ...
But, I think ultimately it sorrta ends up as the same thing.
That is, it would be badness to make RM's usage of partial responses specific
to HTTP (by explicitly setting the response code to 202 from within the RM
code), because there may be other transports that require the partial response
semantics. So we'd effectively end up having tied our RM implementation to HTTP.
> 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.
Sure, we think of these as async transports, but we may still require partial
response type semantics, depending on the detail of how the response channel
works for each transport.
Put HTTP (or any other specific transport) out of your mind for a moment, and
lets consider the fundamental question as to we originally came to the
conclusion that partial responses are needed by RM.
Its basically to allow timely ACKs to be sent in two specific scenarios. Where
the client's source sequence has an anonymous acksTo (so that ACKs must be
piggy-backed on responses rather than being sent standalone), and either:
A) the client invokes a series of exclusively oneway operations, so that there
are no application-level responses ever sent back), hence no opportunity to
piggy-back ACKs
or:
B) the client invokes a series of non-interleaved twoway operations, but the
implementor up-calls are sufficiently long-lived so that a response will only
become available *after* the client's retransmission interval has expired, so
that the client has already resent the message before the server gets a chance
to acknowledge the first message instance.
Note that partial responses are only required when the acksTo is anonymous, in
the wider sense of "send the ACKs to the individual destinations specific to
each individual response message", not necessarily the narrow sense of "send
the ACKs as part of a synchronous response on the backchannel of the incoming
TCP connection".
Now for an asynch transport that uses the same *long-lived* destination to
receive *all* responses (and ACKs), and where that transport is continually
listening for incoming traffic on that destination regardless of whether
there's an outstanding reply expected, then the requirement for partial
responses shouldn't even arise (i.e. the acksTo should always be non-anonymous
in this case).
But, says you, shouldn't the above statement be true of all async transports?
Nope, unfortunately that's not the case.
Take for example the CXF JMS transport. For good or ill, the way this currently
works is that a *different* temporary queue is specified as the replyTo for
each request, and the client-side transport only expects to receive a *single*
incoming message on that destination (i.e. in JMS parlance, instead of
installing a MessageListener on the response Queue to allow for a series of
onMessage() notifications, it makes just one call to MessageConsumer.receive()
to accept a single response message).
For this style of JMS transport, we could envisage sending first a partial
response, recognizable in some way as such by the receiving JMSConduit so as to
cause it to make a second call to MessageConsumer.receive() in expectation of
the full response in the twoway case. For oneways, it would make just one
(instead of zero) calls to MessageConsumer.receive().
You get the idea I hope ... Even though this transport is async, it still uses
an anonymous style of response back-channel (in the wider sense as defined
above).
So why not just "fix" the JMS transport so that it works in a more naturally
async way? Well, that a whole other discussion, but my main point is that even
an async-style transport may require partial response semantics. So we should
not tie our usage of partial response to HTTP (by setting the 202 response code
from within the RM layer), as we can't be sure that the underlying transport is
actually HTTP.
> So I want to ask: do we have to have a dependency on the
> server side code in the client code?
Not sure what you mean by a dependency here. Do you mean that the client-side
transport is dependent on the server-side transport acting in a specific way?
> 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?
The client-side Conduit is only capable of correlating the response where
replyTo destination is anonymous (in the wider sense again).
So for example, for non-decoupled HTTP, the response is received back on the
same physical connection as the request was sent, so bada bing, correlation is
trivial.
Similarly in the CXF style of JMS, the response Queue is specific to the
request, so again correlation is obvious to the client-side transport.
However, when the response channel is truly decoupled (e.g. sent over a
separate server->client HTTP connection, or a static JMS response Destination),
then the transport is not in general capable of doing the correlation itself.
> Is there a reason why this has to happen
> there? Or why its at least better suited in the transport than out?
As explained above, the response correlation cannot be done by the transport in
certain cases. So at least in these cases, the correlation *must* be done
outside the transport (i.e. in the WS-A layer).
Cheers,
Eoghan
> - 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
>
