Geronimo 叛逆者: 摒弃 JBoss，使用 Apache Geronimo

Geronimo 很 “年轻”，而 JBoss 则不然

您可能已经在这里阅读过有关 Geronimo 或者 JBoss 的文章。Geronimo 和 JBoss 这两个产品已经发布近两年了。Geronimo 产品最近刚发布了版本 1.0；而 JBoss 已经非常成熟了，发布过四个主要的版本。近来将 JBoss 应用程序迁移到 Geronimo 上看起来已经成为一种趋势。本文提供了在进行迁移工作时可能遇到的问题的技术信息，并对添加到 Geronimo 中的功能进行了概述，版本 1.0 的发布会使未来的迁移变得更加顺利。简而言之，本文概述了这一前景。

许可

Apache Geronimo 是在业务友好的 Apache 2.0 许可下发布的，自 2003 年秋开始进行开发。Geronimo 刚刚发布了版本 1.0，但是在这里我无法列出添加到 Geronimo 中的所有功能，即使是最近三个月添加的功能也无法列出，否则这些内容会占满我的文章。

JBoss 是在次通用公共许可证（Lesser General Public License，LGPL）下发布的。LGPL 也算是比较业务友好的许可证，但是有时候需要对 JBoss 源代码进行更改以支持特定的应用程序，而许可证要求将更改作为一个修补程序返回给 JBoss 代码库。JBoss Application Server 的最新版本是 4.0，该版本支持大量有用且具有前瞻性的插件。

J2EE 1.4 认证

要进行更贴切的比较，我们必须回过头对 JBoss 1.0 以前的版本和 Geronimo 1.0 以前的版本进行比较。由于当 JBoss 处在版本 2.0 开发的阶段时，我才开始注意到它，所以我将使用 JBoss 高一些的版本开始比较。这里我所能给出的主要比较是，实际上（不是凭感觉）Geronimo 1.0 以前的版本就已经通过 J2EE 1.4 认证了。在经过未完全达成一致的争议和争吵，并遭受来自各方对不合理收费的置疑后，JBoss 直到版本 4.0 才通过认证。这是大约一年多以前所发生的事情。

相反，Geronimo 小组却顺利地通过了认证过程并广受欢迎。我认为这与 Geronimo 小组坚持遵循标准有着很大的关系。我还认为这与项目的相对成熟也不无关系。

体系结构决定一切

JBoss Application Server 版本 4.0 是完全构建在 Java 管理扩展（Java Management Extensions，JMX）体系结构之上的。JMX 是 Sun Microsystems 开发的一种 API，允许使用标准命名和查找机制来轻松地找到 JMX 组件，并允许进行标准的调用，这样就能够在其他代码中使用 JMX 组件。我过去曾大量使用 JMX 和 JBoss 创建新的组件，例如使用调制解调器池 JMX 服务以支持来自远程设备的老式串行线调用，并发现 JMX 体系结构有一个令人头痛的问题。每次我想使用我的 JMX 服务，都因对带有 JMX API 调用的代码的抱怨而告终。虽然这样的代码易于封装，但是在可移植性上仍然存在障碍，因为它需要重新编写查找和调用代码，这实际上将应用程序捆绑到了 JBoss 平台上。

实际上，不管各个 API 的功能有多强大，在应用程序中使用特定于平台的功能都是很危险的，除非永远将应用程序绑定在某一平台上。最近 JBoss 应用服务器的 JBossAOP 功能就是这样的一个 API，使用该功能会将应用程序更紧密地绑定在 JBoss 上，并降低了迁移到其他 J2EE 平台的可移植性。

相反，Geronimo 应用服务器是构建在称作 GBeans 的轻量级组件体系结构之上的。在读过一些 Geronimo 内核代码后，我所能看出的 Geronimo 和 JBoss 主要的不同在于 GBean 体系结构是一个比 JMX 更加丰富的组件抽象。真正使 Geronimo 的体系结构与众不同的是，其在内部使用了大量的称为控制反转（Inversion of Control，IOC）的概念。文章 “Geronimo GBean Architecture”详细描述了 GBean 体系结构的工作方式。GBean 间的依赖性和对其他 GBean 的引用由 Geronimo 内核自动管理。内核为每一个 GBean 提供运行时环境，观察每个 GBean 的需求并加入适当的引用。这使得开发人员不用经常编写毫无意义的注册表查找代码，例如 JMX API 要求编写的那些代码。

