Overview of Pegasus An Open-Source WBEM implementation 17 July 2001 Karl Version 1.0

Agenda  Overview -What (and why)is Pegasus?  The Pegasus Environment  The Pegasus Software Architecture  Pegasus Status Today  Plans  The Pegasus Project  A Challenge for the Future

1. Overview

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.

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 TOG manageability standards  Base Platform for Open Group Application management Projects

Origins of Pegasus  Pegasus was initiated in 2000 by the Open Group in collaboration with:  BMC Software  IBM  Tivoli Systems

Key Pegasus Objectives Pegasus Open Source Portable Efficient And Lightweight Standards Based Continuity Modular And Extensible Production Quality MIT License DMTF WBEM C++ Code Base C++ and portable Libraries

Pegasus Working Group Philosophy  Manageability not management  The working group’s 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

Pegasus is 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

Pegasus is Portable  Designed for multi-platform, multi-OS, multi- compiler implementation  Platforms ported today  UNIX (AIX, HPUX, Compaq Tru64, Solaris)  Linux  Windows Platforms (NT, 2000, 9x)  Compaq Himalaya (Tandem)

Efficient and Lightweight  Core written in C++  Designed for execution efficiency  Designed to be production-quality solution

Pegasus is 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

Pegasus is 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

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.

2. WBEM and CIM Techlologies

WBEM Architectures Transport Encoding Transport Encoding HTTP Access Data Description Discovery  DMI WBEM

What it is CIM?  CIM is an implementation neutral schema for describing overall management information  CIM facilitates the common understanding of management data across different management systems  CIM facilitates the integration of management information from different sources  CIM today is a data model not an implementation  MOF syntax supports sharing information across management systems  CIM provides models for both instrumentation and management

Meta Model CIM Specification V2 Extension Schema System Network Device Apps Core Users CIM Schema v2.5 (800+ classes) DMTF WBEM Components

Web-based Enterprise Management (WBEM)  Information Model  CIM Schema (Core, System,…)  Communication Model  CIM Operations over HTTP  Transport Encoding  Cim-xml – CIM/XML mapping  Event Model  CIM indications (new in 2.5)  CIM Object Manager (CIMOM)  Operation Routing  Result Aggregation  Repository  Class and Instance Persistence  Resource Providers  Instrumentation subagents Management Applications cim-xml Transport CIM Object Manager Resource Providers CMIP Objects CMI P SNMP MIBs SNMP DMI MIFs RPC CIM Objects Inter net Schema CIM Server CIM Client

Common Information Model  Defines the Schema used to represent real- world objects being managed  Object oriented paradigm  CIM Specification  Meta model, high level concepts, and definition language (MOF)  CIM Schema  Core and Common Model

Interoperability  XML encoding  Definition for each operation  HTTP Transport  HTTP 1.0 and 1.1  Common Operations Semantics  Data  Meta data  Queries   Methods CIM Client CIM Client CIM Server CIM Server Managed Resources

Managed Object Format (MOF)

2. The Pegasus Environment

Major Components Client CIM Object Manager Repository Client CIM Clients Client CIM Providers Many Clients Management Applications Many Providers per CIMOM CIM-XML

Key Interoperability Interfaces CIM Object Manager CIM Object Manager CIM Providers Application Manageability to Manager Multiple management systems Common open manageability Object Manager / Providers Multiple Providers Encourage common providers Management System Enterprise Management Console Enterprise Management Console Application Provider / Resource Interface Protect Applications Make application management easy

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, …

Pathways of Communication Client CIM Object Manager CIM Repository Client CIM Clients Client CIM Providers

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.

Component Location in Pegasus Today

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).

Communication Mechanisms in Pegasus

The Pegasus CIMOM Client CIM Server Repository Client CIM Clients Client CIM Providers

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

Operation Routing Client CIM Object Manager Repository Client CIM Clients CIM Clients Client CIM Providers CIM Providers Class Operations Routed to the Repository

Operation Routing Client CIM Object Manager Repository Client CIM Clients CIM Clients Client CIM Providers CIM Providers Instance Operations Routng Routing By Class To Provider if Qualifier Defined Default is to Instnace Repository

Indication Routing Client CIM Object Manager Repository Client CIM Listener CIM Listener Client CIM Providers CIM Providers Indication routing Handler Client CIM Clients CIM Clients Subscriptons Indications

