Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <7b774c950703131450y33b1f0acpa71e1710da85a110@mail.gmail.com>
Date: Tue, 13 Mar 2007 17:50:46 -0400
From: "Dan Diephouse" <dan@envoisolutions.com>
To: cxf-dev@incubator.apache.org
Subject: Re: http: URLs and setepURL
In-Reply-To: <45F701CA.9080909@iona.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_30807_31284431.1173822646901"
References: <45F5B7DE.8080104@iona.com>
	 <7b774c950703121900y24de185bgd454c8cc39bd1e5a@mail.gmail.com>
	 <45F6A89E.80108@iona.com>
	 <7b774c950703130716j58911dcdicd584ab486f820b@mail.gmail.com>
	 <45F6C2BC.4030605@iona.com>
	 <7b774c950703130939o27b4e7b9v7ce759ed1c6db4d1@mail.gmail.com>
	 <45F701CA.9080909@iona.com>

------=_Part_30807_31284431.1173822646901
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 3/13/07, Polar Humenn <phumenn@iona.com> 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

------=_Part_30807_31284431.1173822646901--