cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: Proposal for Decoupling and Issues with CXFServlet
Date Thu, 04 Jan 2007 19:58:13 GMT
Hi Ted,
We haven't tied WS-RM to HTTP. What we're taling about is an HTTP specific
non standard "feature" in RM which involves piggybacking partial responses.
Let me explain. Computers and A and B are communicating. Messages from A->B
go to http://a.com/ and messages from B->A go to http://b.com. This is the
decoupled HTTP scenario where we don't use a synchronous HTTP reply, but
instead follow the instructions of the WS-A ReplyTo header (which points to
http://b.com or http://a.com).  In RM we can send a message from A to B and
then "piggyback" a response on the synchronous HTTP response which includes
a WS-RM SequenceAcknowledgement. Without RM this would just be an empty
response like any other one way message.

As you can imagine, implementing this is a pain, because one ways are in
fact supposed to be one way and not include a response!

The question to me is whether or not we want to add transparent type of
support for decoupled channels in the transport layer. So I have this code:

Conduit c =  ... // get a conduit and send a message
c.send(message);

// Find a decoupled destination which receives responses
Destination destination = c.getBackChannel();
// Set our MessageObserver which listens for messages
destination.setMessageObserver(myMessageObserver);

Currently the HTTPConduit knows about the decoupled destination which we
want to receive messages on.

So what I'm arguing is that we should remove the decoupled knowledge out of
the HTTP transport and let the WS-A/RM layer figure it out for themselves.

- Dan

On 1/4/07, Ted Neward <ted@tedneward.com> wrote:
>
> Recognizing that I'm not a "dev", per se, (and thus my input may be
> rightly
> ignored) I still would like to weigh in with a +1: WS-* services are
> definitely not tied to any particular channel--such was a major reason for
> WS-Addressing's Action, so as to do away with the SOAP Action HTTP header
> from SOAP 1.1 when they rewrote the standard for SOAP 1.2. This is also
> one
> of the reasons the SOAP-over-UDP spec was written, to demonstrate bindings
> to something other than HTTP.
>
> Tying WS-(anything) to a particular transport is a HUGE mistake, IMHO.
>
> <rant xmlns="http://www.tedneward.com/pragmatic-xml-services">
> This is partly why I'd suggested that CXF needs more in the way of
> multi-transport samples--these issues become much clearer when you start
> thinking about WS-RM over SMTP or (particularly) UDP. If you tie WS-RM in
> to
> HTTP, then not only do you have to rewrite that code if/when somebody
> (like
> me) wants to use another transport (TCP, UDP, FTP, SMTP/POP3, XMPP, JMS
> all
> come to mind as viable options), but you further the misnomer of "Web"
> services (meaning XML is only good for shipment over HTTP) as opposed to
> "XML" services (meaning transport is largely an implementation detail).
> HTTP
> is a good protocol, but hardly the be-all/end-all transport that solves
> all
> problems.
> </rant>
>
> Ted Neward
> Java, .NET, XML Services
> Consulting, Teaching, Speaking, Writing
> http://www.tedneward.com
>
> > -----Original Message-----
> > From: Glynn, Eoghan [mailto:eoghan.glynn@iona.com]
> > Sent: Thursday, January 04, 2007 2:32 AM
> > To: cxf-dev@incubator.apache.org
> > Cc: Fang, Yue (Freeman)
> > Subject: RE: Proposal for Decoupling and Issues with CXFServlet
> >
> >
> > > > 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
> >
> >
> > --
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.5.432 / Virus Database: 268.16.4/615 - Release Date: 1/3/2007
> > 1:34 PM
> >
>
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.16.5/616 - Release Date: 1/4/2007
> 1:34 PM
>
>
>
>


-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message