When approaching the creation of a web service, one of the core decisions to developing a system that fulfills the requirements is the selection of a web service stack. Some of the more notable open source solutions currently are: Apache Axis2, Apache CXF, Spring Web Services, and Metro. To be explicit, a web service stack is a protocol stack that is intended to define, locate, and implement a web service. Generally a web service stack makes use of four separate protocols:
• Transport Protocol - This is responsible for the transportation of messages between network applications.
• Messaging Protocol – This is responsible for encoding messages in XML so they are decipherable by either end of a network connection.
• Description Protocol – This protocol describes the public interface of a Web Service.
• Discovery Protocol – This protocol centralizes web services to allow for easy discovery of them by connecting applications.
The two particular web service stacks that are compared and debated frequently are Apache Axis2 and Metro. In an attempt to determine from a general outlook which of the technologies is better to use, several bits of data were compiled for comparison’s sake.
When comparing stacks, one common metric to look at is performance. A small sample set of data was compiled from tests involving both Axis2 and Metro. When performing these tests Axis2 was hosted by Apache Tomcat 7 and Metro was hosted by Glassfish 3; both servers were on a Windows 7 system. The web server and client were both hosted by this same Windows machine. This was done in an effort to remove network latency from the performance calculations. During these tests it became apparent that when using plain text messages, regardless of the size, their performance differences are negligible at best. Most messages were processed and a return message was provided in less than 150ms. During my testing I did not take into account the use of the WS-Standards, and from some research IBM conducted it appears that Metro’s performance with the use of WS-Security is up to 50% better in the case of large and small messages.
Small Messages
Large Messages
(Courtesy of http://www.ibm.com/developerworks/java/library/j-jws11/)
Axis2 provides support for multiple data bindings: ADB, JiBX, and XMLBeans. Metro, on the other hand, only supports JAXB 2. These binds allow for the conversion from platform independent XML to platform dependent data structures. While it is possible to write custom bindings it is usually more efficient to use a premade binding from an existing framework. The approach of allowing multiple data bindings is one of the key strengths of Axis2 and this attribute is not shared with the Metro stack.
When dealing with web services there are several WS-Standards that can be supported by a stack. With each of the WS-* add-ons you can modify the behavior of the stack to meet specific requirements. Below is a comparison of the support for WS-* standards.
In addition to better support for the WS-Standards across the board, Axis2 has implemented the use of WSDL 1.0 and WSDL 2.0 in its Description Protocol. On this from, Metro currently only supports WSDL 1.0. Also, when it comes to the topics of attachments, transports, WS-Addressing versions, and encoding tables Metro and Axis2 have identical support.
The comparison between the Axis2 and Metro web service stacks has shown that there are negligible differences between them. If, when developing your web service you put a higher value on data bindings and WS-* support: Axis2 is marginally better. On the other hand, if you are looking for secure messaging and performance is important factor: Metro is marginally better. What this choice, in most cases, comes down to is what the developers are more comfortable working with, and what technology is already in place. If Tomcat is already in place there is a compelling argument in the ease of adding axis2 compared to Metro. This is obviously reversed in the case of a Glassfish server.
I hope you have enjoyed reading this blog entry. Feel free to ask questions or leave comments below, I look forward to responding to them. To learn more about Action Identity, visit our website.
To contact us, click here.
Interested in reading similar articles?
http://www.actionidentity.com/blog/post.cfm/optimizing-drivers-that-involve-multiple-information-resources
http://www.actionidentity.com/blog/post.cfm/splitting-up-a-driver-to-increase-functionality-a-narrative
http://www.actionidentity.com/blog/post.cfm/unique-delimited-text-driver-solved
http://www.actionidentity.com/blog/page.cfm/archives
Recent Comments