技术刨析：传统应用与Web服务的接口

申请免费试用、咨询电话：400-8352-114

技术刨析：传统应用与Web服务的接口

Web应用的不断发展，使人们发现在Web应用和传统桌面应用(比如企业内部管理系统、办公自动化系统等)之间存在着连接的鸿沟。他们不得不重复地将数据从Web应用迁移到传统桌面应用，又从传统桌面应用将数据迁移到Web应用。这成为阻碍Web应用进入主流工作流的一个巨大障碍。

Internet的发展，以及基于Internet的B2B电子商务的不断发展，为各种类型的商业实体提供了发现新客户、供应流、新服务的各种机会，体现了Internet巨大的价值。但是，在B2B的高速发展中，有一个主要的屏障阻碍了电子商务向开放的全球一体化的贸易模式发展。

目前，大多数电子商务的应用与基于Web的商业服务在处理购买者、供应商、交易市场和服务提供者的联系方式上各不相同。如何将这些应用方便、低代价地连接在一起，从而实现大范围的、跨企业实体的商务应用系统对接，这是摆在开发人员面前的一大问题。不同的应用(尤其是不同企业的)使用的开发语言不同，部署的平台不同，通讯协议和对外交换的数据格式也有差异。如何解决语言差异、平台差异、协议差异和数据差异带来的高代价系统集成是这个问题的关键。

从1998年开始发展的XML及其相关技术，被证明有可能解决以上这个问题。近期开始蓬勃发展的Web服务技术(Web Services Technology)正是基于XML技术、针对这一问题的最佳解决方案。XML Web服务是当今IT业界关注的焦点。Web服务技术主要目标就是在现有各种平台基础上构筑一个通用的平台无关、语言无关的技术层，各种不同平台之上的应用依靠这个技术层来实施彼此的连接和集成。如果需要用一句话来概括Web服务技术与传统Web应用技术的差异的话，就是传统Web应用技术解决的问题是如何让人来使用Web应用提供的服务，而Web服务技术则要解决如何让计算机系统使用Web应用所提供的服务。我们知道，在PC的软件系统中除桌面应用外，还有很多底层的Service(可以参照Windows NT/2000中的对应概念)为应用提供基础服务。Web服务同样也可以看成是为应用提供基础服务，不同点在于可以被自由地部署在Internet上，使用Web服务技术实施访问。

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

Web服务技术带动了现代计算机技术的革命。

商业需求驱动Web服务

现在，电子商务发展的重心已经从过去的.COM的模式，转到传统企业电子商务化进程中来。既然是企业的电子商务化，模式是否崭新是次要的，能否为企业带来经济利益是主要的。在规划企业电子商务应用的时候，企业管理人员和系统架构师更多关注的是该电子商务应用是否能为企业带来直接的经济收益、是否有利于削减某方面的开支、是否能够优化资源使用等，这些都是由企业的商业利益驱动的。在这一轮的电子商务发展中，技术完全是为商业服务的，任何脱离商业需求的“新”技术必然是毫无用武之地。

系统架构师们广泛考证，在对企业运作机制经过务实的调研后，总结出了7种当前最有价值进行实施的电子商务应用，它们是：

1. 企业门户(Portal)；

2. 网上连锁商店(Storefront)；

3. 集团内联网(Intranet)与知识库(Knowledge Base)；

4. 供应链(Supply Chain)管理；

5. 客户服务(Customer Service)；

6. 分销(Distribution)管理；

7. 提供ASP(Application Service Provider)服务。

为了实施这些电子商务应用，不外乎采用下面几种手段：由自己的IT部门具体计划并实施；外包给软件公司或解决方案提供商计划并实施，当然解决方案或实施计划中可能会包含平台软件或专用软件模块的采购。然而，无论自身的IT部门还是外包的解决方案提供商，给出的实施计划都应该是正式运营前的。一旦应用被部署后，由于商务环境和商务需求的改进和不断变化，这些电子商务应用不可避免地需要被修订和更新，以符合新的电子商务流程。而到最后，企业的管理人员甚至会想为企业的员工、客户及合作伙伴分别定制具体应用，以获得最大的商业利益，并保持竞争力。

在这些应用更新中，下面三个可能是最主要的、也是最常发生的：

1. 增加新的电子商务应用，这常常会每几个星期或每几个月发生一次；

2. 对电子商务的流程进行更改，这常常每周或每几天发生一次；

3. 应用户的需求进行更改，甚至每个小时都会发生，尤其是当需要为每个客户、每个合作伙伴或每个企业员工都定制首选的电子商务应用的时候。

