cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Polar Humenn <>
Subject Re: http: URLs and setepURL
Date Tue, 13 Mar 2007 19:55:54 GMT
Dan Diephouse wrote:
> [snip]
> No, think of an activation namespace as a transport id.  As in  "

So, what does a "transport id" mean?  In particular what does the above 
URL mean as a transport id?

In http2 the HTTPTransportFactory seems to get registered under the 
following "activation namespaces" or "transport id"s.

So if a CondiutInitator is registered under all of these "transport id" 
what's the common factor that unites them? Or what are their 
differentiators? What do they signify?

> > I assume from this, that the ConduitInitator returned from the
>> CoduitInitiatorManager is only supposed to issue Conduits in the
>> namespaces it has been registered under? That could be one to many, as
>> one conduit initiator may be registered for many namespaces.
>> From the ClientImpl the namespace seems to be the "TransportID" from
>> the EndpointInfo. What is the "TransportId" supposed to mean? Is this an
>> "activation" namespace? What is the correlation?
> Yes, they're the same thing.  (In my mind we should get rid of the
> activationnamespace terminology as its confusing).

Okay, so at least we've cleared that up.  :-) Yay!  Now, I just want to 
know what each one means or at least with respect to other components, 
WSDL files, logical WSDL, etc.

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

> It seems that currently in CXF there is *only* one ConduitInitiator for
>> all of "http" and that's the http(2).HTTPTransportFactory. It is
>> registered under any number of "activation" namespaces, which seems to
>> be governed by some configuration device.
> The HTTPTransportFactory gets loaded by the CondiuitIniaitorManager. See
> cxf.xml and SpringBeanMap for details on how this is loaded. In essence
> SpringBeanMap looks through the spring context to discover all the
> ConduitInitiators and then registers them with the
> ConduitInitiatorManager.).

Fair enough, what happens when you have conduit initiators that get 
registered under the same name? (or I should say, what is meant to happen).

What are the meanings, or constraints? That is, would you expect 
something that is registered under ".....//http" to be used for anything 
other than "http"? like, "ftp","corba:iiop", or "telnet"? Alternatively, 
would you be assured that it will handle "http". Is there a definitive 
specification for those "transport id"s?

> This implemenation generates a *new* conduit for each
>> getConduit(EndpointInfo, EndpointReferenceType) call and there is no
>> reuse of conduits. The ClientImpl asks for a conduit for each message it
>> creates to a particular endpoint. So the point seems to be moot, as the
>> Endpoint stuff only provides a *default* should the application not want
>> to "override" with the ENDPOINT_ADDRESS, PATH_INFO, and QUERY_STRING.
> That seems odd, it should be using ClientImpl.getConduit().

Well it's an internal call, ClientImpl.getCoduit() gets the 
ConduitInitiationManager, and gets the Conduit Initiator for the 
"transportID", which seems to be associated with the EndpointInfo, and 
then gets the Conduit from the EndpointInfo and EndpointReferenceType.

> So, basically, we can make no assumptions about a Conduit as a point of
>> protection or trust.
>> Operationally, as Eoghan pointed out, we really cannot even assume the
>> actual protocol it is going to handle. Is this correct summation?
> Ick, thats a semantic I really don't like. But thats a good point, if
> someone is overriding the endpoint address for a different transport, we
> should be using a different Conduit implementation.
> So I think I'll get behind the earlier suggestion of
> - Selecting a conduit in MessageSenderInterceptor if the user is 
> overriding
> it via a property.

So you are saying that maybe architecturally the ClientImpl should not 
be selecting the Conduit at all?

The ClientImpl is the core implementation underlying the "stubs" which 
are generated, correct? It basically correlates the request it's going 
to send out, and get back a response if any and return it upwards to the 
stubs. Correct?

Why does the ClientImpl select the Conduit? Is it so the Client can set 
up a "decoupled" response?

ClientImpl should trust that its request to go down to the intended 
target. However, if an interceptor can change by altering the 
ENDPOINT_ADDRESS property on the message, we have got to float any trust 
establishment to when the actual the connection made.

As Eoghan says that he we shouldn't be trusting IP addresses at all 
because of potential spoofing. He's right, here it's just all the more 

This is even more disturbing, because (from another thread) if you put 
some policy attachment matching a particular WSDL endpoint address requiring different some lax settings, and 
the request actually gets sent to where 
requests should be going to that with greater security (stronger 
encryption, etc). then not only have a trust problem, you have an
assurance problem.

> - Always associate a Conduit with a particular protocol and host. 
> (although
> not paths)

This might be a viable approach, but questions must be answered. What is 
the purpose of the Conduit abstraction. Right now it kinda reminds me of 
Worm Holes. :-)

Basically, the ClientImpl (through the Client interface) ties the 
"type/interface/JAX-WS Port" (which basically associates request to 
response) to the CXF core. The ClientImpl explicitly causes a message to 
be sent down a conduit. Should it just "imply" that the message go down 
a conduit? How does does the client correlate the conduit to the 
"type/interface/JAX-WS Port" that called it?

Once we can nail down the semantics this then we can decide on some of 
the details and where to hang assurance/trust/security arguments.

> That gets rid of some of the ickiness, no?
We should try.


> Regards,
> - Dan
> 1.

View raw message