Axis2 vs CXF vs Metro

Capabilities

Both Axis2 and CFX also evolved from existing projects. Axis2 came from the well known Axis 1.x series. CXF is literally the offspring of the XFire and Celtix projects, as those two projects have pooled their codebases and development teams to give rise to CXF. The delta between the old projects and their new versions is significant in each case. Axis2 is a total rewrite of Axis from the ground up, using a new modular architecture that allows its functionality to be more easily extended. CXF has also been extensively retooled from its Xfire and Celtix origins. Both Axis2 and CXF provide migration guides that give developers tips on how to migrate from their previous versions, but as of this writing neither project has provided migration tools or guides for porting web services from one framework to another. In such a migration, though, it’s always worth looking at all the options available. Axis2 and CXF each take different approaches to web service development and these approaches will appeal more to some developers than others.

CXF: has support for WS-Addressing, WS-Policy, WS-RM, WS-Security, and WS-I BasicProfile. Axis2 supports each of these except for WS-Policy, which will be supported in an upcoming version.

CXF was written with Spring in mind; Axis2 is not.

Axis2 supports a wider range of data bindings, including XMLBeans, JiBX, JaxMe and JaxBRI as well as its own native data binding, ADB. Note that support for JaxME and JaxBRI are still considered experimental in Axis2 1.2. CXF currently supports only JAXB and Aegis; support for XMLBeans, JiBX and Castor will come in CXF 2.1.

Axis2 supports multiple languages — there is a C/C++ version available in addition to the Java version.

In comparing these frameworks, though, it’s just as important to look at their approach to developing web services as it is to compare features. From a developer perspective, both frameworks behave very differently from one another. Axis2 has taken an approach that makes it in many ways resemble an application server in miniature. Axis2 comes packaged with a WAR that can be deployed on a servlet container such as Tomcat that is designed to make web services easier to manage and deploy on the fly. The Axis2 Web Administration module allows Axis2 to be configured dynamically while applications are running: new services can be uploaded, activated or deactivated and their parameters may be changed. The administration UI also allows modules to be enabled on one or more running services.

The only downside to using the UI for these purposes is the fact that configuration changes made through it are not persistent — they go away when the servlet container is restarted.

Axis2 lends itself towards web services that stand alone, independent of other applications, and offers a wide variety of functionality, and a good model for adding more functionality as time goes on through its modular architecture. Some developers may find that a little too cumbersome or heavy-duty for their needs. These developers might prefer to look at Apache CXF.

CXF concentrates on developer ergonomics and embeddability. Most configurations are done via the API instead of cumbersome XML files, Spring integration is heavily emphasized, including support for Spring 2.0, and CXF’s APIs and Spring configuration mirror one another fairly closely. CXF emphasizes code-first design, using simple APIs to make development of services from existing applications easier (and its embeddability helps too).

As regarding Metro, the Java API for XML based Web Services is the successor of the JAXRPC specification. JAX-WS respectively its predecessor is message based and supports asynchronous communication. The Configuration is managed by annotations therefore Java 5 or higher is required. JAX-WS isn’t downwardly compatible to its predecessor JAX-RPC. With JAXWS it is pretty easy to write and consume Web Services. The default values of numerous parameters are comfortable for the programmer, so that simple Pojos declared with a @WebService annotation can be used as a Service.

Metro is documented in detail. Apart from the JAX-WS, JAXB and JWS specifications there are numerous tutorials und samples. The Netbeans IDE as well as the tutorials of the enterprise pack makes it particularly easy to get started. Of course, Eclipse can also be used for the development with Metro. Web applications containing Web Services which have been realized with JAX-WS are executable in the Glassfish Application Server. To make services also executable in other application servers, two libraries (JAX-WS and JAXB) have to be installed. Application servers such as JBoss, WebSphere or Tomcat can be upgraded with JAX-WS within about 10 minutes.

Performance

Due to the modern streaming XML parser, the performance of all three SOAP engines is very well. The ping time for a locale roundtrip is about 2-4 milliseconds (message size about 3KB, Dual Core Notebook). Therefore the time delay by the SOAP communication is negligible in many projects.

WS-* Standards

The support of the WS-Standard family can also be decisive for the selection of a SOAP engine. For example, messages sent to services can be secured with signatures as described in the Web Service Security standard (in short WSS). Table 1 shows the support for WS*-Standards of the toolkits. The following table summarizes the standards implemented by each framework:

