cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
Subject RE: [PROPOSAL] Client and Conduit changes
Date Wed, 28 Mar 2007 15:54:43 GMT


> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com] 
> Sent: 28 March 2007 15:40
> To: cxf-dev@incubator.apache.org
> Subject: Re: [PROPOSAL] Client and Conduit changes
> 
> 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. 


What do you mean by an "abstraction with boundaries of Conduits and
Destinations"?

Are the boundaries of which you speak:

(a) the Conduit and Destination APIs
(b) the lifecycle of, and referers to, the Conduit and Destination
instances
(c) something else?

As far as I can see, we're *both* proposing changes that would fall
mainly under category (b).

Currently the Conduit lifecycle is managed by the Client. And the DRE
lifecycle is managed by the Conduit.

You want to change things so that DRE is also managed by the Client.
Correct?

I want to change things so that neither is managed by the Client.

So I think it would be fair to say that we *both* see a reason to go
changing things. Just different things. Or?


> I don't really see any reason to go changing this.


See above.

And here's a specific reason ...

Having the Client create a Conduit before its actually definite that a
Conduit is required makes it awkward for an interceptor in the outbound
chain to:

(a) divert the message in such a way that doesn't require a Conduit at
all
(b) divert the message to a different endpoint, that maybe necessitates
a different Conduit instance to the one selected up front by the Client

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


Sorry I don't really see the relevance of this to the current
discussion.

Maybe I'm just being slow today :)

Can you explain why the Camel requirement necessitates the type of
changes you're proposing?

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


No XML configuration is needed? So you're proposing a (client-less,
HTTP-based) application must hard-code the DRE address?

What happens if I reorganize by domains? Or my DHCP lease expires? Or
I'm assigned a new port range? Or I discover a port clash with some
other piece of software? Or my firewall config is changed? Or the NATS
setup is changed? Or I want to provision the client app to 100s or 1000s
of different hosts without recompiling for each? Or the client app is
migrated to a new host? Or the server app is migrated off-host so that a
localhost-based DRE no longer works?


> 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 get it that the Client config is of comparable complexity the Conduit
config.

Now, just for a second, imagine the application doesn't have a Client
instance. But the application cannot hard-code the DRE (see above for a
selection of reasons why this might be so). 

Where does the config come from in that case?


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


OK, can we be 100% clear here. What exactly are these convenience
wrapper methods?

Are you proposing new APIs on Client such as setFaultToEndpoint() and
setAcksTo()?


> > Is introducing an abstract ConduitPolicy really that big an issue?
> 
> 
> YES! We've already created very complex APIs for transports. 
> Its time to simplify.


But the complexity you take away with one hand, you add back with the
other ... i.e. you're proposing adding a bunch of complexity to the
Client.

Now I'd anticipate your counter-argument as something like ... yes but
we want developers to write their own transports, not their own clients.
Fair enough, but I'm saying that transport-writers need not be concerned
with handling the DRE logic if its factored out to the AbstractConduit.

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


Consider a client-less application that can't hard-code the DRE, as
described above.

Surely it is more complex for such an application to pull in a
configured DRE, that for the Conduit to handle this on its behalf?

/Eoghan




Mime
View raw message