远程EJB与本地EJB的可伸缩性

Question

我一直在尝试在数据访问层的本地和远程EJB之间做出决定。通过大量的研究，似乎普遍的共识是，如果我想要可扩展性，我应该使用远程EJB。

这意味着什么？我找不到任何明确说明为什么远程EJB可以扩展而Local不能扩展的东西。

Answer 1

我不确定你在哪里达成一致意见。

记住Fowler's First Law of Distributed Objects。

您必须通过网络从Java对象到关系数据库进行调用（除非它是内存数据库）。为什么从会话bean向远程对象添加额外的跃点会更快或更具可伸缩性？

此外，可扩展性的决定远不止于此。

我说你的共识是错误的：如果可以，请选择本地。

Answer 2

区别在于：

• LocalBean： 这将在与调用者相同的EJB容器中运行。这意味着与远程呼叫相比，每个呼叫都更快。但即使资源耗尽，它也将保持在同一服务器节点上。

• RemoteBean： 这将在EJB集群中的一个节点上运行。如果正在运行refource的auf，它将跳转到另一个节点。您还可以添加节点以进行扩展。

修改 如果您希望bean只是编辑数据库，请使用LocalBeans .. 正如@duffymo写的那样

Answer 3

我假设我们正在谈论一个经典的Java EE场景：

 client (usually browser) ----> Servlet ----> EJB ----> DB

在这种情况下，我们可以共同定位Servlet和EJB，并使用本地接口或在单独的层中使用Servlet和EJB，因此需要远程接口 - 当然使用远程接口需要额外的网络跃点，但它可以可以想象给予好处。

首先考虑缩放本地方案。 Servlet / EJB引擎运行不足，因此我们部署另一个，获得更多功能（显然，servlet前面的一些喷涂器必须分配工作。我们需要更多的功能，添加更多的Servlet / EJB层。就好了，它可以扩展。但是......

假设我们的EJB层真的很重，可能在获取数据后进行了一些复杂的计算。为了实现我们所需的性能，我们扩展组合的Servlet / EJB层，但我们不需要Servlet引擎的所有副本，它们几乎不做任何工作，所有工作都在EJB层，我们消耗内存和其他资源没原因。在这种情况下，使用远程EJB可能会让我们获胜，我们可以独立部署，获得所需的servlet引擎和EJB引擎的尽可能多的副本，与复杂的计算成本相比，远程跃点的成本可以忽略不计

Answer 4

嗯，我理解接受的答案，但远程EJB的使用并不总是指多个服务器中的分布式业务逻辑。

使用远程EJB的可扩展性的一个很好的例子是API Gateways。您可以将API网关配置为EJB客户端（每个示例使用一个WAR），以使用包含业务逻辑的不同服务器（每个示例的EAR）中的远程EJB。

使用这个想法，您可以拥有多个服务器来为API网关提供远程EJB，为每个lookup中的所有服务器分配工作。