EJB文件处理模式
在我们结束本节之前，让我的快速的浏览一下容器提供商在EJB处理模式方面可能的变更。规范中对此并没有明确的表态，但我可以想到 至少两种模式。
1) 一种办法是首先利用EJB文件生成类似于EJB2.1部署模式的文件（包括必要的接口和部署描述符）然后再用类似于EJB2.1的方式来部署 这个EJB组件。当然，这样产生的部署描述符可能并不标准但是它可以解决同一个容器对EJB2.1和EJB3.0兼容的问题。
2) 另一种方法是一种类似于JSP托放的部署模式。你可以把一个EJB文件放到一个预先定义的目录下，然后容器会识别这个EJB并处理它， 然后部署并使之可以使用。这种方法可以建立于上面那种方法之上，在支持反复部署时有很大的帮助。考虑到部署的简单性也是EJB3.0 规范的目的之一，我真诚的希望在下一个草案出来时能够确定一个模式(至少能有一个非正式的)。 你有什么想法？
EJB3.0规范的制定正在有序的进行，为了使EJB的开发变得更加容易，EJB规范组织作出的努力是有目共睹的。就像他们说的那样，一切对 会变得简单，但做到这一点并不容易。目前已经定义了50个注释标记(还有几个将在下一个草案中发布)，每一个都有自己的缺省规则和其 他的操作。当然，我真的不希望EJB3.0变成EJB2.1的一个翻版"EJB 3.0 = EJB 2.1 for dummies"（希望这个等式不要成立）。最后，我 还是忍不住要提一些我自己的观点：
1) 首先，规范确实使反复部署变得容易了，并且有一个简单的模式来访问运行时环境。我还是觉得home接口应该放弃。 2) 在早期的EJB规范中，实体bean用于映射一个持久化存储。理论上(也许只是理论上)可能需要把实体bean映射到一个遗留的 EIS(enterprise information system)系统中。出于将来扩展的考虑这样作是有好处的，并且可以使更多的业务数据模型采用实体bean。 也因此其伴随的复杂性使得实体bean不被看好。在本次提交的草案中，一个实体bean只是一个数据库的映射。并且是基于非抽象持久化模 式和简单的数据访问模式的更加简单开发。
3) 我对模型变更持保留态度，我认为在EJB中包含SQL脚本片断并不是个好注意。一些开发人员完全反对包含某些“SQL片段（SQLness）” （比如@Table 和 @Column注释）。我的观点是这些SQLness是好的，据此我们可以清楚的知道我们到底要数据库作些什么。但是某些SQL 段我看来并不是很好，比如columnDefinition="BLOB NOT NULL"，这使得EJB代码和SQL之间的耦合太过紧密了。
4) 尽管对于本地SQL的支持看似很诱人，其实在EJB代码中嵌入SQL是一个非常糟糕的主意。当然，有些办法可以避免在EJB中硬编码SQL， 但是这应该在规范中说明，而不能是某些开发人员自己定义的模式。
5) 假设@Table注释只用于类。在运行时通过@Table注释的name属性定义的表名称将必须对应一个实际的数据库表。规范对此应该给予清 楚的说明和一致的模式。
6) 规范还需要更清楚的说明客户端编程模型，尤其是普通java客户端。规范中所有的参考都假设或者隐含的使用EJB客户端。而且规范 中对客户端的向后兼容方面也没有给出明确的说法。
7) Transient注释应该重新命名以避免和已有的transient关键字发生冲突。事实上，在这一点上我们更乐于稍微的背离一下 configuration-by-exception原则并且定义一个@Persistent注释来明确的定义持久化字段。@Persistent注释可以仅仅是一个标记注释 或者它可以有几个属性来关联O/R映射注释。
与其他规范的关联
目前可能影响到EJB3.0的JSR有JSR175（java语言元数据工具）和JSR181（Java Web服务元数据） JSR175已经初步完成并且不会和EJB3.0有太大的冲突；但是JSR181与EJB3.0有两个关联的地方：
1) Web service接口：EJB规范将采用一种机制适应JSR181以便可以把一个bean实现为一个Web service并告诉Web service如何被客户端 调用。
2) JSR 181计划采用不同的机制来处理安全问题。在早期的规范中EJB建议使用一个一致的机制（MethodPermissions），但是JSR 181 计划使用一个稍微不同的方式（SecurityRoles和SecurityIdentity注释）。同样的RunAs注释的定义也存在这些许差别。这一问题还在 解决中最终会在J2EE层的规范中维持其一致性。
在J2EE 1.5中的一些开发规范可能与EJB3.0有关联。除了上面说到的几个关联之外现在没有其他的开发规范与EJB3.0有冲突。
结束语
在使EJB的开发变得简单高效之前，我们还有很长一段路要走。规范组织在降低EJB的开发难度方面起了个好头。O/R映射模型的提议还处 在早期阶段，规范组织正在完善它。我希望它不要太复杂也不要与SQL过分的耦合。让我们不要只是停留在期望、希望、思考和请求中： 提出你的想法并把你的建议发送给规范组织ejb3-feedback@sun.com。JCP并不是很民主的组织，但是你的建议一定是有价值的。
本文的观点是作者的个人主张与作者所在的公司没有任何关系。作者非常感谢Hemant Khandelwal对发表此文的帮助。 提供下载的代码是EJB3.0草案的示例代码。由于没有工具和环境的支持这个例子是没有经过验证的。这些代码只是示例了未来的EJB3.0 大概的样子。
Anil Sharma是BEA System公司开发Weblogic Integration产品的资深程序员。在加入BEA之前曾就职于Oracle 和 Pramati，并一直致力 于研究J2EE技术。在业余时间它喜欢听音乐看电影；他还参加一些开源项目的开发工作。收藏地址:http://www.qqread.com/java/2007/11/r380859.html进入讨论组讨论。
相关图文阅读
频道图文推荐
健 康 咨 询
时 尚 咨 询
相关专题
- 精通Hibernate之映射继承关系（四） (0次浏览)
- 何不将Java与.NET合二为一？ (0次浏览)
- Hibernate的JNDI名称绑定分析 (0次浏览)
- 精通Hibernate之映射继承关系（一） (0次浏览)
- 精通Hibernate之映射继承关系（二） (0次浏览)
- 美国计算机教授语出惊人：Java对学生有害 (0次浏览)
- JDK 6 JRE 6 Update 4 (0次浏览)
- 三步教你改善Java代码质量 (0次浏览)
- Java语言入门 简述Java语言回收机制 (0次浏览)
- 2008年Java开发者最迫切的五个期望 (0次浏览)
