cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <>
Subject Re: http: URLs and setepURL
Date Tue, 13 Mar 2007 21:50:46 GMT
On 3/13/07, Polar Humenn <> wrote:
> 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?

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

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


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 = ...;

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

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


- Dan

Dan Diephouse
Envoi Solutions |

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message