EJB - 何时使用远程和/或本地接口？ [英] EJB's - when to use Remote and/or local interfaces?
问题描述
如果我上面的假设是正确的，您将如何选择是否使用本地或远程用于新应用程序的接口，您不确定流量是多少？开始使用本地界面，并逐渐升级到适用的远程接口？
感谢任何澄清和建议。
我对Java EE非常新，我正在努力了解本地接口和远程接口的概念。
在EJB规范的初始版本中，EJB被假定为远程组件，调用它们的唯一方法是进行远程调用，使用RMI语义及其所有开销（每个方法调用的网络调用和对象序列化）。即使在与EJB容器相同的虚拟机中并行配置，EJB客户端也必须支付此性能损失。
后来，Sun认识到大多数业务应用程序实际上并不是在不同层次上分发EJB，而是通过引入本地接口的概念来修复规范（在EJB 2.0中），以便客户端与同一虚拟机并置在EJB容器中可以使用直接方法调用来调用EJB，完全绕过RMI语义（和相关的开销）。
我被告知，Java EE的一大优点是容易扩展（我认为这意味着您可以在不同的服务器上部署不同的组件）
Java EE可以缩放，但这并不一定意味着分发组件。您可以在集群上运行Web + EJB应用程序，而不必分离Web层和EJB层。
如果您希望应用程序在不同的服务器上具有不同的组件，您是否应该使用远程接口？如果您的应用程序仅驻留在一个服务器上，则使用本地界面？
我将这样做：使用远程接口if客户端不在同一个JVM中（这并不意味着只使用一个服务器/ JVM）。
（...）开始关闭使用本地接口，并逐渐升级到远程接口适用？
我可能会从本地接口开始。如已经暗示的，切换到远程接口并不总是强制性的（您可以集中一个并置的结构）。
我建议检查下面提到的资源（第一个是相当老但仍然相关，其他2个更新）。
资源
- Tyler Jewell的EJB 2.0规范发布评论
- 在J2EE集群的罩下王玉
- <王Yu a h h <<
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> li> 缩放您的Java EE应用程序 - 第2部分通过王玉
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?
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.
I'm very new to Java EE and I'm trying to understand the concept of Local interfaces and Remote interfaces.
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.
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).
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 can scale, but this doesn't necessarily means distributing components. You can run a Web+EJB application on a cluster without separating the Web tier and the EJB tier.
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).
(...) 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 collocated structure).
I suggest to check the resources mentioned below (the 2 first ones are quite old but still relevant, the 2 others are more recent).
Resources
- EJB 2.0 Specification Release Review by Tyler Jewell
- Under the Hood of J2EE Clustering by Wang Yu
- Scaling Your Java EE Applications by Wang Yu
- Scaling Your Java EE Applications -- Part 2 by Wang Yu
这篇关于EJB - 何时使用远程和/或本地接口？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
