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 Wed, 14 Mar 2007 16:28:21 GMT

> -----Original Message-----
> > 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.
> >   
> I don't mind being wrong, but I would like the informed 
> opportunity to be right. :)
> So, I want to write some documentation as to what the nature 
> of this beast really is. Please help me to elaborate. In the 
> HTTPConduit Constructor and elsewhere what is the formal 
> correlation between the EndpointInfo and the EndpointReferenceType?

Is it just the client-side you're concerned with?

Then note, the ConduitInitiator.getConduit(EndpointInfo endpointInfo,
EndpointReferenceType target) override is NOT used on the client-side.

So the EndpointReferenceType param passed to the ctor is ALWAYS null. A
new EPR is fabricated from the address specified in the EndpointInfo and
this is used as the Conduit target.

The getConduit() target parama is only ever non-null AFAIK on the
server-side when a decoupled back-channel is being established. In this
case the EndpointInfo is for the (server-side) target endpoint, whereas
the EndpointReferenceType is to the decoupled (client-side)replyTo.

In the original version of the ConduitInitiator, only the
getConduit(EndpointReferenceType target) was defined. The override with
the extra EndpointInfo param was added to facilitate the retrieval of

So please, lets draw a line under this and move on.

> > And yes, the wsa:ReplyTo endpoint reference could refer to 
> an endpoint 
> > on a different machine.
> Is this a logical entity? 

The EPR refers to physical endpoint, e.g. a HTTP listener on host X &
port Y.

> Is it "externalized" as an Http header? 


> A Soap header?


For example in the <wsa:ReplyTo> or  <wsa:FaultTo>, or the

Or maybe the EPR instance is never externalized, it depends on the

> EndpointReferenceType: What is "Reference" about it?

It refers to something. That something is an endpoint. Which makes it an
endpoint reference. That's just the name dreamt up by the WS-A spec
writers. They could have called it a FooBar instead. I don't see a real
issue here.

> and what is "Type" about it?

Please read the WS-A schema. 

It's called an EndpointReference*Type* bacuase that's the coding style
used in the schema ... i.e. define a complex type, and call it

JAXB then generates Java code from the schema. The schema type name
determines the Java type name. Again, I don't see a real issue here.

> The one you are talking about here, is the "Return Address" 
> type for a "decoupled" response?


Dan mistook the target EPR of the Conduit with the back-channel EPR.

I explained this in my last mail on this thread.

As did Dan in his last mail.

Can't make it any clearer.

> > 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.
> >
> >   
> I have to ask, what is meant by "Transport" here

A thing that moves bits from A to B. And back again.


View raw message