Request Lifecycle Channel Protocol Encodings Aggregator Providers Repository 8. Transmit TCP Message 7. Form HTTP Response 6. Encode to XML 5. Aggregate Results Outgoing Response Channel Protocol Encodings Dispatcher 1. Receive TCP Message 2. Process HTTP Request 3. Decode XML 4. Dispatch Request Incoming Request

Key Characteristics  Open source  Available Today  Portable  Designed to build and run on wide variety of platforms  C++ core  C++ CIM Objects  C++ Operation/Provider/Service/Repository interfaces  Modular and extensible  Modular components to extend the core  Manageability service extensions to extend functionality  Light weight

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

Building A Modular Manageability Environmnent Core Object Manager Core Object Manager XML-CIM Module Connector Provider Connector Provider Connector CIM Client Connector... Resources Service Extension Service Extension Service Extension Service Extension Service Extension Service Extension Service Extension Service Extension Repository Undefined CIM Client Repository Service Extension Service Extension Service Extension Service Extension Service Extension Service Extension Service Extension Service Extension

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

Flexible Provider Interfaces  SUN WBEM Provider Interface  Java based  Classes, etc. “similar” to Pegasus  C Provider Interface  Many Providers written in C  We will support multiple provider interfaces and language bindings.  Perl, Scripting, etc. CIM Object Manager CIM Object Manager Interface Adapter Providers Interface Adapter Interface Adapter Providers

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

Modules  The core server functions are organized into loadable modules.  Standard APIs are defined for each module.  Alternative implementations can be provided later without recompiling the Pegasus server.

Manageability Service Extensions  Super Providers  Access to the Core Broker  Examples  Indication Management service.  Query engine service.  Class repository service.  Instance repository service.

Connectors (Protocol Adapters)  Functions  Adapt to different protocols  Characteristics  Protocol  Encoding  Security  Discovery  Examples  Xml-CIM  Local Protocols  Soap  WMI  Corba environment interface Pegasus Core Xml-cim Connector Xml-cim Connector Pegasus Provider Pegasus Provider Connector Remote Provider Xml-cim Client Xml-cim Client Soap Connector Soap Connector Soap Client Soap Client Corba Connector Corba Connector External Corba Environment

Pegasus Manageability Environment CIM Object Broker Broker) Provider Registration Service Registration Request Routing CIM Object Broker Broker) Provider Registration Service Registration Request Routing ARM Provider ARM Provider Resource Providers Broker Consumers Gateways Apps XML/CIM Connector XML/CIM Connector Class Repository Class Repository Service extensions Security Interface For Spec... AIC Provider AIC Provider Apps Object Browser Editor Object Browser Editor Instance Repository Instance Repository SecurityEvents Provider SDK Remote Provider Remote Provider Provider SDK Queuing Client SDK MOF Compiler

Programming Language Support  The Pegasus core is implemented in C++ and hence client and provider interface are provided for C++.  An integrated JVM is planned to allow providers to be developed in Java.  Of course it is possible to use existing Java clients to interact with the Pegasus CIMOM.

CIM Objects in C++  CIMClass  CIMInstance  CIMProperty  CIMMethod  CIMParameter  CIMQualifierDecl  CIMQualifier

Class Declaration Example (Part 1)  Consider the following MOF class declaration: class Alarm { [key] uint64 id; string message = “none”; };

Class Declaration Example (Part 2)  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))).addProperty(CIMProperty(“message”, “none”));

Property Iteration Example:  The properties of a class may be iterated like this: CIMClass c; … for (Uint32 i = 0, n = c.getPropertyCount(); i < n; i++) { CIMProperty p = c.getProperty(i); }

4. The Pegasus Implementation TodayAndTomorrow

Status Today  Phase 1 complete  Phase 1  CIMOM including HTTP Server and CIM-xml Protocol Provider interfaces and dispatch Repository with Instances, Classes, Associations C++ CIM Object Model representation Admin and support functions  MOF Compiler  Client Interface and test clients  Test providers and beginning of some real providers  Integrated unit and client server tests (regression)  Beta level code quality  Needs More testing

The Components Today Pegasus CIM Object Manager Pegasus CIM Object Manager Compiler Instance Repository Instance Repository Class Repository Class Repository C++ Interface Adapter C++ Interface Adapter C++ Providers C++ Providers C Interface Adapter C Interface Adapter Browsing Client Browsing Client Test Clients Test Clients

