管理应用程序编程: WBEM 和 CIM 简介

Paul Monday继续他关于构建资源管理应用程序的三部分系列文章，以及基于 Web的企业管理 (WBEM) 倡议的知识。WBEM用于标准化企业网络中受管资源的描述和使用。接着，Paul 描述包含 WBEM的组件并使用一个简单的文件系统示例来练习使用此技术。请点击文章顶部和底部的 讨论，与作者和其他读者分享对本文的看法。

在这一系列的 第 1 部分中，我对联邦管理架构，用于为分布式网络创建基于策略的管理解决方案的 Sun Microsystem 的标准框架作了初步介绍。Jiro 技术是 FMA 的单独执行，特别设计用来为交叉平台分布式存储网络构建管理应用程序。

在第 2 部分中，我将重点放在一个与 FMA 有重叠但对于企业计算环境的需求更具体的标准上。基于 Web 的企业管理 (WBEM) 倡议是一套减轻程序和接口（用于管理一个完整的企业环境）编写负担的技术，它由分布式管理工作组 (DMTF) 负责开发。就像分布式存储网络一样，企业计算环境从各种厂商那里集成硬件和软件。造成的后果是网络管理员经常被要求去部署大量的管理应用程序和技术，还得不断学习新技术以保持自己在这个领域中的领先地位。因为企业网络的规模和复杂性将会 -- 实际上一定会 -- 成指数地增长，所以网络管理员几乎要不断地学习，必须为跟上这个领域的新发展而努力奋斗。

通过提供处理受管资源的标准化方法，WBEM 大大简化了创建管理应用程序的过程从而简化了管理企业网络的工作。这将转变成更大、更易管理的计算机网络，同时也更好地利用了管理员的时间和精力。

为了开始学习 WBEM，我将提供一份组成这个标准的组件的概述，并讲解如何把它们作为框架使用来开发管理应用程序。

WBEM 概述

WBEM 作为一项业界倡议，起始于 1996 年，它规范了企业网络中受管资源的描述与使用。WBEM 由以下几个组件组成：

• 公共信息模型 (CIM) 是一种机制，用于为受管资源建模并以受管对象格式 (MOF) 表现这些模型。使用 CIM 和 MOF，组成受管资源或资源网络的组件可以象在面向对象设计过程中使用的组件一样被建模和看待。
• 受管对象格式 (MOF) 是源自 CIM 模型中的类和关联的正规描述。MOF 有它独有的语法，但使用来自于 DMTF 中的 DTD 可将它转化为 XML。
• 标准化模型是一个 CIM 类集合，用于表现一个特殊的管理域。模型可以表现核心 CIM 类、网络类、软件类和更多的类。
• CIM 对象管理器 (CIMOM) 是 CIM 类实例的一个数据库。CIMOM 是访问管理资源的重点。
• XML API 提供对数据的标准化访问并启用针对 CIMOM 中显示的受管资源的操作。

各个公司提供自己对 WBEM 的实现，它们都必须遵循由 DMTF 提出的规范。所有符合 WBEM 的技术必须接受由 DMTF 发行的标准化模型并且所有关联的 CIMOM 都可通过标准 XML API 访问。

存储网络工业协会 (SNIA) 的成员正在构建一个开放源代码的 CIMOM，它基于 WBEM 标准同时松散地基于 Sun Microsystem 对 WBEM 的实现。SNIA 和 Sun 的实现都是在 Java 平台上构建的。微软还用 Windows 管理规范 (WMI) 技术提出了基于 WBEM 的解决方案。（请参阅 参考资料，可得到完整的基于 WBEM 技术的清单）

在下一节，我们将深入探讨组成 WBEM 的各个组件。我将使用类似于我们在这个系列的第 1 部分中使用的文件系统的示例，来循序渐进地解释一个简单的基于 WBEM 的开发过程。我们必须熟悉这个将用来建模和构建文件系统的过程，因为它接近地反映了传统的面向对象的先建模（典型情况下通过 UML ）后编程的开发周期。我们将按以下步骤进行：

• 用 CIM 建模技术为环境建模。
• 为类和类之间的关联产生 MOF 。
• 为要求动态数据更新的类构建动态提供者。
• 将 MOF 导入 CIMOM 并植入类实例要求的任意静态数据。
• 通过 CIMOM 的 API 使用受管对象。（我们将为这个系列的最后一部分保留这一步）

