cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Polar Humenn <phum...@iona.com>
Subject Re: http: URLs and setepURL
Date Wed, 14 Mar 2007 14:12:52 GMT
Glynn, Eoghan 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.
>   

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?


> And yes, the wsa:ReplyTo endpoint reference could refer to an endpoint
> on a different machine. 
Is this a logical entity? Is it "externalized" as an Http header? A Soap 
header?

EndpointReferenceType: What is "Reference" about it? and what is "Type" 
about it?

The one you are talking about here, is the "Return Address" type for a 
"decoupled" response?
> 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?


cheers,
-Polar
> /Eoghan
>
>   
>
>   
>   


Mime
View raw message