ESB与服务的区别

Question

我是Java EE的新手，最近几天一直在努力理解一些基本的中间件概念，我认为我可能已经有了关于“如何工作”的重大突破。这个问题的一部分是请求确认我的发现，另一部分则是一个合法的问题。

请确认/澄清：我对服务总线/MOM（消息导向中间件）的理解是它们天生就是用于异步处理客户端请求。这与通常由某种服务实现的同步请求-响应周期不同。在Java中，这样的总线/MOM可以是像Apache Camel这样的东西，而同步服务可以是像EJB（3）这样的东西。因此，如果客户端需要立即处理请求，则 HttpRequest 可能会发送到Web服务，然后将请求转发到正确的EJB；该EJB处理消息并将结果返回给服务，然后将 HttpResponse 返回给客户端。因此，如果客户端有一个不会阻塞他们的请求，而只需要被处理，则Web服务将他们的 HttpRequest 转发到服务总线上的某个终点，并且该请求将被视为消息并由各种处理器（过滤器、转换器等）处理。

首先，请纠正我是否错误地陈述了ESB/MOM解决方案最适合处理异步请求，并且EJB（再次，3.x）最适合实时响应同步请求；或者请确认我是正确的。

在这种情况下，对我来说，大型应用程序需要两种类型的后端来处理同步（阻塞）和异步（非阻塞）客户端请求。因此，我的理论是将后端实现如下：

- 使用像JBoss或GlassFish这样的全功能应用服务器 - 在应用程序服务器的Web容器中有两个WAR： WebServices.war 和 ESB.war ，分别代表后端“网关”和服务总线 - 在应用程序服务器的业务容器中拥有所有的EJBs - 现在， WebService.war （网关）可以检测是否将请求转发到ESB或EJBs。

我的第二个问题是：我完全偏离了基本的中间件概念吗？还是这是一个半可行的方法？

编辑：从最初的回复中，我已经看到我在两个方面错了：（1）ESB和EJB实际上可以是同步或异步的；（2）使用MDB时，可以将EJB连接起来，就像ESB一样。

所以这些更正为我带来了一些新的思维障碍：

• 何时选择使用ESB，何时选择使用MDB/EJB解决方案；以及
• 我非常喜欢Apache Camel的Processors API（EIPs的实现）；我能否在每个EJB内部使用Camel处理器（Filter，WireTap等），但仍然使用MDB/EJB？

- IAmYourFaja

---

异步并不意味着“发射并忘记”，因为生产者可以设置一个回复通道，并在该通道上等待响应。 - opyate

感谢@opyate - 你能告诉我异步意味着什么吗？我认为反命题不成立：EJB在其原始状态下不能以总线方式连接在一起，对吗？我的理解是EJB旨在成为独立的服务，而不是中间件“链条上的链接”。 - IAmYourFaja

您可以轻松地使用EJB构建复合服务，调用一系列其他EJB，然后返回结果。但是，使用异步请求会有些棘手。ESB软件专门为这些任务而设计。 - Petter Nordlander

关于你上一个问题。为什么不使用Camel将你的EJB粘合在一起呢？最好尽可能多地使用MDBs。这样，你就可以将所有业务逻辑放在EJB中，而整个集成层则在Camel中。保持业务逻辑清晰，避免过多的集成逻辑总是很好的选择。 - Petter Nordlander

Answer 1

这是一个很大的问题，需要一个很大的答案。

ESB可以处理同步或异步请求，消息通常是异步使用的。

然而，你的后端实现理论是相当错误的。

JAX WS Web服务可以直接从EJB jar或EAR中运行，并且可以在任何应用服务器中以这种方式执行。EJB可以将消息放入队列中，甚至可以是异步的。

你不应该将请求传递给ESB，而应该反过来。

ESB应该在客户端和后端之间中继和转换请求和响应。ESB的一个重要思想是，如果后端更改了，客户端并不知道或关心，因为他们的合同是与ESB而不是后端签订的。

