Web 服务带来了什么 ?

柴晓路

2002-3-8

电子商务应用的挑战

随着 Internet 的兴起，部署在 Web 上的应用随着 Internet 的深入人心，而不断发展。当 Web 应用已经走入人们的日常工作和生活的时候，人们发现在 Web 应用和传统桌面应用 ( 比如企业内部管理系统、办公自动化系统等 ) 之间存在着连接的鸿沟，人们不得不重复地将数据从 Web 应用迁移到传统桌面应用，或从传统桌面应用将数据迁移到 Web 应用，其中的迁移操作基本都要通过人的操作来完成，这成为了阻碍 Web 应用进入主流工作流的一个巨大的障碍。计算机的应用是要追求信息的自动化处理，然而，目前的应用状况，则使人们不得不在自动化的流程之间掺加上若干的人工步骤，这会在不同程度上降低人们使用计算机系统的积极性。

举个例子，某个公司通过 Web 提供了一个在线产品定购系统，这个公司的某一个客户找到了这个在线产品定购系统，在 Web 表单中输入了订单，同时在浏览器里获得了订单确认的响应。由于这个客户的公司内部使用了企业管理系统，应内部管理的需要，他还不得不同时把这个订单确认从浏览器里面复制出来，然后手工地填入企业内部管理系统的相应界面上，以使得内部系统中的事务能够正常流转。此时这个用户事实上将信息重复输入了两遍，对用户而言无论如何是一件厌烦的事情，从计算机系统的角度来看，这完全可以避免。

目前，大多数电子商务的应用在处理购买者、供应商、 Marketplace 和服务提供者之间的连接方式上各不相同。如何将这些应用方便地低代价地连接在一起，从而实现大范围的跨企业实体的商务应用系统的应用系统级别的互联，这是摆在开发人员面前的一大问题。不同的应用 ( 尤其是不同企业的 ) 开发语言不同、部署平台不同、通讯协议也可能不同，对外交换的数据格式更是可能有着巨大的差异。如何去面对语言差异、平台差异、协议差异、数据结构的差异所带来的复杂的系统集成的挑战是解决这个问题的关键。

XML & Web 服务 , 消除差异的持续努力

从 1998 年开始发展的 XML 技术及其相关技术是尝试解决这些差异的初步尝试。 XML 技术的提出，其初衷是为了改善 HTML 的无结构化的状况而造成的全球 Web 信息的结构混乱。 XML 规范的开发小组为了使得全球 Web 信息能够迈向结构化的方向，基于强大的 SGML 语言，制订了 XML 1.0 的规范。最初， XML 的应用的确是关注在信息发布领域，大量的使用 XML/XSLT 技术的网站纷纷出现，以证明 XML 在信息发布领域的优越性。之后，随着 XSL 规范的不断成熟， XML 技术从信息发布领域延伸到传统的电子出版领域，而基于 Web 的信息发布也正式成为了电子出版的形式之一：网络媒体出版。

然而，另一方面，由于 XML 的处理器 (Parser ，一般为 DOM 获或 SAX) 在各种平台上都分别交互开发人员使用，大家不约而同地发现，使用 XML 在不同的异构系统之间交换数据是一件那么方便的事情：首先， XML 格式具备描述各种类型数据的能力；其次，使用 DOM/SAX 对 XML 进行处理，开发人员可以节省开发通常需要的文件格式处理的模块， DOM/SAX 为 XML 处理封装了一套有效的方法；再次， XML 、 DOM 是 W3C 规范，大家都会遵循规范，在不同平台的处理方式是完全一致的。因此，很快， XML 就成为了应用范围极为广泛的数据交换的工具。随着应用 XML 进行数据交换的理念不断深入人心，另两个 XML 相关的规范也慢慢被引入到使用 XML 进行数据交换的领域里来，开发人员使用 XSLT 实现不同 XML 数据交换格式的互相转换，同时利用 XML Schema 对 XML 数据交换格式进行数据建模，由于它们都是基于 XML 的，同时平台工具不断更新以支持这些新规范，以使得数据层集成 ( 数据交换 ) 的应用得以在技术的强大后盾的支持下，不断推广。目前使用 XML 进行数据交换已经成为计算机软件领域，尤其是电子商务应用领域的标准技术模式。

XML 解决了在不同平台 / 系统之间的数据结构 / 模式的差异，使得数据层在 XML 技术的支持下，统一了起来。

