EJB 本地接口（从 EJB 2.0 规范开始使用）为共存的 EJB 提供了性能优化方 法。本地接口必须被您的应用程序显式地进行访问，这需要代码的改变和防止以 后配置 EJB 时需要应用程序的改变。如果您确定 EJB 调用始终是本地的，那么 可以充分利用本地 EJB 的优化。然而，会话 Facade 本身的实现（典型例子如无 状态会话 Bean）应该设计为远程接口。通过这种方式，其他的客户端可以远程地 使用 EJB 本身，而不会破坏现有的业务逻辑。因为 EJB 可以同时具有本地和远 程接口，所以这是完全可以实现的。

为了性能的优化，可以将一个本地接口添加到会话 Facade。这样做利用了这 样一个事实，在大多数情况下（至少在 Web 应用程序中），您的 EJB 客户端和 EJB 会共同存在于同一个 Java 虚拟机（JVM）中。另外一种情况是，如果会话 Facade 在本地被调用，可以使用 Java EE 应用服务器配置优化（configuration optimizations），例如 WebSphere 中的“No Local Copies”。然而，您必须注 意到这些可供选择的方案会将交互方法从按值传递（pass-by-value）改变为按引 用传递（pass-by-reference）。这可能会在您的代码中产生很微妙的错误。最好 使用本地 EJB，因为对于每个 Bean 而言，其行为是可以控制的，而不会影响到 整个应用服务器。

如果在您的会话 Facade 中使用远程接口（而不是本地接口），您也可以将同 样的会话 Facade 在 Java EE 1.4 中以兼容的方式作为 Web 服务来配置。（这 是因为 JSR 109，Java EE 1.4 中的 Web 服务部署部分，要求使用无状态会话 Bean 的远程接口作为 EJB Web 服务和 EJB 实现的接口。）这样做是值得的，因 为这样做可以为您的业务逻辑增加客户端类型的数量。

最重要的Java EE最佳实践(6)

8. 使用无状态会话 Bean，而不是有状态会话 Bean。

这样做可以使您的系统更经得起故障转移。使用 HttpSession 存储和用户相 关的状态。

以我们的观点来看，有状态会话 Bean 的概念已经过时了。如果您仔细对其考 虑一下，一个有状态会话 Bean 实际上与一个 CORBA 对象在体系结构上是完全相 同的，无非就是一个对象实例绑定到一个服务器，并且依赖于服务器来管理其生 命周期。如果服务器关闭了，这种对象也就不存在，那么这个 Bean 的客户端的 信息也就不存在。

Java EE 应用服务器为有状态会话 Bean 提供的故障转移能够解决一些问题， 但是有状态的解决方案没有无状态的解决方案易于扩展。例如，在 WebSphere Application Server 中，对无状态会话 Bean 的请求，是通过对部署无状态会话 的成员集群进行平衡加载来实现。相反地，Java EE 应用服务器不能对有状态 Bean 的请求进行平衡加载。这意味着您的集群中的服务器的加载过程会是不均衡 的。此外，使用有状态会话 Bean 将会再添加一些状态到您的应用服务器上，这 也是不好的做法。有状态会话 Bean 增加了系统的复杂性，并且在出现故障的情 况下使问题变得复杂化。创建健壮的分布式系统的一个关键原则是尽量使用无状 态行为。

因此，我们建议对大多数应用程序使用无状态会话 Bean 方法。任何在处理时 需要使用的与用户相关的状态应该以参数的形式传送到 EJB 的方法中（并且通过 使用一种机制如 HttpSession 来存储它）或者从持久性的后端存储（例如通过使 用实体 Bean)作为 EJB 事务的一部分来进行检索。在合适的情况下，这个信息可 以缓存到内存中，但是要注意在分布式的环境中保存这种缓存所潜在的挑战性。 缓存非常适合于只读数据。

总之，您要确保从一开始就要考虑到可扩展性。检查设

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