2 引言
• DCOM 和 CORBA都过于复杂。要熟悉DCOM或CORBA，并进行相应的
设计和编程，是一项需要许多个月来掌握的艰难任务 （而要达到专家
水平，需要好几年）
• 在其各自的历史中，性能问题一直在折磨这两种平台。DCOM 只有一种
实现可用，所以不可能购买性能更好的实现。而尽管有多家供应商提供
CORBA 产品，很难找到遵从标准、性能良好的实现——其主要原因是
CORBA 规范自身所带来的复杂性 （在许多情况下，其特性都丰富得超
出了需要）
• 在异种环境中，让 DCOM 和 CORBA 共存从来都不是一件容易的事情：
尽管有供应商提供互操作产品，这两种平台之间的互操作从来都不是无
缝的，而且难以管理，会产生互不相连的技术孤岛。
2002 年， Microsoft .NET 平台 [11] 取代了 DCOM。但尽管 .NET 提供了
比 DCOM 更强大的分布式计算支持，它仍然是 Microsoft 的独家解决方案，
因而不是异种环境下的选择。另一方面， CORBA 近年来已停滞不前，许多
供应商离开了市场，给消费者留下了不再受到广泛支持的平台；剩下的少
数供应商在进一步标准化方面的兴趣也已衰退，致使 CORBA 规范中的许
多缺陷未能得到解决，或是在它们被报告多年之后才得到解决。
在 DCOM 和 CORBA 衰败的同时，分布式计算社群对 SOAP[23] 和 web
services[24] 产生了浓厚的兴趣。使用无处不在的 WWW 基础设施和 HTTP
来开发中间件平台的想法十分迷人——至少在理论上。 SOAP 和 web
services 曾经允诺要成为 Internet 上的分布式计算通用语言。 但尽管引发了
很大的公众效应，发表了许多论文， web services 却没有能兑现其允诺：在
本书撰写的同时，用 web services 架构开发的商业系统非常少。其原因是：
• 无论是在网络带宽方面，还是在 CPU 开销方面，SOAP 都会给应用造成
严重的性能恶化，以致于该技术无法适用于许多有苛刻性能要求的系
统。
• 尽管 SOAP 提供了 "on-the-wire" 规范，要开发现实的应用，那仍是不够
的，因为该规范提供的抽象层次太低。应用可以把各种 SOAP 消息拼凑
在一起，但这样做极其繁琐而易错。
• 缺乏更高级的抽象促使供应商提供各种应用开发平台，使遵从 SOAP 的
应用开发自动化。但是，除了协议一级，这些开发平台完全没有标准
化，不可避免是私有的，所以用一家供应商开发的应用无法与其他供应
商的中间件产品一起使用。
• 关于 SOAP 和 web services 的架构安全性，有一些严重的担忧 [15] 。特别
地，许多专家都表示，他们对该平台缺乏内在的安全性感到担忧。
我的内容管理
展开