尽管如此，如果你的应用程序已经暴露了Web服务，那么你可能不需要ESB，记住没有一种正确或错误的方法来做某事。

我建议你写一个更明确的问题，涵盖你的具体问题，你可能会得到很多关于如何解决它的建议。

更新：

你还可以获得消息驱动的EJB，这确实允许EJB以总线的方式链接在一起。

进一步更新：

因此，我使用ESB的一个场景是，如果我需要将遗留系统中的非标准基础服务公开为SOAP服务。但是还有更多需要考虑的，你还应该为你的组织实现一个数据字典，这将使ESB公开的服务即使在替换遗留系统时也能保持不变的机会更大。

因此，以一个具体的例子来说，组织应该在其数据字典中定义客户实体的外观，ESB可以公开一个检索客户的服务。ESB将在基于遗留系统上执行某些调用，然后转换结果。如果将来存储客户的后端系统发生更改，则ESB公开的服务可能仍然相同，只需更新后端调用和转换即可。

现在希望有了这个想法，下一部分就会有意义了。所有这些都可以使用“传统”的ESB（如JBoss ESB或Mule ESB）实现，但也可以使用EJB + Camel（或其他东西）实现。

开箱即用的ESB的优点是提供的连接器、监听器和转换器。然而，如果没有任何开箱即用的功能可以帮助你，那么你选择的方向几乎没有什么区别。

自己构建ESB的优点是可维护性，很容易找到熟悉EJB并且可以快速学习Camel的资源，而不是找到专门的ESB资源或培训资源。

希望这有所帮助！

- Justin

---

哇，非常好的回答（+1）！我已经将您的更正合并到我的问题底部的“编辑”中 - 如果您不介意，您能否请阅读我的编辑并告诉我是否越来越接近？再次感谢！ - IAmYourFaja

Answer 2

如您所见，中间件/集成领域的定义和术语有些混乱。让我详细说明一下。

服务只是提供功能的“某物”的概念。有多种方法来公开服务。

下面提到的 EJB 不包括 MDB（消息驱动 Bean），其实现异步消息。

同步请求/响应 - 请求后很快就期望收到响应。通常通过 Web 服务和 EJB（RMI 等）实现。

作为发布的消息发送给许多订阅者，这些订阅者消耗数据（通常是价格列表从价格主系统推送到需要信息的各个系统，如订单系统）。

作为一个“发出并忘记”的消息从一个应用程序发送到另一个应用程序。通常，订单系统需要将订单发送到发票系统，然后发票系统公开一个创建发票的服务。

在概念上，ESB 是一个软性的东西。它是关于公司业务服务如何公开以便整个公司的应用程序可以消耗/使用这些服务的概念/协议。这基本上可能只是一组约束“只允许使用 SOAP/WebServices 的请求/响应服务，并且所有消息都应符合 OAGIS XML 标准”。但是，在大多数情况下，大多数公司的应用程序/服务器/系统环境不是同质的。有 COTS 产品，带有 COBOL 应用程序的大型机，.NET 应用程序以及 Java EE 应用程序。因此，常见的方法是使用 ESB 软件套件在技术上实现服务总线，或者构建适配器以接向总线。Apache Camel 可作为 ESB 实现的一部分来设置路由、转换、转换等。

与 ESB 紧密集成的一个东西是面向消息的中间件，您说得还不错。它通常只是实现消息队列的服务器。相对于直接调用 EJB/Web 服务，MOM 的好处有几个。

如果采用异步模式（发布/订阅、发出并忘记和异步请求/响应），那么具有高稳定性和稳定性的中继服务器将使整体上业务消息的传输失败减少。

与 ESB 非常坚韧的 MOM 通常很容易实现适配器，而且能够很好地承受负载峰值、网络干扰和硬件/软件故障。消息通常是持久性的，并在传递之前存储到磁盘上。此外，在 JMS 兼容的实现中通常提供事务。这保证了数据不会丢失。

我希望我没有比以前更搞糟事情。至少这是我的看法。

- Petter Nordlander