Geronimo 的体系结构使得开发人员不用编写 JMX 这样的 API 引入的毫无意义的代码段。

那么，这意味着什么呢？这意味着 Geronimo 的体系结构使得开发人员不用编写 JMX 这样的 API 引入的毫无意义的代码段。Geronimo 的主要构建块是 GBean，它提供了一种直接了当的方法来提供有关每个 GBean 的需求的信息，例如如何在运行时构建 GBean，并提供其运行所需要的信息。这个体系结构的另一个新颖特性是：创建 GBean 的过程中不涉及到 XML，只有几行具体的源代码。而且，可以很容易地将 GBean 中包含的信息转化为 JMX 所需的信息，因此可以将其看作 JMX 的超集，因此从长期来看它会更加灵活。

为了更具灵活性，正在对 JBoss 应用服务器的 5.0 版本进行更改，力求成为一个更加模块化的体系结构。但是在通过阅读所提供的文档来了解这个新的体系结构时，发现很多地方声明“更改中，恕不另行通知”，这使我认为当前有关微内核体系结构的思想还没有完全充实。在文档中我发现了很多面向方面编程（aspect oriented programming，AOP）以及 Reflection Caching 方面的论述，这些论述暗示这可能是一个控制反转（IoC ）体系结构。我还在对一个支持该假说的组件的描述中发现了对 supply 和 demand 的论述。然而，对依赖项 的引用似乎与前提相违背，因为在一个真正的 IoC 系统中，依赖项是在运行时确定的。JBoss 的文档中提到 XML 描述符用来描述组件的所有运行时需求。我更喜欢在类的内部说明类的运行时行为，将有关类的所有信息集中保存在一个地方。但是，由于 JBoss 尚未完成其体系结构的实现，我们必须等待对这些问题的回答变得更清楚。

目前存在的缺点和不足之处的证据

下面几节对 Apache Geronimo 和 JBoss 的一些重要功能进行了比较。

自动为 CMP 创建模式

JBoss 几乎总是自动地为容器管理持久性（Container Managed Persistence，CMP）生成模式。它还有一个很棒的功能，称为自动模式迁移，该功能根据 JBoss 用新部署的应用程序所发现的差别自动修改数据库表。当进行少量更改时，例如添加或删除数据库列，该功能可以有效地减少数据库管理员对模式的修改操作。当然，比较复杂的更改仍然需要一些模式迁移工具。

目前，Geronimo 中自动为 CMP 创建模式这一功能尚未完成。要在 Geronimo 中使用 CMP，必须使用下列方法之一：

为应用程序生成自己的数据库模式并手动安装。

使用某种数据库，其模式语言受 TranQL 支持，然后使用构建系统内部的 TranQL 模式生成器在构建时生成模式输出。

用户仍然需要使用这个生成的模式手动准备数据库。但是，Dain Sundstrom 已经在忙于解决问题，包括为 CMP 自动创建模式的初始实现。随着自动模式生成功能的实现，我希望 CMP 应用程序的部署会生成初始模式，并且已部署的应用程序的用户无需运行 SQL 命令。

连接到多种数据库

Geronimo 使用 TranQL 库以支持 CMP 通过 Java 数据库连接（Java Database Connectivity，JDBC）连接到多种数据库。JBoss 最初使用一种称为 JBossCMP 的库，直到最近才开始与用于数据库访问的流行的 Hibernate 库集成，Hibernate 库允许 JBoss 支持很多种数据库。TranQL 有一种明确的支持结构，但是目前支持的数据库没有 Hibernate 库那么多。

自动生成主键和未知的主键

Geronimo 开发人员目前正在开发的其他功能包括自动为 CMP 生成主键和未知的主键。现在已经开始支持自动生成主键和未知的主键字段处理，而且越来越多的人开始使用它。Geronimo 已经支持自动递增字段主键和顺序表主键。我猜想很快就会开发出对此功能的良好支持。JBoss 已经具有这些功能。

群集和故障转移