在这篇文章中，我已使用了 SNIA 中的开放源代码 CIMOM 创建示例。请参阅 参考资料，下载 SNIA 的 CIMOM。

 

回页首

 

公共信息模型

公共信息模型(CIM)，目前为 2.2 版，以类似对象设计图和称为受管对象格式 (MOF) 的模型的中性语言描述的形式，提供了一个数据建模环境。在这一点上，CIM 建模环境 和 MOF 与统一建模语言 (UML)、接口定义语言 (IDL) 很相似。

CIM 开发周期与面向对象开发周期非常相似，在此周期内要开发类图，创建类的中性语言描述和它们的关联，实现类，然后部署并使用结果数据和操作。CIM 开发在两个重要方面反映了面向对象的开发：一是它使用继承来扩展现有的类，二是它用类图作为转换数据结构的主要机制。

然而，与面向对象的类不同，CIM 的类包含唯一标识对象实例的关键字。纯面向对象的设计不用关键字标识实例（虽然一些对象技术 -- 诸如 Enterprise JavaBeans -- 的确有关键字定义）。另外，CIM 包含一个很象数据库连接的特别的 关联类。这个关联涉及的实例，就象磁盘外壳和外壳里的物理磁盘。这种关联不是创建外壳和磁盘类之间的关系，而是定义两个类之间的关系。类本身没有这样的关系。通过关联而不是通过显式查询受管资源类实例来为实例定位。使用 CIM 对象实例中的关键字才可使关联定位成为可能。

CIM 和纯面向对象设计的区别是由于它们在各自环境中有不同的使用意向。然而面向对象技术已经发展成服务于创建应用程序编程环境的需求，CIM 则明确地适用于描述，编目录和与受管资源交互。为进一步理解 CIM 是如何工作的，应该看创建和构建它的类层次和各种模型的方式。

如何创建 CIM 模型

DMTF 通过在标准体中的重复创建一个分层类层次，它正确反映需管理的各种区域中的可管理元素。每个管理区域，如存储器或应用程序，都显示在 CIM 模型中。在这些管理区域中细化的 DMTF 标准体工作在不同的管理区域上。图 1 说明了 CIM 模型在概念上是如何层叠的。核心模型居中，其它模型依次构建体现了更为具体的管理区域。

图 1. CIM 模型 
 

核心模型是按 Java 平台类层次的结构构建的。核心模型包含所有管理区域公共的类与关联。例如，所有可管理元素是从一个名为 CIM_ManagedElement 的类继承而来的。在下面的清单 1 中，可以看到一个受管元素包含一套所有可管理实体的公共基本属性。我们将立刻讨论更多关于 MOF 的内容 -- 清单 1 中使用的语言。到目前为止，仅仅看到了模型的结构。

清单 1. CIM_ManagedElement类

// ==================================================================// ManagedElement// ==================================================================     [Abstract, Description (     "ManagedElement is an abstract class that provides a common "    "superclass (or top of the inheritance tree) for the "    "non-association classes in the CIM Schema.")]     class CIM_ManagedElement     {       [MaxLen (64), Description (        "The Caption property is a short textual description (one-"        "line string) of the object.") ]       string Caption;       [Description (        "The Description property provides a textual description of "        "the object.") ]       string Description;     };

 

受管元素的子类包含逻辑元素和物理元素，如图 2 的一个 CIM 模型所示。物理元素可以触及且／或是可以编码的。逻辑元素通常表示一个软件层。

图 2. 基础 CIM 层次 
 

除核心模型之外，个别工作组已经为特殊的管理领域，如网络、设备、用户、应用程序等创建了标准。这些标准扩展了核心模型并脱离核心模型发展，虽然它们将在新版的完整模型中趋向统一。关联类仍然是模型定义中的一大部分。基础关联作为受管元素间的公共关系存在。

 

回页首

 

CIM 建模和 MOF

图 2 清楚地表明，使用 CIM 建模与用 UML 类图表建模非常相似。与 UML 一样，CIM 提供了一套图表用于许多种情况下的建模。完整的 CIM 入门远在这篇文章的范围之外，但您需知道它的基本知识以看懂下面的图表。

CIM 用着色编码通过系统实时传达类结构和对象移动。这一点我们在图 2 中须注意：

• 蓝线表示继承。
• 红线表示关联，线上标明了关联名。请记住，关联是它自己类的类型。
• 绿线表示集成。集成是关联的特殊情况。

