WebSphere Application Server V5 中的数据库验证

文档选项 未显示需要 JavaScript 的文档选项 样例代码

级别： 初级

Jian Tang (jian.tang@us.ibm.com), IBM WebSphere Development, IBM
Teresa Kan (teresa.kan @us.ibm.com), IBM WebSphere Architecture and Development, IBM

2004 年 5 月 01 日

在 WebSphere Application Server V5 中，应用组件提供者可以使用 res-auth 元素来指定如何将安全性主体（security principal）和数据源相关联，要么用容器管理别名，要么用组件管理别名，或者二者同时使用。本文描述了这些别名和部署描述符中的 res-auth 元素之间的关系，同时也描述了在不同的 res-auth 设置下 WebSphere Application Server 运行时如何将两个别名和数据源相关联。

引言

在 J2EE 1.3中，资源管理器连接工厂引用通过在部署描述符中使用 resource-ref 元素来作用于应用组件。每个 resource-ref元素都描述了对单个资源管理器连接工厂的引用。resource-ref 元素包括：

• 描述元素
• 强制性的 res-ref-name、res-type 和 res-auth 元素
• 可选的 res-sharing-scope元素

在这些元素中，res-auth 用于指定应用组件提供者如何将安全性主体（用户 ID和密码）和资源管理器相关联。应用组件提供者可以指定应用程序是否处理对资源的验证（res-auth = Application），或者指定是否将这一工作指派给容器（res-auth = Container）。

IBM® WebSphere® Application Server（以下称为 Application Server） V5 （包括版本 5.0、5.0.1和 5.0.2）是一个遵循 Java™ 2 Enterprise Edition （J2EE） 1.3的应用服务器。应用组件提供者可以使用 res-auth 部署描述符元素来指明在 Application Server 运行时中使用哪种验证方法。不同的是，ApplicationServer 也为容器管理持久性（CMP）Enterprise Java Beans （EJB）提供了一个 IBM 扩展来验证数据源。

让用户理解 Application Server如何在不同的 res-auth 值的情况下验证基础数据库是很重要的。要是没有很好地理解，用户编写的应用程序就可能不能获取连接，或者获取与错误用户 ID的连接。为了达到这一目的，本文详细分析了数据库验证。我们首先描述在 J2EE 1.3 规范中定义的数据源验证的必要条件，然后描述Application Server 提供什么特征来允许应用程序验证数据库，同时也会介绍在不同场景中会使用哪一个用户 ID 和密码来验证。然后给出一些示例来说明关于如何在 WebSphere Studio Application Developer（下面称为 Application Developer） 版本 5 中设置 res-auth 部署描述符。最后，我们还会提供一些使用 ApplicationServer 管理控制台来创建数据源和设置验证数据别名的示例。

回页首

J2EE 1.3 中的数据库验证

J2EE 1.3 详细说明了对所有类型的资源（包括数据库、J2C 连接工厂、JMX连接工厂及其他）进行资源验证的必要条件。这里我们只把重点放在数据库验证方面。

根据 J2EE 1.3 规范，应用服务器与Enterprise Information System （EIS）互相配合，从而确保恰当地验证与基础 EIS 建立连接的资源主体。J2EE连接器体系结构识别两个得到广泛支持的验证机制：

• BasicPassword:一个基本的基于用户名/密码的验证机制。
• Kerbv5: 基于 Kerberos Version 5 的验证机制。

大部分数据库都要求应用程序提供一个用户 ID和密码来与它们的数据源建立连接。应用程序按照 JDBC 程序设计模型，使用数据源来访问数据库中的数据。在 JDBC 程序设计模型中，有两种方式可以通过 DataSource对象来将用户 ID 和密码传递给数据库：

1. 应用程序在 DataSource 对象中设置用户 ID 和密码。
   一旦在 DataSource 对象中设置了用户 ID 和密码，它们就成为您在建立连接时的缺省用户 ID 和密码了。如果应用程序调用 DataSource对象中的 getConnection 方法来建立连接，而不传递用户 ID 和密码参数，那么在使用 getConnection（）时就会通过缺省的用户 ID和密码来建立连接。
2. 应用程序直接将用户 ID 和密码传递到 getConnection（String userid，String password）方法中。
   在这种情况下，应用程序使用确切的用户 ID 和密码来明确告知数据库它要获取连接，而无视在 DataSource 对象中设置的是什么用户 ID 和密码。

