一種對稱的雙向解耦的企業(yè)服務(wù)描述方法及服務(wù)調(diào)度系統(tǒng)的制作方法
【專利摘要】本發(fā)明公開了一種對稱的雙向解耦的企業(yè)服務(wù)描述方法及服務(wù)調(diào)度系統(tǒng)，涉及基于服務(wù)的業(yè)務(wù)與系統(tǒng)集成領(lǐng)域。該方法把服務(wù)的語義和服務(wù)的部署分離，引入額外的屬性來標(biāo)示服務(wù)類型（輸出或者輸入）和調(diào)用類型（同步讀、同步寫或者異步寫）。對于類型定義、消息結(jié)構(gòu)定義、服務(wù)Operation定義等則遵從WSDL2.0協(xié)議從而保證和任何其他基于WSDL描述的服務(wù)能夠很好的集成。與現(xiàn)有技術(shù)相比，通過該方法能夠以相同的方式對于服務(wù)調(diào)用者的服務(wù)需求和服務(wù)提供者的服務(wù)描述進行描述，使得服務(wù)調(diào)用者在邏輯上和服務(wù)提供者解耦。具有很好的推廣應(yīng)用價值。
【專利說明】—種對稱的雙向解耦的企業(yè)服務(wù)描述方法及服務(wù)調(diào)度系統(tǒng)
【技術(shù)領(lǐng)域】
[0001]本發(fā)明涉及基于服務(wù)的業(yè)務(wù)與系統(tǒng)集成領(lǐng)域，具體地說是一種對稱的雙向解耦的企業(yè)服務(wù)描述方法及服務(wù)調(diào)度系統(tǒng)。
【背景技術(shù)】
[0002]面向服務(wù)的體系結(jié)構(gòu)(service-oriented architecture, SOA)廣泛的應(yīng)用在復(fù)雜的信息系統(tǒng)之間的集成和企業(yè)應(yīng)用的服務(wù)設(shè)計中，它將應(yīng)用程序的不同功能單元(稱為服務(wù))通過定義良好的接口和契約聯(lián)系起來，使得服務(wù)調(diào)用者無需關(guān)心服務(wù)提供者的技術(shù)實現(xiàn)細(xì)節(jié)，提高了軟件系統(tǒng)的開放性，并降低了系統(tǒng)集成的復(fù)雜性和成本。
[0003]目前主要是通過服務(wù)組件(如C0RBA)和Web Service來實現(xiàn)SOA架構(gòu)，但是存在的主要問題是:服務(wù)實現(xiàn)雖然不關(guān)心別人如何調(diào)用，但是服務(wù)調(diào)用者即便是通過ESB解決了服務(wù)提供者的連接和路由問題，還是需要關(guān)心服務(wù)調(diào)用者的服務(wù)接口，并根據(jù)服務(wù)接口發(fā)出服務(wù)請求(Request),并理解服務(wù)提供者的響應(yīng)消息(Response),從而根據(jù)響應(yīng)消息的內(nèi)容進行處理。這本質(zhì)上是產(chǎn)生了一個單向依賴，只不過在ESB的介入下把物理層和邏輯層的依賴降低為只有邏輯層的依賴。
[0004]目前這種以服務(wù)提供者為中心的SOA實現(xiàn)，在系統(tǒng)集成場景中還有一個問題就是源系統(tǒng)和目標(biāo)系統(tǒng)都只考慮提供服務(wù)被動的被其他人調(diào)用，項目實施過程還是需要通過代碼來從某個系統(tǒng)發(fā)起服務(wù)的調(diào)用?；谏鲜龅膶ΨQ的服務(wù)描述，系統(tǒng)設(shè)計時可以分別以服務(wù)的形式設(shè)計系統(tǒng)需要調(diào)用的服務(wù)需求和提供對外提供的服務(wù)描述，系統(tǒng)集成時則可以實現(xiàn)完全基于服務(wù)的集成。
[0005]隨著用戶對于系統(tǒng)響應(yīng)性(Responsiveness)要求的提高,異步的理念越來越多的被廣泛使用在系統(tǒng)的設(shè)計中，特別是Ajax技術(shù)在Web編程中極大提高了網(wǎng)站的性能和用戶體驗，也進一步推廣了異步編程模式，但是在異步服務(wù)調(diào)用方面還缺乏現(xiàn)成的框架進行集成?；诋惒降木幊棠Ｊ?，出現(xiàn)了業(yè)務(wù)事件的概念，其根本是事件發(fā)生的主體以服務(wù)的形式在企業(yè)服務(wù)庫中進行描述，在事件發(fā)生的時候，以web服務(wù)的方式通知其他人，并把事件的信息發(fā)布出來。事件的訂閱者基于業(yè)務(wù)事件和事件的信息進行異步的處理。

【發(fā)明內(nèi)容】

