cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: http: URLs and setepURL
Date Tue, 13 Mar 2007 16:39:45 GMT
Hiya Polar,

On 3/13/07, Polar Humenn <phumenn@iona.com> wrote:
>
> Okay Dan,
>
> I was under the impression that the Conduit was tied to a particular
> "endpoint", which in my mind was specified as a host:port+path
> designation. I am undoubtedly mistaken on this point. I think I'm just
> confused as to the formal definition of Endpoint, whatever that may be.


Hell if I know what an endpoint is [1]. It could be a physical endpoint. It
could be more of an interface. It depends on the context.

A Conduit is merely a message sender to a *type* of service, no matter
> where that service may be?


I suppose that works.

Please bear with me as I try to figure out the invariants.
>
> What are the formal requirements for ConduitInitiatorManager and
> ConduitInitiator?
>
> The ConduitIntiatorManager looks like it supposed to get a
> ConuitInitiator via a
> particular namespace, which I assume is something of the form:
>
>        "http://apache.org/hello_world_soap"
>
> and is merely an identifier with no "server like" hosts that are implied
> targets for my requests. Is this correct? These appears to be organized
> as "activationNamespaces". What are "activation" namespaces?


No, think of an activation namespace as a transport id.  As in  "
http://schemas.xmlsoap.org/soap/http"

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

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)

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

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

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.
- Always associate a Conduit with a particular protocol and host. (although
not paths)

That gets rid of some of the ickiness, no?

Regards,
- Dan

1.
http://lists.w3.org/Archives/Public/public-ws-addressing/2005May/0015.html

-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

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