CN104735111A - 采用webservice作统一接口实现esb的方法 - Google Patents

Abstract

本发明涉及一种采用WEBSERVICE作统一接口实现ESB的方法，其步骤包括：1）建立标准的MVC系统框架并添加SOA架构，把WEBSERVICE的开源框架AXIS2整合到标准的MVC框架中。2）更改AXIS2的核心架构实现，添加服务级消息接收器并作为所有操作的相同的消息接收器，由AXIS2自动给操作选择正确的消息接收器；3）对外发布空的服务，用消息接收器拦截所有的通信，并把报文体包装成SOAP报文返回给服务请求者，实现服务消息的统一处理。本发明提供的统一的访问、处理服务的方法，能够应对枢纽级别的大型应用，保证了通信报文的灵活性。

Description

采用WEBSERVICE作统一接口实现ESB的方法

技术领域

本发明涉及的是信息系统中的B/S架构中SOA领域的实现模型，具体地说是利用WEBSERVICE的AXIS2技术实现ESB总线，在其基础上发布空的服务，实现统一接口、服务编排，达到企业级总线服务的目的。

背景技术

SOA(Service Oriented Architecture)面向服务的架构，是一种将信息系统模块化为服务的架构风格。拥有服务之后，可以通过编配服务给业务流程带来生命力。通过SOA，软件可以灵活的为服务提供者和消费者选择实现技术和部署位置，通过稳定的服务接口，隔离服务消费者和服务提供者之间的耦合，大大缩小接口双方由于业务或者技术的改变而对另外一方造成的影响。

由于系统共享平台面对多个外部系统，外部系统的业务、技术升级是不可避免的。采用SOA架构来设计共享平台的安全体系，可以使得共享平台应对灵活多变的外部系统，搭建可高、稳定的安全平台，本发明就是应对多变的项目架构技术实现的一种方式。

目前，现有的SOA架构存在的问题是：

J2EE系统采用三层的MVC架构之后，多个视图能共享一个模型，模型是自包含的，与控制器和视图保持相对独立，所以可以方便地改变应用程序的数据层和业务规则，控制器提高了应用程序的灵活性和可配置性。其解决的主要问题有下几部分：

·将Web页面中的输入元素封装为一个（请求）数据对象。

·根据请求的不同，调度相应的逻辑处理单元，并将（请求）数据对象作为参数传入。

·逻辑处理单元完成运算后，返回一个结果数据对象。

·将结果数据对象中的数据与预先设计的表现层相融合并展现给用户或将其持久化。

上述内容涉及的都是分层的问题，而不能解决分布问题。在大型企业中分布式系统的架构就显得特别重要，但是显然用先前的MVC并不能实现庞大的平台开发。大部分J2EE应用程序，特别是WEB应用程序，并不能从分布式体系架构中受益。甚至相反，由于前期的过渡设计，在根本无需分布式的应用中大量使用分布式技术，不但没有享受到分布式的优点，而且还带来了不同应用层之间昂贵的远程调用，引入了复杂的远程访问期间基础架构和分布式编程。同时，逻辑层的分层远比物理层的分隔重要。选择分布式也就是选择ESB（EnterpriseService Bus，企业服务总线），选择ESB也就是选择了重量级组件。选择了重量级的组件，就很难面对频繁的统一服务管理，如何让诸多的服务都集中在一起，通过同一个通道去通信，这也正是SOA中的ESB的关键路径，是需要解决的重要问题。

发明内容

本发明的目的是针对上述问题，提供一种统一的注册、访问、处理服务的方法，无论是新服务，还是旧服务，都只需要调用一个接口，无论注册了多少个服务，在ESB对外的接口中，核心内部调用永远是一个，添加了新服务接口，通信报文实际上还是利用一个接口，对外注册的服务都是空的服务。

本发明利用标准的WEBSERVICE架构进行改进，形成ESB级别的SOA构架。实现ESB包括以下步骤：首先建立标准的MVC系统框架，然后整合AXIS2技术点，更改标准的MVC框架和AXIS2技术使它可以实现ESB理念，然后对外发布空服务，以拦截器的形式去统一接口及接口的实现。

