cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Neward" <...@tedneward.com>
Subject RE: Proposal for Decoupling and Issues with CXFServlet
Date Fri, 05 Jan 2007 22:18:43 GMT
> 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.
> 
Right; with you so far.

> 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!
>
Yep, and in fact one of the major reasons I cite to people why HTTP isn't
the end-all of protocols. (Offline support is another.)

> 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.
>
OK, on that, I can't claim to have any knowledge or ability to offer advice.
(Well, I could, but I'd be speaking blindly and probably not add much.) I
just wanted to throw my $.02 in because it sounded suspiciously like the
"why should we decouple from HTTP debate" that's a sore subject for me.
Thanks for gently pointing out the real issue at stake here. :-)

For what it's worth, my (completely uneducated) opinion states that parts
that shouldn't know about a concern really shouldn't know about it, so on
the surface of things I would tend to agree with you that the HTTP transport
shouldn't know about the redirect. But I also don't want to see CXF take
huge perf hits on the altar of aesthetics, so...

Ted Neward
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.tedneward.com
 

> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: Thursday, January 04, 2007 11:58 AM
> To: cxf-dev@incubator.apache.org
> Subject: Re: Proposal for Decoupling and Issues with CXFServlet
> 
> 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
> 
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.16.5/616 - Release Date: 1/4/2007
> 1:34 PM
> 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.16.6/617 - Release Date: 1/5/2007
11:11 AM
 


Mime
View raw message