Return to HowToAccessCIMClasses.txt CVS log

Up to [Pegasus] / pegasus_unsupported / wsm

PEP#: 9999
TITLE: add wsm

DESCRIPTION: add wsm components

              HOW TO ACCESS CIM CLASS INFORMATION WITH WSM

V1 30 March 2007, K. Schopmeyer, Original

INTRODUCTION

WSM need CIM class information information
in the transformation between wsm objects and cim objects.  This is 
required
because wsm objects do not carry any data typing and cim objects are 
inherently data typed.  

This transform is required both:

The WSM frontend server to convert between cimobjects and wsm xml object 
definitions

The CIMCLientAPI=WSMAPI translator (src/Client/CIMWSMClient) to adapt 
CIM objects at the CIM API interface to corresponding WSM XML objects.


However, the access of CIM Classes is not part of the WS_Management 
protocol so some other means must be found to gain access to CIM Class 
information.

WSM provides two means of doing this:

1. Access to a CIM/XML CIM Server.  This allows the CIM Class operations 
to be processed directly by a cim server using the xim/xml protocol just 
as if WSM did not exist.   The means for setting this up is defined in 
other HOWTOS in this directory.  

This is controlled by the environment variable WSM_USE_WSMAN.

2. Direct access to a local Pegasus Repository.  This allows the Classes 
to be defined locally and a local repository set up to provide class 
information.  Instead of accessing class information via client calls to 
the cim/xml server, calls are made directly to a local CIM repository set 
up in the client environment.  This MUST BE a repository created with 
OpenPegasus tools and MUST include the same namespaces and classes as the 
target servers for WS_MAN.  Every class for which instances are to be 
accessed in any WSM server, must contain the corresponding class 
definitions locally in the CIM Repository AND in the same namespace as it 
is in the remote system.  Thus, if there is a namespace xyz in the remote 
system that is used by WSM, there MUST BE a corresponding namespace xyz 
in the local system with the classes from the remote system.

For the purposes of demonstrations, this functionality is controlled by 
the environment variable PEGASUS_CLIENT_HOME which must be set and define 
a home directory for the local repository.  The actual repository would 
exist in a subdirectory named "repository" of the directory defined in 
PEGASUS_CLIENT_HOME.

Note that both WSM_USE_WSMAN and PEGASUS_CLIENT_HOME environment variables 
must be set to use the local reponsitory

ACCESSING UP A LOCAL REPOSITORY

If a local Pegasus server exists.

The flag for use of the local repository can be setup with the environment 
variable setting of

export PEGASUS_CLIENT_HOME=$PEGASUS_HOME.

This sets the CLIENT home to the same directory as the Pegasus home and 
normally the repository is a subdirectory to PEGASUS_HOME.

Repository in some other directory

If the repository is in directory 

   /home/myhome/pegasusClient/repository


export PEGASUS_CLIENT_HOME="/home/myhome/pegasusClient"

SETTING UP A LOCAL CLIENT REPOSITORY

The primary tool to set up the local repository is simply the Pegasus 
compiler.  This means that the user must have access to the MOF defined 
in the remote system AND know the namespaces to compile the MOF locally 
into the local repository.

In addition, a local PEGASUS server repository can be copied as the basis 
for a local repository.

In addition, we are supplying one more tool that may help with setting up 
the local repository IF the remote server also has CIM/XML access.  We 
will supply a limited copy tool that will copy all of the classes from the 
remote repository to the local repository for a single namespace.  


Karl Schopmeyer
30 March 2007