max404.NET

Образцы подходов к передаче сообщений в сервисно-ориентированной архитектуре, Часть 1

Это первая из двух статей рассматривает образцы(patterns)подходов к передаче сообщений существующие на различных уровнях абстракции в сервисно-ориентированной архитектуре(SOA). Вместо того, чтобы явно декларировать как системы взаимодействуют через низкоуровневые протоколы и объектно-ориентированную архитектуру, SOA обеспечивает абстрактный интерфейс, посредством которого сервис может взаимодействовать с другими сервисами или приложениями используя слабосвязанную (часто асинхронную) модель коммуникации на основе сообщений.

Введение: Конфигурация процесса и тенденции гибкости

Потребность в гибкости процесса - далеко не новая тенденция. Эта тенденция была очевидна в течение прошлых двух десятилетий. Появились cети, Интернет и мобильные вычисления, что способствовало глобальному буму продуктивности, приводя к технологическим новшествам, которые постоянно образовывая фонд для обновления процессов индустриального века.

Эти решения сформированы прежде всего на системных или проприетарных платформах обмена сообщениями, нацеленных на обеспечение инфраструктуры интеграции и коммуникации между различными бизнес-компонентами. Типичный метод для доступа к этим системам - через широкий ассортимент предварительно подготовленных адаптеров, которые обеспечивают двунаправленную связь со многими типами прикладных процессов. Вместо того, чтобы явно объявлять, как системы взаимодействуют через низкоуровневые протоколы и объектно-ориентированную архитектуру, сервисно-ориентированная архитектура(SOA) позволяет предоставить абстрактный интерфейс, через который могут взаимодействовать процессы или сервисы. Это может представлено как взаимосвязанное предприятие на основе процесса, которое выставляет набор слабосвязанных, крупнозернистых сервисов.

Что такое SOA?

SOA - совокупность компонентов, удовлетворяющих бизнес-потребности. Она включает компоненты, сервисы и процессы. Компоненты - двоичные, имеют определенный интерфейс (обычно только один); сервис - группировка компонентов (выполнимых программ), необходимых для выполнения работы. Этот высший уровень разработки приложений обеспечивает стратегическое преимущество, облегчая сосредоточение на деловых требованиях.

SOA - не новый подход к программному дизайну; некоторые из базовых понятий SOA существуют в течение многих лет. Джес Томпсон, исследовательский директор в Gartner, утверждает, что основные понятия относятся к началу 1970-ых, когда исследователи начали обрисовывать границы вокруг программного обеспечения и обеспечения доступа к этому программному обеспечению только через четкие интерфейсы.

Сервис в основном осуществляется как крупнозернистый, поддающийся обнаружению программный объект, который существует как единственный экземпляр и взаимодействует с приложениями и другими сервисам через слабосвязанную (часто асинхронную) модель коммуникации на основе сообщений.

Самый важный аспект SOA - то, что она отделяет реализацию сервиса от его интерфейса. Потребители сервиса видят его просто как оконечную точку коммуникации, поддерживающую специфический формат запроса или контракт. Потребителю не важно, как выполняется сервис; единственное обязательное требование - то, что сервис посылает ответ назад потребителю в согласованном формате, указанном в контракте.

Объекты SOA

SOA состоит из различных объектов, конфигурированных вместе, чтобы поддержать парадигму нахождения, связывания, и выполнения (find, bind, and execute) как показано на рисунке 1.

Рисунок 1. Разъяснение SOA

Потребитель сервиса (Service Consumer)

Потребитель сервиса - приложение, сервис, или некий другой тип программного модуля, который запрашивает сервис. Это объект, который инициирует нахождение сервиса в сервисном реестре, осуществляет привязку к сервису по транспорту, и выполнение сервисной функции. Сервисный потребитель выполняет сервис, посылая ему запрос, отформатированный согласно контракту.

Поставщик услуг (Service Provider)

Поставщик услуг(сервиса) - адресуемый объект сети, который принимает и выполняет запросы потребителей. Это может быть универсальная система, компонент, или любой другой тип программной системы. Поставщик услуг публикует контракт в сервисном реестре для доступа потребителями сервиса.

Сервисный реестр (Service Registry)

Сервисный реестр - каталог на базе сети, который содержит доступные сервисы. Это объект, который принимает и сохраняет контракты от поставщиков услуг и предоставляет эти контракты интересующимся потребителям.

Сервисный контракт (Service Contract)

Контракт - это спецификация способа, которым потребитель сервиса будет взаимодействовать с поставщиком услуг. Он определяет формат запроса и ответа от сервиса. Сервисный контракт может требовать ряда предварительных и пост условий. Предварительные и пост условия определяют состояния, в которых должен находиться сервис, чтобы выполнить определенную функцию. Контракт может также определить уровни качества сервиса (QoS), спецификации для неконструктивных аспектов сервиса.

