分散式計算是指各種不同的工作站通過網路互相連線，由分散式系統提供跨越網路透明地訪問各種異構裝置所需要的支援，使得使用者可以充分利用網路上的各種計算資源來完成自己的任務[1]。與網路技術的發展和日益增長的應用需求相適應，分散式計算已經成為新一代計算和應用的主流。分散式計算中所涉及的分散式系統是指元件分佈在網路計算機上且通過訊息傳遞進行通訊和動作協調的系統[2]。分散式系統具有以下特徵：元件的併發性、缺乏全域性時鐘、元件故障的 獨立性。構造分散式系統的挑戰主要是其元件的異構性、開放性（指允許增加或替換元件）、安全性、可伸縮性（指使用者數量增加時能正常執行的能力）、故障處理 以及元件的併發性和透明性。構造和使用分散式系統的主要動力來源是資源共享，因此分散式系統之間的通訊和整合技術一直是關注的重點。

中介軟體是指一個軟體層，它提供了一個程式設計抽象以及對底層網路、硬體、作業系統和程式語言異構性的遮蔽，同時還為服務 器和分散式應用的程式設計人員提供了一致的計算模型。中介軟體能夠很好地完成異構分佈系統的整合、互操作，並且能夠很好地保證這些系統的可移植特性，因而極大地 降低了開發分散式應用的週期，能夠提高系統的可靠性，是當前分散式應用開發和分散式系統整合的主要手段。

本文對分散式企業應用和分散式實時應用的整合技術進行了簡要介紹。

企業自上世紀七十年代開始使用IT支援系統至今，一些大型企業中各種IT支援系統平均達數十種之多。它們大部分是一個個的資訊孤島，管理著企業特定的各個職能部門的工作，相互之間缺乏有效的通訊。隨著資訊科技的不斷髮展，今天的企業需要一個整合的、開放的、面向使用者且隨需而變的IT支援系統，因此面臨著應用系統的整合問題。不同的應用（尤其是不同企業的）的開發語言不同，部署平臺不同，通訊協議不同，對外交換的資料格式也存在著差異，如何去解決語言差異、平臺差異、協議差異、資料差異所帶來的高代價的系統整合是這個問題的關鍵。

企業應用整合（Enterprise Application Integration，EAI）將企業中的業務流程、應 用系統、硬體和各種標準聯合起來，在兩個或更多的企業應用系統之間實現無縫整合，使它們像一個整體一樣進行業務處理和資訊共享。企業應用整合不僅包括企業 內部的應用系統整合，還包括企業與企業之間的整合，以實現企業與企業之間的資訊交換、商務協同、過程整合和組建虛擬企業和動態聯盟等。目前，常用的企業應 用整合技術有遠端過程呼叫技術、分散式物件技術、面向訊息的中介軟體技術和Web服務技術。

最早提出遠端過程呼叫的是美國Birrell和NelSon，其後在Xerox工作站上實現，它非常類似於在單機程式設計過程中經常使用的過程呼叫（Procedure Call）。在分散式環境下，遠端 過程呼叫允許本地計算機上的程式呼叫遠端計算機上的程序。遠端過程呼叫允許傳送一個請求（客戶程序）到遠地程序即被呼叫者，被呼叫者或伺服器程序執行這個 過程併發回一個結果（響應）訊息。該方法最主要的特點是程式不需要知道呼叫的過程是本地還是遠地。遠端過程呼叫和傳統的過程呼叫不同就在於呼叫者（Caller或Client）和被呼叫的程序（Server）是在不同的機器上的不同的程序。

1987年，Sun Microsystem公司開發了開放式網路計算（ONC）RPC系統，作為它的網路檔案系統（NFS）的基本通訊機制；同年，Apollo Computer公司為其作業系統開發了網路計算系統（NCS）的RPC系統。在1989年，開放式軟體基礎設施（OSF）組織為RPC系統發出了技術請求（RFT），並收到了兩個主要提案：一個來自HP/DEC，基於NCS；另一個來自Sun，基於ONC。最終，OSF選擇NCS作為其分步式計算環境（DCE）的RPC機制。1990年，Microsoft基於DCE/RPC的修訂版開發了RPC機制，使得RPC技術得到了更廣泛的應用。

遠端過程呼叫的靈活性體現在它的跨平臺性上，它不僅遠端的子程式，而且這種呼叫是可以跨越不同作業系統平臺的。而遠端過程呼叫的缺點在於其採用了同步通訊方式，適合於小型的簡單應用。對於一些大型的應用，需要支援多種通訊模式時，遠端過程呼叫就不太適合。

