 |
|
 |
 |
|
|
 
Eamonn McManus's BlogJSR-262 and WS-ManagementPosted by emcmanus on November 06, 2006 at 08:53 AM | Comments (5)JSR-262 is defining "A Web-Services Connector for JMX Agents", and I'm the Spec Lead. The Expert Group recently decided to replace the custom protocol that was defined in the Early Draft document with a protocol that builds on the WS-Management standard. Here's the background to that decision. WS-Management and WSDMIdeally a Web Services Connector for the JMX world would build on some existing and standard Web Services protocol. The problem we faced early on in JSR-262 is that there were two such protocols, WS-Management and WSDM. Without getting into the details, the protocols were incompatible and support for them was about evenly split between the major industry players. So rather than choosing one of them arbitrarily, which would have been politically very difficult, we defined a custom protocol. A custom protocolThe custom protocol is defined in the Early Draft document. It is conceptually very simple, and very specific to JMX technology. Basically we defined two XML document schemas, one representing an MBeanServer request, such as getAttribute or queryNames, and the other representing the corresponding reply. Then the protocol basically consisted of a trivial WSDL that defined an operation taking an MBeanServerRequest parameter and returning an MBeanServerResponse. 
(This is simple only conceptually, because it becomes massively complicated once you start getting into the details of how Java objects are serialized into XML inside the requests and responses.) Convergence between WS-Management and WSDMThe picture changed with the publication of the white paper Toward Converging Web Service Standards for Resources, Events, and Management, co-signed by key players in each of the two camps. With this paper, an approach based on an existing standard rather than a custom protocol became possible. Furthermore, we had begun getting feedback that defining a new and arguably rival standard was leading to confusion. From a practical perspective, it is not expected that the converged standard will be finalized before about 2008. JSR-262 is targeted for Java SE 7, which is also scheduled for 2008, but given the necessary lead time to integrate into Java SE, we cannot reasonably wait for the converged protocol to be ready. However, studying the convergence proposal, we can see that its bottom layers are the existing standards WS-Transfer, WS-Enumeration, and WS-Eventing. WS-Management is basically just a definition of how to use these three specifications for management. So if we include WS-Management in version 1.0 of JSR-262, we can plan to support the converged protocol in a later version, and that should be an incremental and compatible change. It will add the new specifications discussed in the convergence document: WS-ResourceTransfer, WS-Transfer Addendum, WS-MetadataExchange 1.1, and WS-EventingNotification. A further advantage of including WS-Management is that we have a much better story for integration into heterogeneous network environments. Previous JMX standards defined a sort of "JMX island". They were very useful provided everything was based around JMX technology. But if parts of your network didn't use JMX technology, then they were cast out of the island. Client use cases for JSR-262Rather than launching straight into a deeply technical exploration of what this change implies for the JSR-262 protocol, I think it is useful to look at what we see as being the client use cases driving our choices. Client use case: JMX Connector ClientThis is a Java client that is using the JMX Remote API to access the server. Ideally, this client should look exactly like a client using another protocol (such as the RMI connector defined by JSR-160). The only difference should be the URL it specifies. So in particular there should not need to be any configuration of XML schemas or the like on the client or server for this use case. 
The switch to WS-Management will be completely invisible to this sort of client. It still establishes its connection with JMXConnectorFactory.connect, using code something like this:
JMXServiceURL url = new JMXServiceURL("service:jmx:ws://blah:8888/blah");
JMXConnector cc = JMXConnectorFactory.connect(url);
MBeanServerConnection mbsc = cc.getMBeanServerConnection();
String osName = mbsc.getAttribute(
new ObjectName("java.lang:type=OperatingSystem"), "Name");
This code is exactly the same as if we were using the RMI
connector that is already part of the Java SE platform, except
that we have replaced The details of exactly what gets sent over the wire do change compared to the Early Draft, of course, since the protocol is now based on WS-Management. But both the client and the server will be updated to reflect the change. Client use case: JMX-aware clientThis is a client, probably not running on the Java platform, that is interacting with JMX resources. For example, suppose you have an app server that exposes the JSR-77 MBeans, and you deploy a JSR-262 connector server on top of it. Then you could write a perl or ruby or C# client that is able to display the various statistics exposed by those MBeans. 
It might be more accurate to call this client "JMX-model-aware". It probably doesn't know what the MBeanServer interface looks like, but it does know the details of one or more JMX models. In the example, it knows what the names of the MBeans in the JSR-77 model are, even if it calls them "Resource Instances" rather than MBeans. It knows what attributes it can expect to find in those MBeans, even if it calls them "properties". Client use case: Specific WS-Management clientThis is a client that is expecting a particular schema or set of schemas for the WS-Management resources it is interacting with. For example, a client that knows about a CIM model and that accesses that model using the standard WS-CIM mapping. In this use case, JMX is just an implementation technology and the client interaction is exactly the same as if it were interacting with a C# agent implementing the same model. 
Not a client use case: using the JMX API to access WS-ManagementWe do not intend to address the use case of a JMX Connector Client that is using the JMX Remote API to interact with arbitrary WS-Management instrumentation. The connector client we define expects the WS-Management agent it interacts with to implement the exact schemas we define. If you need to interact with WS-Management, then you should use a WS-Management client API, such as the one defined by the Wiseman project. The JMX Remote API is not a good fit for this case. XML schemas for WS-Management contentTo understand the WS-Management client use case, you need to
know that WS-Management does not specify the XML schema to be
used for "Management Resources". Suppose you want to
<s:Body>
<PhysicalDisk xmlns="http://schemas.acme.com/2005/02/samples/physDisk">
<Manufacturer> Acme, Inc. </Manufacturer>
<Model> 123-SCSI 42 GB Drive </Model>
<LUN> 2 </LUN>
<Cylinders> 16384 </Cylinders>
<Heads> 80 </Heads>
<Sectors> 63 </Sectors>
<OctetsPerSector> 512 </OctetsPerSector>
<BootPartition> 0 </BootPartition>
</PhysicalDisk>
</s:Body>
The client had better be prepared to deal with the
So to be useful in a general WS-Management context, JSR-262 will have to provide an adaptor in the JMX sense of the word. An adaptor takes a standard protocol such as SNMP or WS-Management and converts it into operations on the JMX MBean Server. In the case of a WS-Management adaptor, it will need to take SOAP headers like these (excerpted)... <wsman:ResourceURI>http://samples.org/2005/02/physicalDisk</wsman:ResourceURI> <wsa:Action> http://schemas.xmlsoap.org/ws/2004/09/transfer/Get </wsa:Action> <wsman:SelectorSet> <wsman:Selector Name="LUN"> 2 </wsman:Selector> </wsman:SelectorSet> ...and derive a JMX ObjectName
like We will define some JMX-specific rules that say how an
arbitrary We will also define a plug-in mechanism that will allow you to
customize these rules for a particular environment, in the WS-Management use case. So you could
could tell the adaptor how to convert
A particular application of this plug-in mechanism would apply to the WS-CIM mapping, as illustrated above. However, to be complete we would also need to specify how CIM classes are translated into JMX MBeans, which is beyond the scope of the JSR. It's definitely something we'll investigate in order to validate the proposed plug-in mechanism. Another way to look at this is that the first two use cases correspond to a situation where you are starting from an existing JMX model such as the JSR-77 MBeans. The third use case corresponds to a situation where you are starting from an existing WS-Management model such as one you might get from applying WS-CIM to a CIM model. So what happens now?We need to rework the specification and the Reference Implementation to take these changes into account. Luckily the work of implementing the WS-Management protocol in the Java language has already been done in the Wiseman project on java.net, which we intend to build on. Once the changes have been made to the specification, we plan
to release another Early Draft. That's probably going to take a
few months, though. In the meantime, comments on this change
are welcome either in public on this blog or in private to Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
CommentsComments are listed in date ascending order (oldest first) | Post Comment
| |
 java.net RSS Feeds
|
