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 Thu, 22 Mar 2007 20:53:22 GMT
On 3/20/07, Glynn, Eoghan <eoghan.glynn@iona.com> wrote:
>
>
>
> > 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.
>
>
> So how would a user suppress the Client's creation of a Conduit if its
> only when the dispatch gets as far as some interceptor that the dispatch is
> diverted in such as a way as to not require a Conduit? Note the Conduit is
> created *up-front* by the Client, before InterceptorChain.doInterceptor()
> is called for the outward dispatch.


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.

> 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?
>
>
> The undue burden is NOT in driving the programmatic API. I agree the
> amount of work there is roughly the same.
>
> The problem is that there should be declarative mechanism as well as a
> programmatic API. The application doesn't necessarily want to hard-code the
> DRE address.
>
> This declarative mechanism is currently provided by the Conduit
> configuration. Any application can take advantage of this, regardless of how
> the invocation is dispatched (whether via the Client, Dispatch, direct
> InterceptorChain.doIntercept(), whatever) because if it's a remote
> invocation, there's *always* going to be a Conduit instance involved.
>
> You're proposing moving this config to hang off the Client instead. As a
> result the application would be forced to either (a) use the Client in order
> to declaratively specify the DRE, or (b) invent and manage its own config
> mechanism. Makes sense, or?


Well first, nearly everyone will be using the Client.

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.

> 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.
>
>
> So regardless of whether:
>
> (a) we hang the DRE config off the Conduit (as is currently the case) or
> the Client (as you propose),
>
> or
>
> (b) the application chooses to use the Client or some other mechanism to
> mediate the invocation
>
> Would you agree that if the application wants to set the faultTo or acksTo
> to some other address than the replyTo, then they would have to do so in a
> way that's not consistent with whatever way the replyTo is set?
>
> If so, I think the setting of the faultTo/acksTo is neutral to the
> argument, and neither bolsters your case nor mine.
>

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.

The benefit is that it does not introduce a new ClientPolicy class and does
not the Conduit contract.

- Dan

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

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