|
Web 服务内幕，第 1 部分 我们已走了多远？
“Web 服务革命”目前形势如何？在这个以“Web 服务内幕”命名的新专栏的第一部分中，我将回顾在过去几年中涌现的一些工具和技术，以突出显示它们的差异和相似之处。
您好，欢迎光临本专栏，我们致力于探究 Web 服务世界。在接下来的几个月中，我将彻底而详细地说明 Web 服务体系结构的基本原则，并特别关注核心约定，其推动了新兴的、发展迅猛以及涌现出的技术范例：互操作性。
但是，我不是要展望 Web 服务将来会带来什么，只是想迅速回顾一下 Web 服务走过的历程，当今它（根据工具的实用性）的适用范围，并就使这个令人激动的新技术具有可行性和竞争性还须付出多少努力的问题，发表了一些个人见解。
我们的起点
如果您认为因特网上的 Web 服务发展非常迅速，那么您的看法完全正确。真是难以置信，这个新范例（SOAP、WSDL 和 UDDI）的构建模块都仅仅才出现了几个月而已，却已经对设计、开发和部署基于 Web 的应用的观念产生了巨大的影响。
简单对象访问协议（SOAP，请参阅参考资料）起源要追朔到 1998 年，源自最初由 Vserland Software 的 Dave Winter 创建的基于 XML 的 RPC 机制的想法。1999 年后期，此想法在 DevelopMentor 的 Winer、Don Box 和 Microsoft 的共同努力下发展成了 SOAP 版本 0.9。那时，开发人员社区的反应很复杂。如果我回忆正确的话，我当时的反应是 SOAP 看起来象一个很酷的玩具，到离实用还有一大段差距。事情变化得很快。在 SOAP 版本 0.9 发布没有多久，就发布了 SOAP 1.0，它增加了很多的改进并扩大了所支持开发人员的范围。
IBM 于 2000 年 5 月合作开发了 SOAP 版本 1.1 的规范（请参阅参考资料），并把它作为 W3C Note 来提交，由此正式加入 SOAP 的开发行列，从而正式标志了“Web 服务革命”的开始。随着 IBM 的加入，非 Microsoft 开发平台上的开发人员站了起来并首次关注了 SOAP。这种可在松散的联合和动态的集成应用之间建立的无缝跨平台互操作的约定具有极大的诱惑力，尤其适用于 Java 开发的原则。
从这一点讲，Microsoft 和 IBM 在把基于 SOAP 的开发工具发展为开发者手头所使用工具方面起了领导作用。开始很简单，IBM 是第一个为 SOAP（请参阅参考资料）开发出基于 Java 的工具包，这为开放源码 Apache Software Foundation 的进一步开发做出了积极的贡献。Microsoft 随后不久发布了它们的第一个再现 SOAP 工具包并在接下来的六月主动公布他们的宏伟的 .NET Web 服务。
随着支持 SOAP 产业的迅速发展，IBM 和 Microsoft 随后把他们的注意力转向填补出现的 Web 服务体系结构的各种漏洞。即，由于基于 SOAP 应用即将迅速发展的潜力，他们需要一个描述此类服务的机制和一旦部署了此类服务就要定位服务的机制。在去年九月，Microsoft、IBM 和 Ariba 共同公布了通用描述、发现和集成（UDDI [请参阅参考资料]），这就为发现部署在因特网上 Web 服务提供了一个开放的规范和一整套工具。然后，仅仅是几星期的时间，这三个公司又公布了 Web 服务描述语言（WSDL [请参阅参考资料])，它是一种描述基于 SOAP Web 服务能力和技术细节的 XML 语法，这种服务允许动态跨平台集成来实现 SOAP。
在本专栏以后的部分中，我想探讨如何把这三个受到称赞的、具有不同的技术的每个规范组合起来以提供 Web 服务体系结构的基础，以及 IBM 如何在在 Web 开发中把大多数优点应用于这个新范例中，从而占据领先地位。
目前形势
研究下目前形势通常可以让我们更好地确定现在所处的阶段和发展方向。回顾 Web 服务的历程，我很高兴地说它正处于技术成熟的第一个阶段 -- 即已被接受。Web 开发世界已逐渐将 Web 服务视作可行的工具，用于实现许多更陈旧、更大且更庞大的技术所不能完成的任务：在平台和操作系统之间实现无缝互操作性。显然，在 Web 开发行业中，几乎每个主要的开发商都在研究如何才能够最大限度的利用 SOAP 和其它支持 Web 服务的技术。
今天，用 Web 服务体系结构创建的应用类型大多数都是相当简单的“玩具”，主要是帮助开发人员掌握相对于展示真正企业规模平台适用性的基本概念。应该承认，目前这种情况下仍有例外，如果仔细观察成熟的 Web 服务工具，譬如说 Java Enterprise SDK 或 Microsoft COM+ Platform，显然在企业开发界中仍然需要继续努力以发挥出 Web 服务的真正潜力。
那么，这句话是什么意思呢？这意味着在企业环境中，仍需要尝试、测试和证明 SOAP、WSDL 和 UDDI 可以发挥作用而且产生好的效果。它是否表示，作为一位开发人员者或技术决策者，不应指望 Web 服务解决企业层次的问题？或者，甚至说得更彻底一些，在时间和成果已经可以使实现这些标准的工具发展到成熟阶段（适合于那些对于任务比较关键的环境）之前，您甚至不敢正视 SOAP？绝对不是这样！如上所述，虽然我还没有基于 Web 服务将 SOAP、WSDL 和 UDDI 部署到企业环境，此领域的发展和进步就已经非常迅猛。Enterprise-ready 工具，如 Microsoft 的 .NET 平台和 Apache Axis Engine（这两个工具目前仍然都在开发中）许诺将开发出构建在企业 Web 服务之上的高价值、高性能和高稳定性的产品。今天通过了解和使用 SOAP，您的开发队伍将获得宝贵的经验，这将帮助他们在这个新的开发范例中获得成功。也许同样重要的是，他们的经验将帮助我们中的这些人来构建这些工具，并完善和调整它们，使之满足客户的挑战性需求。
适用领域
在上一次统计中，随着支持多种操作系统和开发语言的不断增长，我知道至少有 39 种不同方法可实现 SOAP 规范。然而，它们都各自有自己的能力、支持标准和质量控制的级别，但他们都至少有一个共同点：都知道如何创建和使用 SOAP Envelopes。不要低估这个事实的重要性。这仅意味着无论如何实现工具，或在哪里部署它，这里都有一个潜在的无缝互操作性，它允许在一个平台上用一种语言编写的应用程序可以使用在另一个完全不同的平台上以完全不同语言编写的应用程序的服务。
在下面并列比较了四种在 Java、Win32 和 Perl 环境中最常见的 SOAP 实现的特点。从分析的结果中可以得知，在特定的 SOAP 或相关的 SOAP 特性中，与其说有更多的差异不如说有更多的相似之处。这是一件好事，因为这意味着我们越来越清楚地意识到 SOAP 的真正潜力。然而，在某些情况下确实存在差异，如果不知道如何避开它们的诀窍，差异会严重到引起一些麻烦（那些试图将 Microsoft 工具包与 Apache SOAP 一起使用的人可以证明）。我计划在今后的文章中，深入的讨论这些差异，请密切注意。
特性 选项 Apache SOAP 版本 2.1 SOAP::Lite Perl 版本 MS SOAP 工具包 Beta 2
遵循 SOAP 1.1
数据类型
定制编码风格 （是／否／有限） 是 否 有限
数组
一维 （是／否／有限） 是 是 是
多维 （是／否／有限） 否 否 是
部分 （是／否／有限） 否 否 否
稀疏 （是／否／有限） 否 否 否
多引用 （是／否／有限） 有限 是 有限
头文件／主体交叉引用 （是／否／有限） 有限 是 有限
循环引用 （是／否／有限） 否 是 否
实体编码 （是／否／有限） 是 是 是
容错
Actor （是／否／有限） 有限 有限 有限
复杂的细节 （是／否／有限） 是 是 是
支持 XML Schema 数据类型 （是／否／有限） 是 是 是
属性
mustUnderstand （是／否／有限） 有限 否 有限
actor （是／否／有限） 有限 有限 有限
root （是／否／有限） 是 有限 否
id/href （是／否／有限） 有限 是 有限
HTTP
M-POST （是／否／有限） 否 是 否
对象串行化 （是／否／有限） 是 是 是
支持 UTF8 （是／否／有限） 是 有限 是
传输
SMTP （否／全部／客户机／服务器） 是 客户机 否
POP3 （否／全部／客户机／服务器） 否 服务器 否
FTP （否／全部／客户机／服务器） 否 客户机 否
TCP （否／全部／客户机／服务器） 否 全部 否
HTTP （否／全部／客户机／服务器） 是 服务器 是
IO （否／全部／客户机／服务器） 否 全部 否
存取传输具体细节（如 cookie） （是／否） 否 是 否
扩展（如压缩或加密） （是／否）– 名称扩展 压缩
支持 SOAP 连接 （是／否／有限） 是 有限（仅语法分析） 否
安全性
SSL （是／否／有限） 是 是 是
基本／摘要认证 （是／否／有限） 否 是 是
数字签名 （是／否／有限） 否 否 否
管理和配置
日志 （是／否／有限） 有限 是 是
基于文件的配置 （是／否／有限） 是 否 是
没有／部署（实用程序、基于 web 地访问） （是／否／有限） 是 N/A 是
消息传递模式
单向消息 （是／否／有限） 是 是 否
异步消息 （是／否／有限） 否 否 否
调度
类／对象的名称空间 （是／否／有限） 是 是 是
SOAPAction （是／否／有限） 是 否 是
其它 （名称）
支持串行化
酬载生成（从描述／手工） （手册／从描述） 两者均有 两者均有 两者均有
定制串行化 （是／否／有限） 是 是 是
定制非串行化 （是／否／有限） 是 是 是
服务描述
WSDL
可读 （是／否／有限） 否 是 是
可生成 （是／否／有限） 否 否 是
可选／必须 （可选／必须） N/A 可选 可选
必需有存根 （静态／动态） 静态 两者均有，可选 动态
复数类型 （是／否／有限） N/A 否 是
其它 （名称） 消息编码扩展
错误处理 （是／否／有限） 是 是 是
建立公共基础
关于当前定义和涉及 Web 服务领域最令人吃惊的事情不是事物进展的速度，而是许多公司签署了一个开发项目，共同建立一个能够共同使用的基本互操作性的公共基础。Microsoft 和 IBM 长时间以来在 Web 开发产业是竞争对手，但现在他们联合起来，通过全面支持 SOAP、WSDL 和 UDDI 规范来确保他们的工具可以无缝地互相通信。显然，还有很多事要做；事实上，当我写本文时，IBM Web 服务小组和 Apache SOAP 开发小组正忙着与 Microsoft 小组就各种实现中存在的互操作性问题进行谈判。
我在张贴关于 SOAP 的邮件列表上看到的最常见问题是如何使 Microsoft SOAP 客户机或服务器与 Apache 或 IBM WSTK 客户机或服务器通信。在这个方案中，大多数开发者所面临的问题是总是围绕着一定的差异或限制 Apache 和 Microsoft 所实现的 SOAP 规范的方法。在随后的文章中，我将使用一个有深度的示例来展示如何做到这一点。确保下载最新版本的 Apache SOAP（至少是版本 2.1 [如果已经下载了 IBM Web 服务工具包版本 2.1 或更高版本，那您就有了 Apache SOAP 2.1]）和最新的 Microsoft's SOAP 工具包的第二个版本（请参阅参考资料）。这些所做的每一个更新都提供了已改进的互操作性和一些其他特性，这些证明它们能够使您的生活变得更加轻松自在。
Java 开发人员所使用的 Apache SOAP 工具也可以随意地下载 IBM Web 服务工具包 (WSTK) 或 Web 服务开发环境 (WSDE) -- 可以扩大和拓展 Apache SOAP 功能的两套工具。通过 alphaWorks 提供的这些技术可以支持 WSDL 和 UDDI 以及其它一些特性和开发工具，这些可以完成 Web 服务开发平台将具有的所有功能。
现在怎么办？
下一个问题应该是：现在怎么办？我已经简单回顾了 Web 服务的历史并大致了解了它现在所处的位置。我已经告诉过您当今构建 Web 服务需要的工具所处的阶段。虽然现在就着手构建关于 Web 服务的整个企业来说，这还不是一个好的想法。但同时，如果您有能力去做这件事，那么这个时刻不久就会到来。我们比较了当前可以使用的最流行的 SOAP 工具，那么当需要在特定平台上开发 Web 服务时，知道该从那里下手。
下一步是应该开始了解当前可以使用的 Web 服务：
如果还未准备好，请阅读关于 SOAP、WSDL 和 UDDI 规范
下载 IBM Web 服务工具包最新版本
研究工具包中提供的 Web 服务样本
开始实现自己的 Web 服务
|