[0006]本發(fā)明的技術(shù)任務(wù)是針對上述現(xiàn)有技術(shù)的不足，提供一種對稱的雙向解耦的企業(yè)服務(wù)描述方法通過該方法能夠以相同的方式對于服務(wù)調(diào)用者的服務(wù)需求和服務(wù)提供者的服務(wù)描述進行描述，使得服務(wù)調(diào)用者在邏輯上和服務(wù)提供者解耦。
[0007]本發(fā)明進一步的技術(shù)任務(wù)是提供一種對稱的雙向解耦的企業(yè)調(diào)度系統(tǒng)。
[0008]本發(fā)明的技術(shù)任務(wù)是按以下方式實現(xiàn)的:一種對稱的雙向解耦的企業(yè)服務(wù)描述方法，其特點是將服務(wù)的語義和服務(wù)的部署分離，引入額外的屬性來標(biāo)示服務(wù)類型(輸出或者輸入)和調(diào)用類型(同步讀、同步寫或者異步寫)，對于類型定義、消息結(jié)構(gòu)定義、服務(wù)Operation定義則遵從WSDL2.0協(xié)議以保證和其他基于WSDL描述的服務(wù)能夠集成: 引入的額外的屬性包括:
服務(wù)的描述弓I入額外ServiceType和OperationType:ServiceType用于描述服務(wù)是需求描述還是提供的服務(wù)的描述；OperationType用于描述調(diào)用類型是異步請求，同步讀請求還是同步寫請求；
消息頭引入額外的屬性字段 IsSync、SycnCounter> MsgOrderContext 及 MsgOrderID,通過這些字段來保證數(shù)據(jù)的一致性:
IsSync用于確定是否狀態(tài)同步；SycnCounter用于確定消息同步的次數(shù)；MsgOrderContext用于確定消息編號依據(jù)；MsgOrderID用于確定消息序列號。
[0009]在上述對稱的無耦合的服務(wù)描述方法基礎(chǔ)上實現(xiàn)了服務(wù)調(diào)度系統(tǒng)，來進行服務(wù)的調(diào)度和適配，從而實現(xiàn)了 SOA架構(gòu)的靈活的基于服務(wù)的系統(tǒng)集成。其特點是調(diào)度系統(tǒng)接受服務(wù)調(diào)用者的XML格式Message，并根據(jù)消息發(fā)送者的身份信息進行消息路由，并經(jīng)過消息適配的過程把消息轉(zhuǎn)換為符合消息接受者能夠處理的消息結(jié)構(gòu)后，發(fā)送給接收者，所述身份信息包括:Interface Name、Operation Name、發(fā)送者所在的系統(tǒng)及發(fā)送方ID。
[0010]具體來說，上述對稱的雙向解耦的企業(yè)服務(wù)調(diào)度系統(tǒng)包括以下功能模塊:
(1)消息接收適配器:
針對不同的通信協(xié)議，提供消息發(fā)送者把服務(wù)調(diào)用或者通知消息發(fā)送給服務(wù)調(diào)度系統(tǒng)的通道，同時消息接收適配器通過通信通道的不同參數(shù)識別消息發(fā)送者的基本身份(如Interface 名字,Operation 名字，系統(tǒng) ID)等；
(2)消息隊列:
消息隊列接收消息接收適配器傳遞過來的消息進行持久化，避免消息丟失，然后從消息隊列中提取消息提交給消息路由；
(3)服務(wù)路由:
根據(jù)消息發(fā)送者的基本身份信息和消息體的字段內(nèi)容，讀取部署的集成模型，進行服務(wù)路由，計算出消息應(yīng)該發(fā)送給哪些接受者；
(4)服務(wù)映射:
服務(wù)映射組件根據(jù)定義的消息結(jié)構(gòu)的映射，調(diào)用相應(yīng)的功能把發(fā)送者傳輸?shù)南⒔Y(jié)構(gòu)轉(zhuǎn)換為接受者能夠處理的結(jié)構(gòu)，所述消息結(jié)構(gòu)的映射是實施顧問在定義集成模型的時候定義的；
(5)映射邏輯:
實施顧問在定義集成模型時，定義的消息結(jié)構(gòu)映射；
(6)數(shù)據(jù)庫訪問組件:
負(fù)責(zé)和數(shù)據(jù)庫交互，提供消息持久化的API (用程序編程接口)和集成模型和服務(wù)描述信息讀取的API ；
(7)異常組件:
異常組件根據(jù)異常處理策略在mapping (映射)或者消息處理過程中發(fā)生異常時，進行對應(yīng)的異常處理或者通知系統(tǒng)管理員進行人工處理；
(8)消息發(fā)送適配器:
消息發(fā)送適配器根據(jù)服務(wù)接收者定義的通信協(xié)議，把轉(zhuǎn)換后的消息發(fā)送給服務(wù)的接收者；同時將內(nèi)部XML消息轉(zhuǎn)換為適配器對應(yīng)的格式。[0011]本發(fā)明的對稱的雙向解耦的企業(yè)服務(wù)描述方法及服務(wù)調(diào)度系統(tǒng)與現(xiàn)有技術(shù)相比具有以下突出的有益效果:
(1)通過對稱的完全解耦的服務(wù)描述方法把服務(wù)調(diào)用者的需求作為一種服務(wù)進行描述和注冊，從而實現(xiàn)了服務(wù)生產(chǎn)者和消費者邏輯上的解耦；
(2)在邏輯解耦的基礎(chǔ)上，實現(xiàn)了異步的服務(wù)集成和服務(wù)化的業(yè)務(wù)事件發(fā)布和訂閱機
制；
(3)服務(wù)協(xié)同和調(diào)度框架實現(xiàn)了服務(wù)中介的功能，增加了服務(wù)需求定義，降低了系統(tǒng)集成的成本。
【專利附圖】

