cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: [PROPOSAL] Client and Conduit changes
Date Tue, 20 Mar 2007 00:08:31 GMT
On 3/17/07, Glynn, Eoghan <eoghan.glynn@iona.com> wrote:
>
>
>
> My position is that the Conduit should continue to hold to the reference
> to, and manage the lifecycle of, the decoupled response endpoint (DRE).
>
> Without rehashing the entire thread, my reasons briefly are:
>
> 1. Separation of concerns
>
> The DRE is an aspect of the transport and thus should be created and
> referenced from within the realm of the transport.


Then why aren't we creating other decoupled endpoints from the transport
layer? This assumes a 1:1 association which isn't so.

On the other hand, the purpose of the Client is to set up interceptor chains
> and dispatch the invocation. Such invocations may NOT require a DRE, or even
> a Conduit for that matter. Thus I think it inappropriate for the Client to
> be concerned with the creation of the DRE, and would even go one step
> further and move the Conduit creation to the MessageSenderInterceptor, so
> that a Conduit comes into being only if it really is needed.


Then do you want to get rid of Exchange.getConduit/getDestination or
Message.getConduit/getDestination as well? Just because you want to not
require the conduit doesn't mean that there shouldn't be conduit/destination
properties on the Client. This is completely orthogonal to the issue.

2. Avoid forcing the usage of a Client instance
>
> In general, if A is to be responsible for maintaining a reference to B,
> then its reasonable to expect that the existence of a B implies the
> existence of an A. Otherwise, in some cases an instance of A will have be
> artificially created, solely to manage the reference to B.
>
> But if a DRE is in use, then the *only* other thing we're guaranteed also
> exists is the corresponding Conduit.
>
> IMO we should neither require the usage of a Client instance to mediate
> invocations, nor impose any undue burden on applications that choose to wire
> up the interceptor chains directly and initiate dispatch themselves.
>
> An example of an undue burden would be forcing such applications to either
> always create the DRE *programmatically* via
> DestinationFactory.getDestination(), or if they want the DRE to be
> specified declaratively, to manage this configuration themselves.


Undue burden? Where is the undue burden?

Your approach:

Conduit conduit = conduitInitiator.getConduit(Endpoint);
ConduitPolicy policy = conduit.getConduitPolicy();
policy.setDecoupledEndpoint (replyToEPR);
conduit.setMessageObserver(myObserver);

My approach:

Conduit conduit = conduitInitiator.getConduit(Endpoint);
DestinationFactory destination = destinationFactory.getDestination
(replyToEPR);
destination.setMessageObser(myObserver);
conduit.setMessageObserver(myObserver); // if you need to listen for back
channel messages

It is arguably the SAME amount of work. The benefit of the latter is its
consistent.

3. Suitability for JMS
>
> In order to setup a Destination, JMS may require more information than can
> be easily shoe-horned into an EPR. Stuff like a JNDI provider,
> ConnectionFactory username/password etc.
>
> Now I don't accept the JMS as odd-man-out argument, especially when most
> of the counter-examples wheeled out ( i.e. XMPP, TCP, FTP) do not
> currently even exist as CXF transports. I could just as easily make up a
> list of non-existent transports that suggests that the URI-friendliness of
> HTTP is the exceptional case, but obviously you'd argue my list was
> hypothetical and proved nothing. And you'd be right :)
>
> Neither does the "most people just use HTTP" line wash with me. One of the
> design centres of CXF is to be a multi-transport stack, and that in my book
> amounts to more than just paying lip-service to non-HTTP transports.


Even if there isn't enough information in the JMS EPR to completely set up a
JMS endpoint, it doesn't mean its completely useless. It can still be a nice
way to hang onto references of a JMS endpoint that I've set up earlier on.
For instance, a user could enter in the jms:// EPR in a configuration
screen. By calling DestinationFactory.getDestination(epr) it would then
retrieve a previously configured instance of the JMS destination.

Also I'd like to respond quickly to a couple of specific points that Dan
> makes in his proposal:
>
> "Right now if you want to create different endpoints for receiving
> ReplyTos and FaultTos you have configure the ReplyTos using the Conduit API
> and the FaultTos using the destination API. Creating those endpoints in
> different ways is bad IMO."
>
> So how would this be any different under your proposal? Is the implication
> that in addition to a Client.setAsynchronousEndpoint() API, you'd also add
> Client.setFaultToEndpoint() and Client.setAcksToEndpoint(), and similarly
> expose <faultToEndpoint> and <acksToEndpoint> elements in your proposed
> <client> bean?


If so, this would expose *way* too much of WS-A and WS-RM semantics directly
> in the Client, which should IMO be independent of such QoS concerns. The CXF
> WS-A and WS-RM layers were specifically designed to be pluggable, so that
> they could slotted into the runtime without impact on the core APIs. I would
> be strongly against a move that breaks this ... I mean, what next,
> Client.setSecurityPolicyToken()??


If on the other hand, if you're not suggesting polluting the Client with
> those aspects of WS-A & WS-RM, can you explain how your proposal provides a
> consistent mechanism for specifying the faultTo & acksTo vis-à-vis the
> replytTo?


No, I was more referring to scenarios where someone is not using the Client.
The one you seem to be so concerned about in #1.

Another point which I strongly disagree with:
>
> "If all Conduits share the same code for setting up decoupled
> destinations, that is a sign to me that we can take it out of the Conduit."
>
> I've never come across a design principle that suggests having common code
> in a common base class is a sign that such code should be moved elsewhere.
> In fact what purpose do common base classes serve, other than to factor out
> commonality from sub-classes?


Base classes would be another solution to that problem.  I wasn't trying to
say base classes are evil. I was trying to say that the concept of a
decoupled endpoint isn't critical to the concept of a Conduit, and so I
think it should be taken out. Sometimes you can simplify the classes and
then incorporate more advanced concepts into another class. For instance, in
Microsoft's WCF, you have the IDuplexChannel which extends the IInputChannel
and IOutputChannel.  I don't think that is so outrageous really...

- Dan

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

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