检验EJB 3.0 简化API规范 - 编程入门网

@Stateless　@Interceptors({StockRequestAudit}) public　class　StockBean　implements　Stock 　 public　double　getQuote(String　symbol) 　 { 　 return　100.33; 　 } }

除此之外，您可以选择开发那些在 Bean 类内部实现的******方法，同时也可以指定多个******，这种情况下它们被调用的次序由在 Bean 类中定义的次序决定。

检验EJB 3.0 简化API规范(4)

引入依赖性

使得 EJB 开发测试操作很困难的原因是 EJB 代码依赖于数据源等因素，这种情况如同 EJB 客户端如何调用 EJB 组件一样。EJB 3.0 规范将引入依赖性作为一种组织机制来介绍，以此来减少这些困难。EJB 能够通过引入代码来定义资源引用，而不是通过使用 JNDI 查看功能。下面是一个 EJB bean 需要调用另一个 EJB 组件并且使用数据源来完成 JDBC 工作的实例：

@Stateless　public　class　StockBean　implements　Stock { @EJB(name="MarketBean",　businessInterface="Market") Market　market; @Resource(name="StockDB,　resourceType="javax.sql.DataSource") DataSource　stockDS　 　 public　double　getQuote(String　symbol) 　 { 　 Connection　con　=　stockDS.getConnection(); 　 //DO　JDBC　work 　　 return　market.getCurrentPrice(symbol); 　 } }

依赖性的引入可以以多种方式出现，例如，通过设置属性值的方法或者类变量。

注解还是部署描述符？

当前 EJB 3.0 规范的早期草案标记出了空缺的章节，将使用部署描述符作为注解的一种备选方案。但是注解方法会更好吗？考虑一下"部署" 描述符的名称，该名称意味着它描述了与部署相关的应用程序的元素。我认为在目前的 EJB 部署描述符中的许多元素都是开发构件，而不是部署构件。那么在部署描述符中什么元素比较好呢？

被部署时很可能改变的元素，例如资源引用到实际资源的映射。

全面应用到 EJB 组件群的元素。注解在为特定类指明元素方面做了很多有益的工作，但是应用到多个 bean 的元素应该在外部得到描述。例如，我想将一个一般的安全角色应用到一套 EJB 组件中，而不是单独的 EJB 组件。为该指定操作留有空间要比在每个单独的 EJB Bean 类上定义注解更有效率。

确定的元素（留心事务划分）应该从部署描述符中移除，这是因为它们与部署无关。允许部署器忽略例如事务语义的行为将非常具有危险。JCP 应该在以后的修改中注意这些事实。

结束语

EJB 规范中简化 API 部分的第二个草案依然非常空洞；该规范的契约部分也已经从早期草案中消失。我期待该核心契约将在很多方面做出定义，例如注解中定义的资源引用如何向定义在应用程序服务器上的实际数据源获取"映射"，定时服务会发生什么行为，等等。不看该核心契约，很难做出评论，因此我们将其留作以后讨论。

今天的开发者应该如何去做呢？继续使用当前的 EJB 规范，用户的 J2EE 应用程序服务器的厂商在很长一段时间内会完全支持该规范。如果您跟随最佳实践，例如对自己的应用程序分层，就可以用最轻松的方式进行修改。

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!