Friday Jul 11, 2008

VBScript XML processing to extract JMX content

In a previous post I have presented the details of the VBScript script used to interact with a JMX application in which a Web Services Connector was deployed.

In order to deal with XML namespaces, I wrote a really horrible function based on the knowledge of the namespace prefix name computation. Something that I presented as a very bad way, caused by my lack of expertise in VBScript.

Since this previous post, I have written a bunch of scripts and dived into some VBScript librairies details. I have found the right way to process XML and deal with Namespaces. This is done thanks to XPATH usage. By setting a set of properties on the object returned by CreateObject("Microsoft.XMLDOM"), you can inject prefix/namespace associations. These associations are then usable when selecting XML nodes.

Retrieving the WS-Enumeration enumeration context of an MBean subscription

WS-Man session creation and subscription invocation is detailed in the previous post. The enumeration context must be extracted as follow:
set reply = ...

Dim objXMLDoc
set objXMLDoc = CreateObject("Microsoft.XMLDOM")

' Make the reply to be loaded synchronously
objXMLDoc.async = False

' Load the reply 
objXMLDoc.loadXML(reply)

' Make XPath the selection dialect
objXMLDoc.setProperty "SelectionLanguage", "XPath"

' Associate "wsen" prefix to WS-Enumeration namespace.
objXMLDoc.setProperty "SelectionNamespaces", "xmlns:wsen='http://schemas.xmlsoap.org/ws/2004/09/enumeration'"

' There is a single enumeration node, selectSingleNode returns the first one.
Dim node
set node = objXMLDoc.selectSingleNode("//wsen:EnumerationContext")

' node.text contains the enumeration context value
dim enumContext 
set enumContext = node.text

Retrieving the MBean Notifications pulled from the server

Notification pulling is detailed in the previous post. Extracting all the Messages contained in the list of notifications is done as follow:
set reply = ...
dim replyXml
set replyXml= CreateObject("Microsoft.XMLDOM")
replyXml.async = False
replyXml.loadXML(reply)

' Make XPath the selection dialect
replyXml.setProperty "SelectionLanguage", "XPath"

' Associate "jmx" prefix to JMX Web Services Connector namespace.
replyXml.setProperty "SelectionNamespaces", "xmlns:jmx='http://jsr262.dev.java.net/jmxconnector'"

' Select all the Notification Message nodes text values
set msgList = replyXml.selectNodes("//jmx:TargetedNotification/jmx:Message/text()")

' Display the Messages
for i = 0 To (msgList.length - 1)
    set msg = msgList(i)
    ' Display the notification message
    WScript.echo "Notification : " & msg
next

Conclusion

VBScript API to extract XML content is efficient and simple to use. It is very helpful when extracting values from complex data structures (such as CompositeData or MBeanInfo). Obviously its usage is much wider than JMX interoperability.

Hope this help.

Jean-Fran├žois

Monday Feb 11, 2008

Up the Metro stack to JMX Technology: A Wise Man's Journey

Up the Metro stack to JMX Technology: A Wise Man's Journey


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 WS-Management 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 help.

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 JMX Technology

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 reality.

The details of this technology switch are of interest to anyone who wants to make their existing applications benefit from Metro's features.

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 in Metro.

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.

The @Addressing 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 a Membership Submission and they defined another “non standard but supported” Annotation to express our requirement : com.sun.xml.ws.developer.MemberSubmissionAddressing

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 things...

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 Provider<SOAPMessage>. 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 based processing.


Current WiseMan Architecture




The 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:

  • Improve deployability

  • Improve alignment and reuse

  • Improve interoperability

  • Improve performance

Deployability, 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.

Fast Infoset

- "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 = (BindingProvider) port;

Map<String, Object> requestContext = provider.getRequestContext();

requestContext.put("com.sun.xml.ws.client.ContentNegotiation", "pessimistic");

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 release.

The following code extract shows how to create a Dispatch<Message> for Membership Submission:

Dispatch<Message> port = service.createDispatch(JMXWSConfiguration.JMX_WS_CONNECTOR_PORT, Message.class, Service.Mode.MESSAGE, new MemberSubmissionAddressingFeature(true, true));

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 (Provider<Message>) 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 class com.sun.xml.ws.developer.MemberSubmissionEndpointReference).

Security

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.

BindingProvider provider = (BindingProvider) port;

Map<String, Object> requestContext = provider.getRequestContext(); requestContext.put(BindingProvider.USERNAME_PROPERTY, “user); requestContext.put(BindingProvider.PASSWORD_PROPERTY, “password”);

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 Connector Architecture




Interoperability

