Geronimo renegade: OpenEJB 和 Apache Geronimo 的 EJB 实现
Enterprise JavaBeans (EJBs) 到底有什么了不起的，为什么对 Java™ 2 Platform, Enterprise Edition (J2EE) 开发来说如此重要？在这一期的 Geronimo 叛逆者 专栏中，OpenEJB 的共同创始人 David Blevins 将介绍 EJB 可以为您做什么，并解释 OpenEJB 如何被选择作为 Apache Geronimo 的 EJB 实现。
说实在的，在我看来，EJB 并不好用。它们需要开发人员在应用程序中投入比他们想像的还要多的精力；它们引以为基础的接口强制您实现许多您甚至根本不需要的功能；而且因为您需要在容器中运行它们，所以使用 JUnit 将它们与应用程序的其他部分一起测试是十分棘手的。
但是，它们也许恰恰正是 J2EE 开发的基石。
所以当 The Powers That Be 邀请我在这一期 Geronimo renegade 中选择 OpenEJB 作为 Apache Geronimo 的 EJB 实现时，我的兴趣被激发了。也许我能最终弄清楚它到底有什么了不起的。
  |
|
OpenEJB 如何成为 Apache Geronimo 的一部分
我曾打电话给 David Blevins，他与 Richard Monson-Haefel 在六年前共同创建了 OpenEJB，他还创建了 Geronimo。我想知道 OpenEJB 为 Geronimo 提供了什么，以及 EJB 本身为开发人员提供了什么。
我首先问他 OpenEJB 是如何在 Geronimo 等比较大的项目中兴起的。David 解释说，他在 Geronimo 尚未正式发布、只是一个传闻的时候就已经支持 Geronimo 项目了。“所以我绝对是所谓的 Geronimo 阴谋的一部分” ，他开玩笑地说。
哈，又是阴谋。我问他为什么总是这样形容 Geronimo 呢。“哦，Geronimo 真的非常 FUD（恐惧，不确定，怀疑），对于如此标榜我们的那些人来说。” 他解释说，Geronimo 创始人的目标首先是将将合适的人聚集起来，然后才考虑合适的组件。“参与创建 Geronimo 的个人基本上都将自我和自己的代码抛在一边，而决定首先将自己投入项目中” ，David 告诉我。基本上，他们是从一张白板开始尝试创建项目的。
那么 OpenEJB 是如何成为这张白板的一部分呢？“哦，我猜原因就是您所知道的那些”，David 说。但他并不十分严肃。事实上，一开始是最初的 Geronimo 创始人之一的 Dain Sundstrom 邀请他加入该项目的。Dain 实际上在一年前就曾试图聘请 David 参与一个类似的开放源码项目：“有一段时间，他参加了 Twin Cities Java Users Group (TCJUG) 的每一次社交聚会，并不断就此事纠缠我。”
当他们确实走到一起时，真的是命中注定一样。虽然他们两个都来自 Minnesota，但组建 Geronimo 项目的时候，David 正在 San Francisco 任教。“我说，‘这样吧，我现在在 San Francisco，所以您必须等到我返回 Minnesota。’ 当然他说，‘太好了，我也在 San Francisco’ ，他刚从一个会议返回来。所以那天我们正好在 San Francisco 聚到一起讨论，他本来以为会继续得到我一直给他的 no。但当重心从另一个项目转到 Apache J2EE 实现时，答案立即变成 yes。”。
而且，作为 OpenEJB 的领导人（因为 Monson-Haefel 在几年前已经离开），David 决心围绕 Geronimo 的工作重振该社区。“我们只知道这是应该做的事情”，他说。
不仅如此，OpenEJB 和 Geronimo 这两个团体建立了大型项目中罕见的协作。OpenEJB 的 Alan Cabrera 编写了 Geronimo 的安全系统。Aaron Mulder，一本有关 Geronimo 的可自由下载的书籍的作者，也郑重其事地检查了这个由 IBM® 捐献的控制台。Geronimo 的 Dain Sundstrom 和 David Jencks 为 OpenEJB 做了不计其数的工作，以使其遵循 EJB 2.1（Open EJB 原来只遵循 EJB 1.1）。Gianny D'Amour，Geronimo 的早期附加物，全力促进 David 称为 “我所见过的最大的 Geronimo 或 OpenEJB 补丁，基本上完成了我们的 CMP（container-managed persistence，容器管理持久性）实现” 。Jacek Laskowski，一位 OpenEJB 的长期贡献者，第一个开始了 Geronimo-Tomcat 集成工作，该工作由 Geronimo 的 Jeff Genender 驱动完成，Jeff Genender 最终也成为 OpenEJB 的贡献者。
事实上，当谈到 OpenEJB 和 Geronimo 时，David 说，“它在很大程度上是一个社区”。这就是为什么当 Geronimo 邀请 OpenEJB 成为 Apache 的一部分时答案又一次是 yes 的原因之一。
OpenEJB 仍在获取所有必要的文件，以成为 Apache 孵化期的一部分，任何第三方，比如持有任何一部分代码版权的公司，需要以书面形式作出正式的授权和捐献。之后，OpenEJB 代码在孵化期的子版本中就有了自己的区段。邮件列表将位于孵化期领域之下，诸如此类的事项更方便了两个项目涉及的工作。
孵化期曾被描述为密封过渡仓 (airlock) 一类的东西。因为项目曾被邀请成为 Apache 的一部分但还没有正式被接受。为了保证从孵化期毕业，项目必须适应所谓的 Apache 做事方式。“有许多标准”，David 解释说，“但基本上您必须展示一个健康的社区，您必须有干净的 IP”。
项目目前正致力于这个过程中所谓的干净 IP 方面，并正在获取来自曾资助早期开发的公司（比如 Intalio）的退出。但一个健康的社区不成问题。项目已经存在六年了，有许多热忱的贡献者。（这个队伍阶层已经随着 Geronimo 的加入而显著膨胀。）这种多样性对 Apache 来说至关紧要。David 解释说，“多样性是代码和社区在人力资源撤退时存活下去的关键因素。” 换句话说，当社区的一部分人离开一段时间时（这在任何长期项目中都是必不可避免的），社区作为一个整体必须足够强壮和多样化才能生存。
同时，OpenEJB 必须至少使一个发行版成为孵化期过程的一部分。项目已经因为参与 Geronimo 受到了极大的影响，尤其是在容器方面，需要投入大部分工作升级到 EJB 2.1。
|
|
OpenEJB 实际上包括两个部分 —— 服务器和容器，团队强调将二者分离。EJB 规范将容器和服务器合同描述为不同的两部分，但从没有实际定义这些部分。OpenEJB 定义了容器-服务器合同，最终 OpenEJB 的服务器部分几乎原封不动地合并到 Geronimo 中，但容器部分在该项目中被完全重写。“我们没有全部使用 Jetty，而且没有全部使用 OpenEJB，OpenEJB 在 Geronimo 存在之前已经到处都是了”，David 说。“让我们（Geronimo 社区成员）引以为豪的一件事是我们只是随机地聚集起来一群人，并成就了弗兰肯斯泰因般的结果。”
OpenEJB 的服务器端处理等式的分布式部分。在任何分布式系统中都需要两样东西：定位要使用的组件或服务器的能力，以及定位之后调用组件或服务的方式。定位组件或服 务通常需要类似注册的操作。在 Web 服务中为 “统一描述、发现和集成” (Universal Description, Discovery and Integration, UDDI）。在 CORBA 中为 CosNaming。在 EJB 中为 “Java 命名和目录接口” (Naming and Directory Interface, JNDI)。理想情况下，您应该能够通过正常编程方式实现第二部分 —— 调用组件。换句话说，您应该能够像调用本地对象一样调用组件。
环境的服务器部分处理该调用过程，该部分确保调用到达实际远程对象，并确保响应返回给客户机。服务器还处理任务，比如 “通过调用通信事务处理安全状态” ，David 说。
我必须承认，对于 Plain Old Java Objects (POJO) 来说这是相当棘手的事情。我已经开始看到使用 EJB 的优点。但我仍然是一个 Web 服务小子，所以远程系统吓不倒我。EJB 还能为我这个程序员做什么呢？基本上，它似乎主要以由容器执行的函数为中心。
|
|
有三种类型的 EJB —— 会话 bean（无状态的和有状态的）、消息驱动 bean (MDB) 和实体 bean。“我从来都不喜欢术语无状态 或有状态”， David 承认，“因为它们都保留状态。只是它们对状态具有不同的保证。我曾经教过 EJB（课程），我总是告诉我的学生将它们看作专用实例和共享实例。专用实例是有状态的会话 bean，共享实例是无状态会话 bean。可以将共享组件看作从图书馆借来的书。如果在读完之后归还它，则可以再次签出，但不能获得物理相同的同一本书，即使其标题相同。有的人可能在里 面涂写了，您在访问这本书时必须将这些考虑在内。”
专用或无状态的 bean 没有这个问题，因为一旦您请求一个这样的 bean，它就是您的了。其他任何人都不能使用该组件实例，所以可以确保任何涂改都是您的。这里的挑战在于，您现在冒着累积服务器上几乎无数个这种私有状 态的风险，所以需要一种方法来将那些目前不使用的状态推到磁盘中。所有这些都由容器处理。
容器还管理 MDB，从而使您可以很容易地使用 Java Message Service (JMS) 来回传递消息。您可以通过 JMS 以事务处理方式调用（消息驱动），这是一个非常方便的特性”， David 解释说。“您不必编写许多代码。您必须做的就是实现接口，而请求是从 JMS 到达您那里的。”在这种应用程序中，不必太多关注接收您消息的客户机的形式。
还有实体 bean 的问题，它具有自己的优点 —— 主要是持久性和高速缓存方面。例如，您可以从数据库提取信息，并使用实体 bean 在事务处理期间高速缓存数据。“老实说，如果让您亲自编程，您会发现这种优化是非常困难的”， David 说。
|
|
该功能全部都由容器负责。容器 “管理无状态 bean 池以及无状态 bean 和实体 bean 的高速缓存区”，David 告诉我，“当调用来临时，它会进行必要的工作，将组件准备好以便调用。它在调用前准备好所有事务状态或确保所有安全要求，然后一旦发生调用，它将处理任何 类型的故障，比如回滚事务处理等，然后将请求发送给要与客户机通信的服务器。”
好了，容器要做的事情实在太多了。就容器而言，使用 bean 可能要比试图亲自管理一切要值得。但这并不是容器所做的全部事情。容器还可以管理每个组件的生命周期。
您可能说，“那这意味着什么呢？” 这意味着容器明确知道要发生在组件上的事情并能够让您知道。例如，您可能想知道它何时将调用一个组件，是当它在组件中启动一个事务之前、在结束一个事务之 前，还是在销毁一个组件之前，等等。您为什么想知道？因为您可以在那时实际执行操作。例如，您可以实现回调，即在事务处理完成时或回调时发送消息。这使您 可以完全控制组件的生命周期。
但这种能力不会没有代价。这个代价就是您必须实际实现所有这些回调，不管您是否使用它们。这对不需要 EJB 提供的全部功能的程序员来说是一个问题，因为实现每个回调的问题不在于 EJB 实现的选择，而在于通过无格式旧 Java 接口实现 EJB 这一事实的后果。“如果您有较低端的需求，那么使用这个 API 开发是相当麻烦的” ，David 说。
幸运的是，大多数复杂性将随着 EJB 3.0 的到来而消失，这是 EJB 构造方式的主要变化。不需要实现这些接口和回调，只需要注释无格式的旧 Java 类即可。“在 EJB 3.0 中，只能说 ‘乒，那是一个组件，我已经将之标示为无状态” ，David 解释说。要实现回调，只需创建方法并适当地将其注释即可。“为了减少你这边的工作，它需要实现很多，因此出现了这些反模式（人们为使用会话定位器的 EJB 找到的），还有类似的所有这类疯狂的东西，他们能够基本屏蔽了 EJB API，但是还可以用-- 所有这些东西现在还不是必需的。”
当然，这些留待将来解决，等到 OpenEJB 3 分支开始成为 Geronimo 一部分的时候（我猜想）。但即使现在也存在 OpenEJB 与应用服务器如此配合的必然原因。
您可能知道，Geronimo 基于 GBeans 的概念，它允许您作为管理员来确定到底想要激活哪个组件。所以您可以具有超流水线的版本或超工业强度的版本，但您应该选择您希望支持的版本。 OpenEJB 十分符合这个概念，因为服务器和容器之间的彻底分离使得用户可以非常灵活地确定要支持的工具。例如，尽管一些 EJB 系统要求您具有服务器要提供的 CORBA、Web 服务和任何其他工具，OpenEJB 允许您通过将每个工具包装为 GBean 来挑选。这样，您就可以具有两个不同的 CORBA orb、任意数目的 Web 服务实现和其他任何您认为必要的工具。或者，您还可以一个也不支持且仅允许本地调用。此外，通过服务器的构造方式，您可以支持多个工具而不必具有应用服务 器甚至应用程序的多个副本。（作者注：David 指出，这种能力对于 Web 服务尤其有用，其目的在于完全的互操作性，但现实有时无法达到这种目标。）
|
|
向前看，OpenEJB 有一些令人兴奋的特性即将面市；一些是崭新的，一些不太新。例如，David 对容器驱动测试的嵌入式可测试性的拟定回报感到非常兴奋。这种能力使得用户可以容易地使用 JUnit 测试 OpenEJB 组件。通常，这些组件没有容器不能运行，并要求您在测试前和拆卸后执行特殊设置。但嵌入式可测试性允许您创建一个环境，将容器包含在其中作为系统的嵌入式 部分，同样地，您可以嵌入类似 IBM Cloudscape™ 的数据库。“这是 OpenEJB 1 中包含的东西，在 OpenEJB 2 中丢失了，我们将在 OpenEJB 3 中恢复”， David 解释说。“所以如果您编写 OpenEJB 组件，那么您可以毫不费力地用正常的 JUnit 测试运行它们。”
OpenEJB 3 还将着眼于支持 Java Persistence Architecture API (JPA)。David 介绍说，“OpenEJB 在过去偏向于使用其他组件实现其持久性。在 OpenEJB 1 中，我们使用了 Castor，在 2 中使用了 TranQL。在 3 中我们将使用 OpenJPA，该 API 目前是标准，所以 OpenEJB 3 将是可插拔的。所以如果 TranQL 或 Castor 或任何其他项目确实决定支持 JPA，我们将能够支持它们中的任何一个，或者同时全部支持。”
OpenEJB 还将支持构造器注入，从而使得容器可以在运行时提供各种类和对象。EJB 3.0 规范谈到了公共字段注入和 setter 注入，但构造器注入将使您可以避免为预期不会更改的值创建 setter。当然，它还能够帮助避免使用公共字段实现相同功能的必要性。“我们在 1995 年基本停止了这种行为，大约在 Java 发明三天后”，David 声明。
|
|
有了持久性、事务管理并认识到对该 API 的编程将不会始终如此痛苦，我可以看到深入调查 EJB 的价值所在，尤其是对于注定要在 Apache Geronimo 上运行的项目来说。它们在 Web 应用程序中是强大的力量，事实上，甚至在非 Web 应用程序中也是如此。请参阅本文 参考资料 一节中的链接，以帮助您继续自己的调查。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/374079/viewspace-130285/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/374079/viewspace-130285/
172
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
