1 / 75

Overview of Pegasus An Open-Source WBEM implementation

Agenda. Overview -What (and why)is Pegasus?The Pegasus EnvironmentThe Pegasus Software ArchitecturePegasus Status TodayPlansThe Pegasus ProjectA Challenge for the Future. 1. Overview. What is Pegasus?. Pegasus is an open-source reference implementation of the DMTF WBEM specificationsPegasus

dareh
Télécharger la présentation

Overview of Pegasus An Open-Source WBEM implementation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


    1. Overview of Pegasus An Open-Source WBEM implementation 17 July 2001 Karl Schopmeyer(k.schopmeyer@opengroup.org)

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

    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

    8. Pegasus Working Group Philosophy Manageability not management The 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

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

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

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

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

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

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

    16. WBEM Architectures

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

    18. DMTF WBEM Components

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

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

    21. Interoperability XML encoding Definition for each operation HTTP Transport HTTP 1.0 and 1.1 Common Operations Semantics Data Meta data Queries? Methods

    22. Managed Object Format (MOF)

    24. Major Components

    25. Key Interoperability Interfaces

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

    27. Pathways of Communication

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

    29. Component Location in Pegasus Today

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

    31. Communication Mechanisms in Pegasus

    32. The Pegasus CIMOM

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

    34. Operation Routing

    35. Operation Routing

    36. Indication Routing

    37. Request Lifecycle

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

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

    40. Building A Modular Manageability Environmnent

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

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

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

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

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

    46. Connectors (Protocol Adapters) Functions Adapt to different protocols Characteristics Protocol Encoding Security Discovery Examples Xml-CIM Local Protocols Soap WMI Corba environment interface

    47. Pegasus Manageability Environment

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

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

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

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

    52. 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); }

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

    55. The Components Today

    56. CIM Functionality Missing From Phase 1 Events Security WQL and Query

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

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

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

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

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

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

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

    65. Project Contributors Moving from core development to adding functionality Major Contributors BMC Compaq Hewlett Packard IBM

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

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

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

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

    71. However We do not make money off of infrastructure If we dont 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

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

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

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

    75. Where to Get More Information Pegasus is public and Open Source www.opengroup.org/pegasus Pegasus WEB Site Source Code Builds on Linux and Windows Snapshots and CVS Binary Release Documentation Pegasus Working Group

More Related