Up the Metro stack to JMX Technology: A Wise Man's
What a long trip... We started by
driving on the HTTP highway, slid on SOAP, turned left at the XML
crossroads, passed over the WS-Addressing bridge, visited
WS-Enumeration, WS-Eventing and WS-Transfer, got a bit lost in
WS-Management country, discovered that JMX was not so far off, and
finally took a rest (but not a RESTful one) in the Web Services
Connector... Did we do all that on our own? No, we did it with a set
of friends, the Metros, or the high-performance, extensible,
easy-to-use web service stack.
OK, I guess you get it. This little
journey lists the set of standards that have been pressed into
service to expose JMX MBeans as
resources. Luckily we didn't have to implement them all. The
JAX-WS (a core Metro
component) and WiseMan
(a WS-Management Java implementation) projects have been of great
Now Sun has announced that the WiseMan
project is to become part of the Glassfish
community. So, it seems to be an appropriate time to look at how
the Web Services
Connector for JMX Agent RI makes use of WiseMan and Metro.
In this article, I will describe how we
changed WiseMan to use
part of the Metro stack, what the benefits were, and finally how
these technologies are leveraged in the Web Services Connector for
Moving WiseMan to the Stack
In 2007, some significant engineering tasks were undertaken in the
WiseMan project to bring the benefits of Metro to WiseMan. This
section outlines the steps that were needed to make this move a
The details of this technology switch are of interest to anyone
who wants to make their existing applications benefit from Metro's
From Servlet to JAX-WS 2.0
WiseMan, was, in its pre-1.0 release, closely coupled with
Servlet. At the time,
Servlet container was the
only way to deploy a WiseMan-based application. We decided to add a
JAX-WS Endpoint to the WiseMan project and suddenly we found we could
be much more agile. Deployments like the Java SE and Java EE
platforms became possible. What a change! For example, being able to
base our test suite on the lightweight HTTP server bundled with
JAX-WS made our lives much easier...
The JAX-WS Endpoint we developed is a Provider<SOAPMessage>.
Simply annotating with @WebService
was not possible. WS-Addressing makes intensive use of SOAP headers
to convey part of the protocol information. To access to such
headers, we need full access to the SOAP Message. After some
redesigning of the existing code we extracted a WSManAgent
Class that is accessible from a JAX-WS Endpoint or a Servlet.
We took this opportunity to switch to the JAXB release contained
So we were happy and impatient to move forward. We already knew
that the JAX-WS team was working on adding WS-Addressing
support and were waiting for it eagerly.
From JAX-WS 2.0 to JAX-WS 2.1
JAX-WS 2.1 comes with support for WS-Addressing. It's a very smart
integration. By just using annotations, your Endpoint becomes
addressable thanks to WS-A.
annotation that you can use to tag your Endpoint implies that the
WS-Addressing 1.0 release is to be used. However, WS-Management
requires the use of
another release of the WS-A standard, which is a great pity. We
discovered that we were not able to leverage this support. We were
afraid this was the end of the road, but the JAX-WS engineering team
came back to us showing us the Metro
specific API. We were not the first customer with a dependency on
Submission and they defined another “non standard but
supported” Annotation to express our requirement :
With this annotation added, we removed
all the code related to WS-A request-response headers.
So we were happy...but not for long.
Our great friends Yves and Sandra of
the JMX QA team started to
develop some simple stress tests and we started to discover horrible
From SOAPMessage to Message
We discovered that 80% of the time spent handling a request was
spent in the DOM/SAAJ layer. That's 80% of some big numbers, too...
You remember? Our Endpoint is a
This means that when called, a SOAPMessage
object is injected and a SOAPMessage
object is expected as the returned value. So we were either stuck, or
we had to re-implement the SOAP layer to rely on the STAX API, or we
were left with our disapointing figures.
Could the Metro API solve this issue?
Yes, the Metro API solved this issue. Once again we were not the
first customer, etc., etc., etc. As a solution, an efficient
implementation of SAAJ, that is very well integrated with JAXB, is
exposed as the Message
API (located in the com.sun.xml.ws.api.message
package). In order to benefit from its power, you must completely
forget all the development you have done on top of SAAJ and rewrite
everything on top of this new API. Which is exactly what we did. OK,
we re-designed it to make both approaches live together nicely, but
we also designed a new API for WiseMan, that was completely isolated
from SAAJ. And things started to work much faster (3 to 4 times
quicker). The numbers were becoming acceptable, for this kind of XML
Current WiseMan Architecture
diagram above shows the different products that are used to build the
WiseMan stack on the client and the server. You can see that
the WiseMan client stack doesn't rely on Metro, yet. A
work-in-progress aims to define and implement such a move, which will
greatly improve performance and ease of use.
Improvements for the WiseMan Project
This move helped the project to:
interoperability and performance are the key words of the Web
Services Connector for JMX Technology. Based on these new
capabilities, WiseMan is becoming the WS-Man implementation
of choice for the Web Services Connector for JMX.
When using this
connector you are not directly in contact with the stack but you
indirectly benefit from the properties you are interested in.
Web Services Connector for JMX Continues Leveraging Metro
This section looks at how the the Web Services Connector for JMX
Technology continues leveraging Metro.
- "Increase performance!"
- "Increase performance? Hmm..."
Simple, use Fast Infoset!
It comes with the stack, it's efficient, it doesn't break
interoperability and it's easy to use. We did it and we experienced
another big improvement. To enable Fast Infoset in your client API,
access the BindingProvider
and provide a Fast Infoset key to the request context. For example:
BindingProvider provider =
requestContext = provider.getRequestContext();
Dispatch<Message> on the client side.
On the client side of the connector, we use the JAX-WS Dispatch
class. A Dispatch
instance can be seen as an Endpoint proxy that deals with the
complete SOAP Message (as opposed to classical JAX-WS proxies that
expose a service level API). Since JAX-WS 2.1, Dispatch
also handles WS-Addressing. Using Metro specific API, we are creating
an efficient Dispatch
that is compliant with the WS-Addressing Membership Submission
The following code extract shows how to create a Dispatch<Message>
for Membership Submission:
Message.class, Service.Mode.MESSAGE, new
Endpoint on the client side
WS-Management defines a way for a WS-Management Agent to deliver
its Events in a PUSH mode. This delivery mode implies that the event
sink (the client) is itself an Endpoint. We deploy a JAX-WS Endpoint
inside our connector client to receive pushed events.
WS-A EndPointReference API
The JMX Web Services Connector RI exposes a non-standard API to
customize the mapping of MBeans to WS-Management resources. In this
API, we allow customers to hook
their customization as low as the WS-Management protocol
itself. We needed a WS-Addressing Endpoint reference to expose.
The JAX-WS class javax.xml.ws.EndpointReference
offers a standard 1.0 representation that we are internally
translating into a Membership Submission via the Metro API (using the
JAX-WS offers support for HTTP Basic Authentication and HTTPS. We
are leveraging both.
HTTP Basic Auth
You provide the credentials to a Dispatcher
via the request context. The following code extract shows how to
provide your credentials.
provider = (BindingProvider) port;
Object> requestContext = provider.getRequestContext();
Server Side Security
The way you secure the server side depends on the container in
which the Connector is deployed. For more details about how to use
the HTTP server bundled in Metro, check the
HTTP server API documentation.
Current Web Services
Based on this architecture, we performed interoperability testing
with WinRM (Microsoft's WS-Management based set of tools and API).
document sums up the scenarios we are testing.
We didn't experience any problems related to interoperability.
Choosing Metro was definitely the right choice. On nearly
all levels it has offered the features we were hoping for. When the
boundaries of the standards were reached, Metro-specific API entered
the scene and offered a solution. Metro really is ahead of the field
in terms of improving performance.
So who is the wise man? The ones who defined such long stacks? No,
I don't think so....
But Glassfish could be. Its management and monitoring features are
based on JMX technology.
So, by deploying the Web Services Connector for JMX (for which the
Public Review specification and Early Access 3 RI will be available
mid-February) in a Glassfish Server, all the existing MBeans (such as
those defined by AMX,
by JSR 77, and by you)
are automatically exposed as WS-Management resources.
You can imagine the long journey we went through. Would you want
to do this on your own, to expose your tiniest resources?
Be wise and use JMX, let us fill in the gaps!
PS: My sincere thanks to
Jitendra and Rama
from the JAX-WS team for their help. Special thanks to Stuart
Clements, my personnal editor and grammar checker.