Gluecode Software 的主要创始人 Jeremy Boynes，展望 Apache Geronimo 的远大前程
Gluecode Software 是日益增多的成功地商业化开源软件的公司之一，它已经将好些很有前途的开源中间件组件（包括 Apache Geronimo 和 Apache Derby 等）合并到 J2EE 应用服务器堆栈中。在最近 IBM 宣布收购 Gluecode 公司后，我们与 Jeremy Boynes（Geronimo 的主要创建者和 Gluecode 的 CTO）进行了座谈，聆听了他对 Geronimo、Java™ 未来发展方向和开源状况的展望。
当首席技术官 Jeremy Boynes 加入 Gluecode Software 时，他带来了关于将开源软件和企业级应用开发相结合的第一手资料。他过去是 Bravanta 和 Netmosphere 的首席架构师，通过使用开源软件，他帮助这两家公司降低了成本开支。他拥有 20 年的企业计算经验，曾在 Cisco、BT、Centrum Systems 和 Sequent Computer Systems 任职。他拥有电子工程师学位，并且作为创建者和负责人参与了众多的大型开源项目，包括 OpenEJB、ObjectWeb、Derby Java 数据库以及 Apache 基金会的 Geronimo J2EE 服务器项目。
IBM 已经宣布收购 Gluecode Software，这符合它扶持和参与开源社区，同时鼓励采用开放标准的目标。像 Eclipse、Derby 和 Apache HTTP 服务器（httpd）一样，IBM 引进 Gluecode Software 的基于 Geronimo 的平台，来为它现有的中间件阵容提供开源中间件。
|
不要认为 Geronimo 仅仅只是另外一个 J2EE 服务器，其实它是用来构建各种各样特定基础设施服务的系统框架的一个开端。
—— Jeremy Boynes |
我们的 developerWorks 成员问 Jeremy：作为 Geronimo 的架构师之一，请为我们介绍一下 Geronimo 的设计目标、架构以及它是如何脱颖而出的。或许您还可以给我们一些关于这种规模的开源项目是如何聚合在一起的方面的见解。
developerWorks：您可以描述一下 Geronimo 的架构么？它的主要组件是什么？
Jeremy Boynes：从 Geronimo 一开始，项目的主要目标就是，通过将支持 J2EE 规范不同部分的许多现有开源项目进行集成，以产生 J2EE 1.4 的实现。该架构专注于两个主要方面：提供一个框架，该框架有助于集成，但是对其他项目毫无影响；提供一组系统服务模块，这些模块组装在一起就成为最终的服务器。
该架构的核心是 Geronimo 内核和 GBean 框架。该核心提供一个基础设施，用于控制其他服务是如何配置、激活和管理的，并且控制它们之间的依赖性是如何分辨的。这个核心已经保持得很小，这使得 Geronimo 可以压缩到最小的设备中。
实际上该核心有两个变种。一个是轻量级的，设计用于命令行工具或非托管服务器。另一个设计用于传统的服务器，并且使用 JMX 以便所有组件都得到管理和监控。
在该核心中，我们安装了一系列模块，它们提供诸如事务、安全、日志记录、命名、远程控制之类的系统服务 —— 应用程序期望使用的基础设施是可用的。
通过使用这种灵活性，我们可以组装这些服务以形成特定的应用程序环境。例如，该项目的主要目标是产生一个 J2EE 1.4 环境，我们通过将合适的服务组装在一起实现了这个目标。尽管这种组装模型也可以用于其他配，但是我们主要为 Spring 社区工作以产生一个直接支持 Spring Framework 的组装模型。
这种灵活性功能极其强大，但它在配置控制和管理方面也有其自身的困难。为了解决这些困难，我们在内核中构建了一个强大的配置管理系统，这允许模块被组装、注册和封装，以便安装到任何 Geronimo 内核中。特定服务器具体运行哪些配置可由该服务器本身进行控制，如果在企业级环境中，则由外部管理服务进行控制。
我们实际上也将这种配置管理功能扩展到终端用户应用程序。这使得机构可以在集成或测试环境中创建一个已完整部署的应用程序，然后将其确切的二进制版本经过发布过程转移到生产环境，或者分发给客户。
额外的好处是，通过离线完成所有部署，我们可以实际减少生产服务器中的开销。它也允许我们在部署期间执行广泛的优化，即潜在地扫描字节码和优化代码路径，而不会影响在线系统。
developerWorks：我知道该项目的关键需求之一就是要完全遵循 J2EE 标准。为什么要这么做呢？
JB：这么做基本上是因为，它对我们的用户非常重要。J2EE 在为应用程序定义框架这方面做了很多贡献。这些应用程序由不同机构独立实现，但它们的行为在所有平台上都是一致的（经 Compatibility Test Suites 验证过）。这为企业用户提供了一种保证，如果他们选择 J2EE，那么不会只针对单独的供应商解决方案编写应用程序，或者说应用程序供应商可以一次编写应用程序，然后在任何客户环境中运行。
当然，现实世界中的 J2EE 规范还是不完整的，直至今日，仍有一些领域需要知道正在使用的是哪种实现。然而关键是，用户开始选择他们针对特定解决方案的局限程度。当然，使用开源这种限制会少很多。
证明还只是第一步。为了成功，Geronimo 需要在基本规范之上，为用户提供明显的优势。在该项目中，我们优先关注企业环境中对生产部署影响最大的技术领域。它们主要是与管理、配置、可靠性、可伸缩性和性能相关的特性。
developerWorks：J2EE 规范的哪些部分很难处理，哪些部分比较容易处理？
JB：项目过程中曾经流传着一个关于“88-itis”笑话 —— 为实现 JSR-88 部署规范的每个工作人员开始都用各自的方言交流，然后很快就变得混乱起来。
需要着重说明的是，该规范的某些部分处理起来非常容易，这是因为我们可以集成许多优秀的开源解决方案。例如，对于 Web 容器我们可以集成 Jetty 服务器或 Apache Tomcat，两者都具有优秀的“血统”。同样，我们的 JAXP（用于 XML 处理的 Java API）实现使用了 Apache Xerces，我们的 JMX（Java 管理扩展）实现使用了 MX4J（JMX 的开源实现），我们还基于 Apache Derby（以前称为 Cloudscape）提供了一个嵌入式数据库，等等。
面临严峻挑战的领域，同时也就是阻挠所有 J2EE 实现的领域：使用 Web 服务和 IIOP 与其他服务器的互操作。
developerWorks：已经存在许多能够胜任的商业 J2EE 服务器。为什么 Geronimo 开源还如此重要？
JB：也有其他的开源 J2EE 服务器，例如 ObjectWeb 的 JOnAS。像 Geronimo 这种项目只能通过开源才能成功，此外，为了获得商业实体和独立开发人员的支持，它也必须在类似 Apache License 的 BSD 许可证下进行开发，因为该许可证允许开发混合开源项目和专有技术的解决方案。
例如，Geronimo J2EE 服务器通过 Apache Software Foundation 发布，它基于诸如 Apache Tomcat、Jetty、OpenEJB 和 ActiveMQ 等其他开源项目的组合。
其他组合由该项目或其他机构提供。例如，系统供应商可能使用专有软件（直接依附于操作系统级别的日志）来替代事务管理程序，而企业用户可能使用集成他们自己的一致性和审计基础设施的安全策略来替代安全策略提供程序。
developerWorks： 您是否觉得 Geronimo 的组件化特性有助于开源的开发模型？
JB：我认为类似 Geronimo 采用的模块化方法，对于任何这种规模的软件项目都是很重要的，无论对于开源项目还是对于单独机构的内部项目。
然而我们的最大获益是，开发受到开放社区的驱动。在社区中，无论个人还是公司都能够参与到项目中并从中获益。基于 Apache Software Foundation 及其强调开放、精英和协作的社区，能确保项目的长期发展，同时也防止项目受控于个人行为或单个机构的商业动机。
developerWorks：作为完整的 J2EE 服务器，Geronimo 毫无疑问适合于大型的、分布式的、事务的企业级应用。但对于小型应用来说，哪些方面不适合于使用 Geronimo？
JB： 组件化的架构使 Geronimo 可以从小内存设备一直扩展到企业级应用。我们特别注意将内核保持为占用较小的内存，这样它就可以用于受限的设备，如机顶盒。然后，用户可以根据将要运行的应用程序的需要，选择哪些服务需要配置到框架中。
例如，用于分支机构的简单服务器可以配置一个 Web 容器、安全代理，还可以配置一个消息发传递客户机，然后在本地运行应用程序。远程管理和配置功能方便了从一个中心位置对大量设备的管理。
因为 Geronimo 实际上用于服务器应用程序，因此现在可能还并不适合考虑部署到手持或蜂窝设备。尽管如此，随着这些设备功能的不断增强，未来我们也许会探索这一领域。
developerWorks：您能谈一谈将可伸缩性构建到 Geronimo 中的一些方法么？
JB：很高兴您提到的是可伸缩性而不是单纯的性能（尽管我们在这个领域也非常出色）。在这个使用普通服务器硬件和零许可证成本软件的年代，可伸缩性常常使我们能够更有效地将应用程序扩展到更多的机器，而不是像以前升级为更庞大的服务器。
预配置应用程序和根据需要定制服务器配置的能力，使用户可以将服务器资源更多地投入到应用程序的工作当中，而不是应用服务器的管理开销。
可伸缩性的传统制约因素是对 CPU、内存和 I/O的访问。为了管理 CPU 资源，我们提供了一套线程池。通过调节线程池，可以均衡对入站 Web、EJB 和连接器请求或者由服务器本身生成的请求（比如事务回滚）可用的资源。未来，我们打算将不同服务的线程池组合为一个单独的工作管理基础设施，用于均衡负载。我们也引入了中央事务上下文这一核心概念，它使组件无需在共享线程池或缓存上同步，就可以访问每一个事务信息。
为了满足内存的可伸缩性，我们认真地控制执行任务时容器分配的内存总量。不幸的是，我们控制不了应用程序自身需要的资源。随着我们从实际应用程序中获得经验，这是一个仍需调整的领域。
我们在适当的地方使用了 NIO（Java 的最新 I/O）功能，以提高 I/O 的可伸缩性。我们特别关注的领域是事务日志，在该领域中，通过与 ObjectWeb 的协作建立了 HOWL 项目 —— 非常高效的日志子系统。
最后，这个问题还处于早期阶段。随着 Geronimo 在真实场景中的压力测试，实际的信息将会公诸于众。这方面的问题也一定会引起开发人员的关注。
developerWorks：项目的最大挑战和最大成功是什么？
最大的挑战就是项目本身所具有的复杂性，需要实现整个平台。这些都是在协作但独立的开源项目生态系统上进行的，这平添了几分兴奋。我想这也是最大的成功 —— 这么多的人能够团结在一起，共同完成它。
developerWorks：项目开始时，Geronimo 已经构建到什么程度了，还有多少需要编写？
JB：项目开始时，并没有实际构建 Geronimo 内核。但是许多可以集成的项目 —— 比如 OpenEJB、MX4J、Jetty —— 都已经有了，并且早已存在了。这些项目的绝大多数都需要进行改进以符合 J2EE 1.4 规范。而当我们 2003 年 8 月启动项目时，该规范还没有最终定案。
我们现在马上就要完成了，但是即使经过了完全验证，在性能调优、可用性、国际化、文档化、新特性等到方面仍需努力。
坦白地说，随着项目的发展，我们知道许多领域需要改进，我们也期望把更多的新思想融合到其中。还有很多工作要做，社区是向每个人开放的，欢迎大家积极参与。
developerWorks：除了日常开发的项目之外，还有其他喜欢的项目吗？
JB：Apache Derby。看到它走向开源，我非常兴奋。实际上，我以前使用过 Cloudscape。看到这样的项目加入 Apache 并可用，我非常兴奋，这使我能够更加随心所欲地开发自己的数据库。
developerWorks：您认为开源在企业中已经有一席之地了么？
JB：企业与以前相比，更加接受开源解决方案，尤其是最近的 12 到 18 个月。企业基础设施之一 —— 操作系统对 Linux 的广泛采用，向我们展示了企业越来越易于接受开源技术。我们看到，随着企业开始对用于数据库和应用基础设施的开源技术进行评估，开源技术得到了不断提升。这些成熟的市场具有清晰定义的规范（适用于商业化），我期望 3 年到 5 年后，开源解决方案在这些市场中会扮演一个重要的角色。
developerWorks：如果需要修改开源的某些部分，您认为会是哪里呢？
JB：有许多东西需要修改。最重要的是，每个开源社区需要修改的都有所不同。实际上根本没有开源运动，只有各种各样不同的社区和正在进行的不同形式的开发，开发涉及从 Linux 操作系统、Apache 项目（如 httpd 和 Geronimo），到诸如 Eclipse 和 ObjectWeb 之类的联盟，或者一些 SourceForge 项目中人们喜爱的桌面应用程序。有太多各种各样的问题，所以我很难说出具体哪些部分需要改进。
开源的一部分挑战仍是通信、协作、设法合作、理解商业公司扮演的角色，但仍要考虑个人所做的贡献，等等。所以最大的挑战是文化。每个单独的项目都通过不同的方法应对这些挑战。
developerWorks：Java 的下一件大事是什么？
JB：是 Geronimo [笑]。Java 语言正处于一个令人关注的阶段，越来越多的企业应用开始采用它。我们正在进入一个崭新的阶段，即通过在应用基础设施级别上使用托管运行时环境和虚拟化技术，可以大大方便人们的工作。所以，我想我们不久将会看到一个令人兴奋的增长期。
我们已经看到这种独立趋势的蔓延，像 Spring Framework 就非常符合用户所想。我认为这种百花齐放的情形非常好。而且，也有标准化的过程，因此企业可以完全放心这种技术的未来发展。我们处在一个令人瞩目的时代，太多的改革正在进行，太多的新思想不断涌现，太多的新事物正经受考验，例如 AOP（面向方面编程）和其他一些轻量级框架。我想这一切都非常令人鼓舞。
developerWorks：您还有其他想要与我们 developerWorks 读者一起分享的想法么？
JB：从技术观点来说，惟一最重要的是，我希望我们不要再将 Geronimo 只是作为另一个 J2EE 服务器，而是要把它作为构建各种各样基础设施服务的系统框架的一个开端。按照这种想法，制约该框架的只会是我们的想像力。快来参加我们，帮助我们一起构建未来。
同时，我要感谢所有相关人员，因为太多我在这里无法一一提到。感谢为 Geronimo 项目或其他相关项目做出贡献的人们！