Answers:
我是Java EE的新手，我试图理解本地接口和远程接口的概念。
在EJB规范的初始版本中，“假定” EJB是远程组件，并且调用它们的唯一方法是使用RMI语义及其所隐含的所有开销（对于每个网络调用和对象序列化）进行远程调用。方法调用）。即使与EJB容器并置在同一虚拟机中，EJB客户端也必须为此付出性能损失。
后来，Sun意识到大多数业务应用程序实际上并不是在不同的层上分发EJB，而是通过引入本地接口的概念来固定规范（在EJB 2.0中），以便与EJB容器并置在同一虚拟机中的客户端可以使用EJB调用EJB。直接方法调用，完全绕过RMI语义（以及相关的开销）。
有人告诉我Java EE的一大优点是易于扩展（我相信这意味着您可以在不同的服务器上部署不同的组件）
Java EE可以扩展，但这不一定意味着分发组件。您可以在群集上运行Web + EJB应用程序，而无需分离Web层和EJB层。
如果您希望应用程序在不同的服务器上具有不同的组件，则应该使用远程接口吗？如果您的应用程序仅驻留在一台服务器上，并使用本地接口？
我会这样说：如果客户端不在同一个JVM中，则使用远程接口（这并不意味着仅使用一个服务器/ JVM）。
（...）首先使用本地接口，然后逐步升级到远程接口（如果适用）？
我可能将从使用本地接口开始。就像已经暗示的那样，切换到远程接口并不总是强制性的（您可以将并置的结构集群化）。
我建议检查下面提到的资源（前两个资源很旧，但仍然有用，另外两个资源是较新的）。
It seems like there are a couple ways of scaling a web application (...) and I suppose you could use a combination of both?是的，就是这样。Do you, by chance know of good books on this topic?可悲的是，不，我不知道“ ZE”绝对资源，如果有的话。我已经添加了更多参考资源。
尽管我同意上面的大部分内容，但我还是想稍微完善一下“如何开始”的想法。
我给你的建议是从来没有过直接编程到你的代码中的EJB接口。始终使用常规的，面向业务的接口对其进行编程（这意味着在面向业务的接口上具有代码调用方法），并提供EJB“胶水”代码作为可插入的实现。您的程序应专注于业务逻辑，而不是EJB之类的实现细节。
这样，您可以轻松地在远程和本地实现之间进行切换-如果使用的是IoC容器（例如Spring），则只能通过配置来实现。
关于从本地切换到远程的特别说明：请注意，两者之间在语义上存在一些差异。例如，通过“远程接口”调用EJB方法会导致参数按值传递，而通过“本地接口”调用会导致参数按引用传递。这是一个主要区别；因此，如果您“从本地开始”，请确保在设计系统时也考虑到“远程”语义。
如果您的设计依赖于EJB方法来更改传入的对象，那么以后“切换到远程”将很棘手。也许甚至不可能。
祝好运。
根据EJB 3.2规格的EJB既可以是本地或远程。业务接口不能同时是本地和远程的。
@Local 带注释的Bean仅在它们位于同一应用程序中时才能被访问。
@Remote 可以在不同的应用程序中（位于不同的jvm中）或跨应用程序服务器访问带注释的Bean。
因此要记住的重要事项是：
@Remote注释，则所有实现的接口都将是远程的。@Local指定了注释，则假定所有已实现的接口都是本地的。@Local用来在另一个具有相同JVM的应用程序（JAR，WAR，EAR）中调用EJB吗？
这可能会回答您的担忧：
通常，当您计划在分布式环境中使用Bean时，您的Enterprise Java Bean将需要一个远程客户端视图。具体而言，在这些情况下，将与之一起使用的客户端将位于不同的Java虚拟机（JVM）中。在远程客户端视图的情况下，将通过远程方法调用（RMI）处理从远程本地接口和/或远程组件接口调用的任何方法。
只有真正保证其他企业Bean或客户端只能在单个JVM中寻址该Bean，EJB才能使用本地客户端视图。在这种情况下，将使用直接方法调用而不是RMI进行这种访问。
来源：http : //www.onjava.com/pub/a/onjava/2004/11/03/localremote.html?page= last& x- showcontent= text