在 J2EE 服务器环境中使用 Derby

在 J2EE 应用程序服务器中将 Derby 设置为 Resource Manager

级别： 中级

Stanley Bradbury (bradbury@us.ibm.com), 社区协调人 - Cloudscape, IBM

2005 年 11 月 24 日
2005 年 11 月 24 日 更新

IBM® Cloudscape™ 是免费提供的 Apache Derby 关系数据库管理器的改装产品。J2EE™ 服务器是基于 Sun 的 Java Enterprise Edition（J2EE）规范的中间件软件，它将很多 Java Service 技术捆绑在一个集成的系统中。大多数 J2EE 应用程序要求有一个与 J2EE 服务器集成的遵从 JDBC 规范的数据库，以便存储信息。本文展示如何最恰当地将 Cloudscape 或 Derby 应用到 J2EE 环境中。

简介

应用程序服务器（也称 app server）作为一种为不同位置、使用不同类型计算机的用户提供信息和服务的方法，正得到越来越多人的青睐。通常，应用程序服务器位于数据库或其他信息存储（即后端）与终端用户/客户（即客户机）的中间，从而形成一种“三层架构”。本文讨论如何在一个使用基于 Sun Java Enterprise Edition（J2EE）规范的应用程序服务器系统中，建立作为该系统后端的 IBM Cloudscape 或 Derby 数据库。在这里描述的配置中，数据库管理系统（DBMS）也可能被称作 Resource Manager。

如今，大多数应用程序服务器都基于 J2EE 规范，但也有一些属于其他类型。基于 J2EE 的系统的流行起因于它们的非专有性。它们很快为开放源码和开放架构社区所采纳。这些通用服务器继承了 Java “随处运行”的能力。由于 IBM Cloudscape 引擎（即 Apache Derby 引擎）也是以 Java 实现的，因而可以干净利落地进行集成，并且能不作修改地在任何有 J2EE 服务器的地方运行。

如果您有应用程序服务器方面的经验，那么可以跳过接下来的段落。否则，还是应该阅读一下这个段落，因为它简要地给出了应用程序服务器系统的概念，这有助于理解本文的后续部分。为了理解这个主题，您可以把 J2EE 应用程序服务器想象成“运行”一个或多个基于 Java 的应用程序的中间软件。它组合（捆绑）了支持应用程序和允许连接到网络的用户安全地使用应用程序所需的不同技术。应用程序服务器管理中间层组件，这些组件负责执行大部分重头任务。而客户层通常是使用 Web 浏览器与中间层“交谈”的人。而在中间层的后面，受中间层保护的是一个业务系统，即后端，最近也被称作 Enterprise Information System （EIS）层。在应用程序服务器中运行的应用程序可以使用很多种应用程序编程接口（API）来编写，最常见的有 Java（J2SE）例程、Java Server Page（JSP）和 Servlet。无论使用何种 API，应用程序都可以访问为应用程序服务器环境定义的数据库。图 1 展示了一个描绘这三层和一些组件的简化视图。本文主要关注中间层和 EIS 层。

Derby 的不同之处

大多数 J2EE 应用程序都需要存储数据，管理数据的最常见的方法是使用遵从 JDBC 规范的数据库。任何带 JDBC 驱动程序接口的数据库都可以与 J2EE 应用程序服务器集成，以创建 J2EE 术语中所谓的“Resource Manager”（RM）。Derby 引擎非常适合 Resource Manager 的角色。它被设计成在较大型系统中使用的关系数据库组件，这正是常用于描述 Derby 的术语“嵌入式数据库”所指的意思。当在一个 J2EE 服务器中实现（嵌入）时，它将成为该服务器中实现（部署）的应用程序可以利用的专用工具。

