You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Brian De Pradine <PR...@uk.ibm.com> on 2006/11/22 14:34:40 UTC
[Axis2] Defaulting behaviour when a wsa:To header is omitted from a request
message.
Hello all,
Currently, there is a comment in the AddressingFinalInHandler to the
effect that if no wsa:To header is found in an inbound request message
then we do not use the wsa:Anonymous URL as its default value. This is to
allow an alternative, such as the transport URL, to be used instead. I
believe that this is the wrong option for the following reasons:
1) It is not compliant with the WS-Addressing core spec.
2) It prevents us from optimising the set of WS-Addressing headers
included in a message.
Consider the following request:
<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<wsa:To>http://localhost:8081/axis2/services/MyService</wsa:To>
<wsa:ReplyTo>
<wsa:Address>http://www.w3.org/2005/08/addressing/anonymous</wsa:Address>
</wsa:ReplyTo>
<wsa:MessageID>urn:uuid:7A171A9933336AC3CC11641979655001</wsa:MessageID>
<wsa:Action>urn:echo</wsa:Action>
</soapenv:Header>
<soapenv:Body>
.....
</soapenv:Body>
</soapenv:Envelope>
it will result in the following response:
<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<wsa:To>http://www.w3.org/2005/08/addressing/anonymous</wsa:To>
<wsa:ReplyTo>
<wsa:Address>http://www.w3.org/2005/08/addressing/none</wsa:Address>
</wsa:ReplyTo>
<wsa:MessageID>urn:uuid:0839A16552C8EF67E911641979660934</wsa:MessageID>
<wsa:Action>urn:echo</wsa:Action>
<wsa:RelatesTo wsa:RelationshipType="
http://www.w3.org/2005/08/addressing/reply
">urn:uuid:7A171A9933336AC3CC11641979655001</wsa:RelatesTo>
</soapenv:Header>
<soapenv:Body>
.....
</soapenv:Body>
</soapenv:Envelope>
Instead what we would prefer that the following request be sent:
<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<wsa:To>http://localhost:8081/axis2/services/MyService</wsa:To>
<wsa:MessageID>urn:uuid:7A171A9933336AC3CC11641979655001</wsa:MessageID>
<wsa:Action>urn:echo</wsa:Action>
</soapenv:Header>
<soapenv:Body>
.....
</soapenv:Body>
</soapenv:Envelope>
which would provoke the following response:
<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<wsa:ReplyTo>
<wsa:Address>http://www.w3.org/2005/08/addressing/none</wsa:Address>
</wsa:ReplyTo>
<wsa:MessageID>urn:uuid:0839A16552C8EF67E911641979660934</wsa:MessageID>
<wsa:Action>urn:echo</wsa:Action>
<wsa:RelatesTo>urn:uuid:7A171A9933336AC3CC11641979655001</wsa:RelatesTo>
</soapenv:Header>
<soapenv:Body>
.....
</soapenv:Body>
</soapenv:Envelope>
Notice that in the second request-response pair we are able to leave out
optional headers, as they contain values that match the defaults specified
in the spec. In the request we omitted the wsa:ReplyTo header. In the
response we omitted the wsa:To header (and the relationship type attribute
of the wsa:RelatesTo header). The current Axis2 behaviour prevents us from
generating a response message that omits the wsa:To field. The benefit of
doing this is a performance one, i.e. fewer SOAP headers => better
performance.
I am proposing that axis2 provide the following behaviour instead:
1) If ws-addressing is not engaged then the transport URL can be used to
identify the service
2) if ws-addressing is engaged, but there are no ws-addressing headers in
the message then the transport URL can be used to identify the service
3) if ws-addressing is engaged, and there are ws-addressing headers in the
message, and one of them is the wsa:To header then it will be used to
determine the service.
4) if ws-addressing is engaged, and there are ws-addressing headers in the
message, and the wsa:To header is not one of them then the default value
will be used ( Note: For an inbound request message, an address of
wsa:Anonymous will likely result in a "Service not found" fault. This
means that, if addressing is being used, the wsa:To field of a request
message should always be provided explicitly. For a response message, the
AddressingBasedDispatcher will use the wsa:RelatesTo field to correlate
the response to the original request, so dispatching is not an issue in
this case.)
All comments welcome.
Cheers
Brian DePradine
Web Services Development
IBM Hursley
External +44 (0) 1962 816319 Internal 246319
If you can't find the time to do it right the first time, where will you
find the time to do it again?
Re: [Axis2] Defaulting behaviour when a wsa:To header is omitted from a
request message.
Posted by Brian De Pradine <PR...@uk.ibm.com>.
Hi Eran,
My response is below.
Cheers
Brian DePradine
Web Services Development
IBM Hursley
External +44 (0) 1962 816319 Internal 246319
If you can't find the time to do it right the first time, where will you
find the time to do it again?
Eran Chinthaka <ch...@opensource.lk> wrote on 01/12/2006 18:25:13:
> > As an alternative, there is an existing property called
> > org.apache.axis2.Constants.Configuration.TRANSPORT_IN_URL that already
> > holds the inbound transport URL. If some code wants to use the
transport
> > URL then maybe we should consider stipulating that the code must
always
> > use this property to perform the lookup?
>
> On the other way round, if some one wants to look at the addressing To
> value set it as a property to message context or look in envelope.
> Presence of the above TRANSPORT_IN_URL is not a must.
> But presence of messagecontext.to is a must.
Yes this is also an alternative, I will consider if i can make this work
for me.
Re: [Axis2] Defaulting behaviour when a wsa:To header is omitted
from a request message.
Posted by Eran Chinthaka <ch...@opensource.lk>.
Brian De Pradine wrote:
>
>>
>> I agree with you about your claim on invalid messages being sent by
>> Axis2, if that is happening now. If that is the case, we need to fix it
>> in the sending logic and not in dispatchers or message context.
>
> The issue here is not with the sending logic, but with the inbound
> processing logic. The WS-addressing final inbound handler must be able
> to understand that the absence of a was:To header, in a message that
> includes other mandatory ws-addressing headers, is semantically
> equivalent to the presence of the header,
> <wsa:To>http://www.w3.org/2005/08/addressing/anonymous</wsa:To>. Once
> this logic is available then the handler will be spec compliant, and we
> will be able to add the capability to omit optional headers.
messageContext.to will always be either of transport URL or the value of
wsa:To address. If you want to check the presence of a wsa:To header,
then you need to look it in the envelope and not in the message contecxt.
> As an alternative, there is an existing property called
> org.apache.axis2.Constants.Configuration.TRANSPORT_IN_URL that already
> holds the inbound transport URL. If some code wants to use the transport
> URL then maybe we should consider stipulating that the code must always
> use this property to perform the lookup?
On the other way round, if some one wants to look at the addressing To
value set it as a property to message context or look in envelope.
Presence of the above TRANSPORT_IN_URL is not a must.
But presence of messagecontext.to is a must.
-- Chinthaka
Re: [Axis2] Defaulting behaviour when a wsa:To header is omitted from a
request message.
Posted by Brian De Pradine <PR...@uk.ibm.com>.
Hi Eran,
Please see my comments included below ...
Cheers
Brian DePradine
Web Services Development
IBM Hursley
External +44 (0) 1962 816319 Internal 246319
If you can't find the time to do it right the first time, where will you
find the time to do it again?
Eran Chinthaka <ch...@opensource.lk> wrote on 25/11/2006 15:31:18:
> Hi Brian,
>
> Seems to be a good observation. I agree with some of them, but not all
:).
>
> The reason behind we keeping endpoint information inside message context
> has no direct connection with WS-A. All the information in message
> context can be filled by anyone, starting from transport handlers,
> through addressing handler till user handlers. Please do not understand
> that those information are only from WS-A headers.
You are correct when you say that anyone can change any of the properties
of the message context, and it is this very capability that is responsible
for this problem. Currently, the wsa:To message addressing property is
saved in the message context using MessageContext.setTo(), which delegates
to Options.setTo(). However, the HTTP transport also saves the transport
URL to that same location, by also using MessageContext.setTo(). Until
now, this has not been a problem as the was:To message addressing property
will simply overwrite the transport URL. The change that I want to make is
to simply extend this current behaviour, of overwriting the transport URL,
to the situation where the wsa:To message addressing property has been
omitted, and the default value for the wsa:To message addressing property
must be used.
>
> I agree with you about your claim on invalid messages being sent by
> Axis2, if that is happening now. If that is the case, we need to fix it
> in the sending logic and not in dispatchers or message context.
The issue here is not with the sending logic, but with the inbound
processing logic. The WS-addressing final inbound handler must be able to
understand that the absence of a was:To header, in a message that includes
other mandatory ws-addressing headers, is semantically equivalent to the
presence of the header,
<wsa:To>http://www.w3.org/2005/08/addressing/anonymous</wsa:To>. Once this
logic is available then the handler will be spec compliant, and we will be
able to add the capability to omit optional headers.
>
> Brian De Pradine wrote:
>
> >
> > 3) if ws-addressing is engaged, and there are ws-addressing headers in
> > the message, and one of them is the wsa:To header then it will be used
> > to determine the service.
>
> I don't think we can hard code a requirement like this in to Axis2.
> Admin of Axis2 will decide the order of dispatchers and depending on
> that one dispatcher will find the operation and the service.
>
> For example, one will use wsa:To to reach to an endpoint but some more
> information in SOAP action/request URI or QName of the first child of
> the body will be used inside the engine to identify the service.
It wasn't my intention to suggest that this was a strict behaviour of
Axis2, only that it will be the current behaviour if the administrator
decides to engage WS-Addressing with Axis2.
>
>
>
> -- Chinthaka
>
> [attachment "signature.asc" deleted by Brian De Pradine/UK/IBM]
As an alternative, there is an existing property called
org.apache.axis2.Constants.Configuration.TRANSPORT_IN_URL that already
holds the inbound transport URL. If some code wants to use the transport
URL then maybe we should consider stipulating that the code must always
use this property to perform the lookup?
Re: [Axis2] Defaulting behaviour when a wsa:To header is omitted
from a request message.
Posted by Eran Chinthaka <ch...@opensource.lk>.
Hi Brian,
Seems to be a good observation. I agree with some of them, but not all :).
The reason behind we keeping endpoint information inside message context
has no direct connection with WS-A. All the information in message
context can be filled by anyone, starting from transport handlers,
through addressing handler till user handlers. Please do not understand
that those information are only from WS-A headers.
I agree with you about your claim on invalid messages being sent by
Axis2, if that is happening now. If that is the case, we need to fix it
in the sending logic and not in dispatchers or message context.
Brian De Pradine wrote:
>
> 3) if ws-addressing is engaged, and there are ws-addressing headers in
> the message, and one of them is the wsa:To header then it will be used
> to determine the service.
I don't think we can hard code a requirement like this in to Axis2.
Admin of Axis2 will decide the order of dispatchers and depending on
that one dispatcher will find the operation and the service.
For example, one will use wsa:To to reach to an endpoint but some more
information in SOAP action/request URI or QName of the first child of
the body will be used inside the engine to identify the service.
-- Chinthaka