專利名稱：協(xié)議無關(guān)的soa系統(tǒng)和業(yè)務(wù)處理方法
技術(shù)領(lǐng)域：
本發(fā)明涉及一種S0A技術(shù)領(lǐng)域，特別是指一種協(xié)議無關(guān)的S0A 系統(tǒng)和業(yè)務(wù)處理方法。
背景技術(shù)：
SOA是一種粗粒度、松耦合服務(wù)的架構(gòu)模型，它可以根據(jù)需求通 過網(wǎng)絡(luò)對松散耦合的粗粒度應(yīng)用服務(wù)組件進(jìn)行分布式部署、組合和 使用。并且服務(wù)之間可通過簡單、精確、標(biāo)準(zhǔn)的協(xié)議和接口定義語 言進(jìn)行通信與互操作，不涉及底層編程接口和通信模型。理想的是 平臺中將各種功能以粗粒度的服務(wù)表示出來，每種服務(wù)都能清晰地表示其技術(shù)或業(yè)務(wù)價值，在應(yīng)用實現(xiàn)過程中，可以通過對服務(wù)的動 態(tài)組裝來適應(yīng)用業(yè)務(wù)需求的動態(tài)變化。企業(yè)月良務(wù)總線ESB (Enterprise Service Bus)是S0A架構(gòu)的一 個支柱技術(shù)。它是一種開放的、基于標(biāo)準(zhǔn)的消息處理機(jī)制，通過筒 單的標(biāo)準(zhǔn)適配器和接口，來完成粗粒度應(yīng)用(比如服務(wù))和其他組 件之間的互操作。作為一種消息代理架構(gòu)它提供消息隊列系統(tǒng)，使 用諸如SOAP或JMS (Java Message Service)等標(biāo)準(zhǔn)技術(shù)來實現(xiàn)。一 般地，ESB的主要功能包括通信和消息處理、服務(wù)交互和安全性控 制、服務(wù)質(zhì)量和服務(wù)級別管理、建模、管理和自治、基礎(chǔ)架構(gòu)等。例如目前通常采用遠(yuǎn)程調(diào)用(Remoting)，實現(xiàn)兩個應(yīng)用程序之 間對象的通信流程是首先，客戶端通過遠(yuǎn)程調(diào)用系統(tǒng)，訪問通道 以獲得服務(wù)端對象，再通過代理解析為客戶端對象。這可以實現(xiàn)以 服務(wù)的方式來發(fā)布服務(wù)器端對象。也就是說遠(yuǎn)程對象代碼可以在服 務(wù)器上運(yùn)行，然后客戶端再通過遠(yuǎn)程調(diào)用系統(tǒng)連接服務(wù)器，獲得該 服務(wù)對象并通過序列化在客戶端運(yùn)行。這樣通過獲得服務(wù)器端對象的引用來實現(xiàn)遠(yuǎn)程調(diào)用的目的，也就實現(xiàn)了客戶端和服務(wù)器端有關(guān) 對象的松散耦合。但是目前常用的系統(tǒng)或方法，并不能真正實現(xiàn)松散耦合的粗粒度應(yīng)用服務(wù)組件的分布式部署。例如所使用的協(xié)議發(fā)生改變或者SOA 的系統(tǒng)中使用了多個不同平臺甚至多個協(xié)議的話，傳統(tǒng)的系統(tǒng)和方 法是不能勝任的。例如需要提供的端口號和通道類型等信息將隨著 協(xié)議的變化而發(fā)生變化，而這些是和服務(wù)綁定在一起的。如果可以 將協(xié)議和服務(wù)相分離，即實現(xiàn)服務(wù)和協(xié)議無關(guān)的話，將有效提高代 碼復(fù)用性，并使得服務(wù)的開發(fā)人員只需專注于服務(wù)的業(yè)務(wù)模型等業(yè) 務(wù)上的開發(fā)，從而降低開發(fā)難度。發(fā)明內(nèi)容有鑒于此，本發(fā)明的主要目的在于提供一種協(xié)議無關(guān)的S0A系統(tǒng) 和業(yè)務(wù)處理方法，以實現(xiàn)S0A架構(gòu)的服務(wù)和協(xié)議無關(guān)。本發(fā)明提供了協(xié)議無關(guān)的SOA系統(tǒng)，包括客戶端和服務(wù)器端，其中客戶端包括編程代理302,用于接收業(yè)務(wù)信息和配置的協(xié)議； 協(xié)議選擇器304,用于根據(jù)所述配置的協(xié)議確定所使用的協(xié)議； 協(xié)議客戶端306,用于采用所確定的協(xié)議實現(xiàn)客戶端代理，以實 現(xiàn)傳遞包括所述業(yè)務(wù)信息的信息； 服務(wù)器端包括協(xié)議服務(wù)器端308，用于采用所確定的協(xié)議實現(xiàn)服務(wù)器端代理， 以實現(xiàn)傳遞包括所述業(yè)務(wù)信息的信息；業(yè)務(wù)處理器310，用于處理所接收的業(yè)務(wù)信息。由上可以看出，通過編程代理302和協(xié)議選擇器304在服務(wù)實現(xiàn) 代理之前，還根據(jù)配置的協(xié)議確定將釆用的協(xié)議。通過增加協(xié)議選 擇過程實現(xiàn)具體的服務(wù)和協(xié)議相分離，即實現(xiàn)服務(wù)和協(xié)議的無關(guān)。而協(xié)議的兩端保證了分布式服務(wù)的通信。最后由服務(wù)器的業(yè)務(wù)處理器310完成業(yè)務(wù)邏輯的執(zhí)行，最終達(dá)到了分布式服務(wù)架構(gòu)的目的。優(yōu)選的是，所述協(xié)議客戶端306包括代理實現(xiàn)選擇器3062，用于選取代理實現(xiàn)；代理實現(xiàn)庫3064，用于提供包括對應(yīng)不同協(xié)議的不同代理實現(xiàn)；客戶端代理3066,用于采用所選取的對應(yīng)所確定的協(xié)議的代理 實現(xiàn)，實現(xiàn)客戶端代理。由上可以看出，代理實現(xiàn)庫3064中具體的代理實現(xiàn)描述了對應(yīng) 協(xié)議的實現(xiàn)細(xì)節(jié)，/人而客戶端代理3066可以建立用于在客戶端的通 信的代理，例如偽裝實現(xiàn)所述客戶端代理所需的包含業(yè)務(wù)信息的遠(yuǎn) 程對象，并向本地提供與遠(yuǎn)程對象相同的接口。優(yōu)選的是，所述協(xié)議客戶端(306 )還包括客戶端接口 3068, 用于將包含所述業(yè)務(wù)信息的信息的格式進(jìn)行標(biāo)準(zhǔn)化。由上可以看出，客戶端接口 3068實現(xiàn)了在協(xié)議兩端交互的信息 的格式標(biāo)準(zhǔn)化。優(yōu)選的是，所述業(yè)務(wù)處理器310包括業(yè)務(wù)操作3102,用于讀取業(yè)務(wù)信息；業(yè)務(wù)接口 3106，用于提供調(diào)用業(yè)務(wù)邏輯的接口；業(yè)務(wù)邏輯實現(xiàn)3108，用于根據(jù)所述業(yè)務(wù)邏輯的接口調(diào)用業(yè)務(wù)邏 輯處理所讀取的業(yè)務(wù)信息。由上可以看出，業(yè)務(wù)邏輯實現(xiàn)3108提供了具體的業(yè)務(wù)邏輯的實 現(xiàn)并完成了業(yè)務(wù)信息的處理。從而完成了服務(wù)在服務(wù)器上的實現(xiàn)。優(yōu)選的是，所述業(yè)務(wù)處理器310還包括業(yè)務(wù)邏輯實現(xiàn)選擇器3104，用于選擇所要調(diào)用的業(yè)務(wù)邏輯。由上可以看出，對于一個方法有多個業(yè)務(wù)邏輯實現(xiàn)的情況，利用 業(yè)務(wù)邏輯實現(xiàn)選擇器3104可以完成對業(yè)務(wù)邏輯的選擇。這樣對于客 戶端的應(yīng)用程序不需要考慮具體實現(xiàn)，而只需要提供方法名就可以 了。而且因為真正的處理選擇在服務(wù)器端，還可以實現(xiàn)在服務(wù)器端 對業(yè)務(wù)信息處理的集中控制。本發(fā)明還公開了協(xié)議無關(guān)的SOA的業(yè)務(wù)處理方法，包括客戶端和服務(wù)器端的處理，其中 客戶端的處理包括 A，接收業(yè)務(wù)信息和配置的協(xié)議；B, 根據(jù)配置的協(xié)議確定所使用的協(xié)議；C, 采用所確定的協(xié)議實現(xiàn)客戶端代理，實現(xiàn)傳遞包括所述業(yè)務(wù) 信息的信息；服務(wù)器端的處理包括D, 采用所確定的協(xié)議實現(xiàn)服務(wù)器端代理，實現(xiàn)傳遞包括所述業(yè) 務(wù)信息的信息；E，處理所接收的業(yè)務(wù)信息。由上可以看出，經(jīng)過上面的步驟實現(xiàn)了客戶端的服務(wù)的業(yè)務(wù)邏輯 在服務(wù)器端的實現(xiàn)。其中步驟A和步驟B在步驟C之前，即在服務(wù) 實現(xiàn)代理之前，首先根據(jù)配置的協(xié)議確定將采用的協(xié)議。通過增加 協(xié)議選擇過程實現(xiàn)具體的服務(wù)和協(xié)議相分離，即實現(xiàn)服務(wù)和協(xié)議的 無關(guān)。而步驟C和步驟D在協(xié)議的兩端保證了分布式服務(wù)的通信。 最后由步驟E完成服務(wù)在服務(wù)器上的業(yè)務(wù)邏輯的實現(xiàn)，最終達(dá)到了 分布式服務(wù)架構(gòu)的目的。優(yōu)選的是，所述步驟C包括Cl,選取代理實現(xiàn)；C2，讀取所選取的包括對應(yīng)協(xié)議的代理實現(xiàn)；C3,采用所選取的對應(yīng)協(xié)議的代理實現(xiàn)，實現(xiàn)客戶端代理。由上可以看出，步驟Cl和步驟C2為確定的協(xié)議和服務(wù)選擇和讀取具體的描述了代理實現(xiàn)細(xì)節(jié)的代理實現(xiàn)。而由步驟C3完成代理在客戶端的完整實現(xiàn)。優(yōu)選的是，所述步驟C所述傳遞前還包括將所要傳遞的包含所述業(yè)務(wù)信息的信息的格式進(jìn)行標(biāo)準(zhǔn)化處理。。由上可以看出，實現(xiàn)了在協(xié)議兩端信息交換格式的標(biāo)準(zhǔn)化。 優(yōu)選的是，步驟E中處理所接收的業(yè)務(wù)信息的步驟包括 El,讀取業(yè)務(wù)信息；E2,確定調(diào)用業(yè)務(wù)邏輯的接口；E3,根據(jù)所述業(yè)務(wù)邏輯的接口調(diào)用業(yè)務(wù)邏輯處理所讀取的業(yè)務(wù)信自、由上可以看出，遠(yuǎn)程對象是業(yè)務(wù)信息的載體，步驟E1完成業(yè)務(wù) 信息的讀取后，由步驟E2和E3完成服務(wù)在服務(wù)器端的業(yè)務(wù)邏輯的 具體實現(xiàn)。優(yōu)選的是，所述步驟El和E2之間還包括選擇所要調(diào)用的業(yè)務(wù) 邏輯；由上可以看出，對于一個方法有多個業(yè)務(wù)邏輯實現(xiàn)的情況，通過 增加步驟Ell可以對多個業(yè)務(wù)邏輯進(jìn)行選擇。這樣對于客戶端的應(yīng) 用程序不需要考慮具體實現(xiàn)，而只需要提供方法名就可以了。而且 因為真正的處理選擇在服務(wù)器端，還可以實現(xiàn)在服務(wù)器端對業(yè)務(wù)信 息處理的集中控制。


