In this conclusion to his three-part series on building management applications, Paul Monday shows you how to combine and leverage the best parts of Jiro technology and the Web-Based Enterprise Management (WBEM) initiative. Using familiar examples from the previous two installments, Paul introduces the WBEM client technologies for accessing and manipulating data in a CIMOM. He then shows you how to access the same data more elegantly and efficiently, by rearchitecting the Jiro management facade to act as the interface to the CIMOM. Finally, Paul talks about the need for greater standardization of Jiro management facades and discusses the future of management application programming under a combined Jiro and WBEM development platform.

Everything we've done thus far in this series has been leading up to this final installment, where you'll learn how to combine the best parts of Jiro technology and the Web-Based Enterprise Management (WBEM) initiative to build management applications. Jiro technology implements Sun Microsystems' Federated Management Architecture (FMA) to enable the definition of service-based management application environments. Under the FMA, services are defined and used as a means of communication between management resources and management policies. Jiro is built and optimized around applications that will manage distributed and heterogeneous resources.

WBEM was developed by the Distributed Management Task Force (DMTF) to ease the process of creating environments for interacting with managed resources. Management environments built according to the WBEM specification stress resource modeling, resource interface standardization, and a common client API that interacts with a managed resource repository known as the Common Information Model Object Manager (CIMOM).

By combining Jiro's strength as a management application technology with WBEM's structured representation of managed resources, you leverage the best aspect of each technology while leaving some of the technologies' respective weaknesses behind. At the same time, you do let yourself in for one heck of a learning curve. Each technology is still in an early stage of its development, and there are few standards in place for working with the two together. As a result, you will have to learn both technologies well, and apply your ingenuity to bridging them. I believe this approach offers many rewards, and that the challenge is inherent to working with management applications. We'll discuss some of the specific hurdles involved with combining Jiro and WBEM, and also talk about some of the development efforts sponsored by the DMTF and others.

WBEMsource initiative boosted by announcements at JavaOne The Open Group recently joined with the numerous industry leaders, including SNIA, Sun Microsystems, Caldera International, and the b4wbem project, to form the WBEMsource Initiative. Announced June 6, 2001, the initiative's stated goals are to: Create an environment that fosters open source WBEM implementations Encourage open source contributions to that environment Create standards and testing procedures that promote interoperability between open source WBEM implementations Sun made good on its commitment to the initiative this year at JavaOne, with the announcement that it would open source its Java-based implementation of WBEM, called WBEM Services. The Open Group is actively seeking contributors to the initiative, and Java developers are being encouraged to develop for the newly open sourced WBEM Services. See Resources to learn more about how you can contribute to the project, which will be hosted by SourceForge.

Before we delve into working with Jiro and WBEM together, I'll introduce the various interfaces for accessing and manipulating data in a CIMOM. The examples we use here follow directly from the examples used in the second article in this series. They are based on the open source CIMOM available from the Storage Networking Industry Association (SNIA). See Resources to download the open source CIMOM.

WBEM client technologies

You have a number of options for accessing data and performing operations against a CIMOM. The DMTF supports a data-access standard known as XML over HTTP, which all CIMOMs must implement to be compliant with WBEM. In addition, most CIMOM vendors provide a high-level object access API that writes XML to the CIMOM for you. This unique API also provides some type safety and a more logical way to assemble request documents and send those documents to the CIMOM. The high-level API may also interact with the CIMOM via a vendor-specific path such as Remote Method Invocation (RMI). RMI allows you to avoid document creation and parsing at the process boundaries, and also negates the need to use a parser, thus increasing speed and decreasing the application's footprint.

I'll introduce you to the basics of using XML over HTTP to interact with the CIMOM, then show you how to work with the high-level API that comes with the SNIA CIMOM. Later, we'll use this API as the foundation for bridging a Jiro management facade and the open source CIMOM.

Accessing data using XML over HTTP

