CIMOM Implementation

1
CIMOM Implementation
2
What is Pegasus?

• Pegasus is an open-source reference
  implementation of the DMTF WBEM specifications
• Pegasus is a work project of the TOG Enterprise
  Management Forum
• Pegasus is a platform for building application
  management
• Pegasus is a function-rich, production-quality
  open-source implementation designed to be used in
  high volume server implementations.

3
Why Produce Pegasus?

• Demonstrate manageability concepts.
• Provide additional standards for WBEM
• Provide a working implementation of WBEM
  technologies
• Provide an effective modular implementation
• Support other Open Group manageability standards
• Base Platform for Open Group Application
  management Projects
• Help make WBEM real

• Pegasus was Initiated in 2000 by the Open Group
  in collaboration with
• BMC Software
• IBM
• Tivoli Systems

4
Key Pegasus Objectives
Open Source
Standards Based
Pegasus
Continuity
Portable
Modular And Extensible
Efficient And Lightweight
Production Quality
5
Pegasus Working Group Philosophy

• Manageability not management
• The Pegasus working groups objective is not to
  manage systems but to make them manageable by
  promoting a standard instrumentation environment
• The actual management of systems is left to
  systems management vendors
• No standards without implementation
• The process of implementation provides a rigorous
  process for testing the validity of standards
• Therefore all standards must be validated by
  implementation

6
Open Source

• Code and documentation freely available
• Open Group and Source Forge
• MIT source license
• Open to contributions
• No commitment to Open Group to use code

7
Portable

• Designed for multi-platform, multi-OS,
  multi-compiler implementation
• Platforms ported today
• UNIX (AIX, HPUX, Solaris, Tru-Unix)
• Linux
• Windows Platforms (NT, 2000, 9x)
• Compaq Himalaya (Tandem)

8
Efficient and Lightweight

• Core written in C
• Designed for execution efficiency
• Designed to be production-quality solution

9
Standards Based

• Based on DMTF CIM and CIM-XML specifications
• Open Group is active partner in DMTF
• Growth through participation in specification
  growth
• Commitment to continue DMTF compliance

10
Modular and Extensible

• Minimize core object broker.
• Maximize extensibility through plug-in components
• Component types
• Providers
• Provider interfaces
• Clients
• Repositories (additional repository handlers)
• Manageability service extensions
• Protocol Adapters
• Modules (extend and modify core functions)

Modularity is key to doing parallel development
and allowto extensibility
11
Project for Continued Development

• WBEM will continue to develop functionality and
  standards
• Open Group will develop application management
  partly around Pegasus
• Pegasus Development will continue beyond current
  versions
• Integrate contributions
• Add basic new functionality
• Etc.

12
The Open Group

• Enterprise Management Forum
• Projects include
• Pegasus
• Ex-SNIA Java Based open-source Implementation
• Application Management APIs
• ARM
• AIC
• Software Licensing Standards
• QoS Task Force
• User/Supplier interaction forum to advance QoS
  and Service Level Standards
• Working with DMTF, IETF, TMN

13
2. The Pegasus Environment
14
Pegasus Architecture
Standard Interfaces
Interoperable
MOF Compiler
CIM Server
Interoperable
CIM/HTTP
In-Process
15
CIMOM Capabilities

• Respond to Operations defined in CIM Operations
  spec.
• Create, Modify, Delete operations on
• Class, Instance, Property, Qualifier
• Handle Provider Registration
• Forward Requests to Providers, repositories, etc.
• Read/Write access to Management Information
• Maintain Class/Instance Information
• Traversal of Associations
• Use of WBEM Query Language
• Syntax/Semantic checking (with Qualifiers)
• Available Implementations
• Microsoft (in Windows2000), Sun WBEM SDK, SNIA,
  Open Group Pegasus,

16
Key Interoperability Interfaces
Management System
Enterprise Management Console

• Manageability to Manager
• Multiple management systems
• Common open manageability

CIM Object Manager

• Object Manager / Providers
• Multiple Providers
• Encourage common providers

CIM Providers

• Provider / Resource Interface
• Protect Applications
• Make application management easy

Application
Application
Application
Application
17
The CIM Operations
Standard Interfaces
CIM Operations
Interoperable
CIM Object Mgr
Repository
Repository
Interoperable
CIM/HTTP
In-Process
18
Operations Routing