Conclusion

None of the Web Services frameworks is in general superior to the others. Axis 2 is structured modularly, has many features and can be used as an application server for Web Services. A special feature of Axis 2 is the support of removable binding frameworks, for example XMLBeans. Axis 2 together with the XMLBeans framework included is well suited for Web Services which are using very complex schema definitions. The disadvantages of Axis 2 are its complexity as well as the insufficient JAX-WS support. Therefore anyone who wants to work with JAX-WS should choose Apache CXF or the reference implementation. Those who prefer a seamless integration with the Spring framework are well advised with the JAX-WS implementation.

Furthermore CXF is slim and easy to use. CXF is the tool of choice if a SOAP engine has to be embedded into existing software. Who just wants to code against the standard is well advised with the JAX-WS implementation.

Made by: Arpad Sebesi

Metro, Axis2, CFX

Metro

Metro is a high-performance, extensible, easy-to-use web service stack. The Metro web service stack is a part of the GlassFish community, but it can be also used outside GlassFish. It provides several transports and related technologies to provide efficient connectivity to different services:

HTTP transport

Metro can act as both a client and a server for HTTP. The HTTP web service can run inside any servlet container or anywhere on JavaSE6.

MTOM and XOP

These specifications enable optimized binary encodings of XML content within SOAP 1.2 payloads. XML structure is preserved in a text-based “XML Information Set” manifest, while enabling the document’s contents to be serialized to any binary encoding. These specifications enable encoding of XML content as MIME body parts and encapsulation of those parts – along with the associated XML Information Set manifest — within SOAP 1.2 envelopes. The specifications also describe how to encapsulate binary-encoded XML body parts directly within HTTP packets. The main point is that the size of the XML is reduced resulting in more optimal communication.

SOAP/TCP

SOAP over TCP transport enables highly efficient transmission of SOAP messages by using FastInfoset. Transport support in Metro is extensible. There are other transports available as well, including the in-VM transport, JMS transport, SMTP transport, etc.

Reliability, in Metro, ensures that the underlying system is able to recover from failures caused by messages that are lost or misordered in transit. Recovery is handled by the underlying system without involvement of consumer or provider application code.

Interoperable reliability is achieved by implementing the WS-ReliableMessaging specification. Turning on reliability, in Metro, when developing a web service, is simply a checkbox in a reliability panel in NetBeans.

Atomic transactions are a well-known means to ensure that all operations within a transaction boundary succeed or fail in a consistent manner. If even one operation fails then all other operations are aborted. Transactional support has been available in Java Enterprise Edition for a number of years on IIOP invocations. Metro enables transactional support for web services. Interoperable atomic transactions are enabled, in Metro, by implementing the WSCoordination and WS-AtomicTransactions specifications.

Web services, until now, have relied on transport-based security such as SSL to provide point-to-point security. Metro implements the WS-Security specification to provide interoperable message content integrity and confidentiality, even in the presence of intermediaries. In other words, WS-Security does not rely on transport-based security. WS-Security is a security option provided by Metro besides existing transport security which still may be used. Metro also provides an implementation of the WS-Trust specification as a means for issuing, renewing, and validating security tokens used by WS-Security, and to establish and broker trust relationships.

The core of Metro implements the JAX-WS API and serves as the foundation where all the higher-level features plugs in. The extensibility in this layer enables “pay as you go” model, where you’ll only pay the performance/complexity price for features that you use. The core also provides the basic interoperability features, such as WS-I Basic Profile, WS-I Attachments Profile, and WS-Addressing. Metro builds on top of libraries that are independently reusable outside the context of web services. Those include:

1. JAXB RI for the databinding layer

2. SAAJ for raw DOM access to SOAP messages

3. Woodstox for efficient XML parsing

4. XML stream buffer for efficient infoset buffering

Axis2

