什么是ESB，有什么好处？
在以前的工作中，有很多关于“企业服务总线”（ESB）的讨论。 我阅读了关于它的概念性书籍的一些部分，但从来没有真正理解你将如何实现/整合它的具体条款。 我熟悉SOA /排队/目录服务/等。 但是我不明白ESB到底是什么。
它是一个具体的事情（服务/服务器/经纪人/等），你只需要以不同的方式将所有的应用程序挂接到它上面，还是更简单地devise系统的概念方式？
任何解释或链接到良好的例子将不胜感激。 谢谢。
这是一个相当高层次的抽象概念。 其核心概念是ESB提供的中间件和接口允许企业连接他们的应用程序而无需编写代码。
这可能包括调解协调不兼容的协议，数据和交互。
所有事物都经过中央公共汽车的想法给了额外的抽象层。 使用行业标准将其他应用程序，客户端等“插入”该总线，使得连接新服务，数据源，不同需求的客户端相对容易。
实际的实现
就实际实施而言，这是大型企业支持业务的领域。 虽然这很stream行，但我们的目标是通过与互联网相比，在一定程度上可以理解的理想：
与Internet相似
一个大的通信总线，具有广泛的用途和数据，但都运行标准化的协议。
实际上，人们可以写一个HTTP到FTP连接器，允许浏览器访问FTP站点，而不用调用一个FTP客户端（通常内置在浏览器中）。
混搭
Mashups演示了一个有趣的实现 – 从旧金山权威，从谷歌地图和寿司酒吧位置从雅虎的一些巴士路线数据与评级和运行一个简单的查询，给你最亲密的寿司吧，加权，所以你会愿意为了更好的酒吧进一步旅行。
所有完全不同的服务本身是不兼容的，但是使用标准连接器（例如雅虎pipe道），它们可以被拉到一起成为一个有凝聚力和有用的整体。
-亚当
免责声明：我为IBM工作，并咨询了WebSphere ESB，这是一个IBM产品，专门用于构buildESB。 以下是我的观点，并不一定反映IBM的立场。
不幸的是，ESB对于不同的人来说是不同的。
对我来说，ESB是一种可以插入SOA（面向服务的体系结构）的技术，允许将不同的系统连接在一起。 它经常执行协议转换，消息修改，路由，日志logging，充当安全网关等function。 例如，您可以使用ESB将以前仅作为Web服务提供的服务公开为基于JMS的服务。
在这方面，ESB实现（或者更准确地说，出售来构buildESB的软件 – 例如我所咨询的）通常在技术上与以前被称为消息传递或排队代理的类似，尽pipe目的有些不同因为（正如首字母缩写所暗示的那样）是围绕着服务而非将消息从一个地方移动到另一个地方。 这个区别在技术上有多重要是一个意见。
我在商业ESB方面的经验是，这是一种夸张而昂贵的技术，会造成尽可能多的问题。 ESB将连接新的系统和传统，消息将通过总线飞行，一切都可以无缝地与其他任何事物进行通话。 投入一些弹性，编排，你有一个非常强大的企业应用软件。
当你尝试使用它们的时候，问题就来了，总线的编写开销，创build消息结构等等，都可能超过这个好处。 作为一个成本高昂的项目，ESB被看作是所有技术问题的万能药，而不是在公共汽车上花费太多时间，而不是在连接应用程序/数据上。 通常情况下，多个竞争标准将在同一个组织中争夺领先地位，导致这些系统应该实际上正在解决的经典技术主导孤岛。
恕我直言，它是好得多使用创buildless量的特定接口，通常使用Web服务之间只有那些需要它的系统。
这基本上是devise一个系统的一个概念性的方式 – 软件公司试图通过坚持ESB贴纸和pipe理者来推销你，因为ESB从“更高层次”看起来不错。
ESB基本上是一个MOM（面向消息的中间件），增加了数据模型和结构定义pipe理。 您可以为该总线上的所有应用程序和适配器（可以是带有共享XSD的XML）的公共数据定义。 任何连接必须发送它的信息坚持这个数据定义。 ESB支持加载，共享和版本化这个通用数据定义。 将新组件连接到ESB时，与将其连接到MOM相比，您可以期望获得更多的“兼容性”。 该总线上的每个组件在概念上都被视为“资源” – 所以引入了一个额外的抽象来将发送者与接收者分开。
例如：假设您想要在标准的面向消息的中间件中将应用程序A与应用程序B连接起来，我们来看看JMS。 你和你的同事讨论应用B，同意一个主题，消息types和字段并发送它（伪代码）：sendJms（“TRADE.MSFT”，{MapMessage trader =“pete”price = 101.4 vol = 100}）
如果你在面向服务的体系结构中做同样的事情，你需要
- 安装附加软件
- 学习了很多新的概念
- 在ESB的admin gui中定义你的新Java组件
- 实现一些由ESB控制的接口
- sendJms（getDestination（），{MapMessage trader =“pete”price = 101.4 vol = 100}） – 注意目标是从ESB
第一次可能有点痛苦，但我想你可以习惯了，就像你可以习惯EJB一样;-)
你可以说，一个MOM系统是“无types”（dynamic结构），而ESB是“键入”（静态结构）。 原始Messaging与ESB的权衡与其他无types/types的select类似：
- REST与SOAP
- 未经validation的XML与用XSDvalidation的XML
- Groovy与Java
- 解释型语言与编译型语言
对于较小的项目来说，很快就能够快速地分散出function（例如Groovy代码），但是对于大型项目来说，有一个debugging器（例如Java）是很好的事情，当事情破裂时就要提前警告，并且在人们承诺项目。
所以，如果你的项目遭受太多的人通过检查未经validation的更改而打破系统 – 朝向更多的结构（ESB而不是MOM）。 如果您的项目遇到没有及时完成的事情 – 请select更简单，无types的解决scheme。 如果是两个 – 找一个顾问（只是在开玩笑;-)
那么，这取决于你问谁呢？很多人会说，这是一个“中间件”，它将各种“业务逻辑”连接在一起，从而使这些模块之间的消息传递不了了。 我认为这是一个足够普遍的定义，但我相信你已经通过维基百科得到了那里，而不是。
那些拥有伟大的ESB拯救世界的人将会看到它是最常见的东西，它是一切事物的中心。 大多数ESB实现都是为了封装我们在商业软件中看到的所有重复性任务。 这意味着大多数ESB都会关心数据传输，安全性，日志logging，协议翻译，事件系统，通过Web服务的API暴露等。
我认为这是清楚的，我可以…希望有所帮助。
除了可以从维基百科获得的标准定义之外。 我发现它是连接多个平台和技术的遗留系统的好工具。 这也是构build分布式工作stream和状态pipe理系统（如总账）的好工具。
然而，维护和扩展相当昂贵，复杂和不方便，这使得它成为一个不好的技术select，成为扩展应用程序的通用工具。
看一下我的演讲“ 被选为宠儿 – 如何select正确的ESB ”。
我将解释何时使用ESB，Integration Suite或者只是一个集成框架（如Apache Camel）。 我还讨论开源和专有ESB之间的区别。
