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

EJB's - when to use Remote and/or local interfaces?

提问by Brian DiCasa

I'm very new to Java EE and I'm trying to understand the concept of Local interfaces and Remote interfaces. I've been told that one of the big advantages of Java EE is that it is easy to scale (which I believe means you can deploy different components on different servers). Is that where Remote and Local interfaces come in? Are you supposed to use Remote interfaces if you expect your application to have different components on different servers? And use Local interfaces if your application is only going to reside on one server?

我对 Java EE 很陌生，我正在尝试了解本地接口和远程接口的概念。有人告诉我，Java EE 的一大优势是易于扩展（我相信这意味着您可以在不同的服务器上部署不同的组件）。那是远程和本地接口的用武之地吗？如果您希望您的应用程序在不同的服务器上具有不同的组件，您是否应该使用远程接口？如果您的应用程序仅驻留在一台服务器上，则使用本地接口？

If my assumptions above are correct, how would you go about choosing whether to use Local or Remote interfaces for a new application, where your unsure of what the volume of traffic would be? Start off by using Local interfaces, and gradually upgrade to Remote interfaces where applicable?

如果我的上述假设是正确的，那么在不确定流量是多少的新应用程序中，您将如何选择是使用本地接口还是远程接口？从使用本地接口开始，并在适用的情况下逐渐升级到远程接口？

Thanks for any clarification and suggestions.

感谢您的任何澄清和建议。

采纳答案by Pascal Thivent

I'm very new to Java EE and I'm trying to understand the concept of Local interfaces and Remote interfaces.

我对 Java EE 很陌生，我正在尝试了解本地接口和远程接口的概念。

In the initial versions of the EJB specification, EJBs were "assumed" to be remote components and the only way to invoke them was to make a remote call, using RMI semantics and all the overhead it implies (a network call and object serialization for every method call). EJB clients had to pay this performance penalty even when collocated in the same virtual machine with the EJB container.

在 EJB 规范的初始版本中，EJB 被“假定”为远程组件，调用它们的唯一方法是进行远程调用，使用 RMI 语义和它暗示的所有开销（网络调用和对象序列化）方法调用）。即使与 EJB 容器并置在同一虚拟机中，EJB 客户端也必须为此付出代价。

Later, Sun realized most business applications were actually not distributing EJBs on a different tier and they fixed the spec (in EJB 2.0) by introducing the concept of Local interfaces so that clients collocated in the same virtual machine with the EJB container can call EJBs using direct method invocation, totally bypassing RMI semantics (and the associated overhead).

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

I've been told that one of the big advantages of Java EE is that it is easy to scale (which I believe means you can deploy different components on different servers)

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

Java EE can scale, but this doesn't necessarily means distributingcomponents. You can run a Web+EJB application on a cluster without separating the Web tier and the EJB tier.

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

Are you supposed to use Remote interfaces if you expect your application to have different components on different servers? And use Local interfaces if your application is only going to reside on one server?

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

