Geronimo 叛逆者: 加入集群功能

在 Java™ 2 Platform, Enterprise Edition（J2EE™）服务器上，服务器中的许多不同组件都必须执行集群操作。Web 容器 —— 对于 Geronimo 来说，可能是 Jetty 或 Tomcat —— 必须与其他集群节点的 Web 容器协作，共享用户会话信息和负载测量。这种共享提供了良好的共享均衡方式，并降低了集群中的单一节点得到的请求超出它的处理能力的可能性。而且，企业 JavaBeans （EJB）容器需要保证无状态会话 bean 被复制到其他集群节点，这样如果把用户重定向到集群中的其他节点，他或她的应用程序看起来就像与以前正在通信的节点处于同一状态。另一个主要的必需组件是高可用的 Java 命名和目录接口（Java Naming and Directory Interface，JNDI）目录。这个目录是 Java 企业应用程序保存名称和引用的地方，可以帮助应用程序发现它们运行时需要的对象。重要的是，如果集群中的节点发生故障，那么这个目录不要丢失信息，所以通常会把它复制到集群中的每个节点。

根据 Jeff Genender 的观点，如果没有水平的可伸缩性，Geronimo 就不会被大规模采用或进入大企业。他指出，在依赖于 24/7 无故障运行时间和高事务负载的关键任务系统中，高可用性非常重要。这些性能对于让 Geronimo 达到下一个级别是必需的，而且目前是 Jeff 的最高优先级。

Codehaus，开放源码技术的温床

现在我们来看看 Geronimo 团队从哪来寻找合适的组件，向它的应用服务器添加集群功能。团队需要软件来执行集群操作、数据共享等。他们从哪得到软件呢？当然，他们可以从头开始编写这些组件，但是这有悖于开放源码软件的目的：开放共享、在现有的库之上构建。看起来，Codehaus 这个开放源码宿主操作（与 SourceForge 类似）有许多合适的项目。根据 Jeff Genender 的说法，进入 Codehaus 的项目的壁垒更高，这意味着要将项目放在那里的要求更严。而反过来，这就意味着项目的质量通常会更高，而项目也更成熟。这并不意味着在 Codehaus 上开发项目更难。相反，在这里，开发可以迅速而平稳地发展，没有其他软件孵化器中存在的许多官僚作风。Geronimo 项目已经寻找了许多满足他们当前策略的项目。