4

我是 Java EE 的新手，几天来一直在为一些基本的中间件概念苦苦挣扎，我相信我可能刚刚对“tings 如何工作”的理解有了突破；这个问题的一部分是要求确认我的发现，另一部分是一个合法的问题;-)。

请确认/澄清：我对服务总线/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; 分别代表后端“网关”和服务总线
  • 在应用服务器的业务容器中有我所有的 EJB
  • 现在，WebService.war（网关）可以检测是否将请求中继到 ESB 或 EJB

我的第二个问题是：我是否在这里偏离了基础，我是否错过了中间件 101 的基本概念，或者这是一个半途而废的方法？

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

所以这些更正给我带来了一些新的心理障碍：

  • 何时使用 ESB，何时使用 MDB/EJB 解决方案；和
  • 我真的很喜欢 Apache Camel 的处理器 API（EIP 的实现）；我可以使用 MDB/EJB，但在每个 EJB 中只使用 Camel 处理器（Filter、WireTap等）吗？
4

2 回答 2

5

这是一个大问题，值得一个大答案。

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 的一个优势是可维护性，与找到专门的 ESB 资源或培训资源相比，找到一个非常了解 EJB 并且可以在需要时快速学习 Camel 的资源要容易得多。

我希望这有帮助！

于 2012-06-22T13:40:54.050 回答
3

正如您所注意到的，中间件/集成的世界在定义和术语上有点混乱。让我澄清一下。

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

在下面提到 EJB 时，我指的是 EJB，除了 MDB（消息驱动 Bean），它实现了异步消息传递。

  • 同步请求/回复 - 在请求之后“很快”会收到回复。通常通过 Web 服务和 EJB（RMI 等）实现。
  • 作为向使用数据的多个订阅者发布的消息（通常价格表从价格主系统推送到需要信息的各种系统，例如订单系统）。
  • 作为从一个应用程序到另一个应用程序的即发即弃消息。通常，订单系统需要向调用系统发送订单，然后调用系统公开一个服务来创建发票。

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

与 ESB 紧密集成的一件事是面向消息的中间件，你说得对。它通常只是一个实现消息队列的服务器。与直接调用 EJB/Web 服务相比，MOM 的好处很少。

  • 如果是异步模式（发布/订阅、触发和忘记以及异步请求/回复，那么具有高正常运行时间且非常稳定的中继服务器将总体上减少业务消息的失败传输。
  • MOM 通常使实现适配器和 ESB 变得相当容易，该 ESB 对负载峰值、网络干扰和硬件/软件故障具有很强的弹性。消息通常是持久的，并在中继之前存储到磁盘中。事务也经常可用，特别是在 JMS 兼容的实现中。这保证了数据不会在途中丢失。

我希望我没有比以前更糟。至少这是我对此的看法。

于 2012-06-22T14:25:10.207 回答