Based on this architecture, we performed interoperability testing with WinRM (Microsoft's WS-Management based set of tools and API).

This document sums up the scenarios we are testing.

We didn't experience any problems related to interoperability.

Conclusion

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?

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!

Jean-François Denise

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.

Thursday Aug 16, 2007

Securing JMX Web Services Connector


I have been contacted by a customer of the JSR 262 Early Access 2 who asked me for some material on how to enable HTTPS. I realized that no material was provided. No sample, no blog entry, nothing... Why is there such a lack of documentation? Thinking at it, it appeared that the extreme simplicity of enabling HTTPS for the WS Connector made us forget to provide material for it. This blog entry is trying to correct that and highlight the extreme simplicity enabling HTTPS.

Here, I will present in turn a JDK 5 and a JDK 6 example. The scenario is very common. You have already written a JMX agent and a JMX client. You have already tested that all your JMX MBeans are working well. It is now deployment time! And it is at this precise time that your customer asks you for Security...
You never thought that it could happen to you. You know that security is a complex topic. Encryption, symmetric or asymmetric keys are things that you have heard of but you prefer to stay away from them...
No worries, the JMX WebServices Connector takes charge of all the details. You are just required to configure it. So let's start by securing your ConnectorServer.

Securing the ConnectorServer

Your agent code looks something like :
  JMXConnectorServer server =
                JMXConnectorServerFactory.
                newJMXConnectorServer(new JMXServiceURL("service:jmx:ws:" +
                "//localhost:8080/jmxws"), null,
                ManagementFactory.getPlatformMBeanServer());

  server.start();

Right? This is the very classical way to start a JMX Connector. If this is not the case, if the way you create and start your agent is not similar to this code, please send me a mail (jean-francois dot denise at sun dot com)

So how do you enable HTTPS? Simply by changing the protocol name when creating the JMXServiceURL to be ws-secure instead of ws.

So now your code looks like :
  JMXConnectorServer server =
                JMXConnectorServerFactory.
                newJMXConnectorServer(new JMXServiceURL("service:jmx:ws-secure:" +
                "//localhost:8080/jmxws"), null,
                ManagementFactory.getPlatformMBeanServer());

  server.start();

Are you done? Not yet, you need to provide a KeyStore location and a KeyStore password for SSL to find the certificates. You don't have a KeyStore or a certificate? Not a big deal, use keytool! For example call :

keytool -genkey -keystore jsr262Keystore -keyalg RSA

Answer the questions and provide a KeyStore password. In this blog entry I am using 123456 as the password value. This is something that you should never do in a real context. In this blog entry context, however, is is safe enough.
keytool generates a file named jsr262Keystore. You have now a KeyStore that contains a certificate secured by a password.
If you are running JDK 6, it is enough to actually launch your JMX agent in a secure way. The keyStore and password are provided thanks to two standard Java properties. For example :

java -classpath ... -Djavax.net.ssl.keyStore=jsr262Keystore -Djavax.net.ssl.keyStorePassword=123456 MyJMXAgent

Simple, no? Yes, but what about if I am using JDK 5? Why isn't it so simple?
Simply because JDK 6 has been extended to support a default SSL configuration that relies on the Java properties we previously used (javax.net.ssl.keyStore and javax.net.ssl.keyStorePassword). On JDK 5, you need to provide an instance of javax.net.ssl.SSLContext. Here, I provide you with an SSLContext that reads the standard Java properties in order to compute an SSL configuration. You can use this TestSSLContext Java file that implements the required logic.

How do I pass this SSLContext to the WS ConnectorServer? By using the env map when calling the JMXConnectorServerFactory class.
Your updated source code looks like :
        // Create the SSLContext
         SSLContext ctx = TestSSLContext.getInstance("SSLv3");
        // Create an env map
        Map env = new HashMap(1);
        // Provide the SSLContext
        env.put("jmx.remote.ws.sslcontext", ctx);
        // Create the ConnectorServer providing the env map
        JMXConnectorServer server =
                JMXConnectorServerFactory.
                newJMXConnectorServer(new JMXServiceURL("service:jmx:ws-secure:" +
                "//localhost:8080/jmxws"), env,
                ManagementFactory.getPlatformMBeanServer());
        
        server.start();

You are done, you can start your JMX Agent the same way you did using JDK 6.

java -classpath ... -Djavax.net.ssl.keyStore=jsr262Keystore -Djavax.net.ssl.keyStorePassword=123456 MyJMXAgent

You have now a JMX agent running, waiting for https requests. Let's go secure the client side.

Securing the Connector

This is JDK 5 or 6 independent. You need to replace the ws protocol name with ws-secure as you did on the server side, then provide a TrustStore location and password. The KeyStore named jsr262KeyStore we previously created can be reused by the client.
Your client code looks something like :
 JMXServiceURL url = new JMXServiceURL("service:jmx:ws://localhost:8080/jmxws");
 JMXConnector connector = JMXConnectorFactory.connect(url, null);
 //Get the MBeanServerConnection
 MBeanServerConnection mbsc = connector.getMBeanServerConnection();

Once the JMXServiceURL value has been updated, you code looks like:
 JMXServiceURL url = new JMXServiceURL("service:jmx:ws-secure://localhost:8080/jmxws");
 JMXConnector connector = JMXConnectorFactory.connect(url, null);
 //Get the MBeanServerConnection
 MBeanServerConnection mbsc = connector.getMBeanServerConnection();

When starting the client you provide the TrustStore and password using two standard Java properties. For example :

java -classpath ... -Djavax.net.ssl.trustStore=jsr262Keystore -Djavax.net.ssl.trustStorePassword=123456 MyClient

And... you are done! Extremely simple, no? I hope so, otherwise, let me know ;-).

