采用webservice作统一接口实现esb的方法
【技术领域】
[0001]本发明涉及的是信息系统中的B/S架构中SOA领域的实现模型，具体地说是利用WEBSERVICE的AXIS2技术实现ESB总线，在其基础上发布空的服务，实现统一接口、服务编排，达到企业级总线服务的目的。
【背景技术】
[0002]SOA (Service Oriented Architecture)面向服务的架构，是一种将信息系统模块化为服务的架构风格。拥有服务之后，可以通过编配服务给业务流程带来生命力。通过S0A，软件可以灵活的为服务提供者和消费者选择实现技术和部署位置，通过稳定的服务接口，隔离服务消费者和服务提供者之间的耦合，大大缩小接口双方由于业务或者技术的改变而对另外一方造成的影响。
[0003]由于系统共享平台面对多个外部系统，外部系统的业务、技术升级是不可避免的。采用SOA架构来设计共享平台的安全体系，可以使得共享平台应对灵活多变的外部系统，搭建可高、稳定的安全平台，本发明就是应对多变的项目架构技术实现的一种方式。
[0004]目前，现有的SOA架构存在的问题是:
[0005]J2EE系统采用三层的MVC架构之后，多个视图能共享一个模型，模型是自包含的，与控制器和视图保持相对独立，所以可以方便地改变应用程序的数据层和业务规则，控制器提高了应用程序的灵活性和可配置性。其解决的主要问题有下几部分:
[0006].将Web页面中的输入元素封装为一个(请求)数据对象。
[0007].根据请求的不同，调度相应的逻辑处理单元，并将(请求)数据对象作为参数传入。
[0008].逻辑处理单元完成运算后，返回一个结果数据对象。
[0009]?将结果数据对象中的数据与预先设计的表现层相融合并展现给用户或将其持久化。
[0010]上述内容涉及的都是分层的问题，而不能解决分布问题。在大型企业中分布式系统的架构就显得特别重要，但是显然用先前的MVC并不能实现庞大的平台开发。大部分J2EE应用程序，特别是WEB应用程序，并不能从分布式体系架构中受益。甚至相反，由于前期的过渡设计，在根本无需分布式的应用中大量使用分布式技术，不但没有享受到分布式的优点，而且还带来了不同应用层之间昂贵的远程调用，引入了复杂的远程访问期间基础架构和分布式编程。同时，逻辑层的分层远比物理层的分隔重要。选择分布式也就是选择ESB (Enterprise Service Bus,企业服务总线),选择ESB也就是选择了重量级组件。选择了重量级的组件，就很难面对频繁的统一服务管理，如何让诸多的服务都集中在一起，通过同一个通道去通信，这也正是SOA中的ESB的关键路径，是需要解决的重要问题。
【发明内容】
[0011]本发明的目的是针对上述问题，提供一种统一的注册、访问、处理服务的方法，无论是新服务，还是旧服务，都只需要调用一个接口，无论注册了多少个服务，在ESB对外的接口中，核心内部调用永远是一个，添加了新服务接口，通信报文实际上还是利用一个接口，对外注册的服务都是空的服务。
[0012]本发明利用标准的WEBSERVICE架构进行改进，形成ESB级别的SOA构架。实现ESB包括以下步骤:首先建立标准的MVC系统框架，然后整合AXIS2技术点，更改标准的MVC框架和AXIS2技术使它可以实现ESB理念，然后对外发布空服务，以拦截器的形式去统一接口及接口的实现。
[0013]具体来说，本发明采用的技术方案是:
[0014]一种采用WEBSERVICE作统一接口实现ESB的方法，其步骤包括:
[0015]I)建立标准的MVC系统框架并添加SOA架构，把WEBSERVICE的开源框架AXIS2整合到标准的MVC框架中。
[0016]2)更改AXIS2的核心架构实现，添加服务级消息接收器并作为所有操作的相同的消息接收器，由AXIS2自动给操作选择正确的消息接收器；
[0017]3)对外发布空的服务，用消息接收器拦截所有的通信，并把报文体包装成SOAP报文返回给服务请求者，实现服务消息的统一处理。
[0018]步骤I)中标准的MVC系统框架包括结构化数据库、NYBATIS数据库访问层、SPRING配置管理层和STRUTS2控制访问层等。
[0019]上面方法的实现首先需要对服务进行编排。由于WEBSERVICE的每一个服务都得至少有一个操作对象，而每一个服务都不止一个操作方法，所以就要对服务和操作建立对应关系，然后把操作进行编排，服务的使用者也要和提供者定制一套服务标准。这些标准中包含原子服务与非原子服务，若干个原子服务组合在一起就会变成一个非原子服务，当一个请求如果是一个非原子服务时，那么就要对原子服务进行编排，每一个原子服务都有一个服务号码，根据不同的服务号码，调用不同级别的服务。调用服务引擎可以用java直接读取.java文件，然后自动编译，但这样性能不是很好，本发明采用脚本代码去编排，如shell、ruby脚本语言都是优选的方案。
[0020]然后，就是解决统一报文的问题，在WS中的报文是SOAP格式，远远不能满足架构要求，这是就得对SOAP报文进行格转，格转的步骤有下面几步:
[0021 ] I)消息接收器接收到非SOAP标准报文；
[0022]2)调用消息统一处理器格转成标准的SOAP报文；
[0023]3)根据报文头中的信息确定服用类型；
[0024]4)调用业务实现；
[0025]5)添加业务报文后格转成标准的SOAP报文，回传给服用请求者。
[0026]本发明提供的统一的访问、处理服务的方法，无论是新服务还是旧服务，都能调用一个接口，进行无数个服务的注册查询与操作。具体来说，与现有技术相比，本发明的优点是:
[0027]1.在服务管理方面能够统一处理报文处理机制。
[0028]2.在服务注册者与服务提供者定制完成报文及服务的标准后，即完成了开发，因为本发明是提供的一种消息通道标准与架构。
[0029]3.由于服务的注册、添加、更改会很频繁，对于枢纽级别的项目架构而言，枢纽一定是一对多(多的一方是服务消费者)，本发明能够以不变应万变(发布一个空服务，服务的标准就是步骤I)中定制的标准)，能够应对枢纽级别的大型应用。
[0030]4.在标准的SOAP上再次自定义报文，保证了通信报文的灵活性。
[0031]5.扩容性能强大，因为本发明是采用市场上已经存在的WEBSERVICE标准，WEBSERVICE本身就具有很多自动发布、WSDL标准、SOAP协议等。
【附图说明】
[0032]图1是标准MVC架构的实现图。
[0033]图2是添加AXIS2后的项目结构图。
[0034]图3是AXIS2服务发布标准图。
[0035]图4是AXIS2的服务应用流程图。
[0036]图5是AXIS2机制更改后添加ESB理念的配置图。
[0037]图6是服务调用的运行状态图。
[0038]图7是应用本发明方法的业务用例图。
[0039]图8是利用工具SOAPH进行理论验证的抽象图。
[0040]图9和图10是用工具SOAPH进行测试的结果图，其中图9表示已发布的AccSer服务被成功调用，图10表示此服务做性能压力后的表现情况。
【具体实施方式】
[0041]下面通过具体实施例和附图，对本发明做进一步说明。
[0042]本发明利用标准的WEBSERVICE架构进行改进，形成ESB级别的SOA构架。首先建立标准的MVC系统框架，然后整合AXIS2技术点，更改标准的MVC框架和AXIS2技术使它可以实现ESB理念，下面进行具体说明。
[0043]1.建立标准的MVC项目架构
[0044]首先，根据MVC思想的指导,建立一个标准的Struts2+Spring3+Mybatis的小型项目框架，使项目可以正常启动，并且可以登录。Java2企业版为中间件领域思想的统一发挥了很大的作用。比如，J2EE为分布式事务管理、目录服务和消息服务提供了一套标准的编程接口。J2EE的基础——Java2标准版(J2SE)，成功地为Java提供了一套访问关系数据库的标准。
[0045]MVC框架是由一些类组成，正是这些类为应用程序提供了一个可重用的设计一一或者我们经常提到的——应用程序中的一层。应用程序代码访问类库从而执行任务，而框架是调用应用程序代码，从而管理程序的流程。这就是经常说到的好莱坞原则:“不要试图联系我们，我们到时候自会通知你。”开发者写的程序在运行时由框架调用。MVC是一个设计模式，它强制性的使应用程序的输入、处理和输出分开。
[0046]图1是标准MVC架构的实现图。其中:IE即访问、注册等用户使用层，指服务的注册方，调用用方；ESB服务总线(AXIS2)指ESB和消息处理器、报文格式转换器等；STRUTS2控制访问层是指市场上常用的访问控制框架；SPRING配置管理层是指市场上常用的注入管理控制框架；NYBATIS数据库访问层是数据库操作中间件；结构化数据库是指ORACLE或者MSQL等结构化数据库；其它业务系统:指除本架构中其它的服务注册、使用的系统或平台。
[0047]2.整合AXIS2到标准的MVC项目架构中
[0048]MVC应用程序被分成三个核心部件:模型、视图、控制器，它们各自处理自己的任务。
[0049]AXIS2在实现一个服务时会要求有一个services, xml,在这个文件中配置了服务名、消息接收类、消息的操作类，在这里我们更关心的是AXIS2核心操作一消息接收类。
[0050]AXIS2利用消息接收类把传过来的SOAP包封装后传给我们自定义的类，自定义类是要求我们去写的。也就是说，自定义的类拿到的消息永远是AXIS2的消息接收类(messageReceiver)传过来的。那就是说如果单单发布一个服务,有两个操作类在操作SOAP数据包。如果是这样，就出现了过滤的功能，所有的服务发布后，在通信上而言，都是被过滤后才转给用户所定义的类中。根据AXIS2的标准，可以使用AX1M等方式。无论是哪一种方式，都可以得出一个结论:AXIS2所有的已发布的服务都是被消息接收类过滤后才传给自定义类。
[0051]添加AXIS2后的项目结构图如图2所示。其中，客户端(界面):指IE浏览器；服务总线(消息路由):指ESB和消息处理器、报文格式转换器等；WEB服务器(服务接口):指已经注册成功的或已经发布的WSDL服务；应用服务器(业务逻辑、数据访问):指具体的实现操作方法；数据库(数据):指服务编码存储及查询的数据库。
[0052]分析:根据AXIS2的标准，发布一个服务，只要按照相应的目录新建了相应的报文，一个服务就会被发布，如AXIS