23. 從網際網路存取 Microsoft SQL Server
網際網路程式設計概念
使用 ISAPI 存取 SQL Server
使用 ASP 存取 SQL Server
使用 XML 存取 SQL Server
本章總結
在 Microsoft Windows 2000 作業系統平台上使用 Microsoft SQL Server 2000，可以讓我們輕易把 SQL Server 資料庫「出版（publish）」到網際網路上。Windows 2000 與 Microsoft Internet Information Server（IIS）5的組合提供了包羅永珍的組件與介面，這些工具與 SQL Server 2000 資料庫連接與互動。本章將介紹從網際網路上存取 Microsoft SQL Server 的基本觀念。由於本書並非討論程式發展的專書，因此僅提供數種不同存取方式的概觀。相關程式設計的細節部分，市面上有許多不錯的書籍可供參考。
本章將從網際網路程式設計的概念開始，並介紹 Windows 2000 中預設的網際網路程式設計介面。接著會介紹 ODBC 程式設計與 ADO 的基礎觀念，以及存取 SQL Server 的幾種方法，包括 ISAPI 與 ASP。最後我們會討論 XML，瞭解何謂 XML 以及使用方式。本章涵蓋許多主題，相信應有助於瞭解網際網路程式設計的基本工具。
網際網路程式設計概念
本節將學到 SQL Server 與網際網路應用程式串連的基本觀念。這些應用程式必須包含兩個不同的介面，以執行不同的任務：一個介面用於使用者，另一個則用於 SQL Server。本節將介紹應用程式與 SQL Server 之間的串連方式，包括 IIS 與 ODBC。
以 Windows 2000 與 IIS 5 作為網際網路平台
利用 Windows 2000 與 IIS 5 作為網際網路應用程式的平台，可讓程式開發人員淋漓盡致地存取 SQL Server 的各種功能。程式開發人員可以利用的功能包括整合資料庫存取的伺服器端 script 語言、開放式資料庫連接（Open Database Connectivity，ODBC）資料來源、OLE DB（一套用來存取普遍性資料的強大元件物件模型（Component Object Model，COM）介面）、以及一種被稱為Internet Server API（ISAPI）的 Web 應用程式架構，最後一種架構為傳統 CGI（Common Gateway Interface，共同網關介面）應用程式的強大競爭者。
使用 ODBC 資料來源
就 Microsoft Windows 平台來說，ODBC 無疑是資料庫介面的最佳選擇。透過 ODBC，程式開發人員可以存取的資料來源類型相當廣泛，從最單純的純文字檔案到 Microsoft Excel 資料表，甚至 Microsoft Access 及 SQL Server 資料庫均可存取。ODBC 提供資料庫程式設計師一個通用且功能強大的抽象層級。
發展使用 SQL Server 的網際網路應用程式並不需要什麼特殊的手段。要透過 Web 服務器來存取 SQL Server，ODBC 資料來源已經提供了主要的一些方法。它們可以透過被稱作 ActiveX Data Objects（ADO） 的一個 OLE DB COM 物件集合來完成這類工作。ADO 提供一個對象導向介面（object-oriented-interface）來存取 ODBC 資料來源，這種方法比用 ODBC C API 來得簡單。利用 ADO，程式開發人員可以初始化一些簡單的對象來代表資料庫聯機、命令（例如 SQL 陳述式或預存程式）、以及資料錄集（recordsets），其類似於用戶端資料指標並且具有近乎伺服器端資料庫資料指標的功能性。所有的這些資料庫物件與介面讓我們在網際網路上發展使用 SQL Server 的程式變得簡單，尤其是 ODBC 中更提供了一些強大的功能，例如 聯機共用（connection pooling） 。
一個以 ODBC 為基礎的 Web 應用程式，如何適當地利用聯機共用是最要緊的問題之一。聯機共用允許一個中階的應用程式可以維護並分享與 SQL Server 資料庫的聯機。共用的聯機在指定的時間周期內將保持開放的狀態，並可分享給數個使用者。建立聯機通常是一個資源密集的作業並且造成資料庫伺服器的負擔。由於 Web 服務器與關聯的網際網路應用程式操縱著絕大多數的流量，透過資料庫聯機共用便可將建立聯機以及（尤其是）重建聯機的情況降至最低。如此一來，使用者聯機時間可以更快，也降低了資料庫伺服器的資源消耗。在預設的狀況下，IIS 5.0 會動態地分配資料庫聯機共用。
________________________________________
說明
當使用 ODBC 資料來源與 ADO 時，應以每一分頁為基礎使用 ADO 聯機對象。相較於使用整個工作階段對象，若在分頁需要時才建立聯機對象，並在不需要時立即釋放它，資料庫聯機可更快地釋放回共用狀態以便其它聯機使用。如此可大大地降低網際網路應用程式使用者等待聯機的時間。
________________________________________
選擇網路連結庫
雖然 SQL Server 可以支援具名管道及 Banyan Vines 等數種不同的網路連結庫，但當您在網際網路上部署一個 SQL Server 資料庫時仍應使用 TCP/IP 網路連結庫。在 SQL Server 網路連結庫的眾多選擇中，TCP/IP 能提供絕佳的網路適應性，聯機速度與效能。（網路連結庫已在 第 11 章 解釋。）
若使用 TCP/IP 作為網路連結庫，SQL Server 安全性模式會被限制在只能使用標準安全性。這種模式使用 SQL Server 登入來驗證。TCP/IP 並不支援整合式安全性，其使用 Windows 2000 賬戶來加以驗證，能提供較佳的安全性以及較有效率的方法來維護 SQL Server 系統主控台裡賬戶的集中管理。不過，使用整合式安全性相對在某些層面上也會惡化系統的效能。
首先，若使用整合式安全性，ODBC聯機共用的效力就會嚴重受限。採取整合式安全性時，每個透過Web伺服器驗證進入資料庫伺服器的使用者必須使用唯一的登入。如此一來，聯機共用所能提供的益處全然無效，因為共用的聯機會被拒絕，要聯機就必須使用與現存聯機相同的登入與密碼。
其次，以具名管道網路連結庫為基礎的聯機多半與整合式安全性一起使用，這種聯機一般說來會較為緩慢。使用具名管道還會造成聯機共用的一些問題。您可以將匿名賬戶對應到一個有效 SQL Server 登入，藉著這個方法在具名管道串連中使用聯機共用，不過多數 Web 服務器會採取挑戰與響應驗證模式或基本驗證模式以強制單獨聯機至 SQL Server。結果就是否定了聯機共用可提供的任何效能改善。
如果 SQL Server 與 Web 服務器是分裝在不同的機器上，使用整合式安全性也會對驗證模式的選擇有所限制。挑戰與響應驗證模式將無法使用，能選擇的只有基本驗證模式與匿名驗證模式。在網際網路上讓一個安全系統允許匿名驗證絕不是明智的做法，而基本驗證，一如剛剛所說的，則會讓聯機共用無法發揮。
使用 ISAPI 存取 SQL Server
ISAPI 是一組函式呼叫的集合，這些函式呼叫是設計來提供給網際網路應用程式開發人員一個可以延伸 IIS 機能的強大工具。ISAPI 應用程式程式能提供卓越的效能與低階的控制。事實上，ISAPI 應用程式程式在 IIS 上會比其它的 Web 應用程式來得更有效率。此外，透過 ISAPI，程式開發人員可以應用 Win32 API 的所有功能。
ISAPI 應用程式程式的動態連結程式庫（DLL）有兩種類別：擴充程式（extension）和篩選器（filter）。由於 DDL 是典型的編譯過的程式碼，執行的速度比直譯的程式碼或 script 語言要快很多。如果您的網際網路應用程式在執行速度與延展性上要求很高，那麼即使在程式設計與修改上會花點功夫，ISAPI 擴充程式與篩選器仍是最佳的選擇。接下來的幾節裡我們會詳細介紹 ISAPI 擴充程式與篩選器，然後解釋一下 ISAPI 應用程式程式的設計與使用上的限制。
ISAPI 擴充程式
ISAPI 擴充程式的執行方式與 DLL 相同，它們會被載入到 IIS 處理空間或是與其分開的另外一個處理空間。當您在 Web 服務器上安裝 ISAPI 擴充程式時可以選擇載入的方式。如果應用程式不太穩定，擴充程式應該被載入到分開的處理空間，以避免一個錯誤的 ISAPI 擴充程式毀了整個 Web 服務器。如果 ISAPI 擴充程式還在實驗階段或是尚未完整測試，這種事是有可能發生的。
要呼叫一個 ISAPI 擴充程式，可利用 URL 中.dll的虛擬路徑，例如： http://www.mydomain.com/SampleISAPI.dll 。
當我們利用這種方式呼叫 ISAPI 擴充程式後，如果它尚未被載入，則此 ISAPI 擴充程式會被載入到記憶體中，並掌控整個要求，而 IIS 就變成伺服器與用戶端瀏覽器之間一個單純傳送資料的媒介。這種應用的一個例子是網際網路月台上的自訂搜尋引擎。
ISAPI 篩選器
ISAPI 篩選器的執行方式也與 DLL 相同，不過它們在 Web 服務器啟動時便載入到 IIS 處理空間，並且保留在記憶體中直到伺服器停止。ISAPI 篩選器可以設定來接收任何數量的篩選器事件通知，這些通知訊息在 IIS 處理每個 HTTP 要求及產生 HTTP 響應時都會出現。當一個 ISAPI 篩選器被載入後，篩選器會與 IIS 通訊，應該要通知篩選器的事件便會透過一種特殊的結構來傳輸。每當有類似的事件發生時，對該事件註冊（registered）為應通知的篩選器便會收到一個事件通知訊息。
ISAPI 是一個功能相當強大的工具，可用來執行壓縮或加密，自訂的驗證，Web 流量日誌與分析，甚至伺服器端 scripting engine。您可以建立一個 ISAPI 篩選器檢查每個傳送至用戶端的 Web 網頁設定，搜尋特殊的標籤，並修改它們使其擁有一致的外觀，就如同一個 ASP 網頁所做的一樣。
ISAPI 篩選器能夠檢查每個進來與出去的資料流，這種能力使它成為一個好用且很有彈性的工具。不過，如果使用太多的 ISAPI 篩選器，整個網站的效能與延展性就會徹底降低。舉例來說，如果每個單一的輸入與輸出網頁都需要篩選，就有可能因篩選器的過度活動而造成系統嚴重的負擔。當您在決定篩選器要執行的工作時，應特別注意的是如何將其工作最小化。例如，在一個自訂的加密結構裡，篩選器應該只有在 IIS 需要從用戶端讀取資料或將資料寫入到用戶端時才執行加密。如此便可減少 ISAPI 篩選器應完成的工作數量。
ISAPI 的限制
ISAPI 技術雖然可以提供最佳的有效效能，但它也有一些缺點。由於寫作 ISAPI 擴充程式與篩選器大多利用 C 或 C++，因此開發 ISAPI 擴充程式與篩選器會比開發 script 網頁來得耗時，維護也會比較困難。當 ISAPI 擴充程式與篩選器需要修改時，整個應用程式都需要重新編譯，而不只是替換檔案。再者，即使 ISAPI 擴充程式與篩選器的執行速度一般說來會比與其功用類似的伺服器端 script 程式來得快，但它們無法保證能提供最理想的延展性。最後，某些程式設計抽象過程（大部分伺服器端 script 程式開發人員都認為該有的），特別是 session 對象，令人驚訝的是在 ISAPI 程式設計中竟然沒有。比起伺服器端 script 的程式設計，ISAPI 程式設計可說是相當低階。
使用 ASP 存取 SQL Server
ASP 是一個伺服器端 script 環境，程式開發人員可以利用它來建立互動的、動態網頁，進而發展出功能強大的 Web 應用程式。一個 ASP 檔案是一個副檔名為 .asp 的純文字檔案，裡面可包含任何文字組合、HTML 卷標、以及伺服器端 script。雖然 ASP 純粹執行於伺服器端，程式開發人員仍然可以在他們的 HTML 碼中包含用戶端 script，並且透過使用者的瀏覽器來執行而不是透過 Web 服務器來處理。
當 Web 服務器接收到一個對 ASP 檔案的要求，Web 服務器會執行檔案中包含在特殊標籤內的伺服器端 sript 並建立一個網頁。產出的結果是純粹的 HTML 檔案，其中可包含剛剛提到的用戶端 sript 組件。這個檔案接著被傳送到用戶端的瀏覽器，瀏覽器再將這些組件執行或表現在螢幕上。不會有任何 ASP 原始碼被傳送到用戶端。它們的分析與執行全都在伺服器上完成。使用者並不會見到建立網頁的 script 命令，他們看到的是這些命令建立出來的東西。
除了包含伺服器端 script，ASP 檔案也可以包含對 COM 組件的呼叫，以執行許多不同的任務，包括資料庫存取。此外，也可執行橫跨數種不同發展環境的商業邏輯對象。
ASP 在語言採用上相當中立。程式開發人員可以利用他們熟悉的 script 語言，如 Microsoft Visual Basic Scripting Edition（VBScript）、Microsoft JScript 或 Perl，來開發 ASP 檔案，而發現到開發過程並不困難。ASP 網頁可以使用已安裝在 Web 服務器中並與 COM 相容的 scripting engine 支援的 script 語言。 scripting engine 是一種程式，可用來處理以特定語言寫成的命令。IIS 包括的 scripting engine 支援常用的 VBScript（以 Visual Basic 為基礎）及 JScript（歐洲電腦製造商協會（European Computer Manufacturers Association，ECMA）262 語言規格的 Microsoft 版本）語言。從協力廠商那裡可以取得像是 Perl 這類語言的 scripting engine。
ASP 具有一些超越傳統 CGI 應用程式的優點。之前已經提到，對 VBScript 或 JScript 已經相當熟悉的程式開發人員將不需要學習新的程式語言，像是 C 或 Perl。ASP 提供了一些針對使用者工作階段，要求及響應處理的對象，這使得 ASP 的功能更為強大，並且讓個人化的內容開發更為容易。此外，比起利用 C 語言開發並編譯的 CGI 應用程式，ASP 僅需極少的時間與程式碼便可處理與收集 HTML 表單資訊，並將其儲存在資料庫裡。由於所有的 ASP 程式碼都是內嵌於 HTML 檔案中，因此 ASP 的維護也相當容易。
使用 XML 存取 SQL Server
XML 是 Extensible Markup Language （延伸標記語言）的縮寫，但 XML 實際上並不是一種語言。它其實是一種系統，可用來定義其它的語言，以及表達資料結構的通用文法。不同於僅僅用來指明 Web 檔案呈現方式的 HTML 標籤語言，XML 指定了檔案的內容與結構。所謂 結構化資料（structured data） ，指的是依其內容或使用方式標記起來的資料。
XML 天生具有可延伸的特性。程式開發人員利用 XML 來定義 Web 網頁內的資料，並依其需求限定細節的層級。舉例來說，程式開發人員可使用 <AUTHOR> 或 <TITLE> 標籤來描述書籍與出版的相關資訊。如果需要額外的定義，程式開發人員可以增加 <RETAILPRICE>、<PUBLISHER>，或甚至 <ISBN> 標籤。使用 XML 類似於在資料庫中建立一份資料表，它必須決定應用程式需要的資料元素，就彷佛決定需要哪些資料行才能完整地描述資料表中的資料列。
由於 XML 並不描述呈現方式，因此一個 XML 檔案只要寫作一次便可使用不同的裝置以各種方式來顯示，包括 網頁瀏覽器、行動電話、汽車的車用顯示器等等。這些裝置可能有各自的顯示需求：電腦螢幕也許是 800×600 像素，而一個無線網際網路裝置卻可能只支援 200×200 像素。由於 XML 僅定義了檔案的結構與內容，這些裝置只要利用各自整合的 XML 瀏覽器，便可將檔案依其特定的顯示需求呈現出來。不同於 HTML 檔案，XML 檔案在編寫後可以用得更為長久，不會因為新的顯示技術而很快被淘汰。
XML 真正有用的地方在於它可以利用 檔案物件模型（Document Object Model，DOM） 來產生互動的功能。DOM 是一個介面，用來定義存取檔案中資料的機制。使用 DOM，程式開發人員可以利用標準化的方式撰寫動態內容。舉例來說，程式開發人員可以使用 DOM 讓內容某一特定部分在一些情況下產生行為。使用這種方法可以讓檔案增加一些效果，例如可以讓文字的某一部份－比方說，一個在 XML 中已被稱為 <TITLE> 的卷標標記起來的書名－在使用者的滑鼠游標滑過時會改變顏色，表示說這是一個指向某一家線上書店的超級連結。要利用目前專門的 DOM 與樣式表規格來達成這類效果並不容易，不過由 W3C 制定的新的 DOM 標準將可協助 XML 程式開發人員維護真正的平台獨立。
XML 也很快地成為交換資料與檔案的標準。XML 可用來在網際網路上相異的資料庫系統之間交換資料。舉例來說，一家汽車零件供貨商可利用 XML 與汽車製造商交換存貨資料，即使這兩家廠商可能是在兩種不同的平台上使用兩種完全不同的資料庫系統。由於 XML 描述了資料結構的方式，因此它可以毫無問題地成為將兩種既不相同也不相容的系統之間的橋樑。
本章總結
在本章中，您已學習到在 Windows 2000 作業系統平台上利用 SQL Server 與 IIS 5 來開發網際網路應用程式的相關基礎。可用來開發應用程式的選擇相當多，包括像是 ASP 這類 script 環境，或是如 ISAPI 擴充程式與篩選器這類編譯器代碼，每種選擇都有其各自的優點與缺點。當您在選擇一個工具開發您的大型網際網路應用程式，應特別注意每一種選擇的交易限制以避免日後發生問題。
