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 Mon, 08 Jan 2007 14:40:37 GMT
On 1/8/07, Glynn, Eoghan <eoghan.glynn@iona.com> wrote:

> > First, if there is a transport which requires an anonymous
> > partial response, we could still support that. In my mind
> > this is analagous to the SOAP case.
> > SOAP has an HTTP binding and HTTP specific semantics.We have
> > some HTTP specific code in the SOAP module to support things
> > like response codes. I wouldn't be any more keen on adding
> > SOAP specifics into the HTTP transport than I am to add
> > WS-A/RM semantics.
>
> But is polluting RM with HTTP-specifics any better that polluting HTTP
> with RM concepts?
>

IMO, yes :-)

> I'm not sure that the HTTP-specifics in the SOAP binding is a good
> exemplar, as IIRC you yourself argued strongly against burning
> special-case handling of HTTP GET into the SOAP interceptors (i.e the
> isGET() logic).

The problem with the isGET isn't that it forced SOAP to deal with HTTP
issues, its that it requires every interceptor to look and check if there is
an HTTP GET request. This puts a burden on developers and makes the
interceptor logic more complex.

>
> Further, explicitly setting the Message.RESPONSE_CODE to 500 in the
> Soap1{1|2}OutFaultInterceptor is to my mind unnecessary. Surely the
> HTTPDestination could just check whether the outgoing message is a fault
> (i.e. message == message.getExchage().getOutFaultMessage()) and just set
> the response code itself to 500 in that case?
>

I'm not a fan of checking/setting response codes any more than necessary in
the HTTP layer. The logic for setting the fault code isn't quite so simple.
There are non-500 fault codes as well:
http://www.w3.org/TR/soap12-part2/#http-respbindprocess And once you start
to introduce this logic it starts to interfere with the HTTP/RESTful
bindings.

> Also, while the partial response idea was motivated by some RM
> use-cases, exposing this concept to the HTTP level isn't IMO quite the
> same thing as putting RM semantics directly into the HTTP transport,
> (i.e. HTTP still knows nothing about the wsrm namespace, types,
> operations etc).

I see what you're saying, but still if there was no RM, I don't think we'd
be checking for a 202 response code in our HTTP Conduit or setting one on
the JettyHTTPDestination. If it is some general feature, who's to say that
it wouldn't be a 200 response code and there wouldn't be other HTTP headers
that we wouldn't need to add.

> Are you objecting just to the HTTPConduit having a reference to the
> ServerEngine, or to the presence of a ServerEngine instance in the
> client-side runtime?
>
> If the latter, how would the client-side arrange to receive decoupled
> responses without some sort of HTTP listener being launched in-process?
> Shouldn't this client-side HTTP listener re-use the server-side logic?
> Or are you thinking that the client-side should only embed a minimal
> HTTP listener (like nanoHTTPD)?

Sorry if I wasn't clear. I'm objecting to maintaining the server side
connection in the client code. And vis a versa. Instead of registering the
Client MessageObserver like this:

Destination d = conduit.getBackChannel(); // this sets up a back channel via
the JettyHTTPServerEngine.getForPort(...) method
d.setMessageObserver(client);

Just doing this instead:

Destination d = destinationFactory.getDestination(replyToEPR);
d.setMessageObserver(client);

This would mean that any HTTP Destination could be used with any HTTP
Conduit. It also simplifies the code as the http conduits/destinations don't
need to worry about each other. Is there a reason this wouldn't be possible?

>
> > And let me try to give a fair recap for why I understand you
> > think things are best this way:
> > A) Partial responses are best dealt with in the transport
> > layer because they have transport specific logic. Namely the
> > HTTP response code needs to be set.
> > B) You can't achieve (A) without encapsulating the decoupling
> > in the transport interfaces (via the getBackChannel methods)
> > C) Doing things in this way makes it easier to enforce security policy
> >
> > Please let me know if I've misrepresented your position. I
> > have absolutely no desire to do so.
>
> Yes, this pretty much sums up my core arguments.
>

Yay, we're getting somewhere! :-)

> > I completely follow your logic in B, however I think I
> > disagree with A.
> >
> >    -  As I mentioned above, RM has HTTP specific semantics and those
> >    should be contained inside the RM module. This is the same
> > policy we have
> >    with things like the SOAP binding. This does not mean it
> > has to be hardcoded
> >    into the partial response logic. The RM module could
> > discover different
> >    transport specific logic. i.e. we could have an
> > RMTransport interface
> >    which has something like a "void
> > setupPartialResponse(Message)" method.
>
> Would this RMTransport be like a sub-interface of Destination, that the
> RM layer would down-cast to as required?
>
> If so, any wouldn't transport that we're likely to want to run RM over
> would have to implement RMTransport as opposed to Destination, so that
> we end up in effect with as much (or as little, depending on your point
> of view) RM pollution of the transport as before?
>

I think it could be done one of two ways. The first is as you mention. I
would imagine in this case the RMTransport interface would become part of
the API module. The second would be to make it its own independent interface
which is discovered like the transports currently are. The first is probably
easier.

I don't think it would be equivalent to the current code. It would be in one
well contained method, and isn't run unless we are doing a partial response
in RM. It would also not need to be implemented unless a transport needed to
support customizing a partial response - i.e. an HTTP 202 accepted response
status. JMS wouldn't need to implement anything. Completely optional. Also
my motivation for doing so would be not only to remove the partial response
handling, but also the decoupling support built into the HTTP transport as
well (for reasons I won't repeat...)

> > Furthermore, I'm really not a fan of B, which makes me less
> > inclined to like A.  Why?
> >
> >    - Encapsulating the decoupling logic complicates transports: For
> >    instance, methods we've added for encapsulation of the
> > decoupling include:
> >    Conduit.getBackChannel(), Destination.getBackChannel(),
> >    ConduitInitiator.getConduit(EndpointInfo, EndpointReferenceTarget).
>
> Well, I guess we could simplify things a bit by factoring out the logic
> related to partial response into a separate sub-interface of Destination
> (assuming that's what you intended with the suggested RMTransport).
>

I'm suggesting we
- remove the Conduit.getBackChannel()
- make Destination.getBackChannel() have no arguments and only return the
anonymous back channel
- remove the Conduit.getConduit(EndpointInfo, EndpointReferenceTarget)
method

This would move the decoupling support out of the HTTP layer and into the
WS-A layer. That is the WS-A layer would be responsible for creating a non
anonymous ReplyTo conduit, setting up a decoupled Client destination, etc.

> I'm not sure I understand how you'd intend to get away without worrying
> about a decoupled Destination on the client-side ... how would the
> client be capable of receiving decoupled responses?
>

I'm not trying to get rid of the decoupled Destination. Simply trying to
move the decoupling logic elsewhere. Does the above help explain what I mean
better?

- Dan


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

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