Article: Open Source WS Stacks for Java - Design Goals and Philosophy

Evaluate these implementations and you will notice several holes to be fullfiled, so you have to adapt yourself and build upon their limitations. Bottom line: open source WS stack != out of the box.

I'm a bit confused with how Spring-WS is positioned - does it aim to be a full WS stack with its own implementations of the WS-* specs? For example, I thought, for WS-Security it leverages the Sun XWSS implementation but the idea is to promote a simpler programming model with configuration based security interceptors to handle signing, encryption etc...did I miss something?

I'm not sure what you mean by saying 'holes'. It is obvious that none of the stacks implement all the WS-* specs that are out there (if specification compliance was the fact that you are referring to). Right now the WS spec space is maturing and there are some specs that are worth waiting for.
BTW what matters as the 'out of the box' functionality is what *you* expect to see as 'out of the box'. If you are a typical web services developer Axis2 will do most of the tasks out of the box (i.e. without making additional configurations). I'm sure CXF and other implementations are well versed in this as well. If you are looking for very specialized functionality then it is inevitable that you have to do some tweaking! (which does not imply that these frameworks are immature in any way)

I'm a bit confused with how Spring-WS is positioned - does it aim to be a full WS stack with its own implementations of the WS-* specs? For example, I thought, for WS-Security it leverages the Sun XWSS implementation but the idea is to promote a simpler programming model with configuration based security interceptors to handle signing, encryption etc...did I miss something?

I'm not sure what you mean by saying 'holes'. It is obvious that none of the stacks implement all the WS-* specs that are out there (if specification compliance was the fact that you are referring to). Right now the WS spec space is maturing and there are some specs that are worth waiting for.
BTW what matters as the 'out of the box' functionality is what *you* expect to see as 'out of the box'. If you are a typical web services developer Axis2 will do most of the tasks out of the box (i.e. without making additional configurations). I'm sure CXF and other implementations are well versed in this as well. If you are looking for very specialized functionality then it is inevitable that you have to do some tweaking! (which does not imply that these frameworks are immature in any way)

Stefan, this is a good interview; nice to see so many familiar names out there -I've met Dan, Paul and have had email discussions with Arjen and Tom ... Arjen's contract first design is definitely something I agree with.

One thing I want to question is Koshuke's claim that metro is the most widely "installed" toolkit. As it is in JAva6, it is out there pretty widely, but how common is it in use. Server side, Java5 support is still stabilising; I don't know how common Java6 is. It is out there on the client, but what is in Java 6 is a version that is stuck at the JAXP 2.0 level *forever*. Is that the version that has benefited from the ongoing interop work with Microsoft, or the version that predates this work.

-steve loughran

ps "I don't think anyone disagrees that data-binding is useful for many situations"
Ah, that would be me. I think its a misguided practise that creates long term interop problems. Data binding to the DB, yes, hibernate is wonderful. But trying to map java data graphs to and from XML trees, no. Adopt a decent XML model like Xom and embrace XPath access to the data structures.

Erik, You are jumping off to conclusions here. True that the current RM implementation (Sandesha) does in-memory queuing by default. However there are options for you to tie it into a database and unfortunately that option cannot be set as default because it requires a bit of configuration from the user.
If you look at WSO2 WSAS (wso2.com/products/wsas/) which is based on Axis2, Sandesha and a lot of other Web Services projects, it comes with a sophisticated management console that allows you to control these.

Again my point is that 'out of the box' means what you expect as out of the box. In your case you look for extended functionality like WS-RM and that when it does not do the persistent storage by default,you see it as a hole. How I see it is that when you drop in the Sandesha module, a given Axis2 instance becomes instantly compatible with RM enabled services/clients and that is sufficient to make it out of the box. As for persisting the messages it is a configuration option for Sandesha module. This is similar in cases like WS-Security where you have to configure the key stores before/after dropping in the Rampart module.

What I believe is that all these OS SOAP stacks have come a long way and are sufficiently mature. If you are to implement a SOAP based Web service solution today, I'm sure all these OS SOAP Stacks will come to the picture and compete with the proprietary solutions. This is a sure sign of being mature.

Re: databinding, I spoke to some of the developers about this in more detail -- the common thread seems to be that even though they don't like data-binding, it's their user base that simply demands it.

There seems to be a general (and justified) uneasiness about data binding on the part of the interviewees. However, there is data binding and there is data binding. In my opinion, the problematic variety tries to generate object code from XML or vice-versa. JAXB, ADB, XMLBeans, etc., belong to this category. However, there are tools like Castor and JiBX that do not adopt the approach of generating one from the other. Castor and JiBX start with *both* an XML document and a Java class and use a mapping file to wire elements and attributes together in very flexible ways. XML processing with JiBX is reportedly as fast as native RMI.

I believe that Service Contracts (expressed as XML schemas in the SOAP doc/lit style) and Java Domain Objects are both First Class Entities. First Class Entities are independently defined and should not be generated from any other entity. The Service Contract is independently negotiated between service providers and consumers. The Domain Model is how the service is actually implemented. Neither should be derived from the other. The JiBX/Castor approach respects this and does not attempt the tight coupling that results with the other data binding frameworks that try to *generate* one from the other.

I suspect that's why people don't like data binding. What they really don't like are ADB, JAXB and XMLBeans. They should look at Castor and JiBX. This non-generational data binding is a very good principle, ranking up there with contract-first design!

Regards,
Ganesh

Steve,

I share your point of view - "trying to map java data graphs to and from XML trees, no".

However I would go a step further - why map xml to hibernate value objects? Why not from xml to sql and from resultset to xml? xml schema is the defacto biz domain model - why duplicate it any level pojos or hibernate? In the end isn't a web service a set of transformations from client speak to physical and from physical to client speak through a canonical model (xml schema)?

I have done the above successfully using xquery. It turned out nice - metadata got separated and j2ee took care of transactions.

- radu marian

In the answer of question number three it is stated that WS-Security 1.0 and 1.1 is supported by CXF. But from what I can find from CXF's webpage, it only supports a part of WS-Security 1.0. I can't find any version information on there main page but they are using WSS4J to support WS-Security. WSS4J supports the following:

* OASIS Web Serives Security: SOAP Message Security 1.0 Standard 200401, March 2004
* Username Token profile V1.0
* X.509 Token Profile V1.0

And the following specifications are included in WS-Security 1.1:
* WS-Security Core Specification 1.1
* Username Token Profile 1.1
* X.509 Token Profile 1.1
* SAML Token profile 1.1
* Kerberos Token Profile 1.1
* Rights Expression Language (REL) Token Profile 1.1
* SOAP with Attachments (SWA) Profile 1.1

Have I missed something or am I right?

The new lines didn't work very well. So, here is an other try.

In the answer of question number three it is stated that WS-Security 1.0 and 1.1 is supported by CXF. But from what I can find from CXF's webpage, it only supports a part of WS-Security 1.0. I can't find any version information on there main page but they are using WSS4J to support WS-Security. WSS4J supports the following:



* OASIS Web Serives Security: SOAP Message Security 1.0 Standard 200401, March 2004

* Username Token profile V1.0

* X.509 Token Profile V1.0



And the following specifications are included in WS-Security 1.1:



* WS-Security Core Specification 1.1

* Username Token Profile 1.1

* X.509 Token Profile 1.1

* SAML Token profile 1.1

* Kerberos Token Profile 1.1

* Rights Expression Language (REL) Token Profile 1.1

* SOAP with Attachments (SWA) Profile 1.1



Have I missed something or am I right?