随着时间的推移，IT系统不断增长和发展，它们开始彼此分散开来。一家供应商的解决方案与另一家供应商的解决方案没有沟通。接下来你知道的是，你有一个完整的IT堆栈，只有你拥有它的所有这一事实才能将其连接起来。因此，需要有一种方法来组织这项技术“意大利面”，以避免重复工作，尤其是在实现和执行业务逻辑时。
*注意：以下是关于语义的争论：物理拓扑与逻辑拓扑、方法与架构与技术。以下解释旨在进行概述。
企业应用程序集成
企业应用程序集成（EAI）是解决所有这些异乎寻常的蔓延问题的一个解决方案，它是一种技术、工具和框架，用于实现应用程序之间基于消息的实时集成。这些消息是由单个应用程序内的更改或参数触发的。EAI是通过点对点和hub-and-spoke两种方式之一实现的。
点对点模型意味着每个应用程序都必须进行自定义，以便与其他应用程序和IT部件进行通信。这都是针对每个IT资产及其连接的每个资产进行自定义的。这也是一项非常繁琐的工作，而且可以理解，很容易出错。更复杂的是，随着时间的推移，随着基础设施和应用程序的更新，这种模型可能很难维护。
为了解决这个问题，有一种hub-and-spoke模型，在该模型中，应用程序和服务之间的连接由中央代理中心处理。连接中心与应用程序和服务的辐条可以单独维护。这使得应用程序本身更加集中，所有集成艺术都通过中枢和辐条处理。这种方法的主要缺点是中心的集中化。它成为系统和基础设施通信的单点故障。EAI集线器和扬声器模型中的所有集成在设计上都取决于集线器的功能。
企业服务总线
遵循EAI hub-and-spoke方法的是企业服务总线（ESB），这是一种在应用程序之间提供基于消息的抽象模块化服务的工具。
ESB还充当了一个中心枢纽，在这里所有这些模块化服务都可以共享、路由和组织起来，以便将应用程序和数据彼此连接起来。这是一个更好的EAI hub-and-spoke解决方案，但可能并不是最终解决方案，因为组织在增长、添加资产，并且需要在其所有属性和软件资源中提高速度。
到目前为止，您已经推测ESB看起来很像轮辐式模型。这是真的，但ESB具有一些非常独特的特性，这些特性使其在功能方面与众不同。
- ESB使用开放标准将自己呈现为服务。这样就不需要为每个应用程序编写唯一的接口。
- 集成服务可以在对应用程序进行最小更改的情况下进行部署。
- ESB依靠行业标准、开放协议和接口来简化新部署。
然而，典型的ESB部署通常会导致集中式体系结构，这显然是因为在hub-and-spoke模型中提到的用于托管和控制所有集成服务的位置。但是集中式ESB部署和体系结构带有严格的中央治理，这无助于提供更快、更自适应的解决方案，而这些解决方案是数字变换主动性。此外，ESB本身往往成为单片应用程序。
敏捷集成
到目前为止，我们已经讨论了集成本身——使一切协同工作的技术。那么，什么是敏捷集成？简而言之，这就是Red Hat如何看待互联系统的未来，以及它们如何支持您的it团队必须完成的真正工作，以实现繁荣，特别是随着变化的频繁发生。
Red Hat认为，传统的集成方法（由集中的团队控制单片技术）可能会阻碍分布式应用程序的开发和长期使用。像ESB这样的传统集成技术具有优先考虑安全性和数据完整性等优点，但它们也依赖于单个团队来定义整个企业的集成。
今天的松散耦合、云计算应用程序体系结构是通过敏捷的DevOps方法需要同样灵活和可扩展的集成方法。Red Hat对敏捷集成的看法是，这是一种连接资源的方法，它结合了集成技术、敏捷交付技术和云计算平台，以提高软件交付的速度和安全性。具体来说，敏捷集成包括将API等集成技术部署到Linux容器中，并将集成角色扩展到跨职能团队。敏捷集成体系结构可分为三个关键功能：分布式集成、，容器和应用程序编程接口。
