uda

uca/uda(4張)

UDA（universal data access，通用數據訪問，也叫全局數據訪問）是microsoft為企業應用範圍內各種類型信息存取所制定的一項新戰略，它提供對多種數據源進行存取的一致界面。説起數據存取界面，microsoft以前是最令人感到混亂和迷惑的了。從早期的db－library到廣為接受的odbc，及至近年來基於對象的dao（data access obejct，數據存取對象），rdo（remote data object，遠程數據對象），dao/odbcdirect（dao/odbc直接存取），ado（activex data object，活動數據對象），給用户的選擇帶來了麻煩，而各種技術之間互不通用，也使得每選擇一種存取界面都要重新學習，加重了開發人員的負擔。因此，uda技術的出現將會結束這種混亂局面。今後只要使用uda即可，而不必勞神費力地在那些存取界面上選擇了。

uda可以看作是應用程序和各種數據之間的一箇中間層：uda一方面可以對各種類型的數據源進行高效存取，同時又提供一個獨立於編程語言、開發工具的統一編程界面。這樣，企業可以選用他們所熟悉的，容易使用的開發工具把分散的、完全不同的各類數據源集成起來，創建容易易維護，功能強大的應用程序。

技術

uda並不是一種全新的技術，它是由microsoft以前各種數據存取界面加以綜合發展而來的，並遵循microsoft最新的dcom規範。它的技術基礎是odbc、rdo、dao等這些成熟的，廣泛使用的技術。因此uda以得到業界廣泛支持的工業標準為基礎，所以能夠和各主要的數據庫平台一同工作，同時因而容易學習，便於使用。

uda實際是由microsoft的一些數據存取組件（data access components）組成的，它的各個組件用於各種特定的目的，而uda則定義了一種協同工作的機制。這些組件包括activex data object（remote data service，rds，以前稱為advanced database connector，adc），oledb和odbc，其中最重要的是oledb和ado。oledb提供了對底層各種數據源的存取界面，面向數據提供者；ado則嚮應用程序提供了統一的數據存取界面，面向應用程序開發人員。

綜述

微軟提供了UDA技術作為一個解決方案來解決從多個數據源中操作數據的問題。通過使用UDA技術，可以通過一個公共的界面集合來到達不同的數據源，比如可以使用UDA來操作關係數據庫（比如SQL SERVER，ORALCE）、文本文件、電子郵件、目錄服務中的目錄系統、OFFICE文檔等等。

UDA包括了一個軟件組件的集合用來和應用程序以及本身進行交互。UDA是基於COM之上的，所以UDA技術是和位置無關、語言無關，並且各個版本都是健壯的。MDAC是UDA的關鍵的實現。MDAC包括了ADO、OLE DB、ODBC、DAO、RDS等組件。ADO可以看成是OLE DB的上層，ODBC只能支持關係數據庫，可以認為是一種過時的技術，DAO主要是用來和ACCESS數據庫進行溝通，RDS是用來在服務器和客户機之間通過ADO進行記錄集的傳送，在基於Web的應用中大有作為。

如果大家經常從事在Windows下的數據庫方面的開發工作的話，對ADO、OLE DB、DAO等一定已經不陌生，但是對RDS不一定非常熟悉，因為它主要是用在基於Internet的體系架構上的，所以有必要介紹一下RDS。

當前最新的RDS的版本是2.0，如果使用的IIS是4.0版本的話，RDS的版本是1.5的，注意只有在安裝了IIS以後，系統才會帶有RDS組件。RDS的目的就是讓ADO的消費者能夠通過遠程的OLE DB提供者來獲取數據，ADO消費者實際上是通過HTTP或者DCOM協議和數據提供者進行聯繫的，客户端應用可以選擇直接和遠程機器上的OLE DB提供者進行交互，或者是通過和遠程機器上的COM控件進行交互，發出查詢，接收結果集合。

當採用和OLE DB提供者直接交互這種模式的時候，客户端應用需要提供給數據提供者需要的所有信息，比如連接字符串和命令字符串。客户決定需要工作的特定的數據源和需要執行的特定的命令，服務器端把結果（一般是一個ADO Recordset結果集）返回給客户.