• Class Operations
• Routed to the Class Repository
• Instance Operations
• To Provider if Provider Qualifier exists
• To Instance repository if no Provider
• Instance routing at Class Level Today
• Issues Routing at instance level

19
The CIM Indications
Standard Interfaces
Interoperable
Indication Handlers
SNMP, cim-xml, etc.
CIM Object Mgr
Repository
Repository
Interoperable
CIM/HTTP
In-Process
Indicators
20
Modularity and Extensibility

• Providers
• Grow with DMTF provider concepts
• Provider Interfaces
• Protocol Adapters (connectors)
• Client - Xml-cim today (Soap, etc. in future)
• Provider, service, repository, etc.
• Modules
• Modularize core so it can be extended and
  modified through attachable modules
• Manageability Service Extensions
• Think super providers

21
Building A Modular Manageability Environment
Core Object Broker
Connector
Connector
. . .
Provider
22
Pegasus Manageability Environment
Management System
Management System
CIMOM
Services core additional
Application Consumer
Application Consumer
Management System Connector
Application Consumer
Consumers Gateways Apps
XML/CIM Connector
Management System Connector

• CIM Object Broker
• Provider Registration
• Service Registration
• Request Routing
• Securiy

Broker
Class Repository
Instance Repository
AIC Provider
ARM Provider
SNMP Provider
. . .
Providers
Interface For Spec
Apps
OS
Etc.
Resource
23
Provider Interoperability

• In the classical architecture, interoperability
  is only supported between the client and server.
• In addition, the Pegasus architecture aims to
  support provider/server interoperability.
• Goal
• Write a provider once and run it under any CIM
  server implementation.
• Provider/Server Interoperability
• Participating in efforts to standardize the
  Provider/Server protocol.
• Proposing provider API standards.
• Writing adapters enabling Pegasus providers to
  run under other CIM servers.
• Adapters enabling other providers to run under
  Pegasus

24
Important Provider Interfaces

• SUN WBEM Provider Interface
• Java based
• Classes, etc. similar to Pegasus
• C Provider Interface
• Sun has a specification here.
• We will support multiple provider interfaces and
  language bindings.

25
In-Process and Out-of-process Providers

• Today Pegasus based on shared Library Providers
• Extend to
• Internal Providers
• IPC based Providers
• Providers in Remotes systems
• Objectives
• Write Provider once and compile/link for
  different environments
• Technique
• Use connectors as basis for provider/CIMOM
  communication
• Issues
• Security, discovery

26
Manageability Service Extensions

• Super Providers
• Access to the Core Broker

• Examples
• Indication Subscription service.
• Class repository service.
• Instance repository service.

27
Connectors (Protocol Adapters)

• Functions
• Adapt to different protocols
• Characteristics
• Protocol
• Encoding
• Security
• Discovery
• Examples
• Xml-CIM
• Local Protocols
• Soap
• WMI
• Corba environment interface

Xml-cim Client
Soap Client
Xml-cim Connector
Soap Connector
External Corba Environment
Pegasus Core
Corba Connector
Pegasus Provider
Connector
Remote Provider
28
Pegasus Interfaces

• Common Interface base for
• Clients, providers, services, connectors
• Based on CIM Operations over HTTP
• Additional functions for each interface
• Interfaces separated from implementation

Core Object Broker
29
3. The Pegasus Software Architecture
30
Major Components
Client
Client
CIM Clients
Repository
CIM Server
Client
Client
CIM Providers
31
Topics

• Communication.
• Representation of CIM Elements.
• The Client Interface.
• The CIM Object Manager.
• The Provider Interface.
• The Repository Interface.

32
Pathways of Communication
33
Component Location

• A component may be located in one of three places
  with respect to the CIM Server.
• In-process.
• Local out-of-process (on the same machine).
• Remote out-of-process (on another machine).
• For example, a provider may be in-process, local,
  or remote.

34
Component Location in Pegasus Today
35
Possible Communication Mechanisms

• Components could potentially communicate with the
  CIM Server using the following mechanisms
• CIM/HTTP (remote).
• Proprietary TCP-based protocol (remote).
• Direct call (in process).
• Shared memory (local).
• Named pipes (local).

36
Communication Mechanisms in Pegasus
37
Client Communication

• Uses CIM/HTTP as sole protocol.
• Asynchronous socket I/O.
• An efficient XML parser.
• Fast enough to eliminate the need for a
  proprietary protocol.

38
An Efficient XML Parser

• No memory heap usage during parsing.
• Modifies message in place to avoid copying.
• Non-validating parser (loose validation).