二十世紀九十年代，隨著面向物件技術的廣泛應用和和分散式系統成為計算機系統和應用的主流技術，出現了分散式物件技 術。分散式物件技術是面向物件技術和分散式技術的結合，其提供了一種通訊機制，透明地在異構的分散式計算環境中傳遞物件請求，而這些物件可以位於本地或遠 程機器。主流的分散式物件技術有以下三種：

l       物件管理組織（Object Management Group, OMG）制定的CORBA（Common Object Request Broker Architecture，通用物件請求代理架構）技術。

l       Microsoft公司提出的DCOM（Distributed Component Object Mode，分散式元件物件模型）技術。

l       Sun公司提出的RMI（Remote Method Invocation，遠端方法呼叫）技術。

CORBA是OMG專門為異構平臺上不同語言開發的分散式物件進行互操作而制定的規範。OMG組織是一個國際性的非盈利組織，成立於1989年，致力於面向物件軟體開 發的實踐與理論，制定工業指南和物件管理規範，加快物件技術的發展。其目標是為應用開發提供一個公共框架，使得基於物件的軟體在分佈異構環境下具有良好的 可重用性、可移植性和互操作性，從而能夠在由多種作業系統構成的異構分佈環境中，方便地建立異構分散式應用系統，或實現企業資訊資源的整合。為實現上述目 標，OMG組織成立後不久就制定了OMA（Object Management Architecture，物件管理體系結構）參考模型，其主要包含四個部分：應用物件（Application Object）、物件服務（Object Service）、公共設施（Common Facilities）和物件請求代理（Object Request Broker）。針對OMA中的核心部分ORB，OMG組織制定了CORBA規範。CORBA規範遮蔽了底層硬體、作業系統和網路協議的不同，使開發者能夠將精力集中到應用邏輯上，而不需考慮複雜的異構環境通訊問題。1991年，CORBA1.1規範正式提出，定義了IDL介面語言和ORB物件請求代理中介軟體。1995年，OMG釋出CORBA 2.0，提出了IIOP（Internet Inter Object Protocol），用以規範不同廠家的ORB之間的互聯互通。自此，CORBA逐漸成型，2002年，OMG組織正式釋出了CORBA3.0規範。

CORBA規範給出了ORB的基本結構及其各部分的功能描述，包括：介面定義語言（IDL）、靜態呼叫介面（IDL Stub）、ORB介面、動態呼叫介面（DII）、靜態框架介面（SS）、動態框架介面（DSI）、物件介面卡（OA）、介面庫、物件實現庫和ORB間的互操作協議IIOP，其關係如下圖所示。

圖1. CORBA ORB的結構

物件的介面通過IDL定義，獨立於物件的實現。IDL編譯器將物件的IDL檔案編譯成客戶端的存根（Stubs）和伺服器端的框架（Skeleton）。客戶端根據IDL Stubs使用靜態方式呼叫物件服務；或根據介面庫中得IDL描述資訊採用動態呼叫方式搜尋可用的服務，找到這些服務的介面並構造使用這些服務的請求。物件實現在執行客戶請求時，通過物件介面卡獲取ORB的服務。物件介面卡是物件訪問ORB服務的主要通道，拓為例項化的物件服務提供執行環境，接收客戶請求並傳送給服務物件。此外，物件介面卡還負責為服務物件分配物件ID，以及將物件類和例項化物件註冊到物件實現庫中。物件實現庫包含了允許ORB查詢和呼叫物件實現的相關資訊，是ORB進行物件匹配的場所。CORBA自發布以來，已經有很多實現。目前市場上流行的產品有：IONA公司的Orbix，Inprise/Borland公司的VisiBroker等。

DCOM是由Microsoft於1996年提出的分散式物件構件標準，旨在提高應用軟體的互操作能力。COM（Component Object Model，元件物件模型）技術使得程式的各個元件之間可以用一種統一的方式進行互動，而DCOM實際上是COM技術在分散式環境中的擴充套件，它建立在DEC（分散式計算環境）的RPC規範之上，可以實現在兩臺不同的計算機之間呼叫COM物件，物件間的通訊通過網路來傳輸。DCOM遮蔽了COM物件的位置差異，使使用者不需知道COM物件的實際位置，就可以使用該COM物件。

圖2. DCOM整體結構圖