當採用和COM組件（該組件使用ADO記錄集）交互的模式的時候，客户端應用程序激活中間件暴露出來的方法，然後把ADO Recordset作為一個參數進行傳遞，這裏表示層和用户界面層駐留在客户端，業務邏輯層就駐留在中間件（COM組件）上，數據和引用一致性檢查就在數據源端進行。這是真正的基於多層的開發模式.

在RDS2.0中有了新的內容，那就是開發人員可以直接寫他們自己的服務器端的商業邏輯，同時能夠使他們的客户端直接和遠程OLE DB提供者相連而不需要通過商業對象層。 這樣，Web服務器管理員能夠直接管理從RDS客户端到來的要求和OLE DB數據源聯繫的請求、並且能夠通過定製的句柄(handler)進行商業邏輯檢查，所謂商業邏輯檢查包括數據有效性檢查等等，它們能夠通過RDS被加到應用程序上去。服務器管理員可以很容易的編寫他們自己的定製的處理邏輯，為了幫助管理員使用這個定製的特徵，一個簡單的處理句柄(handler)已經被加到了所有基於SQL的OLE DB提供者上。句柄的行為是通過安裝在服務器上的 ini文件進行控制的。

當RDS被用來以客户端應用程序和遠程OLE DB提供者之間直接通訊的模式操作的時候，WEB服務器上的一個RDS DataFactroy對象用來處理客户端請求。DataFactory對象實現一個稱為Query的方法來打開一個新的記錄集，它也能夠通過SubmitChanges方法改變記錄集。

在RDS2.0中，DataFactory方法能夠通過編寫一個客户端對象的方法進行增強，它實現了一個特定的稱為IDataFactoryHandler的接口，開發人員可以建立他們自己的定製的對象來實現IDataFactoryHandler接口。然後這些對象能夠顯式的被DataFactory方法調用來擴展缺省的功能。具體的示例代碼如下：

AdorRs ActiveConnection =

Handler=MyHandler obj;Provider=MS Remote;Remote Server=網址;

DSN=TTMIS_CW;

AdorRs Source = "Select * from Products"

AdorRs Open

在上面的代碼段中，開發人員可以指定在服務器端的缺省句柄對象為MyHandler obj。當這段代碼被執行的時候，服務器缺省的調用DataFactory對象。但是，在DataFactory對象的方法Query打開一個記錄集的時候，它通過調用接口IDataFactoryHandler來創建MyHandler obj對象，在這個接口中，它調用GetRecordset或者是Reconnect方法，傳遞連接和命令字符串。在句柄的客户代碼部分能夠打開一個ADO連接或者是記錄集並把它傳遞給對象DataFactory,這樣用户就可以使用句柄內部的ADO事件來定製連接或者是記錄集對象

當客户端代碼使用RDS的時候，如果沒有指定句柄的話，DataFactory執行客户查詢，DataFactory使用ADO和OLE DB提供者進行交互。當客户端代碼指定了句柄的時候，客户端請求仍然由DataFactory對象執行，然後DataFactory對象輪流使用指定的句柄來處理客户的請求。

一個RDS服務器的客户端句柄是一個COM自動化對象用來實現IDataFactoryHandler接口，它必須由在註冊表中註冊的ProgID,註冊表的位置如下：

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DataFactory\HandlerInfo\safehandlerlist

客户端代碼在打開一個ADO記錄集的時候，必須在連接字符串中包含標籤'handler=;'以便能夠使用指定的句柄。如果使用RDS.Datacontrol來打開記錄集的話，句柄屬性必須設置為句柄的ProgID。服務器管理員可以強制RDS服務器使用句柄，當然需要在註冊表的如下位置，插入HandlerRequired=1

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DataFactory\HandlerInfo

當該註冊項被插入後，所有不包括'handler=;'的RDS請求都會被拒絕。同時必須指向一個有效的定製的句柄對象，這些對象在註冊表的safehandlerlist處進行註冊，具體位置和上面一樣。

為了保證數據通訊的安全性，MDAC2.0安裝了一個缺省的定製的句柄對象-MSDFMAP HANDLER。這個句柄的行為是由 ini文件驅動的，稱為Msdfmap ini。該文件被安裝在Windows目錄下，服務器管理員能夠配置該 ini文件，用來定製MSDFMAP HANDLER的行為。需要注意的是，管理員可以配置多個 ini文件，如果使用一個不同的 ini文件的話，在客户端的連接字符串必須為如下的形式：

RDSCONTROL Handler = "MSDFMAP Handler,myOtherNameSpace ini"

