This article provides links to online resources as well as foundational information to understand WBEM and CIM, two related open standards for distributed management.
Contents |
Before beginning, it is important to have an understanding of CIM, the Common Information Model, as defined by the Distributed Management Task Force (DMTF), as well as WBEM â Web Based Enterprise Management â as it pertains to OpenWBEM, which is the CIM object manager that we will be using.
An excellent book to consider is âA Practical Approach to WBEM/CIM Managementâ? by Chris Hobbs, Auerbach Publications, 2004, ISBN 0849323061.
The references in the list immediately below should be considered required reading. The remainder of this document assumes knowledge contained within these references, and it will probably make little sense to you to move on until you have familiarized yourself with the concepts in these documents.
The references below are provided for additional information as optional references.
Optional Online CIM References:
Optional Online OpenWBEM References:
You will also want to download Novell's CIM SDK information, if you have not done so already. The CIM SDK download includes this document along with all of the sample code discussed in this document.
WBEM stands for âWeb-Based Enterprise Managementâ? and is an open standard that is managed and promoted by the Distributed Management Task Force (DMTF). 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. There are many good CIMOMs available in the community. Novell chose to base their management on OpenWBEM for a few key reasons:
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:
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:
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.
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.
What are the things we want to manage remotely? Below are some possible things we may wish to do from a remote location:
The OpenWBEM CIMOM allows us to plug in at several locations for our purposes:
One benefit of managing our application through a CIMOM is that it is completely decoupled from the client that connects to it. As long as the client knows what to do, it can accomplish all of the management tasks by sending the appropriate CIM/XML requests to the CIMOM.
This can be of particular benefit to you if you are an ISV. You can allow your application to be managed via the CIMOM, then publish the interface specification. Your end users can choose to use your management client, if you provide one, or they can create their own from within their own management console.
Some examples of alternative CIM clients that could be created for an application include:
© 2008 Novell, Inc. All Rights Reserved.
