企业服务总线的好处

我建议 To ESB or not to ESB 首先,由创建者编写 Mule .

ESB是实现 Enterprise Integration Patterns .

ESB帮助解决的各种问题

• 您有许多要规范化为单个协议的协议(如FTP、电子邮件、SOAP、XMPP等到消息系统),例如ActiveMQ。这允许您将服务实现与协议分离。
• 您需要一种一致的方法将服务连接到这个体系结构中,以便它们能够监听消息、处理消息和生成消息(消息端点、通道适配器等)。
• 您可能需要一个托管容器将这些不同的组件部署到(例如servicemix、mule)
• 您可能需要将一些预构建的组件和适配器放入各种协议中(例如servicemix、mule和camel有许多预构建的组件)。
• 您可能需要长时间运行的工作流。业务流程管理通常是与ESB(ApacheODE插入到许多开放源代码ESB)一起提供的。

ESB的替代方案

备选方案实际上取决于您试图解决的问题。

• 为了提供分布式服务,人们通常使用应用服务器,通过点对点的RPC协议(如RMI上的EJB或HTTP上的Web服务)公开服务。因此,客户机不是将消息放到“总线”上,而是直接调用服务器。
• 要响应特定的协议,您只需构建一个响应该协议的客户机,例如编写一个使用javamail侦听电子邮件的应用程序,或者一个使用smack侦听XMPP的应用程序。如果您的问题被限制在一个或两个协议上,那么可能不值得引入完整的ESB。

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

这将取决于您选择的ESB,尽管考虑到大多数好的ESB设计用于调用各种协议以及主机POJO,但是您不需要做太多的工作来构建与ESB兼容的系统。值得尝试使代码异步化。

例如,ApacheCamel可能具有最简洁的配置,这里是 tutorial .

三个主要优势:

• 总线为端点提供了一种相互连接的方式,而不必直接进行通信。它 简化通信 对于端点,因为它们只需要符合标准通信接口,即总线。(这是任何技术总线,而不仅仅是ESB)
• ESB提供了 单一场所 获得一些关键的终点指标:频率、可用性和性能。
• ESB倾向于提供多个通信接口。然而,开发人员只需要选择从总线获取和接收数据最简单的一个。

但是,确保这些将提供 商业价值 为了你的处境。拥有一个ESB又增加了企业的复杂性。理想情况下,您不应该基于几个应用程序来选择它,而应该基于整个组织。应该只有 一 组织的生产ESB集群。

选择:

• 只需将事物直接连接到彼此,特别是在通信协议相同的情况下。这对于简单的应用程序集群很好,并且不需要太多的思考。但是,随着应用程序数量的增长,维护互连变得困难。
• 另一种选择是MQ实现。这将为您提供一种在没有复杂互连的情况下推送数据的方法,但随后您只能使用一个通信通道。幸运的是,Java具有JMS标准。

实用性:

我已经说明了可能的替代方案。他们一开始可能看起来很糟糕,但并不是说你不能这样开始。我亲自编写一些东西来直接与远程通信,而不必经过ESB,以确保它可以工作,而不必担心太多的集成问题。

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

最后,只需回答以下问题:从长远来看,为简化企业的其他复杂性而增加一点复杂性的时间是否值得付出代价?

除了已经提到的站点之外。你应该阅读这篇文章 Don't use an ESB unless you absolutely have to “。它是由mulesource的cto编写的,mulesource是目前最流行的开源ESB之一。不完全是你问题的答案,更重要的是要问你自己“我需要ESB吗”?

有一个 decent 3-part series 在IBM,关于ESB,这是一个非常面向概念和供应商不可知论的概念(大多数情况下)。我在ibm的网站上搜索,发现了很多关于ESB的好东西。还有一些不错的信息、视频和东西 BizTalk site .

看看这个 Hanselminutes podcast . 它回答了一些在实现服务总线之前应该真正问自己的问题。

企业服务总线(EnterpriseServiceBus,ESB)是中间件的软件体系结构,它为更复杂的体系结构提供基本服务。例如,ESB集成了实现面向服务的体系结构(SOA)所需的功能。一般来说,ESB可以被认为是一种管理对应用程序和服务(尤其是旧版本)的访问的机制,通过基于Web或基于表单的客户端前端向最终用户提供单一、简单和一致的接口。

本质上,ESB为分布式异构后端服务和应用程序以及分布式异构前端用户和信息消费者做了中间件真正应该做的事情:隐藏复杂性,简化访问,允许开发人员使用通用的、规范的查询、访问和交互形式,在他的背景。ESB吸引力的关键,也可能是它未来的成功,在于它能够支持由业务需求驱动的增量服务和应用程序集成,而不是由可用技术控制。

http://searchsoa.techtarget.com/definition/enterprise-service-bus

WSO2 Enterprise Service Bus (产品)

