xmlns:xsd="http://www.w3.org/2001/XMLSchema">
List contents of DEPARTMENT table.
Lists each department.
SELECT * FROM DEPARTMENT WHERE deptno=:deptno Web 服務提供者運行時在運行時做下列事情： 從 DADX 文件創建 WDSL。 從 DADX 創建一個基于瀏覽器的測試環境。 使用 DADX 文件作為 Web 服務的實現。 由于用戶只需要編寫 DADX 文件，因此并不需要理解 WSDL 規范。一個適度復雜的 DADX 的 WSDL 長度可能有許多頁。運行時將確定一個 SQL 操作的參數（比如本例中的 deptno）并且還分析該 SQL 結果集的元數據，以創建正確的 XML 輸出類型。 用戶將完成下列步驟，以創建一個 DADX 應用程序： 創建一個 DADX 文件。 創建和部署一個 Web 應用程序。 訪問基于瀏覽器的測試環境，例如，http://localhost:9080/services/sample/list.dadx/TEST。 上一頁123456下一頁 修改 Web 應用程序中的 DADX 并再次調用測試。 DADX 中的查詢是作為一個實現工作的，因為運行時執行查詢并將結果格式化為 XML。這意味著用戶不需要用編程語言編寫代碼并理解 Web 服務引擎的編程模型。假如用戶自己希望為 WebSphere 編寫 Web 服務，他將需要編寫 Java 代碼或者 EnterPRise Java Bean（EJB）來調用 SQL。 用于訪問測試環境的 URL 包括 DADX 名稱（例如，list.dadx）以及其他部分。其中一個部分是“services”，它是 DADX 所在的 Web 應用程序的 名稱或者 上下文根。另一個部分（mydatabase）是一個 組名稱。組是 Web 應用程序中的 DADX 文件的容器。組之間相互共享配置設置，比如用于連接數據庫的數據庫用戶。在后面，我們將看到假如配置數據庫用戶。 安全性方面 Web 應用程序或者 Web 服務應用程序的安全性由許多部分組成。其中許多安全性方面對于數據庫治理員是已知的。本節解釋在 WebSphere 中這是如何工作的。這里我們關注的事情是： 識別/認證 授權 完整性/機密性 識別意味著告訴該服務您是誰。例如，您可以作為用戶“dirk”進行連接。當然，假如沒有 認證，這就沒有太多的意義。通過認證，您提供一個證實，表示您的確就是所聲稱的那個人。這個證實可以是一個口令或者某種安全令牌。這對于使用“CONNECT TO sample USER dirk USING mypassWord”SQL 命令的用戶來說是熟悉的。 授權負責為用戶答應或者拒絕特定的事情。在數據庫系統中，這是通過“GRANT”語句完成的。我們將解釋在 Web 服務上下文中，用戶是如何做類似“GRANT SELECT, INSERT ON CALENDAR TO USER PHIL”的事情的。 上一頁123456下一頁 完整性是一種確保消息沒有被篡改的方法。通過使用 機密性，我們可以確保沒有人能夠讀取在非安全的通信隧道上傳輸的消息。確保機密性的一個例子是使用加密。 Web 服務安全性 您可以通過以下兩種方式獲得 Web 服務安全性： 傳輸級安全性。 消息級安全性。 傳輸級安全性意味著安全機制是通過傳輸所提供的方法獲得的。例如，您可以通過使用 HTTPS（安全 HTTP）獲得機密性。HTTPS 將加密所有被交換的 HTTP 消息。假如 Web 服務切換到另一個傳輸，比如不具有加密通信隧道的非安全的 HTTP，那么消息將再次以明文傳輸。 本文解釋如何為 DB2 Web 服務提供者設置傳輸級安全性。雖然還沒有介紹消息級安全性，但是我們先來看看這個特性。 由于您還希望非安全傳輸上的安全性，因此需要使用 消息級安全機制，比如 WS-Security。WS-Security 答應用戶使用多種安全性元素，比如用戶名、簽名和加密機制以及安全令牌。與傳輸級安全性相比，WS-Security 答應用戶只是加密消息的一部分（例如，信用卡號碼）而不是加密客戶機和服務器之間的完整通信。它還答應不同的識別和認證機制。 圖 1. WS Security 路線圖
如圖 1 所示，WS-Security 是一個 Web 服務安全性標準，其他的 Web 服務安全性標準構建在它的上面。IBM 和 Microsoft 發布了 WS Security 的這個路線圖（請參閱參考資料小節）。其他的標準簡要描述如下： WS-Policy：描述中間點和端點上的安全策略（或者其他商業策略）的能力和約束（例如，所需的安全令牌，所支持的加密算法，隱私權規則）。 WS-Trust：描述使 Web 服務能夠安全地進行互操作的信任模型的框架。 上一頁123456下一頁 WS-Privacy：描述 Web 服務提供者和請求者如何聲明主題隱私權首選項和組織隱私權實踐聲明的模型。 WS-SecureConversation：描述如何治理和認證各方之間的消息交換，包括安全上下文交換以及建立和繼續會話密鑰。 WS-Federation：描述在異構的聯合環境中如何治理和代理信任關系，包括支持聯合的身份。 WS-Authorization：描述如何治理授權數據和授權策略。 在下面，我們討論 DB2 Web 服務提供者安全性所引起的問題，并展示如何在 WebSphere 中解決這些問題。 在 WebSphere 中實現 Web 服務安全性 DB2 Web 服務提供者的安全性問題 為 DB2 Web 服務提供者設置安全性的治理員的問題是識別和認證的問題，這個我們已經提到過。我們將要求用戶通過 HTTP 認證進行客戶認證來解決該問題。HTTP 認證意味著 HTTP 請求必須具有一個帶有用戶標識和口令的 HTTP 頭字段。當您在瀏覽器中碰到一個要求認證的 Web 頁面時，您通常得到一個對話框，讓您為該 Web 頁面輸入您的用戶標識和口令。在 SOAP 情況下，必須修改客戶機程序以發送用戶標識和口令。 我們通過對 URL 使用 J2EE（Java 企業版）授權機制來解決授權問題。由于所有的 Web 服務請求都基于發送消息到特定的 URL，我們可以配置 Web 應用程序使得只有特定的用戶可以發送請求給特定 URL。URL 可以是一個 DADX，或者是一組完整的 DADX 文件。我們將在后面具體討論。 機密性和完整性可以通過要求用戶使用 HTTPS 來簡單地得到解決。這意味著所有網絡傳輸都是加密的，并且消息篡改也可以檢測到。 這里還有最后一個問題，就是將利用 WebSphere 認證的用戶映射到執行 DADX 中的語句的數據庫用戶。由于我們的運行時不能確定在 HTTP 認證中所使用的用戶標識和口令，因此我們不能使用該用戶連接到數據庫。在某些情況下，假如應用服務器用戶不同于數據庫用戶，這甚至是不現實的。這種情況的一個例子是應用服務器和數據庫服務器運行在不同的機器上并且都使用操作系統作為用戶注冊表。相反，您可以在組（包含多個 DADX 文件）上指定一個用戶標識和口令。該用戶將被用于執行組中的 DADX 中的所有 SQL 語句。假如希望區分執行 SQL 的用戶，您可以創建單獨的組，比如針對會計部門的用戶創建一個組，針對工程部門的用戶創建一個組。 上一頁123456下一頁 預備工作 對于下面的步驟，我們假定您已經按照安裝所推薦的，從 DB2 V8 安裝中的 sqllibsamplesjavaWebsphere 目錄下，將 dxxworf.zip 解壓到 c:worf。您還需要遵循安裝指令。您不需要安裝示例 Web 應用程序 services.war，因為我們在下面的步驟中將要修改它。假如已經部署 services.war，這是可以接受的，因為我們將要把該示例 war 部署為一個不同的 Web 應用程序。 我們將使用應用服務器工具集（Application Server Toolkit，ASTK）來修改示例 war 文件，以增加安全性約束。ASTK 非常類似于 WebSphere Studio，因此假如用戶喜歡用 WebSphere Studio ，也能達到同樣的效果。第一步是將示例 war 文件導入到 ASTK 中。圖 2 中描述了這一步。 圖 2. 導入示例 war 文件
輸入您希望添加安全性約束的 war 文件的位置。 圖 3. 指定 war 文件的位置
我們創建一個名為“SecureDADX”的新的 Web 應用程序，該應用程序將包括 DADX 文件和其他配置文件。 圖 4. 指定 Web 應用程序的名稱
同時，還將示例 war 文件從符合 J2EE 1.2 遷移到符合 J2EE 1.3。選擇 SecureDADXWeb 模塊，右擊并選擇 Migrate和 J2EE Migration wizard。這答應我們在后面使用 WebSphere 5 DataSource。 我們已經導入 Web 應用程序，現在可以針對安全性對它進行修改了。下一步是在 war 文件中設置數據庫連接。 上一頁123456 新聞熱點
疑難解答
