Web服务设计师，第3部分：Web服务是CORBA的翻版吗？

Dan Gisolfi (gisolfi@us.ibm.com)

解决方案设计师，IBM jStart Emerging Technologies

2001 年 7 月

早在 Web 服务传播的初期，客户们就已经开始询问这一技术与 CORBA 有何区别。 它是不是分布式计算的另一种形式？在 Web 服务设计师的这一部分，Dan Gisolfi 简要概述了 SOAP、DCOM 和 CORBA 之间的区别，并为分布式计算领域内的 Web 服务提出了一个有价值的建议。
可通过点击文章顶部或者底部的讨论，加入这篇文章的讨论论坛。

在以前的文章中，我曾论述过动态电子商务的构想以及能让我们得以实现这一构想的可用技术，也就是 SOAP、WSDL 和 UDDI。对于好奇的读者来说，动态电子商务的整个课题只是分布式计算的另一种形式。对于这一新的分布式计算模型所作的调整改进是跨平台以及跨编程语言的互操作性。自从分布式计算成为主流概念以来，我们首次拥有了一个建立在真正支持互操作性的开放标准基础上的解决方案。

在宣传 Web 服务的整个行程中，我所面对的听众总会产生一种善意的疑问。拋开听众不谈，对于 Web 服务的疑问通常是通过以下（及相关的）问题中的某一个表现出来：

Web 服务技术与 CORBA 有何区别？

为什么 Web 服务能在 CORBA 失败的领域获得成功？

有两个原因使得我对这些问题持欢迎态度。首先，它们反映了人们对于分布式计算有一定的熟悉程度，这有助于交流的开展。分布式计算编程模型在 IT 产业内成为主流已经有些时日了。我估计这一情形至少在近二十年内是如此。因此交流能着重于以前解决方案的缺点以及将来对于成功的解决方案的要求。

其次，由于我们讨论的并非一个全新的概念，那么人们能否接受 Web 服务的有关风险就小了。这也反映了它的开放标准基础以及这些标准在厂商解决方案中的普遍性。低风险还反映了在改进 Web 服务互操作性方面所做的实际努力（这与以前解决方案所作出的关于厂商互操作性的“圆滑”承诺形成了对比 — 我在后面还将详细讲述这一点）。

过去，对象管理组（Object Management Group，OMG）及其 700 多个成员公司曾试图规定厂商们需如何设计对象请求代理程序（object request brokers，ORB）以实现互操作性。然而，现实情况是厂商们在 ORB 的实现上存在竞争，因此从商业的角度来说不存在实现互操作性的动机。事实上，真正的 ORB 厂商的商业目的是能在分布式计算应用程序的两端同时出售其解决方案：请求者和 提供者节点。

SOAP 是一个出色的分布式计算解决方案，因为它通过规范级别和实现级别上的开放标准，实现了互操作性。我跳到后面的内容上去了。让我们回过头来看一下 CORBA 和 DCOM，最后再来看 SOAP。我将提供一些关键区别，并举例说明为什么基于 SOAP 技术的 Web 服务拥有更好的分布式计算解决方案。

通信协议模型的简单历史

分布式应用程序需要一个定义两个并发进程间通信机制的协议。存在两种建立这种应用程序的通信协议模型： 消息传递／排队以及请求／响应。消息传递和请求／响应模型各有所长，可以相互代替执行。例如，能用较低级别的请求／响应协议来建立消息传递系统。Microsoft 分布式计算环境（Distributed Computing Environment，DCE）就是这样的。对于远程过程调用（Remote Procedure Call，RPC）应用程序来说，同步请求／响应的设计风格通常是自然契合的。

在 20 世纪 80 年代，通信协议模型集中在网络层上，如最初由 Sun Microsystems 开发的网络文件系统（Network File System，NFS）— 大多数联网的 Unix 系统都用它作为分布式文件系统 — 以及 Microsoft 的运行在 Windows NT 上的 DCE RPC 应用程序。到了 90 年代，面向对象的编程团体迫切要求一个能将应用程序对象与网络协议链接起来的对象 RPC（ORPC）协议。ORPC 和先于它们的 RPC 协议之间的主要区别是 ORPC 将通信端点的映射编码至一个语言级别的对象中（请参阅参考资料中的 A Young Person's Guide to The Simple Object Access Protocol ）。

这一映射允许服务器端的中间件在服务器进程中定位并实例化一个目标对象。有一些技术（如将索引作为散列表键映射到一个数组或相关联的符号名称中）被用来实现端点到对象的映射。在 SOAP 和 Web 服务出现以前，在通用内部 ORB 协议（GIOP）中，Microsoft DCOM 和 CORBA 的因特网内部 ORB 协议（Internt Inter-ORB Protocol，IIOP）风格是业界的主流 ORPC 协议。

