不考慮中間

中間件及其應用

泰州電信分公司通建部陳晴摘要：隨著計算機應用范圍的不斷擴大，中間件

技術已成為計算機應用的一個熱點話題。本文細述了中間件的概念以及各種類型

中間件的技術特性，并對中間件在客戶/服務結構的應用進行了討論，最后介紹

了一個中間件應用的一個實例。

關鍵詞：中間件應用

1.中間件的概念

計算機硬件、軟件技術的迅速發展，使計算機應用不斷滲透到各個領域，特

別是隨著LAN技術的發展應用、Inrenet的普及、計算機應用范圍的不斷擴大、

以及企業的跨區域運營，急切需要建立由若干個子系統組成集成計算機信息系統,

以期待完成更復雜、更高級的功能。但是，已有的計算機信息系統是異構的,普

遍存在著嚴重的"信息孤島"問題，即每個子系統之間是獨立的、不能有效地進行

信息交換和共享。于是，現代企業管理向人們提出了建立一個基于不同數據庫、

不同主機平臺、不同應用范圍、不同人機界面、不同網路類型的綜合應用系統的

需求，如何把這些不同類型的設備、數據庫、軟件和網絡集成起來開發出新的應

用，是我們目前亟待解決的難題。一個較好的解決方法便是采用中間件技術。

中間件的概念是隨著多層應用模式和分布式計算技術的發展逐漸形成的，主

要為解決異構問題。對于中間件目前還沒有統一的定義，總的來說，中間件是一

種軟件總線，不同的主機平臺、數據庫和應用被按照規范制作成插件安裝在總線

上，實現異構系統的信息共享，又被描述為軟件“粘合劑”，將不能交互的應用

系統間粘在一起。它是一軟件集合，提供了獨立系統間通信的函數和對異構系統

進行應用集成的工具，并具有如下的一些特點：

滿足綜合應用的需要

運行于多種主機和OS平臺

支持分布計算，提供跨網絡、硬件和OS的透明性的應用或服務的交互

支持標準的協議和接口

圖1示意了中間件在系統中所處層次，從體系結構上看，中間件是位于操作

系統和應用軟件之間的通用服務，它的主要作用是用來屏蔽網絡硬件平臺的差異

性和操作系統、數據庫以及網絡協議的異構性，使應用軟件能夠比較平滑地運行

于不同平臺上。同時中間件在負載平衡、連接管理和調度方面起了很大的作用，

使企業級應用的性能得到大幅提升，滿足了關鍵業務的需求。

、

2.中間件的分類

從概念上講，中間件的雛形早在70年代就出現了，消息通信和事務管理是

其最初具有的功能。到了90年代，隨著互聯網的普及和企業管理的需要，對于

中間件的需求也逐漸多樣化，從而促使中間件技術進一步細分，產生了不同類別

的中間件產品。根據應用編程接口功能和應用的不同，傳統上將中間件分為5大

類，分別是數據庫中間件（DatabaMiddleware）、基于遠程過程調用中間件

（RPC-badMiddelware）、面向消息中間件(Message-orientedMiddleware)、

分布事務處理中間件（Distributedtransactionprocessingmonitor

Middleware）和對象請求代理中間件（ObjectrequestbrokerMiddelware）。

2.1.數據庫中間件

數據庫中間件是所有中間件中最普遍、最成熟的一種。它提供了一系列應用

程序接口API，通過中間層而不考慮操作系統及網絡來訪問本地或異地的數據庫，

提供了良好的數據庫獨立性。

ODBC就是一種基于數據庫的中間件，它提供了一組對數據庫訪問的標準

API，通過SQL來完成其大部分任務。一個完整的ODBC由下列幾個部件組成：應

用程序(Application)、ODBC管理器(Administrator)、驅動程序管理器

(DriverManager)、ODBC驅動程序和數據源。各部件之間的關系如圖2圖所

示：

應用程序要訪問一個數據庫，首先必須用ODBC管理器注冊一個數據源，管

理器根據數據源提供的數據庫位置、數據庫類型及ODBC驅動程序等信息，建立

起ODBC與具體數據庫的聯系。這樣，只要應用程序將數據源名提供給ODBC，ODBC

就能建立起與相應數據庫的連接。在ODBC中，ODBCAPI不直接訪問數據庫，

必須通過驅動程序管理器與數據庫交換信息，驅動程序管理器負責將應用程序對

ODBCAPI的調用傳遞給正確的驅動程序，而驅動程序在執行完相應的操作后，

將結果通過驅動程序管理器返回給應用程序。

基于ODBC的應用程序對數據庫的操作不依賴任何DBMS，不直接與DBMS打

交道，所有的數據庫操作均由對應的DBMS的ODBC驅動程序完成。也就是說，不

論是FoxPro、Access還是Oracle數據庫，均可用ODBCAPI進行訪問。由此可

見，ODBC的最大優點是能以統一的方式處理所有的數據庫。