J2EE 服务器为网络通信和安全性提供支持，它们可以根据系统需求进行配置。Derby 引擎不提供这些功能，但是乐于利用服务器环境中的这些服务。很多数据库系统二进制文件中的很大一部分代码都是支持 J2EE 系统中已经存在的系统安全和网络通信功能。Derby 占用的内存很少，因为它的库没有包含这些代码。当 Derby 被嵌入到一个 J2EE 服务器中时，只需使整个服务器系统所占的内存增加 2 MB，就可以创建一个功能完备的遵从 JDBC 的 Resource Manager 。

Derby 与 J2EE

下面的列表列出了使用 Derby 的一些关键优点。要了解完整信息，请参阅本文 参考资料 小节中引用的“Tech Overview”。

• Derby 是一种功能完备的关系数据库，具有能与大型企业数据库相抗衡的能力。不要让它极小的规模（2 MB）和成本（0 美元）给骗了。
• Derby 是纯事务型的，当和 J2EE 服务器的 JTA 事务管理器一起使用时，可以参与全局（分布式）事务。
• Derby 数据库系统（二进制文件和数据库）可以复制到任何带有 J2SE JVM 的平台，并且无需重新编译或作其他修改就能运行。
• 缺省配置下的 Derby 数据库系统不需要进行单独的管理。它的引擎在 J2EE 服务器 JVM 进程中运行，成为系统集成的一部分。

在设计使用数据库的应用程序时，首先做出的决定之一是如何访问数据。J2SE 提供以下两种方法来访问带有 JDBC 兼容驱动程序的关系数据库：

1. 使用 JDBC 服务提供程序接口（SPI）。这意味着应用程序使用 JDBC DataSource 接口来建立到数据库的连接。对于 J2EE 应用程序，这是可取的访问方法，原因有以下几点：
   • 它允许程序代码完全独立于数据库。驱动程序信息、数据库的位置和配置参数都是由 J2EE 服务器存储的。
   • 它允许使用连接共享（即连接池）。J2EE 服务器连接管理器有效地管理连接，从而大大地提高性能和可伸缩性。
   • 它允许 Enterprise JavaBeans（EJB）使用数据库来实现 J2EE 服务器中的业务逻辑。虽然没有要求实现 EJB 层，但这样做可以为建立高度可伸缩的分布式应用程序架构提供基础。
2. 直接来自应用程序代码。这意味着应用程序使用 JDBC DriverManager 类来建立数据库连接。独立（不基于服务器）的数据库应用程序正是以这种方式来编写的。这种应用程序是自包含的，不依赖于来自应用程序服务器的信息或服务。这种应用程序也不会从应用程序服务器 JDBC Service Provider 提供的可移植性和可伸缩性中受益。

使用 J2EE 应用程序服务器的主要优点在于它简化了对用于数据库访问的 JDBC SPI 的使用。大多数业务程序员都不愿意，为了使用 JDBC SPI 而编写他们自己的数据源和连接池代码，并实现一个命名的服务器。实际上，更高效的方法是建立一个应用程序服务器环境。

将 Derby 用作 Resource Manager

本节展示如何使用 JDBC 服务提供程序接口（SPI）将 Derby 设置为 J2EE Resource Manager 。除了前面列出的诸多优点以外，使用 JDBC SPI 来支持 Derby 嵌入式驱动程序还可以避免由应用程序服务器引擎内实现的安全性和隔离措施导致的潜在问题（请参阅 应用程序服务器中的 Resource Manager 小节，以获得更多信息）。将一个数据库定义为受管资源的一般步骤是：

1. 准备数据库：
   • 安装 RDBMS。对于 Derby 来说，这意味着将 derby.jar 添加到应用程序服务器目录树中。
   • 在必要时启动 RDBMS。对于 Derby 来说，当应用程序服务器装载 JDBC 驱动程序时，引擎将自动启动。
   • 创建应用程序数据库。这通常是通过由数据库的命令行处理工具（例如 IJ）处理的一个 SQL 命令文件来完成的。
