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: <7b774c950703280739m18b7821ckef3080e53c789896@mail.gmail.com>
Date: Wed, 28 Mar 2007 09:39:51 -0500
From: "Dan Diephouse" <dan@envoisolutions.com>
To: cxf-dev@incubator.apache.org
Subject: Re: [PROPOSAL] Client and Conduit changes
In-Reply-To: <FA1787F64A095C4090E76EBAF8B183E071FCE1@emea-ems1.IONAGLOBAL.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_23849_18443589.1175092791413"
References: <7b774c950703221353u5eb42a69ia518c73ec0556ae@mail.gmail.com>
	 <FA1787F64A095C4090E76EBAF8B183E071FCE1@emea-ems1.IONAGLOBAL.com>

------=_Part_23849_18443589.1175092791413
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 3/28/07, Glynn, Eoghan <eoghan.glynn@iona.com> wrote:
>
>
> > I see your point - I suppose there could be a flag. But look
> > at it the other way around too. If this type of thing is
> > adopted, that doesn't mean that we can do
> > client.set(Destination.class, myDestination).
> >
> > At the moment I'm very strongly against this idea and if
> > you're serious about getting it in, I would suggest starting
> > another thread outlining your use case so we can discuss
> > possible solutions.
>
>
> Can you outline why you're very strongly against the idea of deferring the
> creation of a Conduit until we're sure its actually needed?


I see it as unnecessary. We've defined an abstraction with boundaries of
Conduits and Destinations. I don't really see any reason to go changing
this.

For instance, I've been talking to James Strachan about using Camel a bit.
Camel can do a bit of routing of CXF messages. On the Client side of things,
we should be able to send a message in and then get the response some time
later from Camel (if there is a response). The idea is that it can work on
whatever the representation - pojos, xml, bytes, etc. The boundary into this
system from the client perspective would still be a transport. Camel can
just add a MessageObserver on a local:// destination. How the message comes
into Camel then becomes a matter of the Binding.  For the POJO case, I'd
like to create an ObjectBinding which doesn't do any serialization. It'd
also be nice to have a flag so the SOAP binding produce a Source object
ultimately.


> >
> > Second, no one will be forced to invent new config
> > mechanisms. They can use the existing configuration
> > mechanisms. i.e. they can declare a <destination> and a
> > <conduit> in their XML if thats the route they want to go.
> > Then when they grab the Destination/Conduit those will be
> > configured according to their configuration.
>
>
> It's the grabbing from the configuration that I'm concerned about.
>
> What exactly is entailed by the app grabbing from config, plus defining
> the config schema upfront?
>
> Why should application code (that doesn't use a Client) have to concerned
> at all with managing config?
>

It doesn't have to be... See below.

Why not just allow the decoupled Destination to be picked up via a config
> mechanism that's provided by the CXF framework?
>
> What is guaranteed to exist for a decoupled MEP? A Conduit instance.
>
> What is not guaranteed to exist for a decoupled MEP? A Client instance.
>
> So it seems to that simple logic dictates that the DRE config should be
> associated with the one thing we *know* will exist, i.e. the Conduit.


Lets compare the two cases of setting up a decoupled endpoint from an XML
configuration perspective.

Case 1: now


    <http:conduit id="{
http://cxf.apache.org/greeter_control}GreeterPort.http-conduit">
      <http:client DecoupledEndpoint="
http://localhost:9995/decoupled_endpoint"/>
    </http:conduit>

Case 2:My Proposal
2a) No Client: No XML configuration is needed, unless you're using JMS. In
which case you add a <jms:destination> to your XML config
2b) My proposed client config:

<jaxws:client id="....">
  <jaxws:destination><http:destination address="
http://localhost:9995/decoupled_endpoint"/></jaxws:destination>
</jaxws:client>


> >
> >
> > I'm saying that if someone is just using the transport layer (i.e. no
> > client) and using multiple decoupled endpoints, its more
> > consistent to just use the Destination* APIs. And its the
> > same amount of work.
>
>
> By the "Destination* APIs", do you mean DestinationFactory.getDestination
> ()?
>
> Well, that is exactly what would be used to create a different acksTo or
> faultTo in the current scenario.
>
> And it sounds to me like it would also be required in your proposal too
> (assuming you're not proposing new Client.setAcksToEndpoint() etc. APIs)
>
> So I really don't seen what your consistency argument is based on (?)
>
> AFAICS in *both* your proposal *and* in the current model, a *different*
> mechanism must used to set up the replyTo versus the acksTo/faultTo (if
> these are to be different).


Correct me please here if I'm wrong.


When you use the Client, yes, the Client adds some convenience wrapper
methods. When you don't use the Client, you always use the destination apis
to set up the decoupled endpoint.


> Is introducing an abstract ConduitPolicy really that big an issue?


YES! We've already created very complex APIs for transports. Its time to
simplify.

I would think it much easier for the CXF framework to support a small
> extension to its current config schemas, than for a (Client-less)
> application to have to manage the config of the DRE itself.


You have yet to show where the burden is for a Client-less application which
manages a DRE itself. I don't see how its any more complex than what is
currently there.

- Dan


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

------=_Part_23849_18443589.1175092791413--