我对Java EE非常陌生，我试图理解本地接口和远程接口的概念。有人告诉我，Java EE的一大优点是它易于扩展（我相信这意味着您可以在不同的服务器上部署不同的组件）。这就是远程和本地接口的用武之地吗？如果您希望应用程序在不同的服务器上具有不同的组件，是否应该使用远程接口？如果您的应用程序仅驻留在一台服务器上，请使用本地接口？
如果我上面的假设是正确的，那么您将如何选择是将本地接口还是远程接口用于新应用程序，而您不确定流量是多少？从使用本地接口开始，并在适用的情况下逐步升级到远程接口？
感谢您的澄清和建议。
我对Java EE非常陌生，我试图理解本地接口和远程接口的概念。
在 EJB 规范的初始版本中，EJB 被“假定”为远程组件，调用它们的唯一方法是使用 RMI 语义及其隐含的所有开销（网络调用和每个方法调用的对象序列化）进行远程调用。即使 EJB 客户端与 EJB 容器并置在同一虚拟机中，EJB 客户端也必须支付此性能损失。
后来，Sun 意识到大多数业务应用程序实际上并没有将 EJB 分布在不同的层上，并且它们通过引入本地接口的概念来修复规范（在 EJB 2.0 中），以便与 EJB 容器并置在同一虚拟机中的客户端可以使用直接方法调用来调用 EJB，完全绕过 RMI 语义（以及相关的开销）。
有人告诉我，Java EE的一大优点是它易于扩展（我相信这意味着您可以在不同的服务器上部署不同的组件）。
Java EE可以扩展，但这并不一定意味着分发组件。您可以在集群上运行 Web+EJB 应用程序，而无需分隔 Web 层和 EJB 层。
如果您希望应用程序在不同的服务器上具有不同的组件，是否应该使用远程接口？如果您的应用程序仅驻留在一台服务器上，请使用本地接口？
我会这样说：如果客户端不在同一个JVM中，请使用远程接口（这并不意味着只使用一个服务器/ JVM）。
(...)从使用本地接口开始，并在适用的情况下逐步升级到远程接口？
我可能会从使用本地接口开始。如前所述，切换到远程接口并不总是强制性的（您可以群集并置结构）。
我建议检查下面提到的资源（前2个很旧，但仍然相关，另外2个是最近的）。
虽然我同意上面写的大部分内容，但我想稍微完善一下“如何开始”的想法。
我对你的建议是永远不要在你的代码中直接编程到EJB接口。始终使用常规的、面向业务的接口，对其进行编程（即在面向业务的接口上调用代码调用方法），并提供 EJB“粘合”代码作为可插拔实现。您的程序应该专注于业务逻辑，而不是实现细节，例如 EJB。
这样，您可以轻松地在远程和本地实现之间切换 - 如果您使用诸如Spring之类的IoC容器，则只需通过配置即可完成。
关于从本地切换到远程的特别说明：请注意，两者之间有一些语义差异。例如，通过 EJB 方法的“远程接口”调用 EJB 方法会导致参数按值传递，而通过“本地接口”调用会导致参数按引用传递。这是一个主要区别;因此，如果您“从本地开始”，请确保在设计系统时也考虑到“远程”语义。
如果你的设计依赖于EJB方法改变传入的对象，那么你以后“切换到远程”会很棘手;甚至可能是不可能的。
祝你好运。