具体来说，本发明采用的技术方案是：

一种采用WEBSERVICE作统一接口实现ESB的方法，其步骤包括：

1）建立标准的MVC系统框架并添加SOA架构，把WEBSERVICE的开源框架AXIS2整合到标准的MVC框架中。

2）更改AXIS2的核心架构实现，添加服务级消息接收器并作为所有操作的相同的消息接收器，由AXIS2自动给操作选择正确的消息接收器；

3）对外发布空的服务，用消息接收器拦截所有的通信，并把报文体包装成SOAP报文返回给服务请求者，实现服务消息的统一处理。

步骤1）中标准的MVC系统框架包括结构化数据库、NYBATIS数据库访问层、SPRING配置管理层和STRUTS2控制访问层等。

上面方法的实现首先需要对服务进行编排。由于WEBSERVICE的每一个服务都得至少有一个操作对象，而每一个服务都不止一个操作方法，所以就要对服务和操作建立对应关系，然后把操作进行编排，服务的使用者也要和提供者定制一套服务标准。这些标准中包含原子服务与非原子服务，若干个原子服务组合在一起就会变成一个非原子服务，当一个请求如果是一个非原子服务时，那么就要对原子服务进行编排，每一个原子服务都有一个服务号码，根据不同的服务号码，调用不同级别的服务。调用服务引擎可以用java直接读取.java文件，然后自动编译，但这样性能不是很好，本发明采用脚本代码去编排，如shell、ruby脚本语言都是优选的方案。

然后，就是解决统一报文的问题，在WS中的报文是SOAP格式，远远不能满足架构要求，这是就得对SOAP报文进行格转，格转的步骤有下面几步：

1）消息接收器接收到非SOAP标准报文；

2）调用消息统一处理器格转成标准的SOAP报文；

3）根据报文头中的信息确定服用类型；

4）调用业务实现；

5）添加业务报文后格转成标准的SOAP报文，回传给服用请求者。

本发明提供的统一的访问、处理服务的方法，无论是新服务还是旧服务，都能调用一个接口，进行无数个服务的注册查询与操作。具体来说，与现有技术相比，本发明的优点是：

1.在服务管理方面能够统一处理报文处理机制。

2.在服务注册者与服务提供者定制完成报文及服务的标准后，即完成了开发，因为本发明是提供的一种消息通道标准与架构。

3.由于服务的注册、添加、更改会很频繁，对于枢纽级别的项目架构而言，枢纽一定是一对多（多的一方是服务消费者），本发明能够以不变应万变(发布一个空服务，服务的标准就是步骤1)中定制的标准)，能够应对枢纽级别的大型应用。

4.在标准的SOAP上再次自定义报文，保证了通信报文的灵活性。

5.扩容性能强大，因为本发明是采用市场上已经存在的WEBSERVICE标准，WEBSERVICE本身就具有很多自动发布、WSDL标准、SOAP协议等。

附图说明

图1是标准MVC架构的实现图。

图2是添加AXIS2后的项目结构图。

图3是AXIS2服务发布标准图。

图4是AXIS2的服务应用流程图。

图5是AXIS2机制更改后添加ESB理念的配置图。

图6是服务调用的运行状态图。

图7是应用本发明方法的业务用例图。

图8是利用工具SOAPUI进行理论验证的抽象图。

图9和图10是用工具SOAPUI进行测试的结果图，其中图9表示已发布的AccSer服务被成功调用，图10表示此服务做性能压力后的表现情况。

具体实施方式

下面通过具体实施例和附图，对本发明做进一步说明。

本发明利用标准的WEBSERVICE架构进行改进，形成ESB级别的SOA构架。首先建立标准的MVC系统框架，然后整合AXIS2技术点，更改标准的MVC框架和AXIS2技术使它可以实现ESB理念，下面进行具体说明。

1.建立标准的MVC项目架构