圖1為實施例中.NET Remoting協(xié)議的示意圖；圖2為實施例中WebService協(xié)議的示意圖；圖3為協(xié)議無關(guān)的S0A系統(tǒng)300的示意圖；圖4為協(xié)議客戶端306和協(xié)議服務(wù)器端308的示意圖；圖5為帶客戶端接口的實施例的協(xié)議客戶端306的示意圖；圖6為業(yè)務(wù)處理310的示意圖；圖7為協(xié)議無關(guān)的SA0的業(yè)務(wù)處理方法的流程圖；圖8為步驟708和步驟710實現(xiàn)通信的流程圖；圖9為步驟712實現(xiàn)業(yè)務(wù)信息處理的流程圖。
具體實施方式
通常的，Web編程模型提供使用分布式通信編程框架生成Web樣 式服務(wù)所需的基本框架元素。而本發(fā)明SOA系統(tǒng)實現(xiàn)了一種與底層 協(xié)議和分布式對象協(xié)議無關(guān)的面向服務(wù)的編程模型。通過本發(fā)明，在如.NET的平臺上，如微軟(Microsoft )等公司已經(jīng)提供了多種分 布式協(xié)議，如WebService編程才莫型或.NET Remoting編程模型，和 已經(jīng)才是供的更先進(jìn)的編禾呈才莫型，^口 Windows Communication Foundation以及任何將來可能出現(xiàn)的編程模型，這些對本發(fā)明SOA 系統(tǒng)來說，都可以進(jìn)行統(tǒng)一處理。本發(fā)明SOA系統(tǒng)實現(xiàn)了基于業(yè)務(wù)的分布式對象協(xié)議或服務(wù)協(xié)議。本發(fā)明SOA系統(tǒng)中，實現(xiàn)通信的協(xié)議客戶端和協(xié)議服務(wù)器端包Locator)、讀取所確定出的代理實現(xiàn)的具體內(nèi)容的代理實現(xiàn)庫 (Proxy Repository)、根據(jù)讀取的代理實現(xiàn)的具體內(nèi)容實現(xiàn)在客 戶端/服務(wù)器端代理的客戶端代理(Proxy )和服務(wù)器端存根(Stub )。其中，所采用的協(xié)議可以由WebService、 . NET Remoting或WCF (Windows Communication Foundation)實現(xiàn)。下面舉例說明如圖1所示為采用.NET Remoting協(xié)議的示意圖，包括.NET Remoting代理實現(xiàn)選擇器102 (.NET Remoting Locator) 、 .NET Remoting代理實現(xiàn)庫104 (.NET Remoting Repository) .NET Remoting的客戶端代理106/服務(wù)器端存才艮108 (.NET Remoting Proxy/Stub )。如圖2所示為采用WebService協(xié)議的示意圖，包括WebService 代理實現(xiàn)選擇器202 (WebService Locator) 、 WebService代理實 現(xiàn)庫204 (WebService Repository )和具體的WebService的客戶 端代理206/服務(wù)器端存根208 (WebService Proxy/Stub)。同理，采用WCF協(xié)議可由WCF代理實現(xiàn)選4奪器(WCF Locator)、 WCF代理實現(xiàn)庫(WCF Repostiory)和具體的WCF的客戶端代理/服 務(wù)器端存根(WCF Proxy/Stub)構(gòu)成。不難理解的是，采用以上3個協(xié)議僅為舉例，也可以采用其它協(xié) 議構(gòu)成類似的模式實現(xiàn)協(xié)議客戶端和協(xié)議服務(wù)器端的通信，在此不 一一詳述。對于本發(fā)明的協(xié)議無關(guān)的S0A系統(tǒng)實現(xiàn)編程模型時，需要首先建 立業(yè)務(wù)接口 (Business Interface),然后針對這個業(yè)務(wù)接口，給出 一個或多個業(yè)務(wù)邏輯實現(xiàn)(Strategy Implementation)。由協(xié)議無關(guān) 的SOA系統(tǒng)提供一個公共的協(xié)議選擇器(Service Locator),然后 為每個業(yè)務(wù)接口自動生成編程代理(Agent )、實現(xiàn)客戶端接口 (CI ient Interface )的客戶端代理(Proxy )、服務(wù)器端存根(Stub )、 業(yè)務(wù)操作(Business Operation)和業(yè)務(wù)邏輯選擇器(Strategy Selector)等。其中業(yè)務(wù)邏輯實現(xiàn)選擇器允許修改生成的代碼。在 下文具體介紹SOA系統(tǒng)時，將陸續(xù)介紹出上面的具體內(nèi)容。下面以在客戶端下訂單時遠(yuǎn)程調(diào)用服務(wù)器中的業(yè)務(wù)邏輯實現(xiàn)編 程模型為例，結(jié)合圖3對協(xié)議無關(guān)的SOA系統(tǒng)300進(jìn)行詳細(xì)說明。在本例中，客戶端的應(yīng)用程序描述了要為 一個用戶ID (CustomerID)為ABC Company的客戶下訂單，其訂單的ID和名稱 (Name)分別是2345和ABC Company。該描述中需要的執(zhí)行方法(Do ) 的具體實現(xiàn)，即業(yè)務(wù)邏輯的實現(xiàn)在服務(wù)器端。 以下是客戶端應(yīng)用程序的示例 public void TestLocal() { PlaceOrderAgent agent = new PlaceOrderAgent (); agent.CustomerID = "ABC Company"; OrderData data = new OrderData (); data.Id = 2345; data.Name = "ABC Company"; agent.OrderData = data; object o = agent. Do (); Console. Wr i teLine (o. ToStr ing ()); }上述示例是采用CH吾言的下訂單程序，不難理解，也可以采用其它編程語言描述該應(yīng)用程序。對于本發(fā)明協(xié)議無關(guān)的S0A系統(tǒng)300,其客戶端包括 編程代理302,用于接收業(yè)務(wù)信息和配置的協(xié)議。 在本實施例中，從客戶端的應(yīng)用程序接收業(yè)務(wù)信息和配置的協(xié) 議。接收的業(yè)務(wù)信息包括業(yè)務(wù)數(shù)據(jù)(如所述應(yīng)用程序中描述的用戶 ID-CustomerID和訂單數(shù)據(jù)-OrderData )和所調(diào)用的方法名(Do )。 配置的協(xié)議是訂單業(yè)務(wù)(IPlaceOrder )所屬服務(wù)的所配置的協(xié)議。 不難理解，如果調(diào)用多個方法，例如Dol和Do2，只需在編程代理 302中添加調(diào)用的方法即可。 以下是編程代理302示例 // Full Generated public class PlaceOrderAgent : Agent { public string CustomerID { get; set; } public OrderData OrderData { get; set; } public object Do () { IPlaceOrder po =(IPlaceOrder)ServiceLocator.GetService (typeof (IPlaceOrder))協(xié)議選擇器304，用于根據(jù)所述配置的協(xié)議確定所使用的協(xié)議。以下是協(xié)議選擇器304的示例Service Locator 使用了服務(wù)定位器設(shè)計模式 RemotingLocator, WebServiceLocator， WCFLocator IPlaceOrder ipo =(IPlaceOrder) ServiceLocator. GetService (typeof (IPlaceOrder))對于所有或單個服務(wù)可以對應(yīng)一個或多個配置的協(xié)議。在本實施 例中，其對應(yīng)關(guān)系可以由服務(wù)開發(fā)人員或平臺開發(fā)人員指定，也可以根據(jù)系統(tǒng)環(huán)境，如系統(tǒng)默認(rèn)的協(xié)議進(jìn)行選擇。協(xié)議客戶端306,用于采用所確定的協(xié)議實現(xiàn)客戶端代理，以實現(xiàn)傳遞包括所述業(yè)務(wù)信息的信息。如圖4所示為協(xié)議客戶端306和協(xié)議服務(wù)器端308的示意圖。下 文將結(jié)合圖4對協(xié)議的兩端進(jìn)行詳細(xì)說明。對于本發(fā)明協(xié)議無關(guān)的SOA系統(tǒng)300,其服務(wù)器端包括協(xié)議服務(wù)器端308,用于采用所確定的協(xié)議實現(xiàn)服務(wù)器端代理， 以實現(xiàn)傳遞包括所述業(yè)務(wù)信息的信息。業(yè)務(wù)處理器310,用于處理所接收的業(yè)務(wù)信息。如圖6所示為業(yè)務(wù)處理器310的示意圖。下文將結(jié)合圖6對業(yè)務(wù) 處理器310進(jìn)行詳細(xì)說明。由上可以看出，通過編程代理302和協(xié)議選擇器304在選擇服務(wù) 的具體配置項實現(xiàn)代理之前，還根據(jù)配置的協(xié)議選擇所采用的協(xié)議。 通過增加協(xié)議選擇過程實現(xiàn)具體的服務(wù)和協(xié)議相分離。而協(xié)議的兩 端保證了分布式服務(wù)的通信。最后由服務(wù)器的業(yè)務(wù)處理器310完成 業(yè)務(wù)邏輯的執(zhí)行，最終達(dá)到了分布式服務(wù)架構(gòu)的目的。下面結(jié)合圖4對協(xié)議的兩端進(jìn)行詳細(xì)說明，協(xié)議的兩端包括協(xié)議 客戶端306和協(xié)議服務(wù)器端"8,井中協(xié)議客戶端306，包括代理實現(xiàn)選擇器3062,用于選擇代理實現(xiàn)。在本實施例中包括查看并選取下文對客戶端代理3066描述中的代理實現(xiàn)庫3064，用于提供包括對應(yīng)不同協(xié)議的不同代理實現(xiàn)。代理實現(xiàn)庫中存儲了不同協(xié)議的不同代理實現(xiàn)，例如是不同的配 置文件。在本實施例中，為每個服務(wù)都預(yù)設(shè)了特定的配置文件，配 置文件中包含了端口號和通道類型等代理實現(xiàn)細(xì)節(jié)?？蛻舳舜?066，用于采用所選取的對應(yīng)所確定的協(xié)議的代理 實現(xiàn)，實現(xiàn)客戶端代理。例如，當(dāng)采用.NET Remoting客戶端^理時，其示例如下 public class PlaceOrderRemotingProxy : MarshalByRefObject/* or RemoteCUentProxy */， IPlaceOrder { public object Do(string customerID， OrderData order) { PlaceOrder po = new PlaceOrder(); // or other standard method to access server side object. po. CustomerID = customerID; // here we transform BusinessData to BusinessEntity. OrderEntity entity = new OrderEntity; entity.Order ID = order.Order ID; po. Do(); J J又如，當(dāng)采用WebService客戶端4氣理時，其示例如下 public class PlaceOrderWSProxy : HttpSoapClientProxy/* or other goody */， IPlaceOrder { public object Do (string customerID， OrderData order) { return base. Invoke (new object [] {customerlD, order}); } }'生成客戶端代理3066的同時也自動生成asmx格式的服務(wù)器存 根，以及所有微軟Web Service編程模型要求程序員手寫或被開發(fā) 工具自動生成，正確運(yùn)行所需的代碼。所述生成方法和步驟參見本 申請人:的申請?zhí)枮?008 1 0227 043.8的中國專利申請，此處不再贅述。在另一個實施例中，協(xié)議客戶端306還包括客戶端接口 3068, 用于提供傳遞信息的標(biāo)準(zhǔn)化接口 。如圖5所示為帶客戶端接口 3068 的實施例的協(xié)議客戶端306的示意圖?？蛻舳私涌?3068可以看成是方法的集合。本實施例中用C并語言 中的interface來實現(xiàn)。在本實施例中，不同協(xié)議最終^提供的信息 都是預(yù)設(shè)的統(tǒng)一格式，在客戶端接口 3068進(jìn)行強(qiáng)制轉(zhuǎn)換。以下是客戶端接口 3068的示例 // Client-Server Interaction Protocol. public interface IPlaceOrder { Object Do(string customerID， OrderData order); - } 〃說明,訂單數(shù)據(jù)(OrderData )不是訂單實體(OrderEntity)。 由上完成了采用所確定的協(xié)議實現(xiàn)包括傳遞所述業(yè)務(wù)信息的協(xié)議客戶端的代理。其中客戶端接口 3068為協(xié)議兩端交互提供了標(biāo)準(zhǔn) 化的4妄口 。圖4中所示的協(xié)議服務(wù)器端模塊308用于實現(xiàn)在服務(wù)器端的代 理。在本實施例中作為協(xié)議的服務(wù)器端，可采用目前通用的服務(wù)器 端存根。以實現(xiàn)例如對象的反序列化等功能。由上可以看出，協(xié)議的兩端實現(xiàn)了通信兩端的代理機(jī)制。即實現(xiàn) 了 SOA分布式架構(gòu)的通信部分。下面結(jié)合圖6對協(xié)議無關(guān)的SOA系統(tǒng)300的業(yè)務(wù)處理310進(jìn)行詳 細(xì)說明。如圖6所示業(yè)務(wù)處理310包括 業(yè)務(wù)操作3102，用于讀取業(yè)務(wù)信息；在本實施例中，讀取的業(yè)務(wù)信息包括業(yè)務(wù)數(shù)據(jù)(CustomerID和 OrderData)和調(diào)用的方法(Do )。以下是業(yè)務(wù)操作3102的示例 // Full Generated by Business Operation Metadata [Service] public class PlaceOrder : BusinessOperation { public string CustomerID {get set …；} public OrderEntity Order {get …；set …；} public override object Do 0 { IPlaceOrderStrategy strategy = PlaceOrderSelector. Select (this); stragegy. Do(this); } }業(yè)務(wù)邏輯選擇器3104,用于選擇所要調(diào)用的業(yè)務(wù)邏輯。 在本實施例中，方法(Do)的實現(xiàn)有多種業(yè)務(wù)邏輯。例如對不同 客戶可以有不同的費(fèi)用折扣率。以下是業(yè)務(wù)邏輯選擇器3104的示例 // Generate initial code public partial class PlaceOrderSelector { public static IPlaceOrderStrategy Select (PlaceOrder order) { // please write your code here. - } }業(yè)務(wù)接口 3106,用于提供調(diào)用業(yè)務(wù)邏輯的接口。業(yè)務(wù)接口 3106和客戶端接口 3068 —樣，也可以看成是方法(Do)的集合，其暴露了業(yè)務(wù)邏輯實現(xiàn)的接口?？梢圆捎?#的Interface 實現(xiàn)。以下是服務(wù)器端業(yè)務(wù)接口 3106的示例 public interface IPlaceOrderStrategy { object Do(PlaceOrder placeOrder); }業(yè)務(wù)邏輯實現(xiàn)3108,用于根據(jù)所述業(yè)務(wù)邏輯的接口調(diào)用業(yè)務(wù)邏 輯處理所讀取的業(yè)務(wù)信息。在本實施例中，方法(Do )有2個訂單業(yè)務(wù)邏輯 (PlaceOrderStrategy ) 的業(yè)務(wù)邏輯實現(xiàn)。分別是 PlaceOrderStrategyl和Place0rderStrategy2。以下是PlaceOrderStrategyl的示例 // Generate initial code public partial class PlaceOrderStrategyl : IPlaceOrderStrategy { public object Do (PlaceOrder po) {} }以下是Place0rderStrategy2的示例 // Generate initial code public partial class Place0rderStrategy2 : IPlaceOrderStrategy { public object Do (PlaceOrder po)由上就完成了服務(wù)在服務(wù)器上的實現(xiàn)，在本實施例中即為遠(yuǎn)程對 象代碼在服務(wù)器上的運(yùn)行。然后將運(yùn)行得到的結(jié)果返回給客戶端即可。以上的各個代碼示例采用的是0#語言，但不難理解的是，本發(fā)明的系統(tǒng)也可以用其它語言實現(xiàn)。下面結(jié)合附圖和在客戶端下訂單的示例(參見系統(tǒng)實施例中的客戶端程序示例)對協(xié)議無關(guān)的SAO業(yè)務(wù)處理方法進(jìn)行詳細(xì)說明。如圖7所示為協(xié)議無關(guān)的SAO業(yè)務(wù)處理方法的流程圖，包括以下 步驟步驟702,應(yīng)用程序調(diào)用S0A。對于應(yīng)用程序來說，SOA的分布式服務(wù)是透明的。也就是說，雖 然在本實施例中，下訂單的方法(Do)的真正的業(yè)務(wù)邏輯實現(xiàn)是在 服務(wù)器上實現(xiàn)的。但是對于客戶端的應(yīng)用程序來說，并沒有什么不 同。所述方法在客戶端的處理，包括 步驟704，接收業(yè)務(wù)信息和配置的協(xié)議。從客戶端的應(yīng)用程序接收到需要處理的業(yè)務(wù)信息和配置的協(xié)議。 在本實施例中，業(yè)務(wù)信息包括業(yè)務(wù)數(shù)據(jù)和方法名。配置的協(xié)議是對 應(yīng)于服務(wù)預(yù)設(shè)的。步驟706，根據(jù)配置的協(xié)議確定所使用的協(xié)議。本實施例中，使用的協(xié)議可以是分布式協(xié)議任意一種，如.NET Remoting、 WebService或WCF。步驟708，采用所確定的協(xié)議實現(xiàn)客戶端代理，實現(xiàn)傳遞包括所 述業(yè)務(wù)信息的信息。針對不同的服務(wù)，不同的協(xié)議有具體的代理實現(xiàn)。下文將結(jié)合圖 8對協(xié)議在兩端的實現(xiàn)進(jìn)行詳細(xì)說明。在服務(wù)器端，包括步驟710,采用所確定的協(xié)議實現(xiàn)服務(wù)器端的代理，實現(xiàn)傳遞包 括所述業(yè)務(wù)信息的信息。步驟712，處理所接收的業(yè)務(wù)信息。服務(wù)器端接到業(yè)務(wù)信息后，利用服務(wù)器上的業(yè)務(wù)邏輯進(jìn)行處理，得到處理結(jié)果。下文將結(jié)合圖9 對服務(wù)器上的業(yè)務(wù)處理進(jìn)行詳細(xì)說明。步驟714,返回處理結(jié)果。將處理結(jié)果返回給調(diào)用S0A的應(yīng)用程 序即可。由上可以看出，步驟704和步驟706在服務(wù)的通信之前提供了協(xié) 議選擇。而步驟708和步驟710為具體通信的步驟。步驟712完成 了服務(wù)在服務(wù)器上的實現(xiàn)。最終由步驟714返回結(jié)果，完整的實現(xiàn) 了 S0A的服務(wù)的分布式部署。而服務(wù)組件和具體的協(xié)議之間并沒有 直接綁定，對于客戶端的應(yīng)用程序來說，整個過程是透明的，而對 于服務(wù)開發(fā)人員來說，同樣的不需要考慮協(xié)議的實現(xiàn)。從而實現(xiàn)了 SOA和協(xié)議的無關(guān)。下面結(jié)合圖8對實現(xiàn)通信的步驟708和步驟710進(jìn)行詳細(xì)說明。客戶端的處理步驟包括步驟7082，選取代理實現(xiàn)。對于同一個協(xié)議，不同服務(wù)可能需 要不同的代理實現(xiàn)。在本步驟中將為服務(wù)選擇具體的代理實現(xiàn)。在 本實施例中，代理實現(xiàn)和服務(wù)的對應(yīng)關(guān)系是預(yù)設(shè)的?？梢杂煞?wù)開 發(fā)人員或平臺開發(fā)人員指定，也可以根據(jù)平臺環(huán)境進(jìn)行選擇。步驟7084,讀取所選取的包括對應(yīng)協(xié)議的代理實現(xiàn)。根據(jù)選擇 的代理實現(xiàn)，讀:f又代理實現(xiàn)的具體內(nèi)容。本實施例中，代理實現(xiàn)包 含了實現(xiàn)通信的具體細(xì)節(jié)，例如端口號和通道類型等。不難理解， 代理實現(xiàn)可以是采用配置文件的方式，也可以是其它的可以描述通 信實現(xiàn)細(xì)節(jié)的其它方式。步驟7086,釆用所選取的對應(yīng)協(xié)議的代理實現(xiàn)，實現(xiàn)客戶端代 理。因為代理實現(xiàn)已經(jīng)描述了通信的實現(xiàn)細(xì)節(jié)，本步驟可以完整的 實現(xiàn)客戶端的代理。還包括在客戶端偽裝為遠(yuǎn)程對象并向本地提供 遠(yuǎn)程對象相同的4^口。在另一個實施例中，步驟7086后還包括將傳遞的信息強(qiáng)制轉(zhuǎn) 化成為預(yù)設(shè)的標(biāo)準(zhǔn)格式。由此實現(xiàn)了協(xié)議兩端交換信息格式的標(biāo)準(zhǔn) 化。服務(wù)器端的處理步驟包括；步驟710,采用所選擇的協(xié)議實現(xiàn)服務(wù)器端的代理。包括反序列 化遠(yuǎn)程對象等通信的具體實現(xiàn)。由上可以看出，步驟708的三個子步驟完成了在客戶端建立通信 的步驟。步驟7 08配合步驟710完成了協(xié)議兩端之間通信的建立。下面結(jié)合圖9詳細(xì)說明實現(xiàn)業(yè)務(wù)信息處理的步驟712的流程，包 括以下步驟步驟7122,讀取業(yè)務(wù)信息。在本實施例中，包括讀取業(yè)務(wù)數(shù)據(jù) (CustomerID和OrderDate )和方法名(方法Do)等。 步驟7124，選擇所要調(diào)用的業(yè)務(wù)邏輯。對于同 一個方法可以有多個實現(xiàn)的業(yè)務(wù)邏輯。在這里實現(xiàn)了業(yè)務(wù) 邏輯的選#^。例如在本實施例中，方法(Do)可以有2個具體的業(yè) 務(wù)邏輯實現(xiàn)，即PlaceOrderStrategyl和Place0rderStrategy2，通 過本步驟確定出具體所選擇的業(yè)務(wù)邏輯。步驟7126，確定調(diào)用業(yè)務(wù)邏輯的接口。接口是多個方法(Do) 的集合。通過調(diào)用業(yè)務(wù)邏輯的實現(xiàn)接口就可以調(diào)用其中的方法(Do )。步驟7128,根據(jù)所述業(yè)務(wù)邏輯的接口調(diào)用業(yè)務(wù)邏輯處理所讀取 的業(yè)務(wù)信息。由上可以看出，經(jīng)過這四個步驟完成了業(yè)務(wù)信息的整個處理過程。以上所述僅為本發(fā)明的較佳實施例而已，并不用以限制本發(fā)明， 凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改進(jìn) 等，均應(yīng)包含在本發(fā)明的保護(hù)范圍之內(nèi)。
權(quán)利要求
1.一種協(xié)議無關(guān)的SOA系統(tǒng)，其特征在于，包括客戶端和服務(wù)器端，其中客戶端包括編程代理(302)，用于接收業(yè)務(wù)信息和配置的協(xié)議；協(xié)議選擇器(304)，用于根據(jù)所述配置的協(xié)議確定所使用的協(xié)議；協(xié)議客戶端(306)，用于采用所確定的協(xié)議實現(xiàn)客戶端代理，以傳遞包含所述業(yè)務(wù)信息的信息；服務(wù)器端包括協(xié)議服務(wù)器端(308)，用于采用所確定的協(xié)議實現(xiàn)服務(wù)器端代理，以傳遞包含所述業(yè)務(wù)信息的信息；業(yè)務(wù)處理器(310)，用于處理所接收的業(yè)務(wù)信息。
2. 如權(quán)利要求1所述系統(tǒng)，其特征在于，所述協(xié)議客戶端(306 )包括代理實現(xiàn)選擇器(3062 ),用于選取代理實現(xiàn)； 代理實現(xiàn)庫(3064 ),用于提供對應(yīng)不同協(xié)議的不同代理實現(xiàn)； 客戶端代理(3066 ),用于采用所選取的對應(yīng)所確定的協(xié)議的代理實 現(xiàn)，實現(xiàn)客戶端代理。
3. 如權(quán)利要求1或2所述系統(tǒng)，其特征在于，所述協(xié)議客戶端(306 )還包括客戶端接口 (3068 ),用于將包含所述業(yè)務(wù)信息的信息的格式進(jìn)行標(biāo) 準(zhǔn)化。
4. 如權(quán)利要求2所述系統(tǒng)，其特征在于，所述業(yè)務(wù)處理器(310)包括'.業(yè)務(wù)操作(3102),用于讀取業(yè)務(wù)信息； 業(yè)務(wù)接口 (3106),用于提供調(diào)用業(yè)務(wù)邏輯的接口； 業(yè)務(wù)邏輯實現(xiàn)(3108),用于根據(jù)所述業(yè)務(wù)邏輯的接口調(diào)用業(yè)務(wù)邏輯 處理所讀耳又的業(yè)務(wù)信息。
5. 如權(quán)利要求4所述系統(tǒng)，其特征在于，所述業(yè)務(wù)處理器(310)還 包括業(yè)務(wù)邏輯實現(xiàn)選擇器(3104),用于選擇所要調(diào)用的業(yè)務(wù)邏輯。
6. —種協(xié)議無關(guān)的SOA的業(yè)務(wù)處理方法，其特征在于，包括客戶端和 服務(wù)器端的處理，其中客戶端的處理包括A, 接收業(yè)務(wù)信息和配置的協(xié)議；B, 才艮據(jù)配置的協(xié)議確定所使用的協(xié)議；C, 采用所確定的協(xié)議實現(xiàn)客戶端代理，傳遞包含所述業(yè)務(wù)信息的信息； 服務(wù)器端的處理包括D，采用所確定的協(xié)議實現(xiàn)服務(wù)器端代理，傳遞包含所述業(yè)務(wù)信息的信自 E，處理所接收的業(yè)務(wù)信息。
7. 如權(quán)利要求6所述方法，其特征在于，步驟C所述采用所確定的協(xié) 議實現(xiàn)客戶端代理的步驟包括Cl,選取代理實現(xiàn)；C2，讀取所選取的包括對應(yīng)協(xié)議的代理實現(xiàn)；C3,采用所讀取的包括對應(yīng)所確定協(xié)議的代理實現(xiàn)，實現(xiàn)客戶端的代理。
8. 如權(quán)利要求6或7所述方法，其特征在于，步驟C所述傳遞前還包括將所要傳遞的包含所述業(yè)務(wù)信息的信息的格式進(jìn)行標(biāo)準(zhǔn)化處理。
9. 如權(quán)利要求6所述方法，其特征在于，步驟E中處理所接收的業(yè)務(wù) 信息的步驟包括El，讀取業(yè)務(wù)信息；E2,確定調(diào)用業(yè)務(wù)邏輯的接口；E3，根據(jù)所述業(yè)務(wù)邏輯的接口調(diào)用業(yè)務(wù)邏輯處理所讀取的業(yè)務(wù)信息。
10. 如權(quán)利要求9所述方法，其特征在于，所述步驟E1和E2之間還 包括選擇所要調(diào)用的業(yè)務(wù)邏輯。
全文摘要
本發(fā)明提供了一種協(xié)議無關(guān)的SOA系統(tǒng)，包括客戶端和服務(wù)器端，其中客戶端包括編程代理，用于接收業(yè)務(wù)信息和配置的協(xié)議；協(xié)議選擇器，用于根據(jù)所述配置的協(xié)議確定所使用的協(xié)議；協(xié)議客戶端，用于采用所確定的協(xié)議實現(xiàn)客戶端代理，以傳遞包含所述業(yè)務(wù)信息的信息；服務(wù)器端包括協(xié)議服務(wù)器端，用于采用所確定的協(xié)議實現(xiàn)服務(wù)器端代理，以傳遞包含所述業(yè)務(wù)信息的信息；業(yè)務(wù)處理器，用于處理所接收的業(yè)務(wù)信息。還相應(yīng)提供了一種協(xié)議無關(guān)的SOA的業(yè)務(wù)處理方法。使用本發(fā)明，可以實現(xiàn)SOA架構(gòu)的服務(wù)和協(xié)議無關(guān)。
文檔編號H04L29/06GK101409717SQ200810227919
公開日2009年4月15日 申請日期2008年12月1日 優(yōu)先權(quán)日2008年12月1日
發(fā)明者豪 方 申請人:用友軟件股份有限公司