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 Sat, 03 Mar 2007 00:58:50 GMT
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 <eoghan.glynn@iona.com> 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:dan@envoisolutions.com]
> > Sent: 27 February 2007 16:06
> > To: cxf-dev@incubator.apache.org
> > 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

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