Аренда сервиса (Service Lease)

Аренда (время, в течение которого может быть удержано состояние), которую сервисный реестр предоставляет потребителю, является необходимой для поддержки сервисом, информации о состоянии привязки между потребителем и провайдером. Она предписывает свободную связь между потребителем и провайдером, ограничивая время, в течении которого они могут быть связаны. Без арендного договора, потребитель мог бы связавшись с сервисом однажды, никогда не перепривязываться к его контракту снова.

Обнаруживаемость и динамическая привязка:
Передача сообщений в SOA

SOA поддерживает понятие динамического обнаружения сервиса. Сервисный потребитель делает запрос сервиса сервисному реестру, и тот возвращает список всех поставщиков услуг, которые поддерживают требуемый сервис. Потребитель выбирает из списка наиболее подходящего поставщика услуг, и привязывается к нему, используя указатель из пункта сервисного реестра.

Потребитель форматирует сообщение запроса, опираясь на спецификации контракта, и привязывает сообщение к каналу связи, поддерживаемому сервисом. Поставщик услуг выполняет сервис и возвращает сообщение, которое соответствует определению сообщения в сервисном контракте.

Единственная зависимость между провайдером и потребителем - контракт, который обеспечивается сторонним сервисным реестром. Эта зависимость - только во время выполнения, а не во время компиляции. Вся информация нужная потребителю о сервисе получается и используется во время выполнения. Сервисные интерфейсы обнаруживаются динамически, сообщения также создаются динамически. Потребитель сервиса не знает формата сообщения запроса, или сообщения ответа, или местоположения сервиса, пока это не станет ему фактически необходимо.

Способность преобразовать сообщения даёт выгоду, позволения приложениям быть намного менее связанными друг с другом. Передача сообщений подводит фундамент под SOA; без передачи сообщений не было бы SOA.

Каталог образцов передачи сообщений в контексте SOA

Образцы(patterns) передачи сообщений существуют на различных уровнях абстракции в SOA. Некоторые образцы используются, чтобы непосредственно представить сообщение, или атрибуты транспортной системы передачи сообщений. Другие используются, чтобы представить создание сообщения, или изменение информационного содержания сообщения. Образцы также используются, чтобы обсудить сложные механизмы управления сообщениям. Образцы в передаче сообщений SOA могут быть разделены на следующие категории:
- Образцы типов сообщений. Описывают различные варианты сообщений, которые могут использоваться в SOA.
- Образцы каналов сообщений. Описывают фундаментальные атрибуты транспортной системы передачи сообщений.
- Образцы маршрутизации. Описывают механизмы направления сообщений между Поставщиком услуг и Потребителем сервиса.
- Образцы потребителей сервиса. Описывают поведение клиентов системы передачи сообщений.
- Образцы контрактов. Иллюстрируют поведенческую спецификацию, позволяющую поддерживать удобную коммуникацию между Поставщиком услуг и Потребителем.
- Образцы конструирования сообщений. Описывают создание содержания сообщений, которые путешествуют в системе передачи сообщений.
- Образцы преобразования. Изменение информационного содержания сообщений при передаче сообщений на уровне предприятия.

Рисунок 2. Каталог образцов передачи сообщений в контексте SOA

Образцы типов сообщений

Само сообщение - просто структура данных какого-либо рода - например строки, массив байтов, запись, или объект. Оно может интерпретироваться просто как данные, как описание команды, которая будет вызвана получателем, или как описание события, которое произошло в отправителе. Отправитель может послать сообщение-команду(Command Message), определяя функцию или метод на получателе, который желает вызвать. Он может послать сообщение-документ(Document Message), передавая структуру данных получателю. Или может послать сообщение-событие(Event Message), уведомляя получателя об изменениях.

Следующие образцы типов сообщений обычно используются в SOA.

Сообщение-команда (Command Message)

Проблема: Как вызвать процедуру в другом приложении?

Решение: Используйте сообщение-команду, чтобы надежно вызвать процедуру в другом приложении, как показано на рисунке 3.

Рисунок 3. Сообщение-команда

Взаимодействия: Сообщение-команда управляет другим приложением, или рядом других приложений, посылая специально отформатированное сообщение целевой системе. Сообщение-команда включает интеллектуальные инструкции, указывающие определенное действие, либо через заголовки и атрибуты, либо как часть содержания сообщения. Получатель выполняет соответствующее действие, указанное в сообщении. Сообщения-команды близко связаны с образцом Команда[9].

Сообщение-команда это просто обычное сообщение, которое, случается, содержит команду. Запрос Simple Object Access Protocol (SOAP) - сообщение-команда.

Сообщения-команды обычно посылают в двухточечном канале так, чтобы каждая команда была получена и вызвана только однажды.