经常的应用更新是当今电子商务应用部署所面临的最大问题。如何提升企业的响应能力，削减响应开支，提升企业的竞争力，是所有的信息化企业必须面对的问题。

复杂系统对接是不妥的解决方案

为了达到保持企业核心竞争力的目的，大部分企业在IT上投入了极多的资金和资源，那么他们的选择是否正确呢？在商务上无疑是正确的。“没有电子商务将等于无商可务”，可是他们采取的方法正确吗？

首先让我们来看一看目前大多数企业是如何操作的。

目前，在构建电子商务应用的时候，程序员们一般都是采用“独立解决方案”来实施的。也就是说，对于每个应用都是为需要的企业资源或外部资源编写连接代码，使应用得以运行。这些资源包括：传统系统(Legacy Systems)、数据库、Web应用及Web资源，以及正在不断涌现的Web服务。

程序员还需要编写更多的代码，使大量的用户能够访问每个应用。例如通过公司的Web站点，使用公司内部的桌面应用程序等等。由于这些应用都是“辛苦”编程的产物，几乎很难再定制。当需要融入新的电子商务流程时，需要为额外的用户群提供访问界面，需要继承不同的电子商务应用，为用户提供更完整的增值服务。所有的这一切，都不得不从最初的系统设计开始做起。因为所有的应用都是从一次性开发的角度实施的，应用的每一个更改都需要由特定的程序员来完成。这样，通过跨应用集成的方式实现电子商务应用的重用变得异常困难。

由于每个应用都有其自己特有的基础架构，这些应用在部署、更改和维护上的代价都异常高昂。企业不得不为每套应用配置特有的专业技术人员，并保持与不同技术供应商或解决方案供应商的密切联系。这些应用既不能方便地继承，也不能随着企业商务的规模扩展而方便地实现应用的规模扩展。

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

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

第一个应用，企业的为之付出的总的费用应该是该应用开发和部署费用，以及运营时态的维护和更新费用。

第二个应用，应用的开发和部署费用是一样的，但是企业需要为之花费额外的集成费用，同时由于整个企业应用环境变得更加复杂，运营时态的维护和更新费用可能呈指数形式增加。

同样，当第三个、第四个应用被部署后，企业所支出的费用可能是高得惊人。

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

早先出现的电子商务技术，比如EDI、Web EDI (也许是基于XML的)、内容服务器、应用服务器、EAI(Enterprise Application Integration)，以及那些为创建企业门户和其它单个电子商务应用(上面提到的7种应用)而设计的独立解决方案，都无法解决这个问题。之所以无能为力，是因为它们都是基于复杂应用连接的，不具备良好集成能力的应用开发模式，它们都是通过程序代码实现复杂应用连接、电子商务应用及其它信息系统的。这样的实现方式既无法有效地解决经常发生的因电子商务流程的更改而触发的大额费用，也无法有效地解决各类用户的定制需求。

Web服务和商业Web

电子商务需要摆脱独立解决方案的实现模式，需要舍弃复杂系统连接的实现方法。一个有效的电子商务应用不应该是仅仅基于程序员和那些复杂的代码的。对于电子商务而言，传统的由程序员主导的、由里向外的开发模式，应当被由用户主导的、由外向里的开发模式取代。冗长的、串行开发循环，应当被即时的、快速的应用装配所取代，并且这样的应用应具备较高的可定制性。

基于XML技术的Web服务正是解决这一问题的最佳手段。Web服务的使用，将改变目前的开发模式和应用部署的费用规模。各种Web服务分别实现了一定的电子商务功能，将各种电子商务的Web服务进行组合和集成，以创建动态电子商务应用。Web服务能够统一封装信息、行为、数据表现，以及商务流程，而无需考虑应用所在的环境使用何种系统和设备。

使用Web服务，企业能够通过抽象和混合将自身的电子商务组件化。当一个企业的核心竞争力被组件化之后，这些核心竞争力就能够很方便地在不同的企业之间共享，同时架构跨企业的电子商务应用，形成商务Web。

在商务Web中，不需要因为使用电子商务应用而购买所承载的应用软件。Web服务是一种无需购买并部署的组件，这种组件是被一次部署到Internet中，然后到处可用的一种新型组件，所有应用只需要能够连入Internet，就可以使用和集成Web服务。采用Web服务开发的代价显著降低了，程序员无需与多种平台进行交互，只需要与一种组件进行交互，即Web服务。Web服务的调用界面完全采用标准的XML及相关技术，代码实现上的代价也显著下降。采用Web服务部署和集成的费用大大降低，流程也无需更改大量代码，甚至通过工具支持根本无需更改程序代码。随着新的Web服务技术，如WSDL/UDDI/WSFL的大量使用，Web服务在运行时态进行动态装配将成为现实，甚至可以应用户的需要实时装配。

