1 karl 1.1 <html>
2
3 <head>
4 <meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
5 <meta name="GENERATOR" content="Microsoft FrontPage 4.0">
6 <meta name="ProgId" content="FrontPage.Editor.Document">
7 <title>Creating Multiple Provider Interfaces</title>
8 </head>
9
10 <body>
11
12 <H1 align="center">Pegasus Project Working Paper</H1>
13
14 <H1 align="center">CREATING MULTIPLE PROVIDER INTERFACES</H1>
15
16 <b>AUTHORS:</b> Karl Schopmeyer
17 <p><font size="1">Last Update <!--webbot bot="Timestamp" startspan
18 S-Type="EDITED" S-Format="%A, %B %d, %Y %I:%M %p" -->Sunday, June 03, 2001 09:03 PM<!--webbot
19 bot="Timestamp" i-CheckSum="43635" endspan -->
20 </font></p>
21 <p>Revision Status</p>
22 karl 1.1 <table border="1" width="80%">
23 <tr>
24 <td width="25%"><b>Revision</b></td>
25 <td width="25%">Date</td>
26 <td width="25%">Author(s)</td>
27 <td width="25%">Reason</td>
28 </tr>
29 <tr>
30 <td width="25%">0.8</td>
31 <td width="25%">2 June 2001</td>
32 <td width="25%">KS</td>
33 <td width="25%">Partly done</td>
34 </tr>
35 <tr>
36 <td width="25%"> </td>
37 <td width="25%"> </td>
38 <td width="25%"> </td>
39 <td width="25%"> </td>
40 </tr>
41 <tr>
42 <td width="25%"> </td>
43 karl 1.1 <td width="25%"> </td>
44 <td width="25%"> </td>
45 <td width="25%"> </td>
46 </tr>
47 <tr>
48 <td width="25%"> </td>
49 <td width="25%"> </td>
50 <td width="25%"> </td>
51 <td width="25%"> </td>
52 </tr>
53 </table>
54
55 <h2>Introduction</h2>
56
57 <p>The following is a discussion document to form the basis for deciding if a
58 more flexible interface for providers would be logical</p>
59
60 <h2>Requirement</h2>
61
62 <p>The clear requirement is that in the future we will be required to support
63 multiple language bindings for Pegasus for several reasons:</p>
64 karl 1.1
65 <ol>
66 <li>The SUN WBEM Java bindings are a requirement to support a large set of
67 providers already written and to allow writing other providers in Java in
68 the future.</li>
69 <li>We have long discussed providers written in scripting languages like TCL
70 or even the shell.</li>
71 <li>There has been interest in interfacing components written in Perl into
72 Pegasus.</li>
73 <li>There has been a demand for a C interface since a lot of providers are
74 written in C.</li>
75 </ol>
76 <p>Thus we expect to see multiple language bindings.</p>
77
78 <p>It also becomes clear that even in C++ there may be demands for multiple
79 types of interfaces although this is not yet clear. Thus, for example, we
80 today have an interface the incorporates all of the CIM Operations into one
81 Interface Class (provider). There is a demand now to create several
82 interfaces that breaks the CIM Operations into multiple groups probably by
83 object type (Instance, property, method, association, Indication). In this
84 model, each interface would implement the methods associated with its object
85 karl 1.1 (get, set, create, etc.). To implement an provider for more than one type of
86 these interfaces, the provider would have to implement the different interfaces.</p>
87
88 <p>Both of these models have logic and it is not clear that one or the other is
89 universally better. While the majority of the users will probably use the
90 multiple interface approach, we need not change the existing approach or remove
91 it. It can be kept as a separate provider interface.</p>
92
93 <p>There is also the consideration we must give to migration and change in the
94 future. It is a serious question how we can protect existing providers
95 from change and at the same time migrate the the environment to match future
96 requirements and changes.</p>
97
98 <h2>TECHNOLOGY</h2>
99
100 <p>The proposal is that we implement a provider interface module as a separate
101 entity -- separate interface modules. Each interface module would
102 implement a set of interfaces. We would keep a core interface in the Core
103 Pegasus (probably similar to the existing interface with the general changes
104 proposed) and to implement any other
105 interface, Provider Interface modules would perform the transforms between the
106 karl 1.1 "base interface" and other interfaces.</p>
107
108 <p>We would define the rules for how we create a provider interface module. A
109 new provider interface would be created as a separate entity and installed as a separate
110 module (typically a shared library in those environments that support
111 shared libraries).</p>
112
113 <p>NOTE: Caldera is implementing something similar in the Caldera OpenWBEM and
114 they have currently chosen to implement it using the provider
115 registration. </p>
116
117 <p>In fact, this technique is much more general in that it does not require
118 anything special in the provider, simply knowledge from the registration of
119 which interface to call.</p>
120
121 <p>I propose that we use something similar and further that we propose that a
122 field be incorporated into the provider registration classes to build this into
123 the next generation of provider registration being defined now within the
124 Interop Group.</p>
125
126 <p>Our presumption is that this will separate the writing of provider language
127 karl 1.1 bindings and other interfaces from the Pegasus core and allow these interfaces
128 to be created separatly. This will further help organize the tasks of creating a
129 modular environment for Pegasus.</p>
130
131 <h3>Determining the Provider interface.</h3>
132
133 <p> The module interfaces will be defined on a class, method, or property
134 basis. Each class/method/property could go to a different provider
135 interface. One of the questions is the technique we use to pick a particular
136 interface for a particular provider. Before we issue the first Operation
137 request to the provider we must know what interface we need to pass through.</p>
138
139 <p>Since the interface must be known when you get the first request for the
140 provider and try to initialize the provider, this information cannot come from
141 the provider at initialization unless we implement one single known interface
142 to the provider. In effect we do that today with the Initialize. The
143 required interface module could be defined through this interface.</p>
144
145 <p>An alternative would be to define the particular interface through the
146 registration of the provider. Today that registration is through the provider
147 qualifier. In the future it will be through the registration class for the
148 karl 1.1 provider. </p>
149
150 <p>NOTE: Caldera modified the current Provider Qualifier to add a field which identifies
151 the provider interface. A new provider interface can be added to the
152 CIMOM by simply creating a shared library that creates a Provider Interface
153 object object a. The format of the provider qualifier that the CIMOM understands is
154 "<font face="Courier New">[interface id]::[interface specific text]</font>". The "interface id" is used by the provider interface multi-plexor to identify the provider interface that can supply the provider.
155 Thus, their compiled in provider interface is <font face="Courier New">"cimom::provider id"</font>
156 and the C++ interface <font face="Courier New">"c++::provider id"</font>.
157 </p>
158
159 <p>The third possible technique is to start the provider registration class now
160 and use that as the means to define the interface.
161 </p>
162
163 <p>The first technique ( getting information back at initialize from the
164 provider about its interface) simply will not work because we cannot guanatee
165 the provider will have the correct form of interface for initialize. In
166 some cases, this may be specific to the provider interface. Therefore, our
167 choice is either the provider qualifier or starting the provider
168 registration class. I suggest that for the moment, the provider qualifier
169 karl 1.1 is by far the easiest and can be implemented now.</p>
170
|
Return to
CreatingMultipleProviderInterfaces.htm
CVS log
Up to [Pegasus] / pegasus / doc / WorkPapers