Сообщение-документ (Document Message)

Проблема: Как Вы можете передавать данные между сервисами?

Решения: Использовать сообщение-документ, чтобы надежно передать структуру данных между приложениями.

Рисунок 4. Сообщение-документ

Взаимодействия: Сообщение-документ это просто одиночный блок информации, одиночный объект или структура данных, которая может быть разложена на меньшие блоки. Важная часть сообщения-документа - его содержание; документ. Это содержание восстанавливается демаршаллингом/десериализацией данных.

Сообщения-документы обычно посылают, используя двухточечный канал. В сценариях запрос-ответа, ответ обычно сообщение-документ, где возвращаемое значение - документ.

Сообщение-документ может быть сообщением любого вида в системе передачи сообщений. Сообщение ответа SOAP - сообщение-документ.

Сообщение-событие (Event Message)

Проблема: Несколько приложений хотели бы использовать уведомление о событии, чтобы координировать свои действия, и хотели бы использовать передачу сообщений, чтобы сообщаться с этими событиями. Как может использоваться передача сообщений, чтобы передать события от одного сервиса другому?

Решения: Использовать сообщение-событие для надежного, асинхронного уведомления о событиях между приложениями.

Рисунок 5. Сообщение-событие

Взаимодействия: Сообщение-событие расширяет модель Наблюдателя(Observer) на распределенные приложения. Сообщения-события можно посылать от одного сервиса другому, чтобы обеспечить уведомление о событиях жизненного цикла в пределах сервис-ориентированного предприятия, или для объявления о состоянии определенной деятельности. Приложения этого образца включают мониторинг предприятия и централизованную регистрацию(logging).
Важная особенность сообщений-событий в том, что они не требуют ответа.
Сообщение-событие может быть любым видом сообщения в системе передачи сообщений. Событие может быть объектом или данными типа документа XML.
"Если сообщение утверждает, что Курс акций для определенного 'символа' изменился, это - событие. Если сообщение предоставило информацию о 'символе', включая его новую цену, это - документ."

Сообщение запрос-ответ (Request-Reply Message)

Проблема: Сообщения двигаются в канале сообщений в одном направлении, от отправителя к получателю. Эта асинхронная передача делает поставку более надежной и отделяет отправителя от получателя. Проблема состоит в том, что коммуникация между компонентами часто должна быть двухсторонней. Когда один компонент уведомляет другой об изменениях, может потребоваться получение подтверждения доставки.
Может ли передача сообщений быть двухсторонней?

Решения: Послать пару сообщений запрос-ответ, каждый в его собственном канале.

Рисунок 6. Сообщение запрос-ответ

Взаимодействия: Запрос-ответ имеет двух участников:
- Запрашивающая сторона(Requester) (Потребитель сервиса). Посылает сообщение запроса и ждет сообщения ответа.
- Отвечающая сторона(Replier) (Поставщик услуг). Получает сообщение запроса и отвечает сообщением ответа.

Канал запроса может быть двухточечным каналом, или каналом публикации-подписки(publish-subscribe). Различие этих каналов в том, должен ли запрос быть передан всем заинтересованным сторонам или только единственному потребителю. Канал ответа, с другой стороны, является почти всегда двухточечным, потому что шировковещательные ответы обычно не имеют смысла.
Запрос походит на вызов метода. Ответ в этом случае может быть:
- Пусто
- Значение результата
- Исключение

Запрос должен содержать обратный адрес, чтобы сообщить отвечающей стороне, куда послать ответ. Ответ должен содержать идентификатор корреляции, который определяет, на какой запрос выдан этот ответ.

Образцы каналов передачи сообщений

Каналы(channels), также известные как очереди(queues), являются логическими тропами транспортировки сообщенй. Канал ведет себя как коллекция или массив сообщений, но "волшебным образом" разделен между множеством компьютеров и может использоваться одновременно множеством приложений.

Поставщик услуг - программа, которая посылает сообщение, записывая сообщение в канал. Потребитель получает сообщение от канала. Есть различные виды доступных каналов передачи сообщений.

Двухточечный(Point-to-Point) канал

Проблема: Отправитель посылает сообщение системе передачи сообщений, которая ответственна за его доставку конкретному получателю. Система передачи сообщений может доставить сообщение сразу (непосредственно входя в контакт с получателем), или хранить его, пока получатель не подключится.

Как Вы можете быть уверенными, что только один потребитель получит сообщение?

Решение: Послать сообщение посредством двухточечного канала, который гарантирует, что только один получатель получит конкретное сообщение.

Рисунок 7. Двухточечный канал