清单 1 显示的样本代码从 DB2 类型 2 JDBC 驱动的数据源获取连接。DB2 数据源的类是 COM.ibm.db2.jdbc.DB2DataSource 。在这些代码中：

• 我们在数据源中调用 setUser（userid1） 和 setPassword（pwd1），通过这样的方法来建立数据源的缺省用户 ID 和密码。
• 连接“con1”是使用不带参数的 getConnection（）从数据源“ds”获得的连接。因此，连接是通过缺省的用户 ID/密码（userid1/pwd1）获取的。
• 连接“con2”是通过不同的用户 ID/密码（userid2/pwd2）从数据源“ds”中获取的。

清单 1. 以不同的用户 ID 和密码获取两个连接

COM.ibm.db2.jdbc.DB2DataSource ds = new COM.ibm.db2.jdbc.DB2DataSource（）;
ds.setDatabaseName（sample）;
ds.setUser（userid1）;
ds.setPassword（pwd1）;
java.sql.Connection con1 = ds.getConnection（）;  
... ...
java.sql.Connection con2 = ds.getConnection（userid2，pwd2）;
... ...
                

在任何的应用服务器中使用数据源时，您都不能够直接构建数据源并在应用程序中设置它的特性，如清单 1所示；在应用程序中直接构建数据源会使应用程序无法在不同的数据库中使用，这会导致数据源不可由应用服务器进行管理。通常获取 DataSource对象的编程做法是从 JNDI 名称空间中查找数据源。数据源的 JNDI 名称是指定为在应用部署描述符中引用的资源。在部署过程中，这一资源引用会被链接到Application Server 运行时环境中定义的数据源的 JNDI 名称上。由于 res-auth 是资源引用元素的一部分，所以验证主体（用户 ID和密码）就会由 Application Server 传递给数据库（这一点随后会讨论）。清单 2 显示了如何在应用程序中查找数据源的一个示例。

清单 2. 从 JNDI 名称空间中查找数据源

try {
 InitialContext ctx = new InitialContext（）;
 // Perform a naming service lookup to get the DataSource object.
 DataSource ds = （DataSource）ctx.lookup（java:comp/env/jdbc/myDS）;
} 
catch （Exception e） {
 // Handle the exception
}
                

根据 J2EE 1.3规范，应用组件提供者使用 res-auth 部署描述符元素来指明使用两种资源验证方法中的哪一种。res-auth 的值可以是 Container 或 Application：

• Container：意味着容器将代表应用程序登录到资源管理器。
• Application：应用程序必须程序化地登录到资源管理器。

接下来，我们将会看到在不同的 res-auth 值下如何使用用户 ID 和密码来验证数据库。

回页首

WebSphere Application Server V5中的数据库验证

WebSphere Application Server V5 提供了两种类型的数据源：

• WebSphere Application Server V4数据源
• WebSphere Application Server V5 数据源。

如果应用程序使用版本4 的数据源，则应用程序所具有的连接行为和 Application Server V4 中的是一样的。Application Server V5也包含这一支持，从而能够提供对 J2EE 1.2 应用程序的支持。

如果应用程序使用版本 5 的数据源，则数据源会使用 J2EE 1.3连接器体系结构来访问关系数据库。只有版本 5 的数据源才使用在 J2EE 1.3 中指定的验证机制。因此，本文讨论的数据源只应用于 WebSphereApplication Server V5 数据源。

除了以上部分提到的这两种获取连接的方式以外，Application Server V5还提供了一种特定于 IBM 的获取连接的方式：首先查看从 JNDI 名称空间得到的数据源，找出 com.ibm.websphere.rsadapter.WSDataSource ，然后使用 WSDataSource.getConnection（com.ibm.websphere.rsadapter.JDBCConnectionSpec） 来获取连接。采用这种方式时，您可以根据自己的喜好来将用户ID 和密码设置在 JDBCConnectionSpec 对象中。清单 3 显示了如何使用这种 IBM 扩展方式来获取连接。

清单 3. 使用 WSDataSource.getConnection（JDBCConnectionSpec）来获取连接

// Create a JDBCConnectionSpec object
JDBCConnectionSpec connSpec = WSRRAFactory.createJDBCConnectionSpec（）;
connSpec.setUserName（"userid1"）;
connSpec.setPassword（"pwd1"）;
// Get connection using connection spec 
java.sql.Connection conn = （（com.ibm.websphere.rsadapter.WSDataSource）ds）.
 getConnection（connSpec）;
                