关键字根据属性定义指定，并将以一种简单的符号： [key] 出现在图中。注意，多个属性可以形成一个特殊的实例的关键字。

MOF 和 Java 语言

MOF 语言是作为整个 WBEM 规范的一部分由 DMTF 定义的。DMTF 有许多与表现 CIM 模型的 MOF 一起工作的工具。MOF 包含了一套内在的数据类型，您可以在 CIM 规范中找到它们。基于这篇文章的主旨，我们仅关注那些基本的数据类型，如下所示：

• string : 一个 UCS2 字符串
• boolean : 一个布尔值，真或假
• datetime : 一个包含日期／时间的字符串
• uint8 : 一个无符号 8 位整数
• int8 : 有符号 8 位整数

虽然这些类型与 Java 语言相类似，但这种类似是不精确的。所以，我们在用 Java 语言为实现 CIM 编程时千万要小心，尤其在处理驻留在 CIM 对象管理器中的数据时更要特别仔细。

回顾一下清单 1，您会注意到类 CIM_ManagedElement 的声明是在括号中的元数据之后。以下是清单 1 中的元数据：

清单 2. 类 CIM_ManagedElement的元数据

    [Abstract, Description (     "ManagedElement is an abstract class that provides a common "    "superclass (or top of the inheritance tree) for the "    "non-association classes in the CIM Schema.")]

 

在 MOF 中的每个声明前都可以有这样的元数据。在这种情况下，元数据告诉我们受管元素类是抽象的并提供类的声明。可为不同的数据类型和声明声明不同的限定符。例如，字符串可以声明一个 MAXLEN 限定符，它将限制字符串的长度，或一个数组可以声明一个 VALUES 限定符，它将指明要输入数组的值的集合。CIM 规范列出了很多可以应用于不同声明的限定符。

我们将在这篇文章中使用简单的模型和 MOF，但必须知道为受管理资源建模的复杂性和精确性而且用 MOF 表现那些模型会很快增长。由于缺乏完整的集成工具集，所以开发环境变得更加复杂。请参阅 参考资料，下载 CIM 规范和更多关于 CIM 建模和 MOF 的信息。

 

回页首

 

CIM 对象管理是如何工作的

整个 CIM 模型和标准扩展是软硬件厂商为便于进一步扩展而建立的。在一个面向对象的设计过程完成时，您就可以将设计付诸实践。同样，一旦一个 CIM 模型和 MOF 定义完成时，软件包被导入到一个 CIM 对象管理器 (CIMOM)。CIMOM 提供了一个中心库，网络客户可在其中收集关于系统中受管资源的信息。

从现在开始我们将关注数据是如何进入 CIMOM 的。在下一部分中，我们将重点了解网络客户如何平衡驻留在 CIMOM 中的数据和受管资源的操作特性。

植入 CIMOM

将数据植入 CIMOM 是从在 CIMOM 中导入或创建受管资源定义开始。这很象在数据库中创建一个表。定义复杂类的 MOF 文件先被导入 CIMOM，随后导入一个类的实例，该类与一个可在 CIMOM 中创建的指定的受管资源有关。

您可以使用一个客户接口来创建类实例，但那并不是植入 CIMOM 的最普遍的机制。通常，您将为 CIMOM 提供静态数据，或者您得到一个能提供动态数据的提供者类。图 3 是对 CIMOM 和其组件的逻辑描述。

图 3. CIMOM 的逻辑描述 
 

数据的状态 -- 静态或动态 -- 将取决于包含在 MOF 文件中的元数据。我们在接下来的部分中将进一步讨论这个问题。但首先，让我们创建一个简单的示例说明我们将要讨论的过程。

一个简单的文件系统

我们将创建一个向 CIMOM 反映文件系统的 MOF 。在我们的示例中即将使用的文件系统过于简单，所以我们称它为“简单的文件系统”。在清单 3 中显示的 SIMPLE_FileSystem MOF 体现了我们的文件系统的实现。

清单 3. SIMPLE_FileSystem MOF

// ==================================================================//   SIMPLE_FileSystem// ==================================================================class SIMPLE_FileSystem : CIM_LogicalElement{        [        Override("Name"),        Description("The inherited Name.  The value must be         overridden to indicate it is now a key value and will be         retrieved dynamically."),        Key        ]     string Name;        [Description("The total amount of space available on a filesystem")]     uint32 TotalSpace;        [Description("The amount of space that is used in a filesystem")]     uint32 UsedSpace;};

 

