Re: [Axis2] Defaulting behaviour when a wsa:To header is omitted from a request message.

2006-12-06 Thread Brian De Pradine
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 <[EMAIL PROTECTED]> 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.

2006-12-01 Thread Eran Chinthaka
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,
> http://www.w3.org/2005/08/addressing/anonymous. 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




signature.asc
Description: OpenPGP digital signature


Re: [Axis2] Defaulting behaviour when a wsa:To header is omitted from a request message.

2006-11-28 Thread Brian De Pradine
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 <[EMAIL PROTECTED]> 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, 
http://www.w3.org/2005/08/addressing/anonymous. 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.

2006-11-25 Thread Eran Chinthaka
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



signature.asc
Description: OpenPGP digital signature