cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: http: URLs and setepURL
Date Tue, 13 Mar 2007 22:06:51 GMT
Heh, seems I realized my error about the same time you did. Thanks.
- Dan

On 3/13/07, Glynn, Eoghan <eoghan.glynn@iona.com> wrote:
>
>
>
> > > Then the Conduit is gotten from ConduitInitiator based on the
> > >> EndpointInfo object and possibly a corresponding
> > >> EndpointReferenceType object (what's the formal
> > correlation of these
> > >> two?). On what basis is that Conduit supposed to be
> > created or selected?
> > >
> > >
> > > The EndpointReferenceType is supposed to be the EPR of the back
> > > channel Destination.The conduit is responsible for setting up a
> > > decoupled destination if necessary.
> > >
> > > (I'm not sure how its supposed to work if you have multiple
> > decoupled
> > > destinations though, see the other ongoing thread about
> > Client APIs &
> > > EPRs for info on that)
> > >
> >
> > So the EndpointReferenceType is basically a "return address" for a
> > "decoupled" response. I wish the type name would be more descriptive
> > toward that meaning. What are its constraints w.r.t. the Endpoint in
> > question. Are their any? Can it be a different protocol? If it's an
> > address is completely on some other machine? Is that allowed?
>
>
> Gotta jump on this point before this discussion gets conflated with a
> completely separate issue ...
>
> First you guys are referring to *different* EndpointReferenceType
> instances ... Polar to the Conduit's target, Dan to its back-channel
> (accessible via Conduit.getTarget() and
> Conduit.getBackChannel().getAddress() respectively).
>
> Secondly, Polar, you're wrong to say the EndpointReferenceType is
> 'basically a "return address" for a "decoupled" response'. It's simply a
> type that represents an endpoint, and can refer to ANY endpoint, whether
> server-side or client-side, whether consuming requests, responses or
> faults. So this type is not misnamed as you suggest.
>
> And yes, the wsa:ReplyTo endpoint reference could refer to an endpoint
> on a different machine. I would contend that it *must* be the same
> transport, though this restriction isn't spelt out explicitly by the
> WS-A spec. DanD & I debated this issue previously on cxf-dev, can't
> remember the thread subject, but the outcome was that we would not allow
> different transports for the To & ReplyTo as there's no way for the
> client to know that the server-side supports any transport other than
> the one advertized by the target endpoint.
>
> /Eoghan
>
>
>
>
>


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

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