Comparing Metro and CXF

Over the past couple of weeks, I have been doing some research on Metro and CXF to find out some performance nos and see if there's a clear advantage in using one over the other for JAX-WS compliant service. In short, Metro definately was faster than CXF (untuned or out of the box). Here's a chart I put together showing the numbers - I ran the same call in a loop, making 100 serial calls.


(All timings are in seconds)
The data was collected on a Toshiba Dual Core 2.1 Gz, 2GB RAM Tablet running Windows XP with the services hosted in Weblogic 10.3. The service itself did not do much in terms of functionality but to populate some in-memory data into the service response. So these times would not necessarily match true functional service times.

I also took a look at development simplicity as the other key measure in determining the viability of the 2 libraries in the enterprise. I took the WSDL first approach in the development of these services, and found that CXF was a little easier to work with than Metro. Code generation and configuration were the 2 key factors here and both had some quirks here (with namespaces especially). CXF, out of the box integrates well with Spring. Metro doesn't though there is some hook that has been developed for it (though the initial version had a memory leak) - I did not try Spring integration with Metro.

In terms of functionality and supporting the WS-* standards, Metro definately has it all, while CXF is catching up. To me the key WS standards are WS-Security/WS-Policy, WS-Reliability & WS-Transaction. While Metro supports them all being a reference implementation for the spec, CXF supports some parts of WS-Security/WS-Policy while it does not support WS-Transaction at this point.

Overall, I still prefer CXF over Metro, though it seems like Metro looks a winner in all key categories I considered. At the end of the day, the differences are marginal and really depend upon what your needs are from a project perspective. What I mean here is that if you are looking at other things - eg. an ESB maybe (though management hates that word now, so be careful on that one...:)), for your project, then CXF fits in very well since it is a part of the Apache FUSE project. For Metro, Sun's(or Oracle) libraries are under a binary license (BCL), so that may be an issue to you if you are looking to change code (sometimes to fix a problem), but other than that, both libraries are solid and will probably both have equal adoptance across the enterprise space. While it may be a no brainer that if you were using XFire before, you should move to CXF now, performance wise, don't expect any difference (in-fact XFire was actually marginally faster over CXF). One thing I do need to play with here is the tuning recommendations on marshalling/unmarshalling of Xml in CXF that the project site talks about when using JAXB. I will post that information later since currently the documentation on it is really lacking (besides this - SXC).

Hope this post helps you make a choice - if its not helped, then its probably because both libraries are equally good - though I will say that Apache Axis definately has fallen behind.

A Single Sign-on implementation

If you are looking to implement a Single Signon implementation, then a worthwhile library to look at would be OpenSAML 2.0. The 2.0 library is well written and much more intuitive to use compared to its predecessor - OpenSAML 1.0. I recently implemented a SAML 1.1 solution using the 2.0 library on Weblogic 8.1. The library by default is for the Java 1.5 platform, however using Retroweaver, one can use it for Java 1.4 (since Weblogic 8.1 does not work with Java 1.5). The SAML Browser/Artifact profile is pretty easy to understand and implement with the library and good ol' Wikipedia gives an easy explanation of the steps needed to get the communication going. However, I would recommend that you read through the OASIS SAMLBind document to get a better understanding of implementation details.

I used Xfire (v1.2.6) to implement the Artifact Resolution Service at the IdP that the Service provider invokes once it receives the artifact posted to it. Since the OpenSAML library works with the raw xml document, one needs to configure xfire to prevent marshalling of the incoming xml to java POJOs. XFire has a cool way to work with raw xml documents, using a binding called as Message Binding. So the xfire service interface looks like:

public XMLStreamReader invoke(Document samlRequest) throws Exception

and the OpenSAML library can then work with the DOM document using the XMLObjectBuilderFactory request factory.

Some quirks here - while returning the response, I had to return an object of type XMLStreamReader - I used W3CDOMStreamReader to convert to this type. Also, for getting SOAP faults correctly, the interface definition of the service had to throw the base "Exception"class and not a specific exception type.

While the implementation does add a bit of added complexity through the use of XFire, it works out pretty well and allows one to use these excellent libraries -XFire & OpenSAML 2.0 - together to leverage the best of both.

The solution is on its way into production this week - fingers crossed....:).