级别： 初级 John Gates (jtgates@us.ibm.com), , WebSphere Enablement Team，IBM
2002 年 8 月 01 日 许多 WebSphere 应用程序都必须访问 DB2 数据库。当为 zOS 上的 WebSphere 开发时，一般的开发情况包括在 WebSphere Studio Application Developer 内开发一个应用程序并对其进行单元测试，然后重部署到 z/OS 和 OS/390 版 WebSphere Application Server 上。如果正在开发的要被部署的应用程序必须访问 zOS 版 DB2 数据库中的数据，则开发工具也就非访问 zSeries 机器上的数据库数据不可。最佳做法是用 java:comp 表示法和 DB2 Connect Gateway 一道来访问 DB2 数据源，而不是将数据库名称硬编码，如果将数据库名称硬编码，那么在将来应用程序投产时就不得不进行更改。遵循这个最佳做法，将减轻部署到多个平台的工作。
读者：
开发者
产品：
WebSphere Application Server
版本：
4.0.x
平台：
zSeries，
OS/390，
Windows NT，
Windows 2000，
AIX，
linux，
Hp-UX，
Solaris
产品：
WebSphere Studio Application Developer
版本：
4.0.x
平台：
linux，
Windows NT，
Windows 2000，
Windows 98，
Windows Xp
关键字：
WebSphere，
Application Server，
datasource，
database，
DB2，
UDB，
java:comp，
WebSphere Studio，
DB2 Connect，
WSAD，
数据源，
数据库
主题：
基于组件的开发，配置和管理，体系结构，安装和规划，调试-测试-问题诊断，部署一个应用程序，EJB
摘要
许多 WebSphere 应用程序都必须访问 DB2 数据库。当为 zOS 上的 WebSphere 开发时，一般的开发情况包括在 WebSphere Studio Application Developer 内开发一个应用程序并对其进行单元测试，然后重部署到 z/OS 和 OS/390 版 WebSphere Application Server 上。如果正在开发的要被部署的应用程序必须访问 zOS 版 DB2 数据库中的数据，则开发工具也就非访问 zSeries 机器上的数据库数据不可。最佳做法是用 java:comp表示法和 DB2 Connect Gateway 一道来访问 DB2 数据源，而不是将数据库名称硬编码，如果将数据库名称硬编码，那么在将来应用程序投产时就不得不进行更改。遵循这个最佳做法，将减轻部署到多个平台的工作。
推荐方案
当开发 WebSphere 应用程序时，可移植性应该是头号关心的事。目标应该是从开发转到单元测试再到部署时不更改任何代码。在开发访问 Host DB2 数据库的应用程序时，要考虑两项技术。
-
用 java:comp 访问数据库资源
在一个平台上开发应用程序，然后把这些应用程序部署到另一个平台上，在此过程中持续存在的一个问题就是解决命名差异。不同的平台需要不同的驱动程序、参数以及访问系统资源的技术。当用 JDBC 访问 DB2 数据库时，这点尤为令人恼火。
为了描述到资源（例如，Host DB2 数据库）的数据库连接，我们使用
数据源的概念。在数据源内，我们定义了把逻辑名与连接到实际数据库所需要的物理要求进行关联所需的所有信息。这些参数可能包括像这样的内容：物理数据库名（Host DB2 的数据库位置名）、访问数据库要用到的用户标识和密码、JDBC 驱动程序名以及访问 DB2 主机位置所必需的 url。
为每个数据库定义一个不同的数据源名，或者定义应用程序将会被部署到的主机，这样，在我们更改平台时，我们就不需要更改应用程序代码了。然而，这对更改数据源名的问题并没有帮助。解决这一问题的传统做法是使用 .properties 文件。实际被部署的代码读取 .properties 文件来获得它要在被部署的平台上使用的数据源名。
为了不再仰仗开发者理解部署平台的错综复杂，J2EE 1.2 引入了命名子上下文（naming subcontext）的概念。通过使用 java:comp/env/jdbc/dbname 表示法，对于应用程序开发者来说，就有可能在他的应用程序代码中访问数据库资源，而不必要担心连接到数据库所需的物理要求。java:comp JNDI 名称是在应用程序中编码的逻辑名。在应用程序的装配者装配应用程序期间，数据源的物理名在应用程序的 J2EE 绑定中被指定。这个级别的间接性允许应用程序在不同的环境中被部署，而不用更改实际的应用程序代码。对于 zOS 上的 WebSphere，在 System Management End User Interface（SMEUI）中对这个逻辑名到物理名的映射进行解析。这样，我们可以将应用程序代码中所引用的数据库的逻辑名和应用程序部署过程中定义的物理数据库要求分离开来。开发者可以选择一个名字并且在部署描述符中提供期望类型的资源；然后部署者仅在操作环境（已经绑定到部署者所选择的任意名称）中增加一个到适当数据源的链接。净效应是对于一个给定的逻辑数据源可以有多个名称，可能是每个名字对应部署过程的每个阶段。通过使用 java 子上下文，应用程序可以被多次重部署，而根本不用更改应用程序代码。
-
从 WebSphere Studio Application Developer 中用 DB2 Connect 访问 Host DB2 数据。
在构建与平台无关的应用程序时要考虑的第二件事就是总是访问应用程序所驻留平台上的数据库数据。我们有非常简单的方法来访问 Host DB2 数据。DB2 UDB 包括一个叫 DB2 Connect Gateway 的功能。这个软件创建了一个传输机制，这样对远程 Host DB2 数据库的调用看上去就像网关所在平台的本地数据库调用一样。一旦网关接收了 SQL 调用，网关就用 DRDA 协议和 Host DB2 的 DDF 服务器通信。
使用 DB2 UDB 中的 Client Configuration Assistant，第一步是创建到远程 Host DB2 数据库的连接。一旦建立了连接并且定义了连接的逻辑名，就可以在 WebSphere Studio Application Developer 中将这个名称用在数据源定义上。尽管连接到远程数据库所需的底层物理需求不同，但所有这些细节均不为应用程序开发者所知。通过 DB2 Connect Gateway 和 java:comp 表示法的魔力，J2EE 开发者们可以访问他们想访问的任何远程数据库，其方式与他们访问位于工作站本地的数据库的方式相同。
重要信息：这些最佳做法还适用于从运行在多平台（NT、Windows 2000、AIX、Sun、Hp）版 WebSphere 上的应用程序访问 DB2 数据库。
应被取代的方法
使用 java:comp
正如上面所扼要叙述的，使用 java:comp 表示法访问 DB2 资源的一种应被取代的方法是，用数据源名直接编码，并使用 .properties 文件指明应用程序应该使用哪个数据源。这把将数据源名和实际物理数据库源关联起来的担子落在了应用程序开发者身上。我们不赞成这个办法，赞成 java:comp 方法。
使用 DB2 Connect
另一个应被取代的方法是首先在开发平台本地运行的 DB2 UDB 中创建数据库。开发和单元测试一样，都要使用这个数据库来完成。如果在 OS/390 上部署，则在 DB2 UDB 上创建的数据库在迁移到 DB2 390 之前必须更改。这基本上是一个手工过程：从 DB2 UDB 数据库创建 DDL；在 OS/390 上创建数据库；为任何包含主键的表创建一个唯一的索引；运行 DDL 定义来创建和植入数据库；并且在安全产品中作必要的授权和许可来允许对数据库表的访问。
上面的过程将在 DB2 390 上重新创建 UDB 数据库。这很可能不是您要让应用程序运行起来所要采取的唯一步骤。对于如何能在 DB2 390 中定义数据库，有几大限制。这些限制中的几个是：表列名最多 18 个字符，java 对大对象的有限支持，以及几个不兼容的数据类型。所有这些都可以克服，但是需要调查研究和额外的工作。
参考资料
关于作者
对本文的评价
| 