2. 定义和部署应用程序用来访问数据库的数据源。此时，大多数 J2EE 服务器将自动做以下工作：
   • 注册对象名称到一个名称服务器中。在应用程序中，这个名称用于替代任何特定于数据库的信息，以建立到数据库的连接。
   • 设置一个连接池。这个池对应用程序是完全透明的，可以提高性能和可伸缩性。
3. 启动数据源/连接器，或者配置应用程序服务器，使之自动启动。
4. 使用用于连接的 JDBC DataSource 接口编写应用程序（或者使用容器管理的持久性，但那是另一个话题）。

在“定义和部署数据源”这一步中，需要提供特定于 RDBMS 和数据库的信息，以便建立连接。完成这一步所需的基本信息有：

• JDBC 驱动程序库的位置和名称（例如：derby.jar）。
• JDBC 驱动程序类名（例如：org.apache.derby.jdbc.EmbeddedDriver）
• 数据库连接 URL （例如：jdbc:derby:Databases/JPetstoreDB）
• 参数代码（多数情况下是可选的）

捕捉数据源信息和部署数据源的过程会随着 J2EE 服务器的不同而不同。很多系统有一个控制台应用程序来帮助定义和部署数据源。下一节展示了如何使用 Gluecode Standard Edition Console 来设置数据源。在后面的 参考资料 小节中，通过相应的链接可以找到关于将 Derby 设置为 IBM WebSphere® 和 Apache Geronimo 中的 Resource Manager 的手册说明。

使用 Gluecode Standard Edition 设置 Derby Resource Manager

Gluecode Standard Edition 是一种集成了很多开放源码技术的应用程序服务器。它简化了 J2EE 环境中 Java 应用程序的部署和管理。Gluecode 捆绑了 Apache Geronimo J2EE 服务器，并提供了一个 GUI 管理控制台，用于连接 Resource Manager 和部署应用程序（要了解关于获得和使用 Gluecode 的信息，请访问 参考资料 小节中的 Gluecode 链接）。下面的步骤概括了为一个名为 JPetstoreDB 的 Derby 数据库创建数据源的过程。对于这个例子，必须将该数据库复制到 Gluecode 子目录 ...var/derby/Databases 中。该实现使用与 Gluecode 捆绑的 Apache Derby（可以在 ...repository/incubator-derby/jars 中找到）。

1. 启动 Gluecode 并访问管理控制台（URL：http://localhost:8080/console/login.html）。
2. 在开始的 Information 屏幕中，单击左侧导航列表中的 Databases 链接（图 2）。

2. 在 Database Connections 窗口中，单击列表框底部的 Add New Datasource 链接。
3. 为新数据源填入信息，如图 3 所示。单击 Create。

这就够了。现在，部署在服务器上的应用程序便可以通过引用 JNDI 名称来访问这个数据库，而不必管实际使用的是哪种 DBMS。

服务器中的 Resource Manager

当按照以上描述完成配置之后，Derby 数据库使应用程序服务器层与 EIS 层之间的差别模糊化。与大多数其他 RDBMS 不同，它是在应用程序服务器 JVM 中运行的 Java 程序（嵌入式的），而不是在它自己的地址空间内单独运行的进程。 部署多个使用 Derby 的应用程序

按照 Derby 的设计，数据库引擎（derby.jar）可以很容易地与应用程序包捆绑在一起，成为随应用程序安装的 jar 文件。这使得独立应用程序环境中的安装可以一步到位，而不会导致任何问题。然而，如前所述，在应用程序服务器环境中，由于数据库引擎是嵌入在其中的，当使用多个版本的 Derby 时，可能引发问题。使用嵌入式 Derby 的一项重要原则是 “决不将来自多个 derby.jar 副本的类装载到同一个 JVM 中”。

