> 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:[EMAIL PROTECTED] > Sent: Thursday, January 04, 2007 11:58 AM > To: [email protected] > 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > > > Sent: Thursday, January 04, 2007 2:32 AM > > > To: [email protected] > > > 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