39
HTTP Implementation

• Uses asynchronous socket I/O in conjunction with
  message queues to achieve optimal throughput.
• Provides entry points to adding web server
  capabilities such as putting and getting of
  documents (to support remote upgrade and
  deployment later on).

40
Proposals

• Support out-of-process providers (local and
  remote).
• Support out-of-process repositories (local and
  remote).
• Location independent provider development.

41
Representation of CIM Elements

• Representing CIM Elements in Pegasus with C

42
CIM Data Types in C

• Uint8
• Sint8
• Uint16
• Sint16
• Uint32
• Sint32
• Uint64
• Sint64
• Real32
• Real64

• Boolean
• Char16
• String
• CIMDateTime
• CIMReference

43
CIM Values in C

• CIM values (property, parameter, and qualifier
  values) are represented using the CIMValue class.
  This class
• Encapsulates a union of all CIM data types.
• Has a type member indicating the type currently
  being represented.
• Provides access/modifier methods overloaded for
  each CIM data type.

44
CIM Elements in C

• CIMClass
• CIMInstance
• CIMProperty
• CIMMethod
• CIMParameter
• CIMQualifierDecl
• CIMQualifier

45
Class Declaration Example (Part 1)

• Consider the following MOF class declaration
• class Alarm
• key
• uint64 id
• string message none
• This class is defined in C as follows
• CIMClass alarmClass(Alarm)
• CIMProperty id(id, Uint32(0))
• id.addQualifier(CIMQualifier(key, true))
• CIMProperty message(message, none)
• alarmClass.addProperty(id)
• alarmClass.addProperty(message)
• Or more succinctly like this
• CIMClass alarmClass(Alarm)
• alarmClass
• .addProperty(CIMProperty(id, Uint32(0))
• .addQualifier(CIMQualifier(key, true)))

46
Property Iteration Example

• The properties of a class may be iterated like
  this
• CIMClass c
• for (Uint32 i 0, n c.getPropertyCount()
• i lt n i)
• CIMProperty p c.getProperty(i)

47
The Client Interface
48
The Client Interface

• A C interface for interacting with the Pegasus
  Server (or any CIM Server).
• Uses CIM/HTTP to communicate.
• Provides a method for each CIM operation defined
  in the CIM Operations over HTTP, V1.0
  specification.

49
The CIM Operations

• GetClass
• GetInstance
• DeleteClass
• DeleteInstance
• CreateClass
• CreateInstance
• ModifyClass
• ModifyInstance
• EnumerateClasses
• EnumerateClassNames
• EnumerateInstances
• EnumerateInstanceNames
• ExecQuery

• Associators
• AssociatorNames
• References
• ReferenceNames
• GetProperty
• SetProperty
• GetQualifier
• SetQualifier
• InvokeMethod

50
CIM Operation Example
ltinstancegt GetInstance ( IN
ltinstanceNamegt InstanceName,
IN,OPTIONAL boolean LocalOnly true,
IN,OPTIONAL boolean IncludeQualifiers false,
IN,OPTIONAL boolean IncludeClassOrigin
false, IN,OPTIONAL,NULL string
PropertyList NULL )
CIM Operations Specification
virtual CIMInstance getInstance( const
String nameSpace, const CIMReference
instanceName, Boolean localOnly true,
Boolean includeQualifiers false, Boolean
includeClassOrigin false, const
ArrayltStringgt propertyList NULL_PROPERTY_L
IST)
Pegasus Class Method
51
Client Connection Example

• A client connects to the CIM Server on the host
  called saturn at port 5988 like this
• Selector selector
• CIMClient client(selector)
• client.connect(saturn5988)

52
GetClass Example

• A client gets a class like this
• CIMClass alarmClass
• client.getClass(root/cimv2, Alarm)

53
Client Proposals

• Asynchronous Interface APIs
• Interface independent of local/remote client

54
The Pegasus CIMOM
Client
Client
CIM Clients
Repository
CIM Server
Client
Client
CIM Providers
55
Request Lifecycle
Incoming Request
Outgoing Response
1. Receive TCP Message
Channel
Channel
8. Transmit TCP Message
2. Process HTTP Request
Protocol
Protocol
7. Form HTTP Response
Encodings
Encodings
3. Decode from XML
6. Encode to XML
Dispatcher
Repository
4. Dispatch Request
Aggregator
5. Aggregate Results
56
CIMOM Modules

