EJB 的-什么时候使用远程和/或本地接口？

我对 JavaEE 很陌生，我试图理解本地接口和远程接口的概念。

在 EJB 规范的初始版本中，EJB 被“假定”为远程组件，调用它们的唯一方法是使用 RMI 语义和所有开销(每个方法调用的网络调用和对象序列化)进行远程调用。即使与 EJB 容器并置在同一个虚拟机中，EJB 客户机也必须支付这种性能损失。

后来，Sun 意识到大多数业务应用程序实际上并没有在不同的层上发布 EJB，他们通过引入本地接口的概念修正了规范(在 EJB 2.0中) ，这样客户端与 EJB 容器并置在同一个虚拟机中，就可以使用直接的方法调用来调用 EJB，完全绕过 RMI 语义(和相关的开销)。

有人告诉我，JavaEE 的一大优点是易于扩展(我相信这意味着您可以在不同的服务器上部署不同的组件)

JavaEE 可以扩展，但这并不一定意味着 分发组件。您可以在集群上运行 Web + EJB 应用程序，而无需分离 Web 层和 EJB 层。

如果希望应用程序在不同的服务器上具有不同的组件，是否应该使用 Remote 接口？如果您的应用程序只能驻留在一个服务器上，那么使用 Local 接口吗？

我的措辞是这样的: 如果客户端不在同一个 JVM 中，那么使用远程接口(这并不意味着只使用一个服务器/JVM)。

(...)从使用本地接口开始，然后在适用的地方逐步升级到 Remote 接口？

我可能会从使用 Local 接口开始。正如已经提到的，切换到远程接口并不总是强制性的(您可以集群一个 搭配结构)。

我建议检查下面提到的资源(前两个很老，但仍然相关，其他两个是最近的)。

资源

• J2EE 集群的帽子下王宇
• 扩展您的 JavaEE 应用程序 作者: Wang Yu
• 扩展您的 JavaEE 应用程序——第2部分 作者: 王宇

虽然我同意上面所写的大部分内容，但我想稍微改进一下“如何开始”的想法。

我给您的建议是，永远不要在代码中将 永远不会程序直接编写到 EJB 接口。始终使用常规的、面向业务的接口，对其进行编程(意思是，在面向业务的接口上使用代码调用方法) ，并提供 EJB“粘合”代码作为可插入的实现。您的程序应该专注于业务逻辑，而不是 EJB 之类的实现细节。

这样，您可以很容易地在远程实现和本地实现之间切换——如果您使用 IoC 容器，比如 Spring，那么您只需通过配置就可以完成切换。

关于从本地切换到远程的一个特别注意事项: 注意两者之间存在一些语义差异。例如，通过其“远程接口”调用 EJB 方法导致通过值传递参数，而通过“本地接口”调用导致通过引用传递参数。这是 少校的不同之处; 因此，如果您“从本地开始”，请确保您的系统设计也考虑到了“远程”语义。

如果您的设计依赖于更改传入对象的 EJB 方法，那么以后“切换到远程”将是棘手的，甚至可能是不可能的。

祝你好运。

这或许可以解答你的疑虑:

通常，您的 EnterpriseJavaBean 需要在 计划在分布式环境中使用 bean 的情况。 具体来说，这些是将要工作的客户端的情况 将与它在一个不同的 Java 虚拟机(JVM) 从远程主机调用任何方法 接口和/或远程组件接口将通过远程处理 方法调用(RMI)。

EJB 只有在确保本地客户端视图 其他企业 bean 或客户机只会在 如果是这种情况，这种访问将使用 直接方法调用，而不是 RMI。

资料来源: http://www.onjava.com/pub/a/onjava/2004/11/03/localremote.html?page=last&x-showcontent=text

根据 EJB Spec 3.2，EJB 可以是 本地也可以是 遥控器。 业务接口不能同时是本地的和远程的。

只有在同一个应用程序中，才能访问 @Local带注释的 bean。

可以跨不同的应用程序访问带有 @Remote注释的 bean，这些应用程序驻留在不同的 jvms 中或跨应用程序服务器。

所以要记住的重要事情是:

1. If a bean class contains the @Remote annotation, then all implemented interfaces are to be remote.
2. 如果 bean 类不包含注释，或者指定了 @Local注释，则假定所有实现的接口都是本地的。
3. 为不包含接口的 bean 显式定义的任何接口都必须声明为@Local。
4. EJB 3.2版倾向于为需要显式定义本地和远程接口的情况提供更高的粒度。