kapok

             
                                               81_RedStar81@163.com
                                               TomHornson.student@www.sina.com.cn

                  一、數據訪問接口體系探討

1.Open Client/Open Server

C/S結構的中間件具體來說是配置在客戶端和服務器端的軟件包(注2::).Sybase Open Client/Open Server使分布式異構環境下的互操作成為可能.這里我們簡述Sybase C/S 中間件的工作原理.Open Client 是客戶端的API,它使客戶端應用程序和第三方的工具軟件把SQL語句和遠程過程調用(RPC)通過網絡發送給Sybase SQL Server,或經由Open Server應用(以利用Open Server開發為標志的應用)發送到其它的數據源(數據庫系統或Objects Managents或普通的數據存儲體)或其它類型的服務器.從Open Client API調用到信道傳輸有兩種很重要的行為發生,TDS(同于Telnet、Ftp等屬于應用層協議)格式化程序負責將上層的以API調用為標志的SQL或RPC等轉化為TDS消息包而支持多種傳輸規程的網絡庫把TDS包按對應客戶端與服務器端通信協議的封裝格式化.自然在客戶端,信道傳輸行為發生之前,同于其它的網絡應用還有很多的行為(具體參看有關協議模型的資料).Open Server是服務器端的API,它允許客戶機以SQL語句或RPC形式向一個非Sql Server數據源或其它類型的服務器發送請求.而后使該數據源或特殊服務器以標準的TDS格式向客戶端送回狀態和數據.Open Server可構成較為理想的C/S結構環境,即所有的客戶端能按統一的方式與所有的服務器交互,而所有的服務器亦能按統一的方式接受客戶端的請求,并以標準的格式向客戶端返回結果.作為擴展,我們這里再介紹點關于Open Client/Open Server的知識,以便讀者在下面詳細探討的ODBC體系分析中看到一些歷史的技術因素.事實上,正如上面所述,Open Client/Open Server都是API,到Sybase System 11為止,成熟的API包含客戶端的DB-Library、Client-Library和服務器端的Server-Library還有公共的CS-Library.重要的特性對比列舉如下

      1.Client-Library 優于 較老的DB-Library 而且Client-Library是與SQL無關的.

      2.DB-Library 不支持服務器端的游標.Client-Library功能全面,支持所有類型的游標,包括敏感和不敏感游標

      3.Open Server 是服務器端的API,用來開發服務器端應用.提供一致的數據訪問框架能力.Open Server應用既可與Sybase通信又可與非Sybase通信而Sybase SQL Server 連接其它的數據源需要利用Open Server API開發Sybase Open GetWay.

這里稍微提一下,通過對Open Client/Open Server實現的功能、當時數據庫系統服務特性、ODBC等較晚出現的接口體系、現時數據庫系統服務特性的綜合分析對比, 你會發

現Open Client 應用(Open Client Application,包含Sybase Open GetWay、Normal DataSource Application、Mail Open Client 及其它的一些體現統一的數據訪問框架的應用)在后來的數據接口體系中亦可實現同樣功能但是實現的方式、功能的實現體及其分布大不相同.雖然到現時還有一些影子.

2.ODBC(Open DataBase Connectivity : 開放數據庫連接)

ODBC是Microsoft Windows Open Standards Architecture (WOSA,Windows開放服務體系)的重要組成部分,由Microsoft公司于1991年底發布,短短幾年已成為事實上的工業標準.它建立了一組規范,提供了一套分層(隨著層的擴展,數據服務能力不斷的增強)的標準API(支持SQL),它解決了嵌入式SQL接口的非規范核心,數據應用系統用它來訪問任何提供了ODBC驅動程序(一組DLL)的數據庫,結束了過去針對不同的數據庫系統開發須掌握相應數據訪問API的時代.事實上,可將ODBC體系看作統一的數據訪問界面,而使這種統一的數據訪問成為可能的就是各數據庫產品廠商提供的相應的ODBC Provider(ODBC提供者即ODBC 驅動),但ODBC一般只能用于關系數據庫,很難訪問對象數據庫或其它非關系數據庫或數據系統.下面簡述ODBC體系的組成和工作原理. ODBC規范闡釋,ODBC體系有四個組成部分:Application、Driver Manager、Driver、Data Source.(如下圖).

 

    結合現實的高層開發工作流程如下：

         1.數據應用系統首先獲得在ODBC數據源管理器中建立的DSN(存儲了與數據提供程序連接的詳細信息包含數據庫位置、數據庫類型及相應的ODBC驅動程序等),然后 Driver Manager依賴一種叫做數據庫獨立的交流(Database Indepedent Communications Technology)的技術與數據源建立聯系(其中涉及客戶端和服務器端多種Agent對象的問題,詳情不敘,可參見下圖).

        2.Driver Mangaer調用特定ODBC驅動程序將ODBC標準API轉化為適用于具體數據庫系統的函數調用(數據庫特征不同之處也在這里翻譯如SQL語法差異等),然后經由客戶端的Request Agent發送到數據源.

        3.數據源Database Agent處理操作,將結果返回到客戶端的Request Agent,再向上經Driver(這里會有翻譯和標準化錯誤碼的行為)、Driver Mangaer返回給Application.

      需要說明的是定義和操作光標、維護事務、負責任何與訪問數據源的必要軟件層進行交互(包括與底層網絡或文件系統接口的軟件)等行為亦由驅動程序完成.

    結合ODBC API調用順序描敘工作流程:初始化(分配環境--->分配連接句柄--->與服務器連接--->分配語句句柄)-------->SQL處理(語句處理和檢索部分)-------->終止(釋放語句句柄--->與服務器斷開--->釋放連接句柄--->釋放環境).

3.OLE DB(Object Link and Embedding DataBase)

  隨著網絡技術和數據庫技術的不斷發展,現在的應用系統對數據集成的要求越來越高.有必要將不同的地方,不同的格式(如關系型數據庫和操作 系統中的文件、電子表格、電子郵件、多媒體數據以及目錄服務信息或主機系統中的IMS和VSAM數據等等)的數據集成.傳統的解決方案是使用大型的數據庫系統,把所有這些數據都移到數據庫系統中,然后按照操作數據庫的辦法對這些數據進行訪問,這樣做雖然能夠按統一的方式對數據進行各種操作,這種間接訪問方式帶來了很多問題,比如數據更新不及時、空間資源的冗余和訪問效率低等等

   此時Microsoft公司的通用數據訪問技術(UDA)應運而生,它使數據應用系統能通過實現標準OLE DB接口的數據提供者來訪問各種各樣的數據,而不管數據駐留在何處,也不需要進行數據轉移或復制、轉換.

   OLE DB作為一種數據訪問接口體系,體現了Microsoft的通用數據訪問(UDA)策略的理念.UDA能夠通過標準接口來訪問各種類型的數據.同于ODBC體系它也提供了一套標準API,不過OLE DB API是完全基于COM的,其特點是采用了多層模型.在COM通信層的一側是數據另一側則是數據使用者.這種基于COM的通信可被概括為在抽象對象(如DataSource、Session、Command 和 Rowset)上執行的操作.因此,當使用者連接到DataSource,打開 Session,發出Command,并返回數據Rowset時,便會出現這種情況.

  事實上,OLE DB是系統級的編程接口,它定義了一組COM接口,這組接口封裝了各種數據

系統的訪問操作,這組接口為數據使用者和數據提供者建立了標準,OLE DB還提供了一組標準

的服務組件,用于提供查詢、緩存、數據更新、事務處理等操作,因此數據提供方只需實現一

些簡單的數據操作.在使用方就可以獲得全部的數據控制能力.