.NET会取代COM吗？

－－准备Web服务的未来

Roger Sessions

首席执行官，ObjectWatch

2000 年 12 月

Roger Sessions 概述了 Microsoft 从 COM 到 .NET 的组件体系结构演变，并预言：Web 服务的引入将使 Microsoft .NET 应用与其它大多数受组件影响的技术（特别是 EJB 技术）互操作。

Gartner Group 最近出了一份名为“CIO 警报：Microsoft COM 不再是战略性选择！”的报告。必须说明，我发现这个标题很滑稽。COM 不再是战略性选择。竟然还是 CIO 警报。真的吗。

我觉得这种说法非常滑稽的原因在于：依我看来，COM 从 1996 年起就不再是战略性选择了。那时 Microsoft 首先发行了 MTS 并取代了 COM 编程模型。看起来您又得起个大早来回想 Gartner Group。就象 1996 年初那样。（CIO 警报：MTS 于四年前推出。）

COM 历史

COM（Microsoft 的组件模型）很大程度上基于 OMG 的 CORBA（公共对象请求代理体系结构），CORBA 可追溯到 90 年代初，但现在早已落伍。与 CORBA 类似，COM 是简单的面向组件打包和分发技术，基本上是加入了多态性的远程过程调用。

同样与 CORBA 类似的是，COM 是伪客户机／服务器体系结构，并具有该体系结构的所有可伸缩性限制。（CIO 警报：客户机／服务器体系结构不可伸缩）。客户机／服务器体系结构将商业逻辑与客户机过程捆绑在一起。客户机／服务器体系结构的问题在于：客户机与系统资源的关系是一对一关系，其中最出名（但不是唯一）的是数据库连接。伪客户机／服务器体系结构将商业逻辑从客户机过程移出（如 COM/DCOM 和 CORBA），但不提供一对一关系。COM/DCOM 和 CORBA 是伪客户机／服务器体系结构，就这点而论，其通过可用系统资源来支持大量客户机的能力受到一定限制（典型的例子还是数据库连接）。

COM 和其兄弟 DCOM 被设计成用来支持快速分发的方法传输，这种方法传输对富客户机系统很重要，但对如今基于 Web 的商业系统所采用的瘦客户机系统则根本不重要。（CIO 警报：瘦客户机已取代了富客户机。）

与 CORBA 目标类似，COM/DCOM 目标与 COM+ 目标完全不同。COM/DCOM 被优化成支持快速方法传输，而 COM+ 则被优化成支持高事务吞吐量。毕竟，在电子贸易系统中赢利的途径是增加事务吞吐量，而不是减少最初曾被忽略的客户机响应次数。因此，COM/DCOM 基于客户机／服务器模型，而 COM+ 则基于三层编程模型。（CIO 警报：Web 取代了客户机服务器体系结构）。这使 COM+ 更类似于事务处理监视器（如 BEA 的 Tuxedo 或 IBM 的 CICS），而不是组件模型（如 Microsoft 的 COM）。

.NET 仅仅是具有几个新特性的 COM+ 吗？

如果我们在谈论 .NET 要实现的应用类型，即高可伸缩性、支持 Web、数据库集中型商业逻辑，那么我已经指出，COM/DCOM 早在 1996 年就被 MTS 所取代。四年来我一直在告诉人们在没有 MTS 支持的情况下不要对这样的应用使用 COM/DCOM。

既然 COM+ 只是 MTS 的下一发行版，那么对于 Mircosoft 来说，COM+ 几乎不是新技术。

那么 .NET 呢？

就象 COM+ 是 MTS 的下一发行版一样，.NET 实质上也是 COM+ 的下一发行版。COM/DCOM 为我们带来组件。MTS 则为我们带来使这些组件高度可伸缩的中间层体系结构。COM+ 向该体系结构添加几个新的如异步方法之类的装饰功能。现在，.NET 使我们能够从因特网访问这些高度可伸缩的中间层组件。

Microsoft 把可从因特网访问的中间层组件称为 Web 服务。Web 服务只是使用 HTTP 作为其传输协议以及使用 XML 作为其打包技术的 COM+。严格说来，这不是个有重大影响的构想，但它确实使商业逻辑可以从因特网访问，并且如果有电子聚会场所形式的额外支持，还允许某些非常有趣的商家对商家协作。

这些电子聚会场所是 IBM 和 Microsoft 领导的集中行业协作主题。这些协作的大多数都围绕称为 UDDI.org 的新行业联盟进行。

明天如何编码？