如果在 JDBCConnectionSpec 对象 connSpec 中设置用户ID 和密码 userid1/pwd1，那么从验证的角度看， WSDataSource.getConnection（JDBCConnectionSpecconnSpec） 与 getConnection（userid1，pwd1）所产生的效果是一样的。

如果在JDBCConnectionSpec 对象 connSpec 中没有设置用户 ID 和密码，那么从验证的角度看， WSDataSource.getConnection（JDBCConnectionSpecconnSpec） 与 getConnection（）所产生的效果是一样的。

因此我们将要讨论在不同的 res-auth设置下 getConnection（）和 getConnection（String userid，String password）的不同行为。

当应用程序试图通过调用 Application Server DataSource 对象中的 getConnection（）方法或 getConnection（String userid，String password）方法来获取连接时就会发生数据库验证。Application Server 的 DataSource对象并不是真实的数据源对象，也不是真实的物理连接；这二者都是封装在基础 DataSource 对象和连接对象中的 Application Server代理。当应用程序调用 Application Server 的 DataSource 对象中的任一种 getConnection方法时，Application Server 运行时首先都会试图以特定的用户 ID 从连接池中获取连接。如果 Application Server运行时不能够从连接池中找到连接，则它会调用基础数据源中的 getConnection 方法，并根据应用部署描述符中的 res-auth 的值来决定使用哪一个用户ID 和密码进行验证。

为 Application Server的数据源定义用户 ID 和密码

不像 Application Server V4 那样将用户 ID和密码设置为数据源的属性，Application Server V5 要求将用户 ID 和密码封装在 Java 2 Connector （J2C）Authentication Data Entry 中。J2C验证数据实体提供一种管理用户 ID 和密码的通用且安全的方式来验证 Application Server V5 中的任何资源。这些实体是和别名相关联的，其中，别名可以用在资源定义中以引用特定的用户 ID和密码对。

在配置数据源时，部署器通过容器管理别名或组件管理别名，或者二者同时使用来与数据源相关联。如果您的应用程序的 res-auth部署描述符元素设置为 Container，则用的是容器管理别名；如果您的应用程序的 res-auth 部署描述符元素设置为 Component，则用的是组件管理别名。

容器验证

当 res-auth 元素设置为 Container时，Application Server 在运行时查找数据源时就会尝试获取容器管理别名。如果在数据源中定义了容器管理别名，则 ApplicationServer 从容器管理的别名中获取用户 ID 和密码，然后调用基础数据源中的 setUser（String userid）和 setPassword（String password）方法（如果基础数据源有这两个方法的话）。

如果 Application Server 运行时获取容器管理别名失败，则 setUser（String userid）和 setPassword（String password）方法不会在基础数据源上调用。如果应用程序调用 getConnection（）方法或 getConnection（String userid，Stringpassword）方法来连接 DataSource对象，则 Application Server 运行时会从容器管理别名中提取用户 ID 和密码（例如，userid1/pwd1），然后调用基础数据源中的getConnection（userid1，pwd1）方法。换句话说，在 getConnection（String userid，String password）中传递的用户ID 和密码会完全被忽略。

如果没有和数据源相关联的容器管理别名，则会调用 getConnection（）方法来连接基础数据源。在那种情况下，如果基础数据库需要用户ID 和密码的话您就不能够获取连接。表 1 显示了使用哪些用户 ID 和密码来获取来自数据源的连接：

• 第一列显示的是容器管理别名拥有值为 userid1/pwd1 的用户 ID/密码的情况。如果是在数据源中调用 getConnection（）方法，那么可以使用在容器管理别名中设置的用户ID 和密码来获取连接。如果在数据源中调用的是 getConnection（userid2，pwd2）方法，则用户 ID/密码值userid2/pwd2 会被完全忽略，并在基础数据源中调用 getConnection（userid1，pwd1）方法来获取连接。
• 第二列显示的是没有和数据源相关联的容器管理别名的情况。在这种情况下，getConnection（）和 getConnection（userid2，pwd2）方法都会从需要用户ID 和密码的这些数据库中接收到异常，因为没有为数据源设置缺省的用户 ID 和密码，这样会在基础数据源中调用 getConnection（）。

表 1. 当 res-auth 值为 Container 时使用的验证数据

