On 3/13/07, Polar Humenn <[EMAIL PROTECTED]> wrote:
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?
They can be "foobar" for all I care. They're just some way to link together
an EndpointInfo and a Conduit/Destination.
WSDL uses various different namespaces to refer to HTTP, at least two of
them are WSDL ids. The last two should should not be there. And I think
there is the possibility that the remaining two could be removed.
> 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?.
Same protocol. Any address. Its the address on the local machine which you
want to receive replies at.
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).
Last one registered wins.
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?
Don't read too much into the ids.
> 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.
I think you're missing that the ClientImpl caches the conduit so it doesn't
create a new Conduit for each message. Only for each client instance.
I'm not sure as to whether we should be caching Conduits.
However, I think we SHOULD be caching destinations. And we are not right
now.
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?
No. The Client should select a conduit. But then users should be able to
select a different conduit by setting properties on the message context. I
was proposing that we inspect the message context in
MessageSenderInterceptor to see if the user wanted a different conduit and
if so, override the Client's conduit.
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?
Correct.
Why does the ClientImpl select the Conduit? Is it so the Client can set
up a "decoupled" response?
No, its more convenience for the user.
Client client = ...;
client.setConduit(myConduit);
OR
client.getConduit().setSomeSetting("foo");
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.
Thats a trade off with ease-of-use. Users can reroute a message at any time.
That is a requirement.
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.
Thats an issue for the policy layer, no?
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?
The client doesn't do that correlation. The frontend figures out which port
they want to talk to, then creates a client for that port.
See ClientProxy, JaxWsClientProxy, and ClientProxyFactoryBean for some more
details.
Regards,
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