Взаимодействия: Двухточечный канал гарантирует, что только один потребитель получает любое указанное сообщение. Если канал имеет множество получателей, только один из них может успешно получить конкретное сообщение. Если множество получателей попытаются получить некое сообщение, канал гарантирует, что только один из них преуспеет, так что получатели не должны непосредственно координировать друг с другом. Канал может иметь множество потребителей, получающих многочисленные сообщения одновременно, но только единственный получатель потребляет конкретное сообщение.

Канал публикация-подписка (Publish-Subscribe)

Проблема: Поставщик услуг однократно, широковещательно передает событие всем интересующимся потребителям.

Решение: Переслать событие каналу публикация-подписка, который доставляет копию этого события каждому получателю.

Рисунок 8. Канал публикация-подписка

Взаимодействия: Канал публикация-подписка, который разработан на основе образца Наблюдателя(Observer)[9], и описывает единственный входной канал, который разбивается на множество каналов вывода - по одному для каждого подписчика. После публикации события в канал, это сообщение доставляется каждому из каналов вывода. Каждый канал вывода конфигурирован на взаимно-однозначной(one-to-one) топологии, чтобы позволить только одному потребителю получать сообщение. Событие считается потреблённым только тогда, когда были уведомлены все потребители.
Канал публикация-подписка может быть полезным для управления системами, отладки ошибок и тестирования различного уровня.

Канал типизированных данных(Datatype)

Проблема: Получатель должен знать, сообщения какого типа он получает, иначе не будет знать, как обработать их. Например, отправитель мог бы послать различные объекты типа заказов на поставку, ценовых квот(расценок), и запросов, но получатель вероятно предпримет различные шаги, чтобы обработать каждое из них, так что он должен знать, что есть что.

Решение: Использовать отдельный канал типизированных данных для каждого типа данных, так, чтобы все данные в конкретном канале имели одинаковый тип.

Рисунок 9. Канал типизированных данных

Взаимодействия: В любой системе передачи сообщений есть несколько отдельных каналов типизированных данных для каждого типа данных. Все сообщения в таком канале будут содержать один и тот же тип данных. Основаясь на типе данных, поставщик услуг посылает данные каналу, и потребитель получает их от канала соответствующего типа данных.

Канал мертвых писем(Dead Letter)

Проблема: При доставке сообщения возникает множество причин, приводящих к неудаче. Это могут быть проблемы конфигурации канала сообщения, проблемы с потребителями, или истечение срока годности сообщения.

Решение: Когда появляется любая проблема доставки сообщения, оно может быть перемещено в другой канал передачи сообщений, названный каналом мертвых писем.

Рисунок 10. Канал мертвых писем

Взаимодействия: Канал мертвых писем - отдельный канал, специализированный для плохих или недопустимых сообщений. В этом канале сообщения могут быть перенаправлены в основной канал или даже в отдельный канал для специальной обработки сообщения.

Гарантированная доставка

Проблема: Одно из основных преимуществ асинхронной передачи сообщений по RPC - то, что участники не должны быть online в то же самое время. В то время как сеть недоступна, система передачи сообщений должна использовать хранилище и механизм переадресовывания, чтобы гарантировать жизнестойкость сообщения. По умолчанию, сообщения сохраняются в памяти, пока они не могут быть успешно отправлены следующему пункту контракта. Этот механизм работает хорошо, когда система передачи сообщений работает надежно, но если система передачи сообщений терпит крах, все хранимые сообщения теряются. Как профилактическую меру, приложения используют постоянные носители, например файлы и базы данных, чтобы гарантировать восстановление после системных сбоев.

Решение: Использовать механизм гарантированной доставки, чтобы сделать сообщения постоянными(persistent).

Рисунок 11. Гарантированная доставка

Взаимодействия: При гарантированной доставке, система передачи сообщений использует встроенное хранилище данных (локальное дисковое пространство участвующего компьютера), чтобы сохранить сообщения в каждом участвующем компьютере, на котором установлена система передачи сообщений. Сообщение безопасно хранится, пока не будет успешно доставлено. Таким образом, обеспечивается гарантированная доставка.

Этот механизм гарантируемой доставки увеличивает системную надежность, но за счет производительности, поскольку задействует большое количество операций ввода-вывода и потребляет большое количество дискового пространства. Поэтому, если производительность или отладка/тестирование - приоритет, попробуйте избежать использования гарантированной доставки.

Шина сообщений (Message Bus)

Проблема: Предприятие состоит из различных независимых приложений, общающихся друг с другом унифицированным способом. Мы нуждаемся в архитектуре интеграции/сервисов, которая позволит этим приложениям координировать в слабосвязанной манере.

Решение: Структурировать соединяющее ПО между этими приложениями как шину сообщений, которая дает возможность им сотрудничать, используя передачу сообщений как показано в рисунке 12.

Рисунок 12. Шина сообщений

Взаимодействия: Шина сообщения - комбинация общей модели данных, общего набора команд, и инфраструктуры передачи сообщений, позволяющая различным гетерогенным системам общаться через общедоступный набор интерфейсов.