DCOM的整體結構如上圖所示。DCOM利用RPC提供分佈功能，當客戶程序呼叫介面上的方法時，DCOM將方法呼叫轉換為RPC呼叫。RPC機制自動完成資料的包裝和解包、資料格式的轉換、建立網路會話和處理網路呼叫。可以說DCOM提供了一種面向物件的RPC機制。

RMI是Sun公司於1997年所提出的分散式計算模型，用以解決訪問Java分散式物件的通訊問題。Java是一個提供了可移植的面向物件程式語言和高效能的Java虛擬機器組成的應用系統執行和開發平臺。RMI能夠支援一臺Java虛擬機器（JVM）上的物件與另一臺Java虛擬機器（JVM）上的物件進行通訊。RMI的架構如下圖所示，包含三層：樁/骨架層、遠端呼叫層、傳輸層。

圖3. RMI結構圖

其中，Stub/Skeleton Layer監聽客戶端產生的遠端方法呼叫，將這些呼叫轉換為伺服器端的遠端RMI服務。Remote Reference Layer負責解釋與管理客戶對伺服器上遠端物件的引用。Transport Layer為伺服器端RPL與客戶端RPL建立連線。由於Java的天生跨平臺優勢，RMI的跨平臺能力很強，但它只是Java體系的一部分，對純Java應用的整合能力很強，並沒有跨語言的互操作能力。而企業在資訊化過程中，存在大量非Java開發的遺留系統或採用其它技術開發的獨立系統，這樣就大大增加了RMI在企業資訊資源整合中的成本。

分散式物件技術能在一定程度上解決分散式系統的通訊和整合問題，但是存在著一些問題，如互動雙方以緊耦合的同步通訊方式繫結，基於二進位制通訊協議，並採用跨邏輯層的緊密整合，容易導致可伸縮性問題。另外RMI和DCOM技術限於特定平臺，不能實現異構系統之間的整合，CORBA技術實現複雜，投入高。為了解決分散式系統之間整合的緊耦合問題，產生了面向訊息的中介軟體技術。

面向訊息的中介軟體（Message-Oriented Middleware，MOM），提供了以鬆散耦合的靈活方式整合應用程式的一種機制。它們提供了基於儲存和轉發的應用程式之間的非同步資料傳送，即應用程式彼此不直接通訊，而是與作為中介的MOM通訊。MOM提供了有保證的訊息傳送，應用程式開發人員無需瞭解遠端過程呼叫（RPC）和網路/通訊協議的細節。面向訊息中介軟體利用高效可靠的訊息傳遞機制進行平臺無關的資料交流，並基於資料通訊來進行分散式系統的整合。通過提供訊息傳遞和訊息排隊模型，它可以在分散式環境下擴充套件程序間的通訊。

傳統的面向訊息中介軟體通常採用點對點的訊息傳輸結構，通常由訊息佇列服務、訊息傳遞服務、訊息佇列和訊息應用程式介面API組成，其典型的結構如圖4所示。其基本工作原理為：在訊息傳送方，訊息傳送者呼叫傳送訊息的API函式，將需要傳送的訊息經訊息佇列服務儲存到傳送訊息佇列中；通過雙方訊息傳遞服務之間的互動，經訊息佇列服務將需要傳送的訊息從傳送佇列取出，並送到接收方；接收方再經它的訊息佇列服務將接收到的訊息存放到它的接收訊息佇列中；在訊息接收方，訊息接收者呼叫接收訊息的API函式，同樣經過訊息佇列服務，將需要的訊息從接收佇列中取出，並進行處理。訊息在傳送或接收成功後，訊息佇列服務將對相應的訊息佇列進行管理[3]。

圖4. 點對點訊息傳遞模型

在這種互動方式中，傳送方對訊息進行打包時需要顯明地標註接收方的地址。因此，儘管訊息的接收方和傳送方是鬆耦合連 接的，相互通訊不必保持同步，但由於在訊息中必須繫結接收方地址，導致在廣域、大型應用系統中使用訊息中介軟體不夠靈活，系統擴充套件比較困難。為了增加訊息發 送方和接收方之間對地址的透明性，1990年代末期以後，訊息中介軟體開始向釋出/訂閱架構轉變，併成為企業應用整合中介軟體的一種核心機制，而基於釋出/訂閱架構的訊息中介軟體通常稱為釋出/訂閱訊息中介軟體（Publish/Subscribe Middleware，簡稱P/S MOM）或訊息代理（Message Broker），以與傳統的訊息中介軟體相區別。

