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 新闻热点
疑难解答