注意我们的文件系统是从 CIM_LogicalElement 继承而来的。因此，文件系统继承了以下属性：

• InstallDate (datetime) : 对象安装日期
• Name (string) : 资源名，最大长度为 256 个字符
• Status (string) : 值映象限定符列出可能的状态值；这些值包括 "OK"、"DEGRADED" 及其它
• Caption (string) : 短标题，被 MAXLEN 限定符限制在 64 个字符
• Description (string) : 自由格式的字符描述

在清单 3 中还可以看到名称属性的声明。该属性实际上存在于超类中。CIM 赋予子类更改关于它的一个超类中属性的元数据的能力。MOF 语言需要对那些表明在一个超类中撤销属性的限定符进行重定义。注意，子类中名称属性的 Override 和 Key 限定符被添加到元数据中。

类一旦定义，就被装入 CIMOM。将类装入 CIMOM 的机制真正取决于 CIMOM 的执行者以及使用 CIMOM 的工具的存在性。在 SNIA 开放 CIMOM 的实现的情况下，CIM 浏览器用与连接 CIMOM 并把类定义装入到 CIMOM 中。在使用浏览器与 CIMOM 连接后，可以打开定义类的 MOF 文件。浏览器会对 MOF 文件进行语法分析，并使用标准 CIMOM 客户机远程调用来创建 CIMOM 内的类定义。

在接下来的两部分中，您将学到两种把实例数据装入 CIMOM 的模型。在静态数据模型下，数据通过 CIMOM 的客户机 API 压入持久存储器。这种持久存储机制可以变化，它由 CIMOM 执行器提供。一些 CIMOM 使用简单的文件读写持久数据；另一些则使用 JDBC 与数据库数据交互来维持数据。在动态模型下，您可以插入提供者类，在请求数据时可调用它来提供类实例。

 

回页首

 

静态数据模型

静态数据模型是一种简单的将数据（这些数据不能改变对象实例的生命周期）植入 CIMMOM 的方法。静态数据可包含实例描述和实例标题。最好是提供一个完整的静态对象实例，或者提供一个完整的动态对象实例。您可以使用一个实例 MOF 或使用客户机接口为 CIMOM 提供静态数据。在我们的简单文件系统这个实例中，我们将使用 MOF 数据实例。在后台，CIM 浏览器将使用客户机 API 向 CIMOM 植入静态数据。

一个静态示例

清单 4 显示了一个 MOF 实例。注意每个我们想要设置的属性都有一个值与之关联。

清单 4. 创建一个 SIMPLE_FileSystem 实例

instance of SIMPLE_FileSystem{      Name          = "Bogus_FileSystem";      TotalSpace    = 10;      UsedSpace     = 1;      InstallDate   = "20010617083159.000001-360";      Status        = "OK";      Caption       = "A SIMPLE_FileSystem";      Description   = "This is a bogus filesystem instance.";};

 

每一个厂商的 CIMOM 都有它自己保留静态数据的持久机制。持久机制可能如序列化对象那样简单，也可能如把数据写入数据库那样较为复杂。MOF 文件中的限定符使数据库存储变得比传统方法简单得多（传统方法是把 Java 对象压缩后再存入数据库表中）。一些限定符用于提供字符串数据的数据长度和提供值映象。关键字限定符定义索引和唯一的对象实例，同时对于将数据映射入数据库也有用。

 

回页首

 

动态数据模型

实际上，所有希望提供给 CIMOM 的数据都是静态的情况是很罕见的。更多有趣的受管资源并非是静态的。提供者类允许 CIMOM 客户机收集动态数据，并作用于这些数据。我们正在使用的 CIMOM 是 SNIA 的开放源代码 CIMOM，有供它处理的四种提供者类：

