Operating on the XML Level
XML-based Web Services use XML messages for communication between services and service clients. The high-level JAX-WS APIs are designed to hide the details of converting between Java method invocations and the corresponding XML message. But in some cases, operating at the XML message level is desirable.

JAX-WS defines two new APIs for the Web Services to operate at the XML level. They are javax.xml.ws.Provider and java.xml.ws.Dispatch. Provider is a server-side API while Dispatch is a client-side API. CXF supports this JAX-WS standard. Listing 15 is an example of server code operating at the XML message level. As you see, there's nothing specific to CXF in the code.

Spring Integration
CXF integrates with Spring application framework seamlessly. Service endpoints and service client beans can be created the Spring way. In Section 1.4.2, we've seen how a service endpoint bean can be created using Spring. What we're going to see here is how to create a client.

CXF includes a JaxWsProxyFactory class that creates a client for you from your service endpoint interface. You simply need to tell it what your SEI is (in this case MovieService interface) and the URL of your service. You can then create a client bean via the JaxWsProxyFactory bean by calling its create() method.

An XML configuration file is used to set this up. See Listing 16. This is just a regular Spring configuration file. In this file, two beans are declared, movieServiceClient, which is an SEI bean, and the clientFactory bean, which is a factory bean. The factory bean and factory method attributes specify the factory and the factory method used to create the SEI bean.

To access the SEI bean in the code, one can either get the client bean from the Spring context or inject it into the application using Spring's Injection of Control (IoC) feature. Listing 17 is an example of getting the bean from the context.

Performance
A brief performance test is done to compare the performance of three Web Service stacks - CXF, JBossWS, and JAX-WS RI. In the test, three servers are set up, one for each of the three stacks (the exact versions are CXF 2.0, JAX-WS RI 2.1.1, and JBossWS 2.0).

Apache JMeter test suite is chosen to be the testing software. A test plan is set up in JMeter to act as the client, which sends SOAP messages to the tested servers via HTTP. The servers simply echo the messages back. The sizes of the messages are 12KB.

For each server, five concurrent threads are set up to generate requests back to back. The test runs for 30 minutes and at the end the number of transactions finished is recorded.

The test machine is a Windows PC running XP Professional, with a 1.7GHz Intel Pentium processor and 1.5GB of RAM.

Table 1 summarizes the tests result. It shows the number of transactions during a 30-minute time period for each server.

At the first glance, one may conclude that JAX-WS RI is terribly slower than the other two because the number of transactions is so low. But further study of the testing results and logs indicates the opposite - JAX-WS RI might actually be the fastest of the three. Here's why.

The log shows that a total of 743,203 requests were made by the JAX-WS JMeter client during the time period. However, most of them (665,245) are returned as errors, all address-not-available errors. This is an error when all the ports in a machine are in use and there are no free ports. It can happen under very high loads. This could be an indication that the JAX-WS RI server started so many threads so quickly that the OS releasing ports can somehow not catch up, causing the system to run out of ports eventually.

To verify this hypothesis, the test was run again, only this time just one thread was run instead of five. Table 2 shows the result.

As one can see, the number of transactions is now comparable to the ones of CXF and JBossWS, and the number of errors dropped significantly. The error should be able to be eliminated if running on a server-class OS.

Conclusion
CXF is a robust Web Services framework that supports a variety of Web Service standards. It's easy to develop, configure, and deploy. Additional features such as integration with Spring make it an attractive choice when Inversion of Control (IoC) and Aspect Oriented Programming (AOP) features are important. With the existence of JSR 109, however, it's probably not a good choice when you're developing applications that run in Java EE containers because Java EE-compliant containers provide the same middleware functionalities, which, most likely, will work more seamlessly with the container.

References
•  Apache CXF Web site: http://incubator.apache.org/cxf/.
•  Codehaus XFire Web site: http://xfire.codehaus.org/.
•  Celtix Web site: http://celtix.objectweb.org/.
•  JAX-WS specification (JSR 224). Available at http://jcp.org/en/jsr/detail?id=224.
•  Implementing Enterprise Web Services (JSR 109). Available at http://jcp.org/en/jsr/detail?id=109.
•  Rob Harrop and Jan Machacek. Pro Spring. 2005.
•  Jeff Davies. The Definitive Guide to SOA: BEA AquaLogic Service Bus. 2007.
•  Richard Monson-Haefel. J2EE Web Services. 2003.
•  Meeraj Kinnumpurath. JBI - A Standard-based Approach for SOA in Java. 2005.