• Channel - Implements transport mechanism (e.g.,
  TCP).
• Protocol - Implement application protocol (e.g.,
  HTTP).
• Encodings - Implements encoding and decoding of
  messages (e.g., CIM-XML).
• Dispatcher - Dispatches messages to
  provider(s)/repository.
• Repository - Implements CIM Repository.
• Aggregator - Aggregates results.

57
Module Concept

• The internal CIMOM architecture is being refined
  into a set of modules.
• Each module handles part of the request
  lifecycle.
• Alternative implementations may be provided for
  each module type.
• New module implementations can be used to modify
  or refine the behavior of the CIMOM and to
  facilitate porting.

58
Module Implementations

• Channel - provide a named-pipe implementation.
• Protocol - provide a proprietary binary protocol.
• Encodings - provide a binary encoding scheme.
• Repository - provide a relational-based
  implementation.
• Traffic Encryption - SSL implementation.
• Authentication Challenge and response

59
Queued Operation Model

• Internal representation of operations/Indications
  is messages
• Major components are queue driven
• Mapped to direct interfaces (ex. getClass) at
  provider manager.
• Message manager controls flows, priorities, etc.
• Advantages
• Efficiency
• Threading
• Extensible interfaces
• Flow Control

60
Module Definition and Loading

• Modules implement one of the module interfaces
  (e.g., Repository).
• Modules are configured as dynamic libraries.
• Modules listed in modules file.
• Modules loaded by CIMOM on startup.

61
Indication Import
Export Indication
Client Interface (cim-xml today)
CIM XML Comm Module
CIM Export Request Decoder
Acceptor
xxx
Authentication
Http Delegator
Http xxx
CIM Export Request Processor
XML Decoder
XML Encoder
Indication Consumer Manager
Local Destination
CIM Operations Processing subsystem
Services Subsystem
Response generator
Repository
Authorization
Subscription Service and Indication Processor
Operations Request Processor
Operations Response Processor

• CIM Control Services
• Start/Stop Function
• Provider registration Function
• User/Auth. Function
• jj
• Jj
• __Namespace

PegasusMsgDispatcher
CIM-XML Indication handler
Indication Handler Manager
Provider Mgr Subsystem
Provider Manager
Indication Consumer Manager
SNMP Indication handler
Formal Provider Interface
provider
Pegasus Module Organization
provider
provider
62
The Provider Interface
Client
Client
CIM Clients
Repository
CIM Server
Client
Client
CIM Providers
63
Provider Proposals

• Interoperability with SUN Wbem providers proposal
• We are extending other interoperability ideas

Pegasus CIMOM
SUN WBEM CIMOM
Microsoft CIMOM
Pegasus Providers
SUN WBEM Providers
Microsoft WMI Providers
64
The Repository Interface
Client
Client
CIM Clients
Repository
CIM Server
Client
Client
CIM Providers
65
The Repository Interface

• Defines the interface to manipulating the CIM
  repository.
• Alternative implementations of this interface may
  be provided.
• Pegasus provides a simple default implementation.

66
Default Repository Implementation

• Each CIM Class object is stored in its own file.
• Instance objects stored in single file for each
  class
• CIM objects are encoded as XML in files.
• Namespaces are represented using file system
  directories.
• Single reader/writer at a time.
• Example the class X (subclass of Y) which
  resides in the root/cimv2 namespace would be
  stored in this file
• ltrepository_rootgt/rootcimv20/classes/X.Y

67
Default Repository Limitations

• Adequate for classes and qualifiers (which tend
  to be few).
• Okay for a few hundred instances.
• Not intended to scale to thousands of instances
  (uses a lot of disk space due to internal
  fragmentation).
• Good for scenario in which a few instances come
  from the repository and many instances come from
  providers.

68
Proposed Repository Implementation

• A new repository implementation is under
  consideration to improve scalability
• Encode objects in binary on disk (rather than
  XML). This will reduce size by three to one.
• Combine like objects into a single file rather
  than separate files (this will reduce internal
  fragmentation).
• Provide a fast indexing scheme for keys (disk
  hashing or B-Trees). This will improve lookup
  time.

69
Alternative Repository Modules

• Repository modules may be developed to achieve a
  highly scalable repository. Possibilities
  include
• Basing repository on a relational database.
• Basing repository on Unix DB.
• Making the repository remote.
• Improving space utilization of existing
  implementation by storing objects in binary
  format (rather than as XML).