• InstanceProvider 提供一张动态的、在 CIMOM 中可用的实例清单。例如，在安装时无法知道在您的计算机系统中 -- 如果有 -- 有多少网卡。实例提供者将直接与计算机系统对话确定网卡的数目，然后在适当的时候，用适当的数据提供给请求一个或多个网卡实例的客户机。
• PropertyProvider 能及时提供关于受管资源的数据，并直接从资源本身调用。如果有动态实例，很可能所有的属性也是动态的，那样数据需通过属性提供者提供给 CIMOM。一个好的动态数据的示例是实例提供者的一张网卡上的数据包吞吐量。
• MethodProvider 对于实现类方法很重要。没有方法提供者是无法实现类方法的。实现通过 MOF 在 CIM 类上定义的方法的操作比较复杂。一个方法提供者的示例是关闭计算机系统或复位网卡上的计数器。
• AssociatorProvider 能够在组件之间动态地建立关联。例如，假定 CIMOM 有关于存储器卷标的数据，但存储器卷标还未成为逻辑卷标的一部分，因此没有关联存在。通过逻辑卷标管理器上的方法或发生在 CIMOM 之外的操作系统级命令，可将存储卷标与逻辑卷标关联在一起。在这点上，提供者将返回逻辑卷标的动态实例和存储器卷标之间的关联。这种提供者类型在连接结合松散的实例上功能非常强大。

一个动态示例

我们的简单文件系统是一个类的完美示例，它使用实例提供者和属性提供者来表现它的数据，所以我们将重点放在这两种提供者类上。要使用提供者，必须修改类的 MOF 定义。类必须指出 CIMOM 应使用哪个提供者类检索数据。例如，如果希望类使用一个实例提供者，您要向类定义上方的元数据添加提供者限定符。要使用属性提供者，您要在个别属性上方的元数据中放置属性限定符。

清单 5 显示了我们将如何修改 MOF 文件使我们的简单文件系统类能够使用实例和属性提供者。当首次定义 "Name" 属性作为我们的关键字时，为支持元数据的修改必须把 Name 的定义放进 MOF 中。为余下的数据添加属性提供者，必须再次放入数据定义。如果不这么做，提供者将无法检索超类属性的动态数据。

清单 5. 修改 SIMPLE_FileSystem MOF 以便与提供者一起使用

// ==================================================================//   SIMPLE_FileSystem// ==================================================================[Provider("com.ibm.wbem.providers.SIMPLE_FileSystemProvider")]class SIMPLE_FileSystem : CIM_LogicalElement{        [        Override("Name"),        Provider("com.ibm.wbem.providers.SIMPLE_FileSystemProvider"),        Key        ]     string Name;        [        Override("InstallDate"),        Provider("com.ibm.wbem.providers.SIMPLE_FileSystemProvider")        ]     datetime InstallDate;        [        Override("Status"),        Provider("com.ibm.wbem.providers.SIMPLE_FileSystemProvider")        ]     string Status;        [        Override("Description"),        Provider("com.ibm.wbem.providers.SIMPLE_FileSystemProvider")        ]     string Description;        [        Override("Caption"),        Provider("com.ibm.wbem.providers.SIMPLE_FileSystemProvider")        ]     string Caption;        [Description("The total amount of space available on a filesystem"),         Provider("com.ibm.wbem.providers.SIMPLE_FileSystemProvider")]     uint32 TotalSpace;        [Description("The amount of space that is used in a filesystem"),         Provider("com.ibm.wbem.providers.SIMPLE_FileSystemProvider")]     uint32 UsedSpace;};

 

您可能注意到我们在实例提供者和属性提供者中使用相同的类。这相当普遍，而且重用公共代码也是很好的。一旦添加了提供者标签，必须将 MOF 重新装入 CIMOM 中以使更改生效。一旦 MOF 重新装入，CIMOM 将在类路径中而不是用它自己的持久机制来寻找动态提供者。

 

回页首

 

提供者接口

CIMOM 使用合适的接口来访问各种类型的提供者中的数据。就如您将要看到的，这些接口代码相对较短。在我们最后的示例中，我们将运行一个同时使用实例和属性接口的提供者。但现在，我们只能分别看到每个接口。

清单 6 显示了实例提供者的接口；清单 7 显示了属性提供者的接口。您会注意到两个接口都用到了 CIMObjectPath ， 对象路径通过它所驻留的名称空间、对象实例的类名和对象实例唯一关键字的键／值对来识别特殊的实例。

以下是 InstanceProvider 接口

清单 6. InstanceProvider 接口

public interface InstanceProvider extends CIMProvider {      public abstract Vector enumInstances(CIMObjectPath cop,                      boolean deep,                      CIMClass cimClass) throws CIMException;      public abstract Vector enumInstances(CIMObjectPath cop,                      boolean deep,                      CIMClass cimClass,                      boolean localOnly) throwsCIMException ;      public abstract CIMInstance getInstance(CIMObjectPath cop,                     CIMClass cimClass,                     boolean localOnly) throwsCIMException;      public abstract CIMObjectPath createInstance(CIMObjectPath cop,          CIMInstance cimInstance) throws CIMException;      public abstract void setInstance(CIMObjectPath cop,          CIMInstance cimInstance) throws CIMException;      public abstract void deleteInstance(CIMObjectPath cop)          throws CIMException;      public abstract Vector execQuery(CIMObjectPath op,          String queryStatement,        int ql,          CIMClass cimClass) throws CIMException;}

 