Web服务技术

Web服务是一种部署在Web上的对象(Web Object)，因此具有对象技术承诺的所有优点。Web服务的基石是以XML为主的开放Web服务技术，因此具有比任何现有的对象技术更好的开放性。

Web对象

从外部的使用者的角度而言，Web服务是一种部署在Web上的对象/组件，它具备以下特征：

1. 完好的封装性。Web服务既然是一种部署在Web上的对象，自然具备对象的良好封装性。对于使用者而言，它能且仅能看到该对象提供的功能列表。

2. 松散耦合。这一特征也是源于对象/组件技术，当一个Web服务的实现发生变更的时候，调用者是不会感到这一点的。对于调用者来说，只要Web服务的调用界面不变，它的实现任何变更都是透明的，甚至当Web服务的实现平台从J2EE迁移到了.NET，或者是相反的迁移流程，用户都可以对此一无所知。

从前，分布式的应用程序逻辑需要使用分布式的对象模型，诸如：微软的分布式组件对象模型(DCOM)、对象管理集团的公用对象请求代理程序体系结构(CORBA)或Sun的远程方法调用(RMI)。通过使用这种基本结构，开发人员仍可拥有使用本地模型所提供的丰富资源和精确性，并可将服务置于远程系统中。这些系统有一个共同的缺陷，就是它们无法扩展到互联网上。它们要求服务客户端与系统提供的服务之间必须紧密耦合，即要求一个同类基本结构。这样的系统往往十分脆弱，如果一端的执行机制发生变化，那么另一端便会崩溃。例如，如果服务器应用程序的接口发生更改，那么客户端便会崩溃。

对于松散耦合而言，尤其是在Internet环境下的Web服务，需要有一种适合Internet环境的消息交换协议。XML/SOAP正是目前最为适合的消息交换协议。

3. 使用协约的规范性。这一特征从对象而来，但相比一般对象其界面规范更加规范化，也易于机器理解。首先，作为Web服务，对象界面所提供的功能应当使用标准的描述语言来描述(比如WSDL)。其次，由标准描述语言描述的服务界面应当是能够被发现的，因此这一描述文档需要被存储在私有的或公共的注册库里面。同时，使用标准描述语言描述的使用协约不仅仅是服务界面，还被延伸到Web服务的聚合、跨Web服务的事务和工作流等。这些又都需要服务质量(QoS)的保障。再次，我们知道安全机制对于松散耦合的对象环境的重要性，因此需要对诸如授权认证、数据完整性(比如签名机制)、消息源认证及事务的不可否认性等，运用规范的方法来描述、传输和交换。最后，在所有层次的处理都应当是可管理的，因此需要对管理协约运用同样的机制。

4. 使用标准协议规范。作为Web服务，其所有公共的协约完全需要使用开放的标准协议进行描述、传输和交换。这些标准协议具有完全免费的规范，以便由任意方进行实现。一般而言，绝大多数规范将W3C或OASIS作为最终版本的发布方和维护方。

5. 高度可集成能力。由于Web服务采取简单的、易理解的标准Web协议作为组件界面描述和协同描述规范，完全屏蔽了不同软件平台的差异，因此无论是CORBA、DCOM，还是EJB都可以通过这一种标准的协议进行互操作，实现在当前环境下最高的可集成性。

Web Services “Stack”

前面，我们已经简单地介绍了为了完成在松散耦合的环境下的对象访问，以及在基本对象访问之上的诸如事务、工作流、安全机制等。实现一个完整的Web服务体系需要有一系列的协议规范来支撑。

图1展示了整个Web服务技术体系Web Services“Stack”。其中，底部两层的是先前已经定义好的并且广泛使用的传输层和网络层的标准IP、HTTP、SMTP等。中间部分是目前开发的Web服务的相关标准协议，包括服务调用协议SOAP、服务描述协议WSDL和服务发现协议UDDI、WS-Inspection，以及服务工作流描述语言WSFL、Web服务的安全协议和路由协议等。右边部分是各个协议层的公用机制，这些机制一般由外部的正交机制来完成。

　　图1 Web服务技术体系

从以上这个技术层次图可以看到，Web服务追求的第一目标是简单性。

