cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
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
config.

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? 


No.


> A Soap header?


Maybe. 

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

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

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

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?


No.

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.

/Eoghan 

Mime
View raw message