但是，在基于數據庫的中間件模型中，數據庫作為信息的中心存儲單元，中

間件負責數據間的同步及點到點通信，系統的靈活性提高是以處理性能的降低為

代價的。這種方式不適合于高性能應用處理，因為它需要大量的數據通信，同時，

當網絡發生故障時，系統將不能正常工作。

2.2.基于RPC中間件

'

遠程過程調用是一種廣泛使用的分布式應用程序處理方法，是面向過程和函

數的中間件，提供的是基于過程的服務訪問。它沿用了大多數程序員都非常熟悉

的編程模式，程序員就像調用本地過程一樣在程序中調用遠程過程，啟動遠程過

程的運行，然后將運行結果返回給本地程序。不但如此，遠過程調用還可以將程

序的控制傳遞到遠端的服務器當中去。

在RPC模型中，client和rver只要具備了相應的RPC接口，并且具有RPC

運行支持，就可以完成相應的互操作，而不必限制于特定的rver。因此，RPC

為client/rver分布式計算提供了有力的支持。同時RPC也有一些缺點，主要

是因為RPC一般用于應用程序之間的通信，而且采用的是同步通信方式，因此對

于比較小型的簡單應用還是比較適合的。但是對于一些大型的應用，這種方式就

不是很適合了，因為此時程序員需要考慮網絡或者系統故障，處理并發操作、緩

沖、流量控制以及進程同步等一系列復雜問題。

2.3.面向消息中間件

面向消息的中間件為SERVER、CLIENT間提供了異步的可靠的數據傳輸方式，

使得數據可間斷地來往傳遞，就如同我們通過e-mail傳遞消息，它支持多種通

訊協議、編程語言、應用程序、硬件和軟件平臺。目前流行的MOM中間件產品有

IBM的MQSeries、BEA的MessageQ等。

消息中間件提供的服務主要有以下幾類。

1)存儲轉發服務：消息的發起者使用該服務識別接收地點，如果接收者不

可達，消息便被儲存在隊列或存儲器中，消息的傳遞可以堆積并延遲到某

一事件的觸發（如：接收者可達）。EMAIL應用便是一種消息的存儲轉發模

式。

2)廣播/訂購中間件服務：消息產生者通過廣播/訂購中間件服務將消息公

布到消息中心（代理），消息中心根據所有訂購該消息的程序清單分發消息。

3)事件登記服務：對任何消息系統，在消息的異步傳送和同步傳送過程中

有許多不同的事件發生，消息系統必須對這些事件進行識別管理來控制消

息的傳送。

4)智能路由服務：智能路由中間件服務確保消息以正確的序列傳遞到目的

地。

消息中間件有以下三個主要特點：

A.通訊程序可在不同的時間運行。

B.￥

C.對應用程序的結構沒有約束。在復雜的應用場合中，通訊程序之間不僅

可以是一對一的關系，還可以進行一對多和多對一方式，甚至是上述多

種方式的組合。多種通訊方式的構造并沒有增加應用程序的復雜性。

D.程序與網絡復雜性相隔離。

2.4.分布式事務處理（DTP）中間件

事務處理監控（Transactionprocessingmonitors）最早出現在大型機上，

為其提供支持大規模事務處理的可靠運行環境。隨著分布計算技術的發展，分布

應用系統對大規模的事務處理提出了需求，比如商業活動中大量的關鍵事務處

理。它確保事務處理的完整性，提高系統的處理能力，可以被看作是分布式事務

處理應用程序的“操作系統”。總體上來說，事務處理監控提供以下功能：

兩階段提交：其含義是對一個涉及多張表（table）或多個系統的事務提交

進行監控管理，確保所有數據的一致性和完整性。

失敗恢復：事務監視器為所有事務記錄日志，日志中記錄事務的每個步驟，

利用日志，可對失敗的事務進行回滾或重新計算。

系統同步：TPM使用事務日志使不同的系統保持同步。

事務調度：對事務的執行進行調度，將低效率或實時性低的事務安排在空

閑時段執行，以提高系統的運行效率。

消息隊列管理：保證應用系統提交的請求和數據可在網絡故障或目的服務

器癱瘓等情況下也能遞交到目的服務器。

全局事務工作流管理

負載均衡：保證大量事務在眾多不同系統中快速準確執行。

2.5.%

2.6.對象請求代理（ORB）中間件

隨著對象技術與分布式計算技術的發展，兩者相互結合形成了分布對象計

算，并發展為當今軟件技術的主流方向——對象請求代理中間件。ORB中間件采

用面向對象的技術，將分布計算同面向對象的概念相互結合，可以看作是與編程

語言無關的面向對象的RPC應用。目前，ORB主要存在兩個標準：CORBA和DCOM，

且兩種標準存在了較大差異。

CORBA（CommonObjectRequestBrokerArchitecture）是由OMG組織制訂

的一種標準的面向對象應用程序體系規范，ORB是CORBA平臺的核心。圖3所示