当指定应用程序的 res-auth 等于 Container 时，资源验证就被配置为由容器进行处理。在这种情况下，应用程序不能够使用 getConnection（String，String）方法，因为这种方法是由应用程序用来进行数据库验证的；如果它们这样做，那么 ApplicationServer 会忽略用户 ID 和密码以便将验证工作指派给容器。

应用程序验证

当 res-auth 元素设置为 Application 时，Application Server在运行时查找数据源时就会尝试获取组件管理别名。如果在数据源中定义了组件管理别名，则 Application Server 从组件管理别名中获取用户ID 和密码，然后调用基础数据源中的 setUser（String userid）和 setPassword（String password）方法（如果基础数据源有这两个方法的话）。

如果 Application Server 获取组件管理别名时失败，则 setUser（String user id ）和 setPassword（String password）方法不会在基础 DataSource对象中调用。如果应用程序调用 Application Server 的 DataSource 对象中的任一种 getConnection方法，那么同样的方法也会在基础数据源中调用。表 2 显示了要从数据源中获取连接时使用哪一种用户 ID 和密码：

• 第一列显示的是组件管理别名拥有用户 ID/密码值为 userid1/pwd1 的情况。如果在数据源中调用 getConnection（）方法，那么在数据源中设置的用户ID/密码值 userid1/pwd1 会被用于获取连接。如果是在 DataSource 对象中调用 getConnection（userid2，pwd2）方法，那么会使用userid2/pwd2 值来获取连接。
• 第二列显示的是没有和数据源相关联的组件管理别名的情况。当在 DataSource 对象中调用 getConnection（）方法时，如果要求提供用户ID 和密码来获取连接的话，数据库会抛出一个异常，因为在数据源中没有设置用户 ID 和密码。如果在 DataSource 对象中调用的是getConnection（userid2，pwd2）方法，则使用用户 ID/密码值 userid2/pwd2 来获取连接。

表 2. 当 res-auth 值为 Application 时使用的验证数据

应用程序的部署器必须十分注意在应用程序部署描述符中指定的 res-auth 元素。如果应用程序的 res-auth 元素为 Container，那么部署器就需要为应用程序访问的数据源添加容器管理别名，否则应用程序不能够从数据源中获取连接。如果应用程序的 res-auth 元素为 Application，那么部署器需要为应用程序访问的数据源添加组件管理别名。如果应用程序对每个 getConnection都将用户 ID 和密码传递给数据源，则部署器可以选择不添加组件管理别名。相反，部署器让应用程序处理数据库验证。

另一点值得注意的是，容器管理验证方式比组件管理验证方式会明显健壮一些。在早先的 Application Server V5.0.2 和 APAR PQ76478中，组件管理验证是不安全的。随着 APAR的采用及后续版本的发行，组件管理验证变得安全了，它可以抵抗单元外部的攻击。然而，对于占用其他应用程序资源的内部应用程序而言，组件管理验证还是很脆弱的。因此，应用程序必须将res-auth 设置为Container，以便使用容器管理验证方式。

为 CMP EJB定义验证方式

在 Application Server V5 中，CMP EJB的资源验证是由容器处理的。此外，Application Server V5 还为 CMP 连接工厂提供了一种资源验证的 IBM 扩展方式。这种设置是由IBM 部署描述符扩展文件的 resAuth 元素标识的；例如， ibm-ejb-jar-ext.xmi 。您可以将 resAuth的值设置为以下的任一个：

• Per_Connection_Factory:在 Application Server 运行时将会使用数据源的组件管理别名。
• Container: 将会使用容器管理别名。

让我们来解释一下和 CMP 连接工厂验证设置有关的几个容易混淆的术语：

• 如果您在 Application Developer 中打开一个 CMP EJB，您将地看到显示为“Container authorizationtype”的设置，虽然它表示的是“Container authenticationtype”。
• 在Application Assembly Tool （AAT）中（包含在 Application Developer 中），CMP连接工厂验证类型的下拉列表包括“Per Resource”和“Container”。“Per Resource”是指 CMP EJB的“Per_Connection_Factory”或 res-auth 元素的“Application”。然而，如果您选择Per Resource，则存储在 IBM 部署描述符扩展文件中的值仍然还是“Per_Connection_Factory”。

表 3 显示 CMP EJB 的验证术语映射。

表 3. CMP EJB 连接工厂的验证术语

回页首

在 Application Developer 中设置数据库验证

