基于Ｗｅｂ Ｓｅｒｖｉｃｅ的企业应用集成构架模型研究

顾键萍

【摘要】文章针对传统企业应用系统集成（EAI）方案局限于特定平台和协议以及紧密耦合的缺陷，提出了基于web service服务的企业应用系统集成设计方案，给出了方案的实施步骤，并在此基础上讨论了基于Web Service的企业内集成应用的整体架构模型和模型在企业内的典型应用。

【关键词】EAI； Web service； 集成模型

【中图分类号】 TP311 【文献标识码】A

【文章编号】1674-1145（2008）02-0096-04

随着现代通信技术、计算机网络技术和企业信息化的飞速发展，企业使用的软件，如企业资源计划(ERP)、办公自动化(OA)、客户关系管理(CRM)等应用系统也越来越多。这些应用系统都是根据当时的业务需求而建设的，它们分别归属为企业不同部门所使用，虽然这些应用系统各有侧重点，但它们之间也包含着重复的信息和数据。可是，由于这些应用系统相互独立运行，使得它们之间无法进行信息的交流和共享，导致了众多的信息被封闭在相互独立的应用系统中，这些应用系统之间信息孤立，业务流程被割裂，数据冗余、不一致以及流程不畅。“信息孤岛”中的各个系统尽管在一定时期内可能提高了个别部门或部门内个别业务环节的工作质量和效率。然而，由于“信息孤岛”的上述影响，不少企业虽然投入了相当数量的资金，甚至在信息化建设上经过了多年的坚持不懈地努力，最终却并未得到企业整体管理效率的提高和企业管理整体优化的效果，长此以往，这种状况不仅会严重阻碍企业信息化进程，而且还会产生使企业逐渐丧失信息化信心等极为深远的负面影响[1]。因此如何有效地发挥出这些应用系统的整体优势，研究一种既能集成遗留应用，保护前期投资；又能无缝集成未来应用，避免重复投资的集成模式对企业来说至关重要。

企业应用集成（EAI: Enterprise Application Integration）正是在这样的背景下应需而生。EAI是指对企业中完成不同业务功能的应用系统进行集成，在它们之间建立起可供数据交流和应用沟通的纽带，进而使他们之间的信息交互成为可能。通过这种方式使用户可以访问企业的整体信息，而不必考虑这些具体信息到底是属于哪一个应用系统的，即各个不同应用系统对用户来说是透明的。[2]

一、传统企业应用系统集成

传统的企业应用集成方法主要有两种，点到点（Point-to-Point)的集成和基于企业消息总线或中间件的集成。点到点的方式属于硬编码的方式，在集成应用时工作量较大、开放性不好，且随着待集成的应用的增加，集成的复杂度急剧上升。基于中间件的集成如CORBA、DCOM等之间的互操作，他们的方法都是先建一个集成平台，然后开发各种各样的适配器和连接器(Adapter & connector)去连接已有的应用系统。用适配器来进行信息的有效收集、现有集成平台与原有平台的信息转发[3]。而这种情况下，应用程序和消息总线之间的连通性是用私有总线API和应用程序API来实现的。这种集成本质上仍然是点对点的集成，不仅有失灵活，而且容易受制于传统分布式对象中间件技术存在的局限性，该集成实现成本太高、实现过程复杂且无法通用。传统方法的根本问题都是客户端与服务端之间耦合过于紧密。这种紧耦合的集成方式将影响系统的灵活性和扩展性，阻碍业务的流程调整和优化，不利于企业业务发展。

因此，企业间应用集成客观上迫切需要一种有效的、新的集成方法来克服传统的企业应用集成的缺点。如何选择新的集成方法和技术平台是我们必须考虑的重要问题之一。为此，笔者提出了面向服务的基于Web Service的企业应用集成构架方案。

二、基于Web Service的企业应用集成模式构架方案

Web Services是建立在开放标准和独立于平台的协议基础之上的分布计算单元。在新一代的Web Service中，在功能和技术上都会更先进，将会提供用户接口封装和安全性，它们将能够包装一个应用程序并且把它嵌入到其他的应用程序中去[4]。

基于Web服务实现企业应用系统的集成，它是以Web服务接口的形式将各种应用程序和信息系统进行封装、组合和集成作为服务提供者。Web服务能够统一地封装信息、行为、数据以及业务流程，把应用程序改变成可重用的和柔性的组件。企业的核心业务功能用Web服务封装成组件后，可以很方便地在企业之间共享。基于Web服务的组件被一次性地部署在UDDI中，所有连入网络的服务消费者(应用程序)就可以随时调用和集成这些Web服务[5]。针对现有应用集成方案局限与特定平台和协议以及紧密祸合的缺陷等特点，通过对Web Service基础技术和对企业应用环境的的深入研究，本文提出了以下基于Web Service的企业应用集成的整体架构。其体系结构见图1：

