量身定制異構數據庫統一檢索平臺

文/范澤華

海量數字文獻資源的出現，要求圖書館采用先進技術構建一種全新的文獻信息服務環境來滿足不斷擴張的用戶需求。如果用戶對資源缺乏足夠的認識，對資源的搜索系統不熟悉，且他們在使用各個系統時每次都要進行登錄和認證，那么這就給用戶檢索和利用數字資源帶來極大的不便。

華中科技大學圖書館依托豐富的電子資源，開發出統一檢索平臺(HUSTLIBURP，HUSTLIB-UNION RETRIEVAL PLATFORM)。

合理權衡是架構設計的依據

軟件的開發是在DotNet框架平臺上進行的。架構（Architecture）是軟件設計中非常重要的一個環節。在軟件開發的過程中只要確定了需求和架構，那么這個軟件基本上可以定型。

架構設計是一種權衡。一個問題總是有多種解決方案，而要確定唯一的架構設計的解決方案，就意味著要在不同的矛盾體之間做出一個權衡。在設計的過程中總可以看到很多矛盾體：開放和整合、一致性和特殊化、穩定性和延展性等。任何一對矛盾體都源于對軟件的不同期望。滿足軟件穩定運行的要求，就必然會影響對軟件易于擴展的期望。如果要求軟件簡單明了，那么就會增加設計的復雜度。沒有一個軟件能夠滿足所有的要求，因為這些要求之間帶有天生的互斥性。而評價架構設計的好壞的依據，只能是在其間做出權衡的合理性。

我們認為，良好的架構應能實現重用、透明、延展、簡明、高效、安全等目標。構造三層應用程序

我們從抽象的體系結構級別開發面向對象的應用程序。它在邏輯上構造成三層服務應用程序。應用程序是基于OLTP處理模型的。硬件和網絡體系結構是基于四級分布的，這要求Web服務器功能和應用程序服務器功能具有不同的物理級，并基于復雜的Web應用程序創建一個部署規劃，以便將組件映射到服務器。

解決方案是使用 Microsoft.NET 技術構建的。表示層基于 ASP.NET 中內置的 Web表示框架。ASP.NET 使用內置的代碼隱藏頁功能來簡化 Model-View-Controller 的實現。使用 ASP.NET 內置的 Page Controller 機制來實現表示邏輯。業務層中的域對象是 .NET托管對象。因為表示層和業務層部署在不同的級上，所以使用服務器激活，使對象通過.NET Remoting實現代理。最后，數據層基于Microsoft.NET Framework中的ADO.NET類來提供數據庫訪問。表模塊和業務實體是使用ADO.NET的數據集組件構造的。數據訪問組件的其余部分由.NET構建塊提供。

由于在構建企業級解決方案時會涉及到大量模式，這些模式被組織成更小、更緊密相關的模式集。在瀏覽模式的機制方面，我們利用了關系、抽象級別、群集和視點。實際上，當用戶在角色、主題范圍和詳細程度之間切換時，將自然而然地在這些機制之間進行了切換。

海量數字文獻資源的出現，要求圖書館采用先進技術構建一種全新的文獻信息服務環境來滿足不斷擴張的用戶需求。

用戶界面功能模塊化

用戶界面邏輯的更改往往比業務邏輯頻繁，尤其是在基于Web的應用程序中。例如，可能添加新的用戶界面頁或者可能完全打亂現有的頁面布局。畢竟，基于Web 的瘦客戶端應用程序的優點之一是可以隨時更改用戶界面，而不必重新分發應用程序。如果將顯示代碼和業務邏輯組合并放在單個對象中，則每次更改用戶界面時，都必須修改包含業務邏輯的對象，這很有可能引入錯誤，而且在對用戶界面進行極小更改之后都要重新測試所有的業務邏輯。

在某些情況下，應用程序以不同的方式顯示同一數據。在一些胖客戶端用戶界面中，常常用多個視圖同時顯示相同數據。如果用戶在一個視圖中更改了數據，則系統必須自動更新該數據的其他所有視圖。

簡單有效的HTML頁通常要求采用一套與開發復雜業務邏輯不同的技能。用戶界面活動由以下兩部分組成：顯示和更新。顯示部分負責從數據源檢索數據，并格式化數據以便進行顯示。當用戶基于該數據執行操作時，更新部分將控制權返回給業務邏輯，以便更新數據。

