Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <7b774c950703191708t7f79b890j64f985b401c609c1@mail.gmail.com>
Date: Mon, 19 Mar 2007 20:08:31 -0400
From: "Dan Diephouse" <dan@envoisolutions.com>
To: cxf-dev@incubator.apache.org
Subject: Re: [PROPOSAL] Client and Conduit changes
In-Reply-To: <FA1787F64A095C4090E76EBAF8B183E071FCBB@emea-ems1.IONAGLOBAL.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_113373_32064959.1174349311103"
References: <7b774c950703161519s51ff4744p3ee53ac638dd13bc@mail.gmail.com>
	 <FA1787F64A095C4090E76EBAF8B183E071FCBB@emea-ems1.IONAGLOBAL.com>

------=_Part_113373_32064959.1174349311103
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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 chain=
s
> and dispatch the invocation. Such invocations may NOT require a DRE, or e=
ven
> a Conduit for that matter. Thus I think it inappropriate for the Client t=
o
> 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/destinatio=
n
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 w=
ire
> up the interceptor chains directly and initiate dispatch themselves.
>
> An example of an undue burden would be forcing such applications to eithe=
r
> 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 =3D conduitInitiator.getConduit(Endpoint);
ConduitPolicy policy =3D conduit.getConduitPolicy();
policy.setDecoupledEndpoint (replyToEPR);
conduit.setMessageObserver(myObserver);

My approach:

Conduit conduit =3D conduitInitiator.getConduit(Endpoint);
DestinationFactory destination =3D 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 ca=
n
> 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 o=
f
> 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 th=
e
> design centres of CXF is to be a multi-transport stack, and that in my bo=
ok
> 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 nic=
e
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 A=
PI
> 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 implicatio=
n
> that in addition to a Client.setAsynchronousEndpoint() API, you'd also ad=
d
> 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 directl=
y
> 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 wo=
uld
> 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-=E0-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 cod=
e
> 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 o=
ut
> 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, i=
n
Microsoft's WCF, you have the IDuplexChannel which extends the IInputChanne=
l
and IOutputChannel.  I don't think that is so outrageous really...

- Dan

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

------=_Part_113373_32064959.1174349311103--