Kohsuke Kawaguchi's Blog

Neck-deep in JAX-WS

For the past few months or so I've been working on rearchitecturing the JAX-WS RI. The goal is to bring the performance to the next level, to make it more pluggable in all respects, and to allow more infrastructure-level specifications to be implemented on top of it.

The existing JAX-WS code has its root in JAX-RPC, and with all due respect to people who worked on it, it just shows its age. This time around, We're really paying a lot of attention to separating responsibilities cleanly between components. For example, we want to use JAX-WS with so-called "Unicode and angle brackets", XOP, and FastInfoset --- in more abstract terms, we'd like to have this "encoder" component that's responsible for turning infoset into the stream of bits. Similarly, we want to use JAX-WS with HTTP, in-VM communication, JMS, and JBI (while we are at it, why not throw in SMTP, XMPP, and so on), so in more abstract terms, we'd like to have a pluggable transport layer. There are many, many places where one can define these pluggable components.

The other pillar is to improve the performance. We've identified that there's a lot of unnecessary extra data conversions going on in the old code, like Java objects -> SAAJ, or SAAJ -> stream, etc. So the new architecture pays a particular attention to delay the data conversion as much as possible (and in this process it often avoids some conversions altogether. Moreover, this is done in such a way that keeps the code actually more cleaner than before.

Another source of performance improvement comes from collapsing layers. For example, JAXB can marshal Java objects directly to UTF-8 stream very very fast. But this goes against our notion of the "encoder" abstraction. Like this, there are many places where the separation of responsibility doesn't work well with the performance improvement strategy. So in many places, we come up with ways to allow two components to optimize their interactions, without breaking the general abstractions we are setting up.

Individually, each modularization is all pretty basic obvious things, but when you put them altogether and try to make it work (and work fast!) with specs that aren't perfect, things get really interesting. Well, that's why I'm still stuck in the office at 7pm Friday afternoon.

Comments

• Kohsuke,

  In your post you mention in-VM communication:

  ... "Similarly, we want to use JAX-WS with HTTP, in-VM communication, JMS, and JBI" ...

  Does in-VM communication mean being able to effectively perform a direct Java method call of a service instead of marshalling and then unmarshalling the objects to/from XML?

  If so this is a feature that I would be interested in learning more about. In any event, what sort of performance improvement are you able to measure with in-VM communication?

  Thanks,

  Pat Podenski
  

  Posted by: podenski on March 20, 2007 at 01:59 PM

• 
  There can be different kinds of in-VM communication. The one we have now runs full serialization/deserialization to byte[]. Its primary purpose was to test the JAX-WS RI. But there can be other in-VM transport implementation.

  
  Doing direct Java method call is often not very useful because of the requirements in doing so — such as class visibility, and change in the semantics. One can still implement such a layer on top of the JAX-WS API, but that won't be what we call a "transport".

  Posted by: kohsuke on March 21, 2007 at 07:29 PM

• I would like to use WININET as the transport layer for JAX-WS. It handles the secure store, authentication and proxy issues.

  You talked about pluggable transport layers - can I plug in a new transport layer over WININET?

  We did a transport layer over WININET for xmlrpc.

  Posted by: gqnelson on June 20, 2008 at 01:01 PM

• Yes. We should talk in e-mail.

  Posted by: kohsuke on June 20, 2008 at 03:00 PM

This work is licensed under a Creative Commons License.