Invalid WS-A ReplyTo constant value used by WS-RM

[Aki Yoshida <sa...@googlemail.com>]

Hi,
There is an issue in the way how the current WS-RM implementation
downgrades the WS-A namespace/constants to the 2004/08 version. I
would like to first explain the problem and ask you which solution is
preferred.

CXF uses WS-A 2005/08 internally but for WS-RM, it uses the 2004/08
version because the older WS-RM (1.0)
requires the use of the 2004/08 version. So, it is correct to convert
the internally used 2005/08 namespace/constants to their 2004/08
counterparts.

However, one problem is that the 2005/08 WS-A spec defined two constants

http://www.w3.org/2005/08/addressing/anonymous
http://www.w3.org/2005/08/addressing/none

While the 2004/08 WS-A version seems to have only defined

http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous

and not

http://schemas.xmlsoap.org/ws/2004/08/addressing/role/none

The current conversion used in CXF creates this undefined value and
this is causing some interoperability issues.
More concretely, when the WS-A ReplyTo element is set to the none
value and this is serialized into the above undefined 2004/08 none
constant, it is not recognized by some systems. According to the WS-RM
1.0, in such a case, the ReplyTo element should be omitted to convey
this "none" value (as there is no "none" constant).

Technically, this is simple to fix and I tested my fix locally. But I
would like to hear if this is the preferred solution.

My solution was to introduce a boolean property "usingNoneAddress" to
the addressing configuration bean. If this property is set to false,
the above none constant is not serialized (i.e., the enclosing element
is omitted).

Alternatively, we can always omit serializing the elements containing
the above "none" constant without using any configurable option. But I
was not sure if someone is expecting this invalid "none" constant in
their "non-conformal" implementation. In this case, simply omitting
the elements may break their running scenarios.

Any feedback is appreciated.
Thanks.

Regards, aki

Re: Invalid WS-A ReplyTo constant value used by WS-RM

[Daniel Kulp <dk...@apache.org>]

On Tuesday 16 November 2010 11:21:27 am Aki Yoshida wrote:
..............snip....................
> Technically, this is simple to fix and I tested my fix locally. But I
> would like to hear if this is the preferred solution.
> 
> My solution was to introduce a boolean property "usingNoneAddress" to
> the addressing configuration bean. If this property is set to false,
> the above none constant is not serialized (i.e., the enclosing element
> is omitted).
> 
> Alternatively, we can always omit serializing the elements containing
> the above "none" constant without using any configurable option. But I
> was not sure if someone is expecting this invalid "none" constant in
> their "non-conformal" implementation. In this case, simply omitting
> the elements may break their running scenarios.

Hmm...    That's a good question.

If you omit it, do any of our tests break?

Honestly, I'd actually prefer a spec-correctness-by-default setup where it 
would be omitted normally, but maybe a setting to turn it back on in the case 
where someone has a non-conformant implementation.   I haven't looked at that 
code very well, is that something that seems easily doable?


-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog