Stack independent addressing implementation

[asoldano]

This thread is about:
https://jira.jboss.org/jira/browse/JBWS-2106
and
https://jira.jboss.org/jira/browse/JBWS-2102.
Since the JAX-WSA spec is in withdrawn state, there's actually no spec saying how the ws-addressing advanced headers have to be set and retrieved.
JBossWS Native provides his own implementation in the jaxws-ext module; JBossWS-CXF has its own too (and uses package org.apache.cxf.ws.addressing), JBossWS-Metro doesn't support anything besides what's in the jaxws 2.1 spec.

A common way of setting the ws-a properties in the message and retrieving them would be useful, see the usecases Andrew wrote in the two jira issues above.
Any idea?

[asoldano]

Generally speaking I would see a common api living in jbossws-common. Then we should think about bridging from it to the underlaying stack implementation. Perhaps we could provide handlers doing the required conversions (to read/write the right objects in the MessageContext) and ask users to install them if they want to use the common api?

[ropalka]

First of all we need to keep in mind basic J2EE principle here Write once run everywhere. Thus proprietary api is always wrong approach from this point of view.
And because of wretched JAX-WS spec the first acceptable solution seems to be setting binding provider request properties and populating these properties to message payload via provided WS-A properties propagation JAX-WS handler.

[adinn]

First of all we need to keep in mind basic J2EE principle here Write once run everywhere. Thus proprietary api is always wrong approach from this point of view.

Well, I really want my WSTX implementation to be container-independent and the hope was that JaxWS would provide that independence in the transport layer. However, I have no choice but to use the WSA management API which lies outside the spec -- the WS-* transaction specs requires manipulation of addressing properties. In the absence of any definition from the specs I still need some API to code to and it it would be better if we could provide just one API.

If I were to build myself some facade classes to wrap around the CXF and JBoss WSA implementations of the WSA types I think I would still need to deploy stack-specific code at the interface to the stack (i.e. when I create addressing property values and when I install them or test for them on the client/server side of a connection). So, my code will end up being dual-image and deployment of my code will depend upon the WS deployment. Following this route seems doubly inappropriate in that the AddressingProperties classes are already facades.

Is it possible to deploy the javax.xml.ws.* interfaces in the CXF WS release but configure them to use the CXF builder classes to populate them? In other words to use the implementation provided by the underlying stack but make it available via the same API as the native WS release. If we do choose an API it would be better if it were located in the javax package (although, strictly, we are not supposed to pollute this namespace with our own definitions).

[ropalka]

We discussed this topic with Alessio and we have the following conclusions:

We'll try to discuss this problem with JAX-WS representatives. From our point of view the only correct way of addressing this problem is to update JAX-WS spec so it will include required WS-A abstractions. It already includes some abstractions from WS-Addressing specification i.e. EndpointReference. Thus question is why other abstractions from that spec aren't part of the API? We think they have to be there to don't confuse JAX-WS users and don't make them tend to write proprietary code for each JAX-WS stack they're trying to integrate with.