ESB和EAI技术之间的区别是什么？

　　在我最新一篇关于成功使用ESB文章发表之后，收到了很多反馈，基于这些反馈以及LinkedIn上SOA兴趣组关于 “进行ESB还是不进行是个问题” 的论点，我认为探讨一下ESB和EAI技术是很有用的。

　　EAI或者企业应用集成在ESB被发明出来之前就存在很久了，这些技术旨在为管理点对点集成蔓延提供一种手段，这种集成蔓延经常以连接不同的系统之间出现，变得越来越重要。EAI技术允许这些集成集中管理，甚至是促成一个企业部门，像集成能力中心（ICC）或者集成卓越中心。不幸的是，很多EAI技术由于集中化兼并了所有集成逻辑而遭遇了性能问题，因为这样做十分复杂。

　　ESB技术是随着SOA到来的。尽管一些ESB产品是全新的，也有相当一部分是EAI产品重新包装变成ESB。这就对于客户造成了一些困扰，正如一些案例中，企业不但有遗留集成产品，也有ESB、XML设备和Web服务管理产品，他们提供的功能都是重叠的。当BPM技术开始得到关注时，就变得更为复杂了，正如很多EAI工具以同样的方式利用图形化建模环境进行集成自动化，BPM工具为流程编制提供了图形化建模环境。那么我们如何理清这些呢？

　　首先，集成仍是必须的，而且一直都需要。尽管最佳路径仍旧是构建一个包含集成的系统，都使用统一的接口，有时这是不可能的。例如，你可能有两个第三方的系统，每一个都有自己的引入和输出集成技术。如果这两个不能立即兼容，他们可能不会兼容，你唯一的选择就是在二者之间放点东西进行集成。即使一端有固定的集成接口，在中间，你仍旧需要一些东西，因为你并不希望所有的系统都使用私有接口。

　　其次，记住必须开发集成逻辑。即使“语言”是图形化环境，也不应该被认为是配置实践，就像配置防火墙或者是负载均衡器那样配置。这也正是我上一篇文章一再强调的内容。技术迈向开发人员可能也会促进运营策略管理和加强。技术如果面向运营人员可能就是很好的策略管理和加强，但是紧密配合开发集成逻辑。

　　第三，理解技术的重叠领域，所以仍旧可能是购买了单一的技术。厂商构建了这种重叠，因为不是每一个公司都想在集成任何东西到任何EAI上花费数百万。然而，他们可能对于某个具体的单一ERP系统仍有集成需求。尽管ESB可能不具备遗留EAI工具的所有集成功能，但是可能对于很多场景十分有效。

　　你需要避免什么呢？尽管这是一个单一的ESB部署，试图解决所有的服务交互以及集成逻辑的运营策略。在策略非故意修改、错误配置时或者是由于糟糕的责任分离，注定要面对性能瓶颈和运营风险。

　　我有两个建议：

　　第一，如我上一篇文章所述，尝试维护业务和集成逻辑以及配置运营策略之间的独立性，尽管使用同样的技术也要分离。这可能意味着要有分离的技术实例。

　　第二，部署技术是为某处的运行时策略加强和集成逻辑负责，他们可能只处理受这些策略或者逻辑支持的流量。如果消息进入和离开你的ERP系统需要集成逻辑，在ERP系统之前放置ESB或者EAI，但是不能允许ESB为其他不包含在ERP系统进行简单WEB服务交互的应用处理流量。如果对于所有防火墙之外的web服务需求有一个流量控制的策略加强，对这些策略使用单一ESB或者是服务网关，但是不要和只适用于这些消息自己的集成逻辑混合。把这个逻辑放在其他实例中，或者甚至是其他更适合这项任务的技术中。