Return to
CreatingMultipleProviderInterfaces.htm
CVS log
Up to [Pegasus] / pegasus / doc / WorkPapers
|
Return to
CreatingMultipleProviderInterfaces.htm
CVS log
|
Up to [Pegasus] / pegasus / doc / WorkPapers
|
|
File: [Pegasus] / pegasus / doc / WorkPapers / CreatingMultipleProviderInterfaces.htm
(download)
/
(as text)
Revision: 1.2, Tue Jun 5 11:08:42 2001 UTC (22 years, 11 months ago) by karl Branch: MAIN CVS Tags: version_1_01, version_0_99_1, version_0_99, version_0_97_3, version_0_79_4, test, preBug9676, postBug9676, pep_88, pegasus25BeforeLicenseUpdate, merge_of_dev, mday-merge-start, mday-merge-pegasus/src/Pegasus/Server, mday-merge-pegasus/src/Pegasus/Common, mday-2-0-patches, main, local, dev_dead, dev, VERSION_2_1_RELEASE_HEAD, VERSION_2_1_RELEASE_BRANCH, VERSION_2_1_RELEASE, VERSION_2_1_1_RELEASE, VERSION_2_01_01, VERSION_2_00_RC_4, VERSION_2_00_RC_3, VERSION_2_00_RC_2, VERSION_2_00_RC_1, VERSION_2_00_BRANCH, VERSION_1_10, VERSION_1_09, VERSION_1_08, VERSION_1_07, TEST, TASK_PEP328_SOLARIS_NEVADA_PORT, TASK_PEP317_1JUNE_2013, TASK_PEP233_EmbeddedInstSupport-merge_out_trunk, TASK_BUG_5314_IPC_REFACTORING_ROOT, TASK_BUG_5314_IPC_REFACTORING_BRANCH, TASK_BUG_5314_IPC_REFACTORING-V1, TASK_BUG_5191_QUEUE_CONSOLIDATION_ROOT, TASK_BUG_5191_QUEUE_CONSOLIDATION_BRANCH, TASK-TASK_PEP362_RestfulService_branch-root, TASK-TASK_PEP362_RestfulService_branch-merged_out_from_trunk, TASK-TASK_PEP362_RestfulService_branch-merged_in_to_trunk, TASK-TASK_PEP362_RestfulService_branch-merged_in_from_branch, TASK-TASK_PEP362_RestfulService_branch-branch, TASK-TASK-BUG4011_WinLocalConnect-branch-New-root, TASK-TASK-BUG4011_WinLocalConnect-branch-New-merged_out_to_branch, TASK-TASK-BUG4011_WinLocalConnect-branch-New-merged_out_from_trunk, TASK-TASK-BUG4011_WinLocalConnect-branch-New-merged_in_to_trunk, TASK-TASK-BUG4011_WinLocalConnect-branch-New-merged_in_from_branch, TASK-TASK-BUG4011_WinLocalConnect-branch-New-branch, TASK-PEP362_RestfulService-root, TASK-PEP362_RestfulService-merged_out_to_branch, TASK-PEP362_RestfulService-merged_out_from_trunk, TASK-PEP362_RestfulService-merged_in_to_trunk, TASK-PEP362_RestfulService-merged_in_from_branch, TASK-PEP362_RestfulService-branch, TASK-PEP348_SCMO-root, TASK-PEP348_SCMO-merged_out_to_branch, TASK-PEP348_SCMO-merged_out_from_trunk, TASK-PEP348_SCMO-merged_in_to_trunk, TASK-PEP348_SCMO-merged_in_from_branch, TASK-PEP348_SCMO-branch, TASK-PEP328_SOLARIS_NEVADA_PORT_v2-root, TASK-PEP328_SOLARIS_NEVADA_PORT_v2-branch, TASK-PEP328_SOLARIS_NEVADA_PORT-root, TASK-PEP328_SOLARIS_NEVADA_PORT-branch, TASK-PEP328_SOLARIS_IX86_CC_PORT-root, TASK-PEP328_SOLARIS_IX86_CC_PORT-branch-v2, TASK-PEP328_SOLARIS_IX86_CC_PORT-branch, TASK-PEP317_pullop-root, TASK-PEP317_pullop-merged_out_to_branch, TASK-PEP317_pullop-merged_out_from_trunk, TASK-PEP317_pullop-merged_in_to_trunk, TASK-PEP317_pullop-merged_in_from_branch, TASK-PEP317_pullop-branch, TASK-PEP311_WSMan-root, TASK-PEP311_WSMan-branch, TASK-PEP305_VXWORKS-root, TASK-PEP305_VXWORKS-branch-pre-solaris-port, TASK-PEP305_VXWORKS-branch-post-solaris-port, TASK-PEP305_VXWORKS-branch-beta2, TASK-PEP305_VXWORKS-branch, TASK-PEP305_VXWORKS-2008-10-23, TASK-PEP291_IPV6-root, TASK-PEP291_IPV6-branch, TASK-PEP286_PRIVILEGE_SEPARATION-root, TASK-PEP286_PRIVILEGE_SEPARATION-branch, TASK-PEP274_dacim-root, TASK-PEP274_dacim-merged_out_to_branch, TASK-PEP274_dacim-merged_out_from_trunk, TASK-PEP274_dacim-merged_in_to_trunk, TASK-PEP274_dacim-merged_in_from_branch, TASK-PEP274_dacim-branch, TASK-PEP268_SSLClientCertificatePropagation-root, TASK-PEP268_SSLClientCertificatePropagation-merged_out_to_branch, TASK-PEP268_SSLClientCertificatePropagation-merged_out_from_trunk, TASK-PEP268_SSLClientCertificatePropagation-merged_in_to_trunk, TASK-PEP268_SSLClientCertificatePropagation-merged_in_from_branch, TASK-PEP268_SSLClientCertificatePropagation-branch, TASK-PEP267_SLPReregistrationSupport-root, TASK-PEP267_SLPReregistrationSupport-merging_out_to_branch, TASK-PEP267_SLPReregistrationSupport-merging_out_from_trunk, TASK-PEP267_SLPReregistrationSupport-merged_out_to_branch, TASK-PEP267_SLPReregistrationSupport-merged_out_from_trunk, TASK-PEP267_SLPReregistrationSupport-merged_in_to_trunk, TASK-PEP267_SLPReregistrationSupport-merged_in_from_branch, TASK-PEP267_SLPReregistrationSupport-branch, TASK-PEP250_RPMProvider-root, TASK-PEP250_RPMProvider-merged_out_to_branch, TASK-PEP250_RPMProvider-merged_out_from_trunk, TASK-PEP250_RPMProvider-merged_in_to_trunk, TASK-PEP250_RPMProvider-merged_in_from_branch, TASK-PEP250_RPMProvider-branch, TASK-PEP245_CimErrorInfrastructure-root, TASK-PEP245_CimErrorInfrastructure-merged_out_to_branch, TASK-PEP245_CimErrorInfrastructure-merged_out_from_trunk, TASK-PEP245_CimErrorInfrastructure-merged_in_to_trunk, TASK-PEP245_CimErrorInfrastructure-merged_in_from_branch, TASK-PEP245_CimErrorInfrastructure-branch, TASK-PEP241_OpenPegasusStressTests-root, TASK-PEP241_OpenPegasusStressTests-merged_out_to_branch, TASK-PEP241_OpenPegasusStressTests-merged_out_from_trunk, TASK-PEP241_OpenPegasusStressTests-merged_in_to_trunk, TASK-PEP241_OpenPegasusStressTests-merged_in_from_branch, TASK-PEP241_OpenPegasusStressTests-branch, TASK-Bugs5690_3913_RemoteCMPI-root, TASK-Bugs5690_3913_RemoteCMPI-merged_out_to_branch, TASK-Bugs5690_3913_RemoteCMPI-merged_out_from_trunk, TASK-Bugs5690_3913_RemoteCMPI-merged_in_to_trunk, TASK-Bugs5690_3913_RemoteCMPI-merged_in_from_branch, TASK-Bugs5690_3913_RemoteCMPI-branch, TASK-Bug2102_RCMPIWindows-root, TASK-Bug2102_RCMPIWindows-merged_out_to_branch, TASK-Bug2102_RCMPIWindows-merged_out_from_trunk, TASK-Bug2102_RCMPIWindows-merged_in_to_trunk, TASK-Bug2102_RCMPIWindows-merged_in_from_branch, TASK-Bug2102_RCMPIWindows-branch, TASK-Bug2102Final-root, TASK-Bug2102Final-merged_out_to_branch, TASK-Bug2102Final-merged_out_from_trunk, TASK-Bug2102Final-merged_in_to_trunk, TASK-Bug2102Final-merged_in_from_branch, TASK-Bug2102Final-branch, TASK-Bug2021_RemoteCMPIonWindows-root, TASK-Bug2021_RemoteCMPIonWindows-merged_out_to_branch, TASK-Bug2021_RemoteCMPIonWindows-merged_out_from_trunk, TASK-Bug2021_RemoteCMPIonWindows-merged_in_to_trunk, TASK-Bug2021_RemoteCMPIonWindows-merged_in_from_branch, TASK-Bug2021_RemoteCMPIonWindows-branch, TASK-Bug2021_RCMPIonWindows-root, TASK-Bug2021_RCMPIonWindows-merged_out_to_branch, TASK-Bug2021_RCMPIonWindows-merged_out_from_trunk, TASK-Bug2021_RCMPIonWindows-merged_in_to_trunk, TASK-Bug2021_RCMPIonWindows-merged_in_from_branch, TASK-Bug2021_RCMPIonWindows-branch, TASK-BUG7240-root, TASK-BUG7240-branch, TASK-BUG7146_SqlRepositoryPrototype-root, TASK-BUG7146_SqlRepositoryPrototype-merged_out_to_branch, TASK-BUG7146_SqlRepositoryPrototype-merged_out_from_trunk, TASK-BUG7146_SqlRepositoryPrototype-merged_in_to_trunk, TASK-BUG7146_SqlRepositoryPrototype-merged_in_from_branch, TASK-BUG7146_SqlRepositoryPrototype-branch, TASK-BUG4011_WinLocalConnect-root, TASK-BUG4011_WinLocalConnect-merged_out_to_branch, TASK-BUG4011_WinLocalConnect-merged_out_from_trunk, TASK-BUG4011_WinLocalConnect-merged_in_to_trunk, TASK-BUG4011_WinLocalConnect-merged_in_from_branch, TASK-BUG4011_WinLocalConnect-branch-New, TASK-BUG4011_WinLocalConnect-branch, STABLE, SNAPSHOT_1_04, SLPPERFINST-root, SLPPERFINST-branch, RELEASE_2_9_2-RC2, RELEASE_2_9_2-RC1, RELEASE_2_9_2, RELEASE_2_9_1-RC1, RELEASE_2_9_1, RELEASE_2_9_0-RC1, RELEASE_2_9_0-FC, RELEASE_2_9_0, RELEASE_2_9-root, RELEASE_2_9-branch, RELEASE_2_8_2-RC1, RELEASE_2_8_2, RELEASE_2_8_1-RC1, RELEASE_2_8_1, RELEASE_2_8_0_BETA, RELEASE_2_8_0-RC2, RELEASE_2_8_0-RC1, RELEASE_2_8_0-FC, RELEASE_2_8_0, RELEASE_2_8-root, RELEASE_2_8-branch, RELEASE_2_7_3-RC1, RELEASE_2_7_3, RELEASE_2_7_2-RC1, RELEASE_2_7_2, RELEASE_2_7_1-RC1, RELEASE_2_7_1, RELEASE_2_7_0-RC1, RELEASE_2_7_0-BETA, RELEASE_2_7_0, RELEASE_2_7-root, RELEASE_2_7-branch, RELEASE_2_6_3-RC2, RELEASE_2_6_3-RC1, RELEASE_2_6_3, RELEASE_2_6_2-RC1, RELEASE_2_6_2, RELEASE_2_6_1-RC1, RELEASE_2_6_1, RELEASE_2_6_0-RC1, RELEASE_2_6_0-FC, RELEASE_2_6_0, RELEASE_2_6-root, RELEASE_2_6-branch-clean, RELEASE_2_6-branch, RELEASE_2_5_5-RC2, RELEASE_2_5_5-RC1, RELEASE_2_5_5, RELEASE_2_5_4-RC2, RELEASE_2_5_4-RC1, RELEASE_2_5_4, RELEASE_2_5_3-RC1, RELEASE_2_5_3, RELEASE_2_5_2-RC1, RELEASE_2_5_2, RELEASE_2_5_1-RC1, RELEASE_2_5_1, RELEASE_2_5_0-RC1, RELEASE_2_5_0, RELEASE_2_5-root, RELEASE_2_5-branch, RELEASE_2_4_FC_CANDIDATE_1, RELEASE_2_4_3, RELEASE_2_4_2, RELEASE_2_4_1-BETA3, RELEASE_2_4_1-BETA2, RELEASE_2_4_1-BETA1, RELEASE_2_4_1, RELEASE_2_4_0-RC3, RELEASE_2_4_0-RC2, RELEASE_2_4_0, RELEASE_2_4-root, RELEASE_2_4-branch, RELEASE_2_3_2-testfreeze, RELEASE_2_3_2-root, RELEASE_2_3_2-releasesnapshot, RELEASE_2_3_2-branch-freeze, RELEASE_2_3_2-branch, RELEASE_2_3_1-root, RELEASE_2_3_1-branch, RELEASE_2_3_0-root, RELEASE_2_3_0-msg-freeze, RELEASE_2_3_0-branch, RELEASE_2_2_1-snapshot, RELEASE_2_2_0_0-release, RELEASE_2_2_0-root, RELEASE_2_2_0-branch, RELEASE_2_2-root, RELEASE_2_14_1, RELEASE_2_14_0-RC2, RELEASE_2_14_0-RC1, RELEASE_2_14_0, RELEASE_2_14-root, RELEASE_2_14-branch, RELEASE_2_13_0-RC2, RELEASE_2_13_0-RC1, RELEASE_2_13_0-FC, RELEASE_2_13_0, RELEASE_2_13-root, RELEASE_2_13-branch, RELEASE_2_12_1-RC1, RELEASE_2_12_1, RELEASE_2_12_0-RC1, RELEASE_2_12_0-FC, RELEASE_2_12_0, RELEASE_2_12-root, RELEASE_2_12-branch, RELEASE_2_11_2-RC1, RELEASE_2_11_2, RELEASE_2_11_1-RC1, RELEASE_2_11_1, RELEASE_2_11_0-RC1, RELEASE_2_11_0-FC, RELEASE_2_11_0, RELEASE_2_11-root, RELEASE_2_11-branch, RELEASE_2_10_1-RC1, RELEASE_2_10_1, RELEASE_2_10_0-RC2, RELEASE_2_10_0-RC1, RELEASE_2_10_0, RELEASE_2_10-root, RELEASE_2_10-branch, PRE_LICENSE_UPDATE_2003, PREAUG25UPDATE, POST_LICENSE_UPDATE_2003, POSTAUG25UPDATE, PEP286_PRIVILEGE_SEPARATION_ROOT, PEP286_PRIVILEGE_SEPARATION_CODE_FREEZE, PEP286_PRIVILEGE_SEPARATION_BRANCH, PEP286_PRIVILEGE_SEPARATION_1, PEP244_ServerProfile-root, PEP244_ServerProfile-branch, PEP233_EmbeddedInstSupport-root, PEP233_EmbeddedInstSupport-branch, PEP217_PRE_BRANCH, PEP217_POST_BRANCH, PEP217_BRANCH, PEP214ROOT, PEP214BRANCH, PEP214-root, PEP214-branch, PEP213_SIZE_OPTIMIZATIONS, PEP-214B-root, PEGASUS_FC_VERSION_2_2, PEGASUS_2_5_0_PerformanceDev-string-end, PEGASUS_2_5_0_PerformanceDev-rootlt, PEGASUS_2_5_0_PerformanceDev-root, PEGASUS_2_5_0_PerformanceDev-r2, PEGASUS_2_5_0_PerformanceDev-r1, PEGASUS_2_5_0_PerformanceDev-lit-end, PEGASUS_2_5_0_PerformanceDev-buffer-end, PEGASUS_2_5_0_PerformanceDev-branch, PEGASUS_2_5_0_PerformanceDev-AtomicInt-branch, PEG25_IBM_5_16_05, NPEGASUS_2_5_0_PerformanceDev-String-root, NNPEGASUS_2_5_0_PerformanceDev-String-branch, Makefile, MONITOR_CONSOLIDATION_2_5_BRANCH, LOCAL_ASSOCPROV-ROOT, LOCAL_ASSOCPROV-BRANCH, IBM_241_April1405, HPUX_TEST, HEAD, CQL_2_5_BRANCH, CIMRS_WORK_20130824, CHUNKTESTDONE_PEP140, BeforeUpdateToHeadOct82011, BUG_4225_PERFORMANCE_VERSION_1_DONE Changes since 1.1: +8 -0 lines add documentation |
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Creating Multiple Provider Interfaces</title>
</head>
<body>
<H1 align="center">Pegasus Project Working Paper</H1>
<H1 align="center">CREATING MULTIPLE PROVIDER INTERFACES</H1>
<b>AUTHORS:</b> Karl Schopmeyer
<p><font size="1">Last Update <!--webbot bot="Timestamp" startspan
S-Type="EDITED" S-Format="%A, %B %d, %Y %I:%M %p" -->Sunday, June 03, 2001 09:03 PM<!--webbot
bot="Timestamp" i-CheckSum="43635" endspan -->
</font></p>
<p>Revision Status</p>
<table border="1" width="80%">
<tr>
<td width="25%"><b>Revision</b></td>
<td width="25%">Date</td>
<td width="25%">Author(s)</td>
<td width="25%">Reason</td>
</tr>
<tr>
<td width="25%">0.8</td>
<td width="25%">2 June 2001</td>
<td width="25%">KS</td>
<td width="25%">Partly done</td>
</tr>
<tr>
<td width="25%"> </td>
<td width="25%"> </td>
<td width="25%"> </td>
<td width="25%"> </td>
</tr>
<tr>
<td width="25%"> </td>
<td width="25%"> </td>
<td width="25%"> </td>
<td width="25%"> </td>
</tr>
<tr>
<td width="25%"> </td>
<td width="25%"> </td>
<td width="25%"> </td>
<td width="25%"> </td>
</tr>
</table>
<h2>Introduction</h2>
<p>The following is a discussion document to form the basis for deciding if a
more flexible interface for providers would be logical</p>
<h2>Requirement</h2>
<p>The clear requirement is that in the future we will be required to support
multiple language bindings for Pegasus for several reasons:</p>
<ol>
<li>The SUN WBEM Java bindings are a requirement to support a large set of
providers already written and to allow writing other providers in Java in
the future.</li>
<li>We have long discussed providers written in scripting languages like TCL
or even the shell.</li>
<li>There has been interest in interfacing components written in Perl into
Pegasus.</li>
<li>There has been a demand for a C interface since a lot of providers are
written in C.</li>
</ol>
<p>Thus we expect to see multiple language bindings.</p>
<p>It also becomes clear that even in C++ there may be demands for multiple
types of interfaces although this is not yet clear. Thus, for example, we
today have an interface the incorporates all of the CIM Operations into one
Interface Class (provider). There is a demand now to create several
interfaces that breaks the CIM Operations into multiple groups probably by
object type (Instance, property, method, association, Indication). In this
model, each interface would implement the methods associated with its object
(get, set, create, etc.). To implement an provider for more than one type of
these interfaces, the provider would have to implement the different interfaces.</p>
<p>Both of these models have logic and it is not clear that one or the other is
universally better. While the majority of the users will probably use the
multiple interface approach, we need not change the existing approach or remove
it. It can be kept as a separate provider interface.</p>
<p>There is also the consideration we must give to migration and change in the
future. It is a serious question how we can protect existing providers
from change and at the same time migrate the the environment to match future
requirements and changes.</p>
<h2>TECHNOLOGY</h2>
<p>The proposal is that we implement a provider interface module as a separate
entity -- separate interface modules. Each interface module would
implement a set of interfaces. We would keep a core interface in the Core
Pegasus (probably similar to the existing interface with the general changes
proposed) and to implement any other
interface, Provider Interface modules would perform the transforms between the
"base interface" and other interfaces.</p>
<p>We would define the rules for how we create a provider interface module. A
new provider interface would be created as a separate entity and installed as a separate
module (typically a shared library in those environments that support
shared libraries).</p>
<p>NOTE: Caldera is implementing something similar in the Caldera OpenWBEM and
they have currently chosen to implement it using the provider
registration. </p>
<p>In fact, this technique is much more general in that it does not require
anything special in the provider, simply knowledge from the registration of
which interface to call.</p>
<p>I propose that we use something similar and further that we propose that a
field be incorporated into the provider registration classes to build this into
the next generation of provider registration being defined now within the
Interop Group.</p>
<p>Our presumption is that this will separate the writing of provider language
bindings and other interfaces from the Pegasus core and allow these interfaces
to be created separatly. This will further help organize the tasks of creating a
modular environment for Pegasus.</p>
<h3>Determining the Provider interface.</h3>
<p> The module interfaces will be defined on a class, method, or property
basis. Each class/method/property could go to a different provider
interface. One of the questions is the technique we use to pick a particular
interface for a particular provider. Before we issue the first Operation
request to the provider we must know what interface we need to pass through.</p>
<p>Since the interface must be known when you get the first request for the
provider and try to initialize the provider, this information cannot come from
the provider at initialization unless we implement one single known interface
to the provider. In effect we do that today with the Initialize. The
required interface module could be defined through this interface.</p>
<p>An alternative would be to define the particular interface through the
registration of the provider. Today that registration is through the provider
qualifier. In the future it will be through the registration class for the
provider. </p>
<p>NOTE: Caldera modified the current Provider Qualifier to add a field which identifies
the provider interface. A new provider interface can be added to the
CIMOM by simply creating a shared library that creates a Provider Interface
object object a. The format of the provider qualifier that the CIMOM understands is
"<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.
Thus, their compiled in provider interface is <font face="Courier New">"cimom::provider id"</font>
and the C++ interface <font face="Courier New">"c++::provider id"</font>.
</p>
<p>The third possible technique is to start the provider registration class now
and use that as the means to define the interface.
</p>
<p>The first technique ( getting information back at initialize from the
provider about its interface) simply will not work because we cannot guanatee
the provider will have the correct form of interface for initialize. In
some cases, this may be specific to the provider interface. Therefore, our
choice is either the provider qualifier or starting the provider
registration class. I suggest that for the moment, the provider qualifier
is by far the easiest and can be implemented now.</p>
<p>The "interface specific text" is given to the provider interface once it is found, so it can use it to find the appropriate provider. </p>
<h3>Functions Needed</h3>
<p>The only component within the CIMOM that deals directly with provider interfaces is the provider manager
(ProviderTable today). NOTE: We will change the name at some point of the
ProviderTable to ProviderManager. The provider manager is the provider interface
multiplexor.</p>
<p>The functions we need:</p>
<p>1. Find the interface modules. It may be logical to load these all at
startup rather than loading each one when one of its corresponding providers is
loaded.</p>
<p>2. Initialization function for the interface module. Each interface module
must be initialized at its startup.</p>
<p>3. The decision process to determine which interface module to call for each
operation.</p>
<p>TBD</p>
<p> </p>
<p> </p>
<p></p>
<p>---END OF DOCUMENT--</p>
</body>
</html>
| No CVS admin address has been configured |
Powered by ViewCVS 0.9.2 |