图1基于Web Service的EAI整体构架模型

该方案主要由两部分组成，包括应用集成模型和UDDI Registry。其中，应用集成模型尽可能地利用现有的软件投资和保持原有软件系统的运行，在原有系统的基础上构造一层统一的应用服务层，该应用服务层对外以Web Service的方式提供服务。企业内部以及企业间应用系统的通信都是通过SOAP实现，SOAP的作用是作为消息的载体，实现分布式对象访问和应用系统之间的调用。UDDI Registry提供了一种让客户端动态发布和查找Web service的机制。通过UDDI Registry所提供的标准接口，企业可以发布自己的Web service供其它企业查询、调用;也可以查询特定服务的描述信息，并动态绑定到该服务上。通过服务的定义、发布、查询、绑定、调用等机制，实现了一种松散祸合的应用集成框架，从而克服了现有的应用集成方案紧密祸合，互操作性差的缺点。本方案可以将企业已有的分散的、独立的应用系统和新开发的应用系统组成一个有机的整体，完成更多的功能，以实现企业自动化、商务流程的整合或B2B电子商务，达到使原有系统增值的目的，而又无需对原有系统做大的改动。

（一）应用集成模型

基于Web service的应用集成方案主要由两部分组成，包括应用集成模型和UDDI Registry。采用分层的设计思想，应用集成模型如图2所示：

图2企业应用含有成模型

模型共分为四层，分别是客户层、Web service层、业务逻辑层和数据层。各层的功能划分如下:

1．客户层。与传统的B/S，C/S结构类似，客户层的主要作用是将应用产生的结果信息显示给用户。由于Web浏览器的广泛应用，所以采用以浏览器为主的客户端界面，其它企业的服务器或者应用程序也可以作为此模型的客户端，实现企业之间的数据交换。

2．Web service层。Web service层是模型的一个主要层次，主要由SOAP处理器和Web服务器组成。Web服务器的主要功能是提供交互式Web页面，并负责将来自上一层的请求转发给SOAP处理器，通过HTTP与客户端和SOAP处理器进行通信。

与一般分层结构的系统不同的是，在该层次上添加了一个界面转换器，这是由XML数据与表现分离的特性决定的。转换器负责将各种非标准的XML数据转换成标准的XML数据或者是完成遵守不同XML Schema的XML数据转换。简单的界面转换器可以用XSLT(Exensible Style Sheet Language Transformation)与CSS(cascading style Sheet，级联样式表)来实现，复杂的界面转换器可以用各种编程语言并结合DOM或者SAX有选择地来进行实现如图3：

图3 界面转换器

界面转换器(GUI Translator SOAP处理器)可以产生SOAP请求消息并通过HTTP发送到服务器端，也可以接收客户端的SOAP请求消息，并对其做出适当的响应。

SOAP处理器可以产生SOAP请求消息并通过HTTP发送到服务器端，也可以接收客户端的SOAP请求消息，并对其做出适当的响应。SOAP处理器包括三个部分:服务管理器(负责根据请求管理服务)；被部署服务的列表(SOAP处理器托管的所有服务的列表)；XML转换器。SOAP处理器的的结构如图4所示：

图4 SOAP处理器结构

当SOAP处理器收到Web服务器转发来的SOAP请求消息时，将消息交给服务管理器。服务管理器检查被部署服务的列表，查找在SOAP消息中所需的服务。若没有查找到所请求的服务，它将请求失败返回给Web服务器。若此项服务可以提供，控制权由服务管理器转移给XML转换器。XML转换器负责将SOAP请求的XML结构转换成实现实际服务的编程语言的结构。实际的服务是由业务逻辑层的业务逻辑组件实现的，例如COM，EJB等。XML转换器负责将XML结构转换成本地的组件调用。当XML转换器调用了本地组件的某个方法时，这个方法就会完成它的工作并且将结果信息返回XML转换器。XML转换器将结果转换成SOAP响应消息，由服务管理器将消息发送到Web服务器。

