Paul Monday continues his three-part series on building resource management applications with a look at the Web-Based Enterprise Management (WBEM) initiative. WBEM serves to standardize the description and use of managed resources in enterprise networks. Follow along as Paul describes the components that comprise WBEM, and practice using the technology with a simple filesystem example.

In the first installment in this series, I provided a beginner's introduction to the Federated Management Architecture, Sun Microsystems's standard framework for creating policy-based management solutions for distributed networks. Jiro technology is the sole implementation of the FMA, designed specifically to address the requirements of building management applications for cross-platform distributed storage networks.

In this second installment, I'll focus on a standard that overlaps with the FMA but is more specific to the needs of enterprise computing environments. The Web-Based Enterprise Management (WBEM) initiative, developed by the Distributed Management Task Force (DMTF), is a set of technologies that ease the burden of writing programs and interfaces for managing a complete enterprise environment. Like distributed storage networks, enterprise computing environments assemble hardware and software from a variety of vendors. As a result, network administrators are often required to deploy numerous management applications and techniques, and must constantly learn new technologies in order to remain at the top of their field. Since enterprise networks can -- and in fact must -- exponentially grow in size and complexity, network administrators experience an almost constant learning curve and must fight to stay up with new developments in the field.

By providing a standardized method for accessing managed resources, WBEM vastly simplifies the process of creating management applications, and thus of managing enterprise networks. This translates into larger and more manageable networks of computers, while simultaneously making better use of a network administrator's time and effort.

To get you started with WBEM, I'll provide an overview of the components that comprise the standard and show you how to use them as a framework for developing management applications.

Overview of WBEM

WBEM, which started as an industry initiative in 1996, standardizes the description and use of managed resources in enterprise networks. WBEM consists of several components:

• The Common Information Model (CIM) is a mechanism for modeling managed resources and representing those models in the Managed Object Format (MOF). Using CIM and MOF, the components that make up a managed resource, or a network of resources, can be modeled and viewed in a way similar to that used in an object-oriented design process.
  
  
• The Managed Object Format (MOF) is a formal description of the classes and associations that originate in CIM schemas. MOF is typically its own grammar, but can be translated to XML using a DTD available from the DMTF.
  
  
• Standardized schemas are sets of CIM classes that represent a particular management domain. Schemas exist to represent the core CIM classes, network classes, software classes, and more.
  
  
• A CIM object manager (CIMOM) is a database for instances of CIM classes. CIMOMs represent the central point for accessing management resources.
  
  
• An XML API provides standardized access to data and enables operations on the managed resources that are represented in the CIMOM.

Individual companies provide their own implementations of WBEM, each of which must conform to the specifications put out by the DMTF. All WBEM-compliant technologies must accept the standardized schemas that are published by the DMTF and all associated CIMOMs must be accessible via the standard XML API.

Members of the Storage Networking Industry Association (SNIA) are building an open source CIMOM based on WBEM standards and loosely based on Sun Microsystems' implementation of WBEM. Both the SNIA and Sun implementations are built around the Java platform. Microsoft also provides a WBEM-based solution, with its Windows Management Instrumentation (WMI) technology. (See Resources for a complete listing of WBEM-based technologies.)

In the next sections, we'll talk in depth about the individual components that comprise WBEM. I'll step you through a simple WBEM-based development process, using a filesystem example similar to the one we used in the first installment in this series. The process we'll use to model and build the filesystem should be familiar to you, because it closely mirrors the traditional object-oriented development cycle of modeling (typically via UML) and then programming. We'll proceed as follows:

