Jakarta ee 为什么EJB3.0会话bean需要单独的远程和本地接口

我想知道为什么EJB3.0会话bean需要单独的远程和本地接口。我想大多数时候，他们都会定义同一个合同。为什么我不能有一个公共接口，在我的Bean中，我应该能够说我希望这个Bean可以远程和/或本地访问

谢谢

---

Vikas

我不同意在设计时远程和本地应被视为微不足道的可交互变化

首先，远程调用有开销，所以在设计远程接口时，需要仔细考虑粒度和参数大小是否正确。因此，提醒这将相对昂贵对设计师很有帮助

此外，鉴于远程接口参数是通过值传递的，而本地接口参数是通过引用传递的，这两种情况之间存在根本的语义差异，因此您可以选择以不同的方式设计这两个接口。

位置透明性的概念是一种危险的反模式。您的设计绝对需要知道它是在进行本地调用还是远程调用，原因有很多（错误处理和性能是最明显的）

---

远程EJB接口不同于本地接口，因为异常签名需要不同，以适应只能在远程调用中发生的与网络相关的错误。将远程处理行李装载到本地接口（如EJB1中的情况）会使代码变得可怕。EJB2引入了单独的本地接口，以简化总是本地的EJB的编程。

这就是EJB规范所说的：

本地和远程编程模型之间的选择是Bean提供者在开发企业Bean时做出的设计决策。
虽然可以为企业bean提供远程客户端视图和本地客户端视图，但更典型的将只提供一个或另一个

---

因此，在编写bean时，考虑谁是客户机，本地客户机不太可能需要与远程客户机相同的方法或甚至相同的bean。

一个很好的理由是，您可以通过其接口访问EJB。这样，在使用远程接口时，您可以通过值传递参数，在使用本地接口时，您可以通过引用传递参数。你知道为什么会有这种行为吗？这很有意义：也许您确实希望远程应用程序访问您的业务对象，因为通过引用传递可以减少网络延迟。请记住：远程访问涉及将对象转换为字节流的过程—封送—以及将字节流转换为对象的过程—解组。这个额外的步骤—封送和解封送—会降低应用程序的性能。

我认为，当您的业务需要本地的所有方法时，也需要向远程客户端公开，然后

使用这些方法定义本地接口

使远程接口为空，但扩展本地接口

所有实际的业务逻辑和其他实现都在本地

让您的远程bean实现只委托给本地bean实现

这种方法可能是实现@Local和@Remote到同一接口的一种变通方法。如果需要，可以本地访问相同的方法，如果需要，可以远程访问相同的方法，而不需要任何性能开销

---

这是我的想法。有人请让我知道你的想法来验证这一点

客户端通过bean的接口访问会话或实体bean。EJB容器生成接口实现以强制和管理此行为，充当客户端和bean之间通信的管道。在EJB2.0规范之前的版本中，所有bean都定义并实现为分布式远程组件。因此，bean所需的两个接口被称为主接口（通常定义生命周期方法）和远程接口（通常定义功能性业务方法）

这些bean必须在同一个VM中运行——毕竟，它们是本地的。 参数通过引用发送，而不是复制，远程接口和对象就是这样。如果忽略此区别而不相应地编码，可能会产生意外的副作用。 通常，使用本地或远程访问的决定受以下因素影响：

客户机类型-除非您总是希望客户机是Web组件或其他bean，否则请选择远程访问

bean是否紧密或松耦合-如果bean相互依赖并频繁交互，请考虑本地访问。

可伸缩性—远程访问本质上是可伸缩的，如果可伸缩性是一个重要因素，则应使用远程访问。

---

随着EJB2.0规范中本地接口的出现，大多数来源建议实体bean几乎总是基于本地访问。对于本地接口，大多数关于细粒度数据访问的性能问题都会消失。如果客户机是远程的，则标准设计模式让客户机使用远程接口访问会话bean，然后会话bean充当与实体bean的联络。会话bean通过本地接口与实体bean通信（从模式的角度来看，这种技术称为会话Façade，实际上可以在远程或本地上下文中使用）。

我认为问题是，为什么我不能在声明注入时选择此选项？我同意在许多情况下，我可能必须为这两者设计不同的接口，但在我为这两者设计相同接口的情况下，我应该能够使用本地和远程对其进行注释。这样做的好处是，我的客户机不必担心它是本地调用还是远程调用（除非他指定了JNDINA）

 Internally, J2EE uses the Java Remote Method Invocation over Internet Inter-ORB Protocol (RMI-IIOP) to enable remote, distributed method calls and applications. While this approach provides many benefits, it also generates a large amount of overhead, with a corresponding performance hit as stubs are referenced, parameters go through the marshaling process, and objects are tossed around the network.

 Considerations of performance, practicality, and typical usage in the field resulted in the introduction of local interfaces in the EJB 2.0 specification. As noted, prior terminology referred to the home interface and the remote interface; at this point, depending on which approach is used, local interface and local home interface or remote interface and remote home interface are better terms. Either of the local home or remote home interfaces is referred to as the home interface; either of the local or remote interfaces is referred to as the component interface. This tutorial refers to the interfaces in these terms and uses these conventions for names.

 When using J2EE technologies, it is normal to focus on distributed, or remote, beans, but you should keep the local option in mind, when applicable. It may be surprising to learn that a bean can have local interfaces, remote interfaces, or both. However, the client must write to a specific (that is, local or remote) interface. There are some issues to keep in mind when using local interfaces: