subbu.org

Angle brackets or annotations? Is JAX-WS over-engineered or does it simplify web services development? I am disappointed with the points made by Richard Monson-Haefel and Jason Greene in their challenge and retractions against how complex or easy it is to use JAX-WS. Both their posts were provocative, but sidestep most of the requirements of complex web services. IMO, their positions are at the extreme ends.

For of all, let me look at Richard’s arguments. He complains that JAX-RPC and JAX-WS are over-engineered. He blames the API for its complexity. He blames features like handler chains. He complains that deployment is hard. These complaints are a bit disappointing. Given his expertise as an author of a book on J2EE web services, I would expect him to provide more
concrete criticism, and concrete proposals to address these limitations. Both were missing in his post. On the other side, Jason Greene tries to prove that it is trivial to write a web service using annotations. But I think his example actually proves Richard’s point that,
for the simplest services, JAX-RPC and JAX-WS work fine. His example does not get into any details of real-world complex web services.

On a scale of 1 to 10, I would give JAX-WS at least a 7 (I would have given a 9 had JAX-WS retained backwards compatibility with JAX-RPC). Here is my take on how JAX-specs scale for developing complex web services.

XML First

I would never start designing a web service in Java or some other
programming language, unless, of course, I’m doing a quick demo. Why?
Because, to design inter-operable and loosely-coupled web services, I need
to focus on the wire format first. Mapping to a programming language comes
later. During design, I need to focus on what kind of messages need to be
exchanged, what pieces of data need to be exposed and accepted, and their
detailed semantics. I also need to focus on the kind of faults need to be
returned, and their semantics. In essence, I would focus on a message
exchange protocol for each service.

To do all this, starting from Java with some annotations is not necessarily the best
approach. Such an approach would steal the focus away from the wire format
towards programming details such as class names, class hierarchies, method signatures, exceptions, etc.

To do this effectively, I need an XML-to-Java binding model that maps the
XML well-enough. With the help of JAXB, JAX-WS does a decent job in providing such a binding.

Injection of Services

The next important thing for me is the ability to inject services.
Take, for example, adding a security token to an outgoing message, or
processing a security token on an incoming message. The best way to do
this by adding handlers. Handlers are pluggable, can be inserted and
swapped as required without changing your application. I don’t understand
Richard Monson-Haefel’s complaint on handlers. At BEA, we use handlers to
drive a variety of use cases for our WSRP runtime.

I do have two complaints about handlers. Firstly, the criteria to inject
handlers is very coarse. Although JAX-WS improves upon JAX-RPC by letting
you specify service name patterns, protocol bindings etc., it is still too
coarse. I like to be able to specify handlers with some filtering criteria
using XPath or XQuery. My second complaint is about the underlying SAAJ,
and its tight-coupling to Java Mail and Java Activation Framework. SAAJ, by itself,
is fine, but I get jittery when it starts jumping to Java Mail API for
processing attachments. The programming model is not intuitive, and takes
some expertise to use it correctly.

JAX-WS needs further refinements in this area.

Services without Java Binding

JAX-WS adds support for building web services without requiring Java binding. I consider this to be a very important improvement over JAX-RPC. Both JAX-RPC and JAX-WS spend a lot of energy bridging between WSDL and XML and Java classes and methods. This is not necessarily the wrong approach, since it covers most of the use cases. However, for really performance conscious web services development, it is better to program to the XML directly. For instance,
instead of letting the container to unmarshal XML into Java beans, it may
be faster to proces the raw message directly. JAX-WS let’s you do this with the javax.xml.ws.Provider interface. The provider can receive SOAPMessage or a raw StreamSource

Performance is not the only use case for using providers to build web services. Another key use case is versioning. Direct access to the SOAP message gives more flexibility to create web services that can support multiple versions of web service. Working at this level requires some expertise since you need to be aware of angle brackets, DOM gotchas, namespace prefixes etc, but it is exciting to see this as a possibility with JAX-WS.

Protocol Handlers

This is yet another improvement in JAX-WS over JAX-RPC. Let me elaborate. In JAX-RPC,
handlers are protocol agnostic. Handlers don’t know anything about the
network protocol that was used to transport a message. On the server side,
handlers don’t know anything about the container that was used to run the
service. For purity sake, you might argue that all web services code must
be protocol independent “don’t care how the message got delivered - just
process it”. This may be the case for most web services, but definitely not
all web services. In real-world, web services co-exist with other apps
bound to various network protocols, and in some cases, we need a way to
peek into or influence protocol-specific aspects. Take, for example, any
WSRP producer implementation. For starters, a WSRP producer is a web
service that can be used to view/invoke portlets. In the J2EE world,
portlets mostly run on top of the servlet container. For a WSRP producer
to be able to interact with the servlet runtime, it needs access to
servlet request and servlet response. So, most WSRP producer
implementations out there use some internal/proprietary APIs to get hodl
of these objects from the servlet container. This is just one example.

JAX-WS has the notion of protocol handlers that can get more direct access to protocol level objects such as request and response headers, servlet-container variables like ServletContext, HttpServletRequest, HttpServletResponse, HttpSession etc.

My Summary

Overall, I think JAX-WS is great improvement over JAX-RPC. I take the side of Jason Greene, but not just for annotations. JAX-WS gives me access to more low-level stuff, and I now have less number of reasons to write my own web services stack - which I had to do a couple of years ago since JAX-RPC did not give me all that I wanted.