(
来源：http://www.microsoft.com/china/technet/iis/compl.asp)
作者：Richard Ersek、Ken Jones
Microsoft Corporation
当我们在 Microsoft 1998 年专业开发人员讨论会中介绍 COM+ 的早期测试版时，某天晚上，一个心情烦躁的程序员向我们发出诘问。“Microsoft 到底要干什么？”他说，“想让我们都失业吗？”对于一个为期四天、排满了专门针对与会的 6000 多名开发人员的议题的讨论会来说，这个问题似乎太奇怪了。尽管如此，我们毕竟有些好奇：“您为什么这样说？”“哼，”他接着说，“看看新的 COM+ 用户接口吧。系统管理员几乎能利用它做任何事情。他们再也用不着‘我们’了。”
我们对这位先生保证，他不会丢掉自己的工作。实际上，作为一名 Windows DNA 开发人员，他可能会比以往更有价值。而且，在文章的一开始，我们也愿意向各位系统管理员做出同样的保证。乍一看，新的 COM+ 用户接口（或者用更正式的说法，是组件服务管理工具）似乎无坚不摧：可以用它来执行的操作太多了，包括设置下至组件级的属性，甚至不止如此，它还可用来设置组件接口和方法级的属性。
但当您考虑到组件服务管理工具的双重功能性时，就会发现它不但不那么可怕，而且功能还非常丰富呢。它为系统管理员和应用程序开发人员设计了合二为一的用户接口。在本文中，我们将向您介绍该工具的管理功能，并简要介绍它如何使系统管理员的工作变得更容易。因为本文仅是概述性的，所以我们只概念性地解释这些任务，而未提供具体过程。（有关过程及进一步信息，请参见“组件服务管理帮助”。）
如果您的浏览器不支持内嵌框，请单击此处在单独的页面上查看。
我们首先介绍 MTS 与 COM+ 之间的几个主要更改。然后，我们将讨论组件服务管理工具如何用于三种最常见的系统管理任务：
- 部署应用程序
- 设置基于角色的安全措施和应用程序的安全标识
- 管理对象池，以获得最佳系统性能
许多 IIS 用户对 Microsoft Transaction Server (MTS) 及其用户接口 - MTS Explorer 已经很熟悉。可将 COM+ 视为传统 COM 与 Windows 2000 系统中的 MTS 相结合的一组服务。随着 COM+ 的引入，MTS 的功能也已并入操作系统。如您所将要看到的，COM+ 还可发展和增强 MTS 提供的服务。
如果您一直用的是 MTS 和 MTS Explorer，当您启动组件服务管理工具时，将会注意到几个主要变化。最明显的是，MTS 软件包现在称为 COM+ 应用程序。
“COM
应用程序”并非一个全新概念。它只是个术语，指为了协同工作而开发的多组 COM 组件。在传统的 COM 应用程序中，要安装组件，必须先在注册表中配置各项，这样组件才能够运行。通常用 Regsvr32 实用程序完成这项工作。使用 COM+，当您将组件配置为 COM+ 应用程序时，针对组件的此步骤将自动执行。COM 组件仍可使用 Regsvr32 实用程序在 Windows 2000 中注册，并作为“未配置组件”存在于 COM+ 环境中。未配置组件不会显示在组件服务管理工具中，也不会利用新的 COM+ 服务。但这些组件运行时，会利用 COM+ 供运行分布式 COM+ 应用程序的基本结构的一部分。
COM+
应用程序由一个或多个 COM 组件组成。“COM 类”是一个或多个接口的已命名的具体实现。类通过它的“接口”，提供一组称为“方法”的相关功能。“COM 对象”是 COM 类的一个实例。“COM 组件”是可创建 COM 对象的二进制单位代码（包括打包和注册代码）。
COM
类是用 CLSID 标识的（有时也用 ProgID）。接口是规定了一种契约的一组相关功能，它包括名称、接口签名、接口语义及调度缓冲格式。
接口用 IID 标识。接口语法是在 IDL 和/或类型库中定义的。类的接口应划分为各种可管理的、内聚的方法集。切记，接口是不可改变的，COM 契约规定不可对其加以修改。任何修改（如添加方法）均需定义新接口才能进行。
应用程序编程人员使用 COM+ 编写各种组件，并将其集成在一起，成为应用程序；而系统管理员的任务通常是安装、部署和配置 COM+ 应用程序及其组件。一般情况下，开发人员会将已进行部分配置的 COM+ 应用程序提供给系统管理员。或者，应用程序也可由外部提供。例如，当您从独立软件供应商 (ISV) 处购买 COM+ 应用程序时，即属于这种情况。然后，管理员就可以针对一个或多个特殊环境自定义应用程序（例如，通过在应用程序群集的角色和服务器名称中添加用户帐户）。典型的管理任务包括：
- 在执行管理任务的机器上安装已进行部分配置的 COM+ 应用程序。
- 提供具体环境的属性，例如角色成员和对象池大小。
- 设置 COM+ 应用程序运行的身份（Windows 2000 用户帐户）。
- 重新导出已完全配置好的 COM+ 应用程序。
- 创建应用程序代理（如果将远程访问应用程序的话）。
针对具体环境完全配置好应用程序后，管理员即可将其部署在测试和/或产品机器上。这包括将完整的、已配置的 COM+ 应用程序安装在一台或多台机器中。
组件服务管理工具使用工具中的 Application Export 向导，从而使跨多个服务器部署 COM+ 应用程序变得更容易。您可以使用组件服务管理工具，创建 COM+ 应用程序和应用程序代理的安装软件包。COM+ 可生成与 Windows Installer 兼容的安装软件包，该软件包在一个文件中包含了所有将 COM+ 应用程序安装到另一台机器上所必需的软件。
包含 COM+ 应用程序的 .msi 文件只可安装在支持 COM+ 1.0 服务（目前仅有 Windows 2000 支持）的计算机中。一个额外的好处是，除非用 Windows Installer 创作工具修改了 .msi 文件，否则用 Windows Installer 安装的 COM+ 应用程序就会出现在“添加/删除程序”控制面板中。
组件服务管理工具生成的 .msi 文件包含：
- 带有 COM+ 注册信息的 Windows Installer 表。
- 一个包含应用程序属性的 .apl 文件。
- DLL 和类型库，描述由 COM+ 应用程序类实现的接口。
除 .msi 文件外，组件服务管理工具还会产生一个压缩包 (.cab) 文件。实际上该文件会将 .msi 文件包起来，这样，即可通过 Internet Explorer 部署 COM+ 应用程序。
为了能够从另外的（客户）计算机远程访问 COM+ 服务器应用程序，客户计算机必须装有服务器应用程序属性的子集，包括用于 DCOM 远程接口的代理/存根 DLL 及类型库。该子集的术语是“应用程序代理”。
您可利用组件服务管理工具，轻而易举地导出 COM+ 服务器应用程序，使其成为应用程序代理。COM+ 生成的应用程序代理是标准的 Windows Installer 安装软件包。安装后，应用程序代理会出现在客户计算机的“添加/删除程序”控制面板中。
在生成应用程序代理时，COM+ 会自动提供以下信息。这些信息是应用程序代理远程访问 COM+ 服务器应用程序时必需的。
- 类标识信息（CLSID 和 ProgID） - 一个应用程序代理最多可支持两个 ProgID。
- 应用程序标识及类与应用程序的关系 (AppID)。
- 每个应用程序的位置信息（远程服务器名称）。
- 应用程序的所有接口的调度信息（例如，类别库和代理/存根）。
- MSMQ 队列名称与标识（如果应用程序中启用了排队组件服务）。
- 类、接口和方法属性，不包括角色信息。
- 应用程序属性。
与 COM+ 服务器应用程序不同，应用程序代理可安装在任何支持 DCOM 和 Windows Installer 的操作系统中。其它 Windows 平台上的客户机也可访问在 Windows 2000 服务器上运行的 COM+ 应用程序。在不是运行 Windows 2000（因而也就没有 COM+）的计算机上，将只安装 DCOM 远程访问所需的信息子集。这些信息将安装在 Windows 注册表中。在不是运行 Windows 2000 的计算机上安装应用程序代理（.msi 文件）时，有必要使 Windows Installer 在这些机器上运行。Windows Installer 作为 Platform SDK 的一部分，以可重新分布的格式出现。
安全角色可模拟并实施 COM+ 应用程序的访问控制规则。角色是指为了确定对应用程序资源的访问权限，而为应用程序定义的用户类别。开发人员将角色（符号式用户类别）分配给应用程序，也就潜在地将其分配给了应用程序内的精细结构 - 包括组件、接口、方法或专用应用程序资源。然后，这些角色分配即用于确定哪些用户类别拥有访问应用程序内的哪些元素的权限。
如果应用程序使用基于角色的安全措施，那么每次调用应用程序时，均会检查调用者的角色成员身份。如果调用者不属于对该项目拥有访问权限的角色，调用将会失败。调用者对应用程序或其资源的访问权限，是严格按照调用者所属角色中定义的限制条件授予他们的。
系统管理员的工作是将 Windows 2000 用户帐户和组填充到为应用程序定义的角色中。在执行应用程序的安全规则过程中，这是个至关重要的阶段。给用户分配的角色必须正确代表用户可能会通过应用程序访问的数据和资源与用户之间的关系。
将用户填入角色的最好方法是使用 Windows 2000 组。首先，将用户帐户分配给适当的组，然后确保将该组分配给适当的角色。用 Windows 2000 组填充角色，使您更易于管理大量用户。
在企业计算环境中，常常很难有效跟踪每个用户在组织内的职位，也很难确定如何将用户的职位映射到每个应用程序所特有的基于角色的安全规则。随着用户、管理员和应用程序数量的增加，这项任务也变得越来越复杂。最易于扩展的解决方案是将用户组分配给 COM+ 应用程序角色。
只有在您理解应用程序安全规则后，才可以将组分配给角色。理想情况下，角色的名称应能表明哪些人应属于该角色，例如“Managers”和“Tellers”。此外，每个角色均包含一些描述，您可使用组件服务管理工具访问这些描述。描述中会介绍哪种类型的用户应属于该角色。但是，如果您无法确定哪些用户组属于哪个角色，请参考应用程序的附带文档，或请开发人员澄清。
您可以使用组件服务管理工具，在应用程序安装期间初步分配角色，也可以在应用程序使用期间，对角色成员身份进行任何必要的更改。
对象池
对象池是一种由 COM+ 提供的自动服务，您可用它配置组件，使组件的实例在对象池中保持活动状态，准备好供任何请求该组件的客户机使用。可以对给定组件所维护的对象池进行管理性的配置和监视，并为其指定一些特性，如池的大小和创建请求超时值。一旦应用程序开始运行，COM+ 将管理对象池，根据您指定的标准，处理对象激活和重新使用的细节。
以这种方式重新使用对象，可在性能和扩展性方面显著获益，尤其是将这些对象编写成能够充分利用重新使用时。通过对象池，您可以对池进行管理性配置，使之能够最大限度地利用可用硬件资源。池的配置会随着可用硬件资源的改变而改变。您还可以通过管理性的池管理，控制资源使用。
当您配置组件使之进入对象池时，COM+ 将会维护该组件在对象池中的实例，准备好当任何客户端请求该组件时，立即激活它。所有对象创建请求都会通过池管理器处理。
当应用程序启动时，只要成功创建了对象，对象池就会一直被填充，直到达到您管理性地指定的最低级别。客户机对组件的请求进入后，会以先入先处理为基础而满足。如果对象池中没有可用对象，而且对象池尚未达到其指定的最高级别，就会为该客户机创建并激活一个新对象。
当对象池达到其最高级别时，客户机请求就开始排队。每个请求均会接收来自对象池的第一个可用对象。对象的数量（包括已激活的和未激活的）永远都不会超过对象池的最大值。在一段管理性指定的时间过后，对象创建请求将超时，这样您就能控制客户机等候对象创建的时间。只要可能，在客户机释放一个对象后，COM+ 就会试着重新使用它，直到对象池达到其最高级别。
您可以用对象池的最大容量来精确控制资源使用。例如，如果您有权使用一定数量的数据库连接，您就可以随时控制已打开的连接的数量。
如果您能够考虑到客户使用模式、对象使用特征以及物理资源（如内存与连接），就有可能在调整性能时找到某种最佳平衡。池对象的产出量在达到某一点后，会逐渐衰减。您可确定自己需要哪一级别的性能，并将其与要达到此性能所需的资源相平衡。有了对象池，您就能控制资源的使用。
我们希望本文能帮助您较好地了解新组件服务管理工具的概况。我们还希望您能由此了解到，该工具的设计如何使您更易于管理跨远程计算机的 COM+ 应用程序。我们期待您能为我们提出一些问题、意见和想法，以便我们用于以后的文章。
如果有的读者需要有关 COM+ 的更详细信息，我们可向您提供很多资源。特向您推荐以下书目。虽然这些书目主要面向开发人员，但也能够为系统管理员提供有价值的信息。
1070
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
