1. Книжка про интеграцию через системы обмена сообщениями. Годная.
2. Источник: http://www.enterpriseintegrationpatterns.com/
3. Стили интеграции
3.1. Общая БД
3.1.1. зло
3.2. Файлы
3.2.1. зло
3.3. RPI (remote procedure invocation)
3.3.1. зло
3.4. Messaging
3.4.1. добро
4. Паттерны
4.1. Messaging systems
4.1.1. Message channel
4.1.1.1. Вопрос
4.1.1.1.1. Как одна апликуха общается с другой посредством обмена сообщениями
4.1.1.2. Ответ
4.1.1.2.1. Соединить их с помощью Messaging Channel, в который одна прога будет писать, а другая - читать.
4.1.2. Message
4.1.2.1. Вопрос
4.1.2.1.1. Как проги, соединенные каналом, будут обмениваться кусками инфы?
4.1.2.2. Ответ
4.1.2.2.1. Запакуют инфу в мессаги, которые могут быть переданы в систему обмена сообщениями
4.1.3. Pipes and Filters
4.1.3.1. Вопрос
4.1.3.1.1. Как выполнить комплексную обработку мессаги, сохраняя независимость и гибкость?
4.1.3.2. Ответ
4.1.3.2.1. Использовать Pipes and Filters для разделения больших тасков на последовательность мелких, независимых шагов (Filters), которые соеденины каналами (Pipes)
4.1.4. Message router
4.1.4.1. Вопрос
4.1.4.1.1. Как сделать так, чтобы сообщения попадали на разные фильтры в зависимости от набора условий?
4.1.4.2. Ответ
4.1.4.2.1. Воткнуть специальный фильтр, Message Router, который хавает мессагу и пересылает ее в определенный канал в зависимости от набора условий.
4.1.5. Message Translator
4.1.5.1. Вопрос
4.1.5.1.1. Как системы могут использовать различные форматы данных при общении друг с другом с момощью мессаг?
4.1.5.2. Ответ
4.1.5.2.1. Использовать спец фильтр, Message Translator, между фильтрами или приложениями для трансляции данных в нужный формат
4.1.6. Message endpoint
4.1.6.1. Вопрос
4.1.6.1.1. Как прога присоединится к каналу, чтобы слать и получать мессаги?
4.1.6.2. Ответ
4.1.6.2.1. Заюзает MessageEndpoint, который это могёт
4.2. Messaging channels
4.2.1. Point-to-point Channel
4.2.1.1. Вопрос
4.2.1.1.1. Как вызывающий может убедиться, что только один получатель получит мессагу
4.2.1.2. Ответ
4.2.1.2.1. Отправить мессагу в канал Point-to-point, который доставляет мессагу только одному получателю
4.2.2. Publish-Subscribe Channel
4.2.2.1. Вопрос
4.2.2.1.1. Как сендеру заброадкастить мессагу всем заинтересованным получателям?
4.2.2.2. Ответ
4.2.2.2.1. Отправить мессагу в канал Publish-Subscribe, который доставит копию мессаги всем получателям
4.2.3. Datatype Channel
4.2.3.1. Вопрос
4.2.3.1.1. Как прога может отправлять данные так, чтобы получатель знал, как обработать данные
4.2.3.2. Ответ
4.2.3.2.1. Использовать отдельный Datatype Channel для каждого типа данных, чтобы все данные определенного типа передавались через данный канал.
4.2.4. Invalid message channel
4.2.4.1. Вопрос
4.2.4.1.1. Как получатель мессаги может gracefully обработать кривую мессагу?
4.2.4.2. Ответ
4.2.4.2.1. Должен отправить ее в Invalid Message Channel, спец. канал для кривых мессаг.
4.2.5. Dead Letter Channel
4.2.5.1. Вопрос
4.2.5.1.1. Что система обмена сообщениями должна делать с мессагами, которые не может доставить?
4.2.5.2. Ответ
4.2.5.2.1. Если система не может или уже не должна доставить мессагу, она может положить в Dead Letter Channel
4.2.6. Guaranteed Delivery
4.2.6.1. Вопрос
4.2.6.1.1. Как отправитель может убедиться, что мессага доставлена, даже если система обмена сообщениями упала?
4.2.6.2. Ответ
4.2.6.2.1. Использовать Guaranteed Delivery чтобы сделать мессагу персистентной, чтобы она не была потеряна, если СОС упадет
4.2.7. Channel Adapter
4.2.7.1. Вопрос
4.2.7.1.1. Как вы можете присоединить прогу к СОС, чтобы она могла получать и отправлять мессаги?
4.2.7.2. Ответ
4.2.7.2.1. Использовать Channel Adapter, которая может юзать API или данные приложения и отправлять мессаги с этими данными и наоборот, получать мессаги и делать вызовы API этого приложения или менять данные.
4.2.8. Messaging Bridge
4.2.8.1. Вопрос
4.2.8.1.1. Как несколько СОС могут быть соединены, чтобы мессаги, доступные в одной СОС, были доступны и в остальных СОС ?
4.2.8.2. Ответ
4.2.8.2.1. Использовать MessagingBrindge, чтобы реплицировать сообщения между СОС
4.2.9. Message Bus
4.2.9.1. Вопрос
4.2.9.1.1. Какая архитектура позволяет отдельным приложениям работать вместе, но без сильной связности, чтобы можно было добавлять и удалять приложения, не затрагивая остальные
4.2.9.2. Ответ
4.2.9.2.1. Использовать Message Bus, который позволяет прогам взаимодействовать друг с другом посредством обмена мессагами.
4.3. Message construction
4.3.1. Command Message
4.3.1.1. Вопрос
4.3.1.1.1. Как можно заюзать messaging для вызова процедуры в другом приложении?
4.3.1.2. Ответ
4.3.1.2.1. Использовать CommandMessage для надежного вызова процедуры в другом приложении
4.3.2. DocumentMessage
4.3.2.1. Вопрос
4.3.2.1.1. Как мессаги можно использовать для передачи данных между приложениями?
4.3.2.2. Ответ
4.3.2.2.1. Используйте Document Message для надежной передачи данных между прогами
4.3.3. Event Message
4.3.3.1. Вопрос
4.3.3.1.1. Как mrssaging можно заюзать для передачи событий от одного приложения к другому?
4.3.3.2. Ответ
4.3.3.2.1. Использовать EventMessage для надежной, асинхронной доставки уведомлений между приложениями.
4.3.4. Request-Reply
4.3.4.1. Вопрос
4.3.4.1.1. Когда прога отправляет мессагу, как она может получить ответ от получателя?
4.3.4.2. Ответ
4.3.4.2.1. Отправить пару сообщений (запрос и ответ), каждое по своему каналу.
4.3.5. Return Address
4.3.5.1. Вопрос
4.3.5.1.1. Откуда отвечающий узнает, куда слать мессагу с ответом?
4.3.5.2. Ответ
4.3.5.2.1. Мессага с запросом должна содержать Return Address, который и скажет, куда слать ответную мессагу.
4.3.6. Correlation Identifier
4.3.6.1. Вопрос
4.3.6.1.1. Как отправитель запроса узнает, к какому запросу относится полученный ответ?
4.3.6.2. Ответ
4.3.6.2.1. Каждый ответ должен содержать Correlation Identifier, уникальный идентификатор, указывающий на запрос.
4.3.7. Message Sequence
4.3.7.1. Вопрос
4.3.7.1.1. Как с помощью messaging можно отправить много данных?
4.3.7.2. Ответ
4.3.7.2.1. Разбить данные на куски переслать их в виде Message Sequence, пометив каждую мессагу из последовательности идентификационными полями.
4.3.8. Message Expiration
4.3.8.1. Вопрос
4.3.8.1.1. Как отправитель поймет, что сообщение должно быть рассмотрено как устаревшее и его уже не нужно обрабатывать?
4.3.8.2. Ответ
4.3.8.2.1. Установить Message Expiration для указания "срока годности" мессаги
4.3.9. Format Indicator
4.3.9.1. Вопрос
4.3.9.1.1. Как формат данных мессаги может быть спроектирован, чтобы сделать возможными будущие изменения?
4.3.9.2. Ответ
4.3.9.2.1. Спроектировать формат, который включает идентификатор формата
4.4. Message routing
4.4.1. Content-Based Routed
4.4.1.1. Вопрос
4.4.1.1.1. Как обработать ситуацию, когда реализация одной логической функции (e.g., проверка инвентаря) разделена между несколькими физическими системами?
4.4.1.2. Ответ
4.4.1.2.1. Использовать Content-Based-Router для маршрутизации сообщения корректному получателю на основе содержимого сообщения.
4.4.2. Message Filter
4.4.2.1. Вопрос
4.4.2.1.1. Как компонент может предотвратить получение ненужных ему сообщений?
4.4.2.2. Ответ
4.4.2.2.1. Использовать Message Filter, который ликвидирует нежелательные сообщения из канала на основе набора условий
4.4.3. Dynamic Router
4.4.3.1. Вопрос
4.4.3.1.1. Как вы можете избежать зависимости маршрутизатора от всех возможных пунктов назначения сохраняя его эффективность?
4.4.3.2. Ответ
4.4.3.2.1. Использовать Dynamic Router, router, который сам себя конфигурирует на основе специальных конфигурационных сообщений от участников-пунктов назначения.
4.4.4. Recipient List
4.4.4.1. Вопрос
4.4.4.1.1. Как мы направим мессагу получателям, определенным в динамически изменяемом списке
4.4.4.2. Ответ
4.4.4.2.1. Определить канал для каждого получателя. Далее используйте Recipient List для проверки входящего сообщения, определите список получателей, переслать сообщения на все каналы, ассоциированные с получателями из списка.
4.4.5. Splitter
4.4.5.1. Вопрос
4.4.5.1.1. Как обработать мессагу, если она содержит множество элементов, каждый из которых может быть обработан по-своему?
4.4.5.2. Ответ
4.4.5.2.1. Использовать Splitter для разбиения одной мессаги со списком элементов на несколько мессаг, каждая из которых будет содержать только данные из соответствующего элемента и обрабатываться отдельно.
4.4.6. Aggregator
4.4.6.1. Вопрос
4.4.6.1.1. Как скомбинировать результаты отдельных, но связанных сообщений так, чтобы они могли быть обработаны как едине целое
4.4.6.2. Ответ
4.4.6.2.1. Использовать фильтр с состоянием, Aggregator, собрать и хранить индивидуальные мессаги, пока не соберется полный набор. Далее Aggregator публикует одно сообщение на основе собранных отдельных сообщений.
4.4.7. Resequenter
4.4.7.1. Вопрос
4.4.7.1.1. Как получить поток связанных, но неупорядоченных сообщений в корректном порядке?
4.4.7.2. Ответ
4.4.7.2.1. Использовать фильтр с сотоянием, Resequenter, для сбора и пересортировки мессаг, чтобы отправить их в канал в определенном порядке.
4.4.8. Composed Message Processor
4.4.8.1. Вопрос
4.4.8.1.1. Как обслужить поток сообщений, содержащих множество элементов, каждый из которых может требовать специальной обработки?
4.4.8.2. Ответ
4.4.8.2.1. Использовать Composed Message Processor для обработки такой мессаги. Composed Message Processor разбивает мессагу на отдельные, направляет каждое из них на соответствующий пункт назначения и аггрегирует ответы в единое сообщение.
4.4.9. Scatter-Gather
4.4.9.1. Вопрос
4.4.9.1.1. Как обработать поток сообщений, когда каждое сообщение требуется отправить нескольким получателям, каждый из которых может отправить ответ?
4.4.9.2. Ответ
4.4.9.2.1. Использовать Scatter-Gather, который броадкастит мессагу нескольким получателям, а затем использует Aggregator для сбора ответов и объединения их в единое ответное сообщение.
4.4.10. Routing Slip
4.4.10.1. Вопрос
4.4.10.1.1. Как смаршрутизировать сообщение последовательно через несколько шагов обработки, когда последовательность шагов не известна во время проектирования и может изменяться для каждого сообщения?
4.4.10.2. Ответ
4.4.10.2.1. Прикрепить Routing Slip для каждого сообщения, определив последовательность шагов обработки. Обернуть каждый компонент в специальный message router, который считывает Routing Slip и направляет мессагу следующему компоненту из списка.
4.4.11. Process manager
4.4.11.1. Вопрос
4.4.11.1.1. Как переправить сообщение через несколько шагов обработки когда требуемые шаги могут быть не известны во время проектирования и могут быть непоследовательными?
4.4.11.2. Ответ
4.4.11.2.1. Использовать центральный элемент обработки, ProcessManager, который обслуживает состояние последовательности и определяет следующий шаг обработки на основе промежуточных результатов
4.4.12. Message Broker
4.4.12.1. Вопрос
4.4.12.1.1. Как разделить пункт назначения мессаги от отправителя, сохраняя основной контроль над потоком мессаг?
4.4.12.2. Ответ
4.4.12.2.1. Использовать Message Broker, который может получать сообщения из разных источников, корректно определять адресатов и направлять их в корректный канал.
4.5. Message transformation
4.5.1. Envelope Wrapper
4.5.1.1. Вопрос
4.5.1.1.1. Как существующие системы участвуют в обмене сообщениями, который требует соблюдение определенного формата собщений, таких как заголовок сообщения и шифрование.
4.5.1.2. Ответ
4.5.1.2.1. Использовать Envelope Wrapper для упаковки данных проги в подходящий формат, совместимый с инфраструктурой СОС. При получении сообщение можно распаковать.
4.5.2. Content Enricher
4.5.2.1. Вопрос
4.5.2.1.1. Как общаться с другой системой, если исходная система не имеет всех требуемых другой системой данных.
4.5.2.2. Ответ
4.5.2.2.1. Использовать специальный преобразователь - Content Enricher, чтобы получить доступ к внешнему источнику данных и дополнить сообщение недостающей информацией
4.5.3. Content Filter
4.5.3.1. Вопрос
4.5.3.1.1. Как упростить работу с сообщением, которое содержит множество элементов данных, если вам требуется только малая часть элементов, а не все.
4.5.3.2. Ответ
4.5.3.2.1. Использовать Content Filter для удаления неважных элементов данных из сообщения
4.5.4. Claim check
4.5.4.1. Вопрос
4.5.4.1.1. Как уменьшить объем данных в сообщениях, пересылаемых между системами без потери содержимого?
4.5.4.2. Ответ
4.5.4.2.1. Хранить данные сообщения в хранилище и передавать в сообщении Claim Check (квитанцию), которую получатели смогут использовать для получения хранимой информации.
4.5.5. Normalizer
4.5.5.1. Вопрос
4.5.5.1.1. Как обрабатывать сообщения, которые семантически эквивалентны, но приходят в различных форматах?
4.5.5.2. Ответ
4.5.5.2.1. Использовать Normalizer для перенаправления сообщений через кастомный транслятор сообщений, который преобразует сообщения в единый формат.
4.5.6. Canonical Data Model
4.5.6.1. Вопрос
4.5.6.1.1. Как минимизировать зависимости между интегрируемыми приложениями, использующими различный формат данных?
4.5.6.2. Ответ
4.5.6.2.1. Прежде всего, спроектировать Cananical Data Model, независимую от конкретных приложений. Далее требовать от каждого приложения поддержки Cananical Data Model.
4.6. Messaging endpoints
4.6.1. Messaging gateway
4.6.1.1. Вопрос
4.6.1.1.1. Как отделить доступ к СОС от остальных частей приложения?
4.6.1.2. Ответ
4.6.1.2.1. Использовать Message Gateway, класс, который оборачивает messaging-specific методы, а наружу выставляет domain-specific методы
4.6.2. Message Mapper
4.6.2.1. Вопрос
4.6.2.1.1. Как передавать данные между доменными объектами и инфраструктурой СОС, сохраняя их независимость друг от друга?
4.6.2.2. Ответ
4.6.2.2.1. Создать Message Mapper, который содержит логику отображения между доменными объектами и сообщениями. При этом ни доменные объекты, не элементы инфраструктуры СОС не должны знать о нем.
4.6.3. Transactional Client
4.6.3.1. Вопрос
4.6.3.1.1. Как клиент может контролировать свои транзакции с СОС?
4.6.3.2. Ответ
4.6.3.2.1. Использовать Transactional Client - сделать сессию работы клиента с СОС транзакционной, так что клиент сможет определять границы транзакции
4.6.4. Polling Consumer
4.6.4.1. Вопрос
4.6.4.1.1. Как приложение может потребить сообщение в момент, когда приложение будет к этому готово?
4.6.4.2. Ответ
4.6.4.2.1. Приложение должно использовать Polling Consumer, к которому обращается, когда хочет получить сообщение.
4.6.5. Event-Driven Consumer
4.6.5.1. Вопрос
4.6.5.1.1. Как приложение может автоматически потребить сообщение, когда оно становится доступным?
4.6.5.2. Ответ
4.6.5.2.1. Приложение должно использовать Event-Driven Consumer, с помощью которого будет автоматически обрабатывать сообщения, когда они будут доставлены по каналу.
4.6.6. Competing Consumers
4.6.6.1. Вопрос
4.6.6.1.1. Как может messaging client обработать несколько сообщений одновременно?
4.6.6.2. Ответ
4.6.6.2.1. Создать несколько Competing Consumers на одном канале, чтобы они могли обрабатывать сообщения одновременно
4.6.7. Message Dispatcher
4.6.7.1. Вопрос
4.6.7.1.1. Как скоординировать работу нескольких потребителей на одном канале?
4.6.7.2. Ответ
4.6.7.2.1. Создать Message Dispatcher, который будет потреблять сообщения с канала и распределять их по обработчикам.
4.6.8. Selective Consumer
4.6.8.1. Вопрос
4.6.8.1.1. Как потребители могут выбрать сообщения, которые они хотят получать?
4.6.8.2. Ответ
4.6.8.2.1. Используют Selective Consumer, который будет фильтровать сообщения, полученные по каналу в соответствием с критериями фильтрации.
4.6.9. Durable Subscriber
4.6.9.1. Вопрос
4.6.9.1.1. Как подписчик может предотвратить потерю сообщений, пока не слушает их?
4.6.9.2. Ответ
4.6.9.2.1. Использовать Durable Subscriber, чтобы СОС сохраняла сообщения, пока подписчик отключен.
4.6.10. Idempotent Receiver
4.6.10.1. Вопрос
4.6.10.1.1. Как получатель будет справляться с дублирующимися сообщениями?
4.6.10.2. Ответ
4.6.10.2.1. Надо спроектировать получателя как Idempotent Receiver, чтобы он спокойно обрабатывал ситуации, когда получает одно и то же сообщение несколько раз
4.6.11. Service Activator
4.6.11.1. Вопрос
4.6.11.1.1. Как спроектровать сервис, который можно будет вызывать как с помощью обмена сообщениями, так и с помощью других подходов?
4.6.11.2. Ответ
4.6.11.2.1. Спроектировать Service Activator, который соединяет сообщения, полученные по каналу с сервисом.
4.7. System management
4.7.1. Control Bus
4.7.1.1. Вопрос
4.7.1.1.1. Как эффективно администрировать СОС, распределенную по разным тачкам?
4.7.1.2. Ответ
4.7.1.2.1. Использовать Contril Bus для управления. Control Bus использует те же механизмы обмена сообщениями, что и приложения, но использует отдельные каналы для передачи данных, которые важны для управления компонентами, вовлеченными в поток сообщений.
4.7.2. Detour
4.7.2.1. Вопрос
4.7.2.1.1. Как смаршрутизировать сообщение через несколько промежуточных шагов для выполнения валидации, тестирования или отладки?
4.7.2.2. Ответ
4.7.2.2.1. Сконструировать Detour (объезд) с маршрутизацией на основе контекста, управляемой с помощью Control Bus. В одном состоянии рутер направляет входящие сообщения через дополнительные шаги.
4.7.3. Wire Tap
4.7.3.1. Вопрос
4.7.3.1.1. Как проверить сообщения, передаваемые по каналу point-to-point?
4.7.3.2. Ответ
4.7.3.2.1. Вставить простой RecipientList, который публикует будет публиковать сообщение в дополнительный канал.
4.7.4. Message History
4.7.4.1. Вопрос
4.7.4.1.1. Как эффективно анаоизировать и отлаживать поток сообщений в слабо связной системе?
4.7.4.2. Ответ
4.7.4.2.1. Прежде всего, приаттачить Message History к сообщению. Message History - это список всех приложений, через которые сообщение прошло с момента создания
4.7.5. Message Store
4.7.5.1. Вопрос
4.7.5.1.1. Как делать отчеты на основе информации из сообщений без нарушения слабо связной и transient природы СОС?
4.7.5.2. Ответ
4.7.5.2.1. Использовать Message Store для сохранения информации о каждом сообщении в одном месте.
4.7.6. Smart Proxy
4.7.6.1. Вопрос
4.7.6.1.1. Как отследить сообщения на сервисе, который публикует ответы на Return Address, указанный отправителем?
4.7.6.2. Ответ
4.7.6.2.1. Использовать SmartProxy для сохранения адреса оригинального отправителя и его замены на адрес Smart Proxy. Когда сервис отправит ответ, перенаправить его на оригинальный обратный адрес.
4.7.7. Test Message
4.7.7.1. Вопрос
4.7.7.1.1. Что произойдет, если компонент активно обрабатывает сообщения, но из-за внутренней ошибки выдает некорректные ответы (ответы идут нормально, без задержек, но могут содержать ошибочные данные)?
4.7.7.2. Ответ
4.7.7.2.1. Использовать тестовое сообщение, чтобы убедиться в том, что обработчики сообщений работают нормально.
4.7.8. Channel Purger
4.7.8.1. Вопрос
4.7.8.1.1. Как прочистить канал без шатания тестов или запущенных систем?
4.7.8.2. Ответ
4.7.8.2.1. Использовать Channel Purger для удаления нежелательных сообщений с канала.