Introduction
In addition to the options offered by commercial vendors, there are a number of open source Java frameworks one can choose from to implement Web services. 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, JBossWS and Sun’s Metro. I posed a number of questions to the lead developers of these stacks about their design goals, their approach towards Java and Web services standards, data binding, accessing XML, interoperability, REST support, and framework maturity. As was to be expected, the results revealed many similarities and some noteworthy differences.
I have split this article into two parts: first, I provide an overview of the questions and the highlights from the developers’ answers. Although I have done my best to keep the summary unbiased, the original answers are provided for reference (and for those interested in all of the details) in the second part.
The developers interviewed were Paul Fremantle (Axis2), Dan Diephouse (CXF), Arjen Poutsma (Spring Web Services), Thomas Diesler (JBossWS) and Kohsuke Kawaguchi (Metro):
Paul Fremantle is a co-founder and VP of Technical Sales at WSO2, a company that is a driving force behind a number of Apache projects. While at IBM, Paul created the Web Services Gateway, and led the team that developed and shipped it as part of WebSphere Application Server. Paul was a member of the team that put the Service Integration Bus technology into WebSphere Application Server 6. He also co-created the Web Services Invocation Framework (WSIF) and was co-lead of JSR 110 and OASIS WS-RX TC Co-chair.
Dan Diephouse is a software architect at MuleSource, the company behind the open source Mule ESB. Here he is focused on building and helping others build open source web services/SOA solutions. He is a co-founder of the web services framework Apache CXF, a founder of several other projects including XFire, SXC, and Jettison, and participates in several others whenever possible.
Arjen Poutsma is a senior enterprise application architect is the founder and the project lead for the Spring Web Services. This Spring project aims at facilitating development of document-driven web services. Arjen has also contributed to various other open source projects, including XFire, NEO and others. Since early 2005, Arjen has been a consultant for Interface21 (the company behind Spring) in The Netherlands.
Thomas Diesler is the Web Service project lead at JBoss and generally helps setting the technical direction at JBoss as a member of the Technical Board of Directors. As a member of the JCP, he helped to define various Web Service specification (e.g JAX-WS).
Kohsuke Kawaguchi is a staff engineer at Sun Microsystems has been working on XML and XML schema languages since 2001, including specification work on RELAX NG and W3C XML Schema, and implementation work in a number of related Java artifacts, including JAXB and JAXP. He is active at java.net as one of the original leads of the Java web services and XML community.
Part I: Overview
Design Goals
There are some design goals that are shared among of all of the stacks, such as extensibility, modularity, and performance. Axis2 is designed around an XML object model called AXIOM, a mixture of streaming and tree-based messaging, and provides pluggable data binding support; CXF supports pluggable transports, data bindings, and can even support alternative formats such as JSON. Spring-WS supports lots of different ways to handle XML, too – from XPath-based access to a number of XML APIs such as DOM, SAX and StAX to data binding approaches such as JAXB, Castor and XStream. Metro also features pluggable transports and encodings. Assuming all of these approaches have been put into practice and actually work as expected, it’s hard to see any major difference in this regard.
Paul Fremantle noted that Axis2’s architecture was designed to be implementable in both C and Java. He also highlighted Axis2’s module concept, which allows related collections of handlers to be deployed, together with libraries and data files, as a single unit. Dan Diephouse pointed to CXF’s embeddability as one of its key features; another aspect he noted was the focus on ease-of-use for the developer. Arjen Poutsma put strong emphasis on Spring-WS’s support for the “contract-first” style of WS development. Thomas Diesler pointed out that JBossWS can support both its own native stack as well as integrate with others, including CXF and Metro. Interoperability is listed by Sun’s Kohsuke Kawaguchi as a design goal for Metro.
JCP Standards
There are a number of standards for working with XML and Web Services in the JCP, most notably JAX-RPC, JAXM and their successor, JAX-WS, as well as JAXB (the JCP standard for XML data binding). Opinions start to differ when it comes to support for these standards within the different frameworks.
The Axis2 team made the explicit decision to support JAX-WS as a layer above the “minimal, clean API” that followed its own vision of what makes a framework “cool”. JAXB is supported both on its own and in conjunction with JAX-WS. Paul Fremantle dismisses JAX-RPC and JAXM as outdated and never much used, respectively. Dan Diephouse (and the CXF framework) share the opinion on JAX-RPC and JAXM, and CXF supports JAXB and JAX-WS, too. Interestingly, Diephouse considers JAXB to be “fast, very robust” and has found that it “will work with 99.999% of the schemas” he’s come across. He also points to his own SXC project as a way to considerably speed up JAXB. JBossWS supports JAX-RPC, JAX-WS and JAXB.
For obvious reasons, support for JCP standards is one of the most important goals for Sun’s Metro; as Kohsuke Kawaguchi points out, Metro includes the reference implementations of both the JAXB and JAX-WS JSRs. Arjen Poutsma explains that the programming model exposed by Spring-WS is very similar to that of JAXM in that it is a message-based programming model, and not “an RPC-like model such as JAX-RPC and JAX-WS”. Thus while JAXB 1 and 2 are supported, JAX-WS is not (as an explicit design decision, or so it seems). It seems that both Axis2 and Spring-WS don’t show much appreciation of JAX-WS, while only Spring-WS goes so far as not to include support for it.
Web Services Standards
All of the frameworks claim support for a common set of Web services standards which includes SOAP 1.1 and 1.2, WSDL 1.1, MTOM/XOP, and WS-Security. Axis 2 is the only stack supporting WSDL 2.0 (which is probably not surprising as WSO2 co-founder Sanjiva Weerawarana is one of the WSDL 2.0 editors). All except Spring-WS and JBossWS implement WS-Addressing and WS-Reliable Messaging (support for both WSDL 2.0 and WS-Addressing is planned for future versions of both). Metro is the only stack with support for WS-AtomicTransaction and WS-Coordination, which are hooked up to J2EE/Java EE transactions.
Data Binding
The topic of data binding, i.e. the mapping from XML to objects and back, often leads to intense debates among Web services and XML practitioners. Arjen Poutsma’s opinion (“Data binding […] might be very convenient, but opens the door to a whole range of interoperability issues”) is shared by many of the interviewees, but all stacks – including Arjen’s Spring-WS – support it due to simple user demand. All of them also offer support for direct XML access, usually via SAX, StAX, DOM; some additional options are available, e.g. AXIOM in case of Axis2, Aegis in case of CXF, and XPath for Spring-WS.
Interoperability (.NET/WCF in particular)
Paul Fremantle believes Axis2 to be one of the most interoperable stacks due to the team’s participation in numerous interop events, and points to interop tests for both individual standards as well as whole profiles. Dan Diephouse splits interop testing into three areas: Data binding (where CXF relies on the proven JAXB and Aegis implementations), WS-I Basic Profile support and WS-* interoperablity. CXF relies on its WS-I BP compliance, usage of frameworks such as WSS4J for security (also used by Axis2) and interop testing to ensure interoperability. Arjen Poutsma considers Spring-WS’s contract-first approach the best guarantee for finding and resolving interoperability issues early. According to Kohsuke Kawaguchi, interoperability with Microsoft products was one of the topics with a lot of management attention at Sun’s Metro project. According to Thomas Diesler, JBossWS developers participate in interop events, too.
REST Support
The question about the stacks’ support for REST took none of the developers by surprise, although the answers differed quite significantly. According to Paul Fremantle, Axis2 supports both simple XML over HTTP scenarios (which are often not RESTful) as well as “real” REST via WSDL 2.0’s HTTP binding. One area Axis2 does not support yet is hypermedia. (Personally, I’m skeptical about this assertion since WSDL 2 is still centered around the concept of an operation, which seems anathematic to REST from my point of view.) Dan Diephouse describes CXF’s support for both POX (plain XML over HTTP) as well as REST: the latter is done via annotations, similar to the approach taken by JSR 311. Arjen Poutsma concedes REST is an interesting alternative to SOAP, WS-* and POX, but Spring-WS does not support it yet. When it will do so sometime in the future, it the support will be based on the Spring Web framework. Kohsuke Kawaguchi declares his fandom for REST, but sees support for it as outside of Metro’s scope and points to Jersey, Sun’s JSR 311 implementation. Interestingly enough, Thomas Diesler points to Metro when questioned about REST support in JBossWS.
Framework Maturity
Not surprisingly, all of the developers claim maturity and production readiness for their respective frameworks. Axis2 and CXF are used in numerous other open source projects, Axis2 more so (and even in some commercial products such as IBM WebSphere). According to Arjen Poutsma, the fact that it took two years to get Spring-WS to version 1.0 is due to Interface 21’s high quality standards. Both Kohsuke Kawaguchi (for Sun’s Metro) and Dan Diephouse (for CXF) point to the history of their frameworks, which are rooted in JWSDP and XFire, respectively. Thomas Diesler notes that according to a survery, more than 60% of the JBoss customer base use JBossWS. Kawaguchi cleverly points out that the inclusion of components of Metro in the Java 6 JDK easily makes it the most widely installed toolkit.
Conclusion
It’s hard to come to any obvious recommendation by just looking at the answers provided by the different stacks’ developers. There definitely seems to be more in common, at least from looking at the goals, than there are differences: a focus on efficiency and performance, extensibility and pluggability, and choice for the developer. Axis2 and Metro support more of the WS-* standards than CXF, Spring-WS and JBossWS. While Axis2 tries to unify the “classical” WS-* style and the REST style, the others view support it either with a different programming model or not at all. Metro is obviously the one most influenced by JCP standards.
Wether one views this as fortunate or unfortunate – it seems the Java WS community will continue to have to choose for quite some time.
Part II: The Details
Below are the original questions I posed and and answers I received from the framework developers.
(1) Can you describe the main design goals of “your” framework? What do you perceive as its main strengths and unique features?
Paul Fremantle (Axis2): The primary design goal of Axis2 was to build a framework which was cleanly designed around XML, very highly performant and easily extensible to add support for various WS-* protocols. One aim was to take a strongly XML centric design point. That is, unlike other WS stacks, the Axis2 architecture does not treat XML as a hot potato to convert into an object as quickly as possible.
Rather, it treats XML as the natural data model to execute on, and allows us to ‘outsource’ databinding to best-of-breed open source projects. Pluggable databinding means we can work with JAXB, XmlBeans, our own simple model (ADB), or any third-party package.
AXIOM, our XML API, provides us with incredibly fast and flexible (a blend of streaming and tree-based) message processing.
Our “Module” architecture significantly improves the handler-based model of Axis1 and other systems by allowing related collections of Handlers to be deployed, together with libraries and data files, as a single unit. The module constraint system removes the need for manual handler ordering. Modules are engaged by either user configuration or by policy processing, and distributions can go from “bare” to “fully WS-* enabled” with the inclusion of a few files.
Both services and modules deploy easily as archive files or exploded directories. Configuration and control is enriched by a “scoped” context model - settings come from messages, operations, services, sessions, or the system as a whole, and are very easy to work with.
Our pluggable backends mean it’s easy to implement service adapters for JavaScript, EJBs, Databases or other implementations.
Another key design point was that we designed the architecture to be implementable in both Java and C. To the best of our knowledge we’re unique in having a complete native C implementation. We’ve already done PHP bindings of the C stack and are working on Perl and Ruby bindings and will be doing Python bindings as well.
Dan Diephouse (CXF): First, as an Apache project, we are based on a community model. This means I can not speak for all the developers or organizations involved in the project. So what follows are my opinions only!
In no particular order, some of the goals of our framework are:
Support for web service standards, where web service standards means SOAP/WS-*. We support a range of scenarios for developing services from a simple code first service with no annotations needed, to WSDL first services, to the JAX-WS APIs Provider/Dispatch APIs.
Ergonomics: Granted we aren’t perfect at it, but we really work hard to make CXF as easy to use as possible. Our APIs are designed to make the simple use cases trivial, and the hard use cases possible. We’ve also worked to create a great set of tools - including Maven/Ant plugins.
Embeddability: CXF is designed to be a component which is embedded inside an application. This application can be your own business application, an ESB, or an application server. For instance: Mule, ServiceMix, Geronimo, and JBossWS are some great public examples.
Spring Integration: Our Spring integration makes it easy to configure clients, servers, and transports inside an ApplicationContext.
Performance: The SOAP/XML portion of CXF is based on a streaming XML message model, which facilitates very fast XML processing and low memory usage.
Flexibility and Extensibility: One of the reasons CXF came into being is that we needed a very flexible and extensible framework. You can write new transports easily. You can add support for different bindings. We support non-XML formats such as JSON and Corba. It is all very pluggable and extensible.
Arjen Poutsma (Spring-WS): The main design goal of Spring Web Services is “to make the best practice an easy practice”. Contract-first service development (i.e. starting with the WSDL and XSD) traditionally has been a hassle. Spring Web Services aims to make this easier, for instance by generating the WSDL from a XSD schema.
Another unique feature of Spring-WS is choice, just like all of the products in the Spring portfolio. You can handle the incoming XML messages in any way you want to: by using low-level APIs such as DOM, JDOM, dom4j, XOM, SAX, or StAX, by using XPath expressions, or even by using one of the supported XML Marshalling mechanisms: JAXB 1 or 2, Castor, XMLBeans, JiBX, or XStream.
Thomas Diesler (JBossWS): JBossWS is a framework for plugable web service stacks in the jboss application server. Currently we support our native stack, Sun Metro, and Apache CXF. See here
Kohsuke Kawaguchi (Metro): One of the primary design goals of Metro was the performance. We've done one iteration of web distributed technologies (CORBA, JAX-RPC 1.0 and JAXB 1.0, among other things), so we knew for the first-hand that what slows them down, and how to fix them. Those expertise and experience is put into designing Metro, and I think this is showing. Another part of the performance goal is to provide additional proprietary API for those few (often framework developers) that really need to get the maximum juice out of it. A good example of this would be our asynchronous implementation — it’s not easy enough for typical developers, but for example OpenESB guys take advantage of this to achieve great scalability.
Another design goals of Metro is the extensibility. Again, we had experience under our belt with our previous generations of technologies, so we knew what are the kind of places where additional abstractions are useful. This includes things like transport and encoding abstraction. We used them to implement FastInfoset support and JSON support, which broadens the applicability of Metro, as well as different transports like JMS, SMTP, and in-JVM local transport. In many places we were also able to design our abstractions to facilitate better performance, too. These extensibility was a key for us to implement a large number of WS-* specs in a modular fashion.
Interoperability is another important goal. Also in practice this is more to do with the hard and diligent testing work, rather than designing work. We went through a number of interop workshops with different vendors, we held regular meeting with our engineers and Microsoft engineers to discuss issues, and we even invited a Microsoft guy to JavaOne keynote to show our interoperability. We run interop tests nightly and monitor results. So that's how serious we are about the interoperability.
Last but not least, ease of use is another important goal for us. Again, this has more to do with attention to the details, rather than designing. We feel that the loss of productivity most often comes with the difficulty in trouble-shooting some problems. For example, how many of you have an experience spending hours googling trying to look for a solution for a particular problem? So we put a lot of efforts into doing a good error diagnostics and reporting, putting debug and logging switches to let you and us figure out what's going on, etc. The other important pillar for ease of use is good user support experience and docs. We also provide paid support for Metro through several different channels.
I don't know if any of them are unique, but I think the combination of them makes Metro a very solid web service stack.
(2) 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?
Paul Fremantle (Axis2): From the get-go Axis2 was designed to have a minimal, clean API that would really take advantage of the particular things that make our framework cool - scoped contexts, the AXIOM streaming XML model, Module-based extensibility, etc. We also wanted to ensure Java 1.4 compatibility, and had already had some experience with slowdowns and delays around TCK certification. So we decided to support JAX-WS (which requires 1.5) - but as a plugin layer above the base. We also fully support JAXB, either on its own or with JAX-WS, as a pluggable data binding. This allows us both standards support and independent evolution of our own APIs. We decided JAX-RPC wasn’t worth it since JAX-WS has supplanted it, and JAXM was never much used. We also realize that the JVM isn’t just for Java. We’ve done a lot of work on supporting JavaScript services, and we plan to work on bindings into other JVM languages such as JRuby and Groovy too.
Dan Diephouse (CXF): JAX-WS: We support the JAX-WS 2.0 standard and are busy implementing the 2.1 standard now as well. I view the JAX-WS as very important for two reasons. First, it makes it relatively easy to build web services and clients. Second, because it is a standard, there is a large growing pool of developer knowledge out there on how to use it. This means you as a developer don’t have to spend time learning proprietary APIs or (many of) the ins/outs of a new framework
JAXB: JAXB is also an important JCP standard; for the same reason JAX-WS is: it makes it easy to build services and there is a large body of knowledge out there on how to use it. As an added bonus, the only JAXB implementation out there is very good. It is fast, very robust, and will work with 99.999% of the schemas that I’ve come across. On this last point - you can compare this with ANY other framework, with the exception of possibly XMLBeans, and JAXB will come out ahead.
It does have some annoyances though: you often need to create jaxb.index files, it creates elements in the default namespace by default, and it isn’t as fast as it possibly could be. Regarding the last point, we’ve worked on addressing this via the SXC (http://sxc.codehaus.org) project which provides compiled readers/writers for JAXB beans. This gives JAXB a substantial performance boost.
JAX-RPC: We don’t support JAX-RPC. It is a very outdated standard of very little use if you’re developing a new service. While we’ve discussed adding support for JAX-RPC to help people migrate off from older frameworks, it would provide very little marginal value with a high amount of work on our part.
JAXM: We don’t support JAXM either. Its an older standard which hardly anyone uses. Additionally it seems superseded by JAX-WS.
Arjen Poutsma (Spring-WS): The programming model provided by Spring Web Services is very similar to that of JAXM, i.e. it is a message-based programming model, and not an RPC-like model such as JAX-RPC and JAX-WS. Furthermore, Spring-WS supports SAAJ, the SOAP message abstraction that has been part of J2EE since 1.4, but makes it more developer friendly. For instance, the checked SOAPExceptions thrown by SAAJ are wrapped by runtime exceptions.
Finally, JAXB 1 and 2 are supported by the Object/XML Mapping abstraction.
Thomas Diesler (JBossWS): We support JAX-WS, JAX-RPC, JAXB. In our opinion JAX-WS supercedes JAXM. We have hence no support for JAXM.
Kohsuke Kawaguchi (Metro): Pieces of Metro is available individually as they often have broader applicability than just web services, and these pieces include the JAXB RI, JAX-WS RI, and SAAJ RI, among other things. For those of you who are not familiar with JCP jargons, the RI status means that they are used as one of the exit criteria of a JCP spec, and we can't ship them unless it passes all the compatibility tests (called as TCKs.) This process usually makes the RI most conforming implementation of the spec. So as you can see, Metro takes compatibility very seriously. We even run TCK tests at least nightly, in some cases continuously to detect any compatibility regressions. So for us, it's a part of the development process, not just something we run at the end of a release cycle.
Some other web services toolkits don't place as much emphasis of JCP standards as we do, but I think compatibility is good for users in many ways. For example, it creates a level playing field for competition, it helps avoid a vendor lock-in (thus reducing the risk of you choosing one toolkit and be stuck with it), but more importantly to me, because it creates a bigger ecosystem thanks to a larger user base. A bigger ecosystem makes many things economically feasible that are otherwise impossible, and this encompasses everything from books and articles to training and tools.
We still offer proprietary APIs in many places, but because of these reasons we continue to stick to standards wherever make sense.
(3) 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, …)
Paul Fremantle (Axis2): Axis2 is itself primarily about XML and SOAP message processing, with support for SOAP1.1 and SOAP1.2, and includes a variety of transports (HTTP/S - including Non-Blocking IO, JMS, TCP, SMTP/POP, XMPP). MTOM is supported out-of-the-box, as are WSDL 1.1 and 2.0, WS-Addressing and WS-Policy. We also support pluggable encodings including FastInfoset and JSON. Higher level specs are all supported via pluggability, and we think that’s particularly important for embedded applications where not every spec is needed. We have plugins for WS-Security (1.0/1.1), WS-SecureConversation and Trust, WS-ReliableMessaging (1.0/1.1), WS-Transactions, WS-MetaDataExchange, WS-Transfer, BPEL (Apache Ode), WS-Eventing, and WS-RF/Notification (Apache Muse). Support for other specs can easily be added by our team or others as they become needed.
Dan Diephouse (CXF): We support:
- SOAP 1.1, 1.2
- WSDL 1.1
- WS-I BasicProfile 1.1
- WS-Addressing 2004/08, 1.0
- WS-Policy
- WS-ReliableMessaging 1.0
- WS-Security 1.0, 1.1
We’re hoping to support WS-SecureConversation and WS-Trust soon as well.
There are of course many others out there. Many are unimportant or worthless (you may feel that all of them are, but thats another story!), so we’ve focused in on the ones that we’ve heard from our users about. If you feel you are missing support for an important specification, please send an email to us (http://incubator.apache.org/cxf/mailing-lists.html) so we can look at including it in a future release.
Arjen Poutsma (Spring-WS): Obviously, Web services should primarily concerned with interoperability, but a surprisingly large number of these specifications are not interoperable at all. That means that there are implementations in Java, and perhaps .NET, but not in scripting languages such as Ruby, Python, or Perl. Therefore, we try to take a very pragmatic approach when it comes to implementing WS-* specification, and only implement those which add value, or which have sufficient user demand.
That said, Spring-WS currently supports SOAP 1.1 and 1.2, WSDL 1.1, MTOM and it has a WS-Security implementation that integrates with Spring Security. For the upcoming 1.1 release, we plan to implement WS-Addressing, and WSDL 2.0.
Thomas Diesler (JBossWS): See here. We expect to support more WS-* standards through the Metro/CXF integration. Currently we are also working on native WS-RM support.
Kohsuke Kawaguchi (Metro):
The thing I hate about web services is that there are way too many specs involved. But anyway, starting with basic easy ones, we use WS-I Basic Profile 1.1 as the base line, so WSDLs we publish and consume conform to WS-I BP. For handling large binary data / attachments, we support WS-I attachments profile 1.0, and MTOM/XOP. We also support the entire WS-Addressing 1.0. We even offer improved programming model that takes advantages of WS-Addressing. WS-MetadataExchange support and WS-Policy is also in Metro, which are more or less transparent, but nonetheless important part of making stuff work transparently.
Metro includes WS-ReliableMessaging support for reliable in-order message delivery when intermediaries are involved. It supports WS-AtomicTransaction as well as WS-Coordination. These are hooked up to JavaEE transaction so you can use this to do a declarative distributed transaction that across multiple JavaEE systems and .NET systems without knowing much about the gory details of these on-the-wire protocols.
On the security side, Metro comes with WS-Security, WS-Trust, and WS-SecureConversation. These specs address different needs spanning from simple message-level security to more complex federated authentication that spans across different organizations. All the security, transaction, and reliability features are done under the name of WSIT (AKA Tango project), which we invested significant resources into.
Even though we implement all these specifications and they do come out of the box, there are several things we paid particular attention to. First, we work closely with NetBeans team so that there's always an accompanying NetBeans plugin, which lets you configure those modules through a nice GUI. This protects you from the gory details of how the underlying system configures these specs. Second, this whole thing is pay-as-you-go model, in the sense that you don't pay the performance, complexity, and cognitive penalty of features that you don't use.
Finally, the same modularity allows us to implement other and future WS-* specs, if the user demand the efforts justify doing so. So please let us know what you'd like us to be supporting, if you feel that the list is not adequate.
(4) 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?
Paul Fremantle (Axis2): Axis2 was deliberately designed to support a flexible data-binding model including native XML access to the message. Axis2 supports a wide variety of data-binding toolkits including JAXB, XMLBeans, JIBX, ADB (built-in data binding), and the approach is extensible to any data-binding toolkit - especially if the toolkit supports the StAX standard. If the user chooses direct access to the XML, then Axis2 offers a tree like model (Axiom) as well as the StAX stream, and simple utility classes offer DOM and SAX interfaces as well. We believe that data binding use-cases are very important, and that Java coders should be able to use Web Services with a Java model if they want to, and XML coders should have fast, effective access to the XML if they want to. We think we’ve found a good middle ground which allows both the Java-heads and the XML-heads to be successful with Axis2. Dan Diephouse (CXF): There is this idea out there that data-binding is simply taking XML and making POJOs, but I’d like to enlarge this definition to “any type of processing which hides or removes the original XML infoset.” 99.999% of applications will need to do this - whether they are using JAXB, accessing an XML DOM by hand, or using something like XPath - they will need to extract the data and do some business logic with it. The only applications that won’t need to do this are the ones that end up working with XML as their only datamodel.
Looking at it this way, we can chose a databinding based on our answer to the question: what is the best balance of ease of use and retention of the xml infoset? The answer is “it depends.” I feel that for most applications, JAXB hits the sweet spot. It is very easy to use as it creates very simple POJOs. It hides many of the mundane/error prone XML processing tasks from the user. It works with most, if not all, schemas. And, if you follow proper schema versioning practices, you will end up with a very robust, long lived service which adheres to your contract.
We do support several other ways of databinding though. You can access the raw XML streams via the “StAX databinding.” There is also the Aegis databinding inherited from XFire which makes it easy to build schemas/WSDLs from just about any code. It has support for a lot of alternative datatypes like Maps or java.sql.Date. We have support for JAX-WS Providers which allow you to work with the XML messages as Source objects. We are hoping to provide XMLBeans and JiBX support for our next release as well.
Arjen Poutsma (Spring-WS): Data binding, or Object/XML Mapping as I prefer to call it, might be very convenient, but opens the door to a whole range of interoperability issues. The fact is that the Java language and the XML language are quite different, and whenever a conversion occurs between the two, something can go wrong. Take for instance the difference between an XSD date and java.util.Calendar. Typically, an XSD date “2007-09-14” will be converted to a Calendar that represents 14th September, at midnight in the local time zone. If that Calendar is converted back to XML, you will not end up with the same XSD date that you started out with, but probably a dateTime.
But as I said earlier, OXM can be very convenient. So Spring-WS supports it, in the forms of JAXB 1 and 2, Castor, XMLBeans, JibX, and XStream, but also provides access to the raw XML message if you need to.
Thomas Diesler (JBossWS): We have a notion of a SOAP content element, which is a abstract view of the message parts relevant to data binding. Client code can natively obtain content as XML (DOM), Java (JAXB), or SAAJ.
Kohsuke Kawaguchi (Metro): I don't think anyone disagrees that data-binding is useful for many situations, so of course we offer a data binding solution in Metro. Similarly, I don't think anyone disagrees that access to raw infoset is useful in many other situations, so again obviously we provide that in Metro. OK, so first about data binding. Metro uses JAXB as the data binding solution, which is still to this date the only annotation-driven POJO data binding solution. The use of annotations allow us to support both contract-first and code-first data binding in a single data binding solution, which is something that cannot be said about every data binding technology. Concentrating primarily on JAXB allows us to use our project resources efficiently, as opposed to fragment our developers and users into multiple silos for each data binding technology.
Now, the problem with a data binding technology like JAXB is that you lose the access to XML infoset. While it's a feature in certain situations, this becomes problematic in certain other situations, such as when your processing code is layered, when a web service is really just used as a transport layer, or maybe when you have your own domain specific data binding scheme.
So to this end, Metro offers access to the raw XML infoset through JAX-WS. You can access the entire SOAP message or just the payload part (which is convenient if you are plugging Metro with another data binding technology.) You can access it in a DOM like tree structure by using SAAJ, you can access it as SAX events, or you can access it by a StAX parser.
Speaking of the raw infoset access, we are also working on exposing our efficient internal SOAP message abstraction to you, so that you can access the SOAP message in even more convenient & efficient way.
I guess the other thing that's worth mentioning is that through the mechanism called handlers we allow you to combine both. That is, you can access the SOAP message as infoset first to do a few things, then do the data binding and do something else.
(5) How well do you support interoperability with other WS implementations, particularly .NET/WCF?
Paul Fremantle (Axis2): Our team has participated in interop events with the W3C, OASIS, and Microsoft, and we pride ourselves on a good interop test record. We try to fix all interoperability-related problems as quickly as we can, whether by fixing our own bugs or working around those in released versions of other implementations. As well as the individual interops for specific standards, we’ve worked a lot on interop with .NET/WCF for some particular profiles - especially Secure Reliable with Binary (MTOM, WSRM and WSSecurity together). Based on our testing we believe we are one of the most interoperable stacks.
Dan Diephouse (CXF): There are three levels of interoperability testing that matter to you as a user:
Databinding: The JAXB and Aegis implementations have been well tested with .NET/WCF over many years. I believe both are around 4 years old now.
BasicProfile/SOAP: At this level we’re concerned with ensuring that we’ve followed the assertions and best practices laid out in the BasicProfile standard. If you follow these guidelines you’re pretty much guaranteed good interoperability with other frameworks like .NET/WCF. But we also test our services with .NET/WCF - especially around the harder interopability areas like MTOM.
WS-: Each of the WS- specifications has its own ins/outs, so the story here will vary depending on the specification, its longevity, and its complexity. For instance WS-Security, we use Apache WSS4J framework which has been tested extensively with .NET by the community and many organizations who build products using it. Members of the community, notably IONA, also perform integration testing with WCF at various points during the release cycle. This tests not only the WS-* level, but all the lower levels as well.
Arjen Poutsma (Spring-WS): One of the advantages of the contract-first approach of Spring Web Services is that interoperability issues with other platforms can be directly resolved by the service developer. This means that you don’t have to “persuade” the SOAP engine to use one particular XSD construct instead of the other, because it does not interoperate with the .NET platform. Rather, you can choose the interoperable construct directly.
This approach is illustrated by the sample applications that ship with Spring-WS. These samples show interoperability with Microsoft .NET 1.1, WSE 2.0, and WCF.
Thomas Diesler (JBossWS): We regularly attend the the MSFT interop workshops and actively maintain a number of interop endpoints (http://jbossws.demo.jboss.com:8080/interop/ and http://jbossws.demo.jboss.com:8080/jbossws/services)
Kohsuke Kawaguchi (Metro):
Metro has a large dedicated team of people whose entire job is to ensure interoperability with .NET. As I wrote earlier, the truth is that interoperability is not something you can simply achieve by doing the right design. Rather, it's a result of tireless diligent hard work of the testing guys. Again, most of the work is done as a part of WSIT effort and now an integral part of Metro.
So in Metro, we set up a series of tests for each WS-* modules and constantly run interop testing with Microsoft endpoints. This is at least run nightly to ensure no regressions, and it's one of the release criteria we have — we won't ship Metro unless all the tests pass.
We've been working very closely with Microsoft. There was a weekly manager-level meeting to discuss various issues, with all kinds of engineer-level meetings to hash out and resolve issues. Many of us have been to Redmond multiple times to attend interop workshops. We even invited a Microsoft guy to our JavaOne key note session and demoed our interoperability.
We also pay particular attention to interop related issues with other Java and non-Java toolkits, although I don't think we are hearing too many of them. We also tend to be very forgiving when it comes to accepting broken inputs, and more strict about what we produce, which also improves the chance of smooth interoperability.
All in all, I think it's fair to say we spent a real effort in ensuring interoperability. And thanks to all the hard work of W3C, WS-I, and testing guys of all the web service toolkits, the overall interoperability situation of web services came a long way, and it’s showing.
(6) What is your position with regards to REST? Do you offer any kind of REST support?
Paul Fremantle (Axis2): There are multiple levels to supporting REST. Firstly we have a simple approach that allows developers to do “Plain Old XML” over any transport, including HTTP GET as well as POST. It works out-of-the-box with POJOs, so simple XML/HTTP scenarios are easy. Secondly, we are the only WS toolkit to fully support the WSDL 2.0 HTTP binding. Using that binding, one can fully describe pretty much any RESTful service - for example, we’ve done a complete description of Atom Publishing Protocol with that. So at the level of dealing with URIs, getting data in and out of the URI, supporting all HTTP operations, getting data in and out of the payload, we are now fully REST compliant.
The one area of REST we haven’t attacked yet is known as “hypermedia as the engine of application state”. That is, we do not offer any framework support right now for dealing with creating messages that have links and for properly dealing with those links. That (admittedly hard!) problem is left entirely to the application author. There’s been a lot of conversation about this and we expect to experiment more in a RESTy direction in the future.
Dan Diephouse (CXF): I believe that REST is a great way to build services. As an architecture it has a lot of power, but unfortunately it is often mis understood or not understood at all.
CXF has several tools to help you build RESTful services. We have an XML over HTTP binding which allows you to turn your SOAP web services into simple Plain Ol’ XML services. We support using annotations and URI templates like @HttpResource(“/foo/{bar}”) to map service operations to resources. We also support a convention based mechanism whereby your service will be introspected an intelligently turned into resources. For instance, a method like getPurchaseOrder(long id) will intelligently be mapped to a GET request on the resource /purchaseOrders/{id}. There is also some work and discussion going on surrounding the JSR 311 specification.
Arjen Poutsma (Spring-WS): I think REST is an interesting alternative to SOAP, WS-*, and Plain Old XML (POX). It solves a lot of problems of the WS-* space by basing itself on HTTP, a proven technology. However, I think that REST is just as, or even more restrictive than SOAP is. When writing a REST service, you have to have a clear idea about the resources that are to be exposed , which data formats you support for them (REST is not just about XML!), which HTTP methods you support on them, and what they mean. All of this has to be clearly documented as well; the HTTP specification isn’t enough for this purpose, and I am not sure if WADL is the answer.
Spring Web Services does not support a REST programming model at this moment, but it will be added in the 2.0 release, to be released early next year. REST is very different from SOAP and POX, for instance, there is no XML message coming in at all time. We don’t want to support REST by creating a XML message from an HTTP request, shooting that into the pipeline where three milliseconds later it gets parsed again: that’s simply too expensive. Instead, we will base the REST support on the Spring Web framework.
Thomas Diesler (JBossWS): We actively participate in JSR 311 and support REST via the Metro integration.
Kohsuke Kawaguchi (Metro): Personally, I'm a big fan of REST. Some of my other projects (like Hudson) is entirely REST based. But the problem I have with REST is that, just like any new technology, users often have different understanding of REST, so when they say "do you do REST?" we need to be careful about what we say (as a case in point, how many of you have heard about someone saying "I did my RESTful XYZ" and others yelling that is not REST?)
As we consider REST to be an emerging technology, the current REST support work is going on in our sister project Jersey. Jersey embraces REST to the heart's content, even if it means breaking away from the traditional programming model of Metro. I think this is the right thing, because if you take REST to its logical consequence it's really a different programming model. Just adding some REST like features (such as URI templating) to existing SOAP programming model in a piece meal fashion just wouldn't cut it. This also works nicely for those users for which the primary attraction of REST is to get away from SOAP complexity.
Going forward, however, I think we'll be spending efforts into bringing Jersey as a part of Metro. I think it's going to be interesting to see whether we can bring in some kind of integration and unity between SOAP and REST programming model, or whether they'd really remain substantially different.
(7) 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?
Paul Fremantle (Axis2): Axis2 is definitely production ready. We do regular soak tests, memory usage and performance tests. You can read some of them here: http://wso2.org/library/588.
Axis2 is used in many other frameworks and products including: Eclipse WebTools Project, Apache Geronimo, Apache Tuscany, Apache ODE, IBM WebSphere 6.01, SoapKnox, Apache Synapse, WSO2 Web Services Application Server, WSO2 ESB, Intalio BPMS, and many others.
Dan Diephouse (CXF): CXF has a long history. It is based in XFire which started 4 years ago and in Celtix which started several years ago as well. There is a lot of code which has been inherited from both these projects, which has helped create a stable/mature project. While we have bugs still, we believe in doing releases often and keep a tight feedback cycle with our users. We released our 2.0 release in July and are releasing 2.0.2 soon.
I’ve seen CXF go into several deployments (which unfortunately I can not talk about due to confidentially). There are also a lot of open source projects which have integration with it. Mule (http://mule.codehaus.org) has a CXF connector which MuleSource supports commercially. ServiceMix (http://incubator.apache.org/servicemix) has CXF integration as well which IONA supports via their bundling of ServiceMix/CXF called FUSE. Guillaume Alleon has created a Groovy Web Services (http://docs.codehaus.org/display/GROOVY/GroovyWS) project project which makes it possible to build services using Groovy and invoke services with no WSDL->Code step. I believe several other projects are busy migrating from XFire to CXF as well, like Enunciate (http://enunciate.codehaus.org).
Arjen Poutsma (Spring-WS): In August, we released Spring Web Services 1.0. Before this release, many people were using the milestones and later the release candidates, and were quite satisfied with its stability. The fact that it took us two years to get to the 1.0 release is due to the high standards of quality that Interface21 has. At the end of the year, we plan to release 1.1. This release will bring support for additional transports (JMS, email, and others), and will add support for WS-Addressing. Spring-WS 2.0 will bring support for REST services.
Thomas Diesler (JBossWS): The JBossWS offering is very mature with 2.5 years of ongoing development. According to a survey more than 60% of the JBoss customer base uses JBossWS.
Kohsuke Kawaguchi (Metro): We have changed the name, but a good portion of the code dates as far back as 2001 and Java Web Services Developer Pack (JWSDP), which won several awards including 2005 "web service or related tool of the year" and 2006 JDJ Reader’s Choice awared, and it's essentially the same team that's running the show since then. So there are significant chunk of code that's proven by years of use in the real world, maintained by people with significant experience in those code. The JAX-WS specification, which is the heart of Metro, also goes back quite a history, if you include its predecessor JAX-RPC. It's started 2001, and in this industry 5 years is a really long time. So there again, we have a proven technology built by feedbacks from vendors and users alike.
Then there’s JAXB. I’ve done much of the RI work and now also doing the spec, so I can tell you a lot about how ubiquitous the JAXB RI became. As a case in point, I think all the other web service toolkits discussed here supports the JAXB RI. When you have that level of adoption with more than 10 releases since JAXB 2.0 under our belt, the code becomes rock solid.
On maturity, I guess the other thing we can talk about is the amount of testing that it goes through, which is one of the strength of having a large organization like Sun backing a project. First, each component in Metro goes through a series of testing (normally 3, called unit tests, SQE tests, and TCK tests.) For example in JAXB, we have 1500+ unit tests, 220+ SQE tests, and 5700+ TCK tests. Once the components are integrated into Metro, the whole thing goes through additional testing. This includes interop tests and end-to-end container tests on more than 80 different platform configurations. We even have a cluster of machines dedicated for testing Metro. As we get integrated into JDK and GlassFish, they are running their own tests against Metro, too.
Tests of this magnitude doesn't come in one day — it's only made possible by a long history of our project and several teams of multiple engineers dedicated to writing and running tests in repeated, automated fashion. Again, it's not something the users of Metro would see, but that's the kind of things we do behind the scene to deliver a quality software to you.
Speaking of adoption, Metro is used by a variety of other projects. A subset of Metro is used in most application servers today, including GlassFish, WebLogic, WebSphere, and even in Geronimo. It's used as one of the transport component in OpenESB, as well as its commercial offering Java Composite Application Platform Suite. A similar subset of Metro is also used in all the major Java6 JDKs from Sun, BEA, and IBM. This alone makes Metro the most widely installed toolkit, easily by an order of magnitude.