在基於訊息代理的分散式應用系統中，訊息的傳送方稱為釋出者，訊息的接收方稱為訂閱者，釋出/訂閱模型用稱為主題的內容分層結構代替了點對點模型中的唯一目的地，不同的訊息通過不同的主題進行區分。釋出者向訊息代理髮布其它應用系統感興趣的訊息，而訂閱者從訊息代理接收自己感興趣的訊息，釋出者和訂閱者之間通過訊息代理進行關聯。訊息代理的基本結構如圖5所示

圖5. 釋出/訂閱訊息傳遞模型

訊息代理具有很好的靈活性和可擴充套件性，並支援主動、實時的資訊傳遞方式，當訊息釋出者有動態更新的資料產生時，訊息 代理會通過事件的釋出主動通知訊息訂閱者存在新的資料可用，而無需訊息訂閱者進行頻度無法確定的查詢。訊息代理適合於具有實時性、非同步性、異構性、動態性 和鬆耦合的應用需求。

由於沒有統一的規範和標準，基於訊息中介軟體的應用不可移植，不同的訊息中介軟體也不能互操作，這大大阻礙了訊息中介軟體的發展。JMS(Java Message Service，Java訊息服務)是SUN及其夥伴公司提出的旨在統一各種訊息中介軟體系統介面的規範。它定義了一套通用的介面和相關語義，提供了諸如持久、驗證和事務的訊息服務，它最主要的目的是允許Java應用程式訪問現有的訊息中介軟體。JMS規範沒有指定在訊息節點間所使用的通訊底層協議，來保證應用開發人員不用與其細節打交道，一個特定的JMS實現可能提供基於TCP/IP、HTTP、UDP或者其它的協議。目前許多廠商採用並實現了JMS API，比較流行的JMS商業軟體和開源產品包括：IBM公司的MQSeries、BEA公司的WebLogic、Progress公司的SonicMQ、開源產品Apache Active MQ和OpenJMS。這些產品已經廣泛地應用在金融、郵電、交通、政府等資料傳輸頻繁、交易量大的行業。

雖然訊息中介軟體能夠在客戶和伺服器之間提供同步和非同步的連線，並且在任何時刻都可以將訊息進行傳送或者儲存轉發，但是大多數MOM實現方案提供的都是與自己核心裝置通訊的本地API，影響了應用程式在此類實現方案之間的移植性，從而導致將實現鎖定於特定伺服器供應商的問題，另外通訊的訊息是通訊雙方約定的格式，制定通訊協議本身就是一個複雜的過程。

Web服務提供了一種在廣域網路上共享資料和功能的方法，是分佈物件技術的重要補充。Web服務是一種通過URI標識的軟體應用，其介面及繫結形式可以通過XML標準定義、描述和檢索，Web服務能夠通過XML訊息及Internet協議完成與其他軟體應用的直接互動[4]。它是傳統元件技術在網際網路應用環境下的延伸，其目的和作用是提供一種統一的規範和技術，為連線異構的企業應用系統提供基礎，為網際網路軟體應用提供統一的功能描述和共享機制，提供一種在不同平臺/系統之間進行應用層功能自動整合、自動化處理所需要的技術架構。

Web服務採用一套完全開放且獨立於實現平臺及程式設計語言的互動機制，形成了較為全面的協議族，其中SOAP、WSDL、UDDI以及上層面向服務組合的WS-BPEL等構成了Web服務協議族的核心。此外，許多WS-*系列規範針對Web服務的各個非功能特性進行定義，如關注Web服務安全的WS-Security系列規範、關注Web服務事務管理的WS-Transaction系列規範等。這些技術規範的逐步完善使得Web服務從眾多服務實現中脫穎而出，成為實現服務網格的重要技術基礎。

圖6. Web服務協議棧

