One of the current ongoing R&D projects at CATH is the development of a library of web services for both internal and external use. The first step in this process was the selection of a web service toolkit (or ‘stack’) to use, as there are several competing (and often mutually incompatible) frameworks available. This page compares some of them in brief based on some informal evaluations and background reading.
Note that I am far from being an expert in this field, so feel free to leave a comment if there’s anything here you disagree with. I am, as ever, happy to be corrected.
Also, please don’t get the impression that this is a methodical side-by-side comparison. I would have liked to implement the exact same non-trivial service in each stack, and report systematically on my experiences with each, but in reality I just didn’t have time to do it that rigourously. What I present here is the result of going through one or two tutorials (mostly of the Hello World/echo-a-string/double-a-number kind), reading the docs, hanging out on forums and garnering opinion from blog posts and articles. And the amount of time I spent with each toolkit is admittedly variable.
I hope it will be useful to someone, despite the caveats.
Andrew.
Background and assumptions
All of these toolkits are primarily for the development of SOAP web services, although some provide facilities for other paradigms too (e.g. REST or POX). In addition, they were evaluated from the point of view of top-down (contract-first) design, which is when a WSDL file and XML Schema are drawn up first, containing a description of the services available and their input-output formats. This is then used to generate code (more or less automatically) to handle the requests and responses at the client and/or server ends.
The opposite model, bottom-up (code-first), is very popular in the business world, as when the person writing the clients to access your services is in the same organization as you, internal standards and practices can be enforced at the code level and the actual service definitions can be a bit of an afterthought. Indeed it is relatively common for service or client programmers in this context to never even look at the generated WSDLs. However, there are good arguments for contract-first design, and all the more so when (a) you have to design services compliant with externally-imposed standards and (b) the clients accessing your services may be written using radically different toolkits, design philosophies or programming languages to your own. Much of the literature on the web relates to bottom-up design, and some of the claims made about different toolkits are only true of bottom-up projects, so caveat lector.
Also, there are two main competing service definition paradigms for web services, rpc/encoded and document/literal. Of these, the former is still only in widespread use in MOBY and in the Perl world, while the latter has become a de-facto standard elsewhere, particularly in its ‘wrapped’ dialect. (The details of the differences are beyond the scope of this introduction but there’s a good technical article about them here.) Document/literal is now becoming an ‘official’ standard too with its adoption by the Web Services Interoperability consortium. Therefore, all the frameworks below were assessed in the context of producing document/literal wrapped services.
There is a detailed (if slightly out-of-date) five-way interview with the lead developers/architects of Axis2, Metro, JBossWS, CXF and Spring-WS here. It discusses the design philosophies and architectures of these five frameworks, although it doesn’t cover subjective aspects like ease-of-use.
Axis2
This is an Apache project and largely unrelated to its predecessor Axis. It is a general-purpose implementation of SOAP web services which predates the now-standard JAX-WS model (see below). See: http://ws.apache.org/axis2/
Pros:
- Broad choice of databinding and deployment models
- Good community/developer support
- Code generation tools produce skeleton implementation classes as well as just interfaces
- REST/POX support requires little extra work
Cons:
- Broad choice of databinding and deployment models (!)
- Generated code seems to come in for criticism on the net
- JAX-WS/JAXB-style services supported but still a bit crude; tools only produce interfaces, not skeleton classes
- Error diagnosis can be awkward, requiring inspection of server logs
JAX-WS RI (Metro)
Sun’s ‘Reference Implementation’ of the JAX-WS standard, bundled alongside the GlassFish application server as part of the Java Enterprise Edition SDK. See: https://jax-ws.dev.java.net/
Pros:
- Sun are pushing it heavily = likely to be widespread adoption and good tool support
- JAXB databinding and generated code are elegant and easy to use
- Some of our collaborators use it already
Cons:
- The code generation tools require you to do a lot more work for yourself than Axis2′s, e.g. writing the implementation classes from scratch rather than from auto-generated skeletons
- The server/service configuration files are quite fiddly
- Together these mean that adding new services or changing the interface of existing ones is a bit of a hassle
- Error diagnosis can be awkward, requiring inspection of server logs
JBossWS
This is an implementation of the JAX-WS standard by RedHat and the JBoss community. Seems to work in a very similar way to Metro, similar advantages, same major disadvantage. See: http://www.jboss.org/jbossws/
I have to admit, I didn’t actually go much beyond installing this and reading the docs. If anyone has any practical experiences to share, please add some comments below! Thanks.
CXF
Formed from the merger of two older projects, Celtix and XFire, and has now been adopted by the Apache Foundation. Yes, this does mean that there are two entirely separate Apache web service platforms. Such is the bountiful joy of open-source.
Pros:
- Uses JAX-WS/JAXB natively, so compatibility and tool support shouldn’t be an issue
- Generates skeleton implementation classes as well as just interfaces
- Automatic generation of JavaScript client code, for testing or AJAX interfaces
- More meaningful error messages than Metro or Axis2
- Good community/developer support
- Adding new services/operations or modifying existing ones is pretty intuitive
- Support for REST via JAX-RS standard, and various other communication methods like JMS
Cons:
- Configuration can seem horribly complex — there’s almost too much flexibility
- Non-Spring-programmers may be intimated by Spring-based architecture (also see Spring-WS below)
Spring-WS
Spring Web Services is (obviously) the web services component of the Spring Framework, a popular application development framework that also provides useful facilities like configuration, transaction management, object-relational mapping, database abstraction, logging etc. See: http://www.springframework.org/
Pros:
- Integration with rest of Spring could be useful (although CXF also designed to facilitate this)
- Very firm (actually exclusive) focus on contract-first design
- Tool for constructing WSDL automatically from XSD (really contract-first)
- User can tie in support for various databinding technologies
Cons:
- Young compared to the other frameworks
- Additional learning curve for non-Spring-programmers
- No tools for generating Java classes/interface automatically from XSD/WSDL = more trivial hand-coding
- Document/message-centric model at odds with operation-centric (RPC-like) model used by most other frameworks — you get a blob of XML and can do with it what you want
N.B. The last of these disadvantages is actually, if you believe the Spring-WS team, an advantage after all. This is quite a persuasive argument, since you can plug in any of several unmarshalling (i.e. databinding) steps if you like, or just pull bits out of the XML tree with a parser (again there are several available). Your implementation then won’t be tied to any particular databinding object model, freeing you from the danger of ending up with incorrectly-generated classes or XSD structures that can’t be well represented in Java. Also in many cases you ought to be able to expect better performance this way, e.g. by using forward-only streaming. But it makes the endpoint classes more verbose and slower to create, which would be an issue if you’re providing a lot of services.
See the Epilogue below for more on this way of working.
Soaplab2
Largely developed at the EBI, and replacing the earlier Soaplab, Soaplab2 is a toolkit to enable wrapping of existing software in web service front-ends with the minimum of actual coding. See: http://soaplab.sourceforge.net/soaplab2/
Pros:
- Consistent access method across different back-end operation
- Server-side asynchronous functionality like status polling, job cancellation etc. is built in
- Provides web and command-line clients
- Creation of web services wrappers around existing programs is swift and usually doesn’t require any hand-coding
Cons:
- All Soaplab2 services are designed contract-first, but in ACD, not WSDL/XSD
- Doesn’t use XML Schema to describe input and output types (not in any useful sense)
- WSDLs contain no details of the actual underlying programs or their data requirements
Although it’s a powerful tool, Soaplab2′s approach to SOAP/WSDL is extremely unusual and seems, in a sense, to miss the point. The WSDLs and XSDs it produces don’t even attempt to describe the underlying processes — it just provides generically-named operations like createJob, run, destroy, getSomeResults etc. where the actual ‘service’ required (known as an ‘analysis’) is one of the parameters. Instead of listing these services in the WSDL and providing distinct SOAP endpoints to access them, it provides a list of available analyses via another web service. Elements tend to have non-descriptive names like arg0, arg1 etc. and parameters are generally passed in name-value pairs rather than proper typed data structures.
EDIT (13 Jan 2009): Apparently the Soaplab team have recently started working on ‘typed’ WSDLs (i.e. WSDLs how most other people use them) which may render some of these objections obselete. However, I don’t think they’ve actually released a new version yet which includes these.
Others?
These are all of the open-source options that I’m currently aware of. There are some commercial options around, but even some of these use open-source products under the hood (e.g. IBM WebSphere which is apparently Axis2-based).
Drop a comment if you know any different.
Conclusions
It is a shame that Soaplab2 web services have such a unique and quirky architecture, since its overall aim — enabling easy access to existing bioinformatics resources and tools — covers 90% of what we need web services for at CATH. However, taking the Soaplab2 option would enforce a certain amount of ‘vendor’ lock-in, since only Soaplab2-aware tools would be able to get the best out of the resulting services. For other clients, it would lead to an extra level of abstraction between the service consumer and the service. Rather than simply looking for suitable WSDL-based service descriptions in a registry, one would have to find every Soaplab2-based service and then query each one in order to find out what services it actually offered. The consequences for registry architecture of having some services fully described by their WSDLs and others with definitions hidden in Soaplab2 responses are not clear, but they can’t be good, and the same goes for consistent test suites and automatic service level monitoring.
It is also unclear how Soaplab2-based services would allow for semantic markup of the sort provided by methods like SAWSDL, since the same SOAP operation (e.g. createJob) could take parameters with any one of many different semantic types — sequence, accession number, structure, GO term, whatever — depending on what actual underlying process was being invoked. This would seriously reduce the potential for interoperability, automated service discovery and semantic data mining that could be provided by properly-specified services. One of the Soaplab2 developers claimed in June 2008 on the embrace-tech mailing list that ‘typed’ services were on the to-do list and would be ready in a matter of “weeks or months”, but this is apparently still a work-in-progress six months later, and of course we cannot be certain what form these will take when they do appear. EDIT (13 Jan 2009): This is apparently now being worked on, see above.
Looking instead at general-purpose web service stacks, I would consider Spring-WS if we already possessed in-house Spring expertise, since the focus on contract-first development is a good match for our requirements. Furthermore the Spring framework is very popular with Java developers and seems to provide useful solutions to a lot of common [web] application development problems. The lack of class generation tools could be problematic but is probably solvable with Ant tasks or even Perl scripts. However, the exhaustive feature list and broad compatibility of CXF, coupled with its good reputation on blogs and discussion fora, make it the best candidate available. And it offers Spring integration itself, meaning that should we wish to explore the capabilities of Spring later on, we will still have that option.
Epilogue
Having eventually gone for CXF, I quickly discovered that for performance reasons, our first Java web services project would need to use raw XML messages, rather than databinding to JAXB objects. Thankfully, it’s pretty straightforward to bypass the unmarshalling steps and just treat a SOAP message as raw XML, exactly like Spring-WS does. This is very useful if you want to produce high-throughput web services that process a large amount of data. Several of the services in the project use Oracle to output XML directly (up to tens of thousands of rows at a time) which can be injected into the body of a SOAP message by CXF, using a ‘payload provider’ service. Fast and simple.
I believe Metro also supports provider services, as well as the corresponding ‘dispatch’ clients for sending raw chunks of XML, as these are part of the JAX-WS spec — so this solution could also have been implemented with Metro. Although, having got my head around CXF’s complexity, I am still highly impressed by its flexibility as well as the quality of feedback from its developers and community. So I would have no qualms about recommending it again.