• Model the environment using CIM modeling techniques.
  
  
• Produce MOFs for classes and associations between the classes.
  
  
• Build dynamic providers for classes that require dynamic data updates.
  
  
• Import the MOF into a CIMOM and populate any static data that is required by class instances.
  
  
• Use the managed object via the API to the CIMOM. (We'll save this step for the final installment in the series.)

I've used the open source CIMOM from SNIA to create the examples for this article. See Resources to download SNIA's CIMOM.

Back to top

The Common Information Model

The Common Information Model (CIM), currently in version 2.2, provides a data modeling environment in the form of object-like design diagrams and a language-neutral description of the model known as the Managed Object Format (MOF). In this regard, the CIM modeling environment and MOF closely parallel the pairing of the Unified Modeling Language (UML) and Interface Definition Language (IDL).

The CIM development cycle is very similar to the object-oriented development cycle, in that you'll develop class diagrams, create language-neutral descriptions of the classes and their associations, implement the classes, then deploy and use the resulting data and operations. CIM development mirrors object-oriented development in two important ways: it uses inheritance to extend existing classes, and it uses class diagrams as its primary mechanism for conveying data structure.

Unlike object-oriented classes, however, CIM classes contain keys that uniquely identify object instances. Pure object-oriented design does not use keys for instance identification (though some object technologies -- such as Enterprise JavaBeans -- do have key definitions). In addition, CIM contains a special association class that behaves much like a database join. The association relates instances, such as a disk enclosure and the physical disks within that enclosure. Rather than creating relationships within the enclosure and disk classes, the association defines the relationship between the two classes. The classes themselves have no knowledge of their relationship. Instances are navigated through associations rather than by explicit queries to the managed resource class instances. Association navigation is made possible through the use of keys in the CIM object instances.

The difference between CIM and pure object-oriented design can be explained by the difference in each environment's intended use. Whereas object-oriented technology has evolved to serve the requirements of creating application programming environments, CIM is specifically suited to describing, cataloging, and interacting with managed resources. To further understand how the CIM works, we should look at the ways its class hierarchy and various schemas are created and structured.

How CIM schemas are created

The DMTF goes through iterations in the standards body to create a layered class hierarchy that correctly represents manageable elements from a variety of areas that require management. Each management area, such as storage or applications, is represented in a CIM schema. Different management areas are worked on by different DMTF standards bodies that specialize in those areas. Figure 1 shows how existing CIM schemas are conceptually layered. A core schema is at the center, and schemas then build on each other to represent more specific management areas.

The core schema is structured along the same lines as the Java platform class hierarchy. The core schema contains classes and associations that are common to all of the management areas. For example, all elements that can be managed inherit from a class known as a CIM_ManagedElement. In Listing 1, below, you can see that a managed element contains a base set of attributes that are common to all manageable entities. We'll talk more about MOF -- the language used in Listing 1 -- in a moment. For now, just observe the structure of the schema.

// ==================================================================
// ManagedElement
// ==================================================================
     [Abstract, Description (
     "ManagedElement is an abstract class that provides a common "
	"superclass (or top of the inheritance tree) for the "
	"non-association classes in the CIM Schema.")]
     class CIM_ManagedElement
     {
       [MaxLen (64), Description (
        "The Caption property is a short textual description (one-"
        "line string) of the object.") ]
       string Caption;
       [Description (
        "The Description property provides a textual description of "
        "the object.") ]
       string Description;
     };

Subclasses of the managed element include logical elements and physical elements, as illustrated by Figure 2, a CIM model. A physical element is something that can be touched and/or barcoded. A logical element often represents a software layer.

Beyond the core schema, individual working groups have created standards for particular fields of management, such as networking, devices, users, applications, and more. These standards extend the core schemas and evolve separately from the core schema, though they tend to be consolidated for new versions of completed schemas. Association classes are also a large part of schema definitions. Base associations exist for common relationships between managed elements.

Back to top

CIM modeling and the MOF

As Figure 2 clearly shows, modeling with CIM is quite similar to modeling with UML class diagrams. Like UML, CIM offers a set of diagrams for modeling a wide range of scenarios. A complete primer on CIM is well beyond the scope of this article, but you should know the basics in order to follow the diagrams as we go along.

CIM uses color coding to convey class structure and the movement of objects through systems over time. Here's what you should notice in Figure 2:

• A blue line indicates inheritance.
  
  
• A red line indicates an association, with the association name labeled on the line. Remember that an association is its own class type.
  
  
• A green line indicates aggregation. An aggregation is a special case of an association.

Key designations follow property definitions and will appear in a diagram as a simple notation: [key]. Note that more than one property can form the key for a particular instance.

MOF and the Java language

The MOF language is defined by the DMTF as a part of the overall WBEM specification. The DMTF has a variety of tools for working with MOF representations of CIM models. The MOF contains a set of intrinsic data types, which you'll find in the CIM spec. For the purpose of this article, we'll concern ourselves only with the essential data types, as follows:

• string: a UCS2 String
• boolean: a Boolean, true or false
• datetime: a string containing a date/time
• uint8: an unsigned 8-bit integer
• int8: signed 8-bit integer

While the types have parallels in the Java language, the parallels are not exact. As a result, you should exercise care when programming with the Java language for a CIM implementation, being especially careful about manipulating data that resides in a CIM object manager.

Looking back to Listing 1, you will note that the CIM_ManagedElement class declaration is preceded by metadata enclosed in brackets. Here's the metadata from Listing 1:

     [Abstract, Description (
     "ManagedElement is an abstract class that provides a common "
	"superclass (or top of the inheritance tree) for the "
	"non-association classes in the CIM Schema.")]

Each declaration in the MOF can be preceded by such metadata. In this case, the metadata tells us that the managed element class is abstract and then provides a description of the class. Different qualifiers can be declared for different data types and declarations. For example, a string could declare a MAXLEN qualifier, which would limit the length of the string, or an array could declare a VALUES qualifier, which would a name a specific set of values to be entered into the array. The CIM specification lists many qualifiers that can be applied to different declarations.

We'll use simple models and MOFs in this article, but you should know that the complexity and subtleties of modeling managed resources and representing those models with MOFs can quickly increase. The lack of complete integrated tool sets makes the environment even more complex to work in. See Resources to download the CIM specification and learn more about CIM modeling and the MOF.

Back to top

How CIM object management works

The entire CIM model and standard extensions are built for further extension by hardware and software vendors. At the completion of an object-oriented design process, you put the design to work. Likewise, once a CIM model and MOF definition are complete, the package is imported into a CIM object manager (CIMOM). The CIMOM provides a central repository where clients in a network can go to gather information about managed resources within the system.

We'll focus for now on how data gets into the CIMOM. In the next installment, we'll focus on how network clients can leverage the data and operational characteristics of managed resources residing in the CIMOM.

Populating a CIMOM

Populating a CIMOM with data starts with importing or creating managed resource definitions in the CIMOM. This is very much like creating a table in a database. MOF files that define complex classes are imported into the CIMOM, and subsequently instances of the classes that relate to a specific managed resource can be created within the CIMOM.

You can use a client interface to create class instances, but that isn't the most common mechanism for populating a CIMOM. Generally, you will either provide static data to the CIMOM or latch in a provider class that will provide dynamic data. Figure 3 is a logical depiction of a CIMOM and its components.

The state of data -- static or dynamic -- will depend on metadata contained in the MOF file. We'll discuss this further in the sections that follow. But first, let's create a simple example to illustrate the processes we'll be discussing.

A simple filesystem

We'll create a MOF that will represent a filesystem to the CIMOM. The filesystem we'll use for our examples is oversimplified, so we'll call it the "simple filesystem." The SIMPLE_FileSystem MOF shown in Listing 3 represents our filesystem implementation.

// ==================================================================
//   SIMPLE_FileSystem
// ==================================================================
class SIMPLE_FileSystem : CIM_LogicalElement
{
        [
        Override("Name"),
        Description("The inherited Name.  The value must be
         overridden to indicate it is now a key value and will be
         retrieved dynamically."),
        Key
        ]
     string Name;
        [Description("The total amount of space available on a filesystem")]
     uint32 TotalSpace;
        [Description("The amount of space that is used in a filesystem")]
     uint32 UsedSpace;

};

Notice that our filesystem inherits from CIM_LogicalElement. Thus, the filesystem inherits the following properties:

• InstallDate (datetime): the date that the object was installed
• Name (string): the name of the resource with a maximum length of 256 characters
• Status (string): a value map qualifier lists the possible values of the status; values include "OK", "DEGRADED", and more
• Caption (string): a short caption, limited by a MAXLEN qualifier to 64 characters
• Description (string): a free-form string description

Something else to observe in Listing 3 is the declaration of the name property. This property actually exists in a superclass. The CIM gives subclasses the ability to change metadata about a property in one of its superclasses. The MOF language requires a redefinition with additional qualifiers that indicate that we are overriding a property from a superclass. Notice the Override qualifier and the Key qualifier added to the metadata for the name property in our subclass.

Once the class is defined, it is loaded into the CIMOM. The mechanism by which classes are loaded into a CIMOM really depends on who implemented the CIMOM and on the existence of tools for using the CIMOM. In the case of SNIA's open CIMOM implementation, a CIM browser is used to connect to the CIMOM and load class definitions into the CIMOM. After connecting to the CIMOM with the browser, you open the MOF file that defines the class. The browser parses the MOF file and uses standard CIMOM client remote calls to create the class definition within the CIMOM.

In the next two sections, you'll learn about the two models for loading instance data into a CIMOM. Under the static data model, data is pushed into persistent storage through the CIMOM's client API. The persistent storage mechanism can vary, and is provided by the CIMOM implementor. Some CIMOMs may use simple file reads and writes for persistent data; others may use JDBC to interact with a database for data persistence. Under the dynamic model, you can plug in provider classes, which will be called to provide class instances as data is requested.

Back to top

The static data model

The static data model is an easy way to populate a CIMOM with data that cannot change over the life of an object instance. Static data can include instance descriptions and instance captions. It is best to provide either a completely static object instance or a completely dynamic object instance. You can either use an instance MOF or a client interface to provide static data to the CIMOM. We'll use a data instance MOF, in this case an instance of our simple filesystem. Under the hood, the CIM browser will use the client APIs against the CIMOM to populate the static data.

A static example

Listing 4 shows an instance MOF. Notice that each of the properties that we want to set has a value associated with it.

instance of SIMPLE_FileSystem
{
      Name          = "Bogus_FileSystem";
      TotalSpace    = 10;
      UsedSpace     = 1;
      InstallDate   = "20010617083159.000001-360";
      Status        = "OK";
      Caption       = "A SIMPLE_FileSystem";
      Description   = "This is a bogus filesystem instance.";
};

Each vendor's CIMOM has its own persistence mechanism for retaining static data. The persistence mechanism may be as simple as a serialized object, or there may be a more complex mechanism for writing data to a database. Qualifiers in MOF files make database storage much easier than the traditional method of flattening Java objects into a database table. Several qualifiers exist for providing data lengths for string data, and for providing value maps. Key qualifiers define indexing and unique object instances, also useful for mapping data to a database.

Back to top

The dynamic data model

In practice, it's rare that all the data you want to provide to the CIMOM will be static in nature. The more interesting managed resources simply aren't static. A provider class allows a client of the CIMOM to gather live data, as well as act on that data. The CIMOM we're using, the open source CIMOM from SNIA, has at its disposal four types of provider class:

• InstanceProvider provides a dynamic list of instances that are available in a CIMOM. For example, at installation time, you may have no way of knowing how many network cards -- if any -- are in a computer system. An instance provider would talk directly to the computer system to determine the number of network cards, then provide a client that requested one or more network card instances with the proper data at request time.
  
  
• PropertyProvider can provide timely data about a managed resource, calling it directly from the resource itself. If there are dynamic instances, it is likely that all of the properties should be dynamic as well and thus the data should be supplied to the CIMOM via a property provider. A good example of dynamic data would be the packet throughput on one of the network cards from the instance provider.
  
  
• MethodProvider is essential to implementing a method on a class. There is no way to implement a method on a class without a method provider. Complex operations are carried out with methods that are defined on the CIM class via the MOF. An example of a method provider would be one that shuts down a computer system or resets counters on a network card.
  
  
• AssociatorProvider is able to build associations between components dynamically. For example, assume the CIMOM has data about a storage volume, but the storage volume is not yet a part of a logical volume, thus no association exists. Through a method on the logical volume manager or an operating system level command that takes place outside of the CIMOM, the storage volume can be associated with the logical volume. At this point, the provider would return an association between the live instances of the logical volume and the storage volume. This type of provider is extremely powerful for connecting loosely coupled instances.

A dynamic example

Our simple filesystem is the perfect example of a class that would use an instance provider and a property provider to represent its data, so we'll focus on those two types of provider class. To use providers, the MOF definition of the class must be modified. The class must indicate which provider class the CIMOM should use to retrieve data. For example, if you wanted the class to use an instance provider, you would add a provider qualifier to the metadata just above the class definition. To use a property provider, you would place a property qualifier in the metadata above an individual property.

Listing 5 shows how we would modify the MOF file to enable our simple filesystem class to use instance and property providers. When we first defined the "Name" property to be our key, we had to bring the definition of Name into our MOF, in order to support the modification to the metadata. To add property providers for the rest of the data, we must again bring in the data definitions. If we don't do this, our providers will be unable to retrieve dynamic data for the superclass properties.

// ==================================================================
//   SIMPLE_FileSystem
// ==================================================================
[Provider("com.ibm.wbem.providers.SIMPLE_FileSystemProvider")]
class SIMPLE_FileSystem : CIM_LogicalElement
{
        [
        Override("Name"),
        Provider("com.ibm.wbem.providers.SIMPLE_FileSystemProvider"),
        Key
        ]
     string Name;
        [
        Override("InstallDate"),
        Provider("com.ibm.wbem.providers.SIMPLE_FileSystemProvider")
        ]
     datetime InstallDate;
        [
        Override("Status"),
        Provider("com.ibm.wbem.providers.SIMPLE_FileSystemProvider")
        ]
     string Status;
        [
        Override("Description"),
        Provider("com.ibm.wbem.providers.SIMPLE_FileSystemProvider")
        ]
     string Description;
        [
        Override("Caption"),
        Provider("com.ibm.wbem.providers.SIMPLE_FileSystemProvider")
        ]
     string Caption;
        [Description("The total amount of space available on a filesystem"),
         Provider("com.ibm.wbem.providers.SIMPLE_FileSystemProvider")]
     uint32 TotalSpace;
        [Description("The amount of space that is used in a filesystem"),
         Provider("com.ibm.wbem.providers.SIMPLE_FileSystemProvider")]
     uint32 UsedSpace;
};

You probably noticed that we're using the same class for both the instance provider and the property providers. This happens fairly regularly, and is good reuse of common code. Once the provider tags are added, the MOF must be reloaded into the CIMOM for the changes to take effect. Once the MOF is reloaded, the CIMOM will look for a dynamic provider in the classpath rather than using its own persistence mechanism.

Back to top

Provider interfaces

The CIMOM uses appropriate interfaces to access data in the various types of providers. As you will see, these interfaces are relatively short. For our final example, we'll run a single provider that uses both instance and property interfaces. For now, however, we'll look at each interface separately.

Listing 6 shows the interface to the instance provider; Listing 7 shows the interface to the property provider. You'll notice that both interfaces use something called CIMObjectPath. An object path identifies a particular instance by the namespace in which it resides, the classname of which the object is an instance, and the key/value pairs that form the unique key for that object instance.

Here's the InstanceProvider interface.

public interface InstanceProvider extends CIMProvider {
      public abstract Vector enumInstances(CIMObjectPath cop,
				      boolean deep,
				      CIMClass cimClass) throws CIMException;
      public abstract Vector enumInstances(CIMObjectPath cop,
					  boolean deep,
					  CIMClass cimClass,
					  boolean localOnly) throws
CIMException ;
      public abstract CIMInstance getInstance(CIMObjectPath cop,
					 CIMClass cimClass,
					 boolean localOnly) throws
					
CIMException;
      public abstract CIMObjectPath createInstance(CIMObjectPath cop,
          CIMInstance cimInstance) throws CIMException;
      public abstract void setInstance(CIMObjectPath cop,
          CIMInstance cimInstance) throws CIMException;
      public abstract void deleteInstance(CIMObjectPath cop)
          throws CIMException;
      public abstract Vector execQuery(CIMObjectPath op,
          String queryStatement,
		int ql,
          CIMClass cimClass) throws CIMException;
}

You probably have an intuitive grasp of the methods you see in Listing 6, but here's how they break down:

• enumInstances provides a list of available instances to the CIMOM. This method comes in two flavors: the first returns a vector of object paths to the instances, the second returns a vector of actual instances to the CIMOM. The only difference in the methods is that the latter takes a fourth parameter on the call. This fourth parameter is required to determine how much data should be provided in the instances that are returned. We'll talk more about this method in the final example.
  
  
• getInstance retrieves a single object instance rather than the enumeration of instances.
  
  
• createInstance creates a new object instance based on the provided information.
  
  
• setInstance allows you to set the data for a single instance.
  
  
• deleteInstance removes a particular instance.
  
  
• execQuery is currently not used in the open source CIMOM; in the future, however, it may be used to push queries into the provider for processing.

The create and delete methods may throw an exception on certain types of instances. For example, a CIMOM cannot create or delete a network card. The network card either exists or doesn't exist.

Now take a look at the PropertyProvider interface.

public interface PropertyProvider extends CIMProvider {
      public abstract CIMValue getPropertyValue(CIMObjectPath cop,
					  String oclass,
					  String pName) throws CIMException;
      public abstract void setPropertyValue(CIMObjectPath cop,
				      String oclass,
				      String pName,
				      CIMValue val) throws CIMException;
}

You'll note that the instance of CIMValue is a wrapper for a CIM data type and its corresponding value. CIM data types don't always match the data types available in the Java platform. To ensure the data is correctly interpreted, you must wrap the data in its complete CIM description.

Back to top

Running the provider

With a basic understanding of the instance and property interfaces, we're ready to run the provider for our SIMPLE_FileSystem. The provider in Listing 8 combines the instance and property interfaces to populate the SIMPLE_FileSystem instance in the CIMOM.

A provider serves essentially the same function as the management facades discussed in the first installment of this series. The data returned by a provider is very similar to that returned by a management facade, but there is considerably more code to wade through because of the additional CIM data types required to work with the generic CIMOM layer. On the whole, a provider processes considerably more data than a management facade does.

I'll explain the most important methods in Listing 8, but I suggest you also take the time to go over the code and documentation on your own. I've left the javadoc directly in the code to assist you in reading it. On a method-by-method basis, here's the stuff you definitely don't want to miss:

• initialize is called when the CIMOM first loads the provider class. If your provider needs to open connections to a resource, this is probably the best place to put that code.
  
  
• enumInstances(op,deep,cc,localOnly) is the method for locating all available instances of the filesystem and returning a vector of instances back to the CIMOM. Note that there is a helper method (getFileSystemInstance) to assemble an instance and return it. Assembling a CIMInstance involves creating an instance of the CIMClass that was sent in, then setting the properties of the new instance. As we saw in the original MOF file, a property is set by its label, such as InstallDate, and a corresponding CIMValue, which represents a CIM data type.
  
  
• enumInstances(op,deep,cc) is the second method for enumerating available instances. It functions by enumerating the path (CIMObjectPath) to each of the objects. Given the object path, the CIMOM could then be requested to prepare more data for an object through the getInstance method call.
  
  
• getInstance is a fairly simple method in our example provider, since we're representing only one filesystem. In a real implementation, however, you would want to work with the object path that was passed in to determine exactly what CIM instance should be returned to the CIMOM.
  
  
• execQuery, setInstance, createInstance, deleteInstance were not implemented in this example. The open CIMOM has a robust set of exception classes. Here, the exception indicates that the called method isn't supported.
  
  
• getPropertyValue returns the value of a particular property. When a particular instance is chosen for browsing (via the browser that accompanies the SNIA CIMOM), a method call to enumerate instances is followed by a series of getPropertyValue calls. Any custom logic would be put into this method or into a helper method to be called by the getPropertyValue call.
  
  
• setPropertyValue is interesting in that it passes a new value into our own Java cached value, in this case the value for the used space or total space. (The other values don't support setting the data). In the current version of the CIM browser, the type of data returned will always be a string value. In a real implementation our code would have to be much more robust to ensure that the data type being passed in matched our expectations (such as UINT32).

You may recall that a variety of caching variables were declared for use in the management facade. Our example provider, however, doesn't implement persistence in any way. As a result, restarting the CIMOM will reset the data. A real filesystem provider would incorporate a type of persistence in the filesystem itself. Data would be retrieved directly from the operating system, so restarting the CIMOM wouldn't pose a problem.

In addition, we declared captions, descriptions, and instance names for this example. There are much better ways to do this in a real provider. For example, you could use resource bundles or some other means of persistence for storage. Currently, WBEM doesn't provide much support for localization.

The primary difference between management facades and providers is the use of generic objects for passing data to and from the CIMOM. This extra layer of code appears to result in a high percentage of change. The reality is quite different. Management layers for typical resources are very complex, thus the extra code is actually a smaller percentage than what appears in our simple example. Hopefully, future implementations of WBEM will include tools that generate much of what is necessary to build a provider, allowing programmers to focus on writing the custom code to interact with specific managed resources.

Back to top

Wrapping up

WBEM provides a standardized modeling environment (CIM), an object repository (the CIMOM), and definitions for standardized client access to the CIMOM (MOF). WBEM's strength lies in the rigorous class standardization process maintained by members of the DMTF.

In this article, we quickly explored the environment modeling and class definition process enabled by the CIM and MOF. We defined a simple filesystem class and practiced using both static and dynamic mechanisms to populate an instance of the filesystem into the CIMOM. Finally, we pulled it all together under a single provider that implemented both static and dynamic mechanisms.

Dynamic providers have significant overlap with the management facades deployed under Jiro technology. Providers offer an advantage over management facades, however, in that they latch into a standardized database that comes with a standard client API to enable data access. As management applications become more complex, WBEM simplifies client-side programming by abstracting hardware and software management processes away from the client. Both client programmers and driver-level programmers can benefit considerably from the standardization and reuse of schema design.

In the final installment in this series, I'll show you how to combine Jiro technology and WBEM into a single, open standards-based management application development platform. As in the previous installments, we'll use simple, hands-on examples to practice as we go along. We'll also talk a bit about the future of management application development, so stay tuned.

Back to top

Download

discuss this topic to forum