一种对称的双向解耦的企业服务描述方法及服务调度系统的制作方法
【专利摘要】本发明公开了一种对称的双向解耦的企业服务描述方法及服务调度系统，涉及基于服务的业务与系统集成领域。该方法把服务的语义和服务的部署分离，引入额外的属性来标示服务类型（输出或者输入）和调用类型（同步读、同步写或者异步写）。对于类型定义、消息结构定义、服务Operation定义等则遵从WSDL2.0协议从而保证和任何其他基于WSDL描述的服务能够很好的集成。与现有技术相比，通过该方法能够以相同的方式对于服务调用者的服务需求和服务提供者的服务描述进行描述，使得服务调用者在逻辑上和服务提供者解耦。具有很好的推广应用价值。
【专利说明】—种对称的双向解耦的企业服务描述方法及服务调度系统
【技术领域】
[0001]本发明涉及基于服务的业务与系统集成领域，具体地说是一种对称的双向解耦的企业服务描述方法及服务调度系统。
【背景技术】
[0002]面向服务的体系结构(service-oriented architecture, SOA)广泛的应用在复杂的信息系统之间的集成和企业应用的服务设计中，它将应用程序的不同功能单元(称为服务)通过定义良好的接口和契约联系起来，使得服务调用者无需关心服务提供者的技术实现细节，提高了软件系统的开放性，并降低了系统集成的复杂性和成本。
[0003]目前主要是通过服务组件(如C0RBA)和Web Service来实现SOA架构，但是存在的主要问题是:服务实现虽然不关心别人如何调用，但是服务调用者即便是通过ESB解决了服务提供者的连接和路由问题，还是需要关心服务调用者的服务接口，并根据服务接口发出服务请求(Request),并理解服务提供者的响应消息(Response),从而根据响应消息的内容进行处理。这本质上是产生了一个单向依赖，只不过在ESB的介入下把物理层和逻辑层的依赖降低为只有逻辑层的依赖。
[0004]目前这种以服务提供者为中心的SOA实现，在系统集成场景中还有一个问题就是源系统和目标系统都只考虑提供服务被动的被其他人调用，项目实施过程还是需要通过代码来从某个系统发起服务的调用。基于上述的对称的服务描述，系统设计时可以分别以服务的形式设计系统需要调用的服务需求和提供对外提供的服务描述，系统集成时则可以实现完全基于服务的集成。
[0005]随着用户对于系统响应性(Responsiveness)要求的提高,异步的理念越来越多的被广泛使用在系统的设计中，特别是Ajax技术在Web编程中极大提高了网站的性能和用户体验，也进一步推广了异步编程模式，但是在异步服务调用方面还缺乏现成的框架进行集成。基于异步的编程模式，出现了业务事件的概念，其根本是事件发生的主体以服务的形式在企业服务库中进行描述，在事件发生的时候，以web服务的方式通知其他人，并把事件的信息发布出来。事件的订阅者基于业务事件和事件的信息进行异步的处理。
【发明内容】
[0006]本发明的技术任务是针对上述现有技术的不足，提供一种对称的双向解耦的企业服务描述方法通过该方法能够以相同的方式对于服务调用者的服务需求和服务提供者的服务描述进行描述，使得服务调用者在逻辑上和服务提供者解耦。
[0007]本发明进一步的技术任务是提供一种对称的双向解耦的企业调度系统。
[0008]本发明的技术任务是按以下方式实现的:一种对称的双向解耦的企业服务描述方法，其特点是将服务的语义和服务的部署分离，引入额外的属性来标示服务类型(输出或者输入)和调用类型(同步读、同步写或者异步写)，对于类型定义、消息结构定义、服务Operation定义则遵从WSDL2.0协议以保证和其他基于WSDL描述的服务能够集成: 引入的额外的属性包括:
服务的描述弓I入额外ServiceType和OperationType:ServiceType用于描述服务是需求描述还是提供的服务的描述；OperationType用于描述调用类型是异步请求，同步读请求还是同步写请求；
消息头引入额外的属性字段 IsSync、SycnCounter> MsgOrderContext 及 MsgOrderID,通过这些字段来保证数据的一致性:
IsSync用于确定是否状态同步；SycnCounter用于确定消息同步的次数；MsgOrderContext用于确定消息编号依据；MsgOrderID用于确定消息序列号。
[0009]在上述对称的无耦合的服务描述方法基础上实现了服务调度系统，来进行服务的调度和适配，从而实现了 SOA架构的灵活的基于服务的系统集成。其特点是调度系统接受服务调用者的XML格式Message，并根据消息发送者的身份信息进行消息路由，并经过消息适配的过程把消息转换为符合消息接受者能够处理的消息结构后，发送给接收者，所述身份信息包括:Interface Name、Operation Name、发送者所在的系统及发送方ID。
[0010]具体来说，上述对称的双向解耦的企业服务调度系统包括以下功能模块:
(1)消息接收适配器:
针对不同的通信协议，提供消息发送者把服务调用或者通知消息发送给服务调度系统的通道，同时消息接收适配器通过通信通道的不同参数识别消息发送者的基本身份(如Interface 名字,Operation 名字，系统 ID)等；
(2)消息队列:
消息队列接收消息接收适配器传递过来的消息进行持久化，避免消息丢失，然后从消息队列中提取消息提交给消息路由；
(3)服务路由:
根据消息发送者的基本身份信息和消息体的字段内容，读取部署的集成模型，进行服务路由，计算出消息应该发送给哪些接受者；
(4)服务映射:
服务映射组件根据定义的消息结构的映射，调用相应的功能把发送者传输的消息结构转换为接受者能够处理的结构，所述消息结构的映射是实施顾问在定义集成模型的时候定义的；
(5)映射逻辑:
实施顾问在定义集成模型时，定义的消息结构映射；
(6)数据库访问组件:
负责和数据库交互，提供消息持久化的API (用程序编程接口)和集成模型和服务描述信息读取的API ；
(7)异常组件:
异常组件根据异常处理策略在mapping (映射)或者消息处理过程中发生异常时，进行对应的异常处理或者通知系统管理员进行人工处理；
(8)消息发送适配器:
消息发送适配器根据服务接收者定义的通信协议，把转换后的消息发送给服务的接收者；同时将内部XML消息转换为适配器对应的格式。[0011]本发明的对称的双向解耦的企业服务描述方法及服务调度系统与现有技术相比具有以下突出的有益效果:
(1)通过对称的完全解耦的服务描述方法把服务调用者的需求作为一种服务进行描述和注册，从而实现了服务生产者和消费者逻辑上的解耦；
(2)在逻辑解耦的基础上，实现了异步的服务集成和服务化的业务事件发布和订阅机
制；
(3)服务协同和调度框架实现了服务中介的功能，增加了服务需求定义，降低了系统集成的成本。
【专利附图】
【附图说明】
[0012]附图1是本发明实施例中服务描述元素关系图；
附图2是本发明实施例中服务调度系统功能原理图；
附图3是本发明实施例中定义服务集成场景的示例图。
【具体实施方式】
[0013]参照说明书附图以具体实施例对本发明的对称的双向解耦的企业服务描述方法及服务调度系统作以下详细地说明。
[0014]实施例:
本发明的对称的双向解耦的企业服务描述方法，该方法把服务的语义和服务的部署分离，引入额外的属性来标示服务类型(输出或者输入)和调用类型(同步读、同步写或者异步写)。对于类型定义、消息结构定义、服务Operation定义等则遵从WSDL2.0协议从而保证和任何其他基于WSDL描述的服务能够很好的集成。服务的描述体系包括:
1.ServiceDefinition:是一个服务描述的根元素，包含一个ServiceInterface的元素和若干个DataType的元素。
[0015]2.Service Interface:服务接口，用来标示服务提供者的服务实现描述和服务调用者的服务需求描述。
[0016]Service Interface的元素和属性说明如下:
Operation元素:服务接口提供的服务方法，同一个服务接口可能包含I个或者多个服务方法；
Name属性:服务接口的名称；
NameSpace属性:服务接口名称的命名空间，可选；
ServiceType属性:服务接口的类型。ServiceType的值为O (表示服务提供者提供的服务描述)或者I (服务需求描述)。
[0017]3.1nterface Operation:服务方法,用来定义服务对外部提供的方法。其他属性和元素如下:
OperationName属性:方法的名称；
OperationType属性:可以选择的值为O (异步)，I (同步读),2 (同步写)； RequestMessageType元素:服务请求的消息结构,类型为MessageType ； ResponseMessageType元素:服务响应的消息结构,类型为MessageType ；FaultMessageType元素:服务调用发生应用或者技术层面的错误，返回给调用者的故障消息结构，类型为MessageType。
[0018]4.MessageType:MessageType用来描述服务请求者和调用者之间的调用消息结构。每个Operation都必须定义Request或者Response的消息结构，同步的Operation会同时具备Request和Response消息结构。MessageType通过若干DataType的兀素来定义，一般是一个树形的结构。其属性如下:
Name属性:服务消息结构的名称；
DataType属性:消息结构对应的数据类型名称。
[0019]消息头引入额外的属性字段IsSync (是否状态同步)，SycnCounter (消息同步的次数)，MsgOrderContext (消息编号依据)，MsgOrderID (消息序列号),通过这些字段来保证数据的一致性。
[0020]5.FaultMessage:服务调用中出现了逻辑或者物理错误，最终没有返回正常的Response 消息的情况下，返回 FaultMessage。FaultMessage 是一种特殊的 MessageType。和MessageType没有任何区别。
[0021]6.DataType:和 WSDL 的 DataType 定义完全一致。
[0022]上述服务描述实体关系如附图1所示。
[0023]基于上述描述 方法，业务事件能够以服务的形式描述，并发布在服务库中。对于业务事件，业务事件的通知可以是一种输出通知类的服务，其描述如下:
【权利要求】
1.一种对称的双向解耦的企业服务描述方法，其特征在于:将服务的语义和服务的部署分离，引入额外的属性来标示服务类型和调用类型，对于类型定义、消息结构定义、服务Operation定义则遵从WSDL2.0协议以保证和其他基于WSDL描述的服务能够集成: 引入的额外的属性包括: 服务的描述引入额外ServiceType和OperationType:ServiceType用于描述服务是需求描述还是提供的服务的描述；OperationType用于描述调用类型是异步请求，同步读请求还是同步写请求； 消息头引入额外的属性字段 IsSync、SycnCounter> MsgOrderContext 及 MsgOrderID,通过这些字段来保证数据的一致性: IsSync用于确定是否状态同步；SycnCounter用于确定消息同步的次数；MsgOrderContext用于确定消息编号依据；MsgOrderID用于确定消息序列号。
2.对称的双向解耦的企业服务调度系统，其特征在于调度系统接受服务调用者的XML格式Message，并根据消息发送者的身份信息进行消息路由，并经过消息适配的过程把消息转换为符合消息接受者能够处理的消息结构后，发送给接收者，所述身份信息包括:Interface Name、Operation Name、发送者所在的系统及发送方ID。
3.根据权利要求2所述的对称的双向解耦的企业服务调度系统，其特征在于包括以下功能模块: (1)消息接收适配 器: 针对不同的通信协议，提供消息发送者把服务调用或者通知消息发送给服务调度系统的通道，同时消息接收适配器通过通信通道的不同参数识别消息发送者的基本身份； (2)消息队列: 消息队列接收消息接收适配器传递过来的消息进行持久化，避免消息丢失，然后从消息队列中提取消息提交给消息路由； (3)服务路由: 根据消息发送者的基本身份信息和消息体的字段内容，读取部署的集成模型，进行服务路由，计算出消息应该发送给哪些接受者； (4)服务映射: 服务映射组件根据定义的消息结构的映射，调用相应的功能把发送者传输的消息结构转换为接受者能够处理的结构，所述消息结构的映射是实施顾问在定义集成模型的时候定义的； (5)映射逻辑: 实施顾问在定义集成模型时，定义的消息结构映射； (6)数据库访问组件: 负责和数据库交互，提供消息持久化的API和集成模型和服务描述信息读取的API ； (7)异常组件: 异常组件根据异常处理策略在mapping或者消息处理过程中发生异常时，进行对应的异常处理或者通知系统管理员进行人工处理； (8)消息发送适配器: 消息发送适配器根据服务接收者定义的通信协议，把转换后的消息发送给服务的接收者；同时将内部XML消息转换为适配器对应的格式。
【文档编号】G06F9/44GK103957188SQ201410111861
【公开日】2014年7月30日 申请日期:2014年3月24日 优先权日:2014年3月24日
【发明者】刘俊红, 李远贵, 刘宁 申请人:浪潮集团山东通用软件有限公司