首先，这些协议本身都是简单的，无论是HTTP、FTP等传统的TCP/IP系统的网络协议，还是SOAP、WSDL、UDDI、WSFL等基于XML的协议，设计原则中的一个重点就是力求简单性。相信大家如果对XML、SOAP等有深入了解的话，一定会深深体会这一点。

其次，一个可以使用的Web服务应当按照需要选用若干层次的功能，无需所有的特性。比如在目前状况下，一个简单应用可能只要使用WSDL/SOAP就可以架构一个符合规范的Web服务了。

最后，所有的机制完全是基于现有的技术，并没有创造一个完全的新体系。无论是HTTP、FTP等现有的网络协议，还是SOAP、WSDL等基于XML而定义的协议都是遵循继承原有的被广泛接受的技术，这样才能使得Web服务被广泛接受。

Web服务体系架构

Web服务技术是为在Internet环境下，松散耦合的Web服务之间互相调用、互相集成而设计的技术框架。以XML/SOAP/WSDL/UDDI为主干的Web服务技术，赋予了Web服务一个与传统对象调用技术相似但又不太相同的体系架构。

在讨论体系架构之前，我们先弄清楚两个概念，即Web Services和Web Service。从英文字面上来看，两个术语没有什么差别，一个是复数，一个是单数。然而在Web服务的专业领域，Web Services是指整个架构Web服务的技术框架，比如包括XML/SOAP/WSDL/UDDI等。而Web Service是指使用Web Services构架出来的Web服务实例。本文中，Web Services对应的中文名称是Web服务技术，Web Service则翻译为Web服务。

对于Web服务而言，其标准的、或者说是典型的体系架构应当如图2所示。

　　图2 体系架构

在Web服务的体系架构里，有服务提供者、服务注册中心和服务请求者三个角色。服务提供者是提供最终Web服务的供应商，它实现了一个Web服务，并放置在在线服务器上，供别人使用。服务注册中心是Web服务的注册地，汇集了很多在线的Web服务。一般来说服务提供者将Web服务安置到在线服务器之后，会将Web服务发布到服务注册中心中去，从而使得服务注册中心中包含了越来越多的Web服务的技术信息。

对于想要使用Web服务的服务请求者来说，一般首先去查询服务注册中心，尝试在服务注册中心中寻找所需要的Web服务。当发现了合适的Web服务之后，将从服务注册中心获取这些Web服务的技术信息引用，通过这些引用找到真正的Web服务及其相关的技术信息，从而完成服务请求者和服务提供者之间的技术绑定。

对于这三个角色之间任意两者的交互，使用的都是Web服务的交互方式(服务注册中心也是以Web服务的形式来运行的)。一般来说，可以使用SOAP。这些被调用的Web服务，其调用界面都是使用WSDL来描述的。

Web服务和EAI

问题再一次回到电子商务应用的集成上。根本是企业内部的EAI(Enterprise Application Integration)与企业之间的B2Bi(B2B Integration)，EAI是两者中的基础。

Web服务提供了一个分布式的计算技术，在Internet或者Intranet上通过使用标准的XML协议和信息格式来展现商业应用服务。使用标准的XML协议，使得Web服务平台、语言和发布者能够互相独立。这是EAI解决方案的一个理想的候选者。

通过开放的Internet标准，Web服务描述语言(WSDL，用于服务描述)统一描述、发现和集成规范(UDDI，用于服务的发布和集成)、简单对象访问协议(SOAP，用于服务调用)和Web服务流语言(WSFL，用来定义工作流，这尚不是一个W3C标准)，Web服务消除了现存解决方案(如CORBA和DCOM)中的互用性问题。

Web服务不是EAI，或者只是EAI的一部分，它是另外一个技术。Web服务能够使EAI成为真正可能的和便捷实施的、同时又引人注目的解决方案。Web服务能彻底地改变传统的EAI中点对点的集成处理方式。

使用Web服务，通过松散的应用集成，一个企业仅仅实现EAI的一个子集即能取得实效。与之相反，EAI实现一个全盘的方案，要紧密地集成和联系支持公司业务的所有系统和应用。在公司内部不同的业务系统和技术单体中，可能需要花费数年的持续努力。

Web服务以一种松散的服务捆绑集合形式(也可以说是一个特别得解决方案)，快速、低代价地开发、发布、发现和动态绑定应用。就当代Web服务的技术发展水平来看，Web服务可以实现应用程序之间的函数或方法级的集成。它们不是自然的基于事务的，仅提供了基本的“请求/响应”功能。在下一代的Web服务中，在功能上和技术上都会更先进，将会提供用户接口封装和安全性，它们将能够包装一个应用程序，并且把它嵌入到其它的应用程序中去。

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

