我们针对各种全异的数据源开发实体 EJB 的经验
热 荐
【字体：小 大】
我们针对各种全异的数据源开发实体 EJB 的经验
作者：－ 文章来源：－ 点击数：858 更新时间：2006-4-22 
C. M. Saracco, IBM 硅谷实验室
T. J. Rieger, IBM 硅谷实验室
2003 年 5 月 我们的作者们与读者分享了他们的经验，并比较在使用和不使用 DB2 Information Integrator 进行联邦数据库访问这两种情况下，实现跨越不同后端的数据源的实体 Enterprise JavaBeans 的相对代价。
简介
如果您和许多服务器端 Java™ 开发人员的情况差不多，就可能会发现自己为处理分散在各种数据源中的数据伤透脑筋。在先前的文章中，我们描述了 Java 2 企业版（Java 2 Enterprise Edition，J2EE）程序员是如何使用联邦数据库管理（DBMS）技术来减轻其负担的。其中至少有两篇文章： 构建跨越联邦数据的实体 EJB和 Accessing Federated Databases with Application Server Components向使用 IBM® WebSphere® Studio 的 Application Developer 配置的实体 Enterprise JavaBeans（EJB）开发人员提供了循序渐进的指示信息。
我们想接着这些文章继续进行讨论，研究一下联邦数据库技术会带来多少益处。我们实现了一些需要访问不同数据源中数据的实体 EJB。为了使文章富有趣味性，我们将关键数据存储在两个关系 DBMS（DB2® Universal Database™ 和 Oracle）和一个电子表格系统（Microsoft® Excel）中。显然，如果仅使用关系数据源，则我们的工作可能会比较简单。可是，谁又能说生活总是简单的呢？
我们使用 WebSphere Studio V5 的 Application Developer 配置作为开发和测试平台。 在一种方案中，我们依靠 IBM DB2 Information Integrator 来模拟数据源的单点映像。我们称之为 联邦实现。 在另一种方案中，我们构建了实体 EJB 以直接访问所需的每个数据源。我们称之为 本机数据访问实现。
（和许多人一样，在两种情况下，我们还构建了作为实体 EJB 前端的外观（facade）会话 EJB。但我们将稍后讨论这个问题。）下面讲述我们开发的故事：为了使每种方案成功，我们做了些什么，以及最终学到了什么。
我们希望这种经验能使您深入地了解当使用和不使用联邦 DBMS 来构建这些类型的 EJB 时，所面临的富有挑战性的开发工作。对于那些对此类琐碎细节不感兴趣的读者，我们在下一节中作出了结论。而对于确实喜欢钻研设计和编码问题的读者，则可以通读后续的几节以得出自己的结论 — 并看它们是否与我们的结论一致。
我们学到了什么
我们并不认为开发工作会很简单，但也不会因此气馁。我们已经很认真地处理了所有设计问题，但在实现时还是会遇到一两个意外。
但是，我们确实发现，当使用联邦 DBMS 时，整个任务确实比使用本机数据访问要简单得多。使用联邦 DBMS，设计更为清晰，实现阶段更为迅速，并且，我们最终只需要手工编写极少的代码来进行测试和维护（实际上，比原来的一半还少）。我们意识到这些优点，主要是因为联邦 DBMS 使我们能够构建具有容器管理的持久性（CMP）的单个实体 EJB 来执行所需的任务。
在 没有联邦服务器的情况下，我们需要构建三个单独的实体 EJB：一个用于 Oracle 数据、一个用于 DB2 UDB 数据、另一个用于 Excel 数据。此外，因为我们需要依靠来自于第三方的免费 JDBC/ODBC 桥来访问 Excel 数据，所以不能使用 CMP 实体 bean 来为这种数据建模。而必须通过构建具有 bean 管理的持久性（BMP）的实体 EJB，来编码自己的持久性机制。当然，这会带来更多的工作。
这些体系结构性问题具有连锁效应。与许多 EJB 开发人员一样，我们意识到除了拥有通过 bean 的主键值找到该 bean 的缺省搜索机制之外，我们的 bean 还需要支持更灵活的搜索机制。当然，这意味着我们必须实现定制 finder 方法，就象许多 EJB 开发人员所做的那样。对于 CMP 实体 EJB 的联邦实现，这并不太困难；我们只需用 EJB 查询语言（EJB Query Language，EJB QL）编写一个 finder 方法即可。因为存在与 EJB QL 相关联的限制, 我们不能按自己的意愿在查询中表达所有内容（稍后将进行更详细的讨论），但我们可以针对测试案例尽力克服这些限制。
对于实体 EJB 的本机数据访问实现，情况又有些麻烦了。我们只能将 EJB QL 用于 CMP EJB（Oracle 和 DB2 UDB 数据）。因为 BMP EJB 不支持 EJB QL，所以我们必须在定制的 finder 方法中手工编写 SQL 查询的代码，使用 JDBC 来执行这些查询，以检索必需的数据。因为我们已经熟悉了 SQL，所以这并不太难。但是，它确实意味着：不使用联邦 DBMS，要实现我们的解决方案，就要求我们精通两种查询语言 — EJB QL 和 SQL。
最后，我们的实体 EJB 实现还会影响外观会话 EJB 的工作。有了 联邦实现，会话 EJB 的工作就相对简单了： 查找符合条件的那一个实体 EJB， 调用其定制 finder 方法，然后 处理其结果。
使用 本机数据访问实现时，会话 EJB 必须： 逐个地查找三个符合条件的实体 EJB， 调用每个 EJB 的定制 finder 方法， 将每个方法返回的结果集成起来， 最终按照所期望的方式处理组合的结果。