首先，根据MVC思想的指导，建立一个标准的Struts2+Spring3+Mybatis的小型项目框架，使项目可以正常启动，并且可以登录。Java2企业版为中间件领域思想的统一发挥了很大的作用。比如，J2EE为分布式事务管理、目录服务和消息服务提供了一套标准的编程接口。J2EE的基础——Java2标准版(J2SE)，成功地为Java提供了一套访问关系数据库的标准。

MVC框架是由一些类组成，正是这些类为应用程序提供了一个可重用的设计――或者我们经常提到的——应用程序中的一层。应用程序代码访问类库从而执行任务，而框架是调用应用程序代码，从而管理程序的流程。这就是经常说到的好莱坞原则：“不要试图联系我们，我们到时候自会通知你。”开发者写的程序在运行时由框架调用。MVC是一个设计模式，它强制性的使应用程序的输入、处理和输出分开。

图1是标准MVC架构的实现图。其中：IE即访问、注册等用户使用层，指服务的注册方，调用用方；ESB服务总线(AXIS2)指ESB和消息处理器、报文格式转换器等；STRUTS2控制访问层是指市场上常用的访问控制框架；SPRING配置管理层是指市场上常用的注入管理控制框架；NYBATIS数据库访问层是数据库操作中间件；结构化数据库是指ORACLE或者MSQL等结构化数据库；其它业务系统：指除本架构中其它的服务注册、使用的系统或平台。

2.整合AXIS2到标准的MVC项目架构中

MVC应用程序被分成三个核心部件：模型、视图、控制器，它们各自处理自己的任务。

AXIS2在实现一个服务时会要求有一个services.xml，在这个文件中配置了服务名、消息接收类、消息的操作类，在这里我们更关心的是AXIS2核心操作——消息接收类。

AXIS2利用消息接收类把传过来的SOAP包封装后传给我们自定义的类，自定义类是要求我们去写的。也就是说，自定义的类拿到的消息永远是AXIS2的消息接收类（messageReceiver）传过来的。那就是说如果单单发布一个服务，有两个操作类在操作SOAP数据包。如果是这样，就出现了过滤的功能，所有的服务发布后，在通信上而言，都是被过滤后才转给用户所定义的类中。根据AXIS2的标准，可以使用AXIOM等方式。无论是哪一种方式，都可以得出一个结论：AXIS2所有的已发布的服务都是被消息接收类过滤后才传给自定义类。

添加AXIS2后的项目结构图如图2所示。其中，客户端（界面）：指IE浏览器；服务总线(消息路由)：指ESB和消息处理器、报文格式转换器等；WEB服务器(服务接口)：指已经注册成功的或已经发布的WSDL服务；应用服务器（业务逻辑、数据访问）：指具体的实现操作方法；数据库(数据)：指服务编码存储及查询的数据库。

分析：根据AXIS2的标准，发布一个服务，只要按照相应的目录新建了相应的报文，一个服务就会被发布，如AXIS2服务发布标准图3所示，只要在标准的web项目中新建services目标，根据如图所示新建文件，一个服务就认为被发布。

在services目录下的实现说明如下：

AcctSer服务名

-----------META-INF符合web项目规范的目录

-----------------services.xml实现服务一系列操作的核心配置文件

-----------------AcctSer.wsdl服务的描述性文件

其中在services.xml文件中的AXIS2的标准中可以看到messaeReciver配置了两个实现类，一个是接收，一个是返回的处理类。Services.xml是AXIS2的核心配置文件，每发布一个服务都会生成一个此文件，此文件中配置了消息处理器等配置项。

根据上图得知，其实WEBSERVICE就是一个调用了公共处理机制的类，消息接收器是特殊的处理器，是In路径（请求路径）中的最后一个处理器。Web服务中的每个操作都有他自己的消息接收器，而且不同的操作可以有不同的消息接收器。消息接收器是依赖于消息交换模式的，所以我们必须为不同的消息交换模式指定不同的消息接收器。AXIS2的服务应用流程如图4所示，其中：注册服务：利用AXIS2通信发布提前预定义的标准；编排服务：利用shell或ruby直接读取形式为.bpl的文件，生成服务组合；发布服务：利用WEBSERVICE下发WSDL描述文件；调用服务：服务消费者或SOAPUI调用。

