Robert Flanders and Eduardo B. Fernandez 
翻譯:小比

Data Filter Architecture Pattern
資料過濾架構樣式

 


下一頁


摘要(Abstract)

類似網際網路這般,在能有效提供大量且多樣化資料的系統環境下,為了因應政策或法令,而必須對這些資料進行過濾時,我們推薦下面這種能適用於各種不同過濾政策的過濾架構。

目的(Intent)

一個分散式系統裡,依據既定的政策,針對客戶端所要求的內容來進行過濾;並且希望這樣的過濾動作,在本地端或遠端都能夠進行。

動機(Motivation)

問題(Problem)

大多數分散式系統中,例如:網際網路,為因應公共政策、法律限制、甚至是隱私需求......種種狀況,而必須對服務或所請求的資料進行過濾。

背景(Context)

仔細考量在一個分散式系統中,如何回覆用戶端所要求的資料或服務。例如:一個 CORBA 或 DCOM 的系統可能會向後端 Database 做出要求;或像 Internet 這樣,經由瀏覽器要求一個網頁;甚至是特殊型態的企業內網路(Intranet)等等。

所受影響(Forces)

本樣式(pattern)的定義受到下列需求的影響:

解決方案(Solution)

圖一展示了本建議方案的基本架構。

資料過濾架構樣式將三層式架構的中間層(middle tier)分割成一個過濾服務管理元件(Filter Service administration component),及數個執行於不同的內容供應商資料伺服器(content providers data server),或遠端客戶伺服器(remote clients server)中的分散式遠端過濾代理器物件(distributed remote Filter Agent objects)。這個過濾服務,以可重新配置(reconfigurable)的過濾元件為基礎,並將智慧型管道(政策應用者)評估機制(smart pipe evaluation mechanism)有效的利用網路進行分散配置。過濾元件提供了一個容器,用來持續保存每個客戶端所定義之區域性過濾政策(local user-defined Filter Policies)。這個分散式資料過濾架構樣式會獨立於任何的內容供應商資料(content providers data)及網路協定(Network protocol)之外。

下列元件為本架構的合作者:資料來源(Data source)會將資料遞送到處理管道(processing pipeline)中,資料消化處(Data Sink)則會消化資料,過濾政策(Filter Policy)負責進行機能轉換(functional transformation)及產出(produces output),管道(pipe)負責協調動作同步化(synchronizes active)及資料轉換(transfers data)。智慧型管道的概念則是結合了管道及過濾策略應用者(Filter Policy applicator)兩種元件而產生;也就是說它能夠協調動作同步化,轉換已過濾資料,進行分離式機能甄選(screening),或針對資料流(stream)進行格式轉換(format transformation)。

分散式資料過濾器的好處:在於容許運作中的內容供應商(active content provider),能夠針對特殊的客戶端需求,量身定作資料來源(data source),而不需要特別維護一個大型的客戶資料庫(client database),抑或大型的分散式應用軟體;只有在為了滿足客戶端所特別訂定的政策時,有需要用資料政策來裁切資料源,才需要對過濾代理器資料庫(Filter Agent Database)進行維護。客戶端所接收資料流中的資料,應當通過預先定義的過濾政策篩選,或其格式遵循客戶端所定的標準才行。過濾政策中,可以包含專門針對某種特殊資訊型態所定的規格 ,或轉換演算法。過濾服務(Filter Service)元件則提供了中央集權式的存取權控制(access control)機能,以因應電子商務(E-commence)需求,為允許重新撰寫(re-programmability)的分散式資料客戶端(distributed data clients),提供持續性的資料庫服務(persistent database)。若在一個架構中需要對複合式資料(complex data)進行控制及表述,則必須依賴可重新訂定的過濾政策,及過濾政策評估演算法(以規則為基礎的邏輯引擎, rules based engine),來提供一個開放標準,以因應彈性且多樣化的行為。

 

圖一、基本樣式結構。

適用範圍(Applicability)

下列幾種狀況可以考慮使用分散式資料過濾器:

結構(Structure)

圖二展示了整個分散式資料過濾架構,此架構應用一個分散式的過濾服務,及數個過濾代理器,合作達成我們所要的機能。

過濾服務元件群由兩種不同型態的中間層物件所構成[3]:僅有單一實體(a singleton)[1]的過濾服務元件(Filter Service Component),以及數個過濾代理器元件[1]。每個過濾服務元件中都包含了一個資料庫,裡面記錄了多個群組的過濾政策物件,由這些物件處理分散式資料的過濾。而連接後端資料庫的介面[3],則可以藉由 CORBA 的中間層物件來整合處理。(或許可以利用 CORBA 或 JAVA 元件將資料庫封裝起來,以支援三層式架構的運行[3])過濾服務(Filter Service Component)這個僅有單一實體的元件,則會運作在過濾服務伺服器中,負責維護最主要的過濾服務資料庫(Filter Service Database)。

過濾代理器元件則運作在遠端伺服器裡,或內容供應商的伺服器中,負責維護小型區域性資料庫。過濾代理器資料庫內含用來支援特殊使用者介面的資料過濾政策。過濾代理器算是個智慧型管道,負責過濾或轉換由內容供應商的資料伺服器物件(Data Server Object)所提供的內容。[2]過濾代理器會啟動一個接收資料的執行緒,並且會處理大量資料回傳的要求;當內容供應商提供回呼(callback)服務時,過濾代理器也會開啟一個已登記的回呼物件 ,來因應這項服務。

過濾服務資料庫(Filter Service Database)是個重要,且非常穩固的容器,負責保存所有過濾服務用戶端的 ID 及帳戶資訊。過濾服務元件和過濾代理器一樣都擁有智慧型管道,使系統能避開用戶端的活動狀態。在過濾服務用戶端與過濾服務系統接觸的過程中,過濾服務元件處於一個樞紐地位。

 

圖二、分散式資料過濾架構樣式。

 


下一頁