IBM Director CIM support

General overview

This document is intended as an overview of the CIM support provided in Director. It is not a tutorial on CIM or its concepts. The CIM documents published by the DMTF (Desktop Management Task Force) are considered prerequisite reading. This document will outline four major components that together make up not only the basis of the CIM support for Director, but also are the core of the SDK for CIM usage by other portions of IBM Director and any OEM extensions. For example, the Inventory collection will be done using a portion of this function (the adapter). There are, however, two major CIM functions within IBM Director which exist outside of this discussion: Alerting and Monitoring. The nature of these two components requires that their functionality reside as close as possible to the component, which means they will not be using the functions detailed in this document.

Purpose

The task at hand is to allow the functionality that CIM provides in a way that is useful to Director. In the IBM Director model, that means adding support to the client to consume the CIM functionality, and to surface that information in some way on both the Console and the Server. This is the job of the CIM Adapter. Once the information is available in both places, any function that requires the information might make use of it. The first function that comes to mind is a general case Browser.

Architectural overview

The following diagram outlines the general architecture of the CIM extension for Director.

CIM adapter

The Adapter is provided to allow remote access to clients that have an active CIMOM (CIM Object Manager) by defining Java interfaces. The adapter is available to all IBM Director processes, whether they run on the server, either in or outside of the server's own JVM, or on the Console, and all interfaces operate asynchronously. The second purpose behind the design of the adapter was to provide a "standard" interface for interacting with CIM. The current CIM documentation defines the schema definitions, but lacks any sort of standard interface for interacting with that information. The complete Adapter interface contains three parts:

The interface definitions and the abstract base classes are meant to be implementation neutral. The remaining classes make up the implementation of those interfaces for use in the IBM Director environment.

Adapter interface definitions

All three interfaces operate the same way. They are call/response interfaces, where the call back into the iCIMxxxResponse interface occurs asynchronously from the initial call into the CIMxxx interface. The implementers of the interface will provide an implementation of The caller or user of one of the interfaces is required to implement the appropriate response interface. For example, if you were going to enumerate the classes contained in a given systems CIMOM, you would instantiate an object that implements and you would be required to implement to handle the callback, or response to the class query.

The Interfaces are defined with asynchronous callbacks, to allow for more scalability in networking situations, and to allow the implementers of the interface as much flexibility as possible.

Programmatic flow diagram

  1. The User creates an instance of and makes a request
  2. The Adapter Handler processes the request by interacting with the CIMOM implementation
  3. The Adapter Handler calls the user-supplied implementation of asynchronously

By doing this, the underlying implementation required to interact with the CIMOM is abstracted from the user of the interfaces. This makes replacement of all or part of the adapter handler transparent to the users of the interface.

Abstract base class definitions

These classes are intended to contain all implementation neutral entity content. For example, everything that is necessary to describe/interact with a CIMClass with the exception of anything required for a given environment, is contained in A particular implementation, like the IBM Director implementation described below, would then subclass this and add any additional information required for that implementation. For example, in the case of Director's implementation MOID (Managed Object ID) , which is the ID that uniquely identifies a particular system (client workstation) is added. This allows IBM Director to communicate with the system.

IBM Director implementation classes

These are an implementation based on the first two groups. They are what makes up the CIM Adapter support for Director.

RAS

The CIM support in IBM Director currently has no support through the internal The reason is a lack of code points to support new extensions. This problem should be rectified in a future release. The client code, the subagent running on Win32 platforms, does support a tracing facility.

The CIM Manager (cimmgr.exe) on the clients has a built-in RAS trace facility. By default the tracing is disabled. To enable it, create a file called x:\Program Files\IBM\Director\bin\cimmgr.dbg where x is the drive on which the IBM Director client is installed. The next time the CIM Manager is loaded by the client's Service Manager, RAS will be enabled and trace statements will be written to x:\Program Files\IBM\Director\bin\cimmgr.ras. The RAS trace statements are similar to those obtained via RASWATCH on the IBM Director server. Note, if the cimmgr.exe has already been loaded, you might need to stop and restart TWGIPC for the change to take effect. RAS tracing will be enabled as long as x:\Program Files\IBM\Director\bin\cimmgr.dbg exists. To disable RAS tracing, erase x:\Program Files\IBM\Director\bin\cimmgr.dbg. Again, TWGIPC might need to be stopped and restarted for the change to take effect.