Roland Barcia 的<提示>: 检验 EJB 3.0 简化 API 规范

核心提示： @StatelesspublicclassStockBeanimplementsStock{@EJB(name="MarketBean",businessInterface="Market")Marketmarket;@Resource(name=&quo

@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 应用程序服务器的厂商在很长一段时间内会完全支持该规范。如果您跟随最佳实践，例如对自己的应用程序分层，就可以用最轻松的方式进行修改。