axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian De Pradine <>
Subject Re: [Axis2] Defaulting behaviour when a wsa:To header is omitted from a request message.
Date Tue, 28 Nov 2006 18:13:37 GMT
Hi Eran,

Please see my comments included below ...


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 <> 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></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?
View raw message