[jbossws-dev] [Design of JBoss Web Services] - Re: Stack independent addressing implementation

adinn do-not-reply at jboss.com
Wed Feb 11 04:19:05 EST 2009


anonymous wrote : 
  | 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).


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208897#4208897

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208897



More information about the jbossws-dev mailing list