Dan,
Sorry for the delay in responding to this, but I didn't want to just re-hash my position yet again. Anyway, some further comments inline ... > -----Original Message----- > From: Dan Diephouse [mailto:[EMAIL PROTECTED] > Sent: 22 March 2007 20:53 > To: [email protected] > Subject: Re: [PROPOSAL] Client and Conduit changes > > On 3/20/07, Glynn, Eoghan <[EMAIL PROTECTED]> 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. 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? > > 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. 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? 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. > > 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. 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. Otherwise, it seems to me there is no consistency argument. > The benefit is that it does not introduce a new ClientPolicy > class and does not the Conduit contract. Is introducing an abstract ConduitPolicy really that big an issue? 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. Cheers, Eoghan
