cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <>
Subject RE: http: URLs and setepURL
Date Tue, 13 Mar 2007 21:50:40 GMT

> > 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.




View raw message