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: <7b774c950703161354l12f9dfa3p6fbea667e7f569bc@mail.gmail.com>
Date: Fri, 16 Mar 2007 16:54:38 -0400
From: "Dan Diephouse" <dan@envoisolutions.com>
To: cxf-dev@incubator.apache.org
Subject: Re: Client API, EPRs
In-Reply-To: <FA1787F64A095C4090E76EBAF8B183E071FCB3@emea-ems1.IONAGLOBAL.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_80794_7119407.1174078478196"
References: <7b774c950703151824j6cdab3f2p19644e213c607152@mail.gmail.com>
	 <FA1787F64A095C4090E76EBAF8B183E071FCB3@emea-ems1.IONAGLOBAL.com>

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

On 3/16/07, Glynn, Eoghan <eoghan.glynn@iona.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > Sent: 16 March 2007 01:24
> > To: cxf-dev@incubator.apache.org
> > Subject: Re: Client API, EPRs
> >
> > On 3/15/07, Glynn, Eoghan <eoghan.glynn@iona.com> wrote:
> > >
> > >
> > > >
> > > >
> > > >  -1: as I stated in my other email, there isn't any reason to put
> > > > the DRE inside the conduit.
> > > >
> > > > It is much more straightforward to put the Destination on
> > the Client
> > > > and and have the Client shutdown both the Conduit & DRE. Its
> > > > completely unncessary to introduce yet more complexity into our
> > > > transport APIs for this.
> > >
> > >
> > > Obviously my -1 to your -1 :)
> > >
> > > It's a separation of concerns thing. The DRE is IMO an
> > aspect of the
> > > transport. Thus it is best managed within the realm of the
> > transport.
> > >
> > > It's also an existence issue. First we're not guaranteed to
> > even have
> > > a Client instance. Apart from the JAX-WS Dispatch example,
> > which fair
> > > enough could might someday be rebased on the Client (though
> > the return
> > > value handling is a bit different, a List in the Client's
> > case, but a
> > > single Object of type Source or SOAPMessage for the
> > Dispatch). But do
> > > we really want to _require_ that a Client is always used?
> > Suppose the
> > > app just wants to throw together some special-purpose interceptor
> > > chain and kick off the dispatch directly itself. Do we want to
> > > disallow this approach, or force the app to directly manage the DRE
> > > itself in that case?
> >
> >
> > Is that hard for them to do a
> > destinationFactory.getDestination(epr)? I don't think so.
>
>
> Well I do think so :)
>
> The problem is not the complexity of a making a call to
> DestinationFactory.getDestination() per se.
>
> It's the fact of either always having to make this call
> programmatically, or else manage a configuration mechanism so the DRE
> may be specificied declaratively (in config) if the application doesn't
> set it explicitly.
>
> I hope you're not suggesting that we *only* support setting the DRE
> imperatively, i.e. via a programmatic API?
>
> Assuming you're not, then obviously we'd need the option of pulling the
> DRE in from config. But what would this config policy be associated
> with?
>
> The Client? Well maybe there's no Client as I've pointed out.


You pointed out that there is no client if someone is wiring a bunch of
interceptors together by themselves. 99.9999% of the people will have a
Client. And the other people are already working so low level that they're
not going to want an automatically launched DRE anyway.

And yes this configuration can be set with the client and it even makes a
lot more sense that way.
<jaxws:client id="...SomePort">
  <asynchronousEPR>...</asynchronousEPR>
</jaxws:client>

OR
<jaxws:client id="...SomePort">
  <destination><http:destination...></destination>
</jaxws:client>

As an added bonus this also addresses one of my big gripes about the Client
and transport APIs. Namely that Conduits & Destinations can't be dependency
injected. I should be able to create a client, and wire in arbitrary
conduits/destinations with it. This allows for much more flexibility in your
spring configuration. It gets rid of the need to associate a conduit with an
port name.

Why not just pick it up from the Conduit? We already have an established
> Conduit configuration, and we can always be sure a Conduit will  exist
> whenever it makes sense to set a DRE.


Because of API complexity and inconsistency as I've stated in my other
emails.

>
> > If they wanted, they could even create a DecoupledConduit
> > class which transparently manages the underlying Conduit &
> > Destination. But this logic shouldn't be in the normal low
> > level conduits though.
>
>
> I've already suggested putting it into the AbstractConduit. Would that
> address your issue with it being in the low-level Conduits?


NO. It does nothing to address the API complexity or inconsistency issues
I've pointed out.

> And related to both the existence argument and SoC, I'm
> > thinking we may
> > > not even need a Conduit instance at all when mediating an
> > invocation.
> > > An example would be an optimized form of dispatch where a
> > client-side
> > > interceptor can short-circuit out the whole marshalling/transport
> > > thing and instead handle the request directly. So creating
> > the Conduit
> > > from
> > > Client.invoke() seems premature. Which leads me to think
> > that the idea
> > > of the MessageSenderInterceptor creating the conduit, that you
> > > proposed in another with discussion with Polar as an
> > alternate way of
> > > handling the Message.ENDPOINT_ADDRESS override, may in fact be the
> > > proper way to go in *all* cases (if the
> > ConduitInitiator.getConduit()
> > > were to take responsibility for caching pre-existing
> > Conduits with the
> > > same EndpointInfo & target).
> >
> >
> > Are you saying you just want to pass of the request object or
> > whatever to something else and avoid the any kind of
> > serialization or transport? That is completely possible right
> > now. Just make a Conduit which understands
> > Message.getContent(Object.class) and write an ObjectBinding
> > which doesn't do any databinding. The APIs were made to
> > handle *any* representation and if they can't handle one we
> > should be changing those APIs instead of trying to make
> > Conduits optional. I'm strongly against removing the Conduit
> > off the client. Its really handy for manipulating the
> > Conduit's configuration, providing a different Conduit or the like.
>
>
> The Conduit's configuration could be just as easily manipulated via the
> EndpointInfo as I've suggested.


Thats not Spring/Dependency injenction friendly.

And as far as I can see, its *impossible* as things currently stand for
> a different Conduit instance to be provided to the ClientImpl by a
> JAX-WS application. That's because the ClientImpl.initedConduit field is
> protected and may only be set externally via the ctor, which is called
> in jaxws.ServiceImpl.getPort() outside the direct control of the
> application.
>
> So that's hardly really handy.


Also the choice of ConduitInitiator is driven by
> EndpointInfo.getTransportID(). As explained above, a JAX-WS app can't
> avoid the usage of the ConduitInitiator to get the Conduit, i.e. can't
> provide an alternative Conduit implementation upfront. And the
> transportID on the EndpointInfo is currently fixed on creation.


Just because its that way right now, doesn't make it right. We can change
the client to add a setConduit() method.


However the issue of whether the existance of Client implies the
> existance of a Conduit is slightly tangential to the main questions:
>
> 1. must we force Client to exist in order for an invocation to be
> mediated?


If you want to have a DRE automatically set up, then yes, you must the
client.

2. if not, must the application take responsibility for retrieving the
> DRE from config?


No.

3. if not, what other component manages the DRE config?


The Client.

>
> > I still don't see why all these gymnastics are necessary.
>
>
> By gymnastics, do you mean
> "c.getPolicy(ConduitPolicy.class).setDecoupledEndpoint(myEPR)" versus
> "c.setDecoupledEndpoint(myEPR)"?
>
> Its only one extra API call for the app to make. Hardly a quantum leap
> in terms of complexity.


Its not DI/Spring friendly though. It is also inconsistent as I've pointed
out.

- Dan

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

------=_Part_80794_7119407.1174078478196--