围绕SOAP的谬论和误解

haidong

<p >作为新生事物，SOAP不得不做一些解释以获得认可。SOAP 将成为包括 CORBA、 RMI 和 DCOM在内的其它服务器到服务器通信技术的邻居。围绕现有的技术阵营已经形成。现在各谬论、流言和讥讽横飞。在这篇文章中，Frank Cohen 细述并拆穿了很多围绕SOAP的谬论和误解。<p >作为一个新来者，SOAP 被拿来与它的已确立的和成熟的前辈作比较，包括 CORBA、DCOM、RMI 及其它技术。SOAP 采取了一个轻量级的“让我们与一切互操作”方法。很多围绕 SOAP 的谬论和误解需要拆穿。正如 Ralph Waldo Emerson 曾经说过的要成为一个真正伟大的人要先被误解。<p >这里是一些比较常见的围绕 SOAP 的谬论和误解：<p ><b>误解：SOAP 存在是因为 CORBA 对防火墙不友好</b><p >· CORBA 难与防火墙一起工作的名声是不公平的<p >SOAP 和 CORBA 包含把通过因特网连接传送到远程服务的数据组织在一起的机制。虽然 CORBA 1.0 成功地定义了一种语言无关的通信方式，但它却把实现“对象请求代理”（Object Request Broker,ORB）的协议的任务留给了供应商。因为因特网在它刚出来时是相当新的东西。大部分 CORBA 1.0 ORB不能互操作。CORBA 2.0 引入了“ORB 间协议”（Inter-ORB Protocol,（IIOP）），它和其它网络协议一起，运行在 TCP/IP 之上。<p >防火墙注意到这个新协议，并且有的时候就阻止ORB通信。IIOP很快给CORBA带来一个不应有的难与防火墙一起工作的坏名声。<p >然而，SOAP 通过建立 HTTP 连接隧道来部署自己的协议：SOAP 要求把请求参数组织在 XML 文档中，该文档然后被放到 HTTP POST 请求体中发送到运行在 Web 主机基于 SOAP 的 Web 服务。同样，现在正在做很多扩展 SOAP 的工作，使它能使用其它的传输协议，例如 HTTPS 和 SMTP。<p >SOAP插入现有的Web环境；CORBA 扩展自己以包含 Web。旧系统 — 包括“开放式软件基金会”（Open Software Foundation,（OSF））的“分布式计算环境”（Distributed Computing Environment,（DCE））、联机事务处理（online transaction processing,（OLTP））软件，例如 IBM CICS 和其它拥有自己的协议和语言相关的系统 — 被期望能实现支持 SOAP 的 HTTP 类型的无状态协议。另一方面，IIOP 被设计来使这些旧系统能成为跨网络连接 ORB 的通信协议。<p >自从 CORBA 2.0 在 1995 年问世以来，启动了很多 IIOP/HTTP 网关来启用 IIOP 在 HTTP 上建立隧道。<p ><b>谬论：SOAP 能更好地伸缩，因为 SOAP 是无状态的</b><p >· SOAP 也将最终变成有状态的<p >SOAP 把请求参数组织到 XML 文档并使用 HTTP 来把请求发送到 Web 服务。很多人认为 SOAP 对 HTTP 的依赖使它无状态。并且 SOAP 1.2 确实缺少对会话机制的定义。然而，SOAP 将不可避免地拥有会话机制以启用事务请求。设想一个数据库应用程序，那里由几个 SOAP 请求构成一个事务，并且 SOAP 请求组可能被立即回滚或者提交。毕竟，连想象的无状态 HTTP 协议都有启用有状态事务的 cookie。<p >CORBA 以一个使用无状态的 ORB 请求的简单机制为特色。选择无状态还是有状态是系统设计者在 CORBA 环境中要作的决定。很多系统当它们试图实现复杂的无状态系统时失去了可伸缩性。<p ><b>谬论：SOAP 是开放的，.Net 是封闭的。</b><p >· SOAP 是开放的；如果小心应用，.Net 也是开放的<p >即使 SOAP 是由 W3C 制定的开放标准，Microsoft 的 .NET 对 SOAP 的使用也可能给您的 Web 服务一个意想不到的 Windows 偏见。但是小心使用 .NET 应用程序中的 SOAP 将会使 SOAP 保持开放。<p >SOAP 定义几个基本数据类型（String、Int 和 Double），通过它们可以发送和接收参数。每一个新的数据类型都引入一个序列化器来把 XML 值转换成本机编程语言值并再次返回。Microsoft 的 .NET 部署了另外的专有数据类型。例如，Apache 和 Microsoft SOAP 实现都包括 BigDecimal 数据类型。然而它们是不兼容的。<p >使用 SOAP 定义的原始数据类型保证基于 SOAP 的 Web 服务能与所有的 Web 服务互操作，包括 .NET 服务。 如果您用另一种相近的方法，并使用 .NET 或者其它专用的 SOAP 扩展 — 您的服务将不能与所有其它的 Web 服务互操作。<p >SOAP 实现的不同产生了针对 SOAP 互操作性的工具市场。Cape Clear 的 CapeStudio 和 The Mind Electric 的 Glue 都是用来在 XML 和 SOAP 平台差异之间映射的商业产品。<p ><b>误解：相对今天设计良好、开放和成熟的技术的COBA，SOAP没有优势。</b><p >· SOAP 和 Corba 相比，SOAP 更多地涉及消息传递，而 CORBA 则是远程过程调用。<p >SOAP 和 CORBA 阵营的斗争表明在计算机工业中出现代沟。CORBA 是在 10 年前开放源代码运动出现之前开发的。“对象管理组”（Object Management Group，（OMG））于 1989 年在 3Com、American Airlines、Canon、Data General、HP、Philips、Sun 和 Unisys 的发起下创建了 CORBA。与 Apache Group、Red Hat 和 Sendmail 相比，这些是今天的技术主导。<p >表面上，SOAP 和 CORBA 提供了应用程序间通信的解决方案。实际上，CORBA 做了很多工作使面向对象的程序能搜索和使用远程服务器上的对象。SOAP 做了很多工作来把数据组织成一种可以全局共享并在服务器应用程序软件之间转换的格式。这里 SOAP 利用了 XML 的优点：英语可读的代码、转换语言、描述语言和平台无关性。<p >利用 SOAP 提供数据共享和转换的新技术最近已经出现了。例如，IBM 提供了把旧的 Cobol 应用程序封装到基于 SOAP 的 Web 服务的软件。并且 Cape Clear 的“Web 服务平台”允许 SOAP 调用 CORBA ORB。<p >在 CORBA 能更加强大地构建和部署分布式系统的同时，基于 SOAP 的 Web 服务在遥远的未来就能用可读的数据格式通信。<p ><b>谬论：SOAP 要求您是个 DOM 专家</b><p >· JDOM 消除了当您使用 SOAP 时，须成为 DOM 专家的要求。<p >SOAP 使用 HTTP 来把 XML 请求和响应数据发送到远程运行进程。听起来似乎您必须学习 XML、HTTP、DOM、Web 服务器操作和更多其它知识。但是，实际上大部分 SOAP 示例代码使用 SOAP 的内绑组织方法来设置传出参数和值。因此，除非您发送一个有很多参数的复杂请求，否则我认为最好是使用 SOAP 的 Call 对象和 Vector 来设置参数。<p >SOAP 返回包含一个 XML 文档的一个 Response 对象。Java 开发者有一个新的开放源代码项目 — JDOM 来使操作响应 XML 文档简单。请查看清单 1 来看看如何用 JDOM 获取响应 XML 的根。<p ><ccid_nobr><table width="550" border="1" cellspacing="0" cellpadding="2" bordercolorlight = "black" bordercolordark = "#FFFFFF" align="center"><tr><td bgcolor="e6e6e6" class="code"><pre><ccid_code>清单 1：使用 JDOM SAXBuilder responseSAXTree = new SAXBuilder();Document doc = responseSAXTree.build( response );Root theroot = doc.getRoot();</ccid_code></pre></td></tr></table></ccid_nobr><p >这样，JDOM 消除了使用 SOAP 时须成为一个“文档对象模型”（Document Object Model，（DOM））专家的要求<p >JDOM 最终将成为 Java 自身（JSR 104）的一部分。现在，您可以免费下载和使用 JDOM（请参阅参考资料来找到链接）。要看运转中的 SOAP 和 JDOM，请看 Load 实用程序(也列在参考资料）。Load 是免费的开放源代码实用程序，它用来测试基于 SOAP 的 Web 服务的可伸缩性和性能。<p ><center><font color="#000099"><strong>结束语</strong></font></center><p >很多围绕SOAP的谬论和误解都源自SOAP的年轻或者在计算机工业中发展的代沟。SOAP、CORBA、RMI、DCOM 及其它完成了可伸缩的互操作性。随着时间的推移，SOAP 将作为成熟的技术加入它们的队伍并增加安全性、加密、协议压缩和时间服务方面的工具程序。同时，一套新的工具将会出现，以提供 XML 驱动的服务器应用程序间的数据转换。倘若软件开发者坚持开放标准实现和数据类型，我相信 SOAP 将会成为有着一统服务器天下的新前景的、有效的互操作性技术。<p ><b>参考资料</b><p >参加关于本文的讨论论坛。<p >JDOM，一个免费的用于管理 XML 文档的开放源代码实用程序。<p >Load，一个免费的开放源代码实用程序，用于测试基于 SOAP 的 Web 服务的可伸缩性和性能。<p >Cape Clear 的 CapeStudio 是处理 SOAP 和 WSDL 资源的图形化工具。<p >请参阅 SOAP 协议规范。<p >这里是公开可用的 Web 服务的列表。<p >Glue 是交叉平台 XML 框架。<p >请参阅 Microsoft 的 SOAP 参考资料。<p >IBM 参考资料<p >想获得 Web 服务和 CORBA 的另一个比较，请查看以前的 Web 服务设计师专栏的期刊。<p >关于“Web 服务体系结构和技术”的 Lotus 主页展示了 SOAP 如何适应于其它技术以创建 Web 服务前景。<p >DeveloperToolbox Technical Magazine 最近在文章 Delving into SOAP security 中研究了 SOAP 安全性问题。<p ><b>关于作者</b><p >Frank Cohen 是个软件创业者，他自1975年以来就为了个人计算机全世界的成功作贡献。他开始时为微型机写操作系统，帮助建立视频游戏产业，帮助建立 Norton Utilities 特许，领导 Apple 进入中间件和因特网技术领域的工作并且在最近担任 Sun Community Server、Inclusion.net 和 TuneUp.com 的主要设计师。Frank 维护开放源代码的 Load 项目，他是 PushToTest — 一个可伸缩性和性能测试解决方案公司的 CEO。更多信息可以在 www.PushToTest.com 获得。您可以通过 fcohen@pushtotest.com 与 Frank 联系。 <p >（责任编辑 <ccid_nobr>Sunny</ccid_nobr>）                                 <p align="center"></p></p>