企业服务总线的好处

时间:2010-01-07 19:42:54

标签: java .net architecture esb

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

我正在寻找有关的信息:

  1. 问题的种类和ESB有助于解决
  2. ESB的替代方案 - 以及在它们之间进行选择的权衡
  3. 作为开发人员,您需要做什么来构建与ESB兼容的系统
  4. 我正在寻找比维基百科或供应商的在线营销手册更精细的细节。理想情况下,一些示例代码将有助于阐明利用ESB所涉及的内容。从.NET或Java角度来看,信息将是最有用的。

    感谢。

11 个答案:

答案 0 :(得分:22)

我建议To ESB or not to ESB开头,由Mule的创建者撰写。

答案 1 :(得分:19)

ESB是实施Enterprise Integration Patterns的好方法。

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可能具有最简洁的配置,这里是tutorial

答案 2 :(得分:7)

三个主要优势:

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

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

备选方案:

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

实用性:

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

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

最后,回答以下问题:是时候添加一点复杂性来简化企业从长远来看值得花费的其他复杂性吗?

答案 3 :(得分:6)

除了已经提到过的网站。您应该阅读“Don't use an ESB unless you absolutely have to”这篇文章。它由MuleSource的CTO编写,MuleSource是最受欢迎的开源ESB之一。不完全是你的问题的答案,更多的是要问自己“我需要一个ESB”吗?

答案 4 :(得分:3)

IBM在ESB上有一个decent 3-part series,它非常注重概念,并且与供应商无关(大多数情况下)。我在IBM的网站上找到了很多关于ESB的好东西。 BizTalk site还有一些不错的信息,视频和内容。

答案 5 :(得分:2)

查看此Hanselminutes podcast。它回答了一些在实现服务总线之前你应该问自己的问题。

答案 6 :(得分:2)

企业服务总线(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 Software License v2.0下。 WSO2 ESB允许系统管理员和开发人员方便地配置消息路由,中介,转换,日志记录,任务调度,故障转移,负载平衡等。它支持最常用的企业集成模式(EIP),并支持传输切换,事件,基于规则的中介和基于优先级的中介,以满足高级集成需求。 ESB运行时基于Apache Synapse中介引擎设计为完全异步,非阻塞和流式传输。

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

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

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

WSO2 ESB是一个成熟的企业级ESB。它基于Apache Synapse项目构建,该项目使用Apache Axis2项目构建。所有组件都构建为OSGi包。

答案 7 :(得分:1)

看一下我的演讲“Spoilt for Choice - How to choose the right ESB”。

我将解释何时使用ESB,Integration Suite或仅使用Integration Framework(例如Apache Camel)。我还讨论了开源和专有ESB之间的区别。

答案 8 :(得分:1)

没有理由使用ESB。不要这样做。不必要的复杂性。为什么要直接去中介? ESB的人会告诉你,点到点是不好的,但不知何故指向和从ESB指出是好的。

答案 9 :(得分:0)

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

ESB通常用于事件SOA分布式体系结构,现在似乎是一个热门话题。在你进入ESB之前,让我提醒你马丁的分发系统的福勒第一定律:

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

“我的分布式对象设计的第一定律:不要分发你的对象(来自EAA的P)。

相关章节可在线获取。“

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

ESB与asyn消息传递系统密切相关,因此在开始进入这种实现之前,要知道架构不必是同构的,即所有服务都以相同的方式实现,不要启动最大的从一开始就分配你的系统的错误,你应该只在你需要扩展时分发,不能事先分发。但是,您需要确保的是,您的服务应该能够在需要时轻松分发,而不会违反任何合同,这意味着对该服务的客户进行更改。

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

答案 10 :(得分:0)

首先让我解释 SOA 。它是关于构建一个体系结构作为一组可重用的软件模块,公开为“服务”,具有良好定义的接口。这些服务有助于松散耦合,并从客户端抽象出其实现细节。

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

  • 您如何找到使用的服务&amp;哪个不是?
  • 您如何找到使用特定服务的客户?
  • 如何在不中断的情况下推出服务更新或将新版本公开给现有服务?
  • 如何支持调用旧服务接口的旧客户端的向后兼容性
  • 如何针对内部/外部流量在所有服务中执行日志记录,审核,安全实施等?

上述问题的 ESB是解决方案。 ESB ...

  • 帮助带来秩序
  • 可以严格执行公司政策
    • e.g。安全,限制,审计等始终如一地应用
  • 虚拟化服务端点
    • 促进版本控制,灵活更新,HA /负载平衡等。
  • 执行路由,调解,转换等

可以找到一些示例用例here。请注意,它们来自AdroitLogic的开发人员站点,并严格与AdroitLogic的ESB UltraESB配合使用。