cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <>
Subject Re: Proposal for Decoupling and Issues with CXFServlet
Date Mon, 22 Jan 2007 16:40:34 GMT
On 1/19/07, Glynn, Eoghan <> 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 |

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