图4中的各步骤描述如下：

Step1：注册服务时，服务的使用者与提供者制定一套服务标准，包括WSDL、XSD等接口文件，服务注册者根据预先定制的WSDL、XSD标准，向注册服务处申请注册。

Step2：编排服务处收到新注册的服务后，要进行分类，制定服务编码，如果新注册的服务在服务池中已经存在(根据WSDL和XSD确定)，直接调用已存在的服务。

Step3：当发现新注册的服务已经存在时，要对已存在的服务进行验证是否符合当前新服务的要求，如果符合，则直接使用此服务的编码和接口。

Step4：通知服务注册接口，服务注册成功能，可直接去调用已经存在的原子服务。

Step5：如果在服务池中没有找到此服务，编排服务处将会生成新的服务编码，调用发布服务接口，通知发布新的服务；如果注册的服务是原子服务的组合，则编排服务处将进行原子服务的组装，生成服务组装后的服务编码。

Step6：编排原子服务有两种功能，一是把原子服务进行组合；二是把一些编排服务所常用的公共功能与服务绑定，如报文格式验证等。

Step7：发布服务分两种，一种是更新，一种是发布一个新的服务；更新主要指把原子服务重新组装；发布新的服务是指当原子服务无法满足新注册的服务时，将根据服务注册的标准生成新的原子服务。

Step8：验证服务及启动新服务监听，此处会把WSDL的服务对外开放，并且启用XSD验证功能。

Step9：按服务注册的标准对外开放服务，给注册服务处返回注册是否成功的的报文，并通知此服务已经可调用。

3.更改AXIS2的核心消息处理器，添加ESB理念

怎样才能给所有的操作指定相同的消息接收器呢？只要添加服务级消息接收器即可。如此就不必在操作级别指定消息接收器了。我们要做的是指定服务级消息接收器。而在部署时，AXIS2会自动给操作选择正确的消息接收器。这里就可以根据服务的编码指定Operation的统一级消息接收器，也可以根据服务编码为不同的操作指定不同的消息接收器。指定原则由服务的类别确定，原子服务都是指定消息接收器，组合服务统一调用统一消息处理器。如果是组合服务需要在operation中指定messageReceiver标签，保证了接收和输出的消息处理器是同一个，这样就可以重写这个实现，基于WEBSERVICE发布服务的特性，就可以把上述机制结构调整为如图2所示。

图5是AXIS2机制更改后添加ESB理念的配置图。其中messageReceiver标签中class就是配置核心消息处理器的地方，本发明中的消息处理器就是指这里配置的一个类。该图中的UniEntryReceiver是实现了AXIS2的核心机制后，并且加入了ESB的理念的一个实现类。

4.发布空的服务，格转自定义报文，实现统一处理服务消息

只要根据上图3所示目录新建一个结构服务就可以被注册成功。如果在上述中的services.xml文件中，不写入自定义类，即parameter属性不作任何配置，只配置messageReceiver属性，在messageReceiver的实现类里直接写自己的业务核心操作，并按照AXIS2的规范要求返回相同的SOAP报文体，那么就可以做一件事：在AXIS2的过滤功能上再加点儿业务逻辑，在这个业务逻辑里加入服务编排的功能，让在外部所发布的服务只是一个空的服务。这里空的服务指的是没有实际的操作类，靠服务编排后才能有实现的操作类。这样一来，就发布无数个服务，依靠对服务的编排完成了，对外发布一个叫commons的类作为所有服务的统一调用接口，然后以注册的方式，注册子服务。注册完成后，不用更改任何接口，以参数的形式区别调用的是哪个服务，这个就真正做到了用WEBSERVICE作统一接口服务实现了ESB的集成，其运行状态图如图6所示。此图属于UML中标准的状态图，在此表示一次服务调用的周期及运行状态。

