Recently I upgraded my prefered Java IDE, IntelliJ IDEA, to version 7.0. Aside from encountering the usual "major release" bugs I also discovered a number of new Web Services-related features. Despite not investing much thought into which Web Services Stack I am actually using (I've been using EJB3 for quite some time now and simply annotated my beans with the @WebService annotation... which sorta leaves the decision to the AppServer vendor) I started to wonder about the different implementations when I encountered the newly introduced "Create Web Service Client"-feature in IDEA 7.0.
Furthmore, being the "walking dictionary" (as some of my colleagues choose to titulate me), more and more of my coworkers and friends working with Java were asking me exactly the same question. I thus started to investigate further about how the different stacks compare.
Let's first take a look at JBossWS...
Simply put, JBossWS is Red Hat's implementation of JSR 224 which in turn is meant to be an extension for the JBoss application server (naturally) to make it Java EE 5 Web Services compatible. While it's (to my knowledge) not part of the standard 4.0-distribution it's now fully integrated in the JBoss 4.2 distribution. Installing it in JBoss 4.0 is luckily quite simple (download it and run ant deploy-jboss) and if you are using JBoss as your AppServer of choice it's likely that you will use it to both expose and consume Web Services. Naturally, you are not restricted to only use JBossWS, you may want to use Axis and that's fine, but why make life difficult if you can use something prepacked that works just as well.
One thing is important to remember, though: JBossWS is an implementation of JSR 224, thus, you will have difficulties to consume Web Services using RPC-style binding which you may have deployed in your infrastructure. In that case you will need to use JAX-RPC to consume them. Bare in mind that RPC-style Web Services aren't WS-I compliant and if you have any chance, try to avoid them as you will have interoperability issues as it is considered a deprecated technology.
Update [March 31, 2008]: Don't miss the comment by Thomas Diesler. He informs that the above statement isn't quite correct. JBossWS does indeed have support for JSR-109. Thanks, Thomas!
Now let's take a look at Metro...
With the appearance of Metro some might have been slightly confused how it fits into the big picture of different Web Service Stacks. To make things clear, Metro is not meant to replace JAX-WS. As a matter of fact, it is a neat package of different technologies which already exist, amongst others JAX-WS, WSIT, JAXB et cetara, thus making it a more complete stack than vanilla JAX-WS is.
Metro introduces backwards compatibility for the previously mentoined RPC-style web services, it provides interoperability features with Microsoft's Windows Communication Foundation and a number of other things. Basically, if you want to be able to consume and/or provide Web Services of different styles and with advanced features you should take a look at Metro. Even though it's not been around for so long it's already my stack of choice.
Last but not least I should mentoin that the latest version of GlassFish provides the Metro API and also Red Hat has very recently added JBossWS 3.0 to their offering, which is the JBoss equivalent to Metro and thus you are able to use all the Metro-features in JBoss... provided you deploy it to your server :)
So, a quick look at JAX-WS...
After writing all of the above you basically should have a clear picture about what JAX-WS is, but to summarize: It's the reference implementation of JSR 224. It should come as no surprise that it is used by default in GlassFish 2.0 to provide Java EE 5.0 Web Services features.
And what about Axis?
Lot's of Java Developers working with Web Services will at some time have encountered Apache's Web Services Stack by the name of Axis. It's been around for a long time and thus it is very complete and flexible. For example, you can use a number of different Data Binding providers (i.e. XMLBeans or JAXB), you can use lot's of transport protocols like Jabber, JMS, TCP and, of course, HTTP.
If you feel that Metro can't give you what you need then there is a chance that Axis 2 will provide the features you need.
To sum things up, there are lots and lots of different stacks (IBM, XFire, Oracle, etc.) and all have their pros and cons and in the case of Java EE development you might just as well use what is provided as part of the AppServer unless you are running into limitations which force you to reevaluate. If you are coding a Java SE application that needs to expose a Web Service it's a different situation, though. Before version 6.0 of Sun's JDK distribution didn't contain a Web Services Stack and thus you are required to make a choice. You could just go for Metro or JAX-WS, but Axis 2 has lot's of features which make it an appealing choice.
February 12, 2008
Subscribe to:
Post Comments (Atom)
3 comments:
Do you have any experience with using WS-Security in Metro, Axis2 (Rampart), etc.?
I am writing a Web Service client to attach to a 3rd party service, and I am having trouble distinguishing between the aforementioned stacks.
Actually, JBossWS is an implementation of JAX-RPC (JSR-109) and JAX-WS (JSR-224)
The supported target containers are documented here: http://jbws.dyndns.org/mediawiki/index.php?title=Supported_Target_Containers
Also, please note that JBossWS comes with an integration layer for pluggable web service stacks that allow you to use the same deployment model, management interface, etc for multiple stacks
http://jbws.dyndns.org/mediawiki/index.php?title=WSF
Cheers
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
Web Service Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hi Thomas, thanks a lot for the comment. I didn't realize it was because last time I tried (just a week ago) I got an error message on JBoss 4.2.2 which indicated that this wasn't the case (at least according to a JIRA-issue which I found on jboss.org). I guess I should give it another go.
Post a Comment