Axis2 is a clean and extensible Open Source web services platform with a configurable, modular architecture. The same business logic implementation in Axis2 offers both a SOAP endpoint and a REST interface. Otherwise the architecture is similar to Metro JAX-WS: Axis2 utilizes an XML pull parser, supports hot deployment and asynchronous web services, and can be extended to provide security and reliable messaging similar to WSIT. Apache Axis2 not only supports SOAP 1.1 and SOAP 1.2, but it also has integrated support for the widely popular REST style of Web services. The same business logic implementation can offer both a WS-* style interface as well as a REST/POX style interface simultaneously. Apache Axis2 is more efficient, more modular and more XML-oriented than the older version. It is carefully designed to support the easy addition of plug-in “modules” that extend their functionality for features such as security and reliability. The Modules currently available or under development include:

WS-ReliableMessaging - Supported by Apache Sandesha2

WS-Coordination and WS-AtomicTransaction - Supported by Apache Kandula2

WS-Security - Supported by Apache Rampart

WS-Addressing -Module included as part of Axis2 core

Apache Axis2 is built on Apache AXIOM , a new high performant, pull-based XML object model. Axis2 comes with many new features, enhancements and industry specification implementations.

The key features offered are as follows:

Speed - Axis2 uses its own object model and StAX (Streaming API for XML) parsing to achieve significantly greater speed than earlier versions of Apache Axis.

Low memory foot print- Axis2 was designed ground-up keeping low memory foot print in mind.

AXIOM - Axis2 comes with its own light-weight object model, AXIOM, for message processing which is extensible, highly performant and is developer convenient.

Hot Deployment - Axis2 is equipped with the capability of deploying Web services and handlers while the system is up and running. In other words, new services can be added to the system without having to shut down the server. Simply drop the required Web service archive into the services directory in the repository, and the deployment model will automatically deploy the service and make it available for use.

Asynchronous Web services - Axis2 now supports asynchronous Web services and asynchronous Web services invocation using non-blocking clients and transports.

MEP Support - Axis2 now comes handy with the flexibility to support Message Exchange Patterns (MEPs) with in-built support for basic MEPs defined in WSDL 2.0.

Flexibility - The Axis2 architecture gives the developer complete freedom to insert extensions into the engine for custom header processing, system management, and anything else you can imagine.

Stability - Axis2 defines a set of published interfaces which change relatively slowly compared to the rest of Axis.

Component-oriented Deployment - You can easily define reusable networks of Handlers to implement common patterns of processing for your applications, or to distribute to partners.

Transport Framework - We have a clean and simple abstraction for integrating and using Transports (i.e., senders and listeners for SOAP over various protocols such as SMTP, FTP, message-oriented middleware, etc), and the core of the engine is completely transport-independent.

WSDL support - Axis2 supports the Web Service Description Language, version 1.1 and 2.0, which allows you to easily build stubs to access remote services, and also to automatically export machine-readable descriptions of your deployed services from Axis2.

Add-ons - Several Web services specifications have been incorporated including WSS4J for security (Apache Rampart), Sandesha for reliable messaging, Kandula which is an encapsulation of WS-Coordination, WS-AtomicTransaction and WS-BusinessActivity.

Composition and Extensibility - Modules and phases improve support for composability and extensibility. Modules support composability and can also support new WS-* specifications in a simple and clean manner. They are however not hot deployable as they change the overall behavior of the system.

Apache CFX

Apache CXF is an open source services framework. CXF helps you build and develop services using frontend programming APIs, like JAX-WS. These services can speak a variety of protocols such as SOAP, XML/HTTP, RESTful HTTP, or CORBA and work over a variety of transports such as HTTP, JMS or JBI. CXF includes a broad feature set, but it is primarily focused on the following areas:

Web Services Standards Support: CXF supports a variety of web service standards including SOAP, the Basic Profile, WSDL, WS-Addressing, WS-Policy, WS ReliableMessaging, and WS-Security.

Frontends: CXF supports a variety of “frontend” programming models. CXF implements the JAX-WS APIs (version 2.0 will be TCK compliant). It also includes a “simple frontend” which allows creation of clients and endpoints without annotations. CXF supports both contract first development with WSDL and code first development starting from Java.

Ease of use: CXF is designed to be intuitive and easy to use. There are simple APIs to quickly build code-first services, Maven plug-ins to make tooling integration easy, JAX-WS API support, Spring 2.0 XML support to make configuration a snap, and much more.

Binary and Legacy Protocol Support: CXF has been designed to provide a pluggable architecture that supports not only XML but also non-XML type bindings, such as JSON and CORBA, in combination with any type of transport.

Made by: Arpad Sebesi