JBoss 已经具备了至少两年的另一个功能是群集和故障转移。群集 是指应用服务器能在一台或多台机器（通常是多台机器）上运行其自身的多个实例，并且它允许应用程序透明地连接到任何实例。对用户来说，任何实例看上去都和其他实例是一样的，能够在实例间共享会话状态，有效地提高了应用程序的性能。故障转移 是群集的另一个功能，表示在任何时候，如果群集中的某个节点发生故障，用户会话的状态会在群集中的另一台机器上保留。

Geronimo 版本 1.0 具有群集解决方案的许多成分，但不幸的是，由于某些延误使得那些功能尚未完成，因此开发人员需要等到下一版 Geronimo 发行之后才能利用那些功能。但是，有人告诉了我在 Geronimo 版本 1.0 中让 Tomcat 模块以群集方式运行的过程。

使用 Java 5.0 编译

Geronimo 源码基目前不使用 Java 5.0 进行编译，我知道其主要原因是对通用对象请求代理体系（Common Object Request Broker Architecture，CORBA）实现的依赖，该实现使用 Java 1.4 类库中的类。如果不使用 CORBA，则可以运行在 Java 5.0 中编译的 Geronimo 服务器，还可以在该 Geronimo 服务器内运行使用 Java 5.0 功能编写的应用程序。

幸运的是，这只是一个临时解决方案。为替换 Geronimo 中的 CORBA 实现，小组开始与 Trifork CORBA 集成。Trifork 给出他们的对象请求代理（Object Request Broker，ORB）的源代码作为 Geronimo 项目的一部分，并拿出其开发资源以支持完整的集成。我认为这是推进 Geronimo 项目的很好的一步，因为替换 ORB 将在以后实现 Java 5.0 兼容性。

XDoclet 支持

开发时代码生成是许多 J2EE 开发人员开始利用的简化开发过程的功能。XDoclet 就是其中的一种代码生成器，在 J2EE 开发中得到了大量的使用。XDoclet 在 Java 源代码内部从特定的文档标记中获得信息，并根据您选择进行处理的模板将这些信息导入代码中。XDoclet 在 J2EE 环境中的主要用途是根据源代码自动生成部署描述符。JBoss 具有一套丰富的 XDoclet 标记，可用于您所能想到的与生成部署描述符相关的几乎所有任务，Geronimo 标记在这一方面有些落后。这意味着 Geronimo 使用的部署计划所指定的许多信息没有包含在 J2EE 标准中，这些信息仍然需要手动进行维护。为支持使用 XDoclet 版本 1.2.3 生成部署计划，IBM 的一个小组正在进行此方面的开发。我认为这对在 Geronimo 上进行流畅的应用程序部署非常重要。JBoss 在为其应用服务器开发 XDoclet 模块方面非常积极，Geronimo 必须做一些类似的事情以帮助开发人员避免在指定他们的部署计划时引入错误。

热部署

最后，JBoss 很早以前就具有热部署功能。这意味着可以通过将文件放置到部署目录中进行部署，JBoss 监控此目录，如果目录中的内容有所更改，那么 JBoss 将自动部署应用程序。此功能使应用程序能够在运行时轻松地用新版本替换旧版本，而无需让服务器离线。Geronimo 有多种部署应用程序的方法 —— 使用部署工具或者是使用 Geronimo 部署 Maven 插件直接从 Maven 构建脚本进行部署。

Apache Geronimo 版本 1.0 也具有热部署功能。幸运的是，Aaron Mulder 最近发布了一个热部署功能，支持监控特定目录文件的更新 —— 如果添加了文件，将会部署该文件。如果文件已经更改（文件的最新更新时间或者文件的大小已经更改），那么将会重新部署该文件。可以配置所要监控的目录以及检查文件更改的频率。

只是时间的问题

Geronimo 项目已经完全达到了版本 1.0 目标所需要的质量。每天都会实现急需的功能以填补在新的 J2EE 服务器中可能出现的漏洞（同 JBoss 相比）。我大胆地猜测在 2006 年第一个季度的某个时候，Geronimo 将拥有迁移为 JBoss 版本 4 编写的应用程序所需的全部功能。现在学习 Geronimo 并使用它编写应用程序，付出的努力是非常有价值的，这些努力使您不仅能够利用 Geronimo 版本 1.0 的全部优点，还能够利用基于 Geronimo 的 IBM WebSphere® Application Server Community Edition 的全部优点。

功能一览