cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: Client API, EPRs
Date Fri, 16 Mar 2007 01:24:02 GMT
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. WS-Addressing interceptors will still work fine even though
there is no client. Its the same case as if they wanted a different FaultTo
or AcksTo.

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.

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.

But if there's a DRE involved, then there's also necessarily a Conduit,
> as we've agreed that the decoupled transport must be the same as the
> outgoing.
>
> To summarize:
> A) An invocation doesn't imply the existence of Client


Not that hard to set up a response destination .

B) A Client shouldn't IMO imply the existence of a Conduit


IMO a Client should always have a Conduit.

C) A DRE does imply the existence of a Conduit


Sure, but that doesn't mean it should be in the Conduit :-)

This seems to me a complete logical justification for referencing the
> DRE from the Conduit.


I disagree. :-)

And we could actually go one step further than what's currently there
> and completely decouple the Client from any direct interaction with the
> transport, by removing the reference even to the Conduit, and setting
> this up from the MessageSenderInterceptor instead.


No need to.



> 3. My main issue was to avoid a proliferation of
> > automatically launched
> > > DREs, as the responsibility for the lifecycle mgmt of these DREs
> > > should be the responsibility of CXF. Fair enough, the DRE shutdown
> > > isn't done properly currently, but it would be a tractable
> > problem to
> > > do so, by virtue of the cardinality being limited to
> > one-per-Conduit.
> > > My whole point was that we shouldn't move to a scenario where for
> > > example the application setting a replyTo on an
> > AddressingProperties
> > > instance set in request context would cause CXF to
> > automatically launch a new listener.
> > > The problem here of course is that allowing a per-request setting
> > > would facilitate the application causing many listeners to
> > be created
> > > by CXF, without a good way for the CXF runtime to know when these
> > > should be shutdown. I take it from your comments in more
> > recent mails
> > > on this thread that this is not the sort of mechanism
> > you're looking
> > > for, correct?
> >
> >
> > I just want to do :
> >
> > Client c = ...
> > c.setDecoupledEndpoint(myEPR);
> > c.invoke(...);
> > c.close();
>
>
> How about this instead:
>
> Client c = ...
> c.getPolicy(ConduitPolicy.class).setDecoupledEndpoint(myEPR);
> c.invoke(...);
> c.close();
>
> From the point-of-view of the application, both approaches look and
> smell very similar.
>
> Then internally, we'd implement the Client.getPolicy() API something
> like:
>
>   public <T> T getPolicy(Class<T> type) {
>       return
> endpoint.getEndpointInfo().getTraversedExtensor(type.newInstance(),
> type);
>   }
>
> ... ensuring that getTraversedExtensor() caches up the policy instance
> so that its available to the Conduit when its first created during the
> message dispatch.


I still don't see why all these gymnastics are necessary.


>
> Agreed on getDestination() caching and return a preexisting one if poss.
>
> Similarly for ConduitInitiator.getConduit() as I suggest above.
>

Cool.

- Dan

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

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