为了避免在需要部署多个提供 derby.jar 的应用程序时出现问题，可以使用 sysinfo 命令（org.apache.derby.tools.sysinfo）来判断哪个是更新版本的 Derby，并使用那个 jarfile。软升级（soft upgrade）特性可以使老版本 Derby 创建的数据库与新版本兼容。不要在服务器系统中同时存在多个 derby.jar。

类装载器和类装载器层次结构是一个复杂的话题，其中有更多的细节不是本文所能论述的（要了解关于此话题的更多信息，请访问后面 参考资料 小节中的“J2EE Class Loading Demystified”链接）。然而，需要注意的是，对类装载器的使用会随着应用程序服务器的不同而不同，因此，即使一个直接装载 Derby 驱动程序的应用程序在某个服务器上可以运行得很好，但当部署到另一个应用程序服务器上时，可能无法运行。而通过服务提供程序接口建立数据库连接，无论应用程序服务器如何管理类装载器层次结构，都可以保证应用程序在不同应用程序服务器环境之间是可移植的。

如果应用程序架构使您不能使用服务提供程序接口，或者需要将数据库处理负载分布到另一台机器上，那么可以结合 Network Server 来使用 Derby。Derby Network Server 在一个与 J2EE 服务器分离的进程中运行 Derby。Network Server 给系统引入了一些复杂性，因为它需要单独启动，单独实现验证和一组安全策略（这些事情通常由 J2EE 服务器来处理）。当使用 Derby Network Server 时，还要求使用这里没有提到的不同的 JAR 文件和数据库连接 URL 语法。嵌入在 Derby Network Server 中的 Derby 引擎在一个标准的客户机-服务器架构中运行，这和大多数其他数据库系统是一样的。

结束语

现在有很多 J2EE 应用程序服务器，它们各自捆绑了“自己”的一组 Java 技术产品和服务。要想了解有哪些可用的应用程序服务器，可以访问后面“参考资料”小节中的“Application Server Matrix”链接。每种服务器都为使用相互配合的不同技术提供了简化的接口。大多数应用程序服务器都支持本文描述的数据源和连接池的创建。

大多数 J2EE 应用程序服务器中具有的另一个重要特性是，至少通过 Servlet 和 Java Server Page（JSP）提供对服务器端处理的支持。J2EE 服务器中可能出现的其他服务和技术有 EJB、连接器、JMS、JTA 等。当出现新的技术和标准时，它们也将被并入到这些应用程序服务器中。由于这种技术的范围是如此之广，发展是如此之快，所以很多人第一次面临 J2EE 时变得不知所措也就毫不奇怪了。和所有复杂的系统一样，最好的选择是逐步熟悉 J2EE。本文提供的信息是对 J2EE 架构较基本的一种介绍。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
  
  
• IBM Cloudscape 专栏
  
  
• Cloudscape Version 10：技术概述
  
  
• Using Derby and WebSphere：在 WebSphere Server® 上与 iBATIS JPetStore 4 一起使用 Apache Derby。
  
  
• Using Derby and Geronimo：与在 Geronimo J2EE 服务器上运行的 iBATIS JPetStore 4 一起使用 Apache Derby。
  
  
• Cloudscape Version 10 或 Derby 与 Tomcat 的集成：这是一本关于将关系数据库管理器添加到 servlet 容器中的参考手册。
  
  
• 协同使用 IBM Cloudscape V10 与 IBM WebSphere Application Server V6
  
  
• J2EE 类装入揭密
  
  
• The Application Server Matrix
  
  
• The J2EE 1.4 tutorial
  
  

• 获得 IBM Cloudscape
  
  
• Gluecode：下载试用版。

• 参与论坛讨论。

关于作者

Stanley Bradbury 目前在 IBM 的 Cloudscape 小组担任社区协调人的工作。在此之前，他为 Cloudscape 提供三级支持（2001 年到 2005 年）。在与 Cloudscape 打交道之前，他先后管理过生物技术、制造业和互联网安全服务业的数据库。他毕业于加州大学 Berkeley 分校，喜欢和家人呆在一起。