EJB-何时使用远程和/或本地接口？

Question

我是Java EE的新手，我试图理解本地接口和远程接口的概念。有人告诉我Java
EE的一大优点是易于扩展（我相信这意味着您可以在不同的服务器上部署不同的组件）。那是远程和本地接口进入的地方吗？如果您希望应用程序在不同的服务器上具有不同的组件，则应该使用远程接口吗？如果您的应用程序仅驻留在一台服务器上，并使用本地接口？

如果我的上述假设正确，那么您将如何选择对于新应用程序使用本地接口还是远程接口，而又不确定流量的大小呢？首先使用本地接口，然后在适用的情况下逐步升级到远程接口？

感谢您的澄清和建议。

Answer 1

我是Java EE的新手，我试图理解本地接口和远程接口的概念。

在EJB规范的初始版本中，“假定”
EJB是远程组件，并且调用它们的唯一方法是使用RMI语义及其所隐含的所有开销（对于每个网络调用和对象序列化）进行远程调用。方法调用）。即使将EJB客户端与EJB容器并置在同一虚拟机中，EJB客户端也必须为此付出性能损失。

后来，Sun意识到大多数业务应用程序实际上并不是在不同的层上分发EJB，他们通过引入本地接口的概念来固定规范（在EJB
2.0中），以便与EJB容器并置在同一虚拟机中的客户端可以使用EJB调用EJB。直接方法调用，完全绕过RMI语义（以及相关的开销）。

有人告诉我Java EE的一大优势是易于扩展（我相信这意味着您可以在不同的服务器上部署不同的组件）

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

如果您希望应用程序在不同的服务器上具有不同的组件，则应该使用远程接口吗？如果您的应用程序仅驻留在一台服务器上，并使用本地接口？

我会这样说：如果客户端不在同一个JVM中，则使用远程接口（这并不意味着仅使用一个服务器/ JVM）。

（…）首先使用本地接口，然后逐步升级到远程接口（如果适用）？

我可能将从使用本地接口开始。就像已经暗示的那样，切换到远程接口并不总是强制性的（您可以将 并置的 结构集群化）。

我建议检查下面提到的资源（前两个资源很旧，但仍然有用，另外两个资源是较新的）。

资源资源

• 在J2EE集群的幕后
• Wang Yu 扩展Java EE应用程序
• 扩展Java EE应用程序-第2部分，作者：王瑜