Introduction to WBEM.

Web Based Enterprise Management (WBEM), designed by the Distributed Managed Task Force (DMTF) in 1996, aims at solving one of the main problems of IT professionals - it easily manages heterogeneous hardware. Existing system management tools are becoming increasingly complex, solutions such as Simple Network Management Protocol (SNMP) do not have enough functionality. The wide diversity of hardware, each with its own custom management interface, uses more resources and time to manage. WBEM, with its roots in proven technologies, offers a common framework which is adaptable by vendors, standards based, extensible, re-usable, and highly adaptable to new hardware. All of this translates into a cost saving enhancement path.

To understand Web Based Enterprise Management (WBEM) it is important to understand its concepts and goals, architecture model and the four main standards that govern WBEM. They are the Common Information Model (CIM) specification, the CIM/XML encoding specification, the CIM over HTTP transport standard, and the DMTF Schema.

WBEM Concepts and Goals

Web Based Enterprise Management is an End-to-End interoperable management suite. The foundations of WBEM reflect this goal by being built with these four major concepts in mind:

1. Reduced Total Cost of Ownership - interoperable management lowers the man-hours needed.
2. Improved Time to Market - using standards.
3. Reduced Development Time - existing information models can be used or expanded upon.
4. Support for other management solutions - migration support for SNMP, DMI, etc.

Furthermore it also re-uses many proven and good concepts found in existing system management solutions, such as event-based notifications (traps and notifications in SNMP), expandability (object oriented paradigm), security (HTTPS), and more. 

Comparison to existing solutions

Compared to existing solutions, such as SNMP, Web-frontends, Telnet, WBEM has all of the advantages that the existing solutions combined have. Also, while existing solutions offer a resource or a problem oriented view, WBEM offers both views and more. It also offers a big picture view, allowing the user to focus on the the big picture of the eco-system of systems, networks, users, policies, applications, etc. and concentrate only when needed on the detailed view. Furthermore the data is interoperable - meaning it carries the same meaning across various platforms.

WBEM Architecture

Figure 1 WBEM Architecture.

Web Based Enterprise Management (WBEM) is a three-tiered model. The front-end is called the Common Information Model (CIM) client, also known as the management application. Existing products such as IBM Director, or KDE CIM Browser are examples of CIM clients. The middle-layer, the CIM Object Manager, handles the communication between the CIM Client and the Provider. Examples of CIMOMs are OpenPegasus and OpenWBEM. Developers write the layer underneath the CIMOM; this layer consists of providers, which manage resources. The last piece, which is part of the CIMOM, is the repository. It is used to store static and dynamic data.

Common Information Model specification

