cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <>
Subject RE: Proposal for Decoupling and Issues with CXFServlet
Date Mon, 15 Jan 2007 17:04:15 GMT
> > 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);

Well that's not the way things work currently on the client-side.

We do not set a separate MessageObserver on the back-channel destination, whether decoupled
or not.

Instead, the MessageObserver already set for the Conduit is implicitly also used for the back-channel.
The ClientImpl just provides a *single* MessageObserver, and the response messages are delivered
to this regardless of whether they arrived on the back-channel of the outgoing client->server
connection or on a separate server->client connection.

The idea is that only the transport needs to be aware that it's configured in decoupled mode.

The WS-A layer just asks the transport for a back-channel URI. If something non-null is returned,
this is encoded as the wsa:replyTo in the outgoing message. Otherwise the fallback is the
anonymous URI.

I think we've a different understanding of what the primary task of the WS-A layer is, and
where the division of responsibilities vis-à-vis the transport lies. 

My understanding is that job of the WS-A layer is to gather together the information relating
to addressing, and to encode this in the out-going message. Some of this information is in
the domain of the transport, such as the backchannel address, and the transport should drive
the creation of this. WS-A in my view simply provides a standard transport-independent way
of encoding transport-specific information. In my view, the WS-A layer is is the aggregator,
not the instigator.

You on the other hand, I think, see the WS-A layer in the driving seat, causing the transport
to create a particular back-channel. Is that a fair characterization?

> 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?

Not impossible, just not the best way of doing it IMO.

For a start it would probably involve the WS-A layer being configured with the replyTo EPR
(instead of the transport, as is currently the case).

In such a scenario, how would WS-A validate that the replyTo EPR even makes any sense vis-à-vis
the outgoing transport? Supposing for example WS-A is configured with a JMS replyTo EPR, when
the target endpoint is HTTP-based. From the physical contract (e.g. the target portType in
the WSDL), WS-A would have no way of knowing that the server-side would even be capable of
responing using such a replyTo EPR.

> > >    -  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...)

Yep, there's an argument alright for allowing a transport opt out of the whole partial response
mechanism if its incapable of providing those semantics.

But this could be achieved more simply via some distinguished return from Destination.backChannel(),
e.g. just return null if the partialResponse parameter is non-null. As things currently stand,
WS-A would be tolerant to this and will simply avoid sending the partial response in this
> > > 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 disagree with this division of responsibility between WS-A and transport. See above for

> > 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?

Yep, I see where you're going, but don't agree :)


View raw message