图7是业务用例图，其中服务使用者是服务注册方，服务提供者是对外开放的统一接口服务，ESB服务总线是AXIS2核心消息处理器（可以包含消息处理器和对外统一服务接口）。

我们利用工具SOAPUI测试了上述理论的可行性，进行理论验证的抽象图如图8所示。其中，测试报文：指预先服务的注册方和提供方定义好的WSDL描述文件及报文标准；TestUI指开源测试工具SOAPUI；接收测试报文：指报文格式验证器，如果报文有问题，通知TestUI报文件格式错误，通知形式以SOAP格式通知；服务编排struts2+spring+mybatis指ESB实现后的可整体项目，包含AXIS2、ESB接口等；发布服务：指对外开发WSDL描述文件；返回测试报文：指服务调用成功且报文验证无问题后，返回业务请求数据。

SOAPUI功能测试：使用SOAPUI测试工具进行测试，报文的收发正常。其测试结果：报文可以正常收发。

SOAPUI性能测试：使用SOAPUI测试工具进行测试，报文大小为3K，测试时间为60s。

测试结果如图9和10所示，其中图9表示已发布的AccSer服务被成功调用，图10表示此服务做性能压力后的表现情况。具体结果是：min最小响应时间：2毫秒；max最大响应时间：2毫秒；avg平均响应时间：4.39毫秒；cnt请求数：7881笔；tps每秒处理请求数：131笔；bps吞吐率：>20M；rat错误率：0。

尽管为说明目的公开了本发明的具体实施例和附图，其目的在于帮助理解本发明的内容并据以实施，但是本领域的技术人员可以理解：在不脱离本发明及所附的权利要求的精神和范围内，各种替换、变化和修改都是可能的。本发明不应局限于本说明书最佳实施例和附图所公开的内容，本发明要求保护的范围以权利要求书界定的范围为准。

Claims (8)

1.一种采用WEBSERVICE作统一接口实现ESB的方法，其步骤包括：

1）建立标准的MVC系统框架并添加SOA架构，将WEBSERVICE的开源框架AXIS2整合到标准的MVC系统框架中；

2）更改AXIS2的核心架构实现，添加服务级消息接收器并作为所有操作的相同的消息接收器，由AXIS2自动给操作选择正确的消息接收器；

3）对外发布空的服务，用消息接收器拦截所有的通信，并把报文体包装成SOAP报文返回给服务请求者，实现服务消息的统一处理。

2.如权利要求1所述的方法，其特征在于：所述标准的MVC系统框架包括结构化数据库、NYBATIS数据库访问层、SPRING配置管理层和STRUTS2控制访问层。

3.如权利要求1所述的方法，其特征在于：AXIS2的已发布的服务首先被消息接收类过滤，然后传给自定义类。

4.如权利要求1所述的方法，其特征在于，添加AXIS2后的项目结构图包括：客户端，指IE浏览器；服务总线，包括ESB和消息处理器、报文格式转换器；WEB服务器，指已经注册成功的或已经发布的WSDL服务；应用服务器，指具体的实现操作方法；数据库，指服务编码存储及查询的数据库。

5.如权利要求1所述的方法，其特征在于，AXIS2的服务应用流程包括：注册服务，利用AXIS2通信发布提前预定义的标准；编排服务，直接读取形式为.bpl的文件，生成服务组合；发布服务，利用WEBSERVICE下发WSDL描述文件；调用服务，服务消费者或SOAPUI调用。

6.如权利要求5所述的方法，其特征在于，所述编排服务利用shell或ruby读取形式为.bpl的文件。

7.如权利要求5所述的方法，其特征在于，当一个请求如果是一个非原子服务时，那么就要对原子服务进行编排，每一个服务都有一个服务号码，根据不同的服务号码，调用不同级别的服务。

8.如权利要求1所述的方法，其特征在于，对SOAP报文进行格转的步骤包括：首先消息接收器接收到非SOAP标准报文，然后调用消息统一处理器将其格转成标准的SOAP报文；然后根据报文头中的信息确定服用类型，并调用业务实现，添加业务报文后格转成标准的SOAP报文，回传给服用请求者。