10 tips on how to prevent business value risk
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Article: Open Source WS Stacks for Java - Design Goals and Philosophy
Posted by Stefan Tilkov on Oct 04, 2007
In addition to the options offered by commercial vendors, there are a number of open source Java frameworks one can choose from. Among the most popular open source stacks for implementing a SOAP/WS-* based solution in the Java space are Apache Axis2, Apache CXF, Spring Web Services and Sun’s Metro.
Stefan Tilkov posed a number of questions to the lead developers of these stacks – Paul Fremantle (Axis2), Dan Diephouse (CXF), Arjen Poutsma (Spring Web Services), Thomas Diesler (JBossWS) and Kohsuke Kawaguchi (Metro) – about their design goals, their approach towards Java and Web services standards, data binding, accessing XML, interoperability, REST support, and framework maturity:
- Can you describe the main design goals of "your" framework? What do you perceive as its main strengths and unique features?
- What's your position on and the framework's support for JCP standards such as JAX-WS, JAX-RPC, JAXM, JAXB? Why is support for it included/not included?
- What Web services standards do you support, and why are those you don't support not supported (i.e. do you plan to include them later, not at all, ...)
- What's your position with regards to data binding and the problems many people associate with it? Do you support native access to the XML message, an XML/object mapping, or both?
- How well do you support interoperability with other WS implementations, particularly .NET/WCF?
- What is your position with regards to REST? Do you offer any kind of REST support?
- What is your framework's maturity? Are there any case studies you can point to, are there any commercial or open source products that rely on it?
As was to be expected, the results revealed many similarities and some noteworthy differences – see the full article for details.
- This article is part of a featured topic series on SOA
- See more SOA content at: http://www.infoq.com/soa
- Other recent content items in this topic
Open source WS stack not mature, yet!
by
Erik Bengtson
Posted
Re: Open source WS stack not mature, yet!
by
Ajith Ranabahu
Posted
Re: Open source WS stack not mature, yet!
by
Erik Bengtson
Posted
Re: Open source WS stack not mature, yet!
by
Ajith Ranabahu
Posted
Spring-WS and WS-*
by
Satadru Roy
Posted
Re: Spring-WS and WS-*
by
Arjen Poutsma
Posted
Just how ubquitous is Metro really?
by
Steve Loughran
Posted
Re: Just how ubquitous is Metro really?
by
Stefan Tilkov
Posted
Re: Data binding - a misguided practice
by
Radu Marian
Posted
Another good principle
by
Ganesh Prasad
Posted
CXF does not support WS-Security 1.1?
by
Kjell Winblad
Posted
Re: CXF does not support WS-Security 1.1?
by
Kjell Winblad
Posted
-
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?
Well, we generally try to reuse what is available and fits our requirement. So for supporting WS-Security, we indeed use XWSS from SUN, because it is based on SAAJ, and Spring-WS supports SAAJ as well. In other cases, we have no choice but to implement our own version of a WS-* spec, to make it a good fit in the Spring-WS programming model. -
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)
Just as matter of example and under a very common usage: WS-RM. You expect realible messaging, but if you take Axis2 implementation, messages lie in memory, so if you crash you loose your messages, thus not that reliable. Said this, I can conclude OS WS stack != out of the box. -
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?
12 comments
Watch Thread Reply