Project Phasing for Pegasus Development Project

The Pegasus project is broken into multiple phases, each phase producing:

  1. A working implementation with the capabilities defined
  2. Documentation on the implementation
  3. Specification of architecture, components and interfaces completed in that phase

This page defines the phases for the Pegasus project including the objectives of each phase and the capabilities and functions that will be required to meet these objectives

Phase 0 -  Core Facilities

Objective: Make the MSB core functionality and interfaces available to an extended team of developers, users, and testers.  We want to make the basic capabilities of the MSB including the capability to load classes and attach consumers to be available so that work can continue on the provider and services capabilities.  This will be only an internal release, and not available outside the Pegasus project team. This version will not be able to register, or call providers.

Capabilities Expected:

  1. Compile and install classes in the MSB
  2. Access the classes through a standard CIM/XML/HTTP client. We are not certain what level of Pegasus test client will be available at this time.

Functions Implemented

  1. MOF Compiler
  2. Class Repository and Class repository interface - The class repository we be a very simplistic and low performance implementation probably based on directories and files.
  3. MSB with semantic checking ( The MSB is used by the compiler to install classes
  4. Consumer Direct (Native) Interface
  5. Consumer CIM/XML/HTTP consumer adapter and CIM/XML/HTTP protocol between CIM Server and CIM client.

Components Produced - At least the following components will be part of this release

  1. Source code for base level 0 MSB that can be installed in either Linux or Windows for compilarion
  2. Commandline MOF compiler (source code)
  3. Extensive test examples for the client interface
  4. Note that we do not intend to provide binary versions in this phase nor will we provide copies of external tools used for the implementation (ex. AICE Wrappers). Instucitons on the acquisition and installation of these tools will be provided with the release
  5. Preliminary user manual defining the interfaces, installation procedures, etc.

Documentation Required - Utilization, installation, and interface definitions so that other members of the project team can work with the code.  We do not expect to have a specification available at this time.

Minimum Platforms Supported - Linux, Windows NT

Time Frame: Available  on the TOG WEB distribution before 1 December 2000

COMMENTS:  To accomplish this phase, we expect to use client tools from other projects such as the SNIA client rather than have a working client built for ourselves.

Utilization of the output of Phase 0 - The primary use of this base will be to develop the phase one capabilities including:

  1. Develop the Provider interfaces and provider dispatching
  2. Develop and test Sample providers
  3. Develop and test sample clients
  4. Define, develop and test the services interface
  5. Implement Instance repository
  6. Develop and test dynamic loading of providers
  7. Threading framework ????
  8. Implement user Authentication and Service interface for Authentication

Interim Activities between Phase 0 and Phase 1 delivery -

  1. Development listed above.
  2. Face to face design and planning meetings 1) December 2000, 2) January 2001.

Phase 1 - Working Basic MSB with Providers, Clients, Services

Objective: Extend phase 0 to produce an implementation that can load and access providers and services from standard WBEM consumers and from local (native interface) consumers. In addition, it is important the the services concepts and interfaces be clarified as part of the Phase one project because the services concept is key to our implementation. To demonstrate that this environment we propose the implement at least one additional language binding from the both the consumer and provider interface.

The results of this phase and all resulting phases will be made publicly available. This phase must include both code, documentation and the first version of the specification.

Capabilities Expected

  1. Simple Authentication of clients - Since the authentication is expected to be an attachable internal services, the internal service interface must be defined.
  2. Implement all CIM HTTP Version 1 defined operations
  3. Delegation of operations to repository or providers 
  4. Collation of provider results for operation response
  5. Simple external manageability test service to show concepts of the service extensibility

