首页 文章

ESB与服务

提问于
浏览 次
4

我是Java EE的新手，几天来一直在努力学习一些基本的中间件概念，并且相信我可能在我对"how tings work"的理解上取得了突破 . 这个问题的一部分是要求确认我的调查结果，另一部分是合法的问题;-) .

Please confirm/clarify: 我对服务总线/ MOM（面向消息的中间件）的理解是，它们本质上是异步处理客户端请求 . 这与正常的请求 - 响应周期相反，它是同步的，通常由某种服务实现 . 在Java中，这样的总线/ MOM可能类似于Apache Camel，同步服务可能类似于EJB（3） . 因此，如果客户端需要立即处理请求， HttpRequest 可能会转到Web服务，然后将请求转发到正确的EJB; EJB处理消息并将结果返回给服务，然后服务将 HttpResponse 返回给客户端 . 因此，如果客户端有一个不阻止它们并且只需要处理的请求，那么Web服务会将它们 HttpRequest 转发到服务总线上的某个 endpoints ，并且该请求被视为消息并由各种处理器处理（滤波器，变压器等） .

首先，如果我说错ESB / MOM解决方案最适合处理异步请求，那么请纠正我，并且EJB（同样，3.x）最适合实时响应同步请求;或确认我是对的 .

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

  • 使用像JBoss或GlassFish这样的成熟应用服务器

  • 在应用服务器的Web容器中有两个WAR： WebServices.war 和 ESB.war ;它们分别代表后端"gateway"和服务总线

  • 在应用服务器的业务容器中拥有我的所有EJB

  • 现在， WebService.war （网关）可以检测是否将请求中继到ESB或EJB

我的第二个问题是： am I way off-base here and have I missed the basic concepts of Middleware 101, or is this a half-way decent approach?

Edit: 从初始响应中我已经看到我在两个方面错了：（1）ESB和EJB实际上可以是同步的或异步的，以及（2）当使用MDB时，EJB可以像ESB一样连接起来 .

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

  • 何时使用ESB，何时使用MDB / EJB解决方案;和

  • 我非常喜欢Apache Camel的处理器API（EIP的实现）;我可以使用MDB / EJB但是在每个EJB中只使用Camel处理器（ Filter ， WireTap 等）？

java ejb-3.0 soa apache-camel middleware

2 回答

  • 5

    这是一个很大的问题，值得一个大答案 .

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

    但是你的后端实现理论是非常错误的 .

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

    您不应该将请求转发给ESB，反之亦然 .

    ESB应该在客户端和后端之间中继和转换请求和响应 . ESB的一个重要想法是，如果后端发生变化，客户端不知道或不关心，因为他们的 Contract 是与ESB而不是后端 .

    所有这些都说，如果您的应用程序已经暴露了Web服务，那么您可能不需要ESB并且记住没有一种正确或错误的方法可以执行某些操作 .

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

    UPDATE

    您还可以获得消息驱动的EJB，它们确实可以让EJB在像时尚这样的总线中链接在一起 .

    FURTHER UPDATE

    因此，我将使用ESB的一种情况是，我是否需要在遗留系统中将非基于标准的服务公开为SOAP服务 . 但是还有更多需要考虑的事情，您还应该为组织实现数据字典，这样即使您的遗留系统被替换，ESB公开的服务也可能保持不变 .

    因此，作为一个具体示例，组织应在其数据字典中定义客户实体的外观，ESB可以公开服务以检索客户 . ESB将对a执行一些调用基于遗留系统，然后转换结果 . 如果将来后端系统存储客户更改，ESB公开的服务可能保持不变，只需要更新后端调用和转换 .

    现在希望考虑到这一点，下一点将是有道理的 . 所有这一切都可以通过“传统”ESB实现，例如JBoss ESB或Mule ESB，但也可以使用EJB Camel（或其他东西） .

    开箱即用的ESB的优点是提供的连接器，听众和变压器 . 但是，如果没有任何开箱即用的功能可以帮助您，那么您选择的方向几乎没有差异 .

    家庭发展ESB的一个优点是可维护性，如果需要，可以更容易地找到熟悉EJB并且可以快速学习Camel的资源，而不是找到专门的ESB资源或培训资源 .

    我希望有所帮助！

    回复于
  • 3

    正如您所注意到的，中间件/集成的世界在定义和术语上是一团糟 . 让我澄清一下 .

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

    在引用下面的EJB时，我指的是除了实现异步消息传递的MDB（消息驱动Bean）之外的EJB .

    • 同步请求/回复 - 请求后请求回复"rather soon" . 通常通过Web服务和EJB（RMI等）实现 .

    • 作为向使用数据的许多订户发布的消息（通常价格表从价格主系统推送到需要信息的各种系统，例如订单系统） .

    • 作为从一个应用程序到另一个应用程序的消除和忘记消息 . 典型地，订单系统需要向调用系统发送订单，然后调用系统公开服务以创建发票 .

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

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

    • 如果异步模式（发布/订阅，触发和忘记以及异步 . 请求/回复，那么具有高运行时间且非常稳定的中继服务器将使整个业务消息的失败传输成为可能 .

    • MOM，通常可以很容易地实现适配器和ESB，它非常适应负载峰值，网络干扰和硬件/软件故障 . 消息通常是持久的，并在中继之前存储到磁盘 . 此外，事务通常也是可用的，特别是在符合JMS的实现中 . 这保证了数据不会在途中丢失 .

    我希望我没有比以前更糟糕的事情 . 这至少是我对此的看法 .

    回复于

相关问题