在 Web 應用程序中，單個頁面請求將這兩方面的工作組合在一起：與用戶所選鏈接相關聯的操作進行的處理，以及目標頁面的顯示。在許多情況下，目標頁可能不與操作直接相關。例如，假設有一個用于顯示項目列表的簡單 Web 應用程序，在將項目添加到列表或從列表中刪除項目之后，用戶將返回主列表頁，因此，應用程序必須在執行兩個有很大差異的命令（添加或刪除）之后顯示相同頁面（列表），而所有這些操作均在同一個 HTTP 請求內進行。

結構分析

HUSTLIB-URP結構分析采用的是模式分析方法。模式描述能給定上下文中反復出現的問題，并基于一組指導性影響因素來建議解決方案。解決方案通常是一種簡單的機制，是為了解決模式中所標示出的問題而一起工作的兩個或多個類、對象、服務、進程、線程、組件或節點之間的協作。而OLTP 系統是用來管理事務處理的數據庫子系統。這些子系統確保每個事務的原子性、一致性、獨立性及持久性。

HUSTLIB-URP是一個典型的N層架構，其結構分為四個邏輯層。Web層

Web層為客戶端提供對應用程序的訪問。這一層是作為HUSTLIB-URP.sln解決方案文件中的Web項目實現的。Web層由ASP.NET Web窗體和代碼隱藏文件組成。Web窗體只是使用HTML提供用戶操作，而代碼隱藏文件則實現各種控件的事件處理。

Web層還使用Java Script頁面處理技術，實現選擇數據庫個數計數、內容介紹顯示、流量計算等功能。

業務外觀層

業務外觀層為 Web 層提供處理合法用戶驗證、服務器選擇、日期處理結果及程序異常結果顯示的界面。業務外觀層作為隔離層，將用戶界面與各種業務功能的實現隔離。除了低級系統和支持功能之外，對數據庫服務器的所有調用都是通過此程序集進行的。

業務規則層

業務規則層是作為HUSTLIB-URP解決方案文件中的商務規則項目實現的，它包含各種業務規則和邏輯的實現。業務規則完成合法數據的驗證、實現各個檢索數據庫的接口數據傳輸這樣的任務。

數據訪問層

數據訪問層為業務規則層提供數據服務。這一層是作為HUSTLIB-URP解決方案文件中的檢索項目來實現的。

業務外觀層和業務規則層比較有特點，在Web應用的N層結構開發中使用最多的是三層結構，分別為表示層、中間層和數據層。HUSTLIB-URP的Web層和數據訪問層較好理解，也就是傳統意義上的表示層和數據層，其業務外觀層和業務規則層則是其獨有的。

互操作使用采集方法

異構數據庫統一檢索平臺必須具有較好的互操作性?；ゲ僮髟诋悩媯}儲間使用采集的方式。

采集方法將關于這些資源的元數據從各個倉儲中收集并提供服務，原始資料還需要到它所在的倉儲中去提取。

由于大多數圖書館只擁有對電子資源的使用權，而電子資源中的大多數的數據庫接口一般不向用戶開放接口，因此，在異構倉儲間的互操作方法中，常用的是采集方法。

系統界面與檢索結果展示

系統可檢索中文和外文數據庫，兼容所有可檢數據庫。真正的原始結果在原有界面中提供全文結果，保留所有原有功能。本系統還可兼容所有主要OpenURL鏈接解析器，OpenURL鏈接可嵌入結果引文，方便用戶通過鼠標點擊找到電子文章。

解決方案必須確保滿足不可預知數量的用戶的要求，關注如何組合服務任意數量的應用程序或用戶的多個系統，以提高可伸縮性和可用性。在本系統中分別應用服務器群集、負載平衡群集和故障轉移群集方案，以提高系統的性能和可靠性模式。

本系統具有如下優勢：1.并發統一檢索；2.快速響應及結果緩存；3.通用性好；4. 結果頁面可以繼續瀏覽，支持文件下載；5.支持簡單檢索和高級檢索；6.異構數據庫統一檢索平臺IP認證；7.主頁面數據庫導航功能。

華中科技大學圖書館已經與武漢的8所全國重點大學圖書館合作，為他們量身定做應用系統，并且對湖北省圖書館和中國地質大學進行定制開發，向合作用戶提供部分源代碼。