1996年，全球資訊網聯盟(W3C)開始從事可擴充套件標記語言XML的工作。1998年2月10日釋出了XML1.0，它是一種開發簡單而又可擴充套件的、結構化和半結構化資訊文字表示機制。XML的語言的提出為Web服務相關標準的制訂做出了里程碑式的貢獻，目前幾乎所有的Web服務標準都建立在XML語言的基礎上。隨後，W3C提出了一系列Web服務相關的重要協議和標準。2000年，W3C組建了XML協議工作組，該工作組提出的簡單物件訪問協議SOAP（Simple Object Access Propotol）[5]是Web服務通訊的事實標準。SOAP支援應用程式與應用程式之間的通訊，主要應用於商務對商務的通訊以及企業應用整合。SOAP定義瞭如何通過軟體以獨立於各種程式語言或平臺的方式來構造訊息、處理訊息，從而使那些用不同程式語言編寫的程式之間具有互操作性，並能夠在不同的作業系統上執行。Web服務描述語言WSDL（Web Services Description Language）[6]用於描述Web服務的功能呼叫語法。它將Web Services描述定義為一組服務訪問端點，客戶端可以通過這些服務訪問端點對包含面向文件資訊或面向過程呼叫的服務進行訪問(類似遠端過程呼叫)。2003年5月結構化資訊標準促進組織（OASIS）批准了一項跨網路尋找網路服務的技術，將統一描述、發現和整合協議UDDI2.0[7]版本批准為標準。UDDI 提供了一組基於標準的規範用於描述和發現服務，還提供了一組基於因特網的實現。服務註冊中心儲存了描述商業或其他實體的資訊及其提供的服務的相關技術呼叫介面(或API)。至此，以上協議的引入和釋出奠定了Web服務的基礎。

Web服務體系結構基於三種角色 （服務提供者、服務消費者和服務註冊中心）之間的互動，如下圖所示。服務提供者是一個可通過網路定址的實體，它接受和執行來自服務消費者的請求。它將自己 的服務和介面契約釋出到服務註冊中心，以便服務消費者可以發現和訪問該服務。服務消費者是一個應用程式、一個軟體模組或需要一個服務的另一個服務。它發起 對註冊中心中的服務的查詢，通過傳輸繫結服務，並且執行服務功能。服務消費者根據介面契約來執行服務。服務註冊中心是服務發現的支持者。它包含一個可用服 務的儲存庫，並允許感興趣的服務消費者查詢服務提供者介面。面向服務的體系結構中的協作遵循“查詢、繫結和呼叫”範例，其中，服務消費者執行動態服務定 位，方法是查詢服務註冊中心來查詢與其標準匹配的服務。如果服務存在，註冊中心就給消費者提供介面契約和服務的端點地址。

圖7. Web服務中的三種角色

由於Web服務採用基於XML的開放的Web規範技術，具有更好的封裝性、高度的可整合性以及更好的開放性與互操作性。相對於COM/DCOM、RMI和CORBA等分散式元件模型，Web服務具有鬆散耦合性、簡單性、高度可整合性和開放標準等特點。通過Web服務能夠遮蔽分散式系統間的差異，為跨平臺、鬆耦合、語言無關的網路環境下的資源共享和整合提供瞭解決方案。

Web服務執行平臺為Web服務提供了執行和管理環境，實現了服務部署、執行、管理、監控等功能，使得服務能夠遵照標準的服務契約向服務消費者提供業務功能。目前，主流的開源Web服務執行平臺包括：Apache的Axis[8]、Axis2[9]和Apache CXF[10]。商業Web服務平臺包括IBM 的WebSphere[11]、Microsoft的Windows通訊框架（Windows Communication Framework，WCF）、SUN的Sun GlassFish Enterprise Server[12]等。

實時（Real Time）計算一般是指這樣的計算活動，其正確性不僅依賴於計算的邏輯結果，而且依賴於產生結果的時間[13]。因此，實時計算的核心問題是計算活動的時間可預測性（predictablity）或者時間的確定性（determinism）[14]。時間可預測性指能夠預先知道某個任務是否與應用的時間約束相符合的特性[15]。

目前的企業分散式整合技術及中介軟體能夠提供良好的開發平臺和通訊支援，但是它們缺乏對分散式實時應用的時間約束的支援能力。尤其隨著分散式計算技術和分散式應用的深入發展，一些關鍵業務領域也都使用分散式技術進行構建。在20世紀九十年代，分佈物件(Distributed Object)技術是分佈計算領域的主流技術，因此，以分佈物件為基礎，物件管理組織OMG提出了實時CORBA規範，用於開發分散式實時應用和系統整合。然而，隨著分散式系統的廣泛應用，各分佈節點之間資訊交換的需求越來越大，資訊交換的質量（可靠性、時間延遲）要求也越來越高。傳統的基於C/S架構的分散式軟體系統基本上都是以業務流程為中心的，資料參雜在業務流程中，隨著業務流程而流動，例如實時CORBA就屬於這種架構。這種架構下系統大多采用遠端過程呼叫（RPC）的方式來完成節點之間的資訊互動，資料通過函式引數或返回值的形式傳送。這樣傳送的資料量小，效率低，更存在中心伺服器瓶頸、單點失效等嚴重問題，無法滿足實時環境下以資料共享和整合為目標的分散式應用需求。OMG針對此需求提出DDS（Data Distribution Service，資料分發服務）規範，DDS採用以資料為中心的釋出-訂閱模型，實現了分散式異構環境下海量資料的實時傳輸。以下對這兩種分散式實時系統整合技術進行簡要分析。