什么是 CORBA？

公共对象请求代理架构（Common Object Request Broker Architecture，CORBA）是对象管理组实现分布式计算节点间的互操作性的规范。他们的目标是定义一个架构，该架构能允许不同种类的环境进行对象级通信，而无需考虑是谁设计了分布式应用程序的两个端点。

CORBA 1.1 由对象管理组（Object Management Group，OMG）于 1991 年提出。它定义了允许客户机／服务器对象在对象请求代理（Object Request Broker，ORB）的特定实现中相互作用的接口定义语言（Interface Definition Language，IDL）和应用程序编程接口（Application Programming Interfaces，API）。ORB 是在分布式对象间建立请求者-提供者关系的中间件。

CORBA 2.0 于 1994 年 12 月被采用，它通过指定来自不同厂商的 ORB 如何相互操作解决了互操作性问题。（请参阅参考资料）。

ORB 将收到一条调用消息，来为注册的对象调用一个特定的方法。ORB 截获这条消息，并负责搜索一个能执行该请求的对象，将参数传递给它，调用它的方法，然后返回结果。理论上，请求节点无需知道对象的位置、它的编程语言、它的操作系统或不属于对象接口的一部分的任何其它系统方面的信息。

接口用一系列方法在外部把 CORBA 对象表现出来。一个对象引用可以识别对象的一个特殊实例。CORBA 对象的一个客户程序获取了其对象引用，并将它用作句柄进行方法调用，就好像对象是位于客户程序的地址空间中一样。ORB 负责搜索对象的实现所需要的所有机制，让它做好接收请求的准备，随后将请求传达给它，并将回应（如果有的话）送回客户程序。

什么是 DCOM？

DCOM 是 Microsoft 的 COM（组件对象模型，Component Object Model）的分布式扩展（请参阅参考资料中的 COM95），它在 DCE RPC （请参阅参考资料中的 DCE95）的顶端建立了一个对象远程过程调用（ORPC）的层来支持远程对象。COM 服务器能创建多对象类的对象实例。一个 COM 对象可以支持多个接口，每个接口代表对象的一种不同的视图或行为。一个接口由一套功能相关的方法组成。COM 的客户程序通过获取指向一个对象接口的一个指针，并通过该指针来调用方法以实现与 COM 对象之间的互相作用，就好像对象驻留在客户程序的地址空间中一样。COM 指定任何接口都必须遵循一个标准的内存规划，这与 C++ 的虚拟函数表（请参阅参考资料中的 Rogerson96）相同。由于该规范是二进制级别的，因此它允许集成可能用不同编程语言如 C++、Java 和 Visual Basic（请参阅参考资料）等编写的二进制组件。

基础 RPC 架构

在 DCOM 和 CORBA 中，客户进程与对象服务器之间的互相作用是作为面向对象的 RPC 式通信来实现的。图 1 展示了一个典型的 RPC 结构。为调用一个远程函数，客户程序要调用客户机存根。然后存根将调用参数打包成一个请求消息并调用传输协议将该消息传送到服务器。在服务器端，传输协议将消息传送给服务器存根，随后服务器存根解包请求消息并调用对象中真正的函数。在 DCOM 中，客户机存根被称为代理（Proxy），而服务器存根被称为存根（Stub）。相反，CORBA 中的客户机存根称为存根（Stub），而服务器存根称为框架（Skeleton）。有时， 代理这个名称还被用来指 CORBA 中正在运行的存根实例。至于在 SOAP 和 Web 服务中，我们称客户机存根为服务代理（Service Proxy），称服务器存根为服务实现模板（Service Implementation Template）。表 1 说明了这些概念的不同名称

表 1：不同 RPC 架构中的客户机与服务器组件

图 1：基本 RPC 架构

细微的差别影响互操作性

DCOM 和 CORBA IIOP 有许多相似之处。这两个协议都使用端点标识符来识别服务器端中间件中的目标对象，且它们都使用方法标识符来确定待调用方法的签名。

表 2：CORBA 和 DCOM 中实现属性名称比较

然而，与这些相似之处同时存在的还有一些影响互操作性的差别。 如表 2 所示，存在三个主要的差别：

通信端点的命名：在 ORPC 协议中，需要 ORPC 端点的一些消息表示法以便通过网络传达对象引用。在 CORBA/IIOP 中，这种表示法被称为可互操作的对象引用（Interoperable Object Reference，IOR）。IOR 包含可移植格式的寻址信息，任何基于 CORBA 的产品都能把这些信息解析到对象端点上去。在 DCOM 中，这种表示法被称为 OBJREF，它能将分布式引用计数与端点／对象识别结合起来。遗憾的是，IOR 不能与 OBJREF 相互关联，这就导致了 CORBA 和 DCOM 应用程序之间的互操作性问题。

