一種基於消息的分布式系統以及在其中通信的方法
2023-07-06 16:51:36 5
專利名稱：一種基於消息的分布式系統以及在其中通信的方法
技術領域：
本發明涉及網絡通信領域，尤其涉及一種基於消息的分布式系統，以及在所述系統中利用消息通信的方法。
背景技術：
隨著IP(Internet Protocol，網際協議)網絡的廣泛延伸和帶寬不斷增長，網絡提供了更大的能力，通過網絡對系統進行分布部署，大大提高了系統的性能和靈活性，分布式軟體系統架構是當今很多系統的基本特徵。分布式作為一個系統級的架構，雖然對於不同的系統具有不同的考慮，但都有一個最基本需求，即分布式調用，具體地說，客戶端和服務端可以分布在IP網絡中，並且客戶端和服務端的程序不必使用相同的編譯環境和運行環境，如客戶端可以使用java(一種計算機語言)編寫，服務端使用C++(一種計算機語言)語言編寫，客戶端可以運行在基於Intel(美國英特爾公司)的CPU(中央處理器)的Windows(美國微軟公司生產的「視窗」作業系統)環境，服務端運行在SUN Solaris(美國太陽公司生產的作業系統)上。
實現分布式調用需要考慮的幾個關鍵的因素包括通信模式、對象解析、編碼方式等。
通信模式對於比較複雜的系統各模塊既是服務端提供服務，同時也是客戶端使用其他模塊的服務，通信模式是針對一個具體的場景，有如下模式遠程過程調用—客戶端發送請求給服務端，然後等待響應，即同步通信。
消息傳遞—客戶機發送一個請求，並不期待一個響應。
異步回調—客戶機以上述兩種方式之一調用服務，雙方交換角色，進行回調，這種模式可以以前述兩種方式中的任一種構建。
對象解析由於系統模塊的分布式部署，不再在一個進程甚至一個機器上，調用前必須有通信對象的名稱，這個名稱應該是邏輯上比較獨立的，系統中保持唯一，不與物理資源綁定，避免在部署發生變化後需要修改程序，因此一般需要一個命名服務提供名字解析服務。如CORBA(Common Object RequestBroker Architecture，公共對象請求代理體系結構)使用名字(通過命名伺服器)提供對象定位，DCOM(Distributed Component Object Model，分布式組件對象模型)使用系統註冊提供名稱服務，J2EE(J2EE是一個開放的、基於標準的開發和部署的平臺)使用JNDI(JNDI，Java Naming and DirectoryInterface，Java命名和目錄接口)提供名字服務。
編碼方式通信雙方由於不一定是使用相同的程式語言和具有相同的CPU，所以對字節序的理解不一樣，如Java都是BigEndian(大端模式、高位優先、正向字序、網絡字序、UNIX字序)，C++語言在Intel上是LittleEndian(小端模式、低位優先、逆向字序、INTEL字序、NT字序)，在PowerPC(一種個人臺式計算機)上是BigEndian；除了字節序外，結構對象的內存排列(Layout)也不一致。分布式調用雙方需要有一種一致的編碼方式，常用的編碼方式如AS N.1(Abstract Syntax Normal dot 1，一種使用比較廣泛的數據編碼規範)和CDR(Common Data Representation，公共數據表示，CORBA中使用的數據編碼方式)。
在現有技術中，CORBA是很成熟的一種分布式開發技術。如圖1所示，基於CORBA開發步驟通常可概括為1.用IDL(Interface Difinition Language，CORBA中用於描述接口的語言)文件定義客戶端(Client)和服務端(Server)的應用編程接口(API)；2.編譯IDL文件，生成客戶端代理(stub)代碼、服務端骨架(skeleton)代碼；3.在代理和骨架的基礎上分別實現服務端和客戶端。
其中，圖中ORB(Object Remote Broker)Core是CORBA裡面的對象遠程代理核心。
然而，在上述現有的以CORBA作為分布式開發的技術中存在如下的缺點1.使用複雜，學習成本高。直接使用CORBA開發，需要學習的知識很多，對大多數的C++程式設計師來說，比較困難。
2.CORBA支持類似C++的調用方式，實現一般OO(Object Oriented，面向對象的)系統比較方便，但對於一些領域，需要並發處理大量消息，因此，通常不需要複雜的OO建模，而是需要異步傳遞消息和通知。
3.只支持單一的編碼方式。使用CORBA技術時，在用戶定義了IDL結構後，自動使用CDR編碼，而對於一些移植系統，可能有其他的編碼方式，如ASN.1，這時需要在IDL和其他編碼方式之間作轉換。
4.生成的代碼量大，佔用的內存和硬碟空間大。對於一些非伺服器上的應用，如嵌入式單板，存儲器容量有限，使用IDL定義接口導致大量的代碼，這些代碼要編譯到系統中，造成目標文件很大。
5.無法在支持HA(高可用性)和LB(負載平衡)等電信要求。使用CORBA技術時，直接使用IDL定義接口，由於每個IDL直接編譯成代碼(包括編解碼/通信處理)，這些代碼散布在系統各處，而且這些代碼也是用戶不能修改的，用戶無法在一個地方進行統一處理，而HA、LB等高可用性要求系統能在一些點進行處理，如入口或出口。
發明內容
本發明的目的是提供一種基於消息的分布式系統，該系統可以降低分布式開發的難度。本發明還提出了一種在所述系統中利用消息進行通信的方法。
為此，本發明提供以下技術方案一種基於消息的分布式系統，所述系統包括至少一個節點，所述節點包括至少一個完成特定功能的模塊，所述模塊包括至少一個服務接入點，用於接收服務請求消息，並根據所述服務請求消息完成所需服務；消息發送器，用於將服務請求消息發送至目的服務接入點，請求所需服務。
所述服務接入點具有在所述系統內唯一的服務接入點標識；所述消息中包含目的服務接入點的標識。
所述消息發送器包括同步消息發送器，用於將同步消息發送至目的服務接入點，請求所需服務，並將服務結果返回給發送者；異步消息發送器，用於將異步消息發送至目的服務接入點，請求所需服務，但不負責將服務結果返回給發送者。
所述服務接入點包括至少一個服務執行單元，根據服務請求消息完成所需服務；消息接收和調度單元，接收服務請求消息，並分發給相應的服務執行單元，將服務結果返回給服務請求方。
所述消息接收和調度單元具體包括同步消息接收和調度單元，接收服務請求方的同步消息，調用相應的服務執行單元完成所需服務，將服務結果返回給服務請求方。
異步消息接收和調度單元，接收服務請求方的同步消息，並分發給相應的服務執行單元，待所述服務執行單元完成服務後，創建新消息，將服務結果放在所述新消息中通過消息發送器發送給服務請求方。
所述節點還包括名字伺服器，用於提供名字服務；所述服務接入點將該服務接入點的標識及訪問地址註冊到所述名字伺服器；所述消息發送器根據消息中的目的服務接入點標識從名字伺服器得到目的服務接入點的訪問地址，將消息發送至目的服務接入點。
所述消息包括消息頭和消息體，所述消息頭中至少包含發送所述消息的服務接入點標識，以及接收所述消息的服務接入點標識，所述消息體包含有服務需要的數據。
所述服務接入點標識由節點號、模塊號和服務接入點號組成。
所述模塊還設有一個備份模塊。
所述模塊還包括服務接入點列表存儲器，用於存儲所述模塊中的所有服務接入點。
所述模塊還包括一個服務接入點管理單元，用來管理所述模塊中的所有服務接入點。
本發明還提供一種在分布式系統中利用消息進行通信的方法，用於第一服務接入點向第二服務接入點請求服務，所述方法包括以下步驟1)所述第一服務接入點通過消息發送器向所述第二服務接入點發送消息；
2)所述第二服務接入點接收消息，執行所需服務；3)所述第二服務接入點返回服務結果。
所述消息為同步消息，所述步驟2)具體為所述第二服務接入點接收消息，調用相應服務執行單元，完成所需服務。
所述消息為異步消息，所述步驟2)具體為所述第二服務接入點將所述消息發送給相應的服務執行單元，所述服務執行單元完成所需服務。
所述步驟3)具體為所述第二服務接入點創建新的消息，將服務結果放入所述新消息中，通過消息發送器發送給所述第一服務接入點。
所述消息包括消息頭和消息體，所述消息頭中至少包含發送所述消息的服務接入點標識，以及接收所述消息的服務接入點標識，所述消息體包含有服務需要的數據。
所述服務接入點標識由節點號、模塊號和服務接入點號組成。
所述模塊還設有一個備份模塊，所述步驟1)具體為所述第一服務接入點通過消息發送器向第二服務接入點請求服務，所述消息發送器向位於所有模塊的所述第二服務接入點分別發送請求所述服務的消息。
所述步驟3)具體為位於非備份模塊的所述第二服務接入點返回服務結果。
由於本發明的系統採用了節點-模塊-服務接入點的分層結構，發送消息統一使用消息發送器，接收消息統一使用服務點接入單元，用戶不用關心系統的具體信息，只需要知道對端的接入服務點標識就能夠完成在分布式環境下的通信，簡化了分布式開發的步驟，降低了分布式開發的難度，提高了系統的可靠性，提高了系統的可擴充性，例如可以通過統一的消息處理支持統一的消息日誌，實現HA方案。
圖1是基於CORBA的通常開發步驟示意圖；圖2是本發明中所述系統的結構示意圖；
圖3是節點級聯過程的流程圖；圖4是主節點與一個從節點級聯時的名字服務結構示意圖；圖5是級聯後主節點上看到的名字服務的目錄樹示意圖；圖6是級聯後從節點上看到名字服務的目錄樹示意圖；圖7是根據本發明優選實施方案中節點的結構示意圖；圖8是用C++語言實現一個模塊實例的結構示意圖；圖9是同步調用流程示意圖；圖10是異步調用流程示意圖；圖11是本系統在HA方案中應用的示意圖。
具體實施例方式
下面結合附圖和具體實施例對本發明作進一步說明，但不作為對本發明的限定。
圖2是根據本發明優選實施方案的分布式系統的結構示意圖。如圖2所示，在系統內分布有多個節點，在節點中包括多個完成特定功能的模塊。
本發明所述的節點分布在廣域網內或區域網內。在圖2中，節點1為主節點，其他節點是從節點，主節點是在邏輯上定義的，例如可以根據實際需要把其中一個獨立的節點設置成主節點，其餘節點設置成從節點。從節點和主節點通過級聯的方式聯合，這將在本文的下面進行詳細描述。每個節點都有一個唯一的「節點號」，以和其他節點相區別。每個節點都包括一個名字伺服器模塊，所有從節點都註冊到主節點的名字伺服器模塊上，節點間通過名字伺服器模塊級聯訪問。這將在下面進行詳細描述。
圖3描述了從節點的名字服務級聯到主節點名字服務的過程。
如圖3所示，在級聯前，所有節點的名字伺服器下都只有一個根目錄節點Node0(節點0)，級聯過程可概括為步驟101在主節點名字服務的根下面創建一個目錄節點Node1(節點1)，並連接到自己的Node0；步驟102在主節點名字服務的根下面創建一個目錄節點Node2(節點2)，並連接到第一個從節點的Node0；步驟103在從節點名字服務的根下創建一個目錄節點Primary(主目錄節點)，連接到主節點的根上；重複步驟102、103兩步增加新的從節點，從節點號依次增加，如Node3、Node4、Node5......。
圖4是主節點與一個從節點級聯時的名字服務的結構示意圖。
本領域的技術人員通過上面的描述和公知的常識，應該理解創建節點、目錄節點以及這些節點如何通過名字伺服器模塊聯合在一起的具體實現過程，因此，在這裡不再贅述。
圖5是級聯後，從主節點的名字服務看到的名字服務目錄樹的示意圖。在圖6中，主節點名字服務目錄樹的根(Root)下有內容相同的Node0和Node1，Node1下是主節點的所有模塊名目錄，模塊名目錄下面是該模塊所有服務接入點(SAP)的目錄(在下文中將對SAP詳細描述)。其他節點的目錄連接在主節點名字服務目錄樹的根下，其結構與Node1相同，如圖中的Node2、Node3。
圖6是級聯後，在從節點上的名字服務看到的名字服務目錄樹的示意圖。該從節點的Root目錄下有一個Node0，Node0下是該從節點的所有模塊名目錄，模塊名目錄下面是該模塊所有SAP的目錄。該從節點的根目錄下還有一個Primary節點，在Primary節點下面連接著主節點和其他從節點的根目錄。
圖7是根據本發明優選實施方式的節點的結構示意圖。圖中，1、服務接入點，2消息發送器。如圖7和圖2所示，在該優選的實施方式中，各個節點中包括一個名字伺服器以及多個完成特定功能的模塊。每個模塊都包括一個消息發送器2和至少一個服務接入點1。
在該實施方式中，消息發送器包括同步消息發送器和異步消息發送器。SAP則包括至少一個服務執行單元和消息接收和調度單元。消息接收和調度單元包括同步消息接收和調度單元。
SAP是模塊對外的接口，都有一個在系統內唯一的SAP標識。SAP標識是對其進行訪問的外部標識。SAP標識可以是系統內唯一的全局分層地址，具體地說，分層地址包括節點號、模塊號、SAP號。模塊的所有SAP都通過SAP標識註冊到與其相對應的節點的名字伺服器上。例如，在圖6中，各模塊以及其包含的SAP都掛在相應的Node0下面。此外，在名字服務模塊上還記錄了實際要訪問地址(如物理地址)。在具體訪問時，例如在訪問時通過名字服務根據服務SAP的分層地址，得出它的實際訪問地址，然後根據實際訪問地址訪問。
在模塊中，SAP標識一般保存在特定位置，例如在本發明的一個實施方式中，SAP標識保存在模塊中的一個專用的SAP列表存儲器中。在系統初始啟動時，模塊會訪問SAP列表存儲器，並根據SAP存儲器中的記錄，對記錄的SAP進行初始化。模塊在關閉時會根據SAP存儲器中的記錄註銷這些SAP。當然，本發明並不局限於此，本領域的技術人員應該理解還具有許多其他的存儲方法。
同步消息發送器發送同步消息至目的SAP，請求所需服務，並將服務結果返回給發送者。異步消息發送器，發送異步消息至目的SAP，請求所需服務，但不負責將服務結果返回給發送者。同步消息接收單元接收服務請求方的同步消息，調用相應的服務執行單元完成所需服務，將服務結果返回給服務請求方。異步消息接收和調度單元，接收服務請求方的同步消息，並分發給相應的服務執行單元，待所述服務執行單元完成服務後，創建一個新的消息，將服務結果放在新的消息中通過消息發送器發送給服務請求方。
所述服務接入點在所述系統內具有唯一的全局分層地址都以其全局分層地址註冊到名字伺服器模塊，消息發送器根據註冊到名字伺服器上的全局分層地址向服務接入點發送消息。由於採用了全局分層地址，不同節點中的模塊也可以通過上述相同的方式互相進行訪問。
在該實施方式中，同步消息和異步消息都包括消息頭和消息體，消息頭中至少包含客戶端模塊的地址、服務端地址以及服務端模塊的SAP號，消息體則封裝調用數據。
在下文中，為了便於描述，將發送消息的模塊稱為客戶端模塊，將接受消息的模塊稱為服務端模塊。各模塊既可以是客戶端模塊，也可以是服務端模塊。
在進行同步調用時，客戶端模塊的消息發送器(具體地說，是通過同步消息發送器)向服務端模塊的SAP發送同步消息。服務端模塊通過其具有的SAP(具體地說，是接收和調度單元的同步接收和調度單元)接收該同步消息，並將所接收到的同步消息發送到相應的執行單元，執行單元根據接收到的同步消息的消息體中的具體內容來完成相應的功能操作，並將操作的結果返回到客戶端模塊。在這裡返回的結果同樣是由客戶端模塊的SAP的接收和調度單元來接收的。在進行異步調用時，客戶端模塊的消息發送器(具體地說，是通過異步消息發送器)向服務端模塊的SAP發送異步消息，同樣，服務端模塊通過其具有的異步消息接收和調度單元接收該異步消息，並將所接收到的異步消息發送到相應的執行單元，該執行單元根據接收到的異步消息體中的具體內容來完成相應的功能操作。但是，服務端模塊在完成相應的操作後，並不會給客戶端模塊返回操作結果。但是，服務端的SAP會從接收到的異步消息中獲取客戶端源地址，並對其進行保存。之後，客戶端的SAP在任意需要的時候，可以創建新的消息，並將服務端模塊的服務結果放入新的消息中，根據該客戶端的源地址，向客戶端模塊返回操作的結果。在這裡，在調用過程中所使用的數據可以是二進位數據，並可以使用分布式開發中的各種編碼方式，例如使用CDR或ASN.1編碼方式。
此外，各模塊還可以包括一個管理SAP的單元，用來完成一些所有SAP的共性的管理功能。
在本發明的另外一個優選實施方式中，在節點中還可以設有一個備份模塊，備份模塊同原始模塊完全相同，備份模塊的模塊號也同該模塊的相同。在該實施方式中，上述分層地址還可包括一個「群內號」，用於區分原始模塊和備份模塊。
下面描述一種在根據本發明上述實施方式描述的分布式系統中利用消息進行通信的方法。
首先，上述節點中的一個(在這裡稱為第一節點)的一個模塊(在這裡稱為第一模塊)通過與其對應的消息發送器向另外一個節點(在這裡稱為第二節點)的一個模塊(在這裡稱為第二模塊)發送消息。第二模塊通過與其對應的SAP接收該消息，並根據所接受的消息是同步消息還是異步消息來執行相應操作。其中在第一模塊向第二模塊發送的消息為同步消息時，第二模塊向第一模塊返回操作結果，在第一模塊向第二模塊發送的消息為異步消息時，第二模塊根據所述消息執行相應操作，但不向第一模塊返回操作結果，而僅保存第一模塊的地址。在需要的時候，第二模塊可以根據包括的第一模塊的地址向第一模塊返回操作結果。對於具體的操作過程可參照上文中的描述。
在這裡雖然列舉了兩個節點之間的兩個模塊之間進行通信的方法，但是本領域的技術人員應該認識到在同一節點中的兩個不同模塊也可以進行上述相同的操作。此外，對於上述操作的具體原理和細節已經在前面描述本發明優選實施方式的分布式系統時進行了詳細的論述，因此，在這裡不再贅述。
為了使本領域的技術人員更加完整地理解本發明，下面以C++語言編程為例來詳細描述實現本發明優選實施方式的模塊的細節。
為了使本發明的技術人員更容易地理解本發明，下面將以C++語言編程為例以軟體實現的形式來說明本發明實施方式的一個示例。圖8是用C++語言編程實現一個模塊的實例的結構示意圖。在圖中，iMAP_Lem_Module表示模塊的類名稱，iMAP_Msg_Utility表示消息發送器的類名稱，iMAP_Sap_Cache_Mgr和Sap_Entry分別表示服務接入點緩存管理器的類名稱和服務接入點列表的類名稱。此外，iMAP_Lem_Sap_Impl和iMAP_Admin_Sap_Impl分別表示服務接入點實現基類的類名稱和管理服務接入點實現的類名稱。圖中的連線表示了各類之間的調用關係。圖中的英文是訪問時調用的名稱，沒有特別的含義，也可以用其他的英文名稱替代。
其中，各模塊可以通過包含有進程、動態庫或其他形式的單元來實現，如前所述，每個模塊都有一個唯一的「模塊號」，用於和節點內其他模塊相區別。這些模塊作為SAP的容器完成模塊全局的初始化和SAP的初始化。模塊主體通過消息發送器向其他模塊的SAP發送消息來訪問其他模塊。如上所述，服務接入點緩存管理器由消息發送器使用。服務接入點列表用於存儲該模塊中所有的SAP地址，服務接入點列表在模塊初始化時被初始化。管理服務接入點實現類，可以完成一些所有SAP的共性的管理功能。
SAP從iMAP_Lem)_Sap_Impl派生。SAP提供模塊對外接口的實體，SAP有一個唯一的「SAP號」，和本模塊的其他SAP相區別。SAP實現一個CORBA接口，並註冊到名字伺服器，使用[節點號][模塊號][SAP號]來作為該SAP的外部標識(名字)。
SAP實現的CORBA接口為一個通用的接口，而應用層的SAP一般會提供多個功能，每個功能用一個成員函數實現。應用定義成員函數，同時定義一個分發ID(分發碼)。iMAP_Lem_Sap_Impl通過分發ID查找和調用分發成員函數。成員函數使用宏定義。
上述模塊類和SAP類封裝了服務端的開發，消息發送器提供了客戶端的使用，客戶端使用這個類對象發送同步或異步消息。
模塊類和SAP類中都有獲得iMAP_Msg_Utility實例的函數。消息發送器的關鍵是SAP緩存管理器iMAP_Sap_Cache_Mgr，該類提供SAP的CORBA對象的緩存。這個類的核心是一個SAP的緩存數組。
從上述內容不難看出，本實例中的技術方案簡化了分布式開發的步驟，降低了分布式開發的難度，由於iMAP_Lem_Module封裝了CORBA對象的創建和註冊、註銷，用戶只要專注於SAP的實現；SAP只是一個普通的C++類，從iMAP_Lem_Sap_Impl派生，用戶只需要定義分發碼和實現成員函數，而不需要定義和實現任何CORBA接口。而發送消息統一使用iMAP_Msg_Utility類，用戶也不用關心對端的CORBA對象和名字伺服器，只需要知道對端的SAP標識。
本實例中的方案提供了更好的擴充性和可靠性，由於發送消息統一在iMAP_Msg_Utility中實現，消息接受統一在iMAP_Lem_Sap_Impl中，消息有統一的消息頭，可以對消息進行一些統一的處理，進行一些AOP(AspectOriented Programing，面向方面的編程)，如統一記錄日誌。由於消息統一入口、出口和消息頭，可以統一記錄運行日誌。
此外，如果直接使用CORBA開發，對每個接口定義一個IDL，然後編譯成stub(代理)和skeleton(骨架)，這些代碼量很大，一個簡單的接口可能編譯出1000行以上代碼，造成系統很龐大，在本實施例中，只有一個系統預定義的CORBA接口，新增的功能通過用戶派生類實現自己的業務邏輯，沒有額外的代碼，系統的大小可以控制，在一些嵌入式的系統由於內存受限制，可以通過本發明提供的方案實現很好的分布式特性。
上述實例中，可以使用ORB(CORBA裡面的對象遠程代理)進行底層的通信承載，但在本發明的系統中ORB不是必須的，也可以使用其他方式作為通信的承載。包括但不限於ACE Reactor/EventHandler(ACE Reactor，Adaptive Communication Envionment Reactor/EventHandler，自適應通信環境反應器/事件處理器；是ACE裡面的一個設計模式，對Socket-即套接字的一種C++封裝，ACE是一套開原始碼。)；ICE(Internet CommunicationEnvironment，網際網路通信環境，也是一套開原始碼，是CORBA的簡化版本)；Socket(套接字，是針對IP通信的最廣泛使用的一套編程接口)等，都可以實現本發明的系統。
圖9表示本方案的一個同步調用的過程。下面參照圖8和圖9詳細描述本發明一個實施方式的同步調用過程，其步驟如下步驟901Client(客戶端，即調用者)使用消息發送器(iMAP_Msg_Utility)發送同步消息(Send_sync_msg，消息發送器提供的接口函數)；步驟902iMAP_Msg_Utility對Server(服務端)的iMAP_Lem_Servant(侍服類)執行同步調用(InvokeSnyc，同步調用，底層CORBA接口調用)；步驟903iMAP_Lem_Servant對iMAP_Lem_Sap_Impl執行同步調用(iMAP_Lem_Servant實際和iMAP_Lem_Sap_Impl可以是一個類，分成兩個僅僅是一種實現上的解耦方法，可以看成是一個，前者僅起一個代理作用)；步驟904iMAP_Lem_Sap_Impl在映射中查找分發函數(find_map，分發函數，是服務接入點類的一個成員函數)，服務接入點根據消息頭中的分發碼，找到分發函數；步驟905iMAP_Lem_Sap_Impl執行分發函數；步驟906iMAP_Lem_Sap_Impl同步調用結束，將該調用的輸出參數和返回值返回給iMAP_Lem_Servant；步驟907iMAP_Lem_Servant同步調用結束，將該調用的輸出參數和返回值返回給iMAP_Msg_Utility(即Send_sync_msg函數的輸出參數和返回值)；步驟908iMAP_Msg_Utility同步消息結束，Client獲得調用結果。
圖10表示了本方案的一個異步調用的過程實例，下面參照圖8和圖10詳細描述本發明一個實施方式的異步調用過程，其步驟如下步驟1001Client(客戶端，即調用者)使用消息發送器(iMAP_Msg_Utility)發送異步消息(send_async_msg，消息發送器提供的接口函數)；步驟1002iMAP_Msg_Utility對Server(服務端)的iMAP_Lem_Servant(侍服類)執行異步調用(InvokeAsync，異步調用，底層CORBA接口調用)；步驟1003iMAP_Lem_Servant對iMAP_Lem_Sap_Impl執行異步調用；步驟1004iMAP_Lem_Sap_Impl在映射中查找分發函數；步驟1005iMAP_Lem_Sap_Impl不執行分發函數，把調用打包放進隊列。打包放進隊列過程是把找到的分發函數指針、異步調用的消息頭和消息體放在一個數據結構裡面，然後把這個結構放進一個隊列；步驟1006iMAP_Lem_Sap_Impl異步調用結束，將返回結果(不帶有該調用的輸出參數和返回值)返回給iMAP_Lem_Servant；步驟1007iMAP_Lem_Servant異步調用結束，將返回結果(不帶有該調用的輸出參數和返回值)返回給iMAP_Msg_Utility；步驟1008iMAP_Msg_Utility異步消息結束，將返回結果返回給Client。
步驟1009iMAP_Lem_Sap_Impl通過Svc(線程函數)論詢上述隊列，如果隊列不為空，則取出隊列的內容(分發函數指針、消息頭、消息體)，通過分發函數指針，執行該分發函數，執行時消息頭、消息體作為分發函數的參數傳入。
步驟1010Svc(線程函數)獲得步驟1009中分發函數執行的結果，結果包括兩部分函數返回值，函數輸出參數。
步驟1011Svc使用Server(服務端)的iMAP_Msg_Utility的異步函數(send_async_msg)給Client發送結果(返回值填在消息頭中，輸出參數作為消息體)；Client端實際也是在一個iMAP_Lem_Sap_Impl的實現裡面處理步驟1011的結果。
此處還需要規定一個特殊值比如發函數如果返回空值(DISP VOID)，表示不需要Svc函數再執行步驟1011，將返回空值作為一個特殊定義，分發函數的其他返回值不能使用這個值。
當Client的iMAP_Lem_Sap_Impl在收到Server的iMAP_Msg_Utility發送的消息後，Client端的iMAP_Lem_Sap_Impl的分發函數會返回空值，從而避免形成一個死循環的消息發送。
圖11表示本方案的一種在HA上的應用實例。如圖中所示，在HA方式中，模塊有兩個運行實例，一個是主(Active)，一個是備(Standby)，這兩個實例的節點號、模塊號都一樣，但兩個的「群內號」不一樣，如，一個是0一個是1。對於調用者，他只看到節點號、模塊號、SAP號，因此HA對於調用者是透明的。調用者把目的節點號、模塊號、SAP號傳給消息發送器，後者在調用時中查詢這兩個實例的狀態，如果發現一個是主，一個是備，則給主和備實例同時發送(即同時調用主和備實例的SAP的CORBA函數)，這樣實現複製功能(Duplication function)。
這是實現雙機熱備份的一種機制，也叫做並發選收。即發送的時候給主備對象都發送，但主、備對象處理後，只有主的返回消息發出來(如果兩個的消息都發出來就會造成混亂)，而備的消息不發出來，如圖中虛線部分，這樣實現選擇功能(selection function)。
如此，可以保證在主、備對象中，如果有一個死了，另外一個還能不中斷地進行處理。比如當主對象死了，這時原先備的對象變成了主對象，可以發送消息，而原先的主對象變成了備對象。
主、備作為整體來講，始終有一個輸入和一個輸出。輸入和輸出包括任何內容，當對應文件時，輸入就是讀文件，輸出就是寫文件；當對應資料庫時，輸入就是查詢，輸出就是增刪改。
以上所述的實施例，只是本發明較優選的具體實施方式
的一種，本領域的技術人員在本發明技術的方案範圍內進行的通常變化和替換，都應包含在本發明的保護範圍內。
權利要求
1.一種基於消息的分布式系統，其特徵在於，所述系統包括至少一個節點，所述節點包括至少一個完成特定功能的模塊，所述模塊包括至少一個服務接入點，用於接收服務請求消息，並根據所述服務請求消息完成所需服務；消息發送器，用於將服務請求消息發送至目的服務接入點，請求所需服務。
2.如權利要求1所述的系統，其特徵在於，所述服務接入點具有在所述系統內唯一的服務接入點標識；所述消息中包含目的服務接入點的標識。
3.如權利要求1所述的系統，其特徵在於，所述消息發送器包括同步消息發送器，用於將同步消息發送至目的服務接入點，請求所需服務，並將服務結果返回給發送者；異步消息發送器，用於將異步消息發送至目的服務接入點，請求所需服務，但不負責將服務結果返回給發送者。
4.如權利要求1所述的系統，其特徵在於，所述服務接入點包括至少一個服務執行單元，根據服務請求消息完成所需服務；消息接收和調度單元，接收服務請求消息，並分發給相應的服務執行單元，將服務結果返回給服務請求方。
5.如權利要求4所述的系統，其特徵在於，所述消息接收和調度單元具體包括同步消息接收和調度單元，接收服務請求方的同步消息，調用相應的服務執行單元完成所需服務，將服務結果返回給服務請求方。異步消息接收和調度單元，接收服務請求方的同步消息，並分發給相應的服務執行單元，待所述服務執行單元完成服務後，創建新消息，將服務結果放在所述新消息中通過消息發送器發送給服務請求方。
6.如權利要求2所述的系統，其特徵在於，所述節點還包括名字伺服器，用於提供名字服務；所述服務接入點將該服務接入點的標識及訪問地址註冊到所述名字伺服器；所述消息發送器根據消息中的目的服務接入點標識從名字伺服器得到目的服務接入點的訪問地址，將消息發送至目的服務接入點。
7.如權利要求2所述的系統，其特徵在於，所述消息包括消息頭和消息體，所述消息頭中至少包含發送所述消息的服務接入點標識，以及接收所述消息的服務接入點標識，所述消息體包含有服務需要的數據。
8.如權利要求2所述的系統，其特徵在於，所述服務接入點標識由節點號、模塊號和服務接入點號組成。
9.如權利要求1所述的系統，其特徵在於，所述模塊還設有一個備份模塊。
10.如權利要求1所述的系統，其特徵在於，所述模塊還包括服務接入點列表存儲器，用於存儲所述模塊中的所有服務接入點。
11.如權利要求1所述的系統，其特徵在於，所述模塊還包括一個服務接入點管理單元，用來管理所述模塊中的所有服務接入點。
12.一種在分布式系統中利用消息進行通信的方法，用於第一服務接入點向第二服務接入點請求服務，其特徵在於，所述方法包括以下步驟1)所述第一服務接入點通過消息發送器向所述第二服務接入點發送消息；2)所述第二服務接入點接收消息，執行所需服務；3)所述第二服務接入點返回服務結果。
13.如權利要求12所述的方法，其特徵在於，所述消息為同步消息，所述步驟2)具體為所述第二服務接入點接收消息，調用相應服務執行單元，完成所需服務。
14.如權利要求12所述的方法，其特徵在於，所述消息為異步消息，所述步驟2)具體為所述第二服務接入點將所述消息發送給相應的服務執行單元，所述服務執行單元完成所需服務。
15.如權利要求14所述的方法，其特徵在於，所述步驟3)具體為所述第二服務接入點創建新的消息，將服務結果放入所述新消息中，通過消息發送器發送給所述第一服務接入點。
16.如權利要求12所述的方法，其特徵在於，所述消息包括消息頭和消息體，所述消息頭中至少包含發送所述消息的服務接入點標識，以及接收所述消息的服務接入點標識，所述消息體包含有服務需要的數據。
17.如權利要求12所述的方法，其特徵在於，所述服務入點標識由節點號、模塊號和服務接入點號組成。
18.如權利要求17所述的方法，其特徵在於，所述模塊還設有一個備份模塊，所述步驟1)具體為所述第一服務接入點通過消息發送器向第二服務接入點請求服務，所述消息發送器向位於所有模塊的所述第二服務接入點分別發送請求所述服務的消息。所述步驟3)具體為位於非備份模塊的所述第二服務接入點返回服務結果。
全文摘要
本發明提出了一種基於消息的分布式系統以及在其中進行通信的方法，所述系統包括至少一個節點，所述節點包括至少一個完成特定功能的模塊，所述模塊包括至少一個服務接入點，用於接收服務請求消息，並根據所述服務請求消息完成所需服務；消息發送器，用於將服務請求消息發送至目的服務接入點請求所需服務。利用本發明，發送消息統一使用消息發送器，接受消息統一使用服務點接入單元，用戶不用關心具體信息，只需要知道對端的接入服務點標識就能夠完成在分布式環境下的通信，簡化了開發的難度，提高了系統的可靠性和可擴充性。
文檔編號H04L29/08GK1984149SQ20061007598
公開日2007年6月20日 申請日期2006年4月27日 優先權日2006年4月27日
發明者徐彬豔 申請人:華為技術有限公司