實時應用需求隨著網路應用的普及而日益顯得迫切，OMG組織為了促進實時CORBA技術的發展，於1997 年9月提出了實時CORBA 1. 0 的RFP（request for proposal），得到了來自Alcatel、Hewlett2Packard、Lucent、OOC、Sun、Tri-Pacific、Nortel、IONA、Lockheed-Martin和Visigenic等成員獨立或者聯合提交的實時CORBA規範草案。 最終，於1999年3月，OMG釋出了實時CORBA 1. 0規範。實時CORBA 1. 0規範建立在CORBA 2.2規範以及COSS規範的基礎上，它本身是對CORBA規範的一個擴充套件，下圖表示了實時CORBA 1.0的體系結構中的實體[16]。

圖8. 實時CORBA擴充套件

實時CORBA規範定義了一組標準的介面以及策略供使用者來控制和配置系統的處理器資源、記憶體資源和通訊資源。處理器資源的標準控制機制包括執行緒池、CORBA優先順序、互斥機制和全域性排程服務等；記憶體資源的標準控制機制主要有請求佇列等；而通訊資源的標準控制機制則有協議特性設定和顯式繫結等。執行緒是實時CORBA系統進行排程的實體，規範中對執行緒提供了更加豐富的控制和配置方式以支援實時應用；定義了CORBA 優先順序，用於確定CORBA物件呼叫被處理的先後順序，並定義了優先順序對映介面（Priority Mapping），用於CORBA 優先順序和本地優先順序之間的對映；定義了2 種設定CORBA 優先順序的模式：客戶傳遞模式以及伺服器指定模式；定義了互斥介面Mutex以協調對系統共享資源的競爭；定義了全域性排程服務，應用可以向該排程服務物件指定各種有關引數，例如，週期和執行時間等[16]。與其他CORBA 規範一樣，實時CORBA規範只定義了實時CORBA系統的關鍵部件以及它們提供給使用者使用的介面，而對實現沒有任何規定。

對實時CORBA 進行研究，並取得代表性研究成果的應用系統是Washington大學計算機系分佈物件計算研究組的TAO(The ACE ORB)系統和Rode Island大學計算機系的NraD/URI CORBA系統。TAO系統[17]的研究集中在實時CORBA系統的體系結構和CORBA系統的效能優化策略，並在此基礎上實現了高效能的實時CORBA系統。TAO系統的主要組成部件包括：基於ATM 網絡卡的吉位元輸入/輸出子系統、實時應用QoS描述方法、實時任務排程服務以及高效能的物件介面卡和表示層處理模組等。NraD/URI CORBA系統[18]的目的則是為了支援CORBA 系統動態的端到端時間限制需求。與TAO 系統不同，NraD/URI CORBA系統是通過擴充套件IONA 公司的CORBA產品Orbix系統實現的，因此，它對通用CORBA系統的修改相對較少。NraD/URI CORBA系統的主要組成部件包括：實時引數描述方法、全域性時鐘服務和全域性優先順序服務等。

在大型網路中心繫統中，資訊的實時交換最為關鍵。從多個源產生的資訊必須由資訊製造者按QoS要求將資訊請求者感興趣的資訊進行分發。特別是在實時和關鍵性任務系統中，“在正確的時間和地點獲取正確的資料”是非常關鍵的任務。物件管理組織OMG認識到在分散式實時系統中的實時資料互動的需求，從而，組織在網路、資訊管理、分散式、實時和關鍵性任務系統方面具有豐富經驗的會員定義了DDS（Data Distribution Service，資料分發服務）規範[19]，在2004年12月釋出其1.0版本，2007年1月釋出1.2版本。DDS採用以資料為中心的釋出-訂閱模型，提供了強大的資料QoS控制策略，實現了分散式系統中資料實時、可靠、高效地分發，能夠廣泛應用於航空、國防、分佈模擬、工業自動化、分佈控制、機器人、電信等多個領域。