The language used throughout WBEM is defined in the Common Information Model (CIM) specification, located at (http://www.dmtf.org/standards/cim/cim_spec_v22.). The language has roots in the object-oriented paradigm and in Interface Definition Language (IDL). The CIM language syntax is defined and represented by a Management Object Format (MOF) and Unified Modeling Language (UMF) were applicable. The UML is used to graphically represent complex dependences of the classes. The MOF is for compilers which can understand an augmented Backus Naur Form more easily than graphical pictures. The CIM language is not a pure object-oriented language, as it borrows concepts from other paradigms and disciplines. The fundamental concepts, such as classes, instances, inheritance, qualifiers, methods and properties are from the object oriented world. References and associations are derived from relational database concepts. Triggers and Indications come from the system-management world.

Classes, subclasses, and instances

The most elemental part of the language is the type of data. The data types are: integer (8-bit, 16-bit, 32-bit, unsigned and signed), float (32-bit, 64-bit), double, boolean, character, string or reference. The data is utilized by a property which is a named value. A property has also qualifiers, that determine the data type, and restrictions. For example, the value can only be from 2 to 230. The operators on the data are named methods. Methods manipulate the data and can accept any number of parameters of varying data types. The parameters can be both copy-in and copy-out to accommodate passing of values. The container of methods and properties is a class. The following is an example of such as defined by the MOF language. The class Vehicle contains three properties: Name, VIN and Speed.

class Vehicle {
      [Key, Description (
          "The vendor's name of the vehicle")]
   String Name;
      [Key, Description (
          "The Vehicle Identification Number")]
   String VIN;
      [Description (
          "MPH of the vehicle")]
   Uint8 Speed;
};

Figure 2 Vehicle class.

The class is just a skeleton and does not hold any real values. That is the job of an instance, which contains the "live" data. The following are two example instances of class Vehicle.

instance of Vehicle {
   Name="Ford Mustang GT";
   VIN="1FAFP90S45Y400167";
};

instance of Vehicle {
   Name = "Ford F-150";
    VIN = "1FTPW14514KA10653";
};

Namespaces

A collection of classes is called a namespace. Namespaces can contain thousands of classes or just a few. Namespaces are used to seperate between different realm of uses. For example, there can be configuration realm - "root/PG_Internal" with only configuration classes, "root/cimv2" with classes defined by DMTF, etc.

Inheritence

Another object-oriented concept found in CIM is the inheritance mechanism. For non-object oriented readers, inheritance is exactly what it sounds like. Similar to a child inheriting the traits of its parents, a class can inherit properties of another class. The parent is a super-class, the child is a subclass and that is as far as the analogy goes. In CIM, a subclass (child) can only have one superclass (parent). The properties and methods are inherited by a sub-class can be overridden if needed. An example of sub-class is the class Motorcycle, a subclass of the Vehicle superclass, which looks like this:

class Motorcycle : Vehicle {
      [Description (
          "Number of wheels")]
   Uint8 Wheels;
};

Figure 3 Subclass of Vehicle superclass.

References and object-path

Another concept, derived from object-oriented paradigm and relational databases, is the reference mechanism. In the object-oriented world, a class can "reference" or "point to" another class. However in CIM it is not just a one-way reference (class A has a reference to class B), but a two-way reference (class A reference class B and class B references class A). This two-way connection is used in relational databases to allow a table (class) to reference another table (class). A reference is a set of keys. Keys are special properties of a class which can be used to uniquely describe and identify an instance. In the Vehicle example, the two properties Name and VIN are Keys. The set of those properties is a reference. An example of a reference from the Vehicle instances defined earlier would be:

Name="Ford Mustang GT",VIN="1FAFP90S45Y400167"

The reference combined with the namespace is the object path. For example, the object path to the above reference of instance Vehicle existing in namespace "root/sample", would be:

root/sample:Vehicle.Name="Ford Mustang GT",VIN="1FAFP90S45Y400167"

Associations

There are three types of references: 1-to-1, 1-to-many, and many-to-many (N-M). CIM uses a specific class container called Association to hold the reference information. The Association class has only two properties. These properties are the references.

To specify the right type of relationship - 1-to-1, 1-to-many, many, or N-M, one needs to use qualifiers in the association class. If not used, the default is an N-M relationship. An example, using the previous class Vehicle and a newly defined class Engine (with two instances), is the Association class Vehicle_Engine:

class Engine {
      [Key, Description (
          "Serial number of the engine")]
   String SerialNumber;
      [Description (
          "Name of engine ")]
   String Name;

};

instance of Engine {
  SerialNumber = "123902A323";
  Name = "8 CYLINDERS 5.4 Liters";
};

instance of Engine {
  SerialNumber = "839234989AA3";
  Name = "8 CYLINDERS 5.4 Liters";
};

   [Association]
class Vehicle_Engine {
      [Key, Min ( "1" ), Max ( "1" ), Description (
          "The reference to the vehicle.")]
   Vehicle REF InVehicle;
      [Key, Min ( "1" ), Max ( "1" ), Description (
          "The reference to the engine.")]
   Engine REF HasEngine;
};

Figure 4 Association class Vehicle_Engine and Engine class.

Hence a Vehicle can have one Engine (HasEngine), while an Engine can be in one Vehicle (InVehicle).

As is the case with classes, this is just a skeleton. An instance would actually carry the real-data:

instance of Vehicle_Engine {
   InVehicle="Vehicle.Name=\"Ford Mustang GT\",VIN=\"1FAFP90S45Y400167\"";
   HasEngine = "Engine.SerialNumber=\"123902A323\"";
};

instance of Vehicle_Engine {
   InVehicle = "Vehicle.Name=\"Ford Truck\",VIN=\"1FTPW14514KA10653\"";
   HasEngine = "Engine.SerialNumber=\"839234989AA3\"";
};

Indications and Triggers

The two last concepts in CIM are indications and triggers. Both have roots in System Management. One of the most common system management protocol is Simple Network Management Protocol (SNMP). SNMP sends notifications when something changes. For example when the temperature of the CPU reaches a high threshold value a notification would be sent. In most cases, the implementor of a SNMP agent is responsible for programaticily defining the trigger criteria for notification. Hence the user would be unable to change the criteria. For example the user may want additional notification when the CPU returns to a nominal temperature. CIM allows the user to define triggers (criteria's) using a query language. For example to find out when a Vehicle has reached speed of 120 or higher, an SQL projection can be used:

SELECT Name, VIN From Car WHERE Speed >= 120;

When this trigger is reached, a temporary instance of the class called Indication is sent to the user. The indications are kept until the user acknowledges receiving them, after which they are deleted.

Besides the CIM language constructs, the CIM language specification defines a set of primitive classes and qualifiers, called Meta Schema. These classes and qualifiers are the building blocks of the DMTF Schema, which is explained in details later on in this article.

CIM/XML encoding specification

Web Based Enterprise Management (WBEM) uses proven technologies to communicate. The "Representation of CIM in XML" specification (http://www.dmtf.org/standards/documents/WBEM/DSP201.html) defines the mapping of Common Information Model (CIM) to Extensible Markup Language (XML). It reads as any dry RFC and describes the mapping of the CIM concepts to XML. It is worth noting that during the translation of a MOF to XML (or vice-versa) no information is lost. Classes distributed by vendors can be distributed as XML.

The following is a representation of the instance Vehicle in XML:

<INSTANCE  CLASSNAME="Vehicle" >
   <PROPERTY NAME="Speed"  CLASSORIGIN="Vehicle" PROPAGATED="true" TYPE="uint8">
      <QUALIFIER NAME="Description" TYPE="string" TRANSLATABLE="true">
         <VALUE>MPH of the vehicle</VALUE>
      </QUALIFIER>
    </PROPERTY>
    <PROPERTY NAME="Name"  CLASSORIGIN="Vehicle" TYPE="string">
      <QUALIFIER NAME="Key" TYPE="boolean" OVERRIDABLE="false">
         <VALUE>TRUE</VALUE>
      </QUALIFIER>
      <QUALIFIER NAME="Description" TYPE="string" TRANSLATABLE="true">
         <VALUE>The vendor&apos;s name of the vehicle</VALUE>
      </QUALIFIER>
         <VALUE>Ford Mustang GT</VALUE>
    </PROPERTY>
    <PROPERTY NAME="VIN"  CLASSORIGIN="Vehicle" TYPE="string">
      <QUALIFIER NAME="Key" TYPE="boolean" OVERRIDABLE="false">
         <VALUE>TRUE</VALUE>
      </QUALIFIER>
      <QUALIFIER NAME="Description" TYPE="string" TRANSLATABLE="true">
         <VALUE>The Vehicle Identification Number</VALUE>
      </QUALIFIER>
      <VALUE>1FAFP90S45Y400167</VALUE>
    </PROPERTY>
</INSTANCE>

CIM Operations over HTTP

The next specification, "CIM Operations over HTTP" defines what a management application can do over the wire with CIM and augments them with operations. The specification uses XML tags, which are defined in the "Representation of CIM in XML" specification. The set of CIM operations which the former specification describes are operations on classes, instances, qualifiers and associations.

• Get of an instance. All of the properties values are returned. Getting a class returns the meta-information of the class.
• Create, Modify, and Delete. Modifying an instance can alter the properties. Note: key values cannot be modified.
• ExecuteMethod. Executing a method defined in the instance. In some cases this can be as simple as calling "reset", in other it might require passing in values.
• Enumerate. This allows the user to view all of the instances of the speciefied class and potentially sub-classes.
• EnumerateName. This allows the user to view only the object paths of the instances. Only the key properties are returned, not the other.
• Execute a query. A query statement is used to retrieve classes or instances. The defacto query language is the WBEM Query Language (WQL), which is being superseded with the Common Query Language (CQL). Below is an example WQL query which would display all of the instances in the CIM_Product class whose Name property is not null.



SELECT * FROM CIM_Product WHERE Name != NULL;

There are also special operations to get and set single properties. Also the association classes have their own set of operations for viewing instances. Finally the specification also defines operations on qualifiers and namespaces.

DMTF Schema

Figure 5 Meta Schema borrowed from DMTF CIM specification.

The last specification, the DMTF Schema is the most important specification of them all. The latest version of the DMTF Schema, "CIM Schema 2.9 Preliminary" (http://www.dmtf.org/standards/cim/cim_schema_v29_prelim), defines two set of Schemata: Core and Common. The Meta Schema depicted in the figure above is defined in the "CIM specification" and is used as the building blocks for the other Schemata. The core schema defines the essential classes for System Management, such as ComputerSystem, Operating System, FileSystem, etc. The common schema defines the most important classes for various other disciplines, such as Database, Applications, Network, Physical, Policy, User, etc. Both of these schemata describe the common denominator of classes across all vendor platforms. This is one of reasons why WBEM is being used by many vendors and is called the new tool of the industry. WBEM, with built in support of inheritance and the schemata which encompasses many disciplines, gives the vendor two major benefits:

• Extensibility. There is an easy way to add on features to differentiate the product from the competition. For example a vendor can expand the OperatingSystem class to add OS-unique properties.
• Re-usability. Vendors can inherit values from other instances without having to re-write everything from scratch. For example if an implementation of OperatingSystem class already exist, the vendor can query it for values and add its own own unique properties.

This if course begs the question how does a vendor expand and implement these classes? This is where the developer comes in. The lowest part of the WBEM architecture is the providers. The providers are responsible for serving instances to the CIM Client via the CIM Object Manager.

Providers

The API for providers varies with the implementation of the CIMOM, however there is a standard implemented by all of the CIMOMs Common Manageability Programming Interface (CMPI). The standard includes a C API, and bindings for C++ and Perl API.

There are five different types of providers a developer can implement: Instance, Method, Property, Association, and Indication. The nature of the class determines which type is implemented. For example, the Vehicle class would be a perfect candidate for Property and Instance types. Each type has a different set of functions which must be implemented. These functions are closely tied in with the "CIM Operations over HTTP" operations that can be performed on an instance of a class. For instances, these operations are Get, Modify, Delete, Create, Enumerate, EnumerateNames and ExecuteQuery. For an instance with methods, the ExecuteMethod operation has to be implemented.

For more information, refer to SBLIM (http://www-124.ibm.com/sblim/) and OpenPegasus (http://www.openpegasus.org) websites for provider-skeleton generators, tools, presentations and documents explaining how to write providers, clients, etc.

Conclusion

In summary, Web Based Enterprise Management aims at making the job of IT administrators easier. It does that by borrowing the best parts of existing technologies and combining them to create a language that can easily express complex issues. Furthermore, it also makes the implementor's job easier by offering a set of classes that provides a common definition of management information for systems, networks, applications and services. Existing WBEM implementations, such as OpenPegasus (http://www.openpegasus.org) and OpenWBEM (http://www.openwbem.org) provide easy to use APIs along with toosl, presentations and guides.