对于全球电子商务所提出的广泛的电子商务应用集成和交互而言，光有数据层的集成是不够的。数据层的集成能力，使交互的双方能够彼此了解对方所发送过来的数据，但是数据应当由哪个应用、按照何种方式、使用何种上下文来实施处理，处理完了应当返回何种处理结果等等处理语义都无法通过数据层的集成来完成。大家可能会想到，我在数据中包含指定的应用、指定的处理语义，然后再将这个数据包传给对等方，对等系统接收到这个数据后，分析出发送方期望的应用和处理语义，然后再实施真正的数据处理，并按照发送方的要求返回处理结果。这，正是 Web 服务雏形的应用模式。

然而，此时，如何在数据中指定应用，如何将应用指派与真实的部署在平台上的应用程序映射起来，如何包装返回结果都需要开发人员自己来指定，这有些类似于原先未使用标准数据描述格式而进行数据交换的场合。

Web 服务系列技术则是架构在在 XML 技术的基础上，为在平台层解决掉这些应用层集成所不可避免的问题而提出的开放式的技术架构。

Web 服务的体系架构与 Web 应用的 N 层架构是类似的，不同点在于最上层的面向浏览器的 Web Server 被面向程序 (Web Service Client) 的 Web 服务所取代。而使用 Web 服务的程序可以是桌面应用程序，同样也可以是另一个 Web 服务。图 1 给出了 Web 服务的一个通同的简单的体系架构模式。

图 1 Web 服务的体系架构

构筑 Web 服务的 Web 服务技术家族的主要成员有 XML Schema 、 SOAP 、 WSDL 和 UDDI ，它们都是完全基于新一代 Internet 种子技术 XML 的。 XML Schema 为在不同系统 (Web 服务 ) 之间交换数据而提供了一个核心的跨平台数据建模工具。 SOAP 为在不同系统之间实施平台无关的交互定义了一套基本的元规则和跨平台消息机制， SOAP 是 Web 服务体系中服务交互的基础架构。 WSDL 则是 Web 服务接口界面的跨平台描述工具，依靠 WSDL ， Web 服务的交互界面就能被系统自动处理。 UDDI 则是在动态服务集成解决方案中的首次尝试。这组技术使得底层平台对应用交互透明，应用的互操作能力得到了前所未有的提升。它们组成了第一代的 Web 服务技术。

使用 Web 服务技术

既然 Web 服务技术是针对应用层集成交互的跨平台的技术框架，我们就来看看原先有哪些应用模式无法实现或很难实现，使用了 Web 服务技术之后就变成可以实现或容易实现了。

在本文中，我将主要考察三个领域：

§ EAI ，企业应用集成

§ B2Bi 以及在线服务集成

§ 以 Internet 作为整个后台服务的桌面应用

EAI, 企业应用集成

在很多大型企业中，随着企业业务的成长， ERP 、 CRM 、 SCM 等企业应用被逐个部署，对于大多数企业来说，处于投资、技术和应用领域的考虑，一般不同的应用可能会使用不同厂商所提供的产品。此时，每个应用都有其自己特有的基础架构，这些应用在部署、更改和维护上的代价都异常高昂。企业不得不为每套应用配置特有的专业技术人员，并保持与不同技术供应商或解决方案供应商的密切联系。同时这些应用即不能被方便地继承，也不能随着企业商务的规模扩展而方便地实现应用的规模扩展。

我们很清楚地认识到，即使是只有一个电子商务应用，其创建、维护和定制的代价及复杂度就已经是如此惊人了。何况要涉及多个这样的应用，其代价之高是可想而知的。

让我们来考察当企业部署若干个这样的电子商务应用的情形：

第一个应用，企业的为之付出的总的费用应该是该应用的开发和部署费用、以及运营时态的维护和更新费用。第二个应用，应用的开发和部署费用是一样的，但是企业需要为之花费额外的集成费用，同时由于整个企业应用环境变得更加复杂，其运营时态的维护和更新费用可能呈指数形式增加。同样，当第三个、第四个应用被部署后，企业所支出的费用可能是高得惊人。

这样的电子商务应用的实际运营状况非但无法令企业商务规模迅速增长，甚至会造成相反的影响作用，因为此时， IT 部门不得不雇佣更多的员工并花费更多的资金来管理这些复杂而纷乱的应用，并维护多种承载应用的基础架构。

