COM+ 集成 :.NET Enterprise Services  如何帮你建立分布式应用 作者： Tim Ewald  翻译： Frank Xu Lei 本文假定你熟悉  COM  和 C++ 难度       1   2   3  本文代码下载 : ComPlus.exe (41KB) 查看本文代码在  Code Center:  摘要  .NET  公共语言运行时  (CLR)  是微软下一代的组件技术。  CLR 是 COM 技术的取代者，  但是对于  COM+ 。  COM+  现在称作 .NET Enterprise Services ，是微软为可升级的系统开发工作指定的运行时环境。        本文阐述了如何使用 CLR 实现和部署 COM+  定制的类，如何访问对象上下文环境和调用上下文环境，  和管理环境相关的对象引用的规则。另外讨论了如何管理如数据库链接、池中的对象， COM+  和  新的 .NET Remoting 架构之间的关系。 2000 年 7 月 1 日 ，  微软正式宣布  Microsoft®  。 NET 成为  网络为中心的新一代开发平台。 .NET 的核心就是公共语言运行时  (CLR) ，  新一代组件技术继承自 ( 且向前兼容 ) COM 。  公共语言运行时在很多方面改进了 COM ，  最重要的就是使用元数据描述组件实现和其他组件依赖的所有类型。所有的类型信息都可以通过反射获得和属性扩展。  这样就可以轻而易举创建任何开发者梦寐以求的复杂的组件，  如自动支持对象的序列化。       CLR 公共语言运行时是 COM 的取代者，  但是却不是  COM+ 的取代者。  COM+ 是为对象提供一组可以方便建立分布式系统的服务的运行时环境。  当你使用 COM 时如果你发现 COM+ 有用，那么当你使用公共语言运行时的时候你同样会看到 COM+ 非常有用。  本文是关于如何使用 CLR 进行 COM+ 编程的。我们先快速回顾一下 COM+ ，  然后就是 .NET Enterprise Services 。 快速回顾 COM+       所有的 COM+ 服务都是在上下文环境里实现的。  上下文环境是一个提供运行时服务或者对象驻留场所的进程类的空间  。当一个上下文环境里的对象 ( 或线程 )  调用另外一个上下文环境里的对象，  方法就会被截取，  如图 1 所示。  代理给 COM+  运行时预处理或迟处理请求以及执行满足对象需求的服务代码的机会，  例如调用序列化，  声明事物管理等。 图1 上下文环境和侦听       COM+提供了为需要运行时服务的类所需要的运行时服务。 如果一个类需要服务，COM+会确保实例驻留在能够提供服务的上下文环境里。例如，如果一个类使用了声明的事务，COM+确保每个实例驻留在为对象提供使用的分布式事务的上下文环境里。类是通过声明属性使用COM+运行时服务。每个服务声明用来控制自身行为的属性。       使用COM+运行时服务和标志了声明的属性的类称为配置类。没有使用COM+服务的类或者没标志任何声明的属性的类，称做非配置的类。 COM+在一个称做目录的元数据库存储配置类声明的属性值。 这个目录被分割在控制配置类的实例映射到进程的应用中。有两种应用程序， 库和服务应用程序。 每个配置类属于单个应用。如果一个配置类在库应用程序中， 这种类型的对象通常在客户端创建。如果配置 类在服务应用中，这个类型的对象通常在专有的代理进程dllhost.exe里创建。       当一个配置类被初始化， 对象的创建者必须确保新对象消亡在提供运行时服务的上下文环境里。 当一个新对象对象被创建， 对象的创建者会检查它的服务需求， 比如在类的存储在COM+ 目录里属性值。 如果对象的需求可以被创建者的上下文环境满足， 新对象就驻留在那里，调用不会被侦听。如果新对象的创建者上下文环境不能满足它需求， 新的上下文环境将创建来提供对象所需要的运行时服务。新对象 驻留在新上下文环境里，所有的调用都会被侦听以便确保对象对象访问了它所需要的服务。当配置类被初始化，对象创建者通常将新对象放在创建者的上下文环境。 图 2 对象上下文环境 和 调用上下文环境对象       一个特定上下文环境里的对象也许想要与提供给它上下文环境的运行时服务交互。COM+ 为每个上下文环境建模为一个COM 对象，称作一个对象上下文环境对象 (简称对象上下文环境)。它同样为每个执行的逻辑线程(因果关系)建模为COM 对象，称作一个调用上下文环境 对象 (简称上下文环境)。任何上下文环境里执行的代码能够通过CoGetObjectContext 和 CoGetCallContext获得对象的引用，。(等价与Visual Basic 6.0里的 GetObjectContext and GetSecurityCallContext)。图2说明了这个架构。 用 CLR 实现  COM+  服务类        和 COM 一样， CLR 依赖与 COM+ 提供方便开发者建立可伸缩的应用系统的运行时服务。使用 CLR  实现 COM+  服务类相当容易，某些时候，  比用 COM 实现更加高效。要知道单独通过 COM 的互操作难以实现两种技术的集成。因为当你使用 CLR  实现使用 COM+ 的 COM  组件， CLR  和 COM+ 的集成度已经很深，  产生了一个更好的与其他的 CLR 技术如 Remoting 和代码访问安全集成的编程模型。  CLR 访问 COM+ 的 API 有命名空间 System.EnterpriseServices 类定义。 CLR  依赖  COM+ 的类使用这些类来设置属性和与对象交互以及调用上下文环境。       System.EnterpriseService  里最重要的类是 ServicedComponent 。  所有使用 COM+ 运行时服务的 CLR 类  必须扩展 ServicedComponent ，  如下所示： using System.EnterpriseServices;   namespace ESExample {  public class MyCfgClass : ServicedComponent  {     public MyCfgClass() {}     …  } }       ServicedComponent  出现在被继承的位置就是告诉  公共语言运行时的对象创建者类已经被设置，这个类可能需要使用 COM+ 上下文环境。  继承自 ServicedComponent 的类必须是公开和实际的，  必须提供缺省的公共的构造函数。

实现接口 IObjectConstruct 和 IObjectControl

namespace ESExample

{

 [ ObjectPooling(true， 5， 20) ]

 public class MyPooledCfgClass : ServicedComponent

 {

    public MyPooledCfgClass() {}

    // override CanBePooled so that instances can be

    // reused， use default implementations of Activate

    // and Deactivate provided by ServicedComponent

    public override bool CanBePooled() { return true; }

 }

}

ContextUtil 和 SecurityCallContext

编译组件服务类

using System.EnterpriseServices;

using System.Reflection;

[assembly: ApplicationName("MyApp")]

[assembly: ApplicationActivation(ActivationOption。Library)]

// AssemblyKeyFile attribute references keyfile generated

// by sn.exe - assembly will have strong name

[assembly: AssemblyKeyFile("keyfile")]

namespace ESExample

{

•••

}

sn -k keyfile

csc /out:ESExample.dll /t:library

    /r:System.EnterpriseServices.dll MyCfgClass.cs

 部署组件服务类