Heh, seems I realized my error about the same time you did. Thanks. - Dan
On 3/13/07, Glynn, Eoghan <[EMAIL PROTECTED]> 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