CIM Functionality Missing From Phase 1  Events  Security  WQL and Query

Important Tasks Phase 1  Testing  Pegasus  Interoperability  More Providers for testing and Demos  Better Clients  Documentation  Binary Release

Planned Extensions  CIMOM Functions  Security  Indications  Threading  Async CIM Operations APIs  More Modularity  Enhance Service Configuration  Expanding Provider Characteristics  Out-of-Process Providers  WBEM Functions  Discovery  CIMOM Object Manager Characteristics  Provider Registration and Operations  Clients  Object Browser  Test Clients  Protocol Adapters  Add protocol Adapters  Providers  Test  Sample Implementations  Java Module Interface  Platforms  Easier portability  More platforms

Phase 2 Priority tasks  Threaded Model  Basic Indications Support  CIM Object Manager Capabilities Reporting  Discovery Demonstration  Additional Modularization

5. The Pegasus Project

Overview of the Project  Active project of Enterprise Management Forum of the Open Group  Producing  Pegasus open-source Implementation  Core, clients, providers, repositories  SDKs (Provider and Client)  Documentation for use and development  Specifications for major Interfaces  Continue support and growth of Pegasus  Portability  New functions  New Standards requirements  New Providers  Tools Pegasus Is a continuing project, not a one-shot development

Pegasus Status Today  Phase 1 of 3+ Phases  Version 1.0 Available  Source Code available today  Preliminary documentation available  Multiple users evaluating today  Tested on the platforms defined

Pegasus Project Phases  Phase 1 (July 2001)  Goals  Model Validation  Client and Provider development  Basic Environment  Core model  Cim-xml Operations  Class and instance repositories  Providers  Phase 2 (September)  Goals  Production Environment  Additions  Threading  Configuration  Security  Service Extensions  Indications  Phase 3  Remote Providers  Discovery  Other extensions including other Language Interfaces (ex. Java connector)

Participants  BMC Software  Compaq Computer  Focal Point  Hermes Softlab  Hewlett Packard  IBM  SIAC  The Open Group  Research Institute  Management Forum  Tivoli

Project Contributors  Moving from core development to adding functionality  Major Contributors  BMC  Compaq  Hewlett Packard  IBM

Working Together  Open Source but coordinated  Executive Committee directs strategy  Single Architect  Work from Proposals  Agree to objectives before doing the work  Regular, Stable Releases  Developers style guides  Project scheduling and planning

Immediate Activities  CIMOM  Security  Indications  Threading  Providers  Finalize interfaces  Create Provider SDK  Remote providers  Growth of functionality with DMTF  Discovery  Provider standardization (registration, interfaces)  Next generation interoperability Pegasus will go where the contributors want it to go

Pegasus and Other Manageability Projects  AIC – Application and Control  AIC as a Pegasus Provider  ARM – Applications Response Measurement  ARM and DMTF DAP Information as Pegasus Provider  Other possible Providers  JMX (Java)  SNMP (mapping already defined)  DMI (mapping already defined)

6. A Challenge for all of us

CIMOMs - Basic Concepts  Tool to create Management Interoperability  Infrastructure for manageability  Manageability interoperability  Xml-cim today, ??? Tomorrow  Instrumentation Interoperability  Many providers, few CIMOMs  Lots of applications – limited numbers of providers

However  We do not make money off of infrastructure  If we don’t have common interfaces we will not have interoperability.  WBEM will be useful only when it becomes ubiquitous  CIM is not Easy. Creating complete and Correct CIM environments is not easy  There is a lot of work to do with a common environment and much more with many different environments

Creating an interoperable environment  Creating a common interoperability environment  Management – Manageability – xml-cim  Providers – APIs and protocols  Provider building – Common object implementations  The choice  Build a common structure with contributions  Everybody does their own thing. (Many incompatible and incomplete WBEM Implentations

The Challenge!!!  Can we create a common WBEM infrastructure?  OR  do we all go our own way?

Making WBEM Ubiquitous  We are all involved.  Suppliers  Software/application suppliers  End User organizations  We will only get what we really demand

Where to Get More Information  Pegasus is public and Open Source   Pegasus WEB Site  Source Code  Builds on Linux and Windows  Snapshots and CVS  Binary Release  Documentation  Pegasus Working Group Contributors and Users of the Code are Welcome This presentation is on the Pegasus Site