On 1/19/07, Glynn, Eoghan <[EMAIL PROTECTED]> wrote:
Currently we always send back a partial response when there's a decoupled wsa:ReplyTo in the incoming request. However, I was thinking of changing this logic so that a partial response body is only sent if there are non-WS-A headers contributed by some other interceptor in the outgoing chain, as a body containing only WS-A headers doesn't serve any useful purpose. In those cases, we'd send back a "empty partial response", i.e. a 202 without any entity body in the HTTP case.
+1 to sending a 202 back with the empty message in the decoupled case.
The only substantive actions not undertaken by WS-A are: 1. Setting the response code to 202 2. Getting the HTTPConduit from the HTTP ConduitInitiator for the outgoing full response And I'm blue in the face explaining my position that these two steps are best done by the HTTP layer.
And I still don't think its justified. See below.
Before the REST support was added, WSDL query was probably > the only use > > of GET in the code. But I don't recall anyone suggesting that GETs > > were WSDL-specific. > > > > The difference is ?wsdl doesn't affect our APIs at all. No, you're missing the point. GET is a feature of HTTP. Previously, we used it only to retrieve WSDL. So what though, that didn't make GET specific to WSDL. Similarly 202 is a feature of HTTP. We only use it to make WS-RM work, but again that doesn't make 202 specific to WS-RM.
The "affect our APIs" difference is irrelevant ... the lack of
API-impact arises from a questionable implementation decision to stick the ?wsdl handling logic right in the HTTP Destination code, and then duplicate it across our multiple variants of this. In fact, this is due to factored out to a separate WSDLQueryHandler API or some-such to avoid this duplication.
Personally I would love ?wsdl to be removed from the transport layer. I have already implemented a static resource server for a sample application that I did (served out HTML with javascript), so it is easy enough to serve out WSDL without putting it in the transport layer. Sure, 202 is a feature of HTTP, BUT its usage in the transport currently is specific to particular scenarios that arise when using WS-Addressing and RM. Or in other words, if there wasn't a wsa:ReplyTo that we had to worry about this wouldn't be there. And this has a cascade of effects, namely it introduces handling of decoupled endpoints into the transport layer 1. Introduces Destination.getBackChannel(inMessage, partial, EPR) which has a coupling to the client side transport and requires the transport to be aware of if its operating in decoupled/coupled mode 2. Introduces Conduit.getBackChannel() which has a coupling to the server side transport and again requires the transport to be aware of if its operating in decoupled/coupled mode 3. Introduces ConduitManager.getConduit(EndpointInfo, EPR target) so that the client Conduit can have a reference to the server We've been through the arguments and the only reason we've come up with for introducing these changes is so that we can set the response code in the transport for the decoupled case. But I really don't understand how you think that simplifies things. Its completely unnecessary and makes it harder to write transports. The same thing can be accomplished by 1. Either creating a PartialResponseSupport interface for the transport or set the 202 in the WS-A layer 2. Letting WS-A manage the backchannel
> That's bad. > > > I'm OK with possibly adding a couple methods to help make the RM > > > capabilities easier, but burning the logic into the transports is > > > bad. > > > Making the > > > transports very complex to write is also bad. > > > > Again frankly I don't see the Destination.getBackChannel() > semantics > > as being so difficult to understand. > > > > And certainly IMO this API doesn't make transports very complex to > > write. > > > I've spoken to several people who have worked on writing > transports and they (and myself) think otherwise. Well I ain't a lawyer :), but hearsay proves nothing ... so if these transport writers want to contribute to the debate, let them speak up for themselves and demonstrate their locus standi.
Not all of them are subscribed to this list. Although some of them are and they should speak up. - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
