Post #591

В схеме из поста приведена двойная классификация: с одной стороны, по книге "Паттерны интеграций корпоративных приложений" (Enterprise Integration Patterns, EIP) Грегора Хопа и Бобби Вульфа, там перечислены такие стили интеграции ("известные на момент написания этой книги", т.е. на 2003 год): - Передача файла - Общая база данных - Удаленный вызов процедуры - Обмен сообщениями Собственно, авторы довольно быстро подводят к выводу, что стиль "обмен [асинхронными] сообщениями" самый лучший, и дальше всё разбирается в основном в отношении него. Хотя, конечно, многие паттерны довольно универсальны, т.к. представляют собой решения проблем, возникающих в любом проекте интеграций, безотносительно технологии, по которой он сделан. Основанием для классификации в данном случае выступает природаканала, через который производится обмен, куда пишется сообщение: в файл на диске; в базу данных; никуда не пишется, а пакуется в TCP-пакет и летит по сети; или в промежуточную очередь/шину (в широком смысле — MOM: Message Oriented Middleware). Это всё логические абстракции, обусловленные программной обвязкой: строго говоря, база данных — это тоже набор файлов, как и журналы Кафки, например. Да что там, сокет TCP для операционной системы тоже файл, никакой разницы. В основе своей всё — файловый обмен :)) Книга EIP немного касается содержания сообщений, выделяя такие: - Сообщение с командой - Сообщение с документом - Сообщение о событии - Запрос - Ответ (подтверждение, результат, исключение) При этом Хоп и Вульф не связывают типы сообщений и стили интеграции, хотя, конечно, есть определенное родство: напрмиер, передавать команды через файловый обмен можно, но это скорее редкость; а события чаще передают через асинхронный обмен сообщениями. Вторая классификация взята из книги Майка Амундсена и др. "Непрерывное развитие API" (Continuous API Management), написанной в 2018. В ней речь идёт не вообще об интеграции, а именно про API (сравните смещение ракурса за 15 лет!), и классификация стилей построена как раз на типах сообщений: что мы передаем и что ожидаем в ответ. В первой редакции отдельно про стили API не говорилось, они просто упоминались, как что-то известное. Во 2-й редакции — в 2021 году — появилась отдельная глава, там перечислены такие стили: - Туннельный (это RPC — выполнение команды на удаленном сервере) - Ресурсный (это "простой" REST, в первой редакции книги он называется "CRUD-over-HTTP") - Гипермедиа (это HATEOAS из REST'а: не просто содержание ресурса, а также и необходимые ссылки для работы с этим ресурсом, связанные с ним ресурсы и даже, возможно, какой-то воркфлоу/код для обработки) - Стильзапросов (это когда API предоставляет единую точку для выполнения произвольных запросов: GraphQL, SparQL, поисковые запросы через HTTP и т.п.) - Событийно-ориентированный стиль (это и паттерн "издатель/подписчик", и вообще любая реализация асинхронного обмена). Как можно видеть, обе классификации пересекаются, но не совсем. То, что у Хопа упомянуто вскользь (RPC), у Амундсена раскрыто в деталях (разные стили синхронного взаимодействия), и наоборот (асинхронный обмен сообщениями). Хуже того — мало кто знает, но у Хопа есть вторая книга: Enterprise Integration Patterns, Vol. 2: Conversation Patterns, вышедшая в 2019, не переведенная на русский, и содержащая как раз в качестве одного из паттернов тот же HATEOAS, например (в первой книге никаких упоминаний REST вообще нет, там сплошной SOAP). Идея второй книги примерно в русле Амундсена — да и написаны они, видимо, примерно в одно время: кроме технических моментов, связанных с синхронностью/асинхронностью, гарантией доставки, преобразования данных, маршрутизации и т.п. в интеграционных взаимодействиях ещё имеет значение их последовательность, "разговор", "conversation". У Хопа в второй части EIP появляются паттерны, обеспечивающие как раз этот разговор: оркестрация, хореография, гипермедиа, и новые паттерны, характеризующие стиль общения (например, поллинг и ретраи). В эту же сторону движется и OpenAPI Initiative со своим новым стандартом Arazzo Specification.