【附圖說明】
[0012]附圖1是本發(fā)明實施例中服務(wù)描述元素關(guān)系圖；
附圖2是本發(fā)明實施例中服務(wù)調(diào)度系統(tǒng)功能原理圖；
附圖3是本發(fā)明實施例中定義服務(wù)集成場景的示例圖。
【具體實施方式】
[0013]參照說明書附圖以具體實施例對本發(fā)明的對稱的雙向解耦的企業(yè)服務(wù)描述方法及服務(wù)調(diào)度系統(tǒng)作以下詳細(xì)地說明。
[0014]實施例:
本發(fā)明的對稱的雙向解耦的企業(yè)服務(wù)描述方法，該方法把服務(wù)的語義和服務(wù)的部署分離，引入額外的屬性來標(biāo)示服務(wù)類型(輸出或者輸入)和調(diào)用類型(同步讀、同步寫或者異步寫)。對于類型定義、消息結(jié)構(gòu)定義、服務(wù)Operation定義等則遵從WSDL2.0協(xié)議從而保證和任何其他基于WSDL描述的服務(wù)能夠很好的集成。服務(wù)的描述體系包括:
1.ServiceDefinition:是一個服務(wù)描述的根元素，包含一個ServiceInterface的元素和若干個DataType的元素。
[0015]2.Service Interface:服務(wù)接口，用來標(biāo)示服務(wù)提供者的服務(wù)實現(xiàn)描述和服務(wù)調(diào)用者的服務(wù)需求描述。
[0016]Service Interface的元素和屬性說明如下:
Operation元素:服務(wù)接口提供的服務(wù)方法，同一個服務(wù)接口可能包含I個或者多個服務(wù)方法；
Name屬性:服務(wù)接口的名稱；
NameSpace屬性:服務(wù)接口名稱的命名空間，可選；
ServiceType屬性:服務(wù)接口的類型。ServiceType的值為O (表示服務(wù)提供者提供的服務(wù)描述)或者I (服務(wù)需求描述)。
[0017]3.1nterface Operation:服務(wù)方法,用來定義服務(wù)對外部提供的方法。其他屬性和元素如下:
OperationName屬性:方法的名稱；
OperationType屬性:可以選擇的值為O (異步)，I (同步讀),2 (同步寫)； RequestMessageType元素:服務(wù)請求的消息結(jié)構(gòu),類型為MessageType ； ResponseMessageType元素:服務(wù)響應(yīng)的消息結(jié)構(gòu),類型為MessageType ；FaultMessageType元素:服務(wù)調(diào)用發(fā)生應(yīng)用或者技術(shù)層面的錯誤，返回給調(diào)用者的故障消息結(jié)構(gòu)，類型為MessageType。
[0018]4.MessageType:MessageType用來描述服務(wù)請求者和調(diào)用者之間的調(diào)用消息結(jié)構(gòu)。每個Operation都必須定義Request或者Response的消息結(jié)構(gòu)，同步的Operation會同時具備Request和Response消息結(jié)構(gòu)。MessageType通過若干DataType的兀素來定義，一般是一個樹形的結(jié)構(gòu)。其屬性如下:
Name屬性:服務(wù)消息結(jié)構(gòu)的名稱；
DataType屬性:消息結(jié)構(gòu)對應(yīng)的數(shù)據(jù)類型名稱。
[0019]消息頭引入額外的屬性字段IsSync (是否狀態(tài)同步)，SycnCounter (消息同步的次數(shù))，MsgOrderContext (消息編號依據(jù))，MsgOrderID (消息序列號),通過這些字段來保證數(shù)據(jù)的一致性。
[0020]5.FaultMessage:服務(wù)調(diào)用中出現(xiàn)了邏輯或者物理錯誤，最終沒有返回正常的Response 消息的情況下，返回 FaultMessage。FaultMessage 是一種特殊的 MessageType。和MessageType沒有任何區(qū)別。
[0021]6.DataType:和 WSDL 的 DataType 定義完全一致。
[0022]上述服務(wù)描述實體關(guān)系如附圖1所示。
[0023]基于上述描述 方法，業(yè)務(wù)事件能夠以服務(wù)的形式描述，并發(fā)布在服務(wù)庫中。對于業(yè)務(wù)事件，業(yè)務(wù)事件的通知可以是一種輸出通知類的服務(wù)，其描述如下:
【權(quán)利要求】
1.一種對稱的雙向解耦的企業(yè)服務(wù)描述方法，其特征在于:將服務(wù)的語義和服務(wù)的部署分離，引入額外的屬性來標(biāo)示服務(wù)類型和調(diào)用類型，對于類型定義、消息結(jié)構(gòu)定義、服務(wù)Operation定義則遵從WSDL2.0協(xié)議以保證和其他基于WSDL描述的服務(wù)能夠集成: 引入的額外的屬性包括: 服務(wù)的描述引入額外ServiceType和OperationType:ServiceType用于描述服務(wù)是需求描述還是提供的服務(wù)的描述；OperationType用于描述調(diào)用類型是異步請求，同步讀請求還是同步寫請求； 消息頭引入額外的屬性字段 IsSync、SycnCounter> MsgOrderContext 及 MsgOrderID,通過這些字段來保證數(shù)據(jù)的一致性: IsSync用于確定是否狀態(tài)同步；SycnCounter用于確定消息同步的次數(shù)；MsgOrderContext用于確定消息編號依據(jù)；MsgOrderID用于確定消息序列號。
2.對稱的雙向解耦的企業(yè)服務(wù)調(diào)度系統(tǒng)，其特征在于調(diào)度系統(tǒng)接受服務(wù)調(diào)用者的XML格式Message，并根據(jù)消息發(fā)送者的身份信息進行消息路由，并經(jīng)過消息適配的過程把消息轉(zhuǎn)換為符合消息接受者能夠處理的消息結(jié)構(gòu)后，發(fā)送給接收者，所述身份信息包括:Interface Name、Operation Name、發(fā)送者所在的系統(tǒng)及發(fā)送方ID。
3.根據(jù)權(quán)利要求2所述的對稱的雙向解耦的企業(yè)服務(wù)調(diào)度系統(tǒng)，其特征在于包括以下功能模塊: (1)消息接收適配 器: 針對不同的通信協(xié)議，提供消息發(fā)送者把服務(wù)調(diào)用或者通知消息發(fā)送給服務(wù)調(diào)度系統(tǒng)的通道，同時消息接收適配器通過通信通道的不同參數(shù)識別消息發(fā)送者的基本身份； (2)消息隊列: 消息隊列接收消息接收適配器傳遞過來的消息進行持久化，避免消息丟失，然后從消息隊列中提取消息提交給消息路由； (3)服務(wù)路由: 根據(jù)消息發(fā)送者的基本身份信息和消息體的字段內(nèi)容，讀取部署的集成模型，進行服務(wù)路由，計算出消息應(yīng)該發(fā)送給哪些接受者； (4)服務(wù)映射: 服務(wù)映射組件根據(jù)定義的消息結(jié)構(gòu)的映射，調(diào)用相應(yīng)的功能把發(fā)送者傳輸?shù)南⒔Y(jié)構(gòu)轉(zhuǎn)換為接受者能夠處理的結(jié)構(gòu)，所述消息結(jié)構(gòu)的映射是實施顧問在定義集成模型的時候定義的； (5)映射邏輯: 實施顧問在定義集成模型時，定義的消息結(jié)構(gòu)映射； (6)數(shù)據(jù)庫訪問組件: 負(fù)責(zé)和數(shù)據(jù)庫交互，提供消息持久化的API和集成模型和服務(wù)描述信息讀取的API ； (7)異常組件: 異常組件根據(jù)異常處理策略在mapping或者消息處理過程中發(fā)生異常時，進行對應(yīng)的異常處理或者通知系統(tǒng)管理員進行人工處理； (8)消息發(fā)送適配器: 消息發(fā)送適配器根據(jù)服務(wù)接收者定義的通信協(xié)議，把轉(zhuǎn)換后的消息發(fā)送給服務(wù)的接收者；同時將內(nèi)部XML消息轉(zhuǎn)換為適配器對應(yīng)的格式。
【文檔編號】G06F9/44GK103957188SQ201410111861
【公開日】2014年7月30日 申請日期:2014年3月24日 優(yōu)先權(quán)日:2014年3月24日
【發(fā)明者】劉俊紅, 李遠(yuǎn)貴, 劉寧 申請人:浪潮集團山東通用軟件有限公司