支持一对象多接口：在 CORBA 中，接口标识符是固有的，因为它只支持一种对象接口。然而 DCOM 能支持一对象多接口。

有效负载参数值的格式：在 DCOM 中，有效负载是以一种称为网络数据表示法（Network Data Representation，DR）的格式编写的。在 IIOP/GIOP 中，有效负载是用通用数据表示法（Common Data Representation，CDR）编写的。DR 和 CDR 都处理各种平台上使用的不同数据表示法。需要注意的是，这两种格式之间存在着一些细微的差别，使得它们彼此无法兼容。

为什么 CORBA 和 DCOM 的成功是有限的

尽管 CORBA 和 DCOM 已经在各种平台上得到了实现，然而实际情况是建立在这些协议之上的任何解决方案都依赖于单一厂商的实现。因此，如果要开发一个 DCOM 应用程序，分布式应用程序中所有参与的节点都必须以 Windows 风格运行。如果要开发 CORBA 应用程序，应用程序环境中的每个节点都要运行相同的 ORB 产品。现在也有来自不同厂商的 CORBA ORB 能够相互操作。但是那种互操作性并不能扩展到像安全与事务管理那样的更高级别的服务中去。不仅如此，所有特定于厂商的优化在这种情况下将丢失殆尽。

这两种协议都依赖于严格管理的环境。要找到能成功地在外部调用 DCOM 或 IIOP 的任意两台计算机的几率比较小（请参阅参考资料）。此外，程序员们必须处理数据排列和数据类型所需的协议唯一的消息格式规则。DCOM 和 CORBA 都是服务器对服务器通信的合适的协议。然而，它们在客户机对服务器通信方面都存在严重的缺陷，特别是当客户机遍布因特网时。

改进的 RPC 解决方案需要些什么

尽管 CORBA 和 DCOM 存在着局限性，但由于我们迫切需要一个分布式计算模型，因此它们还是得到了广泛的应用。事实上，随着因特网的出现，企业越来越强烈地希望在公司外部与分布式应用程序结合。那么一个成功的分布式计算模型需要有一些什么样的特征呢？首先，解决方案一定是厂商、平台以及语言都不确定的。此外，它所提供的必须不只是互操作性的承诺；它必须使互操作性有很大的提高。另外，它必须能方便程序员们使用协议及部署应用程序。这就要求能方便地访问协议的客户机和服务器端的实现。简单地说，我们需要一个建立在开放因特网标准基础上的新的分布式计算模型。

依赖开放因特网标准

Web 服务技术组件是一套开放的规范，它们要么是现有的因特网标准，要么是被广泛接受并正在通过正常步骤成为标准的规范。组件的基本部分包含 HTTP、XML、SOAP、WSDL、UDDI 以及 WSFL。

这部分的基础是 HTTP，它是一个被广泛运用的、类似 RPC 的简单协议，并且是防火墙友好的。接下来，是 XML 中的通用数据表示法语言，它同样被广泛使用。SOAP 是一个基于 XML 的消息传递协议，它不确定平台及语言。它同时支持消息传递和请求／响应通信模型。与 CORBA 和 DCOM 一样，它需要一个 IDL。它所使用的 WSDL 是一个基于 XML 的服务 IDL，定义了服务接口和其实现特征。

让我们回顾一下表 2，并注意 HTTP 和 XML 作为一个新的分布式计算模型带给 Web 服务的价值。在 HTTP 中，请求和响应消息都能包含任意的有效负载信息。HTTP 报头（HTTP header）只是纯文本，这使得一般的因特网程序员便于使用。通常，这些报头包含内容长度和内容类型。并且 HTTP 使用 TCP/IP 作为其请求／响应消息的网络通信协议。HTTP 客户机利用 TCP 连接到 HTTP 服务器。建立了 TCP 连接以后，客户机可以向服务器发送 HTTP 请求消息。然后服务器对请求进行处理后将 HTTP 响应消息发送回客户机。简单地说，HTTP 是一种出色的不确定有效负载的传输方式，它提供了 CORBA 和 DCOM 中所能找到的大部分连接管理功能。它还使用 URL 进行对象引用，它们与分别在 CORBA 和 DCOM 中找到的 IOR 和 OBJREF 相一致。

由于 HTTP 是不确定有效负载的，它确实缺少一个在 RPC 消息中表示参数值的机制。这就需引入 XML 了。XML 是一种与平台无关的标记数据表示语言。它允许数据串行化为一种消息格式，从而能轻易地在任何平台上进行解码。然而，与 DR 和 CDR 不同，XML 很容易使用，它提供了一种灵活的、易于扩展的数据格式，并且能获得几乎所有计算平台的支持。不仅如此，它还是开放的，并且被广泛采用。表 2 描述了 HTTP 和 XML 是如何解决困扰 CORBA 和 DCOM 的互操作性问题的。