本节我们就要介绍如何为 Application Developer 版本 5（包括版本 5.1）中的 Bean 管理持久性（BMP）EJB 和 CMPEJB 设置数据库验证类型。

我们的示例应用程序是一个企业应用程序，包含在 下载文件 BankCustomerEAR 中，它包含一个名为 BankCustomerEJB 的 EJB 模块。在 BankCustomerEJB中，有一个名为 Customer 的 BMP EJB 和一个名为 Account 的 CMP EJB。同时还有一个会话 EJB --AccountManagement ，它是作为 Web 应用程序或客户端的会话 façade 来访问实体 EJB 的。

我们首先为 Customer BMP EJB 创建一个数据源引用，并将它的 res-auth 类型设为 Container。然后我们为 Account CMP EJB创建一个 CMP 连接工厂并将它的验证类型设为 Container。我们假定在运行时环境中 Customer 和 Account EJB都使用同一个数据源 jdbc/CustomerDS 。

以下的步骤显示如何为 Customer BMP EJB设置验证值：

1. 在 Application Developer 中打开一个 J2EE Hierarchy 视图（图 1）。
   图 1. BankCustomerEJB 模块的 J2EE 层次视图
   
   
2. 在左面板中展开 EJB Modules，然后双击 BankCustomerEJB（图 1）。
3. 在右面板底部选择 References选项卡，这样就会显示 BankCustomerEJB 的 J2EE Hierarchy 视图。
4. 在列表中选择 Customer，然后单击 Add。这样就会显示 Add Reference 对话框（图 2）。
   图 2. 添加引用到 EJB 中
   
   
   图 3. 创建 EJB 资源引用
   
   
5. 在 Add Reference 对话框中，通过选择 Resource reference来添加资源引用，然后单击 Next以便进入下一个对话框（图 3）。
6. 在 Name 字段中键入 jdbc/myDS ，它就是在您的 BMP bean代码中查找的 JNDI 名称，如清单 2 所示。这个名称不是 Application Server 运行时环境中的数据源的 JNDI名称。在安装应用程序时，会将运行时环境中的数据源的 JNDI 名称映射到这一数据源引用中。在安装过程中，在运行时它会以 JNDI 名称 jdbc/CustomerDS 绑定到数据源上。
7. 由于 Customer BMP EJB 访问关系数据库后端，所以应在 Type 栏中选择 javax.sql.DataSource。
8. 在 Authentication 栏中选择 Container作为验证类型（另一个选项是 Application）。
9. 选中 Finish。

在 References 列表中扩展 Customer显示 ResourceRef jdbc/myDS。ApplicationDeveloper 的左面板会像图 4 所示的那样，其中 Authentication 字段的值显示为 Container。

如果您单击 Source选项卡（它对应于 EJB JAR 文件中的 META-INF/ejb-jar.xml 文件），您将会看到实体 EJBCustomer 下的 <resource-ref> 部分，如清单 4 所示。

清单 4. ejb-jar.xml 中的 <resource-ref> 部分

<entity id="Customer">
… …
 <resource-ref>
  <description></description>
  <res-ref-name>jdbc/myDS</res-ref-name>
  <res-type>javax.sql.DataSource</res-type>
  <res-auth>Container</res-auth>
  <res-sharing-scope>Shareable</res-sharing-scope>
 </resource-ref>
</entity>
                

我们已经成功地将数据源引用添加到 Customer BMP EJB中并将它的 res-auth 方式设置为 Container。现在我们要将连接工厂引用添加到 Account CMP EJB 中，同时也将它的验证类型设置为Container。以下的步骤将会完成这些工作：

1. 在右面板的底部选择 Beans选项卡。
2. 在 Beans dialog 对话框中，在列表中选择 Account以便显示如图 5 所示的信息。
3. 在 CMP Container Factory JNDI Name 字段中键入 jdbc/CustomerDS 。这就是Application Server V5 运行时中的数据源的 JNDI 名。
4. 在 Container authorizationtype （即为 Container authenticationtype）中选择 Container。
5. 单击 Save来保存修改。

如果您切换到 Project Navigator 视图并打开 BankCustomerEJB/ejbModule/META-INF/ibm-ejb-jar-bnd.xmi 文件，您将会看到 <cmpConnectionFactory> 部分，如清单 5 所示。

清单 5. META-INF/ibm-ejb-jar-bnd.xmi 中的 CMPConnectionFactory 部分