Requests, responses, and faults are among the messages that can be passed through XML over HTTP into an active CIMOM. Unlike the Simple Object Access Protocol (SOAP), XML over HTTP was built to target the CIMOM and its capabilities. While SOAP is quickly gaining industry acceptance and is finding its way into some implementations of WBEM (such as Microsoft's Windows Management Instrumentation), it was not designed specifically for the CIMOM and is not part of the WBEM specification.

Operations that can occur against a CIMOM fall into two categories:

• Intrinsic methods are called against a particular namespace. These methods often involve namespace queries or life-cycle operations.
  
  
• Extrinsic methods are called on particular classes or instances that exist within a namespace.

Intrinsic methods are well defined and are part of the specification. Extrinsic methods parallel the definition of a method within a MOF, a process I explained in the previous installment of this series.

Any XML request document you submit to a CIMOM must contain the namespace on which to perform the desired operation, the request type, and any parameters that must be submitted to the method for it to complete. Listing 1 is an XML document that makes a request of the CIMOM for our familiar simple filesystem example. Listing 2 contains the response document. For the sake of brevity, I've left off the necessary HTTP request header. You should review the WBEM specification on your own to learn about the definition of the HTTP header.

<?xml version="1.0" encoding="utf-8">
<CIM CIMVERSION="2.0" DTDVERSION="2.0">
     <MESSAGE ID="87872" PROTOCOLVERSION="1.0">
        <SIMPLEREQ>
           <IMETHODCALL NAME="EnumerateInstances">
               <LOCALNAMESPACEPATH>
                  <NAMESPACE NAME="root"/>
               </LOCALNAMESPACEPATH>
               <IPARAMVALUE NAME="ClassName">
                  <CLASSNAME NAME="SIMPLE_FileSystem"/>
               </IPARAMVALUE>
               <IPARAMVALUE NAME="LocalOnly">
                  <VALUE>TRUE</VALUE>
               </IPARAMVALUE>
               <IPARAMVALUE NAME="DeepInheritance">
                  <VALUE>TRUE</VALUE>
               </IPARAMVALUE>
           </IMETHODCALL>
     </MESSAGE>
</CIM>

The method request operation above contains the following elements:

• SIMPLEREQ tells the CIMOM there is a single contained method call, as opposed to a more complex MULTIREQ.
  
  
• IMETHODCALL identifies an intrinsic method call, along with its name, EnumerateInstances.
  
  
• LOCALNAMESPACEPATH allows one or more namespaces to be listed as targets for the method request.
  
  
• IPARAMVALUE allows you to specify method parameters.

Upon receiving the request document, the CIMOM returns a response document. The response may contain either a fault or a complete listing of the class instances identified in the request. Listing 2 shows the complete listing in response to our request.

<?xml version="1.0" ?>
<CIM CIMVERSION="2.0" DTDVERSION="2.0">
     <MESSAGE ID="0" PROTOCOLVERSION="1.0">
        <SIMPLERSP>
           <IMETHODRESPONSE NAME="EnumerateInstanceNames">
              <IRETURNVALUE>
                 <INSTANCENAME CLASSNAME="SIMPLE_FileSystem">
                    <KEYBINDING NAME="Name">
                       <KEYVALUE VALUETYPE="string">
                       A_Simple_FileSystem
                       </KEYVALUE>   
                    </KEYBINDING>
                 </INSTANCENAME>
              </IRETURNVALUE>
           </IMETHODRESPONSE>
        </SIMPLERSP>
     </MESSAGE>
</CIM>

Some things you should notice about the response document:

• SIMPLERSP parallels the SIMPLEREQ from the requesting document, in that only one response is enclosed in the return document.
  
  
• IMETHODRESPONSE is the name of the intrinsic method that this response addresses.
  
  
• INSTANCENAME is the class instance that was being queried for instances.
  
  
• KEYBINDING/KEYVALUE tags identify keys and their types. For the type of enumeration we requested, only the keys of the classes are returned.

You could receive a fault response for a variety of reasons. The target namespace might not exist. You may have passed invalid parameters on the request. Or access may be denied to the namespace.

Creating valid XML documents and parsing the response documents returned by the CIMOM is a lot of work. While general-purpose XML parsers can go a long way in helping you create and parse documents, you'll more likely rely on a high-level interface, such as the one that comes with the SNIA's open source CIMOM.

Back to top

High-level interfaces to the CIMOM

When it comes to interacting with the CIMOM at the object level, you will eventually have two choices: to use an interface that is unique to a particular CIMOM implementation or to perform your own code-generation operation for particular classes that you will interact with from the application layer. The code-generation option is a ways off (toolkits are being developed but they're not here yet), so we'll focus on working with an object interface.

Any implementation of WBEM will likely include a high-level object that encapsulates interactions with its CIMOM. This approach doesn't completely replace the XML over HTTP interaction; in fact, XML over HTTP will often be used to move the requests of the CIMOM across the network. To make a request against an unknown CIMOM, you would have to ensure a particular WBEM API used XML over HTTP; when working with a known CIMOM, however, you would likely use that CIMOM's optimized object interface. For example, the open source CIMOM can be switched via a class factory to use either XML over HTTP or an RMI object interface. When working with this CIMOM, the RMI interface provides much faster data access than XML over HTTP. The data access method you use is actually hidden, except for a single method call at the start of an application to configure the type of interaction that will occur with the CIMOM.

Listing 3 duplicates the work of the XML document transactions shown in Listing 1 and Listing 2, but is written to the open CIMOM's RMI object interface.

package com.ibm.wbem.client;
import org.snia.wbem.client.*;
import org.snia.wbem.provider.*;
import org.snia.wbem.cim.*;
import java.util.*;
import java.io.*;

public class ClientSample {
     public static void main(String args[]){
        /**
         * A local representation of the remote CIMOM
         * used for submitting requests to the CIMOM
         */
        CIMClient cc=null;
        /**
         * A logical partitioning of the namespace
         * in the remote CIMOM
         */
        CIMNameSpace clientNameSpace=null;
        int portNo=80;                    // cimom port
        String hostName = "localhost";   // host for cimom
        String nameSpace = "root"; // namespace
        String hostURL;                   // URL representation
        // passing in a parm indicates a remote cimom
        if (args.length==1) {
           hostName=args[0];
        }
        // set up the CIMOM URL
        hostURL="http://"+hostName+":"+portNo;

        try {
           // create a namespace to operate in
           clientNameSpace = new CIMNameSpace(hostURL, nameSpace);
           // create a client to the remote CIMOM
           // - namespace identifies the logical group of instances
           //    that we want to work with within the CIMOM
           // - CIMClient.XML says to use the XML over HTTP protocol,
           //    as opposed to any non-standard mechanisms the CIMOM
           //    may support
           cc = new CIMClient(clientNameSpace,null,null,CIMClient.XML);
        } catch (CIMException e) {
           System.err.println("Failed to access CIMOM: "+e);
           System.exit(1);
        }
        /*
         * Return all instances within the name space identified
         *  by the object path to a "SIMPLE_FileSystem" class
         */
        CIMObjectPath path=new CIMObjectPath("SIMPLE_FileSystem");
        try {
           Enumeration en1=cc.enumInstances(path,CIMClient.DEEP);
           if (en1!=null) {
              while (en1.hasMoreElements()) {
                 CIMObjectPath obj=(CIMObjectPath)(en1.nextElement());
                 System.err.println("Found object path:"+obj.toString());
              }
           }
        } catch (CIMException ce) {
           System.err.println("Failed to fetch 
             enumeration of instance paths:"+ce);
           System.exit(1);
        }
     }
}

The code path shown in Listing 3 is as follows:

1. Create a CIM namespace object that identifies the physical location and the namespace within that physical location.
   
   
2. Create a CIM client that represents the connection to the namespace.
   
   
3. Create an object path that identifies the class type that will be located in the namespace. An object path can be further identified by keys on an instance, thus identifying one or more instances in a more exact way than identification by class alone.
   
   
4. Submit a request to the CIMOM via the CIM client object instance to enumerate the instances identified by the object path created in Step 3. This request creates the XML document from Listing 1, submits it to the CIMOM, and waits for a response. The response, Listing 2, is returned to the CIM client, parsed, and converted to a data structure we can enumerate over.
   
   
5. Each instance is identified by an object path with the proper keys. We could use this object path to obtain a CIMInstance object and interact directly with the instance.

The advantage to using high-level object interfaces is that you don't have to create the documents yourself and you don't have to parse the results returned by the CIMOM. For example, when a CIMClient object instance is created, all of the intrinsic methods are available as first-class object method calls on the CIMClient instance. There is substantially less room for error in using the methods in the high-level interface than in an XML interface. There is also substantially less burden involved in constructing the XML documents.

Code generation is a promising method for creating requests to and parsing responses from a CIMOM. WBEM implementors are currently working on toolkits that will allow users to generate CIMOM access classes directly from MOFs or from classes that exist in a CIMOM. This technique should provide ease of data access in a type-safe and standardized manner. Unfortunately, it's a little bit further out on the timeline than the currently available classes, which simply create and parse the XML interactions with the CIMOM. See Resources to learn about WBEM-compliant code-generation toolkits.

Now that you've been introduced to the mechanisms to access and manipulate data in a CIMOM, we can get down to the business of combining our two technologies. Using the techniques demonstrated in the next section, you can create a robust, open standards-based development platform on which to build your management applications.

Back to top

Bringing Jiro and WBEM together

In the first article in this series we talked at length about the Jiro management facade. The management facade exists to break down a managed resource to components, and then allow access to those components through defined control points. The CIMOM works in a similar way, serving up a managed resource's control points for use.

In theory, services should be able to access a resource's control points and data directly, but there are two drawbacks to this approach. The first is duplication of effort between multiple services that must access the same data. Basically, every service would have to write generic CIMOM access code, which can be tricky to write due to generic data handling. The second drawback is that managed resources are often spread out among many CIM classes. A RAID device, for example, consists of disk enclosures, disk drives, power supplies, and network interface cards -- not to mention all of the association classes between these classes.

Fortunately, there's a workaround to all the hassle these drawbacks could cause. By rearchitecting the Jiro management facade to act as the interface to the CIMOM, we effectively convert the database-like model of the CIM into a more object-like model for our application.

A working example

In Figure 1, you see a CIMOM stack diagram with information on where the Jiro management facade and Jiro management policy will fit into the stack.

Before we go further, let's quickly review the construction of the implementation stack, applying the application-centric view defined by the Jiro management facade. The components in the implementation stack, starting from the Jiro management policy and working down to the managed resource, are as follows:

• Jiro management policies are on the top of the stack (except for clients). They pull together resources and other services and trigger changes based on a set of rules. The DMTF is currently working on defining how policy information can reside in the CIMOM. The organization's first effort centers on quality of service (QOS) attributes. Policies interact with Jiro management facades. Were data to reside directly in the CIMOM, management policies would simply use an object interface to the CIMOM to interact with that data.
  
  
• Jiro management facades are responsible for representing managed resources into a management domain. In the first article in this series, you saw that a management facade can be written to interact directly with a managed resource. This time we're focusing on how the management facade can interact with the CIMOM to obtain the same results. Both are valid behaviors since the FMA does not define how to acquire data, only how to use it. When a CIMOM is used to represent a managed resource, the management facade accesses data and resource operations through an object interface to the CIMOM.
  
  
• The CIMOM itself may be acquired in one of many ways. You could use an open source CIMOM such as the one we've used throughout this series; you could use a proprietary CIMOM like those from Sun and Microsoft; or, if you're working within a larger company, you could have reason to write your own CIMOM.
  
  
• The managed resource supplies data to the provider after a call is forwarded to the provider by the CIMOM. The CIMOM interacts with the provider through an interface that is provided by the WBEM implementation, and that the provider implemented, as shown in the previous series installment.

In Listing 4, the latest iteration of our simple filesystem example, I've replaced the oversimplified mechanism for gathering total space and used space in the management facade with a mechanism that requests this data from a CIMOM. If you recall, in the last article we built a provider that plugs into the CIMOM and achieves the same task. In a real filesystem management facade, the code we are replacing would actually be code that delves into native operating system code to acquire information about the filesystem. To allow the management facade to interact with the CIMOM, I've also had to add some variables to record the CIMOM that we will work with, and where it's at. In reality, the code that interacts with the CIMOM would be much more complex, but dynamic. For example, the host name for where the CIMOM resides would not be hardcoded; it would be read from a property file or set via a method on the object. Listing 4 shows a Jiro management facade interacting with a CIMOM.

Once again, we're working with a lot of code. Much of the weight of this example (as with previous examples in this series) comes from interacting with standardized APIs and interfaces. In an enterprise environment that managed complex resources, a smaller percentage of code would be spent interacting with resources and more code would be dedicated to actual services.

To allow the Jiro management facade to act as the interface to the CIMOM, I've made the following changes to the original filesystem example presented in the first article in this series:

• I added additional instance variables for interacting with the CIMOM. The most important are the CIMClient and CIMObjectPath. The CIM client object interacts with the CIMOM, the object path lets the CIMOM know exactly what managed resource we're trying to interact with.
  
  
• I changed each get or set method to route the data request to the CIMOM. To do this, the data we are looking for is identified in the CIMOM request that occurs with the object path and is on the CIM client object instance.
  
  
• I added an additional method to retrieve the CIM client.

While the SimpleJavaFileSystem implementation has changed, and it had to be recompiled, it is the only class that was modified from the first article. The service that operates against the management facade and any clients that operate against it require no changes. From this, you may gather that combining Jiro and WBEM is a fairly simple process -- and in some regard it is. We've standardized the mechanism by which the management facade can access and operate on managed resources within the CIMOM. What we need beyond this mechanism, however, is a standard Jiro management facade for accessing data within a CIMOM. For this, we will have to create interfaces for the Jiro management facades and/or build tools that generate management facades based on more high-level device descriptions. The effort to create and standardize these interfaces and tools is current and ongoing. And it is this effort that will determine the future of management application programming.

Back to top

Standardization and Jiro technology

The combination of Jiro and WBEM is clearly a powerful one and will likely continue to evolve as the development platform of choice for those of us who focus on management applications. Lack of standardization across the two technologies is no small hurdle, but solutions are on the horizon.

The DMTF and SNIA are working together to develop standard device profiles that can be ported to the Jiro platform. A profile is a template designed to jump-start a company in its efforts to model a device. So, for example, a RAID profile would include a set of class definitions and associations generic to all RAID devices. As you've seen, it's fairly simple to generate a management facade interface from a CIM class. The profiles, however, will make it easier to build management facades that represent devices, rather than device components.

I am assuming in all of this discussion that management facade interfaces will be standardized, as we have practiced here, by converting CIM classes to Java interface classes. I make this assumption because this is the method most likely to further the rigorous standardization process established by the DMTF for creating CIM classes, schemas, and profiles. Of course, it will actually be up to the Jiro technology community to determine the process by which the technology's interactive mechanisms -- such as interfaces, events, and log entries -- will be standardized. Interestingly, most of the members of the Jiro community, and all of those who have been involved in the JavaOne conference and demos over the last two years, are also active participants in SNIA or the DMTF or both. Therefore, it is with some certainty that I say that WBEM and the Jiro will continue to evolve in a coherent direction.

Back to top

The future of management application programming

The work of combining the Jiro platform and WBEM isn't for the faint of heart, especially in these early days of the technologies' development. The learning curve involved in leveraging the strengths of the two environments is steep, though I would argue that overcoming it is rewarding. If your work is to develop providers for vendor-specific manageable resources, you'll need to be strong in the areas of CIM modeling and provider implementation. If you're a solution provider building on top of a CIMOM, you should be versed in both client programming against WBEM's generic API and distributed application programming on the Jiro platform.

Ultimately, widespread adoption of Jiro and WBEM as a single development platform will yield many advantages. These three are key:

• Management application programmers will be able to use one standardized platform for acquiring management information and operating on managed resources with that information.
  
  
• Hardware and software vendors will be able to reuse common management models and allow access to management control paths in a way that is consistent with other managed resources.
  
  
• Management applications will be built to access resource data in a standardized fashion. Standardization will broaden the reach of management applications to all devices that support WBEM, a vast improvement over the current model, which supports only devices for which there are specific implementation stacks.

In addition to the individual benefits of using Jiro and WBEM as a single development platform, the field is open for those who want to provide tools that bridge the two technologies, or client-side tools for working with WBEM. Resource vendors are very much in need of software that will assist them in building providers and modeling their resources, as well as tools to automate the creation of common programming interfaces. The implementation of Jiro management facades is ongoing and is of great value to the programming community. To learn about ways you can become involved in these efforts, see Resources.

Back to top

Conclusion

This series of articles on management application programming has explored the Jiro technology, the technologies and standards that comprise WBEM, and how to combine Jiro technology with WBEM to create more powerful, open standards-based management applications. I hope these articles have helped you to learn about Jiro and WBEM and to better understand the potential architectures that may be born of using the two technologies together.

Back to top

Download

discuss this topic to forum