另一方面，用户的应用程序向SOAP处理器发送请求操作的消息，SOAP处理器处理这个请求，XML转换器将所调用的方法和参数格式化成一个SOAP消息，服务管理器把它发送给WSDL文档中说明的Web service所在的UDDI。等待服务器端返回的SOAP响应消息，解析得到返回值。

3．业务逻辑层。业务逻辑层主要由其中部署的业务逻辑组件构成，包括己有的业务逻辑组件和新开发的业务逻辑组件。该层的主要功能是将企业已有的业务逻辑和处理过程以组件的形式提供，这样不仅可以提高系统的可重用性、可维护性和分布系统的计算负荷，也有利于实现与其它系统的集成或整合。该层中所部署的组件的业务逻辑或处理过程一般是整个应用系统中关键的、核心的应用逻辑或处理过程。组件封装业务逻辑和业务数据，主要关心它的某个方法被调用时应该处理的业务；组件的调用则是由上一层来实现的。

4．数据层。数据层主要包含企业的应用系统和各种数据库系统。企业应用系统包括遗留系统、定制系统、新加入的应用系统等等。这些应用系统和它们所依靠的形形色色的数据库系统，由于包含了大量的历史数据，往往具有十分重要的价值。数据层主要完成对数据的存取、更新、检索、修改，维护数据的安全性、完整性、一致性等工作。基于Web service的应用集成方案中，数据库不再和每个活动客户保持一个连接，而是若千个客户通过业务逻辑组件共享数据库的连接。

（二）UDDI Registry

UDDI Registry是所有提供UDDI注册服务的站点的通称。它存储了商业实体的信息以及它们所提供的Web service的相关技术调用界面。通过使用UDDI的发布服务，企业可以单独注册那些希望被别的企业发现的自身提供的Web service。企业可以通过UDDI Registry的Web界面，或使用实现了“UDDI Programmer，5API规范”描述的编程接口的工具，将信息加入到UDDI Registry或者从UDDI Registry查询所需要的Web service的描述文档。从UDDI Registry进行信息查询无需身份认证；而在UDDI Registry上进行信息发布则必须是发布该UDDI Registry自身的用户方能实施，同时以后的更新、删除都必须通过这个Registry，并使用初始发布时使用的用户进行权限认证。

UDDI Registry分为Public UDDI Registry (公共UDDI注册中心)和Private UDDI Registry (私有UDDI注册中心)[6]。Public UDDI Registry是面向全球使用的UDDI注册服务，它是一个逻辑上的统一体，在物理上是以分布式系统的架构实施的，而不同站点之间是采用P2P(对等网络)架构实施，相互之间按一定规则进行数据同步，因此访问其中任意一个站点就基本等于访问了UDDI Registry。当一个企业在UDDI Registry的一个实例中实施注册后，其注册信息会被自动复制到其它UDDI节点，于是就能被任何希望发现这些Web service的人所发现。Private UDDI Registry是独立组织、企业或某一范围内使用的UDDI注册服务，其用户对象不是全球用户。在一家具有多个分公司企业的各个分公司内部，可以建立一个私有的UDDI注册中心。这样，每个分公司下属的部门开发新的应用系统的时候，可以将新系统的功能模块用Web Service封装，并将它们发布到自己的注册中心，这些变化会同时体现到其他分公司的UDDI上。当其他分公司的开发人员需要开发新的系统时，预先到本公司的UDDI注册中心去查询一下，是否有他们需要的功能服务存在，如果存在，则直接执行Web service调用就可以了，不用再耗费多余的人力去进行新的开发。这样，相当于直接利用了其他人的开发结果，就使得各分公司之间能够最大限度地共享资源。同时，从另一个方面来说，也提高了开发的效率，缩短了项目的开发周期。

三、方案的实施步骤

基于Web service的应用集成方案的实施流程如下:

1．建立UDDI Registry，方便服务的发布和查询；

2. 对于已有的应用系统，封装系统的接口，将其部署到SOAP处理器中，以Web service的形式发布，使其它系统可以通过SOAP进行调用;对于新系统开发，要基于Web service进行组件化应用系统开发，将系统的接口以服务的形式发布；

3. 将各系统发布的服务进行描述，生成服务的描述文档WSDL，并注册到Private UDDI Registry，以便其它应用系统能够发现和访问这些服务；

4. 发布对外服务到Public UDDI Registry，便于外部企业发现服务并调用。

四、基于Web Service 的EAI架构在企业内部应用模型

图5显示了在企业内使用基于Web service的EAI整体架构应用模型。在模型中应用服务器通过内部应用程序使用私有UDDI注册中心来获得可提供的Web服务的技术信息，并且在企业内部Internet上调用这些服务。在这个例子里面，Web服务把ERP和财务系统等应用程序松散地集成在一起。

