Posted by kohsuke
on February 10, 2006 at 7:38 PM PST
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.
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.