WBEM stands for Web-Based Enterprise Management and is an open standard that is managed and promoted by the Distributed Management Task Force (DMTF, http://www.dmtf.org/). You can think of WBEM as a collection of specifications, comprised of three specifications, which covers:
WBEM specifies that the Common Information Model, or CIM, will be used as the model for management information. Another specification, called xmlCIM, specifies how CIM information is represented in XML. A third specification, CIM-XML, describes how xmlCIM messages are sent across a network using HTTP as the transport mechanism. HTTPS can also be used.
Based on this information, WBEM also essentially defines a server that implements the standard. In other words, a WBEM server must understand, implement, and honor CIM; it must interpret xmlCIM messages into CIM information; and it must implement an HTTP server in order to receive HTTP or HTTPS requests with xmlCIM information inside.
A server application that implements the WBEM specifications is called a CIM Object Manager, or CIMOM. The CIMOM used for Open Enterprise Server is the OpenWBEM CIMOM (http://www.openwbem.org/). There are many good CIMOMs available in the community. Novell chose to base their management on OpenWBEM for a few key reasons:
OpenWBEM supports the Common Management Programming Interface (CMPI), which means that providers written for other popular CIMOMs, such as Pegasus, should work underneath OpenWBEM with no changes.
The Common Information Model is a general-purpose model for describing management information, and the relationships that exist between bits of information. The CIM specification includes a meta-schema, a core schema model, and a collection of several common models.
The CIM meta-schema is basically a definition of what a CIM schema must look like. The meta-schema describes the different types of elements that compose a CIM schema. A good CIM schema, then, must conform to the specification that is outlined by the CIM meta-schema.
This UML diagram basically defines the CIM meta-schema:
Image Courtesy: The Distributed Management Task Force, http://www.dmtf.org/standards/documents/CIM/DSP0004.pdf, page 14.
Figure 1: CIM Meta Schema
I encourage you to not skip quickly over this model, but instead to pause and study it for a minute or two. This model basically informs you of the types of objects that can exist in your CIM provider, and of the types of things that you can do with your provider. For example, looking at this model we can see:
There are two special types of classes: Associations and Indications.
Associations are not comprised of properties or methods; instead, they are comprised of references.
Properties, Classes, Methods, and other CIM objects can all have Qualifiers.
CIM also includes several basic schema models. This includes what they call the core model and several common models that are built atop the core model, such as the Application model, the Device model, the System model, and the User model. The information about these schema models is available online at the DMTF website: http://www.dmtf.org/standards/cim. There are a couple of things important to note about these CIM schema models. First, all of the CIM models, even the common models, describe management information in a general, platform-agnostic way, where possible. Even the common models describe the management information for a specific problem domain, but do not specify things that are specific to a platform or vendor. Second, the models build atop each other where it makes sense.
Novell also distributes a set of schema models that are pertinent to the Novell products running on your system. The primary thing that these Novell models do is provide platform specificity to the general models in areas where this specificity is necessary. Wherever possible, you should build your application's schema model atop the highest level models that are available. This would include the Novell schema where possible, and you are certainly free, and encouraged, to use the Novell models in your own schema models.
There are a few key reasons why one may be interested in making use of WBEM/CIM technology in their application:
Of course, this presupposes that a CIMOM is running on the target machine; either that, or that you are going to provide a CIMOM along with your application. Fortunately, with Open Enterprise Server, the CIMOM is included by default, and so you can simply choose to leverage it if you desire.
In order to enable WBEM/CIM for your application, you will need to complete the following tasks:
OpenWBEM supports the development of providers in three languages CMPI, C++, and Perl. CMPI is basically C, and is a more complex interface than the other two, but offers the advantage of interoperability between OpenWBEM and other CIMOMs. C++ is the most straightforward of the three interfaces. Perl itself is an easier language to use than the other two, for the uninitiated developer.
When it comes to developing a CIM client, developers are essentially free to choose whatever language they wish. The only requirement is that the language needs to be able to open an HTTP connection, and encode, send, receive, and decode XML over that connection. Due to the existence of decent open-source CIM Client APIs, Java makes a good choice for a language for developing a CIM client. However, other languages like C#, Python, PHP, and Perl also come with good XML parsing and network communication libraries, and so also make good candidates for CIM client languages. Of course, depending on your situation, you may wish to forego the development of a client altogether, and leave with your consumers the opportunity to create the client in whatever environment they see fit.
© 2009 Novell, Inc. All Rights Reserved.
