Overview of Pegasus An Open-Source WBEM implementation

1. Overview ofPegasusAn Open-SourceWBEM implementation 12 June 2001 Michael Brasher (m.brasher@bmc.com) Karl Schopmeyer(k.schopmeyer@opengroup.org) Version 1.0

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

3. 1. Overview

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

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

6. Origins of Pegasus • Pegasus was initiated in 2000 by the Open Group in collaboration with: • BMC Software • IBM • Tivoli Systems

7. Key Pegasus Objectives • Open source • MIT License, open availability • Portable • Code designed for portability • Efficient and Lightweight • Implemented in C++ • Standards Based • DMTF CIM/WBEM compliant • Modular and extensible • Use both internal and external modularity

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

9. Open Source • Code and documentation freely available • Open Group and Source Forge • MIT source License • Open to contributions

10. Portable • Designed for multi-platform, mulit-os, multi-compilers. • Platforms today • UNIX (AIX, HPUX, Solaris) • Linux • Windows Platforms (NT, 2000, 9x) • Compaq Himalaya (Tandem)

11. Efficient and Lightweight • Core written in C++ • Designed for execution efficiency

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

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

14. 2. The Pegasus Environment

15. Consumers Consumers Clients Services CIM/HTTP Consumers Consumers Providers Pegasus Architecture Standard Interfaces Interoperable* CIM Server Interoperable* In-Process CIM/HTTP

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. Consumers Consumers Clients Services CIM/HTTP Consumers Consumers Providers The CIM Operations Standard Interfaces CIM Operations Interoperable* CIM Object Mgr Repository Repository Interoperable* In-Process CIM/HTTP Indicators

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

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

21. Consumers Providers Pegasus Manageability Environment Management System Management System CIMOM Application Consumer Services core*** additional 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 Resource Apps OS Etc.

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

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

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

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

26. Manageability Service Extensions • Super Providers • Access to the Core Broker

27. Example Services • Indication Management service. • Query engine service. • Class repository service. • Instance repository service.

28. Connectors (Protocol Adapters) • Functions • Adapt to different protocols • Characteristics • Protocol • Encoding • Security • Discovery • Examples • Xml-CIM • Local Protocols • Soap • WMI Xml-cim Client Xml-cim Client Xml-cim Connector Soap Connector Pegasus Core Pegasus Provider Connector Connector Java Provider Remote Provider

29. CIM Client Connector Connector Service Extension Service Extension Service Extension Service Extension Repository Repository Provider 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

30. 3. The Pegasus Software Architecture

31. Introduction

32. Major Components Client Client CIM Clients Repository CIM Server Client Client CIM Providers

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

34. Communication

35. Pathways of Communication Client Client CIM Clients CIM Repository CIM Server Client Client CIM Providers

36. Component Location • A component may belocated 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.

37. Component Location in Pegasus Today

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

39. Communication Mechanisms in Pegasus

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

41. An Efficient XML Parser • No memory heap usage during parsing. • Modifies message in place to avoid copying. • Non-validating parser (“loose validation”).

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

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

44. Representation of CIM Elements Representing CIM Elements in Pegasus with C++

45. Uint8 Sint8 Uint16 Sint16 Uint32 Sint32 Uint64 Sint64 Real32 Real64 Boolean Char16 String CIMDateTime CIMReference CIM Data Types in C++

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

47. CIMClass CIMInstance CIMProperty CIMMethod CIMParameter CIMQualifierDecl CIMQualifier CIM Elements in C++

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

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

50. Class Declaration Example (Part 3) • Or more succinctly like this: CIMClass alarmClass(“Alarm”); alarmClass .addProperty(CIMProperty(“id”, Uint32(0)) .addQualifier(CIMQualifier(“key”, true))) .addProperty(CIMProperty(“message”, “none”));