В обзоре собраны краткие описания каждого компонента экосистемы, чтобы дать понимание – как выглядит мир Spring, и ориентиры – что из этого стоит изучить глубже и применять в проекте. Вторая часть обзора доступна по ссылке – «Обзор Spring-компонентов. Часть 2 – Spring Cloud». Принцип «искать нужно там, где потерял, а не там, где светло» кажется очевидным. И все же приходилось видеть, как участники смежного проекта два года бились в аналитическом параличе, выбрав неподходящие инструменты. Со временем, вопрос «что такое Spring» стал источником опасений – не приведет ли незнание экосистемы к выбору ошибочного решения и бесполезной трате ресурсов на изучение или использование в проекте. Перед структурированием компонентов, возник вопрос – на какой источник информации опираться. У Spring с этим творческий беспорядок – проекты в GitHub, реестр стартерных зависимостей, портал Spring Initializr, официальная документация – все источники противоречат друг другу. Решил опираться на документацию. В ней нет снятых с поддержки и экспериментальных проектов. Некоторые из 85 проектов включают несколько Spring-компонентов, поэтому их количество в обзоре – около сотни. Методика анализа стандартная – выявляем границы системы, компоненты верхнеуровневой структуры и их назначение. Поскольку человек может одновременно оперировать примерно семью сущностями, вводим промежуточную структуру – разделяем компоненты на типы, представленные в КДПВ. В обзоре собраны краткие описания каждого компонента экосистемы, чтобы дать общее понимание – как выглядит мир Spring, и ориентиры – что из этого стоит изучить глубже и, возможно, применить в проекте. В разрезе проектов, структура получилась такая: Компоненты Spring Boot приложений 1.1 Уровень интеграции компонентовSpring BootSpring Framework – Core1.2 Уровень бизнес-логикиSpring Framework – TestingSpring Framework – LanguagesSpring ShellSpring StatemachineSpring Batch Spring SecuritySpring SecuritySpring Security KerberosSpring Authorization Server 2. Уровень обмена данными с хранилищамиSpring Framework – Data AccessSpring LDAPSpring DataSpring Data CommonsПоддержка SQL БДSpring Data JPASpring Data EnversSpring Data RESTSpring Data JDBCSpring Data R2DBCSpring Data for Apache Solr (устарел)Spring Data JDBC Extensions (устарел) Поддержка NoSQL БДSpring Data MongoDBSpring Data ElasticsearchSpring Data RedisSpring Data Neo4jSpring Data for Apache CassandraSpring Data CouchbaseSpring Data LDAPПоддержка Grid-хранилищSpring Data for Apache GeodeSpring Data for VMware Tanzu GemFireИнтеграция с BigDataSpring for Apache Hadoop (устарел) 3. Уровень сетевого обмена даннымиSpring Framework – Web MVC (Web Servlet)Spring Framework – WebFlux (Web Reactive)Spring Framework – IntegrationSpring Web FlowSpring HATEOASSpring for GraphQLSpring Web ServicesSpring REST DocsMQ (Message Queue)Spring AMQPSpring for Apache Kafka 4. Фреймворк корпоративной интеграции Spring Integration  Чтобы увидеть все проекты можно развернуть раздел «Компоненты Spring Cloud приложений», обзор на который будет во второй части. Компоненты Spring Cloud приложений 5. Адаптация Spring Boot приложений к облачной средеSpring CloudSpring Cloud CommonsSpring Cloud OpenFeignSpring Cloud Circuit BreakerSpring Cloud SecuritySpring Cloud Schema RegistrySpring Cloud SleuthSpring Cloud ContractSpring Cloud ClusterSpring SessionSpring Session CoreSession-репозиторииSpring Session Data RedisSpring Session MongoDBSpring Session JDBCSpring Session HazelcastSpring Session for Apache Geode 6. Инфраструктурные сервисы, переносимые​ между облачными платформамиСервис с ролью GatewaySpring Cloud GatewayСервисы с ролью Config ServerSpring Cloud ConfigSpring Cloud VaultSpring Cloud BusСервисы с ролью Service DiscoverySpring Cloud Netflix (Eureka)Spring Cloud ZookeeperИнтеграция с Service MeshSpring Cloud Consul 7. Инфраструктурные сервисы, интегрированные​ в облачные платформы​ (клиенты подключения)Spring Cloud AlibabaSpring Cloud KubernetesSpring Cloud for Amazon Web ServicesSpring Cloud Azure (Microsoft)Spring Cloud GCP (Google)Spring Cloud for Cloud FoundrySpring CredHubSpring VaultSpring Cloud ConnectorsАдминистрирование приложений в облачных платформахSpring Cloud CLISpring Cloud SkipperSpring Cloud Pipelines (устарел)Сервисы администрированияс ролью Open Service BrokerSpring Cloud App BrokerSpring Cloud Open Service BrokerSpring Cloud – Foundry Service Broker (устарел) 8. Микро-фреймворки для разработки микросервисовSpring Cloud FunctionSpring Cloud StreamSpring Cloud Stream ApplicationsSpring Cloud TaskSpring Cloud Task App StartersОркестровка конвейеров из Stream и Task сервисовSpring Cloud Data FlowSpring Flo  Проект содержит пять разнородных компонентов:1.1 Классы автоконфигурации для всех компонентов Spring.1.2 Механизм загрузки и переопределения свойств для классов автоконфигурации.1.3 Родительский POM для maven (spring-boot-starter-parent).1.4 Плагин для maven (spring-boot-maven-plugin).1.5 Spring Boot Actuator. Назначение компонентов: 1.1. Классы автоконфигурации для всех компонентов Spring Это привычные классы конфигурации, содержащие условные аннотации. Если не выполняется прописанные в аннотациях условия, блокируется запуск bean-методов. Аннотации проверяют: Есть ли в проекте зависимость, требующая загрузки в контейнер Dependency Injection (DI) бинов этим классом автоконфигурации. Не отключен ли разработчиком запуск этого класса автоконфигурации, через аннотацию в классе конфигурации. Не переопределена ли разработчиком загрузка в DI отдельных бинов этого класса автоконфигурации, через ее реализацию в классе конфигурации. Не переопределены ли разработчиком свойства для настройки бинов, через любой из 12 источников свойств. И далее, класс автоконфигурации загружает бины в DI-контейнер по принципу «не навреди», отдавая приоритет настройкам разработчика. 1.2. Механизм загрузки и переопределения свойств для классов автоконфигурации Поддерживаются 12 источников загрузки свойств в порядке приоритета.  В том числе, этот компонент поддерживает третий принцип 12-факторных приложений – «Настройки, зависящие от развертывания, должны храниться вне сервиса». Spring Boot позволяет вынести, в виде properties файлов, до 2600 настроек на сервер конфигураций Spring Cloud Config. 1.3. Родительский POM для maven (spring-boot-starter-parent) Хранит информацию о версиях транзитивных зависимостей. Снимает необходимость указывать версии зависимостей в POM файле, автоматически подгружая совместимую. 1.4. Плагин для maven (spring-boot-maven-plugin) В дополнение к формированию стандартных WAR и JAR файлов, он позволяет: Создавать Fat JAR – включающие встроенный сервер. Создавать Thin JAR – без библиотек внешних зависимостей. Зависимости подгружаются на сервере, при первом запуске. Множество микросервисов могут переиспользовать зависимости из единого локального maven репозитория. Создавать Docker образы, в том числе многослойные. Многослойность теоретически позволяет ускорить сборку образа. Заявлено что, «медленно» собрав многослойный образ, далее, при минорных изменениях кода, можно будет быстро обновлять только один слой. Но тесты показывают, выигрыша нет. Второй «быстрый» этап выполняется в 6 раз медленнее, чем сборка полного образа штатными средствами Docker. Запускать код проекта на исполнение командой run непосредственно из maven, с формированием jar в фоне. Позволяет скачать из Git исходный код с вложенной maven-embedded  и запустить в системе, не требуя ничего, кроме установленного JDK. 1.5. Spring Boot Actuator Реализует функционал JMX через стандартный HTTP протокол. Включает коллекцию преднастроенных точек подключения. Взглянув на этот список, начинают странно восприниматься многие утверждения. «мы ведем разработку на Spring Boot» звучит как «мы возим тонны кирпичей на ключах от грузовика». Произнесенное с большой значимостью «мы используем Spring без Spring Boot» вызывает вопрос – стоят ли сакрализации лишние полсотни строк в классе конфигурации? Вопросы исчезают, когда выясняется что использование логически некорректных терминов стало частью маркетинговой стратегии. Они провоцируют поиск глубокого смысла, дают темы для конференций по «спринг-потрошению» и мотивируют создавать интернет-порталы по описанию Spring функциональности на человеческом английском. Используемые в этой статье термины «Spring Boot/Cloud приложения» тоже формально некорректны, но выбраны как устоявшиеся и продвигаемые разработчиками Spring. О документации Spring Boot: Стоит учесть, что в документацию Spring Boot вынесены произвольные части описания каждого из компонентов Spring. Поэтому документацию по компонентам есть смысл читать в комплексе с одноименными разделами Spring Boot. Например, загрузка в БД начальных данных из файлов JSON описана в Spring Data, а из файлов в формате SQL – в Spring Boot. Также, в документации Spring Boot есть раздел «How-to Guides» с рекомендуемыми шаблонами для использования различных компонентов Spring. Корневой компонент: 2.1. IoC Container – компонент для внедрения зависимостей (DI - Dependency Injection) и реализации концепции IoC (Inversion of Control, инверсия контроля). На Хабре более устоялся синоним «DI-контейнер». В этот контейнер Spring Boot загружает преднастроенные бины Spring-компонентов, а разработчик – бины с бизнес-логикой и логикой их взаимной интеграции (внедрения зависимостей). DI-контейнер сам выполняет внедрение зависимостей, обеспечивая «инверсию контроля». Вспомогательный функционал: 2.2. Resources – унифицированный интерфейс и его имплементации для абстрагирования доступа к низкоуровневым ресурсам через классы JDK – File, Files, Path, InputStream, ByteArrayInputStream и к ресурсам в ServletContext. 2.3. Validation и Spring Type Conversion – набор библиотек для валидации, преобразования типов и локализация форматов. 2.4. SpEL – язык выражений Spring. 2.5. Spring AOP – для организации проксирования методов, – выполнения дополнительной логики перед или после выполнения методов, обернутых прокси-объектами. В сравнении с полнофункциональными AOP-библиотеками, спроектирован по принципу 10% функциональности, закрывающей 100% типовых потребностей разработчика. Для нетиповых случаев предусмотрено подключение AspectJ. Использование Spring AOP включает два шага: Создать класс (прокси) с логикой, которая должна выполняться при вызове методов или возврате ответа из них. Создать класс сканирования, с условиями при которых методы должны оборачиваться прокси-объектами. Логика прокси-объекта может преобразовывать передающиеся данные, блокировать их передачу в метод или не затрагивать их, например, засекая время для измерения производительности или логируя факт передачи. Механизм сканирования позволяет массово применять дополнительную логику к произвольным методам приложения. Пример: авторизация доступа в Spring Security к методам классов бизнес-логики. 2.6. Аннотации для проверки на Null в IDE. 2.7. Кодеки сериализации и буферы данных. Функционал для юнит и интеграционного тестирования в Spring. Поддержка языков Kotlin, Groovy и семейства Dynamic Language (JSR-223). Компонент для разработки приложений с интерфейсом командной строки. Компонент для реализации в приложении концепции конечного автомата. Компонент для однотипной обработки больших массивов данных. Как правило, при запуске приложение считывает набор заданий из источника данных (БД, файлы XML, CSV и т.п.) и сохраняет результат обработки в то же или другое хранилище. Компоненты для авторизации, аутентификации и защиты от эксплойтов. Авторизация – разрешение или блокировка доступов на трех уровнях: уровень HTTP запросов, уровень методов в java классах, уровень отдельных записей БД. Аутентификация – проверка, к какой учетной записи и роли относится пользователь. Варианты реализации: 8.1. Username/Password – идентификация пользователя по логину и паролю. Form – с отправкой логина и пароля в теле запроса, Basic – с отправкой логина и пароля в заголовке запроса WWW-Authenticate, Digest – с отправкой одноразовой хэш-суммы на основе логина и пароля. 8.2. Remember Me – идентификация пользователя в разных сеансах. с хешированием токенов в cookie, с хранением токенов в БД или ином хранилище. 8.3. Анонимная аутентификация – позволяет явно задать ресурсы, доступные анонимам, и запретить неавторизованный доступ к оставшимся. Страхует от NullPointerException, когда перехватчик аудита запрашивает SecurityContextHolder чтобы определить, какой принципал отвечает за данную операцию. 8.4. Pre-Authentication – аутентификация внешними системами: по SSL-сертификату (X.509), по заголовку HTTP запроса (Siteminder), на уровне контейнера Java EE. 8.5. JAAS (Java Authentication and Authorization Service) - аутентификация средствами низкоуровневой структуры безопасности Java SE. 8.6. CAS (Central Authentication Service) – SSO-аутентификация (Single Sign-On – технология единого входа) на сервере CAS от компании Apereo. 8.7. X509 – взаимная аутентификация – проверка подлинности узла связи и проверки личности клиента на основе SSL-сертификата. 8.8. Run-As – поддержка выполнения пользователем некоторой логики от имени другого пользователя. 8.9. OAuth2 (компонент включает поддержку OpenID) – поддержка внешнего сервера аутентификации: OAuth 2.0 (например, GitHub), OpenID Connect 1.0 (например, Google). Внешним сервером аутентификации может быть и ваше Spring-приложение (пример). Токены JWT лучше, чем логин/пароль подходят для защиты межсистемных запросов. 8.10. SAML2 – протокол SSO-аутентификации на основе XML. Кроме аутентификации, реализованы: 8.11. Поддержка хранения учетных данных пользователей: в оперативной памяти, в реляционной БД, в LDAP. LDAP – тип специализированных БД со своим уникальным языком запросов. Они спроектированы для хранения информации о пользователях – логинов, хэшей паролей и пользовательских ролей. Также могут хранить ФИО, должности, адреса, телефоны и прочие данные пользователей. 8.12. Logout - функция для аннулирования аутентификации. Как организовать двухфакторную аутентификацию, аутентификация по географическому местоположению и т.п. в официальной документации не описано, но есть статьи на Baeldung.com. Только по Spring Security там 180 статей. Компонент для беспарольной аутентификации для Windows-пользователей, уже залогиненных под доменной учетной записью. Kerberos – протокол SSO-аутентификации, используемый в Windows Server (Active Directory). Компонент для создания поставщиков удостоверений OpenID Connect 1.0 и продуктов сервера авторизации OAuth2. Новый проект с версией 0.3.0. В модуле реализованы: 11.1. Transaction Management – компонент управления транзакциями. 11.2. DAO Support – компонент для перехвата исключений уровня DAO. Активируется аннотацией @Repository. 11.3. Spring JDBC – компонент для работы с реляционными БД через JDBC и jdbcTemplate. 11.4. Spring R2DBC – реактивный аналог Spring JDBC. 11.5. Spring ORM – компонент для работы с реляционными БД через произвольные имплементации JPA, включая Hibernate EntityManager, а также через Hibernate Session. 11.6. Spring OXM (Object-XML Mapping) – компонент для сериализации и десоциализации XML. Также используется синоним – маршаллинг. Аналог Spring JDBC для LDAP, с реализацией LdapTemplate (термин LDAP). Общий функционал всех Spring Data компонентов. Предназначен для унифицированного взаимодействия с SQL, NoSQL, LDAP и Grid хранилищами. Позволяет мигрировать между разными типами БД, не затрагивая код, меняя только maven зависимости. Основной функционал: 13.1. Repositories – включает: Коллекцию стандартных CRUD-запросов, в том числе с пагинацией. Единый язык запросов для разных типов БД (SQL, NoSQL, Grid). Механизм проброса запросов в ORM или БД на специфичном для них языке (JPQL, SQL и т.п.) Запросы на языке Spring Data формируются путем составления из ключевых слов имен java методов. При этом java методы должны расширять интерфейс CrudRepository или его наследников. Пример: List<Person> findByLastname – найти все Person с заданным значением в поле Lastname, OrderByFirstname – отсортировать по полю Firstname, Asc – тип сортировки «по возрастанию». Подробнее по ссылкам: Реестр ключевых слов Правила формирования имен методов и порядок их парсинга Дополнительный функционал: 13.2. Projections – запросы отдельных атрибутов объектов. Запросы могут формироваться тремя способами: Interface-based Projections – на основе дополнительного интерфейса, Class-based Projections – на основе DTO, Dynamic Projections – динамические. 13.3. Query by Example (QBE) – динамические запросы объектов, аналог Criteria. 13.4. Auditing – сбор информации, кто и когда создавал или изменял данные в БД. Компонент для работы с любыми реляционными БД. Поддержка Hibernate Envers – аудит, кто и когда создавал или изменял данные в БД. Реализация CRUD-операций с реляционными БД через REST API. Достаточно добавить entity-классы, и REST API сформируется для них автоматически. Использует REST запросы в HAL-формате (HAL – один из вариантов реализации HATEOAS). Компонент для работы с реляционными БД, без поддержки JPA, EntityManager, Lazy и кэширования. Позиционируется как простое решение для простых задач. Поддерживает MyBatis и все еще поддерживает Spring Data Commons. Не путать со Spring JDBC в модуле «Spring Framework – Data Access». Компонент для работы с реляционными БД через реактивные драйверы. Apache Solr – платформа полнотекстового поиска. Поддержка прекращена.  Рекомендован переход на Elasticsearch. Примечание: устаревшие, но поддерживаемые компоненты отражаются в обзоре, чтобы читателю не требовалось тратить время на изучение заведомо ненужных компонентов. Расширения для поддержки БД Oracle. Поддержка прекращена. Полезный функционал разнесен по другим компонентам Spring. Поддержка MongoDB – классическая NoSQL БД с динамическими схемами. Может хранить записи с произвольным набором атрибутов, без предварительного конфигурирования. Поддержка Elasticsearch – БД, ориентированная на полнотекстовый поиск. Поддержка Redis – БД, обычно используемая для организации кэша или очередей сообщений (MQ). Поддержка Neo4j – графовая БД, одна из самых зрелых и полнофункциональных. Поддержка Cassandra – распределенная БД – масштабируемая и отказоустойчивая. Поддержка Cassandra – конкурент MongoDB. MongoDB вышла раньше и занимает большую долю рынка. До 2020 года на Couchbase были жалобы на нестабильность. Какая БД лучше, в интернете много споров с взаимоисключающей информацией. Аналог Spring LDAP с поддержкой Spring Data Commons. In-Memory Data Grid (IMDG) или просто Grid – хранит в оперативной памяти непосредственно java объекты, в потокобезопасной Map (HashTable или ConcurrentMap). Такой способ хранения освобождает от необходимости использовать ORM. Функции Grid-сервера: Управляет кластерами хранилищ, позволяя их реплицировать, партиционировать (разделять данные по хранилищам в кластере) и сохранять данные на диск. Является точкой входа как для прямых запросов к Map, так и с помощью языка объектных запросов OQL (Object Query Language). Обеспечивает распределенные вычисления на основе хранящихся данных. Аналогично хранимым процедурам, PL-SQL и Transact-SQL в реляционных БД. Поддержка Apache Geode – полнофункциональной In-Memory Data Grid. Поддержка GemFire – коммерческой версии Apache Geode. Компонент для интеграции с Apache Hadoop – распределенной файловой системой, с поддержкой распределенных вычислений. Поддержка компонента скоро будет прекращена. Компоненты для обмена по сети данными с другими функциональными модулями: браузерами, фронтэнд и мобильными приложениями, собственными приложениями компании-разработчика, в том числе микросервисами, коробочными системами, поддерживающими интеграцию, коммерческими облачными сервисами. Включает компоненты: 31.1. Контроллер HTML – используется в связке с шаблонизаторами для формирования пользовательских web-интерфейсов. Шаблонизатор – компонент, загружающий данные из Java в HTML-шаблоны страниц пользовательского интерфейса. В документации заявлена поддержка около 15 технологий визуализации, в том числе, реализующие JSR-223. В Spring, шаблонизатор по умолчанию – Thymeleaf, но поддерживается и React. Учитывая, количество «воды» в документации по Thymeleaf, возникает мысль, не проще ли освоить синтаксис JavaScript и писать сразу на React (пример). В Java 8 движок JavaScript Nashorn, уже  встроен. В следующих версиях Java, – Nashorn можно подключить. 31.2. REST контроллер – используется для приема HTTP запросов и отправки ответов. Основные сценарии использования: обработки запросов фронтенда – приложений SPA (Single Page Application) на JavaScript, мобильных приложений и сайтов на других технологиях. Для не-enterprise систем, может реализовывать связь между микросервисами. Этот подход является базовым для Spring Cloud компонентов на основе Netflix. 31.3. Клиент REST (restTemplate) – используется для отправки HTTP запросов и приема ответов. Основные сценарии использования: скачивание данных с сайтов и тестирования REST сервисов. Примечание: в документации «Spring Framework – Web MVC», клиент REST только заявлен, но реализован и описан в модуле «Spring Framework – Integration». 31.4. WebSockets – протокол для двухстороннего канала связи на уровне TCP. Отказ от HTTP снижает накладные расходы, повышая пропускную способность сети. Но его применение обычно ограничено корпоративной сетью, так как требует определенных настроек сетевых устройств на всем пути передачи данных. 31.5. Поддержка устаревших фреймворков: JSF, Struts, Tapestry. Реактивный аналог модуля «Spring Framework – Web MVC». Включает компоненты: 32.1. Контроллер HTML – реактивный, 32.2. REST контроллер – реактивный, 32.3. REST клиент (WebClient) – реактивный, 32.4. WebSockets, 32.5. RSocket – реактивный аналог WebSockets. Включает компоненты: 33.1. Клиент REST (restTemplate) – в документации «Spring Framework – Web MVC» клиент REST только упомянут, но реализован и описан этом модуле (глава REST Endpoints). 33.2. Web Services – базовая поддержка устаревающих, но еще использующихся протоколов обмена данными на основе семейства XML (SOAP, XML-RPC). Активно вытесняется очередями сообщений (MQ – Message Queue). 33.3. EJB – интеграция с Enterprise JavaBeans. Старая, редко используемая технология. 33.4. JMS (Java Message Service) – поддержка брокеров сообщений, использующих протокол JMS для обмена данными через очереди сообщений (MQ). Ограничен поддержкой только java сервисов. Spring рекомендует для протокола JMS использовать брокеры ActiveMQ (classic) или ActiveMQ Artemis. С ними реализована наиболее плотная интеграция – конфигурирование через property файлы для реализации третьего принципа 12-факторных приложений. 33.5. JMX (Java Management Extensions) – протокол управления приложением. Позволяет на работающем приложении вызывать непосредственно методы классов для передачи в них данных (управление) или считывания информации (мониторинг состояния). Spring для его замены рекомендует использовать Spring Boot Actuator. 33.6. Email – компонент для отправки e-mail из Spring. 33.7. Task Execution and Scheduling – поддержка планирования и асинхронного запуска задач через Quartz Scheduler. 33.8. Cache Abstraction – кэш для java методов. Сохраняет в памяти пары значений «параметры вызова java метода и результат выполнения», перехватывает последующие запросы и ищет в памяти «готовый ответ», без выполнения метода. Для хранения пар запрос-ответ поддерживает: ConcurrentMap, Ehcache 2.x, Gemfire, Caffeine и реализации, совместимые с JSR-107 (например, Ehcache 3.x). Организует «поток пользовательских интерфейсов» в виде последовательности шагов. Расширение для контроллеров HTML и шаблонизаторов в модулях Web MVC и WebFlux. Расширение для Web MVC и WebFlux для поддержки формата сообщений HATEOAS в REST контроллерах. На просторах Хабра не удалось найти людей, умеющих извлекать пользу из этой технологии. Формально она помогает реализовать GRASP паттерн «Low Coupling», за счет усложнения формирования запросов. Расширение для Web MVC и WebFlux для поддержки формата сообщений GraphQL в контроллерах, WebSocket и RSocket. GraphQL – язык запросов для API, конкурирующий в REST. Позволяет одним запросом получить ограниченный набор полей из разных объектов предметной области. Это снижает нагрузку на сеть и сервер – уменьшает количество запросов и объем передаваемых данных. Недостатки GraphQL – не поддерживает кэширование и загрузку файлов. В приложении могут одновременно использоваться и REST, и GraphQL контроллеры. На мой взгляд, большую часть преимуществ GraphQL можно получить, используя только REST в паре с DTO (Data Transfer Object). А безальтернативен GraphQL в тех случаях, которые требуют использования динамических запросов к БД, например через Hibernate Criteria. Расширенная поддержка SOAP.Примечание: базовая поддержка реализована в компоненте «Spring Framework – Integration». Автоматической генерирует документацию Open API (Swagger) для REST API. Очереди сообщений (MQ) – современный способ надежной интеграции функциональных подсистем и обмена данными между микросервисами. От Web Services (SOAP) он отличается снижением трудозатрат на разработку интеграционных взаимодействий, а от REST – надежностью, отвечающей требованиям enterprise приложений. MQ поддерживают работу в рамках глобальных транзакций, одновременно включающих и JPA запросы к БД. Если в серии MQ и JPA запросов, при взаимодействии микросервисов,  произойдет сбой, состояние откатится транзакционными механизмами. К классу MQ относятся протоколы: JMS – реализован в «Spring Framework – Integration», поддерживает обмен только между java приложениями. AMQP – поддерживает приложения, написанные на разных языках. Kafka (свой уникальный протокол) – поддерживает приложения, написанные на разных языках, отличается высокой производительностью и масштабируемостью. AMQP (Advanced Message Queuing Protocol – расширенный MQ протокол). Отличается от JMS поддержкой приложений, написанных на разных языках. Для протокола AMQP, Spring рекомендует использовать брокер RabbitMQ, с которым реализована наиболее плотная интеграция – конфигурирование через property файлы для реализации третьего принципа 12-факторных приложений. По отзывам, от Kafka отличается меньшими требованиями к администрированию – при умеренных нагрузках «просто работает, не требуя внимания». Apache Kafka – самый популярный брокер сообщений. Поддерживает приложения, написанные на разных языках. Отличается рекордной производительностью и масштабируемостью. Предназначен для связи систем, использующих разные протоколы интеграции, и промежуточного преобразования данных.  Включает библиотеки для: обработки данных в XML, организации транзакций, авторизации доступа, обработки ошибок, тестирования, коллекцию из 30 интеграционных модулей, содержащих 92 адаптера. Код приложения взаимодействует с адаптерами через абстракцию Message. Роль адаптеров - преобразование Message в сообщение требуемого протокола и обратно. Поддерживаемые протоколы и типы данных: Web- TCP и UDP- HTTP- WebFlux- WebSockets- RSocket- Web Services- FTP/FTPS- SFTP- Mail- XMPP (интернет-чаты)- Feed Adapter (RSS и ATOM)- RMI Data- JDBC- R2DBC- JPA- Redis- MongoDb- Apache Geode (Grid)- Pivotal GemFire (Grid) Messaging- JMS- AMQP- Apache Kafka- ZeroMQ- MQTT – брокер издатель-подписчик для IoT- STOMP (Simple Text Orientated Messaging Protocol) – используется в WebSockets. Прочее- File- Resource- Stream – обмен данными между Java Stream в разных системах.- Spring ApplicationEvent- Zookeeper- JMX- Syslog – записи системного журнала других хостов. По отзывам, борьбу за популярность, этот фреймворк проиграл конкуренту - Apache Camel. В то же время, он стал основой для микро-фреймворка Spring Cloud Stream. В первой части обзора были представлены компоненты Spring Boot и фреймворка корпоративной интеграции. Во второй части будут описаны компоненты Spring Cloud. Наверняка среди читателей будут те, кто глубоко знает тот или иной компонент. Поправки и уточнения приветствуются.