我是Java EE的新手，我正在尝试理解本地接口和远程接口的概念。我被告知Java EE的一大优势是它易于扩展（我相信这意味着您可以在不同的服务器上部署不同的组件）。是远程和本地接口进来的地方吗？如果您希望应用程序在不同的服务器上具有不同的组件，您是否应该使用远程接口？如果您的应用程序只驻留在一台服务器上，请使用本地接口？
如果我的上述假设是正确的，您将如何选择是否为新应用程序使用本地或远程接口，而您不确定流量的大小是多少？从使用本地接口开始，逐步升级到适用的远程接口？
感谢您的任何澄清和建议。
答案 0 :(得分：175)
我是Java EE的新手，我正在尝试理解本地接口和远程接口的概念。
在EJB规范的初始版本中，EJB被“假定”为远程组件，调用它们的唯一方法是使用RMI语义及其所暗示的所有开销（网络调用和对象）进行远程调用每个方法调用的序列化）。即使与EJB容器在同一虚拟机中并置时，EJB客户端也必须支付此性能损失。
后来，Sun意识到大多数业务应用程序实际上并没有在不同的层上分发EJB，他们通过引入Local接口的概念来修复规范（在EJB 2.0中），以便客户端与EJB容器在同一个虚拟机中并置使用直接方法调用调用EJB，完全绕过RMI语义（以及相关的开销）。
我被告知Java EE的一大优势是它易于扩展（我相信这意味着您可以在不同的服务器上部署不同的组件）
Java EE可以扩展，但这并不一定意味着分发组件。您可以在集群上运行Web + EJB应用程序，而无需分离Web层和EJB层。
如果您希望应用程序在不同的服务器上拥有不同的组件，您是否应该使用远程接口？如果您的应用程序只驻留在一台服务器上，请使用本地接口？
我会这样说：如果客户端不在同一个JVM中，则使用远程接口（这并不意味着只使用一个服务器/ JVM）。
（...）从使用本地接口开始，逐步升级到适用的远程接口？
我可能会先使用Local接口。正如已经暗示的那样，切换到远程接口并不总是强制性的（您可以集群并置的结构）。
我建议检查下面提到的资源（前2个是相当陈旧但仍然相关，其他2个是最近的）。
答案 1 :(得分：46)
虽然我同意上面写的大部分内容，但我想稍微改进一下“如何开始”的想法。
我的建议是永远永远直接编程到代码中的EJB接口。始终使用常规的，面向业务的接口，对其进行编程（意味着，在面向业务的接口上使用代码调用方法）并将EJB“粘合”代码作为可插入的实现提供。您的程序应该专注于业务逻辑，而不是EJB等实现细节。
这样，您可以轻松地在远程和本地实现之间切换 - 如果您使用Spring等IoC容器，您只能通过配置来实现。
关于从本地切换到远程的特别说明：请注意，两者之间存在一些语义差异。例如，通过其“远程接口”调用EJB方法会导致参数按值传递，而通过“本地接口”调用会导致参数通过引用传递。这是主要的差异;因此，如果您“从本地开始”，请确保您的系统设计也考虑到“远程”语义。
如果你的设计依赖于EJB方法来改变传入的对象，那么你以后“切换到远程”会很棘手;甚至可能是不可能的。
祝你好运。答案 2 :(得分：15)
根据EJB Spec 3.2，EJB可以是本地或远程。 业务接口不能同时是本地接口和远程接口。
@Local带注释的bean只有在同一个应用程序中才能被访问。
@Remote带注释的bean可以跨不同的应用程序访问，驻留在不同的jvms或跨应用程序服务器。
所以要记住的重要事项是：
@Remote注释，则所有实现的接口都是远程的。@Local注释，则假定所有实现的接口都是本地的。 答案 3 :(得分：7)
这可能会回答您的疑虑：
通常，您的Enterprise Java Bean需要远程客户端视图 计划在分布式环境中使用bean的情况。 具体来说，这些是客户端将要工作的情况 与它将在一个不同的Java虚拟机（JVM）。在这种情况下 远程客户端视图，从远程主页调用任何方法 接口和/或远程组件接口将通过远程处理 方法调用（RMI）。
只有在确实可以保证的情况下，EJB才能使用本地客户端视图 其他企业bean或客户端只会解决a中的bean 单个JVM。如果是这种情况，将进行此类访问 直接方法调用，而不是RMI。
来源：http://www.onjava.com/pub/a/onjava/2004/11/03/localremote.html?page=last&x-showcontent=text