A cup of Java

When it comes to web service frameworks, I can say I've had my share over time. I once started with JAX-RPC for the SOA part of my first big product development I got involved in. We're talking about a distributed DRM system. The team was applying great technology, but the market was not ready for such a product. It was fun to do, no doubt about that. Then I tried out Axis , Axis2, XFire, JBossWS, and now I've finally ended up with JAX-WS RI 2.1.1, deployed within a JBoss 4.2 application container. I analyze: JAX-WS RI is Good, Good, Good!

The JAX-WS web service stack specification finally is mature enough to start implementing all those fancy WS-* related SOA specs that we always wanted to support in our products. The basic architecture is quite easy to grasp and shows some analogy when compared to the servlet container specification. A servlet container basically has notion of three aspects: servlets, filters and listeners. When looking at a JAX-WS container (if I may call it that way) you'll find that endpoint definitions (the classes that you annotate with @WebService) correspond with servlets (that is, very roughly). JAX-WS handlers correspond with servlet filters and the thing that Kohsuke Kawaguchi is doing with his JAX-WS commons project somehow corresponds (again, very roughly) with servlet container listeners (I know, it's more than that, he's doing the factory pattern over there). In the end it's all about proper life-cycle management of the JAX-WS endpoints and the corresponding handler chain that you want to apply over them.

Just like servlet filters can communicate with each other via the request/response object and their attached request and session contexts, so can JAX-WS handlers also communicate with each other and with their serving endpoints via the SOAP context. This SOAP context makes up for a pretty powerful messaging system within a JAX-WS runtime stack. It enables JAX-WS handlers to cooperate to achieve a certain aspect of the client-server communication protocol. For example, you could have one JAX-WS handler adding a SOAP header to the outbound message. If this handler wants to have his generated SOAP header to be signed by the WS-Security JAX-WS handler it could use the SOAP message context to communicate the corresponding SOAP header element Id to the JAX-WS WS-Security handler. A similar pattern can be applied as it comes to verification of WS-Security signed elements. The WS-Security JAX-WS handler could, after successful verification, push the XML element Ids that have been signed correctly onto the SOAP messaging context. That way other JAX-WS handlers later on in the chain can first check whether their SOAP header element has been correctly signed by the WS-Security signature. In my view this is the way WS-Security should be handled. Forget those endless WSS XML configuration files. What you want to do is to manage the WS-Security aspect of your communication protocol programmatically via a highly customizable JAX-WS handler chain.

As already mentioned I particularly like the way JAX-WS RI is going with this new JAX-WS commons project. Here we find an interesting aspecting pattern where you annotate the annotations themselves to attach behavior to them. The first time I saw this pattern was with the Hibernate validation framework. It's nice to see that JAX-WS RI picked this one up and is exploring new possibilities. I for one already implemented an @Injection JAX-WS InstanceResolver annotation that finally made @EJB(mappedName="foobar") to work within my JAX-WS endpoints when deploying my (from WSDL) web services on the JBoss Application Server. Hopefully we'll see some more of such annotation based aspecting showing up in container frameworks.