Шина сообщений может рассматриваться как универсальный соединитель между различными системами предприятия, и как универсальный интерфейс для клиентских приложений, которые желают общаться друг с другом. Шина сообщения требует, чтобы все приложения использовали одну и ту же каноническую модель данных. Приложения, добавляющие сообщения к шине, возможно, должны зависеть от маршрутизаторов сообщений, направляющих сообщения соответствующим конечным адресатам.

Образцы маршрутизации сообщений (Message Routing)

Почти все системы передачи сообщений используют встроенный маршрутизатор и, также, настраиваемую маршрутизацию. Маршрутизаторы сообщений - очень важные стандартные блоки для любой хорошей архитектуры интеграции. В противоположность различным образцам дизайна маршрутизации сообщений, этот образец описывает архитектурный стиль "hub-and-spoke" с немного специализированной внедренной логикой маршрутизации.

В поисках Правильного маршрутизатора

Важное решение для архитектора состоит в выборе соответствующего механизма маршрутизации. Образцы, которые помогут Вам принять правильное решение:
- Конвейеры и фильтр
- Маршрутизатор на основе содержания
- Накопитель содержания

Конвейеры и фильтр (Pipes and Filter)

Проблема: Как Вы можете разделить большую задачу обработки на последовательность меньших, независимых шагов обработки?

Решение: Использовать образец конвейеров и фильтров, чтобы разделить большую задачу обработки на последовательность меньших, независимых шагов обработки (фильтры), которые подключены к каналам (конвейерам, pipes)

Рисунок 13. Конвейеры и фильтр

Взаимодействия: Каждый фильтр выставляет очень простой интерфейс: он получает сообщения на входном конвейере, обрабатывает их, выполняя бизнес-преобразования, и публикует результаты в выходной конвейер. Конвейеры соединяют один фильтр со следующим, посылая сообщения от одного фильтра к следующему. Это очень похоже на вызов выполнения метода через передачу ему параметров и получение возвращаемого значения. Этот образец основан на образце 'цепочка ответственности'(Chain of responsibility)[11]. Поскольку все компоненты используют онинаковый внешний интерфейс, они могут быть составлены в различные решения, путем подключения компонент к различным конвейерам. Подключение между фильтром и конвейером иногда называют портом. В канонической форме, каждый компонент фильтра имеет один входной порт и один порт вывода.

Образец конвейеры и фильтры использует абстрактные конвейеры, чтобы разъединить компоненты друг от друга. Конвейер позволяет одному компоненту посылать сообщение в конвейер так, чтобы оно могло позже использоваться другим процессом, который неизвестен компоненту. Один из потенциальных недостатков архитектуры конвейеров и фильтров - большее число необходимых каналов, которые потребляют циклы центрального процессора и память. Кроме того, публикация сообщения в канал создаёт определенное количество накладных расходов, из-за того, что данные должны быть транслированы из внутреннего формата приложения в собственный формат инфраструктуры передачи сообщений.

Использование конвейеров и фильтров также улучшает module-wise тестирующую способность модуля. Это может помочь подготовить инфраструктуру тестирования, более эффективно тестировать и отлаживать каждую основную функцию в изоляции, потому что мы можем приспособить тестовый механизм к определенной функции.

Маршрутизатор на основе содержания (Content-Based Router)

Проблема: Маршрутизация может базироваться в ряде критериев типа существования полей, определенных значений полей, и так далее.

Решение: Использовать маршрутизатор на основе содержания, чтобы направить каждое сообщение правильному потребителю, основываясь на содержании сообщения.

Рисунок 14. Маршрутизатор на основе содержания

Взаимодействия: Маршрутизатор на основе содержания исследует содержание сообщения и направляет сообщение в различные каналы, основываясь на данных, содержащихся в сообщении. Реализуя маршрутизатор на основе содержания следует быть особо внимательным, чтобы сделать легкую и удобную в сопровождении логику маршрутизации. В более сложных сценариях интеграции, маршрутизатор на основе содержания может быть реализован как механизм конфигурируемых правил, который вычисляет канал адресата, основываясь на конфигурируемом наборе правил.

Накопитель содержания (Content Aggregator)

Проблема: Система передачи сообщений передаёт сообщения между разнообразными источниками. Сообщения имеют подобные содержания, но различные форматы, которые могут усложнить обработку объединенных сообщений. Было бы лучшим решением, если бы мы назначили обработку различным компонентам с различными обязанностями[11]. Например, если мы хотим выделить все сделки конкретного клиента из различных деловых зон для указанной четверти. Этот метод называют связывание событий и установление последовательности (sequencing).

Решение: Использовать меняющий состояние(stateful) накопитель содержания, чтобы собирать и хранить индивидуальные сообщения и комбинировать связанные, публикуя единственное объединенное сообщение.