Functions Implemented - The following list defines the primary functions to be defined and implemented in Phase 1

  1. Provider registration - Today this is based on a proprietary class (provider) and registration is the creation of an instance of this classs.  However, the Interop WG is working today on the implementaiton of a standard registration mechanism ( a provider class that defines the registration and capabilities information for a provider) and if possible we will implement based on the preliminary version of this class.
  2. Provider loading - Dynamic loading of providers. using the direct  C++ api as the MSB/provider interface. To do this, first the interfaces for the provider must be defined and a basic SDK for the provider defined (see the items below)
  3. C++ Provider APIs - Definition of the provider APIs.  These APIs will be based on the C++ cleint APIs with possible additional parameters to improve efficiency of operations between the provider and MSB. 
  4. Direct Client APIs - The C++ client APIs have been defined and documented as part of Phase 0.  However, we expect that the experience of implementation and use in developing clients and the client role for providers will lead to some changes to these APIs. Since the release of the draft specification of these APIs will not be made until the end of phase 1 we do not have to worrry about compatibility problems between clients and the MSB except for clients that are being developed within the group.
  5. Direct C++ services API - We must completely define and implement the services extensions concepts and interfaces. We believe today that there will be several level of service extensions including Internal MSB service extensions (ex. authentication) and manageability services that can be made available to the 
  6. IPC and possibly remote system provider and service APIs - We want to be certain that providers and services can be connected to the MSB from other processes and possibly from other systems.  We must define the interfaces for this (initially we are looking at keeping the current synchronous interfaces and using threading) and what ever protocol and serialization will be required to accomplish this extension.
  7. Test providers - TBD
  8. Scripting Client and Provider - We want to develop at least one very high level scripting client and provider and are looking at TCL as the basis for this today.  This will be used both for our testing and as an example of a working script based client and provider.
  9. Authentication service
  10. Test Clients
  11. Provider SDK - We will define an SDK for providers as a tool to simplify provider development.
  12. Services SDK - Define and implement an SDK for the services interface to simplify the development of services
  13. Client SDK (Possibly) - TBD

Documentation Required - 1) Draft version 1 specificaiton for the MSB, user documentation for the implementation, and 3) programmer documentation (integrated with the code)

Minimum Platforms Supported - Linux, Windows NT

  1. Deliverables for Phase 1 -
  2. Source code for MSB
  3. Source code for sample clients, providers, services
  4. Documentation
  5. Initial Pegasus specification
  6. Binary distribution of the broker for at least Linux and Windows platforms for testing

Expected Utilization of the Output of Phase 1 -

Time Frame: Completed so that a complete demonstration of functionality can be made at the TOG February 2001 meeting.

Phase 2 - Extension for Events and Java Interfaces

Objective: Extend Phase one to include the DMTF model for events and to incorporate JAVA interfaces into the architecture. This will require implementation of the query language as well as event processing and forwarding mechanisms in the MSB. 

Capabilities Expected

  1. Ability to create clients that can process events
  2. Event process and forwarding in the MSB
  3. Ability to attach Java based services and providers

Functions Implemented

  1. Query language implementation - We assume that this has to exist as an MSB service.  Our objective is to implementa at least the Level one Query language
  2. Event Processing in the MSB
  3. Event forwarding
  4. Provider negotiation of services with MSB
  5. Events based services extensions
  6. Java extensions to JVM
  7. Test Java services
  8. Test Java Providers

Minimum Platforms Supported - Linux, Windows NT

Time Frame: We expect this phase to be finished by the June 2001 DMTF Sysdev.  We would hope to be able to conduct interoperability testing at that event.

COMMENTS: There is a demonstration event planned by SNIA for some time in April 2000. We need to investigate whether we will have enough of Phase 2 operational to attend this event.  At least, we should consider taking whatever stable version of the platform we have to the SNIA event.

Phase 3

Objective: Extend the manageability model to networks including CIMOM-CIMOM operations, discover of CIMOMs, a more transparent naming concept, etc.

Capabilities Expected

  1. Undefined

Functions Implemented

  1. Undefined

Time Frame: Undefined

Last Update Wednesday, November 22, 2000 08:39 AM .  For further information or to make comments email k.schopmeyer@opengroup.org