Web 服务技术组件提供了 SOAP 作为映射应用程序对象到网络协议的开放标准 ORPC（请参阅表 3）。尽管 SOAP 不受特定的传输协议的约束，HTTP 还是成为了早先在 SOAP 采纳者中最受欢迎的协议。使用 HTTP 时，SOAP 信封使用 XML 作为请求和响应参数的编码方案。SOAP 消息实质上是一个遵循 SOAP 编码规则的 HTTP 请求和响应。SOAP 端点就是一个基于 HTTP 的、识别方法调用目标的 URL。与 CORBA 一样，SOAP 并不要求一个特定对象被连接到给定的端点上。相反，需要由实现者来决定如何将对象端点标识符映射到服务器端的对象上。在 SOAP 中检查方法名称的名称空间 URI 与在 DCOM 或 CORBA 中检查方法名称的接口 ID 在功能上是相同的。

表 3：Web 服务的互操作性特征

通向成功之路

依靠开放的、被广泛采用的标准只是解决方案的一部分。我们还需确保该解决方案能提供高度的互操作性并且协议的实现容易访问。这也是我看好 Web 服务前景的原因。厂商们纷纷开始支持包含 Web 服务组件的标准。这也许是由于时间选择和省钱的原因，或者也许是因为因特网对编程模型的影响。抛开原因不谈，结果是十分令人满意的。不同于由 DCOM 和 CORBA 解决方案所造成的单一厂商的实现要求，厂商们一致认为，定义一个能让应用程序实现互操作性的分布式计算模型是每个人的最大利益所在。

最近，IBM 为一大群 SOAP 厂商主办了一个互操作性专题研讨会。Microsoft 和 WebMethods 等公司都自愿参与，以保证它们的 SOAP 解决方案能与其他厂商的解决方案实现互操作。这是 90 年代 ORB 之争的 180 度文化转弯。这个专题研讨会只是个开始。另一个由其他厂商主办的专题研讨会已经在计划之中。

当我们介绍开放源代码实现的概念时，情况变得更好了。Web 服务组件的核心，即 HTTP、XML 和 SOAP 的实现可自由地通过 Apache 开放源代码社区得到。WSDL 的免费实现可从 Microsoft 和 IBM 处获得。因此一般的程序员能公开获取必需的工具以快速开发分布式应用程序，此外，他们很放心，为这些应用程序部署的支持可以被应用程序用户简单、划算地解决。

翻版

Web 服务是 CORBA 的翻版吗？不，至少我不把 Web 服务编程模型看作是 CORBA 的再现或再生。我把它看作是一个全新的开放的解决方案，它解决了 CORBA 所解决的相同的分布式计算问题，同时又有更进一步的目标，那就是改进 CORBA 的一些缺陷。

Web 服务技术提供了一个全新的编程模型来利用开放因特网标准建立分布式应用程序。这一全新的分布式计算解决方案采用特定因特网技术的开放性解决了许多 CORBA 和 DCOM 的互操作性问题。特别是，Web 服务

使用 HTTP 来实现防火墙友好和不确定有效负载；

将 XML 作为一个编码模式使用，它能比 DR 和 CDR 更为广泛地被采用；

提供关于 HTTP/SOAP 服务器环境的免费的经济价值建议，或提供关于 ORB 框架的收费的经济价值建议；

使用广泛深入的 URL 因特网概念来解决对象识别问题；并且提供的不只是互操作性的承诺。厂商们正积极工作以证明它们的 SOAP 实现确有互操作性。

Web 服务是不是一个更好的 RPC？我想是的，但只有时间能够证明一切。

参考资料

• 可通过点击文章顶部或者底部的讨论，加入这篇文章的讨论论坛。
  
• 请阅读我这一系列中的 第 1 篇和 第 2 篇专栏文章。
  
• 请阅读 Web Services Conceptual Architecture 以获得 Web 服务的概述。
  
• 请查阅关于动态电子商务的 realworld adoption scenarios。
  
• 请回顾简单对象访问协议。
  
• 请阅读 Web 服务描述语言。
  
• 请访问对象管理组的站点以了解更多关于 CORBA 的信息。
  
• 学习如何将 CORBA ORB 与 WebSphere Application Server 集成起来。
  
• WebSphere Application Server 支持 CORBA、Web 服务以及 J2EE。
  
• 请访问主页，了解更多有关通用描述、发现和集成方面的信息。
  
• 了解谁是 XML 协议工作组的成员。
  
• 更多 dW Web 服务参考资料。

Web服务设计师，第2部分

Web服务设计师，第4部分

Web服务设计师，第5部分

Web服务设计师，第6部分