1 mike 1.1 <html>
2
3 <head>
4 <meta http-equiv="Content-Language" content="en-us">
5 <meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
6 <meta name="GENERATOR" content="Microsoft FrontPage 4.0">
7 <meta name="ProgId" content="FrontPage.Editor.Document">
8 <title>Pegasus Project Phase Defintions</title>
9 </head>
10
11 <body>
12
13 <h1>Project Phasing for Pegasus Development Project</h1>
14 <p>The Pegasus project is broken into multiple phases, each phase producing:</p>
15 <ol>
16 <li>A working implementation with the capabilities defined</li>
17 <li>Documentation on the implementation</li>
18 <li>Specification of architecture, components and interfaces completed in that
19 phase</li>
20 </ol>
21 <p>This page defines the phases for the Pegasus project including the objectives
22 mike 1.1 of each phase and the capabilities and functions that will be required to meet
23 these objectives</p>
24 <h2>Phase 0 - Core Facilities</h2>
25 <p><b>Objective:</b> Make the MSB core functionality and interfaces available to an
26 extended team of developers, users, and testers. We want to make the basic
27 capabilities of the MSB including the capability to load classes and attach
28 consumers to be available so that work can continue on the provider and services
29 capabilities. This will be only an internal release, and not available
30 outside the Pegasus project team. This version will not be able to register, or
31 call providers.</p>
32 <p><b>Capabilities Expected:</b></p>
33 <ol>
34 <li>Compile and install classes in the MSB</li>
35 <li>Access the classes through a standard CIM/XML/HTTP client. We are not
36 certain what level of Pegasus test client will be available at this time.</li>
37 </ol>
38 <p><b>Functions Implemented</b></p>
39 <ol>
40 <li>MOF Compiler</li>
41 <li>Class Repository and Class repository interface - The class repository we be a very simplistic and low performance implementation probably based on
42 directories and files.</li>
43 mike 1.1 <li> MSB with semantic checking ( The MSB is used by the compiler to install
44 classes</li>
45 <li>Consumer Direct (Native) Interface</li>
46 <li>Consumer CIM/XML/HTTP consumer adapter and CIM/XML/HTTP protocol between
47 CIM Server and CIM client.</li>
48 </ol>
49 <p>Components Produced - At least the following components will be part of this
50 release</p>
51 <ol>
52 <li>Source code for base level 0 MSB that can be installed in either Linux or
53 Windows for compilarion</li>
54 <li>Commandline MOF compiler (source code)</li>
55 <li>Extensive test examples for the client interface</li>
56 <li>Note that we do not intend to provide binary versions in this phase nor
57 will we provide copies of external tools used for the implementation (ex.
58 AICE Wrappers). Instucitons on the acquisition and installation of these
59 tools will be provided with the release</li>
60 <li>Preliminary user manual defining the interfaces, installation procedures,
61 etc.</li>
62 </ol>
63 <p><b>Documentation Required </b>- Utilization, installation, and interface
64 mike 1.1 definitions so that other members of the project team can work with the
65 code. We do not expect to have a specification available at this time.</p>
66 <p><b>Minimum Platforms Supported </b>- Linux, Windows NT</p>
67 <p><b>Time Frame: </b>Available on the TOG WEB distribution before 1 December
68 2000</p>
69 <p><b>COMMENTS: </b> To accomplish this phase, we expect to use client
70 tools from other projects such as the SNIA client rather than have a working
71 client built for ourselves.</p>
72 <p><b>Utilization of the output of Phase 0</b> - The primary use of this base
73 will be to develop the phase one capabilities including:</p>
74 <ol>
75 <li>Develop the Provider interfaces and provider dispatching</li>
76 <li>Develop and test Sample providers</li>
77 <li>Develop and test sample clients</li>
78 <li>Define, develop and test the services interface</li>
79 <li>Implement Instance repository</li>
80 <li>Develop and test dynamic loading of providers</li>
81 <li>Threading framework ????</li>
82 <li>Implement user Authentication and Service interface for Authentication</li>
83 </ol>
84 <p><b>Interim Activities between Phase 0 and Phase 1 delivery </b>-</p>
85 mike 1.1 <ol>
86 <li>Development listed above.</li>
87 <li>Face to face design and planning meetings 1) December 2000, 2) January
88 2001.</li>
89 </ol>
90 <h2>Phase 1 - Working Basic MSB with Providers, Clients, Services</h2>
91 <p><b>Objective:</b> Extend phase 0 to produce an implementation that can load and access
92 providers and services from standard WBEM consumers and from local (native interface)
93 consumers. In addition, it is important the the services concepts and interfaces
94 be clarified as part of the Phase one project because the services concept is
95 key to our implementation. To demonstrate that this environment we propose the
96 implement at least one additional language binding from the both the consumer
97 and provider interface.</p>
98 <p>The results of this phase and all resulting phases will be made publicly
99 available. This phase must include both code, documentation and the first
100 version of the specification.</p>
101 <p><b>Capabilities Expected</b></p>
102 <ol>
103 <li>Simple Authentication of clients - Since the authentication is expected to
104 be an attachable internal services, the internal service interface must be
105 defined.</li>
106 mike 1.1 <li>Implement all CIM HTTP Version 1 defined operations</li>
107 <li>Delegation of operations to repository or providers </li>
108 <li>Collation of provider results for operation response</li>
109 <li>Simple external manageability test service to show concepts of the service
110 extensibility</li>
111 </ol>
112 <p><b>Functions Implemented - </b>The following list defines the primary functions
113 to be defined and implemented in Phase 1</p>
114 <ol>
115 <li>Provider registration - Today this is based on a proprietary class
116 (provider) and registration is the creation of an instance of this classs.
117 However, the Interop WG is working today on the implementaiton of a standard
118 registration mechanism ( a provider class that defines the registration and
119 capabilities information for a provider) and if possible we will implement
120 based on the preliminary version of this class.</li>
121 <li>Provider loading - Dynamic loading of providers. using the direct
122 C++ api as the MSB/provider interface. To do this, first the interfaces for
123 the provider must be defined and a basic SDK for the provider defined (see
124 the items below)</li>
125 <li>C++ Provider APIs - Definition of the provider APIs. These APIs will
126 be based on the C++ cleint APIs with possible additional parameters to
127 mike 1.1 improve efficiency of operations between the provider and MSB. </li>
128 <li>Direct Client APIs - The C++ client APIs have been defined and documented
129 as part of Phase 0. However, we expect that the experience of
130 implementation and use in developing clients and the client role for
131 providers will lead to some changes to these APIs. Since the release of the
132 draft specification of these APIs will not be made until the end of phase 1
133 we do not have to worrry about compatibility problems between clients and
134 the MSB except for clients that are being developed within the group.</li>
135 <li>Direct C++ services API - We must completely define and implement the
136 services extensions concepts and interfaces. We believe today that there
137 will be several level of service extensions including Internal MSB service
138 extensions (ex. authentication) and manageability services that can be made
139 available to the </li>
140 <li>IPC and possibly remote system provider and service APIs - We want to be
141 certain that providers and services can be connected to the MSB from other
142 processes and possibly from other systems. We must define the
143 interfaces for this (initially we are looking at keeping the current
144 synchronous interfaces and using threading) and what ever protocol and
145 serialization will be required to accomplish this extension.</li>
146 <li>Test providers - TBD</li>
147 <li>Scripting Client and Provider - We want to develop at least one very high
148 mike 1.1 level scripting client and provider and are looking at TCL as the basis for
149 this today. This will be used both for our testing and as an example
150 of a working script based client and provider.</li>
151 <li>Authentication service</li>
152 <li>Test Clients</li>
153 <li>Provider SDK - We will define an SDK for providers as a tool to simplify
154 provider development.</li>
155 <li>Services SDK - Define and implement an SDK for the services interface to
156 simplify the development of services</li>
157 <li>Client SDK (Possibly) - TBD</li>
158 </ol>
159 <p><b>Documentation Required</b> - 1) Draft version 1 specificaiton for the MSB,
160 user documentation for the implementation, and 3) programmer documentation
161 (integrated with the code)</p>
162 <p><b>Minimum Platforms Supported </b>- Linux, Windows NT</p>
163 <ol>
164 <li>Deliverables for Phase 1 -</li>
165 <li>Source code for MSB</li>
166 <li>Source code for sample clients, providers, services</li>
167 <li>Documentation</li>
168 <li>Initial Pegasus specification</li>
169 mike 1.1 <li>Binary distribution of the broker for at least Linux and Windows platforms
170 for testing</li>
171 </ol>
172 <p><b>Expected Utilization of the Output of Phase 1</b> -</p>
173 <p><b>Time Frame: </b>Completed so that a complete demonstration of
174 functionality can be made at the TOG February 2001 meeting.</p>
175 <h2>Phase 2 - Extension for Events and Java Interfaces</h2>
176 <p><b>Objective:</b> Extend Phase one to include the DMTF model for events and
177 to incorporate JAVA interfaces into the architecture. This will require
178 implementation of the query language as well as event processing and forwarding
179 mechanisms in the MSB. </p>
180 <p><b>Capabilities Expected</b></p>
181 <ol>
182 <li>Ability to create clients that can process events</li>
183 <li>Event process and forwarding in the MSB</li>
184 <li>Ability to attach Java based services and providers</li>
185 </ol>
186 <p><b>Functions Implemented</b></p>
187 <ol>
188 <li>Query language implementation - We assume that this has to exist as an MSB
189 service. Our objective is to implementa at least the Level one Query
190 mike 1.1 language</li>
191 <li>Event Processing in the MSB</li>
192 <li>Event forwarding</li>
193 <li>Provider negotiation of services with MSB</li>
194 <li>Events based services extensions</li>
195 <li>Java extensions to JVM</li>
196 <li>Test Java services</li>
197 <li>Test Java Providers</li>
198 </ol>
199 <p>Minimum Platforms Supported - Linux, Windows NT</p>
200 <p><b>Time Frame: </b>We expect this phase to be finished by the June 2001 DMTF
201 Sysdev. We would hope to be able to conduct interoperability testing at
202 that event.</p>
203 <p>COMMENTS: There is a demonstration event planned by SNIA for some time in
204 April 2000. We need to investigate whether we will have enough of Phase 2
205 operational to attend this event. At least, we should consider taking
206 whatever stable version of the platform we have to the SNIA event.</p>
207 <h2>Phase 3</h2>
208 <p><b>Objective:</b> Extend the manageability model to networks including
209 CIMOM-CIMOM operations, discover of CIMOMs, a more transparent naming concept,
210 etc.</p>
211 mike 1.1 <p><b>Capabilities Expected</b></p>
212 <ol>
213 <li>Undefined</li>
214 </ol>
215 <p><b>Functions Implemented</b></p>
216 <ol>
217 <li>Undefined</li>
218 </ol>
219 <p><b>Time Frame: </b>Undefined</p>
220 <hr>
221 <p>Last Update <!--webbot bot="Timestamp" S-Type="EDITED"
222 S-Format="%A, %B %d, %Y %I:%M %p" startspan -->Wednesday, November 22, 2000 08:39 AM<!--webbot bot="Timestamp" endspan i-checksum="13221" -->
223 . For further information or to make comments email <a href="mailto:k.schopmeyer@opengroup.org">k.schopmeyer@opengroup.org</a></p>
224 <p> </p>
225 <p> </p>
226
227 </body>
228
229 </html>
|
Return to
ProjectPhases.htm
CVS log
Up to [Pegasus] / pegasus / doc