cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
Subject RE: Client API, EPRs
Date Mon, 12 Mar 2007 17:15:49 GMT
 

> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com] 
> Sent: 11 March 2007 21:48
> To: cxf-dev@incubator.apache.org
> Subject: Re: Client API, EPRs
> 
> Hola,
> 
> Apologies for the lag here. Too much traveling going on and I 
> wanted to spend some time thinking through this some more.
> 
> Some comments inline.
> 
> On 3/6/07, Glynn, Eoghan <eoghan.glynn@iona.com> wrote:
> >
> >
> >
> > Hi Dan,
> >
> > Well if CXF is embedded in another product that *already* 
> exposes an 
> > endpoint (e.g. a HTTP listsner) from the client process space, then 
> > CXF could use that to receive decoupled responses.  All the 
> app needs 
> > to do is to provide an appropriate EPR via 
> > AddressingProperties.setReplyTo (), set this on the request 
> context, 
> > and the CXF WS-A layer won't over-write this with any decoupled 
> > response endpoint that may (or may not) have been 
> configured on the Conduit.
> >
> > However, I don't think its reasonable to expect CXF to *actively* 
> > launch a decoupled response endpoint on the basis of a replyTo EPR 
> > provided by the application, for a number of reasons:
> >
> > 1. the replyTo EPR may not contain all the info that the transport 
> > needs to initiate receipt of incoming messages, e.g. JMS may need 
> > stuff like a username/password for the connection factory, 
> maybe a JNDI provider etc.
> > This sort of transport-specific stuff may not be suitable for 
> > shoe-horning into an EPR, and would probably need to be 
> configured in 
> > a transport-specific way.
> 
> 
> First, thats an edge case. 


JMS is an edge-case?


> Second, people are defining 
> standards to shoe-horn JMS info into IRIs. 


Be that as it may, but as things currently stand, JMS needs more than a
URI.


> Third, when the 
> decoupled destination is being set up it can still pull 
> configuration from xml files if people need to add extra 
> configuration info.


Wouldn't that defeat your stated purpose? (i.e. not having to do
transport-specific config)

 
> 2. there's no guarantee that the replyTo EPR specified by the 
> app makes
> > any sense, e.g. it may be for a different transport to that 
> used for 
> > the outbound request (and we discussed the undesirability of mixed 
> > transport within an MEP on this list a while back).
> 
> 
> We should add checks to ensure that this is sane & valid 
> then. Its not that hard to ensure that the ReplyTo transport 
> is the same as the outgoing one.
> We simply need to match up the transport IDs or the protocol 
> part of the URL.
>
> 3. its hard to see how to manage the lifecycle of a listener 
> created on
> > demand by CXF on foot of an application-provided replyTo. 
> What if the 
> > app specifies a different replyTo URI for each sucessive request, 
> > maybe intending that the listener is a one-shot deal (i.e. is only 
> > intended to accept a single decoupled response). There's no way for 
> > the app to communicate this intended lifecycle with CXF, so CXF 
> > wouldn't know when to shutdown the Destination.
> >
> 
> Lets ignore the per request case a moment: How would this 
> differ from how things currently are? 

Well the intention was that the decoupled endpoint is ref-counted, and
then shutdown when the last HTTPConduit referencing it is closed.

However, looking at the code, this intention seems to be frustrated by
two factors:
- Conduit.close() is not being called anywhere
- the ref count has morphed into being non-static

Gonna have to fix that ...

> Lets say I define a 
> replyTo endpoint in my cxf.xmlfile. Its not going to get shut 
> down until I specifically shut it down myself or until I shut 
> the appserver down. So letting CXF create a destination 
> automatically would not really be any different. It just 
> makes it easier for the user to set up the decoupled endpoint 
> via the API. Once they are done with the client they could call
> Client.getDestination().shutdown()
> and release any resources.


I'm not sure it would be that simple.

The user may have specified different decoupled destinations for a
series of invocations mediated by the same Client instance.

So are we going let these accumulate and then have a
close-all-in-one-fell-swoop type API on Client, say
shutdownAllDestinations()?

But that would have the effect of the client hogging transport resources
(e.g. HTTP ports or JMS Destinations) for much longer than necessary,
i.e. for the period after the client has stopped using these as the
replyTo for requests, but before the corresponding JAX-WS proxy or
whatever goes away.

Also there's the issue of what WS-RM uses as its acksTo address. AFAIK
this is still just the decoupled endpoint associated with the Conduit.
However, it needs to continue to be available to receive ACKs for the
lifetime of the RM sequence. So we don't want the application to be able
pull the rug out from under RM by specifying a short-lived replyTo.

Believe me, I thought about more dynamic approaches like what you're
advocating, but came to the conclusion that the lifecycle mgmt could be
much more error-prone.

/Eoghan

 
> (I also would not be opposed to establishing a client life 
> cycle. I.e. a user can call Client.close() once they are done 
> with everything. This would allow RM to terminate the 
> sequence at the same time. But maybe that is a topic for 
> another thread.)
> 
> Regarding the per request use case, my initial reaction is 
> that we should not do any automatic setup here. The main use 
> case that I'm targeting is creating a standard way to create 
> a decoupled endpoint. If the user is overriding it at a per 
> request level they probably have a good reason for doing so 
> and can manage the endpoint creation themselves. I don't see 
> that as a very common case though.
> 
> I don't think there is anything that evil about auto-creating 
> a decoupled endpoint for the user if they specify it. But it 
> does make it easy for anyone to do it in a standard way. 
> Which simplifies configuration and documentation.
> 
> Regards,
> - Dan
> 
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
> 

Mime
View raw message