Since its emergence, Web Service technology has gone a long way towards perfecting itself and finding its right application in the real world. With the maturity of the specifications, Web Service technology, with its power of interoperability, is now the major enabling technology of SOA, which is being adopted by more and more enterprises to build their application integration infrastructure.

Developing Web Services involves a variety of technologies, XML processing, SOAP, and WSDL, to name a few. Luckily, there are frameworks that target handling theses kinds of middleware functions, freeing up developers to focus on the business logic.

Nowadays, many Web Service frameworks exist for all kinds of programming languages. Some of them are open source, others are commercially available. Some examples of such frameworks are Apache Axis and Axis2, WS02 Web Services Framework (WSF), Java Web Services Development Pack (GlassFish), JBossWS, and XINS.

Being one of the Web Service frameworks for Java, Apache CXF is an open source framework developed by the Apache Software Foundation. It's a continuation and merging of two open source projects, Codehaus' XFire project and ObjectWeb's Celtix project. When this was written, the stable version was 2.0.

CXF enables the creation of Web Services using Java technologies. It supports a variety of Web Service standards including WS-I Basic Profile 1.0, WS-Addressing, WS-Policy, WS-ReliableMessaging, and WS-Security.

CXF supports transport protocols like HTTP and JMS. The messaging formats supported include SOAP, XML, RESTFul HTTP, and CORBA. Besides JAXB data binding, it also supports Aegis binding.

CXF is JAX-WS (JSR 224)-compliant and version 2.0 has passed the TCK for JAX-WS 2.0. It makes intensive use of Java 5 annotations and so requires JDK/JRE 5.0 and above.

CXF leverages the Spring application framework for bean management. Endpoints and service clients can be managed as Spring beans.

In the first section of this article, a step-by-step Web Service example using CXF is presented. Some of CXF's basic features are revealed while going through the steps of creating the example. Then we'll touch on some of the unique features of CXF, including RESTful service support and Spring integration. At the end, a brief performance test will compare CXF with JBossWS and the JAX-WS Reference Implementation (RI).

An Example: Getting Movie Show Times
In this example, we'll build a Web Service that lets a client system query for movie show times using the ZIP code entered by a user. For demonstration purposes, most of the irrelevant details are ignored.

CXF supports both code-first development and contract-first development. While code-first development is a handy feature, and most developers find it more straightforward and easier to get start with, it has a vital weakness.

There are several reasons for this. First, a key aspect in successfully developing Web Services is to determine its granularity. Considering the fact that the major application of Web Services is to implement SOA solution at a really high level (e.g., at the enterprise level), the granularity couldn't be too small. In contrast are the Java classes and methods, which tend to be very fine-grained, and are often designed at the very low level (i.e. the class level). Secondly, Web Services bare the nature of language neutral. Building a service from a specific language (like Java) and transforming it into a language-neutral form through some tools would, in some cases, bring over language-specific features, which will degrade the language-neutral nature, thus hurt the interoperability, of the service. Lastly, from a design point of view, service-oriented principles are significantly different from object-oriented paradigms. Although an individual service might be realized using OO principles and techniques, the interaction between services rarely using any of them.

Due to the aforementioned reasons, code-first development will never let you get to the spirit of service-oriented development because developing in Java code and developing in WSDL requires different mindset. Developing with Java code-first and avoiding WSDL as much as possible will guarantee that you will build mediocre software at the best. This is especially true when it comes to designing and developing a SOA solution rather than just individual services.

With that said, let's start with contract-first development for our example, the first step of which is to create the contract - the WSDL document that describes the service.

WSDL Document
Listing 1 shows a segment of the WSDL document. In this document a service called MovieService is defined. This service has only one operation GetShowtimesForZip. The input of this operation is a message containing the ZIP code that the user entered, and the response is a list of theaters and movies along with show times.

The types are defined in a separated XML Schema document and are imported using <xsd:import> statement. The schema document isn't listed here to avoid lengthy text.

Nothing is really special about this WSDL document. Let's now generate the service interface and the service endpoint interface (SEI) from the WSDL document.

Service and Service Endpoint Interfaces
With the WSDL document ready, our next step is to generate server-side Java code from it. CXF provides a tool called wsdl2java that can be used to generate fully annotated Java code from a WSDL document. This tool operates according to the JAX-WS rules for WSDL <--> Java mapping, and its data binding mechanism conforms to JAXB (JSR 22). The tool comes with a set of optional arguments that allow control of the behavior of the tool.

The WSDL document used to generate the Java code has to have a valid portType element, but it doesn't require a binding element or a service element.

The simplest form of running the tool on the command line is listed in Listing 2.

You can specify the package of the generated code using the -p option as shown in Listing 3.

JAX-WS defines an XML-based binding language that can be used to customize the WSDL to Java bindings. The wsdl2java tool implements this feature using the -b option. Listing 4 shows how to specify a JAX-WS binding file for customization.

You can ask the tool to generate an Ant build file for use in your application. To do so, use the -ant option as shown in Listing 5:

Or you can define your own Ant macro. A sample of such a macro is included in the CXF distribution. Listing 6 shows a modified version of it.