ESB与服务

IAm*_*aja 4 java soa middleware apache-camel ejb-3.0

我是Java EE的新手,几天来一直在努力研究一些基本的中间件概念,并相信我可能在我对"如何工作"的理解方面取得了突破; 这个问题的一部分是要求确认我的调查结果,另一部分是合法的问题;-).

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

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

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

  • 使用像JBoss或GlassFish这样的成熟应用服务器
  • 在app server的web容器中有两个WAR:WebServices.warESB.war; 它们分别代表后端"网关"和服务总线
  • 在app server的业务容器中有我所有的EJB
  • 现在,WebService.war(网关)可以检测是否将请求中继到ESB或EJB

我的第二个问题是:我是否离开这里并且错过了中间件101的基本概念,或者这是一种中途体面的方法?

编辑:从最初的响应中我已经看到我在两个方面错了:(1)ESB和EJB实际上可以同步的或异步的,以及(2)当使用MDB时,EJB可以像ESB.

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

  • 何时使用ESB,何时使用MDB/EJB解决方案; 和
  • 非常喜欢Apache Camel的Processors API(EIP的实现); 我可以使用MDB/EJB的但每一个EJB内只使用一个骆驼处理器(Filter,WireTap,等)?

Jus*_*tin 5

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

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

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

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

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

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

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

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

UPDATE

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

进一步更新

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

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

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

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

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

我希望有所帮助!