DDS規範標準化了分散式實時系統中資料釋出、傳遞和接收的介面和行為，定義了以資料為中心的釋出-訂閱機制，提供了一個與平臺無關的資料模型（此模型能夠對映到各種具體的平臺和程式語言）。DDS允許應用程式實時釋出其擁有的資訊，並訂閱其需要的資訊，較好地處理了不可靠網路通訊中資料的自動發現、可靠性和冗餘性等問題，可應用在要求高效能、可預見性和對資源有效使用的關鍵任務領域。

DDS規範描述了兩個層次的介面[20]：低層的DCPS（Data-Centric Publish-Subscriber）用於完成資料的釋出、訂閱，其目的是釋出者能夠高效地將正確的資訊傳遞給適當的訂閱者；高層的DLRL（Data Local Reconstruction Layer）用於資料在本地的表示，其目的是使應用程式能更加直接的訪問交換的資料，並能與本地語言完美的結合起來。

DCPS層是DDS規範的核心，它提供了資料釋出的基礎架構，確保正確有效地傳輸資訊給適當的接收者。該層建立了一個“全域性資料空間”的概念，釋出者和訂閱者在該全域性空間中分別釋出和訂閱自己需要的資料型別，通過中介軟體處理後，再進行資料傳送，將傳統的C/S模式轉為以資料為中心的服務模式。在該模式中，資料並非存在於所有計算機的地址空間中，它僅存於那些對它感興趣的應用程式的本地快取中，而這一點正是釋出-訂閱模型的關鍵所在[21]。圖9顯示了DDS中資料的傳遞過程，圖中主要包括以下幾個實體：生產者（Producer）及其中的資料釋出者（Publisher）和資料寫入者（DataWriter），消費者（Consumer）及其中的資料訂閱者（Subscriber）和資料讀取者（DataReader），主題（Topic）及其對應的資料物件（DataObject）和資料域（Domain）。

圖9. DDS通訊模型

Publisher是一個負責分發資料的實體，它可以釋出不同型別的資料。生產者中的應用程式通過DataWriter的寫操作來寫資料。寫操作以物件的適當型別作為引數，當定義與DataWriter相關聯的Topic時物件的型別就得到確定。物件有了新值，寫操作就會通知中介軟體，但立即構建網路通訊並不是必須的。由Publisher負責決定何時傳送資料以及執行實際的傳送操作，這一行為通過相關的QoS驅動。Subscriber負責接收並分發不同型別的資料，根據Subscriber的QoS，可以接收已釋出的資料。而消費者中的應用程式想要獲取Subscriber接收到的資料，就必須使用一個與Subscriber關聯的型別化的DataReader。DataWriter物件和DataReader物件之間的聯絡通過Topic物件來實現。Topic包含名稱（在系統中唯一的）、資料型別和與資料本身相關的QoS。通過Topic，使空間上、時間上關係鬆散甚至毫無關聯的釋出者和訂閱者之間產生了關聯。

DDS規範定義了較為全面的QoS控制策略，每個DCPS實體都有自身的QoS策略。在主題訂閱時，DDS檢查釋出者釋出的主題是否滿足訂閱者的要求，並檢查其QoS策略是否相容，如果是則在釋出者和訂閱者之間建立連線，進行點對點的資料傳送。否則就給出不相容錯誤提示，如圖10所示。因此，DDS能夠在每一對釋出者和訂閱者之間建立獨立的QoS協定。這使得DDS可以很好地配置和利用系統資源，協調可預言性與執行效率間的平衡，支援複雜多變的資料流需求。

圖10. DDS通訊中的QoS失配

DDS規範提供了21種靈活的資料傳輸QoS控制策略，能夠提供實時系統所要求的效能可預測性和資源可控性，其中比較重要的QoS策略如下：

Ø         Durability（永續性）：如果建立釋出者時此屬性被選中，那麼所建立的釋出者將在記憶體中儲存其釋出資料的歷史記錄，要保留的資料總量由History屬性。Durability允許後加入的訂閱者獲得在訂閱者建立之前已經發送過的資料。

Ø         Reliability（可靠性）：如果建立釋出者時此屬性被選中，那麼所建立的釋出者會交付所有的資料傳送。如果由於通訊錯誤導致訂閱者不能接收到資料，資料服務將會修復該錯誤並重新發送資料。預設狀態下，釋出者進行盡力服務，不會重發丟失的資料。

Ø         History（歷史記錄）：控制傳送佇列中的資料總量，此屬性的使用與Durability及Reliability屬性相關聯。如果Durability屬性被選中，那麼History屬性決定有多少歷史資料會被傳送給後加入的訂閱者。

