You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Polar Humenn <ph...@iona.com> on 2007/03/12 21:28:14 UTC
http: URLs and setepURL
In the HttpConduit I have noticed that the "url" for the conduit is set
up in the constructors from the EndpointInfo, or the EndpointReferenceType.
However, it maybe totally overridden in send(Message) by the
Message.ENDPOINT_ADDRESS on the message. What purpose does this have?
Shouldn't this conduit ONLY be sending messages to the endpoint
designated (configured) for it?
Furthermore, the code fragment in setupURL
String result = value != null ? value : url.toString();
if (null != pathInfo && !result.endWith(pathInfo)) {
result = result + pathInfo;
}
has a bit of a caveat in that you'd never be able to send a request to a
location
of "http://somewhere.com/xx/xx", specified by a URL of
"http://somwhere.com/xx" a Message.PATH_INFO property of "/xx".
Now some might say "why would you want to do that?" I know "xx" doesn't
make sense to most, but what about,
"http://somewhere.com/path/to/parent/.."
as a URL location built up from other things you might have dealt with,
and you want to set a path from there to be "/.." Then you are in a
completely different location than you want to be.
Is there a specific "contract" are placed on Message.ENDPOINT_ADDRESS,
Message.PATH_INFO for this situation, or its it a bug?
Cheers,
-Polar
Re: http: URLs and setepURL
Posted by Dan Diephouse <da...@envoisolutions.com>.
Heh, seems I realized my error about the same time you did. Thanks.
- Dan
On 3/13/07, Glynn, Eoghan <eo...@iona.com> wrote:
>
>
>
> > > 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?
>
>
> Gotta jump on this point before this discussion gets conflated with a
> completely separate issue ...
>
> First you guys are referring to *different* EndpointReferenceType
> instances ... Polar to the Conduit's target, Dan to its back-channel
> (accessible via Conduit.getTarget() and
> Conduit.getBackChannel().getAddress() respectively).
>
> Secondly, Polar, you're wrong to say the EndpointReferenceType is
> 'basically a "return address" for a "decoupled" response'. It's simply a
> type that represents an endpoint, and can refer to ANY endpoint, whether
> server-side or client-side, whether consuming requests, responses or
> faults. So this type is not misnamed as you suggest.
>
> And yes, the wsa:ReplyTo endpoint reference could refer to an endpoint
> on a different machine. I would contend that it *must* be the same
> transport, though this restriction isn't spelt out explicitly by the
> WS-A spec. DanD & I debated this issue previously on cxf-dev, can't
> remember the thread subject, but the outcome was that we would not allow
> different transports for the To & ReplyTo as there's no way for the
> client to know that the server-side supports any transport other than
> the one advertized by the target endpoint.
>
> /Eoghan
>
>
>
>
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: http: URLs and setepURL
Posted by Polar Humenn <ph...@iona.com>.
Dan Diephouse wrote:
> On 3/13/07, Polar Humenn <ph...@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.
>
C'mon guys, they *have* to *mean* something, and there must be something
common about them!
So, if you say its a "way" to link together EndpointInfo and a Conduit,
then it has no dependence on any meaning external to CXF? Somehow I
don't believe that.
What would happen if a conduit initiator wasn't registered under some of
these names?
Lets say for example, the one ending in "/configuration".
What would break?
Would a client not be able to talk to specified endpoint in a particular
WSDL file? Would a client not be able to send a message to a logical
host it constructed programmatically?
-Polar
Re: http: URLs and setepURL
Posted by Dan Diephouse <da...@envoisolutions.com>.
On 3/13/07, Polar Humenn <ph...@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
RE: http: URLs and setepURL
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> -----Original Message-----
>
> > Secondly, Polar, you're wrong to say the EndpointReferenceType is
> > 'basically a "return address" for a "decoupled" response'.
> It's simply
> > a type that represents an endpoint, and can refer to ANY endpoint,
> > whether server-side or client-side, whether consuming requests,
> > responses or faults. So this type is not misnamed as you suggest.
> >
>
> I don't mind being wrong, but I would like the informed
> opportunity to be right. :)
>
> So, I want to write some documentation as to what the nature
> of this beast really is. Please help me to elaborate. In the
> HTTPConduit Constructor and elsewhere what is the formal
> correlation between the EndpointInfo and the EndpointReferenceType?
Is it just the client-side you're concerned with?
Then note, the ConduitInitiator.getConduit(EndpointInfo endpointInfo,
EndpointReferenceType target) override is NOT used on the client-side.
So the EndpointReferenceType param passed to the ctor is ALWAYS null. A
new EPR is fabricated from the address specified in the EndpointInfo and
this is used as the Conduit target.
The getConduit() target parama is only ever non-null AFAIK on the
server-side when a decoupled back-channel is being established. In this
case the EndpointInfo is for the (server-side) target endpoint, whereas
the EndpointReferenceType is to the decoupled (client-side)replyTo.
In the original version of the ConduitInitiator, only the
getConduit(EndpointReferenceType target) was defined. The override with
the extra EndpointInfo param was added to facilitate the retrieval of
config.
So please, lets draw a line under this and move on.
> > And yes, the wsa:ReplyTo endpoint reference could refer to
> an endpoint
> > on a different machine.
> Is this a logical entity?
The EPR refers to physical endpoint, e.g. a HTTP listener on host X &
port Y.
> Is it "externalized" as an Http header?
No.
> A Soap header?
Maybe.
For example in the <wsa:ReplyTo> or <wsa:FaultTo>, or the
<wsrm:AcksTo>.
Or maybe the EPR instance is never externalized, it depends on the
usage.
> EndpointReferenceType: What is "Reference" about it?
It refers to something. That something is an endpoint. Which makes it an
endpoint reference. That's just the name dreamt up by the WS-A spec
writers. They could have called it a FooBar instead. I don't see a real
issue here.
> and what is "Type" about it?
Please read the WS-A schema.
It's called an EndpointReference*Type* bacuase that's the coding style
used in the schema ... i.e. define a complex type, and call it
FooBarType.
JAXB then generates Java code from the schema. The schema type name
determines the Java type name. Again, I don't see a real issue here.
> The one you are talking about here, is the "Return Address"
> type for a "decoupled" response?
No.
Dan mistook the target EPR of the Conduit with the back-channel EPR.
I explained this in my last mail on this thread.
As did Dan in his last mail.
Can't make it any clearer.
> > I would contend that it *must* be the same transport, though this
> > restriction isn't spelt out explicitly by the WS-A spec. DanD & I
> > debated this issue previously on cxf-dev, can't remember the thread
> > subject, but the outcome was that we would not allow different
> > transports for the To & ReplyTo as there's no way for the client to
> > know that the server-side supports any transport other than the one
> > advertized by the target endpoint.
> >
> >
>
> I have to ask, what is meant by "Transport" here
A thing that moves bits from A to B. And back again.
/Eoghan
Re: http: URLs and setepURL
Posted by Polar Humenn <ph...@iona.com>.
Glynn, Eoghan wrote:
>
>
>
>>> 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?
>>
>
>
> Gotta jump on this point before this discussion gets conflated with a
> completely separate issue ...
>
> First you guys are referring to *different* EndpointReferenceType
> instances ... Polar to the Conduit's target, Dan to its back-channel
> (accessible via Conduit.getTarget() and
> Conduit.getBackChannel().getAddress() respectively).
>
> Secondly, Polar, you're wrong to say the EndpointReferenceType is
> 'basically a "return address" for a "decoupled" response'. It's simply a
> type that represents an endpoint, and can refer to ANY endpoint, whether
> server-side or client-side, whether consuming requests, responses or
> faults. So this type is not misnamed as you suggest.
>
I don't mind being wrong, but I would like the informed opportunity to
be right. :)
So, I want to write some documentation as to what the nature of this
beast really is. Please help me to elaborate. In the HTTPConduit
Constructor and elsewhere what is the formal correlation between the
EndpointInfo and the EndpointReferenceType?
> And yes, the wsa:ReplyTo endpoint reference could refer to an endpoint
> on a different machine.
Is this a logical entity? Is it "externalized" as an Http header? A Soap
header?
EndpointReferenceType: What is "Reference" about it? and what is "Type"
about it?
The one you are talking about here, is the "Return Address" type for a
"decoupled" response?
> I would contend that it *must* be the same
> transport, though this restriction isn't spelt out explicitly by the
> WS-A spec. DanD & I debated this issue previously on cxf-dev, can't
> remember the thread subject, but the outcome was that we would not allow
> different transports for the To & ReplyTo as there's no way for the
> client to know that the server-side supports any transport other than
> the one advertized by the target endpoint.
>
>
I have to ask, what is meant by "Transport" here?
cheers,
-Polar
> /Eoghan
>
>
>
>
>
RE: http: URLs and setepURL
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> > 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?
Gotta jump on this point before this discussion gets conflated with a
completely separate issue ...
First you guys are referring to *different* EndpointReferenceType
instances ... Polar to the Conduit's target, Dan to its back-channel
(accessible via Conduit.getTarget() and
Conduit.getBackChannel().getAddress() respectively).
Secondly, Polar, you're wrong to say the EndpointReferenceType is
'basically a "return address" for a "decoupled" response'. It's simply a
type that represents an endpoint, and can refer to ANY endpoint, whether
server-side or client-side, whether consuming requests, responses or
faults. So this type is not misnamed as you suggest.
And yes, the wsa:ReplyTo endpoint reference could refer to an endpoint
on a different machine. I would contend that it *must* be the same
transport, though this restriction isn't spelt out explicitly by the
WS-A spec. DanD & I debated this issue previously on cxf-dev, can't
remember the thread subject, but the outcome was that we would not allow
different transports for the To & ReplyTo as there's no way for the
client to know that the server-side supports any transport other than
the one advertized by the target endpoint.
/Eoghan
Re: http: URLs and setepURL
Posted by Polar Humenn <ph...@iona.com>.
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
>
>
Re: http: URLs and setepURL
Posted by Dan Diephouse <da...@envoisolutions.com>.
On 3/13/07, Dan Diephouse <da...@envoisolutions.com> wrote:
>
>
> 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)
>
My lord, I confused myself with the Destination code.
The EndpointRefereynceType named target is simply a way to override the
address on EndpointInfo.
Sorry for the confusion.
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: http: URLs and setepURL
Posted by Dan Diephouse <da...@envoisolutions.com>.
Hiya Polar,
On 3/13/07, Polar Humenn <ph...@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
Re: http: URLs and setepURL
Posted by Polar Humenn <ph...@iona.com>.
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.
A Conduit is merely a message sender to a *type* of service, no matter
where that service may be?
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?
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?
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?
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.
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.
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?
Cheers,
-Polar
Dan Diephouse wrote:
> I don't know that there is a formal requirement that a Conduit be
> attached
> to a single host or attached to a host+path.
>
> I also think you're exaggerating the problem of overriding the endpoint
> address. Typically people will want to use a different address for a
> development server instead of production. So their configuration is
> likely
> to apply to both. I don't really see any users just sticking in a random
> address there and having an issue with trusting a rogue server.
>
> If you have suggestions about how this should work, would love to hear
> them.
>
> On 3/13/07, Polar Humenn <ph...@iona.com> wrote:
>>
>> Aside from this being just plain wrong, there might be a requirement
>> that the endpoint that the conduit is created with is just a URL with
>> host information.
>>
>> Is it supposed to be the case that the EndpointInfo.getAddress() or
>> EndpointReferenceType.getAddress() is only a URL of the form
>> "http://host.com:1234" or is there an associated path?
>>
>> In what situations is the PATH_INFO used? Is it part of the JAX-WS?
>>
>> Cheers,
>> -Polar
>>
>> Dan Diephouse wrote:
>> > On 3/12/07, Polar Humenn <ph...@iona.com> wrote:
>> >
>> >> Shouldn't this conduit ONLY be sending messages to the endpoint
>> >> designated (configured) for it?
>> >>
>> >> Furthermore, the code fragment in setupURL
>> >>
>> >> String result = value != null ? value : url.toString();
>> >> if (null != pathInfo && !result.endWith(pathInfo)) {
>> >> result = result + pathInfo;
>> >> }
>> >>
>> >> has a bit of a caveat in that you'd never be able to send a
>> request to
>> a
>> >> location
>> >> of "http://somewhere.com/xx/xx", specified by a URL of
>> >> "http://somwhere.com/xx" a Message.PATH_INFO property of "/xx".
>> >>
>> >> Now some might say "why would you want to do that?" I know "xx"
>> doesn't
>> >> make sense to most, but what about,
>> >>
>> >> "http://somewhere.com/path/to/parent/.."
>> >>
>> >> as a URL location built up from other things you might have dealt
>> with,
>> >> and you want to set a path from there to be "/.." Then you are in a
>> >> completely different location than you want to be.
>> >>
>> >> Is there a specific "contract" are placed on
>> Message.ENDPOINT_ADDRESS,
>> >> Message.PATH_INFO for this situation, or its it a bug?
>> >
>> >
>> > -1 to changing this. PATH_INFO is supposed to be all the stuff
>> after the
>> > host. Just like URI.getPath(). -
>> > http://java.sun.com/j2se/1.5.0/docs/api/index.html?java/net/URI.html
>> >
>> > - Dan
>> >
>> >
>>
>>
>
>
Re: http: URLs and setepURL
Posted by Dan Diephouse <da...@envoisolutions.com>.
I don't know that there is a formal requirement that a Conduit be attached
to a single host or attached to a host+path.
I also think you're exaggerating the problem of overriding the endpoint
address. Typically people will want to use a different address for a
development server instead of production. So their configuration is likely
to apply to both. I don't really see any users just sticking in a random
address there and having an issue with trusting a rogue server.
If you have suggestions about how this should work, would love to hear them.
On 3/13/07, Polar Humenn <ph...@iona.com> wrote:
>
> Aside from this being just plain wrong, there might be a requirement
> that the endpoint that the conduit is created with is just a URL with
> host information.
>
> Is it supposed to be the case that the EndpointInfo.getAddress() or
> EndpointReferenceType.getAddress() is only a URL of the form
> "http://host.com:1234" or is there an associated path?
>
> In what situations is the PATH_INFO used? Is it part of the JAX-WS?
>
> Cheers,
> -Polar
>
> Dan Diephouse wrote:
> > On 3/12/07, Polar Humenn <ph...@iona.com> wrote:
> >
> >> Shouldn't this conduit ONLY be sending messages to the endpoint
> >> designated (configured) for it?
> >>
> >> Furthermore, the code fragment in setupURL
> >>
> >> String result = value != null ? value : url.toString();
> >> if (null != pathInfo && !result.endWith(pathInfo)) {
> >> result = result + pathInfo;
> >> }
> >>
> >> has a bit of a caveat in that you'd never be able to send a request to
> a
> >> location
> >> of "http://somewhere.com/xx/xx", specified by a URL of
> >> "http://somwhere.com/xx" a Message.PATH_INFO property of "/xx".
> >>
> >> Now some might say "why would you want to do that?" I know "xx" doesn't
> >> make sense to most, but what about,
> >>
> >> "http://somewhere.com/path/to/parent/.."
> >>
> >> as a URL location built up from other things you might have dealt with,
> >> and you want to set a path from there to be "/.." Then you are in a
> >> completely different location than you want to be.
> >>
> >> Is there a specific "contract" are placed on Message.ENDPOINT_ADDRESS,
> >> Message.PATH_INFO for this situation, or its it a bug?
> >
> >
> > -1 to changing this. PATH_INFO is supposed to be all the stuff after the
> > host. Just like URI.getPath(). -
> > http://java.sun.com/j2se/1.5.0/docs/api/index.html?java/net/URI.html
> >
> > - Dan
> >
> >
>
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: http: URLs and setepURL
Posted by Polar Humenn <ph...@iona.com>.
Aside from this being just plain wrong, there might be a requirement
that the endpoint that the conduit is created with is just a URL with
host information.
Is it supposed to be the case that the EndpointInfo.getAddress() or
EndpointReferenceType.getAddress() is only a URL of the form
"http://host.com:1234" or is there an associated path?
In what situations is the PATH_INFO used? Is it part of the JAX-WS?
Cheers,
-Polar
Dan Diephouse wrote:
> On 3/12/07, Polar Humenn <ph...@iona.com> wrote:
>
>> Shouldn't this conduit ONLY be sending messages to the endpoint
>> designated (configured) for it?
>>
>> Furthermore, the code fragment in setupURL
>>
>> String result = value != null ? value : url.toString();
>> if (null != pathInfo && !result.endWith(pathInfo)) {
>> result = result + pathInfo;
>> }
>>
>> has a bit of a caveat in that you'd never be able to send a request to a
>> location
>> of "http://somewhere.com/xx/xx", specified by a URL of
>> "http://somwhere.com/xx" a Message.PATH_INFO property of "/xx".
>>
>> Now some might say "why would you want to do that?" I know "xx" doesn't
>> make sense to most, but what about,
>>
>> "http://somewhere.com/path/to/parent/.."
>>
>> as a URL location built up from other things you might have dealt with,
>> and you want to set a path from there to be "/.." Then you are in a
>> completely different location than you want to be.
>>
>> Is there a specific "contract" are placed on Message.ENDPOINT_ADDRESS,
>> Message.PATH_INFO for this situation, or its it a bug?
>
>
> -1 to changing this. PATH_INFO is supposed to be all the stuff after the
> host. Just like URI.getPath(). -
> http://java.sun.com/j2se/1.5.0/docs/api/index.html?java/net/URI.html
>
> - Dan
>
>
Re: http: URLs and setepURL
Posted by Dan Diephouse <da...@envoisolutions.com>.
On 3/12/07, Polar Humenn <ph...@iona.com> wrote:
> Shouldn't this conduit ONLY be sending messages to the endpoint
> designated (configured) for it?
>
> Furthermore, the code fragment in setupURL
>
> String result = value != null ? value : url.toString();
> if (null != pathInfo && !result.endWith(pathInfo)) {
> result = result + pathInfo;
> }
>
> has a bit of a caveat in that you'd never be able to send a request to a
> location
> of "http://somewhere.com/xx/xx", specified by a URL of
> "http://somwhere.com/xx" a Message.PATH_INFO property of "/xx".
>
> Now some might say "why would you want to do that?" I know "xx" doesn't
> make sense to most, but what about,
>
> "http://somewhere.com/path/to/parent/.."
>
> as a URL location built up from other things you might have dealt with,
> and you want to set a path from there to be "/.." Then you are in a
> completely different location than you want to be.
>
> Is there a specific "contract" are placed on Message.ENDPOINT_ADDRESS,
> Message.PATH_INFO for this situation, or its it a bug?
-1 to changing this. PATH_INFO is supposed to be all the stuff after the
host. Just like URI.getPath(). -
http://java.sun.com/j2se/1.5.0/docs/api/index.html?java/net/URI.html
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
RE: http: URLs and setepURL
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> -----Original Message-----
> From: Polar Humenn [mailto:phumenn@iona.com]
> Sent: 13 March 2007 13:32
> To: cxf-dev@incubator.apache.org
> Subject: Re: http: URLs and setepURL
>
> If you set up "configuration" with trust deciders and other
> security related stuff, you are fooled into thinking you are
> actually protecting the send to one endpoint, when in fact
> it's getting shipped off to a completely different endpoint
> than the one you configured.
There's no foolin' going on here IMO.
Here's the way I'd see it working ...
1. Conduit.send() figures out the endpoint address it should use, from
the EndpointInfo or EPR, possibly over-ridden by the
Message.ENDPOINT_ADDRESS property.
2. Conduit.send() opens the connection.
3. Now the Conduit knows exactly what the endpoint address is (modulo IP
spoofing), plus possibly some other security-related info (such as the
TLS context in the case of HTTPS)
4. This connection-related info, plus the Exchange, is passed from
Conduit.send() to TrustDecider.establishTrust() so it can make a trust
evaluation
5. If trust is denied, the connection is immediately shut down without
any data being written, and presumably an Exception is propagated up the
application code
So nothing is ever given the wrong impression as to the actual endpoint
that'll be invoked on.
Note that I wrote Conduit.send() above as opposed to HTTPConduit. With a
bit of creativity, this functionality could I guess be put into the
AbstractConduit so as to be available to all transport impls, if you can
come up with generic "target endpoint" and "security context"
representations to pass into a cross-transport TrustDecider.
But initially, it probably only makes sense for HTTP, because this is
the only transport that gives us the TLS context (i.e. via the
HttpsURLConnection.getCipherSuite()/getServerCert() etc APIs).
/Eoghan
> If that's allowed to happen, then you have no assurance what
> is happening and you just might as well protect things down
> at a lower level with VPN stuff.
>
> Cheers,
> -Polar
>
>
> Dan Diephouse wrote:
> > I tend to agree with Polar that it is kind of weird. I thought the
> > idea was that a Conduit is supposed to be a Conduit to a particular
> > endpoint, not many.
> >
> > BUT there is the practical issue of configuration. We may want to
> > configure our conduit based on:
> > 1. The particular jax-ws client & the wsdl port it is talking to 2.
> > The particular URL 3. Both 1 & 2.
> >
> > The problem with #1 is that you have to put in the logic in
> conduits
> > that we already have. The problem with #2 is that we can't have
> > different clients talk to the same url with different settings.
> >
> > I guess we could go down the route of:
> > - If a different EPR is specified create a new Conduit in the
> > MessageSenderInterceptor
> > - Apply the configuration to the new conduit like it would
> be applied
> > to the original conduit
> >
> > But wouldn't that be pretty much equivalent (at least for
> the HTTP case)?
> >
> > - Dan
> >
> > On 3/12/07, Glynn, Eoghan <eo...@iona.com> wrote:
> >>
> >>
> >>
> >> > -----Original Message-----
> >> > From: Polar Humenn [mailto:phumenn@iona.com]
> >> > Sent: 12 March 2007 20:28
> >> > To: cxf-dev@incubator.apache.org
> >> > Subject: http: URLs and setepURL
> >> >
> >> > In the HttpConduit I have noticed that the "url" for the
> conduit is
> >> > set up in the constructors from the EndpointInfo, or the
> >> > EndpointReferenceType.
> >> >
> >> > However, it maybe totally overridden in send(Message) by the
> >> > Message.ENDPOINT_ADDRESS on the message. What purpose
> does this have?
> >>
> >>
> >> I'd imagine the purpose is to support the standard JAX-WS
> mechanism
> >> whereby the application can explicitly control the target
> address by
> >> setting the BindingProvider.ENDPOINT_ADDRESS_PROPERTY on
> the request
> >> context.
> >>
> >>
> >> > Shouldn't this conduit ONLY be sending messages to the endpoint
> >> > designated (configured) for it?
> >>
> >>
> >> Not necessarily.
> >>
> >> The purpose of the BindingProvider.ENDPOINT_ADDRESS_PROPERTY is to
> >> give the client application the flexibility to override the target
> >> endpoint address if necessary. For example the service may have
> >> migrated to a new address, but the WSDL or annotated Java
> available
> >> to the client app may be out-of-date.
> >>
> >>
> >> > Furthermore, the code fragment in setupURL
> >> >
> >> > String result = value != null ? value : url.toString();
> >> > if (null != pathInfo && !result.endWith(pathInfo)) {
> >> > result = result + pathInfo;
> >> > }
> >> >
> >> > has a bit of a caveat in that you'd never be able to
> send a request
> >> > to a location of "http://somewhere.com/xx/xx",
> specified by a URL
> >> > of "http://somwhere.com/xx" a Message.PATH_INFO property
> of "/xx".
> >>
> >>
> >> If you think this is an important usage scenario, feel
> free to submit a
> >> patch with a fix.
> >>
> >>
> >> > Now some might say "why would you want to do that?" I know
> >> > "xx" doesn't make sense to most, but what about,
> >> >
> >> > "http://somewhere.com/path/to/parent/.."
> >> >
> >> > as a URL location built up from other things you might have
> >> > dealt with, and you want to set a path from there to be "/.."
> >> > Then you are in a completely different location than you
> want to be.
> >> >
> >> > Is there a specific "contract" are placed on
> >> > Message.ENDPOINT_ADDRESS, Message.PATH_INFO for this
> >> > situation, or its it a bug?
> >> >
> >> > Cheers,
> >> > -Polar
> >> >
> >> >
> >>
> >
> >
> >
>
>
Re: http: URLs and setepURL
Posted by Polar Humenn <ph...@iona.com>.
If you set up "configuration" with trust deciders and other security
related stuff, you are fooled into thinking you are actually protecting
the send to one endpoint, when in fact it's getting shipped off to a
completely different endpoint than the one you configured.
If that's allowed to happen, then you have no assurance what is
happening and you just might as well protect things down at a lower
level with VPN stuff.
Cheers,
-Polar
Dan Diephouse wrote:
> I tend to agree with Polar that it is kind of weird. I thought the
> idea was
> that a Conduit is supposed to be a Conduit to a particular endpoint, not
> many.
>
> BUT there is the practical issue of configuration. We may want to
> configure
> our conduit based on:
> 1. The particular jax-ws client & the wsdl port it is talking to
> 2. The particular URL
> 3. Both 1 & 2.
>
> The problem with #1 is that you have to put in the logic in conduits
> that we
> already have. The problem with #2 is that we can't have different clients
> talk to the same url with different settings.
>
> I guess we could go down the route of:
> - If a different EPR is specified create a new Conduit in the
> MessageSenderInterceptor
> - Apply the configuration to the new conduit like it would be applied
> to the
> original conduit
>
> But wouldn't that be pretty much equivalent (at least for the HTTP case)?
>
> - Dan
>
> On 3/12/07, Glynn, Eoghan <eo...@iona.com> wrote:
>>
>>
>>
>> > -----Original Message-----
>> > From: Polar Humenn [mailto:phumenn@iona.com]
>> > Sent: 12 March 2007 20:28
>> > To: cxf-dev@incubator.apache.org
>> > Subject: http: URLs and setepURL
>> >
>> > In the HttpConduit I have noticed that the "url" for the
>> > conduit is set up in the constructors from the EndpointInfo,
>> > or the EndpointReferenceType.
>> >
>> > However, it maybe totally overridden in send(Message) by the
>> > Message.ENDPOINT_ADDRESS on the message. What purpose does this have?
>>
>>
>> I'd imagine the purpose is to support the standard JAX-WS mechanism
>> whereby the application can explicitly control the target address by
>> setting the BindingProvider.ENDPOINT_ADDRESS_PROPERTY on the request
>> context.
>>
>>
>> > Shouldn't this conduit ONLY be sending messages to the
>> > endpoint designated (configured) for it?
>>
>>
>> Not necessarily.
>>
>> The purpose of the BindingProvider.ENDPOINT_ADDRESS_PROPERTY is to give
>> the client application the flexibility to override the target endpoint
>> address if necessary. For example the service may have migrated to a new
>> address, but the WSDL or annotated Java available to the client app may
>> be out-of-date.
>>
>>
>> > Furthermore, the code fragment in setupURL
>> >
>> > String result = value != null ? value : url.toString();
>> > if (null != pathInfo && !result.endWith(pathInfo)) {
>> > result = result + pathInfo;
>> > }
>> >
>> > has a bit of a caveat in that you'd never be able to send a
>> > request to a location of "http://somewhere.com/xx/xx",
>> > specified by a URL of "http://somwhere.com/xx" a
>> > Message.PATH_INFO property of "/xx".
>>
>>
>> If you think this is an important usage scenario, feel free to submit a
>> patch with a fix.
>>
>>
>> > Now some might say "why would you want to do that?" I know
>> > "xx" doesn't make sense to most, but what about,
>> >
>> > "http://somewhere.com/path/to/parent/.."
>> >
>> > as a URL location built up from other things you might have
>> > dealt with, and you want to set a path from there to be "/.."
>> > Then you are in a completely different location than you want to be.
>> >
>> > Is there a specific "contract" are placed on
>> > Message.ENDPOINT_ADDRESS, Message.PATH_INFO for this
>> > situation, or its it a bug?
>> >
>> > Cheers,
>> > -Polar
>> >
>> >
>>
>
>
>
Re: http: URLs and setepURL
Posted by Dan Diephouse <da...@envoisolutions.com>.
I tend to agree with Polar that it is kind of weird. I thought the idea was
that a Conduit is supposed to be a Conduit to a particular endpoint, not
many.
BUT there is the practical issue of configuration. We may want to configure
our conduit based on:
1. The particular jax-ws client & the wsdl port it is talking to
2. The particular URL
3. Both 1 & 2.
The problem with #1 is that you have to put in the logic in conduits that we
already have. The problem with #2 is that we can't have different clients
talk to the same url with different settings.
I guess we could go down the route of:
- If a different EPR is specified create a new Conduit in the
MessageSenderInterceptor
- Apply the configuration to the new conduit like it would be applied to the
original conduit
But wouldn't that be pretty much equivalent (at least for the HTTP case)?
- Dan
On 3/12/07, Glynn, Eoghan <eo...@iona.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Polar Humenn [mailto:phumenn@iona.com]
> > Sent: 12 March 2007 20:28
> > To: cxf-dev@incubator.apache.org
> > Subject: http: URLs and setepURL
> >
> > In the HttpConduit I have noticed that the "url" for the
> > conduit is set up in the constructors from the EndpointInfo,
> > or the EndpointReferenceType.
> >
> > However, it maybe totally overridden in send(Message) by the
> > Message.ENDPOINT_ADDRESS on the message. What purpose does this have?
>
>
> I'd imagine the purpose is to support the standard JAX-WS mechanism
> whereby the application can explicitly control the target address by
> setting the BindingProvider.ENDPOINT_ADDRESS_PROPERTY on the request
> context.
>
>
> > Shouldn't this conduit ONLY be sending messages to the
> > endpoint designated (configured) for it?
>
>
> Not necessarily.
>
> The purpose of the BindingProvider.ENDPOINT_ADDRESS_PROPERTY is to give
> the client application the flexibility to override the target endpoint
> address if necessary. For example the service may have migrated to a new
> address, but the WSDL or annotated Java available to the client app may
> be out-of-date.
>
>
> > Furthermore, the code fragment in setupURL
> >
> > String result = value != null ? value : url.toString();
> > if (null != pathInfo && !result.endWith(pathInfo)) {
> > result = result + pathInfo;
> > }
> >
> > has a bit of a caveat in that you'd never be able to send a
> > request to a location of "http://somewhere.com/xx/xx",
> > specified by a URL of "http://somwhere.com/xx" a
> > Message.PATH_INFO property of "/xx".
>
>
> If you think this is an important usage scenario, feel free to submit a
> patch with a fix.
>
>
> > Now some might say "why would you want to do that?" I know
> > "xx" doesn't make sense to most, but what about,
> >
> > "http://somewhere.com/path/to/parent/.."
> >
> > as a URL location built up from other things you might have
> > dealt with, and you want to set a path from there to be "/.."
> > Then you are in a completely different location than you want to be.
> >
> > Is there a specific "contract" are placed on
> > Message.ENDPOINT_ADDRESS, Message.PATH_INFO for this
> > situation, or its it a bug?
> >
> > Cheers,
> > -Polar
> >
> >
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
RE: http: URLs and setepURL
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> -----Original Message-----
> From: Polar Humenn [mailto:phumenn@iona.com]
> Sent: 12 March 2007 20:28
> To: cxf-dev@incubator.apache.org
> Subject: http: URLs and setepURL
>
> In the HttpConduit I have noticed that the "url" for the
> conduit is set up in the constructors from the EndpointInfo,
> or the EndpointReferenceType.
>
> However, it maybe totally overridden in send(Message) by the
> Message.ENDPOINT_ADDRESS on the message. What purpose does this have?
I'd imagine the purpose is to support the standard JAX-WS mechanism
whereby the application can explicitly control the target address by
setting the BindingProvider.ENDPOINT_ADDRESS_PROPERTY on the request
context.
> Shouldn't this conduit ONLY be sending messages to the
> endpoint designated (configured) for it?
Not necessarily.
The purpose of the BindingProvider.ENDPOINT_ADDRESS_PROPERTY is to give
the client application the flexibility to override the target endpoint
address if necessary. For example the service may have migrated to a new
address, but the WSDL or annotated Java available to the client app may
be out-of-date.
> Furthermore, the code fragment in setupURL
>
> String result = value != null ? value : url.toString();
> if (null != pathInfo && !result.endWith(pathInfo)) {
> result = result + pathInfo;
> }
>
> has a bit of a caveat in that you'd never be able to send a
> request to a location of "http://somewhere.com/xx/xx",
> specified by a URL of "http://somwhere.com/xx" a
> Message.PATH_INFO property of "/xx".
If you think this is an important usage scenario, feel free to submit a
patch with a fix.
> Now some might say "why would you want to do that?" I know
> "xx" doesn't make sense to most, but what about,
>
> "http://somewhere.com/path/to/parent/.."
>
> as a URL location built up from other things you might have
> dealt with, and you want to set a path from there to be "/.."
> Then you are in a completely different location than you want to be.
>
> Is there a specific "contract" are placed on
> Message.ENDPOINT_ADDRESS, Message.PATH_INFO for this
> situation, or its it a bug?
>
> Cheers,
> -Polar
>
>