或者也可以為：

Rs open "SQL命令", Provider=MS Remote;Remote Server=MyWebServerSite;

Handler=MSDFMAP.Handler,myOtherNameSpace ini;Data Source=CustomerDatabase

最後需要説明的是，用户可以根據自己的需要定製句柄，句柄包含有兩個方法：

GetRecordset：該方法產生一個新的ADO記錄集，該記錄集必須用 adLockBatchOptimistic的加鎖類型打開，連接和記錄集對象必須把遊標位置設置為 adUseClientBatch。

Reconnect:該函數用來產生一個新的ADO連接對象，並且把ADO記錄對象attach到它上面去。連接對象的遊標位置必須為adUseClientBatch。

構想

下面是UDA的構想示意圖。

發展前景

uda作為microsoft企業範圍內信息存取的新戰略，得到microsoft的極大重視，有着廣闊的發展前景。最近，各大軟件廠商如sybase、informix、intersolv、ca等均表示支持microsoft的uda技術，説明有着廣泛的應用前景。

microsoft近來提出了“分佈式internet應用程序結構”（windows distributed internet applications architecture，dna），作為創建能通過網絡傳送的可伸縮的多層（multitier）分佈式計算解決方案。uda結構的中心元素，它提供一致的、獨立於工具和編程語言的高級數據界面，統一了client/server、web和各種其他的數據存儲和讀取技術，支持用户以統一的方式對結構化和非結構化進行存取。

對於應用程序開發人員來説，uda中的高級編程界面ado將成為他們存取各類格式信息的強有力工具。uda的發展，將導致一項新的數據存取結構。在這種結構下，前端應用程序是一致的、通用的，與後端數據庫的具體存取方法相分離；同時後端的信息源可以千差萬別，只要它們都遵循oledb規範，就可以被前端應用程序存取。

對於開發工具供應商，uda技術的採用可以使他們為他們的客户提供廣泛的數據存取，幫助他們建立功能更豐富、更強健的應用。而dbms廠商更可以利用uda技術為他們的dbms引擎和數據庫提供額外的高效客户端，從而擴大用户的選擇範圍。

無疑，uda這種通用的存儲結構，對於降低應用程序開發成本，提供應用程序的可維護性，進而增強企業的競爭力，獲得最大的商業利益，具有極其重要的作用。那麼，應當什麼時候轉向uda(或是ado)呢?是不是把現有應用程序都轉換為採用ado呢?在這裏筆者提出兩點建議：

(1)如果用户正在運行的應用程序採用的是rdo技術，那麼採用rdo就行了，沒有必要把它們轉換到ado。因為microsoft會繼續支持rdo，而且對大多數應用來説，rdo是完全滿足需要的。

(2)如果用户打算開發新的應用程序，那麼就應該採用ado。採用新的具有廣闊發展前途的技術，會帶來巨大的收穫。

下面具體介紹uda的數據存取組件。

oledb是uda結構中最重要的組件，它是整個uda技術的基礎。oledb是uda的底層的面向對象的數據存取界面，面向各種數據源，包括關係型數據庫、isam、jet或其他任何數據。它被設計為一種開放的規範，以存取各類數據源，包括從主機系統到桌面應用的各類數據。從這一點上説，它的作用類似於odbc。

oledb定義了數據存取、操縱的界面，這些界面主要供開發數據庫與數據庫引擎的數據提供者（data provider）使用，他們編寫出符合oledb規範的數據庫接口，使uda能對他們的數據庫進行存取。應用程序開發人員不必直接使用oledb，他們應該使用更方便的高層編程界面ado。

ado是基於oledb上的高層編程界面，它提供了一致的，高執行效率的數據存取方法。實際上，對應用開發人員來説，uda就是ado，只需使用a?do就可以存取各種數據源了。

ado非常容易使用，因為調用它的方式是人們熟悉的ole automation界面。ado被設計為用來取代rdo和dao，因而它們之間是非常相似的，都是基於層次對象的，ado可以看作它們的超集。熟悉rdo、dao的開發人員可以很快學會ado。但有一點需要注意：ado不向後兼容rdo，它們不能在代碼裏混合使用，但它們之間的差別是非常小的。

rds就是以前的adc，現在被集成到了ado中。為了區分adc與ado的關係，adc改為rds，它與ado使用同一個編程模型。