Рисунок 15. Накопитель содержания

Взаимодействия: Накопитель содержания - специальный фильтр, который получает поток сообщений и коррелирует связанные сообщения. Когда получен законченный набор сообщений, накопитель собирает информацию из каждого коррелированого сообщения и публикует единственное, объединенное сообщение в канал вывода для дальнейшей обработки. Поэтому, накопитель должен быть меняющим состояние(stateful), так как должен сохранить состояние сообщения с состоянием обработки до момента окончания формирования накопления.

Проектируя накопитель, мы должны определить следующие элементы:
- Идентификатор корреляции(Correlation ID). Идентификатор, который указывает на внутренние отношения сообщений.
- Конечное условие(End condition). Условие, определяющее, когда прекратить обработку.
- Алгоритм накопления(Aggregation algorithm). Алгоритм используемый для комбинирования(объединения) полученных сообщений в единственное выходное сообщение.

Каждый раз, когда накопитель содержания получает новое сообщение, он проверяет, является ли сообщение частью уже существующего набора сообщений. После добавления сообщения, накопитель содержания оценивает условие конца процесса для набора сообщений. Если условие истинно, новое объединенное сообщение формируется из набора и публикуется в канал вывода. Если условие конца процесса неистинно, никакое сообщение не публикуется, и накопитель содержания продолжает обработку.

Образцы потребителя сервиса

Существуют несколько возможных типов потребителей сервисов. В этом каталоге образцов мы представим ряд образцов потребителя.

Транзакционный клиент (Transactional Client)

Проблема: Транзакции - важная часть любой системы передачи сообщений и обычно достаточная для любого участника, чтобы послать или получить единственное сообщение. Однако, несколько специфических сценариев, возможно, нуждаются в более широком транзакционном подходе, который в свою очередь, возможно, нуждается в специальной транзакционной координации. Эти случаи включают (но не ограничены):
- Пары сообщений "послать-принять". Получение одного сообщения и отсылка другого.
- Пакетное сообщение. Отсылка или получение группы связанных сообщений в пакетном режиме.
- Координация сообщения/базы данных. Отсылка или получение сообщения, объединенного с обновлением базы данных. Например, когда приложение получает и обрабатывает сообщение для размещения заказа изделия, оно также должно будет модифицировать инвентарную базу данных изделия.

Такие сценарии требуют различной спецификации транзакционных границ с намного большим количеством сложностей, вовлекающих больше, чем только единственное сообщение и могут вовлечь другие транзакционные хранилища, помимо системы передачи сообщений.

Как Вы можете решить этот вид транзакционных проблем?

Решение: Использовать транзакционного клиента, делая сеанс клиента с системой передачи сообщений транзакционным и гарантируя, что клиент может определить сложные транзакционные границы.

Рисунок 16. Диаграмма транзакционной клиентской последовательности

Взаимодействия: Оба участника могут быть транзакционны. С точки зрения отправителя, сообщение не рассматривается добавленным к каналу, пока отправитель не фиксирует сделку. С другой стороны сообщение не удалено из канала, пока получатель не фиксирует сделку.

С транзакционным получателем, сообщения могут быть получены без фактического удаления сообщения от канала. Преимущество этого подхода состоит в том, что, если приложение "упало" в этом пункте, сообщение все еще находится в очереди после того, как было выполнено восстановление сообщений; сообщение не теряется. После того, как обработка сообщения закончена, и при успешной фиксации сделки, сообщение удаляется из канала.

Опрашивающий потребитель (Polling Consumer)

Проблема: В любой системе передачи сообщений, потребитель нуждается в индикации, что приложение освободилось, и может принять сообщение. Лучший подход для потребителя состоит в том, чтобы циклически проверять канал на предмет доступности сообщения. Если какое-либо сообщение доступно, потребитель получает его. Эта проверка - непрерывный процесс, известный как опрос.

Решение: Приложение должно использовать опрашивающего потребителя, такого, который явно делает вызов, когда требуется получить сообщение.

Рисунок 17. Опрашивающий потребитель

Взаимодействия: Опрашивающий потребитель это получатель сообщения. Опрашивающий потребитель ограничивает число потребляемых параллельных сообщений, ограничивая число потоков опроса. Таким образом, это препятствует блокировке приложения при необходимости обработать слишком много запросов, и сохраняет любые дополнительные сообщения поставленными в очередь вплоть до момента, когда сможет их обработать.

Событийно-управляемый потребитель (Event-Driven Consumer)

Проблема: Проблема с опросом потребителей состоит в том, что он является непрерывным процессом, вовлекает специализированные потоки и потребляет время процесса, пока идет опрос о наличии сообщений.