我们知道，在传统 EAI 技术中，应用 A 要和应用 B 进行集成，那么应用 A 要为应用 B 编写一个集成适配器、同样应用 B 也要为应用 A 编写一个集成适配器。当情况更复杂一些，有三个应用存在的时候，那么每个应用需要分别为另两个应用分别编写集成适配器。这简直是企业内部从事应用集成的技术人员的噩梦。当然在这些领域里，也是有一些通用的集成手段，比如 IBM 的 MQ Series 之类的解决方案，对于每个应用来说只要编写一个集成适配器就可以应用技术框架完成集成了，然而，这类技术手段往往只能在一个公司的产品中使用，或者是在使用相同类型平台的场合下使用，不具备通用性。

使用 Web 服务，通过松散的应用集成，一个企业可以仅仅实现 EAI 的一个子集，即能取得实效。与之相反， EAI 要实现一个全盘的方案，来紧密的集成和联系支持公司业务的所有的系统和应用。在公司内部不同的业务系统和技术单体中可能需要花费数年的持续的努力，高投资以及为之配备的充实的资源。 Web 服务，以这样一种松散的服务捆绑集合形式 ( 也可以说是一个特别得解决方案 ) ，能够快速、低代价地开发、发布、发现和动态绑定应用。

现有的主要关注于应用集成的 EAI 解决方案将不得不因此而改变。在将来，包装好的应用程序将使用如 XML 、 SOAP 、 WSDL 和 UDDI 技术来把他们的函数或方法作为 Web 服务的界面来显示。因此， EAI 解决方案将不得不提供一个对服务集成的广泛的支持，而不仅仅是应用集成。

B2Bi 以及在线服务集成

有了 EAI 作为广泛集成的基础， B2Bi(B2B Integration) 就可以提上日程了， EAI 是 B2Bi 的基础，一般来说，只有自身企业的内部管理系统真正实现了彼此地互联，企业与企业之间的集成才是有意义的，否则，业务数据更本不可能直接流动起来，跨企业的事务也不可能被真正实施。

从技术的角度来看，同样，先 EAI 后 B2Bi 也是适合企业信息系统的发展路线的，相对而言，企业内部的应用相对企业外部的应用而言，对于企业的技术人员更为熟悉，应用新技术的难度从而较低，通过在企业内部实施 Web 服务集成，这将使企业内使用和实施 Web 服务的 IT 技术人员熟悉 Web 服务技术，当企业将来使用 Web 服务进行 B2Bi 项目的时候，将会有助于项目的有效进行。在 Intranet 内控制、管理、寻找、执行和维护 Web 服务相对来说也比通过企业防火墙在 Internet 上使用 Web 服务更为容易。进一步来说，它将帮助企业来比较和鉴别，使用标准化和相对便宜的 Web 服务解决方案相对于昂贵的传统的 EAI 解决方案到底是不是对提高企业的产出率更有帮助。

B2Bi 是为了加强企业的竞争能力而实施的项目，因此它具有以下目标：

§ 减少商务活动的开支

§ 减少进入电子商务的成本

§ 提供更加简便的用户操作工具

§ 提高数据的完整性和可访问性

§ 适当的安全和控制

§ 提供可扩展和可控制技术

§ 与现有的应用系统相集成

§ 利用开放标准

§ 全球可部署以及可维护

XML Web 服务正是符合这些目标的有力工具。在商业 Web 上，不同的公司使用着不同应用即部署平台，对于一个公司而言，其业务伙伴将会很多，如果为了和每个业务伙伴进行应用集成，使用传统的技术就必须通过交流和每个业务伙伴达成一致，并分别就通信协议、消息格式、数据模型分别进行实施，其效率显而易见地低下。而如果采用 Web 服务技术，开发人员将自身待集成的应用包装成 Web 服务，使用 WSDL 描述这些包装好的 Web 服务，并按需要将这些 Web 服务及其描述发布到 Web 服务的注册中心中取以供查询，同时所有的这些工作都可以使用支持规范的工具来完成。此时，企业之间的集成就转变为 Web 服务的对接，开发人员可以通过 UDDI API 来查询 Web 服务的注册中心或者与业务伙伴的技术人员进行交流，获取对方的 Web 服务的 WSDL 描述文档，然后通过平台工具自动将 WSDL 描述文档装载到自己的开发平台中，并生成相应的接口，同时开发人员可以使用 XML Schema 的工具快速地理解应用交互需要使