WSO2企业服务总线(ESB)4.7.0文档!wso2 esb是一个快速、轻量级、100%开放源码、用户友好的esb,在Apache软件许可2.0版下分发。WSo2ESB允许系统管理员和开发人员方便地配置消息路由、中介、转换、日志记录、任务调度、故障转移、负载平衡等。它支持最常用的企业集成模式(EIP),并为高级集成需求启用传输切换、事件、基于规则的中介和基于优先级的中介。ESB运行时设计为完全异步、无阻塞和基于ApacheSynapse中介引擎的流式处理。

wso2 esb是在革命性的wso2 carbon平台之上开发的,这是一个基于OSGi的框架,通过组件化为SOA提供无缝的模块化。它包含许多特性和可选组件(附加组件),您可以在ESB中安装这些特性和可选组件,您可以轻松地删除环境中不需要的特性,从而允许您完全定制和定制WSo2ESB,以满足您的确切SOA需求。

建筑 企业上的应用程序基础结构可能本质上很复杂,由数百个语义完全不同的应用程序组成。其中一些应用程序是定制的,一些是从第三方获得的,一些可以是两者的组合,可以在不同的系统环境中运行。

这些异构应用程序之间的集成对企业至关重要。不同的服务可能使用不同的数据格式和通信协议。服务的物理位置可以任意更改。所有这些约束意味着应用程序仍然紧密耦合在一起。ESB可以用来松开不同服务和服务使用者之间的这些耦合。

WSo2ESB是一个成熟的企业级ESB。它建立在Apache Synapse项目上,该项目使用Apache Axis2项目构建。所有组件都是作为OSGi包构建的。

看看我的演示文稿” Spoilt for Choice - How to choose the right ESB “。

我解释了何时使用ESB、集成套件或仅仅是集成框架(如ApacheCamel)。我还讨论了开放源码ESB和专有ESB之间的区别。

看一看 http://www.windowsazure.com/en-us/develop/java/how-to-guides/service-bus-queues/ 和 http://www.windowsazure.com/en-us/develop/java/how-to-guides/service-bus-topics/ 这些都是好东西。

您需要问自己的第一个问题是,为什么需要ESB?

ESB通常用于事件SOA分布式体系结构中,这在当今似乎是一个热门词汇。在您进入ESB之前,让我提醒您马丁的福勒分布系统第一定律:

http://martinfowler.com/bliki/FirstLaw.html

“分布式对象设计的第一条法则:不要(从EAA的P中)分布您的对象。

相关章节可在线查阅。”

当您构建一个新系统时,最重要的方面是它是面向未来的,这意味着易于扩展和维护。如果您围绕松散服务的概念构建系统,并且静态定义的契约分布在网络环境中,那么您可以“隐藏”该特定服务所需的体系结构,因为接口仍然存在。

ESB与Asyn消息传递系统有着密切的关系,因此在您开始使用这种实现之前,要知道一个体系结构不必是同构的,即所有服务都以相同的方式实现,不要开始最大的错误,即从一开始就分发您的系统,您应该只在需要时分发SCA。Le,不在手前。不过,您需要确保的是,如果出现需求,您的服务应该能够轻松地分发,而不会违反任何意味着该服务客户发生变化的合同。

至于ESB的好处,它们与SOA相同,ESB添加了asyn消息(事件)操作的上下文。

可以在这里找到ESB好处的简短概述:

http://javaenterpriseworld.blogspot.de/2014/02/benefits-of-esb.html

主要专业人员大致列出了…

没有理由使用ESB。不要这样做。不必要的复杂性。当你可以直接去的时候,为什么要通过中介?ESB人员会告诉您点对点是不好的,但不知何故点对点和从ESB是好的。

首先让我解释一下 SOA . 它是关于构建一个架构,作为一组可重用的软件模块,公开为具有定义良好的接口的__服务__。这些服务促进了松耦合,并从客户机抽象出其实现细节。

如果每个组件直接调用服务,SOA最终可能会变得混乱。因此,它有以下共同问题。

• 您如何找到使用的服务和不使用的服务?
• 您如何找到使用特定服务的客户?
• 如何在不中断的情况下向服务发布更新或向现有服务公开新版本?
• 如何支持旧客户端调用旧服务接口的向后兼容性
• 您如何在所有服务中为内部/外部流量执行日志记录、审核、安全强制等操作?

这个 ESB是解决方案 以上问题。ESB公司

• 有助于恢复秩序
• 能够严格执行公司政策
  • 例如,安全、节流、审计等始终适用
• 虚拟化服务终结点
  • 促进版本控制、灵活更新、HA/负载平衡等。
• 执行路由、中介、转换等

可以找到一些示例用例 here .请注意,它们来自AdroitLogic的开发人员站点,并且与超级ESB、AdroitLogic的ESB严格耦合。