<ejbBindings xmi:id="EnterpriseBeanBinding_1067204217252" 
jndiName="ejb/com/ibm/websphere/sample/AccountLocalHome">
    <enterpriseBean xmi:type="ejb:ContainerManagedEntity" 
href="META-INF/ejb-jar.xml#Account"/>
    <cmpConnectionFactory 
xmi:id="CMPConnectionFactoryBinding_1076987532266" 
jndiName="jdbc/CustomerDS" resAuth="Container"/>
</ejbBindings>
                

现在我们已经成功地将连接工厂添加到 Account CMP EJB中并将它的验证类型设置为 Container。您可以导出该应用程序并将它安装在 Application Server V5 中了。

回页首

在 Application Server V5 管理控制台中创建别名和数据源

既然我们已经成功地创建了一个带有 BMP EJB Customer 和 CMP EJB Account的应用程序，接下来的步骤就是安装该应用程序并指定这些 EJB 要访问哪一个数据源。

在创建数据源以让这些 EJB 访问之前，我们首先应该在Application Server 中创建一个验证数据别名。正如前面所提到的，验证数据别名是由 J2C 验证数据实体表示的，它是用于管理用户 ID和密码对以供验证 Application Server 中的所有资源。这些实体是和别名相关的，它们可以用在资源定义中以指代特定的用户 ID 和密码对。

以下的步骤阐述如何从 Application Server 管理控制台为数据库创建 J2C 验证数据实体。

1. 在 Application Server 管理控制台的左面板选择 Security => JAAS Configuration => J2C Authentication Data => New。这样就会出现J2C Authentication Data Entries 对话框，如图 6 所示。
2. 每个用户 ID和密码对是由惟一的别名标识的。请输入以下的值：
   • Alias: CustomerDSAlias
   • User ID: user1
   • Password: pwd1
   
   图 6. J2C 验证数据实体
   
   
3. 选择 OK。
4. 单击 Save以保存配置。J2C 验证实体 Tiger1/CustomerDSAlias 存储在 <WebSphere_root>\config\cells\<your_node> 目录的 security.xml 文件中。密码字段在文件中进行了加密编码。

以下的步骤将会帮助您在 Application Server中创建一个数据源。我们这里使用的数据源是 DB2 XA 数据源：

1. 在 Application Server 中，展开左面板的 Resources。
2. 在左边选择 JDBC Providers，这样就能在右面板中显示 JDBCProviders 面板。
3. 您可以选择 New来创建一个新的 JDBC 提供者，或者如果您已经创建了也可以选择现有的JDBC 提供者。假定已经创建了一个名为“DB2 JDBC Provider（XA）”的 JDBC 提供者，选择 DB2 JDBC Provider （XA）。
4. 在页面的底部选择 Data Sources链接来显示 Data Sources 面板。
5. 选择 New来创建一个新的数据源。会出现 New Data Source对话框，如图 7 所示。
   图 7. 新数据源
   
   
6. 在 Name 字段中键入 CustomerDS 。
7. 在 JNDI Name 字段中键入 jdbc/CustomerDS 。在安装 BankCustomerEAR企业应用程序时，Customer BMP EJB 的部署描述符定义的资源需要和这个数据源的实际 JNDI 名绑定在一起。
8. 由于Account CMP EJB 也使用这一数据源，所以请选中 Use this Data Source in container managed persistence（CMP）。
9. 我们将在 Component-managed Authentication Alias 和Container-managed Authentication Alias字段中设置数据源的别名。您可以从下拉列表中选择一个别名。这里我们在两个字段中选择的都是刚刚创建的别名 Tiger1/CustomerDSAlias（Tiger1是节点名称；在您的 Application Server 环境中可能和这有所不同），因为在本示例中我们假定两种验证类型都使用同一个别名。
10. 如果打了最新的补丁，则还会有另一个字段 Mapping-Configuration Alias（图 7 中没有显示出来），它可以让您从 Security => JAAS Configuration => Application Logins Configuration列表中选择。DefaultPrincipalMapping JAAS 配置将验证别名映射为用户 ID 和密码，这和 J2EE Connector 1.0体系结构中定义的 BasicPassword 机制是相符的。
11. 剩下的字段您可以不做改动。
12. 选择 Apply来真正创建数据源。
13. 在页面的底部选择 Custom properties。
14. 选择 databaseName，然后键入数据库的真实名称。
15. 单击 OK并保存设置。

