1 引言

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

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

本文對分布式企業應用和分布式實時應用的集成技術進行了簡要介紹。

2 分布式企業應用集成技術

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

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

2.1 遠程過程調用技術

最早提出遠程過程調用的是美國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技術得到了更廣泛的應用。

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

2.2 分布式對象技術

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

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技術實現復雜，投入高。為了解決分布式系統之間集成的緊耦合問題，產生了面向消息的中間件技術。

2.3 面向消息的中間件技術

面向消息的中間件（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，影響了應用程序在此類實現方案之間的移植性，從而導致將實現鎖定於特定服務器供應商的問題，另外通信的消息是通信雙方約定的格式，制定通信協議本身就是一個復雜的過程。

2.4 Web服務技術

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]等。

3 分布式實時應用集成技術

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

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

3.1 實時CORBA技術

實時應用需求隨著網絡應用的普及而日益顯得迫切，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系統的主要組成部件包括：實時參數描述方法、全局時鐘服務和全局優先級服務等。

3.2 數據分發服務技術

在大型網絡中心系統中，信息的實時交換最為關鍵。從多個源產生的信息必須由信息制造者按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等。

4、總結

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

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

在分布式實時應用集成技術中，實時CORBA技術以分布對象為基礎，可用於開發分布式實時應用和系統集成。然而，在面臨實時環境下以數據共享和集成為目標的分布式應用需求時，傳統的基於C/S架構的分布式軟件系統存在中心服務器瓶頸、單點失效等問題。數據分發服務（DDS）技術采用以數據為中心的發布-訂閱模型，實現了分布式異構環境下海量數據的實時傳輸。

傳統的分布式應用集成技術(網摘)