企业服务总线的好处

我在哪里可以找到有关企业服务总线(ESB)的用途和好处的一些信息？

我正在寻找有关的信息:

问题的种类和ESB有助于解决

ESB的替代方案 - 以及在它们之间进行选择的权衡

作为开发人员,您需要做什么来构建与ESB兼容的系统

我正在寻找比维基百科或供应商的在线营销手册更精细的细节.理想情况下,一些示例代码将有助于阐明利用ESB所涉及的内容.从.NET或Java角度来看,信息最有用.

谢谢.

我建议ESB或者不要ESB开始,由Mule的创建者编写.

ESB是实现企业集成模式的好方法.

ESB有助于解决的各种问题

您有许多协议需要规范化为单个协议(例如FTP,电子邮件,SOAP,XMPP等到消息系统),例如ActiveMQ.这使您可以将服务的实现与协议分离.

您需要一种将服务挂钩到此体系结构的一致方法,以便它们可以侦听消息,处理消息并生成消息(消息端点,通道适配器等).

您可能希望托管容器将这些不同的组件部署到(例如ServiceMix,Mule)中

您可能需要将许多预构建组件和适配器转换为各种协议(例如,ServiceMix,Mule和Camel都有许多预构建组件).

您可能需要长时间运行的工作流程.业务流程管理通常是与ESB一起提供的(Apache ODE插入许多开源ESB).

ESB的替代方案

替代方案实际上取决于您尝试解决的问题.

为了提供分布式服务,人们经常使用通过一些点对点RPC协议(比如基于RMI的EJB或基于HTTP的Web服务)公开服务的应用服务器.因此,客户端不是将消息放到"总线"上,而是直接调用服务器.

要响应特定协议,您可以构建响应该协议的客户端,例如编写使用JavaMail侦听电子邮件的应用程序或使用Smack侦听XMPP的应用程序.如果您的问题仅限于一个或两个协议,则可能不值得引入完整的ESB.

作为开发人员,您需要做什么来构建与ESB兼容的系统

这将取决于您选择的ESB,虽然考虑到大多数好的设计都可以调用各种协议以及主机POJO,但您不需要构建ESB兼容系统.值得尝试使您的代码异步.

例如,Apache Camel可能具有最简洁的配置,这是一个教程.

三个关键优势:

总线为端点提供了一种连接方式,而无需直接相互通信.它简化了端点的通信,因为它们只需要符合标准通信接口即总线.(这适用于任何技术总线,而不仅仅是ESB)

ESB提供了一个获取一些关键端点指标的位置:频率,可用性和性能.

ESB倾向于提供多个通信接口.但是,开发人员只需要选择最简单的方法来获取和接收来自总线的数据.

但是,请确保这些将为您的情况提供商业价值.拥有ESB会为您的企业增加另一个复杂性.理想情况下,您不应该基于一些应用程序而是整个组织来选择此选项.组织应该只有一个生产ESB群集.

备择方案:

只是直接将事物彼此连接,尤其是在通信协议相同的情况下.这对于简单的应用程序集群很有用,并且不需要太多思考.但是,随着应用程序数量的增长,维护互连变得困难.

另一种替代方案是MQ实现.这将为您提供一种在没有复杂互连的情况下推送数据的方法,但是您只能使用一个通信通道.幸运的是,对于Java,它们具有JMS标准.

实用性:

我已说过可能的替代方案.起初他们可能看起来很糟糕,但并不是说你不能这样开始.我个人写的东西是直接与遥控器通话而不通过ESB来确保其工作而不必过多担心集成问题.

如果您没有ESB,我建议您尝试使用Mule进行开发,使用WebSphere ESB进行测试和生产.我倾向于使用两种产品,这些产品应该遵循标准,以确保我们保持供应商的诚实,并确保您的开发人员符合防止无意中供应商锁定的标准.

最后,回答以下问题:是时候添加一点复杂性以简化其他复杂性,从长远来看,您的企业是否值得付出代价？

除了已经提到的网站.您应阅读本文" 不要使用ESB,除非您绝对必须 ".它由MuleSource的CTO编写,MuleSource是最受欢迎的开源ESB之一.不完全是你的问题的答案,更多的是要问自己"我需要一个ESB"吗？