Dan Diephouse wrote:
[snip]
No, think of an activation namespace as a transport id. As in "
http://schemas.xmlsoap.org/soap/http";
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.
http://schemas.xmlsoap.org/wsdl/soap/http
http://schemas.xmlsoap.org/soap/http
http://www.w3.org/2003/05/soap/bindings/HTTP/
http://schemas.xmlsoap.org/wsdl/http
http://cxf.apache.org/transports/http/configuration
http://cxf.apache.org/bindings/xformat
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
blatant.
This is even more disturbing, because (from another thread) if you put
some policy attachment matching a particular WSDL endpoint address
http://backoffice.company.com requiring different some lax settings, and
the request actually gets sent to http://firewall.company.com 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.
Cheers,
-Polar
Regards,
- Dan
1.
http://lists.w3.org/Archives/Public/public-ws-addressing/2005May/0015.html