Решение: Вместо того, чтобы делать опрос потребителем, лучшей идеей могло бы быть использование управляемых событиями сообщений-уведомлений, указывающих на доступность сообщения. Приложение должно использовать событийно-управляемого потребителя. Событийно-управляемые потребители автоматически потребляют сообщения, как только те становятся доступными.

Рисунок 18. Событийно-управляемый потребитель

Рисунок 19. Диаграмма последовательности событийно-управляемого потребителя

Взаимодействия: Событийно-управляемый потребитель вызывается системой передачи сообщений во время прибытия сообщения в канал потребителя. Потребитель использует специфический для приложения механизм обратного вызова(callback), чтобы передать сообщение приложению.

Надёжный (долговременный) подписчик (Durable Subscriber)

Проблема: В некоторых случаях Вы могли бы требовать гарантируемой поставки сообщения, где потребитель сообщения не подключен к каналу публикация-подписка, или канал разрушился перед получением сообщения. В этом случае система передачи сообщений должна обеспечить гарантируемую поставку сообщения, когда потребитель повторно соединяется с системой.

Решение: Использовать надежного подписчика.

Рисунок 20. Надежный подписчик

Рисунок 21. Диаграмма последовательности надежного подписчика

Взаимодействия: Надежная подписка сохраняет сообщения для недоступных подписчиков и гарантирует поставку сообщения, когда подписчик снова подключается, препятствуя потере опубликованных сообщений и обеспечивая гарантируемую доставку. Надежная подписка не имеет никакого эффекта на нормальное поведение сетевого/активного (online/active) подписного механизма.

Идемпотентный Получатель (Idempotent Receiver)

Проблема: Для определенных сценариев, при использовании Надежного подписного механизма, некоторые реализации надежной передачи сообщений обеспечивая гарантируемость, могут произвести дублирующиеся сообщения. Вообще, в этих случаях, гарантировать доставку сообщения можно только снова и снова посылая его, пока не будет возвращено подтверждение от получателя. Однако, если подтверждение потеряно из-за ненадежного подключения, отправитель может снова послать сообщение, уже полученное получателем.

Мы должны гарантировать, что система передачи сообщений в состоянии безопасно обработать любые сообщения, которые получены несколько раз.

Решение: Проектируя получателя, сделать его идемпотентным.

Рисунок 22. Проблема дублирующегося сообщения

Взаимодействия: Термин "идемпотент" возник из математики, и описывает способность функции возвращать тот же самый результат, если применена к себе, то есть f(x) = f(f(x)). В среде передачи сообщений это понятие предоставляет возможность безопасно снова послать то же самого сообщения независимо от полученности этого сообщения несколько раз.

Чтобы обнаруживать и устранять дублирующиеся сообщения, опираясь на идентификатор сообщения, потребитель сообщения должен иметь буфер уже полученных идентификаторов сообщения. Одна из ключевых проблем дизайна - определить таймаут хранения сообщения. В самом простом случае, поставщик услуг посылает одно сообщение за раз, и ожидает подтверждения получателя после каждого сообщения. В этом сценарии, потребитель эффективно использует идентификатор сообщения, чтобы проверить, что идентификаторы являются идентичными. Практически, этот стиль коммуникации очень неэффективен, особенно когда требуется существенная пропускная способность. В этих ситуациях, отправитель мог бы захотеть послать целый набор сообщений в пакетном режиме, не ожидая подтверждение для каждого. При этом необходимо сохранять более длинную хронологию идентификаторов для уже полученных сообщений, и размер буфера сообщений подписчика будет значительно увеличиваться после большого количества сообщений, которое отправитель может послать без подтверждения.

Альтернативный подход к достижению идемпотенции состоит в том, чтобы определить семантику сообщения такой, что вторичная посылка сообщения не воздействует на систему. Например, вместо того, чтобы определить сообщение как переменное уравнение 'Добавить комиссию на 0.3% к Служащему с кодом A1000, имеющему тарифную ставку 10000$', мы могли бы изменить сообщение на 'Установить количество комиссии 300.00$ Служащего с кодом A1000, имеющий тарифную ставку 10000$'. Оба сообщения достигают того же самого результата - даже если текущая комиссия - 300$. Второе сообщение является идемпотентным, потому что получение этого второй раз не будет иметь никакого эффекта. Поэтому, когда это возможно, послайте константы в сообщениях и избегайте переменных. Таким образом мы можем эффективно достигнуть идемпотенции.

Фабрика сервисов (Service Factory)

Проблема: Проектируя сервисного потребителя для множества стилей коммуникации, может быть необходимым определить сервис для каждого стиля, и это понятие может быть связано с образцом Фабричного дизайна(Factory Design Pattern)[9]. В SOA это задача - вызвать правильный сервис, основанный на стиле коммуникации.

