企业应用程序集成简介
本文是我们名为“ Spring Integration for EAI ”的学院课程的一部分。
在本课程中，向您介绍了企业应用程序集成模式以及Spring Integration如何解决它们。 接下来，您将深入研究Spring Integration的基础知识，例如通道，转换器和适配器。 在这里查看 ！
1.简介
这是Spring Integration课程的第一部分。 本部分向您介绍什么是企业集成模式以及如何将不同的策略应用于设计集成解决方案。 之所以要在本课程中获得这些模式的基础知识，是因为Spring Integration项目是基于这些模式设计的。 本课程的以下部分将进入Spring Integration项目，并显示有关如何应用这些模式的实际示例。
2.企业整合模式
Enterprise Integration Patterns是由65种设计模式组成的组，该模式在书中以相同的名称进行编译，并由Gregor Hohpe和Bobby Woolf于2003年编写。定义这些设计模式的目的是需要标准化程序和建立模型。为开发人员提供的参考，以处理建筑集成解决方案。
这组集成设计模式是经验丰富的开发人员多年来重新使用实践的结果，它们每个都描述了针对特定设计问题（与不同系统之间的通信有关）的基本解决方案。
一旦完成本课程，您将了解Spring Integration的API如何基于这些企业集成模式，因为其设计灵感来自于上本书中解释的概念。 第一篇教程将简要介绍这些概念，以使您在了解如何构建Spring Integration时熟悉它们。
3.整合策略
应用程序或系统之间的集成任务一直非常困难。 部分原因是应用程序可以用不同的编程语言编写（由于一个系统无法理解另一个系统，因此无法进行通信）或使用不同的数据格式（消息不兼容）。 多年来，为了解决这些问题并完成集成应用程序的挑战，已采用了不同的方法。 基本上有以下四种简要描述的策略：
文件传输
此策略涉及应用程序通过使用文件共享信息。 您可以具有一个或多个应用程序来生成包含信息的文件（生产者），而其他应用程序将使用此数据（消费者）。 要考虑的最重要的事情之一就是确定文件中的数据将采用哪种标准格式，因为所有涉及的应用程序都应该知道如何处理它。 最受欢迎的格式之一是XML的使用。
设置数据格式后，可能会有多个应用程序以不同方式使用该文件中的信息。 为此，使用方的应用程序将需要一个具有目标的拦截器，以转换生成文件的格式，从而使其可以适应应用程序的要求。
图1
主要优点是它使应用程序彼此分离。 消费应用程序不需要了解生产应用程序的内部。 拦截器将处理文件，因此只要它们保持相同的文件格式，任何涉及的应用程序中的更改都不会影响其他应用程序。
另一方面，这种方法通常会花费时间，因此如果您过于频繁地需要信息，则可能不是理想的选择。 某些应用程序可能需要尽快显示更新的信息。 在这种情况下，共享数据库可能是一个更好的选择。 要考虑的另一个方面是文件传输策略非常不安全，因为它不是事务性的，并且可能存在并发问题。
共享数据库
该解决方案基于具有存储所有需要共享的信息的中央数据库。 这样，如果您使用事务管理，则不同的应用程序将能够同时访问相同的数据。 通过使用相同的数据库，检索到的信息将保持一致并且是最新的。 而且，消费者可以快速访问信息，以确保您不会获取过时的数据。 如果使用文件传输，这将是您将要面对的缺点之一。
图2
但是，您必须记住，如果多个应用程序访问同一数据，则可能会出现性能问题。 某些应用程序可能被阻止，试图修改另一个应用程序锁定的数据。
在设计数据库架构时会发现另一个困难。 生成的模式应适合所有涉及的应用程序。 此外，您还必须考虑到架构中的任何更改都会影响它们。 如今，如果您决定使用像MongoDB或Apache Cassandra这样的NoSQL数据库，则可能不会成为问题，因为这些类型的数据库使用无模式数据结构。 考虑每种类型的优缺点超出了本教程的范围。
远程过程调用
在前面讨论的方法中，生产者产生信息（存储在文件或数据库中），其他人可以使用它。 但是，如果您需要根据共享数据与其他应用程序进行交互，该怎么办？ 这里存在一个问题，因为生产者不知道使用中的应用程序的内部。 您需要某种抽象机制。 这是远程过程调用的来源。
图3
远程过程调用由一个应用程序通过存根与另一个应用程序直接交互组成。 客户端通过本地过程调用调用一个存根（client stub），然后存根将消息发送到服务器，另一个存根（骨架）将在其中接收消息并调用服务器过程。
这种方法的缺点是应用程序紧密耦合，并且调用速度很慢。 这将我们带到了最后一个策略，即消息传递。
讯息传递
如果您需要在应用程序之间交换少量信息，则更适合使用消息传递 。 消息传递的最大好处是组件（生产者和消费者）是分离的。 生产者可以发送消息而无需知道对方在哪。 可能会有一个或多个消费者将收到该消息，但这与生产者无关。
图4
另一个重要功能是消息传递可以异步完成。 这意味着生产者可以发送消息并继续其逻辑，而不必阻塞以等待消费者返回响应。 消费者处理完消息并发送响应后，将通知生产者。
这种方法的主要缺点是它的复杂性，特别是在处理异步消息传递时。
企业集成模式的作者通常认为此策略是集成企业应用程序的最佳方法，而Spring Integration项目也基于该策略。 因此，本教程的其余部分将基于此策略。
基于这种策略的架构称为消息驱动架构。 下一节将说明其基本概念，在本课程中将广泛使用它们的基本概念。
4.消息驱动架构
消息驱动的体系结构是基于您在上一节中看到的消息传递策略的体系结构。 下面解释了构建此策略的基本概念：
- 消息 ：在应用程序之间或同一应用程序的不同组件之间共享的信息量。 该消息是一种数据结构，该结构由包含有关消息的元信息的标头和包含我们要共享的信息的正文组成。
- 生产者 ：创建（产生）消息并将其发送到消息通道的组件。 消息可以同步发送，因此生产者将阻塞其线程并等待，直到收到响应为止。 但是，如果处理可能需要一些时间，则有更好的选择。 生产者可以异步发送消息。
- 消息通道 ：消息通道是将生产者连接到一个或几个使用者的某种管道或队列。
- 使用者 ：从消息通道检索（消费）消息并对其进行处理的组件。 （可选）将响应发送回生产者。
这种消息驱动的方法松散地耦合了应用程序。 异步通信以一种应用程序不需要知道另一个应用程序是否处于活动状态的方式连接两个应用程序。 生产者可以发送消息而忽略它，继续自己的工作。 如果发送过程需要响应，将通知生产者以处理结果。
5.同步和异步通信
同步通信允许两个部分都处于活动状态的实时对话。 发送方发送消息，并等待接收方对其进行处理并返回响应。 当生产者需要立即响应以继续其任务时，这很有用。 这种类型的通讯有其缺点。 例如，如果接收方处理需要时间，则发送方需要完成的下一个任务将被延迟。 甚至更糟的是，消费者可能不活跃。 常见的解决方案是建立超时并在响应花费太多时间时进行处理。
异步通信允许两个部分解耦，每个部分可能在不同的时间起作用（接收方在发送时可能不处于活动状态）。 当发件人不需要立即响应时，这种方法很常见。 它将继续处理其任务，直到收到响应。 当接收器处理需要时间时，异步通信就足够了。
Spring Integration允许两种通信类型，每种通信都有其优点和缺点。 在本课程的以下教程中，您将了解如何实现这一目标，并能够确定在每种情况下哪一种更为合适。
翻译自: https://www.javacodegeeks.com/2015/09/introduction-to-enterprise-application-integration.html