中译本的Transactional COM+:Building Scalable Applications(Addison-Wesley,2001 年)相当之烂,COM+的内容本来就不是很容易懂,翻译者更是基本用金山之类的东西交差,如publisher居然直接就翻译成了出版商!总之读的人懵。懵完之后我最纳闷的是关于context的概念以及与之想对应套间等概念,尤其是涉及到用.Net写COM+服务的时候,CLR里头不是有这些个东西了吗,为什么还要SCM来监听管理?回头查查资料才发现这两者真不是一件事情。于是就想COM+服务被调用的时候SCM还要分配套间,对象池和维护分布式事务,这些其实CLR都内部包括了,但是CLR却不是全局注册的,要想使用COM+服务还得再把.net事务类转化成COM才行! 个人认为这个是过渡时期的做法
毕竟肯定都得在托管效率才高啊。
COM+ 集成:.NET 企业服务如何帮助您构建分布式应用程序
Tim Ewald
摘录。。。。
在我深入研究这些问题之前,您需要了解两个有关 CLR 类与 COM+ 上下文之间关系的细节问题。首先,对派生自 ServicedComponent 的类实例的调用将在 COM+ 上下文边界被侦听。这些对象被称为上下文绑定。对非派生自 ServicedComponent 的类实例的调用将不在 COM+ 上下文边界被侦听。这些对象被称为上下文灵活 (context-agile)。CLR 对象默认情况下总是上下文灵活的。它们只有从 ServicedComponent 派生时才是上下文绑定的。(这仍然与 .NET 远程处理上下文无关,我等一下将对此进行讨论。)
摘录。。。。
ServicedComponent 类派生自 System.ContextBoundObject,而后者又派生自 System.MarshalByRefObject,System.MarshalByRefObject 是使得对象可以通过 .NET 远程处理基础结构访问的基类。在新的远程处理层上直接建立 CLR/COM+ 集成基础结构有两个好处。首先,现在您能够使用远程处理层内置的对 SOAP 的支持,访问使用 COM+ 运行时服务的远程对象。但是,您无法使用 SOAP 从一个进程向另一个进程中传播声明性事务(这也许并不是您希望的,但事情的原理就是这样)。其次,它为 COM+ 运行时服务完全根据 CLR 远程处理层崭新的上下文基础结构实现新版本提供了一种途径,而这是目前的 COM+ 无法使用的。这在将来的某个时候是会实现的。当实现了这一步时,服务将与 SOAP 或者任何其他的传送机制无缝集成,上下文结构将是完全可扩展的。到那时,CLR 将使得 COM+ 编程的许多细节变得更简单,这总可算得上是朝着正确方向迈出了一步。