cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <>
Subject Re: [PROPOSAL] Client and Conduit changes
Date Wed, 28 Mar 2007 17:38:51 GMT
On 3/28/07, Glynn, Eoghan <> wrote:

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

Sure, but its hard for me to know what is motivating your proposal if you do
come up with some specific use cases. I'm glad to see that you daded a
couple below.

> 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

I have no idea what you're getting at here. Can you please give a use case?
That statement is kind of circular... of course if a conduit is required,
you won't be able to divert a message in a way that doesn't require a
conduit. But where are you diverting it? How do you want to divert? Why?

(b) divert the message to a different endpoint, that maybe necessitates
> a different Conduit instance to the one selected up front by the Client

This is where I was going with the Camel example... We could send a message
off to camel (or any other routing thingy - synapse or mule might be options
for people too). Or if we want to route inside the interceptor chain we can
select a new Conduit in any interceptor. Then the MessageSenderInterceptor
can use this new Conduit. If you're tyring to change the destination after
the messagesenderinterceptor - i.e. mid serialization, I don't think thats
very feasible for most bindings/messages.

Once again, what are your use cases here? Please supply some specific
scenarios which require the removal of a Conduit.

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

I was simply talking about how mediation would be possible with Camel as you
had stated that one of the requirements for mediation was the removal of the
Conduit from the Client class. The example was to show that removing the
Conduit is not necessariliy required.

> > Lets compare the two cases of setting up a decoupled endpoint
> > from an XML
> > configuration perspective.
> >
> > Case 1: now
> >
> >
> >     <http:conduit id="{
> >}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?

I see what your saying, but...

They can just put it in their application configuration. If they're already
working with CXF they probably have their own configuration which will drive
their application - whether its UI or database or Spring based.

Also, the number of people attempting to understand the transport API or
write transports will be much greater than those trying to write decoupled
applications without the Client. Sure, I have no statistics to back that up,
but I do have a fair amount of experience in the area. Most people won't
even setup a decoupled endpoint. And the majority of people who do use
decoupled endpoints will use the Client.

I would definitely wager a large sum of money that there are more people
trying to grok or write transports than those writing decoupled applications
without a Client. By an order of magnitude at least. So I have yet to see
why this argument should carry that much weight.

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

No, just the setAsyncrhronousDestination/setAsyncryhronousEndpoint in my
original proposal.

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

You're completely missing the point. The point is that the whole CONCEPT of
Conduits and Destinations are overly complex. To understand AbstractConduit
you still need to understand Conduit. So AbstractConduit doesn't really help
in that regard.

- Dan

Dan Diephouse
Envoi Solutions |

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