I would phrase it like this: use remote interfaces if the client are not in the same JVM (this doesn't mean using only one server/JVM).

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

(...) Start off by using Local interfaces, and gradually upgrade to Remote interfaces where applicable?

(...) 从使用本地接口开始，然后逐渐升级到适用的远程接口？

I would probably start by using Local interfaces. And as already hinted, switching to remote interfaces is not always mandatory (you can cluster a collocatedstructure).

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

I suggest to check the resources mentioned below (the 2 first ones are quite old but still relevant, the 2 others are more recent).

我建议检查下面提到的资源（前 2 个很旧但仍然相关，另外 2 个是最近的）。

Resources

资源

• Under the Hood of J2EE Clusteringby Wang Yu
• Scaling Your Java EE Applicationsby Wang Yu
• Scaling Your Java EE Applications -- Part 2by Wang Yu

• 王宇在 J2EE 集群下
• 扩展您的 Java EE 应用程序作者：Wang Yu
• 扩展您的 Java EE 应用程序——Wang Yu 的第 2 部分

回答by Isaac

While I agree with most of what is written above, I would like to refine the "how to start" ideas a bit.

虽然我同意上面写的大部分内容，但我想稍微改进一下“如何开始”的想法。

My suggestion to you is to never everprogram directly to EJB interfaces within your code. Always use a regular, business-oriented interface, program to it (meaning, have your code call methods on the business-oriented interface) and provide the EJB "glue" code as a pluggable implementation. Your program should be focused on business logic, and not on implementation details such as EJB.

我给你的建议是从来没有过直接编程到你的代码中的EJB接口。始终使用常规的、面向业务的接口，对其进行编程（意思是，在面向业务的接口上使用您的代码调用方法）并提供 EJB“胶水”代码作为可插入的实现。您的程序应该关注业务逻辑，而不是 EJB 等实现细节。

That way, you can easily switch between remote and local implementations - and if you use an IoC container such as Spring, you can do it by means of configuration only.

这样，您可以轻松地在远程和本地实现之间切换 - 如果您使用 IoC 容器（例如 Spring），则只能通过配置来实现。

A special note about switching from local to remote: note that there are a few semantic differences between the two. For example, calling an EJB method via its "remote interface" results in arguments being passed by-value, while calling through the "local interface" results in arguments being passed by-reference. This is a majordifference; so if you "start with local", make sure that you design your system in a way that it takes "remote" semantics into consideration as well.

关于从本地切换到远程的特别说明：请注意，两者之间存在一些语义差异。例如，通过“远程接口”调用 EJB 方法会导致参数按值传递，而通过“本地接口”调用会导致参数按引用传递。这是一个主要区别；因此，如果您“从本地开始”，请确保您设计的系统也考虑到“远程”语义。

If your design relies on EJB methods changing passed-in objects, then it would be tricky for you to "switch to remote" later; perhaps even impossible.

如果您的设计依赖于 EJB 方法更改传入的对象，那么您稍后“切换到远程”会很棘手；也许甚至是不可能的。

Good luck.

祝你好运。

回答by Abdulaziz

This may answers your concerns :

这可能会解答您的疑虑：

Generally, your Enterprise Java Bean will need a remote client view in cases when you plan to use the bean in distributed environments. Specifically, these are the cases when the client that will be working with it will be in a different Java Virtual Machine (JVM). In the case of a remote client view, calling any method from the remote home interface and/or remote component interface will be handled via remote method invocation (RMI).

An EJB can use local client view only if it is really guaranteed that other enterprise beans or clients will only address the bean within a single JVM. If this is the case, such access will be carried out with direct method calls, instead of RMI.

通常，当您计划在分布式环境中使用该 bean 时，您的 Enterprise Java Bean 将需要一个远程客户端视图。具体来说，这些情况是将使用它的客户端将位于不同的 Java 虚拟机 (JVM) 中。在远程客户端视图的情况下，从远程本地接口和/或远程组件接口调用任何方法将通过远程方法调用 (RMI) 进行处理。

仅当确实保证其他企业 bean 或客户端仅在单个 JVM 内寻址该 bean 时，EJB 才能使用本地客户端视图。如果是这种情况，将使用直接方法调用而不是 RMI 来执行此类访问。

Source: http://www.onjava.com/pub/a/onjava/2004/11/03/localremote.html?page=last&x-showcontent=text

来源：http: //www.onjava.com/pub/a/onjava/2004/11/03/localremote.html?page=last& x-showcontent= text

回答by Pritam Banerjee

According to EJB Spec 3.2 an EJB can be either be localor remote. A business interface cannot be both local and remote at the same time.

根据EJB 3.2规格的EJB既可以是本地或远程。业务接口不能同时在本地和远程。

@Localannotated beans can only be accessed if they are in the same application.

@Local只有在同一个应用程序中才能访问带注释的 bean。

@Remoteannotated beans can be accessed across different applications, residing in different jvms or across application servers.

@Remote带注释的 bean 可以跨不同的应用程序访问，驻留在不同的 jvm 或跨应用程序服务器。

So the important things to keep in mind are:

因此，要记住的重要事项是：

1. If a bean class contains the @Remoteannotation, then all implemented interfaces are to be remote.
2. If a bean class contains no annotation or if the @Localannotation is specified, then all implemented interface are assumed to be local.
3. Any interfaces that is explicitly defined for a bean which contains no interface must be declared as @Local.
4. The EJB 3.2 release tends to provide more granularity for situations where local and remote interfaces need to explicitly defined.

1. 如果 bean 类包含@Remote注释，则所有实现的接口都是远程的。
2. 如果 bean 类不包含注解或@Local指定了注解，则假定所有实现的接口都是本地的。
3. 为不包含接口的 bean 显式定义的任何接口都必须声明为 @Local。
4. EJB 3.2 版本倾向于为需要显式定义本地和远程接口的情况提供更多粒度。