在哪里可以找到有关企业服务总线（ESB）的用途和好处的信息？
我正在寻找以下信息：
- ESB解决的问题类型
- 替代ESB的选择，以及在它们之间进行选择时需要权衡的因素
- 作为开发人员构建与ESB兼容系统的要求
我希望得到比维基百科或供应商在线营销手册更详细的信息。最好能提供一些示例代码，以便了解如何利用ESB。从.NET或Java角度获得的信息将是最有用的。
谢谢。
企业服务总线的好处
31
- LBushkin
1
ESB的好处可以在这里找到一个非常简短的概述：http://javaenterpriseworld.blogspot.de/2014/02/benefits-of-esb.html 主要优点大致列举如下... - leon4
11个回答
22
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，尽管由于大多数优秀的ESB都设计为调用各种协议以及托管POJO，因此您不需要做太多工作来构建ESB兼容系统。尝试使您的代码异步化可能会很有价值。
例如，Apache Camel可能具有最简明的配置，这里是一个教程。
- Jamie McCrindle
7
三个关键优势：
- 总线提供了一种终端点相互连接的方式，而无需直接交流。它简化了终端点的通信，因为他们只需要遵循一个标准的通信接口，即总线。（这适用于任何技术总线，不仅仅是ESB） - ESB提供了一个单一的地方来获取一些关键的终端点指标：频率、可用性和性能。 - ESB倾向于提供多个通信接口。然而，开发人员只需要选择最容易从总线获取和接收数据的接口。
但是，请确保它们将为您的情况提供商业价值。拥有一个ESB会给您的企业增加另一层复杂性。理想情况下，您不应该根据少数应用程序选择它，而应该根据整个组织。整个组织应该只有一个生产ESB集群。
替代方案：
- 直接将事物连接到彼此，特别是如果通信协议相同。这对于简单的应用程序集群很好，并且不需要太多思考。然而，随着应用程序数量的增长，维护相互连接变得困难。 - 另一种选择是MQ实现。这将为您提供一种推送数据的方式，而不需要复杂的相互连接，但是您被迫只使用一个通信渠道。幸运的是，对于Java，他们有JMS标准。
实用性：
我已经阐述了可能的替代方案。它们一开始可能看起来很糟糕，但这并不意味着您不能从这样做开始。我个人编写的东西直接与远程进行交流，而不必通过ESB，以确保它能正常工作，而不必过多担心集成问题。
如果您没有ESB，则建议您尝试使用Mule进行开发，使用WebSphere ESB进行测试和生产。我倾向于使用两种遵循标准的产品，以确保我们让供应商诚实并确保您的开发人员遵守标准，从而防止意外的供应商锁定。
最终，只需回答以下问题：在长期运行中，增加一点复杂性以简化其他复杂性的时间是否值得成本？
- 总线提供了一种终端点相互连接的方式，而无需直接交流。它简化了终端点的通信，因为他们只需要遵循一个标准的通信接口，即总线。（这适用于任何技术总线，不仅仅是ESB） - ESB提供了一个单一的地方来获取一些关键的终端点指标：频率、可用性和性能。 - ESB倾向于提供多个通信接口。然而，开发人员只需要选择最容易从总线获取和接收数据的接口。
但是，请确保它们将为您的情况提供商业价值。拥有一个ESB会给您的企业增加另一层复杂性。理想情况下，您不应该根据少数应用程序选择它，而应该根据整个组织。整个组织应该只有一个生产ESB集群。
替代方案：
- 直接将事物连接到彼此，特别是如果通信协议相同。这对于简单的应用程序集群很好，并且不需要太多思考。然而，随着应用程序数量的增长，维护相互连接变得困难。 - 另一种选择是MQ实现。这将为您提供一种推送数据的方式，而不需要复杂的相互连接，但是您被迫只使用一个通信渠道。幸运的是，对于Java，他们有JMS标准。
实用性：
我已经阐述了可能的替代方案。它们一开始可能看起来很糟糕，但这并不意味着您不能从这样做开始。我个人编写的东西直接与远程进行交流，而不必通过ESB，以确保它能正常工作，而不必过多担心集成问题。
如果您没有ESB，则建议您尝试使用Mule进行开发，使用WebSphere ESB进行测试和生产。我倾向于使用两种遵循标准的产品，以确保我们让供应商诚实并确保您的开发人员遵守标准，从而防止意外的供应商锁定。
最终，只需回答以下问题：在长期运行中，增加一点复杂性以简化其他复杂性的时间是否值得成本？
- Archimedes Trajano
6
除了已经提到的网站外，你应该阅读这篇关于“除非必须，不要使用ESB”的文章"Don't use an ESB unless you absolutely have to"。它是由MuleSource的首席技术官撰写的，MuleSource是最受欢迎的开源ESB之一。这不完全是对你问题的回答，更多的是让你自己问一下“我是否需要ESB”。
- Robin
3
这里有一篇IBM的不错的三部曲关于ESB，它是基于概念的，对大多数供应商都适用。我在IBM网站上找到了很多有关ESB的好东西。在BizTalk网站上也有一些不错的信息、视频等。
- JP Alioto
1
我认为IBM有偏向ESB的倾向。我会对他们说的任何话持保留态度。 - duffymo
2
企业服务总线（ESB）是一种中间件软件架构，为更复杂的架构提供基本服务。例如，ESB包含了实现面向服务架构（SOA）所需的功能。从一般意义上讲，ESB可以被视为一种机制，可管理对应用程序和服务（特别是旧版本）的访问，以通过基于Web或表单的客户端前端向最终用户呈现单个、简单和一致的界面。
实质上，ESB为分布式异构后端服务和应用程序以及分布式异构前端用户和信息消费者所做的事情，正是中间件真正应该做的事情：隐藏复杂性，简化访问，允许开发人员使用通用的、规范化的查询、访问和交互形式，处理复杂的细节在后台。ESB吸引人的关键，也可能是它未来成功的关键，在于它能够支持根据业务要求驱动的增量服务和应用程序集成，而不是由可用技术所控制。
这些异构应用程序之间的集成对企业至关重要。不同的服务可能使用不同的数据格式和通信协议。服务的物理位置可以随意更改。所有这些约束意味着您的应用程序仍然紧密耦合在一起。ESB可以用来放松不同服务和服务消费者之间的这些耦合。
WSO2 ESB是一个功能齐全、企业级的ESB。它是基于Apache Synapse项目构建的，该项目使用了Apache Axis2项目。所有组件都是作为OSGi捆绑包构建的。
实质上，ESB为分布式异构后端服务和应用程序以及分布式异构前端用户和信息消费者所做的事情，正是中间件真正应该做的事情：隐藏复杂性，简化访问，允许开发人员使用通用的、规范化的查询、访问和交互形式，处理复杂的细节在后台。ESB吸引人的关键，也可能是它未来成功的关键，在于它能够支持根据业务要求驱动的增量服务和应用程序集成，而不是由可用技术所控制。
http://searchsoa.techtarget.com/definition/enterprise-service-bus
WSO2 企业服务总线(产品)
WSO2企业服务总线（ESB）4.7.0文档！WSO2 ESB是一个快速、轻量级、100%开源和用户友好的ESB，遵循Apache软件许可证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捆绑包构建的。
- Rashod Chamikara Bandara
1
没有任何理由使用ESB。不要这样做。这会增加不必要的复杂性。为什么要通过中间人来传输信息，而不直接传输呢？ESB的支持者会告诉你点对点是不好的，但一些从ESB到点对点的传输却很好。
- user671731
1
请看我的演示文稿 "选择困难症 - 如何选择正确的ESB"
我解释了何时使用ESB、集成套件或仅使用集成框架（如Apache Camel）。我还讨论了开源ESB和专有ESB之间的区别。
我解释了何时使用ESB、集成套件或仅使用集成框架（如Apache Camel）。我还讨论了开源ESB和专有ESB之间的区别。
- Kai Wähner
0
首先让我解释一下SOA。它是关于构建一个架构，作为一组可重用的软件模块，以“服务”的形式公开，并具有明确定义的接口。这些服务促进了松散耦合，并将其实现细节从客户端抽象出来。
如果每个组件直接调用服务，则SOA可能会变得混乱。因此，它具有以下常见问题。
- 如何找到使用哪些服务和不使用哪些服务？
- 如何找到使用特定服务的客户端？
- 如何在不中断现有服务的情况下滚动更新服务或公开新版本的现有服务？
- 如何为调用旧服务接口的旧客户端支持向后兼容性？
- 如何在所有服务的内部/外部流量中执行日志记录、审计、安全强制执行等操作？
ESB是上述问题的解决方案。ESB...
- 帮助带来秩序
- 可以严格执行企业政策
- 例如安全、限流、审计等应用一致
- 虚拟化服务端点
- 促进版本控制、灵活更新、HA/负载平衡等
- 执行路由、中介、转换等操作
一些示例用例可以在这里找到。请注意，它们来自AdroitLogic的开发者网站，并且严格与UltraESB（AdroitLogic的ESB）耦合。
- Rajind Ruparathna
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接