rds是一種新的web數據存取技術，它允許開發者在支持activex的瀏覽器中創建以數據為中心的應用。rds創建這樣的框架，它允許與odbc數據源（包括企業內的intranet和整個inter?net）方便地交互。rds的工作原理是：首先把數據從數據庫服務器中下載到本地的數據緩衝區，然後應用程序（或瀏覽器）通過rds操縱本地數據緩衝區中的數據，最後rds負責用緩衝區中的數據更新遠程數據庫中的數據，同時處理更新衝突。rds提供了下述優點：客户端的數據緩存、可更新的數據、並支持數據綁定的activex控件。

odbc的歷史已經有十幾年了，大家非常熟悉，它也是應用最廣泛的關係型數據庫的界面，幾乎得到了所有數據庫廠商的支持。它是低層的界面，用來針對sql server、oracle等關係型數據庫系統提供統一的編程界面。在uda中，odbc通過oled bprovider for odbc集成到oledb中。

uda在internet/intranet上的應用

uda不僅能在企業內部的intranet上得到有效應用，而且在整個internet上也可大顯身手。不論internet還是in tranet，它們包含了各類信息源的複雜組合，所有的信息都能通過瀏覽器瀏覽，在這裏uda大有用武之地。以前在internet/intranet上開發數據庫應用比較困難，現在通過uda可以方便地進行開發。

從uda的各組件在internet數據存取中可以看到，瀏覽器有兩種方式對遠程數據進行存取：

一種方式是：瀏覽器對數據的存取要求經過網絡傳到相應站點的iss（internet information server）服務器，然後由iis服務器使用ado來完成對各類數據源的數據的存取。這實際上就是microsoft大力推廣的活動服務器頁面技術（activex server pages，asp）。所謂asp技術，簡單地説就是對microsoft的iis在服務器端的一種擴展，它允許基於web的應用程序的開發人員編寫服務器端的腳本以擴展基於web的應用程序的能力。服務器端的腳本可以用vb script來寫，也可以用別的腳本語言來寫。這些用高級語言編寫的腳本在服務器端運行，所以它們不依賴於任何客户端的操作系統或瀏覽器。

另一種方式是：瀏覽器對數據的存取要求直接通知給客户端的adc（rds），然後由adc通過服務器端的oledb把所需的數據下載到客户端本地的數據緩衝區中，由adc管理本地的數據緩衝區中的數據，並負責與瀏覽器進行交互，最後adc使用本地的數據緩衝區中的數據對遠程數據源進行更新。這與傳統的客户/服務器結構模式是非常類似的。

相應地，使用uda開發internet/intranet數據庫應用，即可在客户端進行（通過adc），也可在服務器端進行（通過ado與oledb）。下面加以簡要介紹。

方法1：在服務器端建立ado頁面。

建立ado頁面是基於vb script的，與visual basic for application的開發是非常相似的。步驟如下：

·要創建ado中的adodb對象；

·打開與adodb對象的連接；

·在打開的連接上創建數據結果集，對數據結果集裏的數據進行操作；

·關閉連接。

下面是一小段程序代碼，用以説明上述步驟：

setconn=server createobject

（″adodb connection″）

conn open ado samples

setrs=conn．execute（″select for mauthors″）

方法2：在客户端建立adc頁面

建立adc頁面同樣是基於vb script的，但它是“重客户端”結構，類似於傳統的客户/服務器結構模式，並且還需要客户端的activex控件。建立的過程與vb的form的設計過程非常類似；數據控件用來管理連接；把別的對象綁定到數據控件上；數據控件處理數據集的移動。

建立adc頁面的步驟為：要增加adc對象；創建所需的數據綁定的控件；編寫客户的代碼。

MSDASDK新版本特點介紹

1 OLE DB和ADO可以被用來支持半結構化的數據，主要包括：

1．層次結構的數據存儲（比如文件系統，郵件系統，目錄服務，文檔存儲等等）

2．能夠通過URL直接和對象進行綁定

3．增強了和XML的集成能力，主要包括：

1．把層次化的記錄轉換成XML格式形式保存

2．能夠把記錄集保存到一個流（stream）中而不僅僅是磁盤文件中

3．和ASP的Response和Request對象相集成，保存ADO記錄集

2．增強了ADO錯誤報告能力

3. ADO MD用户能夠提取通過模式對象而不需要初始化和遍歷CubeDe