Some material

Here is all the material I created to write this blog entry. A first NetBeans project containing the source of the agent, the source of TestSSLContext (remember, this is only needed on JDK 5) and the jsr262KeyStore. A second NetBeans project containing the source of the client. You will have to correct some references (mainly JDK, JAX-WS libraries) when opening them but they can help you start securing your app.

Next blog entry to come? Why not use WS-Security (Security applied to the SOAP message) to secure JMX Web Services communication. Stay tuned.

Regards.

Jean-Francois

Tuesday Jun 05, 2007

J2EE Deployment of JMX WS Connector


If you are already evaluating the Early Access 2 of JSR 262, you have perhaps a need to deploy the Connector in your servlet container.
A sample, located in samples/servletdeployment directory, shows you how to achieve such deployment. The provided example shows how to deploy the JSR262 JAX-WS Endpoint com.sun.jmx.remote.ws.wsman.JMXWSManServiceEndpoint inside a JAX-WS compliant servlet container. When created, the endpoint gets a reference to the platform MBeanServer (thanks to java.lang.management.ManagementFactory.getPlatformMBeanServer())
If the MBeans you want to manage are registered inside the platform MBeanServer, you can reuse this sample code. Registering MBeans in the platform MBeanServer is something that we encourage.
If you want to attach the connector to another MBeanServer, then you need to subclass JMXWSManServiceEndpoint and provide your own MBeanServer.

Extending JMXWSManServiceEndpoint JAX-WS endpoint

When extending an annotated class (JMXWSManServiceEndpoint JAX-WS endpoint is annotated), the extended class doesn't inherite from the mother class annotations, you need to re-annotate the extended class.
When deploying in J2EE, no JMXServiceURL is provided to the connector (as opposite to the JMX J2SE way of deploying a Connector). You need to provide to the Connector the URL on which it has been deployed. This is done by calling setURL on JMXWSManServiceEndpoint class. This URL is used when translating from MBean ObjectName to WS-Addressing EPR.

Extended class

The following sample code is a ready to deploy extended class that gets a reference to the first MBeanServer found thanks to the javax.management.MBeanServerFactory class. The URL on which the endpoint has been deployed is hard coded. You can easily externalize it, for example read it from a property file.

import com.sun.jmx.remote.ws.api.JMXWSManDispatcher;
import com.sun.jmx.remote.ws.api.JMXWSManServiceEndpoint;
import javax.xml.ws.WebServiceContext;
import javax.annotation.Resource;
import javax.management.\*;

@javax.xml.ws.WebServiceProvider
@javax.xml.ws.ServiceMode(value=javax.xml.ws.Service.Mode.MESSAGE)
public class ExtendedEndpoint extends JMXWSManServiceEndpoint {
   @Resource
   private WebServiceContext context;

   public ExtendedEndpoint() throws Exception {
       super(new JMXWSManDispatcher(null, 
               (MBeanServer)MBeanServerFactory.findMBeanServer(null).get(0)));
   }

   protected WebServiceContext getWebServiceContext() {
        return context;
   }
}


Packaging the connector

You simply need to update the endpoint implementation in the sun-jaxws.xml file and repackage the extended class in a war file similar to the sample.

sun-jaxws.xml file

<?xml version="1.0" encoding="UTF-8"?>
< endpoints
        xmlns="http://java.sun.com/xml/ns/jax-ws/ri/runtime"
        version="2.0">
        < endpoint
                name="JMXWSManEndpoint"
                implementation="ExtendedEndpoint"
                service="{http://jsr262.dev.java.net/jmxconnector/wsdl}JMXConnectorService"
                port="{http://jsr262.dev.java.net/jmxconnector/wsdl}JMXConnectorPort"
                url-pattern="/jmxws"
                binding="http://www.w3.org/2003/05/soap/bindings/HTTP/">
        </endpoint>
</endpoints>

Conclusion

The simpler way to deploy the Connector is by using the JMXConnectorServerFactory class. This will answer your needs when you want to take benefit of the JAX-WS http server. Direct JAX-WS endpoint deployment is the other way when reusing an existing infrastructure.

Jean-Fran├žois
About

jeanfrancoisdenise

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today