这样就创建了 BankCustomerEAR应用程序将要用到的数据源。我们现在就可以安装企业应用程序并将它的资源引用映射到真实数据源上。请按照以下的步骤来安装 BankCustomerEAR应用程序：

1. 在 Application Server 中，在管理控制台的左面板中扩展 Applications。
2. 选择 Install New application。
3. 在“Preparing for the application installation -- Specify the EAR/WAR/JARmodule to upload and install”页面的右面板中定位到 下载的 BankAcustomerEAR.jar文件，然后单击 Next。
4. 在“Preparing for the application installation --You can choose to generate default bindings and mappings”页面中接受所有的缺省值，然后单击 Next。
   图 8. Install New Application Step 1 页面
   
   
5. 这样就会显示 Step 1 对话框（图 8）。选中 Deploy EJBs，这样在安装过程中 Application Server就会部署您的 EJB。
6. Step 5 旁边的红色标记提示您必须将资源引用映射到系统的资源上。选择 Step 5按钮（图9）。
7. 在这里您可以将资源引用名称链接到运行时环境中的真实数据源上。真实数据源也是由 JNDI 名表示的。在下拉列表中选择 Tiger1:jdbc/CustomerDS（或者您为您的环境选择的恰当名称）。选中 BankCustomerEJB，然后单击 Apply。数据源 Tiger1:jdbc/CustomerDS的 JNDI 名就会在 JNDI name 字段中显示出来。现在 Customer EJB 就会以 JNDI 名 jdbc/CustomerDS 来访问数据源了。
   图 9. Install New Application Step 5 页面
   
   
8. 其他的步骤按缺省设置完成，然后单击 Finish以完成安装。单击 Save来保存设置。

由于我们已经将 CMP 连接工厂和数据源 JNDI 名 jdbc/CustomerDS 相关联了，在安装过程中就不需要再执行这一步。

我们已经成功安装了应用程序并且通过 JNDI 名 jdbc/CustomerDS 将 Customer BMP EJB 的资源引用映射到 Application Server 运行时环境中的数据源上。由于 Customer BMPEJB 的验证类型是 Container，所以可以使用和数据源相关联的容器管理别名。由于 Account CMP EJB 的验证类型是Container，所以同一个和数据源相关联的容器管理组件也可在其中使用。

如果您想运行该应用程序，那么您必须在数据库中创建两个表，并使用 launchClient来运行该应用程序。详细信息请查看 BankCustomerEAR.zip 下载文件中的 readme.txt 。

回页首

结束语

本文中我们描述了如何在 WebSphere ApplicationServer V5 中处理数据库验证。我们重点讨论了当应用程序 res-auth 类型设置为 Application 或 Container 时Application Server 的行为有何不同，并且提供了一个示例来说明如何在 Application Developer 中设置 res-auth类型，还解释了如何使用 Application Server 管理控制台来创建数据源以及设置它的别名。Application Server的管理员或部署人员必须始终将组件管理别名和容器管理别名和数据源相关联。对于给定的应用程序组件，需要由应用程序开发人员或应用程序装配人员指定部署描述符中的res-auth 元素，以便确定在运行时使用哪一个别名。

回页首

下载

	关于下载方法的信息

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
  
  
• J2EE 1.3 规范
  
  
  
  
• EJB 2.0 规范（最终发行版本）
  
  
  
  
• WebSphere Application 信息中心
  
  
  
  
• IBM WebSphere Application Server V5.0 系统管理和配置，WebSphere 系列手册
  
  
  
  
• J2EE 连接器体系结构（J2EE Connector Architecture）规范 1.0（最终发行版本）
  
  
  

作者简介

		Jian Tang 在 WebSphere Application Server Relational Resource Adapter 团队工作，该团队为 WebSphere 应用程序提供相关的数据库连通性。Jian 拥有内布拉斯加州——林肯大学的硕士学位。

		Teresa Kan 是 IBM WebSphere Application Server 软件开发区的团队负责人和架构师。她负责设计 Relational Resource Adapter，这一软件能为 WebSphere J2EE 应用程序提供持久机制来访问关系数据库。Teresa 拥有犹他州立大学计算机科学的理工硕士学位。

对本文的评价

太差！ (1) 需提高 (2) 一般；尚可 (3) 好文章 (4) 真棒！(5) 建议？

回页首