是基于ORB的結構，箭頭方向表示了ORB的調用關系。

圖3：ORB結構示意圖

DCOM（Distributedcomponentobjectmodel）是微軟提出的分布式對象技

術，從OLE（Objectlinkingandembedding）和COM（Componentobjectmodel）

演變而來，DCOM采用ORPC（ObjectRemoteProcedureCall）作為它的基本協

議，并通過SCM（ServiceControlMananger）實現對象實體的操作。圖4所示

是DCOM的結構。

圖4：DCOM體系結構

3.中間件在客戶/服務結構中的應用

客戶/服務的概念最早在80年代提出，并在80年代后期開始被廣泛采用。

在這之前，基于網絡的計算機應用系統主要文件共享模式為主流，隨著計算機應

用范圍的擴大，文件共享的局限性也暴露出來，為了解決這些局限性，產生了客

戶/服務體系結構，并且由于這種結構的諸多優點，使分層模式得到了廣泛應用，

從而推動了中間件技術的發展。

傳統的客戶/服務器模式是一種雙層的結構，通常是一臺個人計算機做客戶

機使用（運行客戶端程序），另外一臺服務器用于存放后臺的數據庫系統，應用

程序與客戶端直接相連，中間沒有其他的層次。這種方式的數據庫應用系統其優

勢在于，開發周期較短，能夠適應大部分中小型數據庫應用系統的要求（當客戶

端數量少于50時）。但隨著數據庫應用的日漸發展，這種結構的應用系統顯現出

諸多缺陷，主要有：對于數據庫服務器端，每當建立一個數據連接，就會占用一

些系統資源以確保與客戶機之間的連接，當數據連接達到一定數量時，數據庫服

務器的響應速度與處理速度將大打折扣；程序的業務邏輯存在于前臺的應用程序

中，或者存在于后臺數據庫中以觸發器(trigger)的方式實現，一旦客戶的業務

邏輯有所改變的話，應用程序以及后臺觸發器都需做相應的修改；由于客戶端應

用程序的開發直接與DBMS連接，易受制與數據庫軟件供應商；這種結構將用戶

界面、業務邏輯以及數據源綁定在一起，會消耗客戶機的大量資源，對客戶機來

說是一個很大的負擔。

~

正是由于雙層結構的局限性，人們提出了三層結構模式。三層客戶/服務結

構中，在客戶端和數據庫管理系統間加入了一個中間層。圖5顯示了一個三層體

系結構，三個層次自上而下分別是用戶應用層、業務層和數據層，通過中間層對

外部數據庫進行數據訪問。中間件技術是三層結構的重點，可以使用不同的中間

件技術實現業務層功能，如消息隊列、事務處理監控、過程調用和對象代理等，

同時在業務層可采用多個中間件技術。不同的中間件技術提供了三層結構的相應

優勢，但總體上講與二層結構相比三層結構有大處理能力、異構性、業務靈活、

可維護管理和可重用等特性。

泰州電信本地網“計費帳務系統”中銷帳子系統便采用了三層結構，該系統

采用了BEA公司的TUXEDO中間件產品。Tuxedo是基于分布式事務處理的中間件，

由服務器端的事務管理器(/T-TransactionCore)、客戶端的工作站(/WS-Work

Station)、可靠隊列服務(/Q-Queue)、應用域(/Domain)和與DCE的結合等幾個

核心部分組成的。提供全局事務管理、故障恢復、兩階段提交、可靠隊列、路由

服務、同步異步通信、負載平衡以及分布式事務處理等功能，以處理事務交易能

力和效率見長。

圖6是泰州“本地計費帳務系統”示意圖。帳務處理應用服務器安裝了TUXEDO

的事務管理器，銷帳、欠費停復話、查詢和銀行代收通過對業務層的服務請求完

成，不需對數據庫直接訪問，在滿足大交易量和平臺共享需求的同時提高了系統

的數據安全性。

4.結束語

隨著電信行業競爭的加劇，迫切要求我們用科學的流程和有效的管理來提升

企業的競爭能力，電信企業的各種生產管理系統、網絡管理系統以及工作流管理

系統紛紛地應運而生，然而這些系統之間是相互獨立的，成為了一個個信息孤島，

企業資源不能共享、信息不能相互交換、各部門工作不能協同、海量信息不能加

工提取用以快速提供決策參考，必須尋找對這些應用系統進行集成的辦法，中間

件技術是我們急于采用的一種方式。

然而，中間件服務并非“萬能藥”，中間件所應遵循的一些原則離實際還有

很大距離。不同的中間件產品使用各自專用的協議和API，來自不同廠家產品很

難實現互操作。有些中間件服務只提供一些平臺的實現，從而限制了應用在異構

系統之間的移植。另外，應用開發較二層結構的客戶/服務結構要復雜，例如，

開發者需要完成構件的定義、域的劃分以及在client方和rver方的功能分配

等工作。