传统EAI解决方案和Web服务之间的显著的不同

下面是传统的EAI解决方案和Web服务之间的一些基本不同点。

注意：有一些不同点所描述的Web服务可能并非是Web服务目前有的特性，而是考虑了Web服务被提议的未来的改进。

1. 简单性，相比于典型的EAI解决方案(也许包括分布式技术如DCOM和CORBA)，Web服务更便于设计、开发、维护和使用。既然开发和使用Web服务的平台框架已经准备好了，创建跨越多个应用程序的商务流程处理将变得相对简单。

2. 开放标准，不像有所有权的EAI解决方案，Web服务是基于开放标准诸如UDDI、SOAP、HTTP的。这个可能是导致Web服务被广泛接受的最重要的因素。事实上，现存的开放标准消除了企业为了支持新出现的Web技术投资的需要。

3. 灵活性，既然EAI解决方案需要点对点集成，一端的改变必须告知另外一端，这自然使集成变得非常的生硬，同时也浪费开发人员的时间。基于Web服务的集成是非常灵活的，因为它是建立在发布服务的应用程序和使用服务的应用程序之间的松散耦合。

4. 便宜，EAI解决方案，诸如消息中介实施是非常昂贵的。而Web服务的实施则便宜而快速。

5. 范围，EAI解决方案诸如消息中介，把应用程序作为一个单个的实体来集成。然而Web服务允许企业把大的应用划分为小的独立逻辑实体，并且进行包装。举例来说，企业可以为一个ERP应用的不同的商业组件进行包装，如订单管理、接受购买订单、订单情况、订单确认、账户接受、账户支付等等。

6. 高效性，已在前面几点提到的Web服务允许应用程序划分为一些小的逻辑组件。因为在小粒度基础上集成应用程序，集成将变得更容易。这也使Web服务的EAI解决方案比传统的EAI解决方案更有效率。

7. 动态，Web服务通过提供动态的服务接口来实施一个动态的集成。在传统的EAI解决方案里都是静态处理的。

Web服务的EAI示例

图3展示了在一个在企业内使用Web服务的例子。在这个例子中，应用服务器中运行的企业门户从多个内部应用集成信息，并提供一个跨越这些应用的业务处理的入口点。企业门户应用通过内部应用程序，使用私有UDDI注册中心(Private UDDI Registry)来获得可提供的Web服务的技术信息，并且在Intranet上调用这些服务。一些经常被调用的Web服务的绑定信息将被企业门户应用缓存，这样得以避免花费在动态绑定上的资源和时间。在这个例子里面，Web服务把企业门户和CRM、ERP应用程序松散地集成在一起。

　　图3 企业应用Web服务的流程图

流程步骤如下：

1. 登录企业门户之后，用户发出请求信息；

2. 支持企业门户框架的应用程序，通过浏览私有UDDI注册中心获得关于CRM和ERP应用的Web服务的技术；

3. Web服务的位置和WSDL绑定信息被传送给应用服务器；

4. 应用程序调用CRM应用发布的Web服务得到个人的信息，如名字、身份证号码、地址及用户的Email，这个通讯过程是基于SOAP交互的；

5. 应用程序调用ERP应用发布的Web服务获得银行账号信息，诸如银行帐号号码、结余和用户交易历史记录，这个通讯过程也是基于SOAP交互的；

6. 信息被格式化后，发给起初的调用用户。

从哪里开始

如果企业在内部应用程序中使用Web服务来实施应用集成中的项目，应当从函数、应用程序接口(API)，或者远端过程调用(RPC)级别开始这一进程。这将使企业内使用和实施Web服务的IT技术人员熟悉Web服务技术。当企业将来使用Web服务进行外部集成(B2B集成)项目时，有助于项目的有效进行。在Intranet内控制、管理、寻找、执行和维护Web服务，相对来说比通过企业防火墙在Internet上使用Web服务更为容易。进一步来说，它将帮助企业进行比较和鉴别使用标准化和相对便宜的Web服务解决方案相对于昂贵的传统的EAI解决方案哪个对提高企业的产出率更有帮助。

然而，要求企业抛弃现存的EAI底层架构，并且盲目地转向开发基于Web服务的解决方案来替代它是不太现实的。企业不会停止使用提供完整事务服务的EAI中间件框架。在使用Web服务的场所，不是替代(现在还不是)，而是应该使用Web服务来支撑现存的下层结构。

经过一段时间，Web服务将逐渐的由一个EAI解决方案进化为一个B2BI(B2B Intergration)解决方案。