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. 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). 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. Makes sense, or? Cheers, Eoghan > -----Original Message----- > From: Dan Diephouse [mailto:[EMAIL PROTECTED] > Sent: 03 March 2007 00:59 > To: [email protected] > Subject: Re: Client API, EPRs > > Hi Eoghan, > I'm a bit concerned about having to set this on the > HTTPConduit (or its configuration). This seems to force the > user to always be involved in setting up the decoupled > endpoint as there is no standard way across transports to set > up the decoupled channel. > > Lets say I embed CXF in another product and I need to > configure via the API the ReplyTo EPR for sequence > acknowledgements. Now my product needs to be aware of each > and every transport that supports decoupling and how to set > up the decoupled response channel. i.e. > HTTPClientPolicy.setDecoupledEndpoint(...); > on each transport. > > Couldn't we make a generic way for people to specify the > ReplyTo EPR and let CXF take care of the rest? By "the rest" > I mean that CXF would set up the decoupled response listener > with just the knowledge of my EPR. Or am I missing something here? > > - Dan > > On 2/27/07, Glynn, Eoghan <[EMAIL PROTECTED]> wrote: > > > > > > Dan, > > > > Have a look at the ws_addressing demo, specifically the explicit > > propogation model. > > > > Here the JAX-WS request context is used to associate a specific > > AddressingProperties instance with the invocation, in this > case to use > > a particular message ID. > > > > Note however that setting the replyTo to a specific EPR won't cause > > the HTTP transport to start listening for decoupled > responses on this URI. > > We've discussed this before on this list, and as you know the > > decoupled response endpoint is currently sepcified as part of the > > HTTPConduit config. > > > > Also as DanK points, the JAX-WS 2.1 subsumes JAX-WSA and provides a > > bunch of convenience APIs for WS-A, including a > > javax.xml.ws.EndpointReference type with a less ugly API > than the JAXB > > generated type that you're complaining about. Instances of > this type > > may be created via BindingProvider.getEndpointReference() and then > > used for example to retrieve a proxy via > > Service.getPort(EndpointReference epr, ...). > > > > Cheers, > > Eoghan > > > > > -----Original Message----- > > > From: Dan Diephouse [mailto:[EMAIL PROTECTED] > > > Sent: 27 February 2007 16:06 > > > To: [email protected] > > > Subject: Client API, EPRs > > > > > > Hi All, > > > > > > Is there a way to use WS-Adressing from the Client API? > > > Specifically I'd like to be able to set the replyTo/faultTo > > > locations somehow for the Client itself and then also on the > > > invocation context: > > > > > > client.setReplyTo(new EndpointReference(" http://foo/replyTo";)); > > > > > > Or: > > > > > > Map<String, Object> context = ...; > > > context.put(REPLY_TO, epr); > > > client.invoke(operation, args, context); > > > > > > This brings up the question in my mind of whether or not > we really > > > want to use EndpointReferenceType throughout the codebase. I'm > > > uncomfortable with the way things stand as > > > - EndpointRefenceType has an ugly API. It is not easy to > create an > > > EPR from a String/URL and I think it should be doable via a > > > constructor. (Yeah, we can create factories, but thats > ugly and it > > > still doesn't make retrieving values friendlier). > > > - We seem to have an odd mixture of EndpointReferenceTypes and > > > EndointInfos going on in our transport interfaces. On > some methods > > > we require both. It seems like it should be either one or > the other. > > > - WIth that said, using an EndpointInfo is odd to me as > thats part > > > of the service model. Using an EPR seems unnatural for reasons I > > > state above. > > > > > > Whats the advantage of using EndpointReferenceType throughout the > > > codebase as opposed to our own class? > > > > > > Regards, > > > - Dan > > > -- > > > Dan Diephouse > > > Envoi Solutions > > > http://envoisolutions.com | http://netzooid.com/blog > > > > > > > > > -- > Dan Diephouse > Envoi Solutions > http://envoisolutions.com | http://netzooid.com/blog >
