我对 Java EE 很陌生，我正在尝试理解本地接口和远程接口的概念。有人告诉我，Java EE 的一大优势是易于扩展（我相信这意味着您可以在不同的服务器上部署不同的组件）。这就是远程和本地接口的用武之地吗？如果您希望您的应用程序在不同的服务器上有不同的组件，您是否应该使用远程接口？如果您的应用程序仅驻留在一台服务器上，则使用本地接口？
如果我的上述假设是正确的，您将如何选择是否为新应用程序使用本地或远程接口，而您不确定流量会是多少？从使用本地接口开始，然后在适用的情况下逐步升级到远程接口？
感谢您的任何澄清和建议。
我对 Java EE 很陌生，我正在尝试理解本地接口和远程接口的概念。
在 EJB 规范的初始版本中，EJB 被“假定”为远程组件，调用它们的唯一方法是使用 RMI 语义及其暗示的所有开销（网络调用和对象序列化）进行远程调用。方法调用）。即使与 EJB 容器并置在同一虚拟机中，EJB 客户端也必须付出这种性能损失。
后来，Sun 意识到大多数业务应用程序实际上并没有将 EJB 分布在不同的层上，他们通过引入本地接口的概念来修复规范（在 EJB 2.0 中），以便与 EJB 容器并置在同一虚拟机中的客户端可以使用以下方式调用 EJB直接方法调用，完全绕过 RMI 语义（以及相关的开销）。
有人告诉我，Java EE 的一大优势是易于扩展（我相信这意味着您可以在不同的服务器上部署不同的组件）
Java EE 可以扩展，但这并不一定意味着 分发 组件。您可以在集群上运行 Web+EJB 应用程序，而无需分离 Web 层和 EJB 层。
如果您希望您的应用程序在不同的服务器上有不同的组件，您是否应该使用远程接口？如果您的应用程序仅驻留在一台服务器上，则使用本地接口？
我会这样表述：如果客户端不在同一个 JVM 中，则使用远程接口（这并不意味着只使用一个服务器/JVM）。
(…) 从使用本地接口开始，然后在适用的情况下逐步升级到远程接口？
我可能会从使用本地接口开始。正如已经暗示的那样，切换到远程接口并不总是强制性的（您可以集群一个 并置 的结构）。
我建议检查下面提到的资源（前 2 个很老但仍然相关，另外 2 个是较新的）。
