Contents |
In this document we will discuss the use of WBEM and CIM, both open standards in the area of remote application management. We will discuss the creation of a solution to remotely manage an application, and to manage rights to that application â who is allowed to do what and under what conditions. We will talk about the technologies used, language options, architectural considerations, and the actual implementation of the solution itself.
The user has a need to completely manage an application that is running on a server, but does not want to be required to use a server console to do so. The reasons for this desire are:
In addition, the user wants to apply detailed and highly granular authorization and access controls to the other users that may have the job function of managing the application. The user also wants to accomplish this task according to industry standards, and wants to have a common interface to other system information and resources that matter to his/her task.
We will make use of a CIMOM on the target server and write a CIMOM provider that will manage the application in question on that server. The CIMOM provides an implementation of CIM, an industry standard management definition. The CIMOM will allow for controlled access to other managed information and resources in addition to those that we explicitly provide through our provider. The CIMOM will also allow us to create the necessary business logic in data and code to enforce the authorization that we want. We will demonstrate how to remotely manage the application using several different types of clients.
For the sake of this tutorial, we will be walking through the implementation of a CIM provider for the Linux time service. This is a very rudimentary service on a Linux box that tells the system the clock and hardware time, as well as the timezone to which the clock time pertains. Despite the simplicity of the provider, it is a fairly complete example that will teach us the fundamentals of writing a CIM provider. Our provider will be able to set or retrieve the system time and timezone.
Before you begin application development using WBEM and CIM, you need a strong understanding of the technologies at work. The article Overview of WBEM and CIM contains some good references and information to get you started.
Preparation to develop applications using WBEM and CIM require special preparation of the development environment, which is covered in the document Development Environment for WBEM and CIM.
What is required to leverage CIM/WBEM technology? Basically, you do three things:
As you may have observed if you installed OpenWBEM from source, there are really two parts to each extension on the server side â the schema that describes what is being modeled, and the source code that implements the logistics of doing what the model needs to have done.
The OpenWBEM CIMOM is primarily an engine that supports the use of schema, maintains a database of static instances of classes as defined within schema, and marshals requests from a client (received via CIM/XML over HTTP) to the appropriate handler for that request, then returns the response from the handler to the requesting client.
When you compile and install the OpenWBEM CIMOM from source, aside from the installation of the engine itself, you also compile and install a base set of handlers that implement the standard schema â primarily telling the CIMOM how to honor object relationships and traverse the object model, and other similar things. After doing this, you then install the CIM schema itself. You may have noticed, if you installed Novell LIFE from source, that you repeated the same steps â you first compiled and installed the providers, then installed the LIFE schema.
This is the basic dance that you do to implement new functionality in CIM on the server side. You create new schema that extends the existing CIM schema, and then you implement code in a CIM provider that takes care of the details of your model. Generally, you will install the providers first, then the schema, but when developing it is usually better methodology to create the new schema first, since this encourages you to design your application well from the beginning.
Once the server side is done, you will still need to implement a client, or plug into an existing client, that can send CIM/XML requests over HTTP to the CIMOM.
To be clear on how this all works, consider an example where a client is going to remotely restart a service.
In this example, the custom code includes the client, the extended schema that defines how this request is handled, and the provider where the method is actually implemented.
The first thing that we need to do when extending the capability of CIM and WBEM is to extend the CIM schema. Refer to How to Design CIM Schema for a detailed walkthrough on this.
Once we have completed our schema extensions, we can develop the provider itself. Refer to How to Develop a CIM Provider for a detailed walkthrough.
In this document and the related sub-documents, we have provided an overview of WBEM and CIM technology, including a justification for using this technology in implementing a remotely managed application. We then discussed the actual implementation of a sample CIM provider to manage system time from a remote location. We have seen how to take advantage of these open standards and how so doing makes it so a generic client can be used to execute and take advantage of the code we wrote in our provider.
I hope this document has been useful to you, and look forward to your feedback. Good luck with your WBEM and CIM efforts moving forward!
The following terms are defined in the Technical Glossary:
| Developer Primer to WBEM and CIM.sxw | 459.1 K | 2005-04-06 |
© 2008 Novell, Inc. All Rights Reserved.