您可能有一种直觉，感到掌握了您在清单 6 中看到的方法，以下是这些方法的详细介绍：

• enumInstances 提供了一列可供 CIMOM 使用的实例。这种方法有两方面作用：第一是将对象路径的向量返回给实例，第二是将实际实例的向量返回给 CIMOM。方法上的唯一区别是后者在调用时使用第四个参数。第四个参数被要求确定在返回的实例中要提供多少数据。在最后的示例中我们将更深入地讨论这种方法。
• getInstance 检索单个对象实例而不是多个列举的实例。
• createInstance 根据提供的信息创建一个新的对象实例。
• setInstance 允许为单一实例设置数据。
• deleteInstance 除去一个特定实例。
• execQuery 目前不在开放源代码 CIMOM 中使用；但将来可能被用于将查询用于提供者以便处理。

create 和 delete 方法在某些类型的实例中可能会产生异常。例如，CIMOM 不能创建或删除网卡。网卡有可能存在或不存在。

现在看一下 PropertyProvider 接口。

清单 7. PropertyProvider 接口

public interface PropertyProvider extends CIMProvider {      public abstract CIMValue getPropertyValue(CIMObjectPath cop,                      String oclass,                      String pName) throws CIMException;      public abstract void setPropertyValue(CIMObjectPath cop,                      String oclass,                      String pName,                      CIMValue val) throws CIMException;}

 

您会注意到 CIMValue 实例是一个 CIM 数据类型和它所对应值的包装。CIM 数据类型并非总是与可用于 Java 平台的数据类型匹配。为确保数据被正确地解释，您必须将数据包装在其完整的 CIM 描述中。

 

回页首

 

运行提供者

有了对实例和属性接口的基本理解，我们可以为我们的 SIMPLE_FileSystem 运行提供者了。在 清单 8 中的提供者组合了实例和属性接口，把 SIMPLE_FileSystem 实例植入 CIMOM 中。

一个提供者本质上起着与在这一系列第 1 部分讨论的管理面相同的作用，由提供者返回的数据与管理面返回的数据十分相似，但前者有更多的大量代码要去费力地处理，因为附加的 CIM 数据类型需要与类属 CIMOM 层一起工作。总的来说，提供者要比管理面处理更多的大量数据。

我将解释在清单 8 中最重要的方法，但我建议您花点时间浏览一下自己的代码与文档。我在代码中直接留了 java 文档帮助您阅读。在方法接方法的基础上，这儿是一些您绝不能遗漏的东西：

• initialize 在首次装入提供者类时被调用。如果您的提供者需要与资源建立连接，这可能是放代码的最好地方。
• enumInstances(op,deep,cc,localOnly) 是一种方法，用于定位文件系统中所有可用的实例并返回一个实例向量给 CIMOM。注意有一个辅助方法 ( getFileSystemInstance ) 来装配实例并返回它。装配一个 CIMInstance 包括创建一个发送进来的 CIMClass 的实例，然后为新实例设置属性。如我们在原始 MOF 文件中所看到的，用标签，如 InstallDate 和对应的 CIMValue（表明一种 CIM 数据类型）设置属性。
• enumInstances(op,deep,cc) 是第二种列举可用实例的方法。它的功能是列举到每个对象的路径 ( CIMObjectPath )。如果给定对象路径，可以通过调用 getInstance 方法请求 CIMOM 为对象准备更多的数据。
• getInstance 在我们的示例中是一个相当简单的方法，因为我们只表现一个文件系统。但是，在实际的实现中，您将希望使用传送进来的对象路径确定为 CIMOM 返回什么 CIM 实例。
• execQuery 、 setInstance 、 createInstance 和 deleteInstance 没有在这个示例中实现。开放 CIMOM 有一套强大的异常类。这里，异常是指不支持被调用的方法。
• getPropertyValue 返回一个特殊属性值。当选中一个特定的实例进行浏览（通过带有 SNIA CIMOM 的浏览器）时，对列举实例的方法调用之后会有一系列 getPropertyValue 调用。任何定制逻辑都将被放到这个方法或一个辅助方法中被 getPropertyValue 调用。
• setPropertyValue 很有趣，因为它把一个新值传送到 Java 缓存值中，在这种情况下这个值给使用过的空间或是给整个空间。（其他值不支持数据设置）。在 CIM 浏览器的当前版本中，返回的数据类型将永远是字符串值。在实际的实现中，我们的代码必须更强大以确保传送的数据类型与我们的期望相一致（例如 UINT32 ）。

