Java Web Service: CXF Introduction

The Apache CXF Web Services Stack is another alternative from the Apache Software Foundation, and the Axis2 stack is also from the same organization. Although they come from the same organization, Axis 2 and CXF take a completely different approach to how to configure and deliver WEB services. In this article, you will learn the basics of using JAXB 2.x and Jax-ws 2.x for CXF Web services, and compare CXF with other jaxb/jax-ws stacks-axis2 and metro-, as discussed in previous articles.

CXF Foundation Comparison

In terms of the user interface, CXF has much in common with the AXIS2 and Metro Web services stacks. The three stacks allow you to either build a Web service from existing Java™ code or start with a WSDL Web service description to generate Java code that uses or implements the service. And, like other stacks, CXF model service operations as method calls, while service port types are modeled as interfaces.

Similar to Axis2, but different from METRO,CXF allows different data binding techniques to be selected. CXF's support for JAXB 2.x is as high as Metro Axis2, because it allows the JAXB standard to be used when generating code from WSDL (and Axis2 is not allowed). CXF also allows other data-binding methods to be used, although support for these methods is not as mature as in Axis2-in particular, you can use CXF to generate code from WSDL only when you use JAXB or XMLBeans data binding.

The preferred service configuration technology used by CXF (or the front-end in CXF terminology) is the Jax-ws 2.x annotation, which is usually accompanied by an XML configuration file. Support for JAX-WS annotations in CXF is the same as in Metro, so there are some limitations to using JAX-WS with Axis2 (in Axis2, as described in "JAXB and Axis2 in Jax-ws"), and CXF is more appropriate for JAX-WS. As with other JAX-WS implementations, CXF requires that the service WSDL be available to the client at run time.

Like other stacks, CXF uses request and response processing flows made up of configurable components. CXF calls the component intercepters, not handlers, but other components are equivalent components. As with Metro, CXF fully supports ws-security and other extension technologies as part of the underlying download. Unlike Metro, the CXF JARs is modular-that is, you can choose JARs as part of your application based on the technology you are using (CXF the/lib/which_jars files in the installation directory will tell you the specific JARs required by the various common use cases). The downside of this modularity is that it ultimately produces a long list of specific JARs that the application needs; on the plus side, it allows you to control the size of your deployment.

Another common with Metro is that CXF typically needs to build a WAR file for the Web service rather than potentially deploy multiple services to a single service installation (which is exactly the approach used by AXIS2). CXF also provides an integrated HTTP server for production use in the form of a Jetty server. This provides a more flexible and powerful alternative to the simple server support integrated in Axis2 and Metro.

Sample Application

The Code Download section provides a version of the Simple Library Management service used in previous articles in this series, which has been modified to demonstrate the use of CXF. As with previous versions, the WSDL service definition altogether defines 4 actions:

GetBook is used to obtain details about a particular book that is identified by the International Standard books number (ISBN).

Getbooksbytype is used to get detailed information about all the books of a certain type.

GetTypes is used to discover existing book types.

Addbook is used to add new books to the library.

In "JAXB and Jax-ws in Axis2", you see how this application works in Axis2, and then in the Metro profile, you see how it works in Metro. Most of the content in these articles also applies to the use of CXF. In addition to the service name and endpoint address, the WSDL is the same; the resulting JAXB data model is the same, and even the generated service classes are the same, except that the service names used in Java packages and jax-ws annotations are different.