简介
应用程序服务器（也称 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 层。
图 1. 三层架构
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 兼容驱动程序的关系数据库：
使用 JDBC 服务提供程序接口（SPI）。这意味着应用程序使用 JDBC DataSource 接 口来建立到数据库的连接。对于 J2EE 应用程序，这是可取的访问方法，原因有以下几点 ：
它允许程序代码完全独立于数据库。驱动程序信息、数据库的位置和配置参数都是由 J2EE 服务器存储的。
它允许使用连接共享（即连接池）。J2EE 服务器连接管理器有效地管理连接，从而大 大地提高性能和可伸缩性。
它允许 Enterprise JavaBeans（EJB）使用数据库来实现 J2EE 服务器中的业务逻辑 。虽然没有要求实现 EJB 层，但这样做可以为建立高度可伸缩的分布式应用程序架构提 供基础。
直接来自应用程序代码。这意味着应用程序使用 JDBC DriverManager 类来建立数据 库连接。独立（不基于服务器）的数据库应用程序正是以这种方式来编写的。这种应用程 序是自包含的，不依赖于来自应用程序服务器的信息或服务。这种应用程序也不会从应用 程序服务器 JDBC Service Provider 提供的可移植性和可伸缩性中受益。
使用 J2EE 应用程序服务器的主要优点在于它简化了对用于数据库访问的 JDBC SPI 的使用。大多数业务程序员都不愿意，为了使用 JDBC SPI 而编写他们自己的数据源和连 接池代码，并实现一个命名的服务器。实际上，更高效的方法是建立一个应用程序服务器 环境。
将 Derby 用作 Resource Manager
本节展示如何使用 JDBC 服务提供程序接口（SPI）将 Derby 设置为 J2EE Resource Manager 。除了前面列出的诸多优点以外，使用 JDBC SPI 来支持 Derby 嵌入式驱动程 序还可以避免由应用程序服务器引擎内实现的安全性和隔离措施导致的潜在问题（请参阅 应用程序服务器中的 Resource Manager 小节，以获得更多信息）。将一个数据库定义为 受管资源的一般步骤是：
准备数据库：
安装 RDBMS。对于 Derby 来说，这意味着将 derby.jar 添加到应用程序服务器目录 树中。
在必要时启动 RDBMS。对于 Derby 来说，当应用程序服务器装载 JDBC 驱动程序时， 引擎将自动启动。
创建应用程序数据库。这通常是通过由数据库的命令行处理工具（例如 IJ）处理的一 个 SQL 命令文件来完成的。
定义和部署应用程序用来访问数据库的数据源。此时，大多数 J2EE 服务器将自动做 以下工作：
注册对象名称到一个名称服务器中。在应用程序中，这个名称用于替代任何特定于数 据库的信息，以建立到数据库的连接。
设置一个连接池。这个池对应用程序是完全透明的，可以提高性能和可伸缩性。
启动数据源/连接器，或者配置应用程序服务器，使之自动启动。
使用用于连接的 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 中找到）。
启动 Gluecode 并访问管理控制台（URL：http://localhost:8080/console/login.html）。
在开始的 Information 屏幕中，单击左侧导航列表中的 Databases 链接（图 2 ）。
图 2. Gluecode 导航列表
在 Database Connections 窗口中，单击列表框底部的 Add New Datasource 链接。
为新数据源填入信息，如图 3 所示。单击 Create。
图 3. Gluecode 数据源定义屏幕
这就够了。现在，部署在服务器上的应用程序便可以通过引用 JNDI 名称来访问这个 数据库，而不必管实际使用的是哪种 DBMS。
服务器中的 Resource Manager
当按照以上描述完成配置之后，Derby 数据库使应用程序服务器层与 EIS 层之间的差 别模糊化。与大多数其他 RDBMS 不同，它是在应用程序服务器 JVM 中运行的 Java 程序 （嵌入式的），而不是在它自己的地址空间内单独运行的进程。由于这个原因，它容易受 到应用程序服务器内部实现细节的影响，尤其容易受多个类装载器的实现的影响。为了同 时运行多个应用程序，并使这些应用程序不致于相互干扰，应用程序服务器使用多个类装 载器来提供必要的隔离。如果 Derby 系统的类是由用于支持单个应用程序实例，而不支 持所有应用程序实例的类装载器装载的，那么它就会碰到问题。数据库引擎类甚至可能跨 多个类装载器。这将导致数据库引擎中止。由于数据库是共享资源，因此应该在比类装载 器更高的层次上装载它。
类装载器和类装载器层次结构是一个复杂的话题，其中有更多的细节不是本文所能论 述的（要了解关于此话题的更多信息，请访问后面 参考资料 小节中的“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 架构较基本的一种介绍。
或许是某个未开发的荒凉小岛，或许是某座闻名遐迩的文化古城。