您可能会回忆起在管理面中声明了各种缓存变量。但我们的示例提供者并没有实现持久性。结果是重新启动 CIMOM 将复位数据。一个真实的文件系统提供者会整合文件系统本身的一种持久类型。数据将被直接从操作系统检索，所以重新启动 CIMOM 将不会引起问题。

另外，我们为这个示例声明标题，描述和实例名。在实际的提供者中有更好的方法来实现这一点。例如，您可以使用资源绑定或另外一些持久存储的方法。目前，WBEM 不为本地化提供太多支持。

管理层和提供者之间的主要区别在于对类属对象的使用上，这些类属对象用于从 CIMOM 传输数据或传输数据到 CIMOM。这种额外的代码层 好象引起了很大的变化。现实中也是大相径庭。典型资源的管理层是很复杂的，因此额外的代码与我们简单示例中的代码相比只占一小部分。将来 WBEM 的实现将很可能包括可生成构建提供者所必需东西的工具，允许程序员将精力集中于编写定制代码来与特定的受管资源交互。

 

回页首

 

总结

WBEM 提供了一个标准化的建模环境 (CIM)、一个对象库 (CIMOM)，和对 CIMOM (MOF) 进行标准化客户机访问的定义。WBEM 的能力体现在由 DMTF 成员维护的严格的类标准化过程方面。

在这篇文章中，我们快速浏览了由 CIM 和 MOF 实现的建模和类定义过程。我们定义了一个简单的文件系统类并练习用静态和动态机制把文件系统的实例植入 CIMOM。最后，我们用一个简单的既实现静态机制又实现动态机制的提供者把所有这些都组合在一起。

动态提供者与使用 Jiro 技术部署的管理面有不少重要的重叠。然而由于提供者锁存了一个标准化的数据库，这个数据库与标准客户机 API 一起实现数据访问，所以提供者较管理面有优势。当管理应用程序变得更为复杂时，WBEM 简化了客户端的编程，这种简化是通过从客户机精简硬件和软件的管理过程来实现的。客户机程序员和驱动器级程序员在很大程度上受益于标准化和模型设计的重用。

在这一系列的最后一部分，我将向您展示怎样把 Jiro 技术和 WBEM 组合成一个单一的、基于开放标准的管理应用程序开发平台。如在前面几部分中所述，我们将使用简单的、现成的示例进行练习。我们还要讨论一些关于未来管理应用程序开发方面的问题。所以请继续关注。

参考资料

• 请从 SNIA 下载 开放源代码 CIMOM。
  
  
• 请下载与本文一起提供的完整 源代码
  
• 您将在 DMTF 主页上找到 WBEM 的概述、CIM 规范、最新的 CIM 模型（写这篇文章时是 2.5 版）和更多其它信息。
  
  
• 基于 Web 的管理网页是另一个关于基于 Web 的管理技术信息的巨大资源，包括 WBEM 的所有主要的实现。
  
  
• 要了解更多有关 CIM 建模的信息，请参见 公共信息模型：实现企业管理的对象模型 (John Wiley & Sons, 2000)。注意这本书并没有提供 CIM 怎样适合整个 WBEM 实现的信息。
  
  
• 这一系列的第一篇文章，“ 开始接触 FMA 和 Jiro”（developerWorks，2001 年 5 月）向初学者介绍了联邦管理架构和 Jiro 技术。
  
  
• 探究 RMI 激活框架是怎样产生 自给自足的、灵活的 Jini 服务（developerWorks，2000 年 10 月）。
  
  
• Tivoli Storage Management Solutions for the Information Grid，第一部分：应用管理 (PDF) 讨论了 Tivoli 计划的关于管理应用程序的现在和将来的方向。
  
  
• 看看 IBM 在 存储与存储管理方面做了什么。
  
  
• 在 developerWorks Java 技术专区上可以找到更多的 Java 参考资料。