Ø         Liveliness（活躍性）：用於檢測釋出者的狀態，甚至當它沒有活躍地傳送資料時也可以檢測。

Ø         Deadline（時間限制）：對於釋出者而言，Deadline是釋出者承諾更新資料的時間間隔；對於訂閱者而言，Deadline是期望從釋出者得到資料更新的最大時間間隔。

DDS為實時環境下以資料為中心的分散式應用提供了實時、高效、可靠的通訊服務，能夠實現分散式異構環境下海量資料的實時傳輸。其具有以下特點[22]：

Ø         複雜的資料流處理：DDS通過對資料傳輸QoS的靈活控制，可以將對更新速率、可靠性和頻寬控制有不同要求的模組很好地整合到一個系統中。

Ø         低時延和高吞吐量：DDS不需要中心伺服器，可以使用直接點到點傳輸和事件驅動傳輸，消除了由於網路中轉而引起的時延，與C/S模型相比大大提高了傳輸速度。另外，DDS還允許應用程式通過降低可靠性來進一步縮短時延，如採用“best-effort”方式傳輸。同時，DDS可利用UDP協議，將單個網路分組同時傳送給多個分散式節點，極大地提高了傳輸的吞吐量。

Ø         容錯：DDS採用點對點的資料傳輸，不存在中心節點，避免了單點失效問題，實現了高容錯性。

Ø         動態配置：DDS的釋出/訂閱通訊模型能夠很好地適應具有動態配置變化的系統，能夠快速發現新的節點及其主題。當網路被分割成兩半時，每一半能獨立地工作如果網路被修復，將會自動重新連線，繼續提供全部服務。

儘管DDS具有以上特點，但並不能滿足所有的通訊要求。例如，DDS不適合與請求-響應服務、檔案傳輸和事務處理。檔案傳輸通常對資訊進行一次性請求，適合於採用C/S模式。同樣的，精確控制的序列化通訊，如可靠的、一次性處理過程，也不適合於採用DDS規範。

目前，比較流行的DDS商業產品和開源軟體包括：美國RTI公司的NDDS（Network Data Distribution Service）、美國PrismTech公司的OpenSpliceDDS、OCI（Object Computing Incorporated）開源軟體OpenDDS等。

二十世紀九十年代以來，網際網路逐漸成為新的計算基礎設施，其出現和普及使計算機軟體開發、部署、執行和維護的環境開 始從封閉、靜態逐步走向開放、動態。越來越多的企業提供基於網際網路的服務，新的業務模式得到了發展，企業業務系統之間的互動逐漸增強，系統之間的通訊和集 成問題凸現出來，即使在企業內部也存在異構系統之間的整合問題，因此，發展出了各種分散式系統整合技術。根據所面向的應用不同，可分為分散式企業應用整合 技術和分散式實時應用整合技術。

在分散式企業應用整合技術中，最初的遠端過程呼叫技術解決了不同計算機之間程序互動的問題。隨著面向物件技術的廣泛應用，誕生了分散式物件技術，如OMG組織的CORBA技術，Java陣營的RMI技術，微軟的DCOM技術。這些技術能在一定程度上解決分散式系統的通訊和整合問題，但是存在著一些問題，如互動雙方以緊耦合的通訊方式繫結，基於二進位制通訊協議，並採用跨邏輯層的緊密整合，容易導致可伸縮性問題。為了解決分散式系統之間整合的緊耦合問題，產生了面向訊息的中介軟體技術（MOM）。但是大多數MOM實現方案提供的都是與自己核心裝置通訊的本地API，影響了應用程式在此類實現方案之間的移植性，從而導致將實現鎖定於特定伺服器供應商的問題。Web服務技術採用一系列完全開放且獨立於實現平臺及程式設計語言的Web規範，具有更好的封裝性、高度的可整合性以及更好的開放性與互操作性。相對於COM/DCOM，RMI和CORBA等分散式元件模型，Web服務具有鬆散耦合性、簡單性、高度可整合性和開放標準等特點。

在分散式實時應用整合技術中，實時CORBA技術以分佈物件為基礎，可用於開發分散式實時應用和系統整合。然而，在面臨實時環境下以資料共享和整合為目標的分散式應用需求時，傳統的基於C/S架構的分散式軟體系統存在中心伺服器瓶頸、單點失效等問題。資料分發服務（DDS）技術採用以資料為中心的釋出-訂閱模型，實現了分散式異構環境下海量資料的實時傳輸。