圖5EAI构架在企业内部应用模型

模型应用流程步骤如下:

1．用户登录企业局域网或者系统集成登录页，并在Web界面 (Browser界面)上发出请求信息；

2．应用服务器查询私有UDDI注册中心，获得应用服务器提供的关于ERP应用和财务系统的Web Service；

3．针对指定Web service的WSDL绑定信息作为基于SOAP的消息被传送给应用服务器；

4．应用程序调用ERP应用和财务系统发布的Web服务产生用户请求响应信息。这个通讯过程是基于SOAP交互的。之后信息被格式化，发送给起初的调用用户。

五、方案典型应用

根据本文所探讨的基于Web service的应用集成架构，构造一个原型系统，系统的结构如图6所示。方框内部是企业内部应用集成解决方案，然后将其扩展到Internet，就成为一个应用集成的整体解决方案。

图6 基于Web Service的EAI企业内部整体解决方案

将企业现有的各应用系统，如ERP、CRM、遗留系统等按照Web service的标准进行封装，发布服务的WSDL文档到Private UDDI Registry。这样，其它应用系统可以通过读取、分析服务的描述文档，获得服务的入口地址、服务名、方法名以及提交方法所需的参数等，从而实现对服务的访问。为了使某些Web service被更多的应用通过各种平台进入并使用，可以将这些Web service注册到Public UDDI Registry，并发布服务的WSDL文档。企业之间的交互与企业内部各应用之间的交互类似。只是要搜索Public UDDI Registry r以获得所需服务的WSDL文档，实现动态绑定，然后通过SOAP访问这些服务。

六、结语

基于Web service的应用集成方案通过服务的定义、发布、发现、绑定、调用等机制，实现了一种松散祸合的应用集成框架。与现有的应用集成解决方案相比较，方案的优点体现在以下几个方面：

1．防火墙问题。本方案通过SOAP实现系统互联，SOAP使用HTTP作为其通信协议，而现代企业防火墙一般只允许HTTP包通过，所以使得方法的调用能够顺利通过防火墙。

2．可扩展性。现有的应用集成方案都是依赖于单个厂商的解决方案来最大优势地使用协议，本方案基于开放的技术标准，具有很好的可扩展性。

3．灵活性。现有的应用集成方案需要点对点集成，一端的改变必须告知另外一端，这使集成变得非常生硬，同时也浪费了开发人员的时间。本方案是非常灵活的，因为它是建立在发布服务的应用程序和使用服务的应用程序之间的松散祸合。

4．细粒度。本方案可以将大的应用系统划分成小的独立的逻辑实体并且包装它们，因为在细粒度基础上集成应用程序，能够在很大程度上降低集成的复杂度，这也使得本方案比现有的应用集成方案效率更高。

5．动态性。本方案通过提供动态的服务接口来实施一种动态的集成，而现有的应用集成方案都是静态处理的。

基于Web Service的EAI对企业的各个信息系统提出了更高的要求，而这也将会是真正实施起来所要面对的最大难题。在一个企业内，总会有一些系统是很难升级到支持Web Service的。在这种情况下，我们或许不得不首先用传统的接口型的整合产品对它们进行初步的封装，然后在一个标准的接口的基础上，再来实现服务的抽取。[8]

【参考文献】

[1]张衍做.制造业企业信息集成网上研讨会[EB/OL]．2005-10-25．http://www．e-works．net．en/ewkArticles/Category14/Article16991．htm．

[2]刘军．基于Web services信息系统企业集成模型研究与实现[D]．华北电力大学硕士学位论文．2005．

[3]柴晓路．Web服务架构与开放互操作技术[M]．北京：清华大学出版社，2002．

[4]王莉莉，王力生．web service技术下的企业应用集成[J]．计算机与现代化．2003，(4)．

[5]MatjazB．Juric，Marjan Hericko，J2EE EAI and Web Services，

EAI Journal，2002，(5)．

[6]孙志刚．基于Web Service的企业应用集成研究[D]．河北工业大学硕士学位论文，2005，(27).

[7]李华星．基于Web Services的面向服务构架的企业应用系统集成[EB/OL]．2007-10-03.http://www．amteam．org/k/EAI/2007-10/602853．html

[8]CCW．EAI从接口走向服务[EB/OL]．2007-01-23.

http://www.amteam.org/k/Theory/2007-1/0/539573.html