如果至少在以后两年内不会出现 .NET 平台的最终版本，那么小公司怎样做才能继续构建不会在刚完成时就被取代的应用呢？正在出现许多改变：新语言、新 ASP+ 开发模型、传递客户机经验的新方法，以及可能是最重要的，Web 服务的新概念，因特网协作的基础。那么，重要问题是：如何在今天创建明天还可以被用作 Web 服务的商业逻辑？

这不如想象的那样困难。首先，Microsoft 将继续支持 COM、DCOM 或 COM+，因此在最坏的情况下，可以通过旧有互操作层运行现有代码。但是，当然没有人想通过旧有互操作层来运行其应用。这确实不是很好。

如果要编写可以方便迁移到 .NET 平台的代码，最好的方法是将商业逻辑打包成 COM+/Visual Basic 组件。COM+/Visual Basic 编程模型与 .NET 编程模型十分类似，而且为 COM+/Visual Basic 彻底编写的代码可以方便地移到 .NET。

这里的要点在于代码必须为 COM+/Visual Basic 模型彻底地编写。大多数现有 COM+/Visual Basic 代码没有彻底地编写。大多数这些代码的最大问题是忽略关键的以中间层为中心的编程方针。最常见的违规是：

隐式编码了事务性边界。

在组件内部维护状态。

将安全性委托给数据库。

如果遵循以中间层为中心的设计规则，将为 .NET 作好准备。但是即使努力遵循了所有这些规则，还是不能毫不费力地将组件移至 .NET 世界。这不是因为组件模型的变更，而是很大程度上因为 Visual Basic 即将发生的变更。

Visual Basic 语法有时看起来有些随意，但正要经历一场老早以前就该发生的最终变动。好消息是 Visual Basic 最终将成为更强壮的语言。坏消息是老版本的 Visual Basic 程序语法将不与 VisualStudio.NET 中的 Visual Basic 语法兼容。迁移将不那么困难，并可以通过迁移工具来简化，但可能没有仅仅复制文件和重新编译那样简单。如果不想作这些更改，可以始终在 Visual Studio 6 中开发，但是这会极大降低您的“酷”(cool) 感。

"酷"是 Microsoft.NET 中的操作词语。如果 Microsoft 在以后几年真正支持所有这些技术，那就更酷了。如果整个行业都在 Web 服务上达成一致（很可能的景象），从而使 Microsoft 的 .NET 应用可以与大多数其它受组件影响的技术（特别使 EJB）互操作，那也会更酷。Web 服务的要点在于它们容忍广泛的组件模型，只在传送和方法打包的最小级别上强制一致。

如果 Microsoft 确实实现其 .NET 承诺，我们将看到因特网的平台主要由 Microsoft 定义。如果 Microsoft 在该问题上犯错误，那我们将看到 Microsoft 的作用将越来越小。这种前景的第一个迹象是 Common Language Runtime、VisualStudio.NET、COM+ 和 SOAP。第一个迹象给人以深刻印象。现在我们必须静观和等待。看 Microsoft 朝哪个方向发展。

参考资料

• 本文中的的很多资料最初都在 Roger Sessions 的 ObjectWatch 时事通讯中：
  
  
  • ObjectWatch 时事通讯第 30 篇（2000 年 10 月 20 日）"CIO Alert: ObjectWatch responds to Gartner!"。
    
  • ObjectWatch 时事通讯第 29 篇（2000 年 6 月）"Letter from the PDC 2000: The Unveiling of Microsoft.NET"。
    
  • ObjectWatch 时事通讯第 25 篇（2000 年 3 月 6 日）"SOAP"。
    
• COM+ and the Battle for the Middle Tier，Roger Sessions 著，Wiley Computer Publishing 于 2000 年出版。
  
• "CIO Alert: Microsoft COM is No Longer a Strategic Choice,"，Edward Younker 著，GartnerGroup 报告 IGG-09062000-01，2000 年 9 月 6 日。（访问该报告需付费注册。）
  
• Roger Sessions 还讲授一日研讨会和上机讲习班。

关于作者

Roger Sessions 世界上中间层体系结构的主要专家之一。他有 Microsoft COM+、OMG CORBA 和 Sun EJB 的丰富经历。他著有五本书籍和许多文章，并曾在无数会议上作演讲。他编写并出版的关于分布式组件技术的 ObjectWatch 时事通讯被广泛阅读和高度认可。他最新的书籍是 COM+ and the Battle for the Middle Tier。可通过 roger@objectwatch.com 与 Roger 联系。