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的工具快速地理解应用交互需要使用的数据结构，然后在自己的应用中引入刚刚使用平台工具生成的调用接口和数据结构，使用SOAP技术与对方的Web服务进行交互，从而完成B2B应用集成。

B2B集成这个概念可以延伸入所有在线服务的彼此集成，比如企业自己的系统就能够和公共的金融服务、海关服务、第三方物流服务、网上商店等等连接在一起，将原来需要依靠纸张的联系转换成电子的方式，并且，其系统的实施仍然能够使企业只要维护一个技术团队：”Web Services Enabling”的技术团队。

 

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

在企业应用领域之外，个人应用领域同样是一个非常大的应用领域，同时其形成的影响力是有过之而无不及的。在过去，以Web为服务的桌面应用已经有了相当的应用，比如：

§         大家使用的非常频繁的即时讯息软件，包括MSN Messenger、Yahoo! Messenger、ICQ、OICQ等，它们以部署在Web上的讯息服务器为后台服务，完成不同终端之间的消息互通。

§         股市行情软件客户端，代表性的有证券之星等，他们依靠不断地从在线行情服务器上同步下载行情数据以提供服务。

§         理财软件，比如Microsoft的Money 2002，以及基本可以通过所有的美国的银行的在线服务获得个人的帐目数据。

对于这些应用而言，提供服务的实体与使用服务的实体要么是一家公司(前两者)，要么是一对一的签署协议，构建一对一连接协议(后者)，虽然从模式上，这已经是“Web服务”应用模式了，然而，其中的那些“Web服务”都是非开放的，除自己的客户端，或私下达成协议的客户端应用外，其他桌面应用是无法使用这些服务的。

即使，有些桌面应用的开发人员通过反向工程获取了某些服务的使用方式，由于那些服务是非开放的，一旦那些服务的接口有所改变(大多并非恶意的)，那么桌面应用的代码就不得不进行相应的升级。

然而，如果那些在线服务都使用Web服务技术进行重新包装之后，对于桌面应用的开发而言，其中的一种开发模式就如同我们前面在EAI集成中提到的那样，需要将描述Web服务的WSDL文档装载入开发环境，然后生成调用接口，并集成入代码。在运行时，Web服务的接口是有可能改变的，当接口改变后，Web服务调用失败，此时，桌面应用应当有能力再一次获取WSDL文档，重新生成调用接口，并与代码进行绑定。也就是说，Web服务技术赋予了应用动态绑定的能力，而不象以前仅仅具备静态绑定的能力。此外，桌面应用还可以选择去查询Web服务的注册中心(比如UDDI Business Registry)，获取其需要的Web服务，然后分别一一动态绑定，并实施调用。当这些技术特性被应用到我们先前讨论的几个应用中，我们就会发现：

§         大家可以使用单一的即时讯息软件，该软件可以联入MSN Messenger Service、Yahoo! Messenger Service、ICQ Service等等，用户只需要使用一个客户端，就可以和任意的即时讯息终端进行消息互通。

§         很多股市分析软件都可以在线使用股市行情服务的数据更新服务，将数据下载到本地后实施分析，用户的选择顿时增加了很多，同时软件开发商的分工也更明确了。

§         理财软件能够动态地去搜索UDDI注册中心，获取所有银行的在线查账服务，从而为用户提供更为即时的服务。

 

我们的机遇

我们知道，Web服务技术仍是一个新兴的发展中的技术，然而无数迹象表明，Web服务将是未来应用架构的一个极为重要的模式。先入才有优势，如何看好这个方向，没有什么理由让它闲置在一边，拱手让给国外的企业慢慢进入并轻而易举地夺取中国的市场。对于目前中国的现状而言，在Web服务领域，有这样一些机遇在等待着我们：

1.      Web服务开发商，Web服务技术提供商。随着Web服务的深入人心，会有越来越多的应用采用Web服务架构，开发Web服务的需求将不断增加，中国背景的应用需要由本地的公司参与，完全依靠国外大公司是无法满足本土化的需求的。

2.      大型企业EAI/B2Bi的Web服务实践。对于大型企业而言，与海外供应商、销售商的业务关系的保持和良性发展是不可回避的问题，虽然在国内的商务环境里，B2B是否会成功仍然有待考证，然而在国际领域，不进行B2B集成就无法直面竞争，甚至可以说你不加入B2B集成环境，就没有参与国际商业活动的准许证。

3.      公共Web应用的Web服务改造。对于很多有一定使用率但使用率有限的Web应用，可以考虑进行Web服务包装，同时开放给软件开发者使用，通过桌面软件交付给用户使用。可以考虑用户向桌面软件提供商购买软件、桌面软件提供商向服务提供商按服务使用率交纳费用这样的模式。

当然，除了这些，还有很多其他的机遇，想想PC刚出现的时候，想想Internet刚出现的时候，新的模式尽在默默地孕育中。

 

当前的努力

为了使Web服务能真正体现它所承诺的语言无关、平台无关、协议无关的互操作性，使得两大Web服务应用平台.NET和J2EE能够无缝地完成应用集成。2002年2月，以IBM、Microsoft为首的一些业界巨头成立了WS-I.org(Web Services Interoperability Organization)，专注于建立能完全消除影响互操作性的平台差异的机制，为Web服务规范的实现提供各种样例和范本，使得开发人员消除对规范理解的二义性的存在，为Web服务的互操作性奠定扎实的基础。此外，UDDI.org、W3C.org的各个工作组都在紧锣密鼓地进行规范的开发，各大技术提供商都在按照规范不停地在自己的主流平台上增加相应的Web服务支持。围绕着Web服务，大家都在努力地争取抢得先机，争取在Web服务领域领先一步，在发展中占据有利的位置。我们相信，Web服务的春天正在来临。