Решение: Проектировать фабрику сервисов, которая подключает сообщения в канале к сервису, к которому оно должно получить доступ.

Рисунок 23. Фабрика сервисов

Взаимодействия: Фабрика сервисов может возвратить простой запрос метода или даже сложный вызов удаленного процесса. Фабрика сервисов вызывает сервис точно так же, как любой другой вызов метода и опционально может создать своё сообщение ответа.

Образец фасада сообщения (Message Facade Pattern)

Проблема: В зависимости от бизнес-требований, Вы, возможно, должны инкапсулировать логический бизнес-поток позади стандартного фасада.

Решение: Фасад сообщения может использоваться асинхронно и обслужен независимо. Он действует как перехватчик между сервисным потребителем и поставщиком услуг.

Рисунок 24. Фасад сообщения

Взаимодействия: Клиент создает сообщение-команду и посылает её фасаду сообщения через канал передачи сообщений. Фасад получает сообщение (используя событийно-управляемого или опрашивающего потребителя) и использует информацию, которую оно содержит, чтобы обратиться к коду бизнес-слоя(business tier), чтобы выполнить вариант использования(use case). Опционально, клиенту посылается ответное сообщение, подтверждая успешное завершение варианта использования и возвращая данные.

---

Заключение

Итак, мы поняли, какие образцы передачи сообщений существуют на различных уровнях абстракции в SOA. В этой статье, которая является первой из двумя частей по образцам передачи сообщений в SOA, использовались образцы типов сообщений, чтобы описать различные множества сообщений в SOA, образцы каналов сообщений, объясняющие транспортные системы передачи сообщений, образцы маршрутизаторов, объясняющие механизмы маршрутизации сообщения между Поставщиком услуг и Потребителем сервиса, и наконец образцы Потребителя сервиса проиллюстрировали поведение клиентов системы передачи сообщений. В следующей статье мы обсудим образцы Контракта, которые иллюстрируют поведенческие спецификации, требуемые для поддержки удобной связи между Поставщиком услуг и Потребителем сервиса и образцы конструирования сообщений, которые описывают создание содержания сообщения, путешествущего в системе передачи сообщений.

Авторские права
G Hohpe & B Woolf, Enterprise Integration Patterns, (adapted material from pages 59-83), (c) 2004 Pearson Education, Inc. Reproduced by permission of Pearson Education, Inc. Publishing as Pearson Addison Wesley. Все права защищены.

Ссылки

1. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions, Gregor Hohpe and Bobby Woolf, Addison-Wesley, 2004


2. Service-oriented architecture: A Primer, Michael S Pallos, EAI Journal, December 2001


3. Solving Information Integration Challenges in a Service-Oriented Enterprise, ZapThink Whitepaper, http://www.zapthink.com/


4. SOA and EAI, De Gamma Website, http://www.2gamma.com/en/produit/soa/eai.asp


5. Introduction to Service-Oriented Programming, Guy Bieber and Jeff Carpenter, Project Openwings, Motorola ISD, 2002


6. Java Web Services Architecture, James McGovern, Sameer Tyagi, Michael Stevens, and Sunil Mathew, Morgan Kaufman Press, 2003


7. Using Service-Oriented Architecture and Component-Based Development to Build Web Service Applications, Alan Brown, Simon Johnston, and Kevin Kelly, IBM, June 2003


8. The Modular Structure of Complex Systems, Parnas D and Clements P, IEEE Journal, 1984


9. Design Patterns: Elements of Reusable Object-Oriented Software, Gamma E, Helm R, Johnson R, and Vlissides J, Addison-Wesley, 1994


10. Computerworld Year-End Special: 2004 Unplugged, Vol. 10, Issue No. 10, 15 December 2003—6 January 2004, http://www.computerworld.com.sg/pcwsg.nsf/unidlookup/27FDABB30061388C48256DFA000C181D


11. Applying UML and Patterns—An introduction to OOA/D and the Unified Process, Craig Larman, 2001

Об авторе

Soumen Chatterjee - Microsoft Certified Professional и Sun Certified Enterprise Architect. Он значительно вовлечен в прикладную интеграцию предприятия и разработку распределенных объектно-ориентированных систем, используя технологию Java/J2EE, обслуживающих глобальных гигантов в отраслях промышленности здравоохранения и финансах. Много зная о образцах дизайна EAI, образцах передачи сообщений и стратегиях тестирования, он проектирует и развивает масштабируемую, многократного использования, удобную в сопровождении, имеющую настраиваемую производительность, архитектуру EAI. Soumen - Старший Консультант в Cap Gemini Ernst & Young. Он поклонник методологии экстремального программирования и имеет первичные интересы в AOP и EAI. Помимо программного обеспечения Soumen любит фильмы, музыку, и следует за технологиями "mind power". Его электроная почта - soumen.chatterjee@cgey.com