max404.NET

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

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

Введение

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

Контракты и сокрытие информации

Контракт интерфейса - опубликованное соглашение между поставщиком услуг и потребителем сервиса. Контракт определяет не только аргументы и возвращаемые сервисом значения, но также и предварительные и пост-условия сервиса. Parnas и Clements лучше всего описывают принципы сокрытия информации:
"Наша модульная структура основана на критерии декомпозиции, известном как сокрытие информации. Согласно этому принципу, системные подробности, которые, вероятно, изменятся независимо, должны быть тайнами отдельных модулей; единственные предположения, которые должны появиться в интерфейсах между модулями - те, которые рассматриваются как "вряд ли изменяемые". Каждая структура данных используется только в одном модуле; одна или несколько программ в пределах модуля могут непосредственно обратиться к ней. Любая другая программа, которая требует информации, сохраненной в структурах данных модуля, должна получить её, вызывая программы доступа, принадлежащие этому модулю." (Parnas и Clements 1984) [8]

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

Образец контракта

Проблема: Как можно определить поведения, независимые от реализаций?

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

Взаимодействия: Методы, типы методов, типы параметров методов, и типы полей предписывают синтаксис интерфейса. Комментарии, названия методов, и имена полей описывают семантику интерфейса. Объект может реализовывать несколько интерфейсов.

Конструирование сообщения

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

Идентификатор Корреляции (Correlation Identifier)

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

Рисунок 1. Идентификатор корреляции

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

Взаимодействия: В идентификаторе корреляции шесть частей:
1. Проситель(Requestor) - Приложение потребителя.
2. Ответчик(Replier) - Поставщик услуг(Service Provider). Получает идентификатор запроса и сохраняет его как идентификатор корреляции в ответе.
3. Запрос(Request) - Сообщение, посланное от потребителя Поставщику услуг, содержащее идентификатор запроса.
4. Ответ(Reply) - Сообщение, посланное от Поставщика услуг Потребителю, содержащее идентификатор корреляции.
5. Идентификатор запроса(Request ID) - токен в запросе, который уникально идентифицирует запрос.
6. Идентификатор корреляции(Correlation ID) - токен в ответе, который имеет то же самое значение как идентификатор запроса в запросе.

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

Последовательность сообщений (Message Sequence)

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

Рисунок 2. Последовательность сообщений, с указанием размера

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

Взаимодействия: Три поля идентификации последовательности сообщения:
- Идентификатор последовательности(Sequence ID), чтобы дифференцировать одну последовательность от другой.
- Идентификатор позиции(Position ID) - относительный уникальный идентификатор, определяющий позицию сообщения в последовательности.
- Индикатор конца последовательности - используется, чтобы указать конец последовательности.

Рисунок 3. Последовательность сообщений с концевым индикатором

Последовательности типично проектируются так, чтобы каждое сообщение в последовательности указывало полный размер последовательности; то есть, число сообщений в последовательности (см. рисунок 26). Кроме того, Вы можете проектировать последовательности так, что каждое сообщение указывает, является ли оно последним (см. рисунок 27). Давайте рассмотрим реальный пример. Предположим, что мы хотим генерировать сообщение для всех счетов с 01/01/2001 до 31/12/2003, что может возвратить миллионы отчетов. Обрабатывая этот сценарий, разделите период на четверти и возвращайте данные для каждой четверти. Отправитель посылает ежеквартальные данные как сообщения, и получатель использует порядковый номер, чтобы пересобрать данные и определяет завершение полученных данных на основании индикатора конца последовательности.

Истечение срока годности сообщения (Expiration)

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

Рисунок 4. Истечение срока годности сообщения

Решение: Установить срок годности сообщения, определяющий длительность его хранения на постоянных носителях.

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

Преобразование сообщений

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

Конвертная обертка (Envelope Wrapper)

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

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

Взаимодействия: Процесс обертывания и разворачивания сообщения состоит из пяти шагов:
1. Источник сообщения публикует сообщение, зависящее от необработанного формата.
2. Обертка берет необработанное сообщение и преобразовывает его в формат сообщения, который соответствует системе передачи сообщений. Это может включать добавление полей заголовка сообщения, шифровку сообщения, добавления мандата безопасности и т.д.
3. Система передачи сообщений обрабатывает получившиеся сообщения.
4. Итоговое сообщение доставляется обработчику(unwrapper). Он полностью возвращает любые модификации сделанные оберткой. Это может включать удаление полей заголовка, расшифровку сообщения или подтверждения мандата безопасности.
5. Потребитель сообщения получает 'clear text' сообщение. Конверт типично обертывает и заголовок сообщения и тело сообщения или полезный груз. Мы можем думать о заголовке, как о информации относительно внешней стороны конверта - она используется системой передачи сообщений, чтобы направить и проследить сообщение. Инфраструктура передачи сообщений не заботится о содержание конверта - полезного груза, или тела - пока конверт не достигает адресата.

Рисунок 5. Конвертная обертка

Обогатитель содержания (Content Enricher)

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

Рисунок 6. Обогатитель содержания

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

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

Фильтр содержания (Content Filter)

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

Рисунок 7. Фильтр содержания

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

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

Квитанция на получение (Claim Check)

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

Рисунок 8. Квитанция на получение

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

Взаимодействия: Образец квитанции на получение состоит из следующих пяти шагов:
1. Прибывает сообщение с данными.
2. Компонент 'check luggage'(багажный чек) генерирует уникальный ключ, который используется на более поздней стадии как квитанция на получение.
3. Компонент 'check luggage' извлекает данные, основанные на уникальном ключе из постоянного хранилища.
4. Удаляет сохраненные данные из сообщения и добавляет квитанцию на получение.
5. Отмеченные данные восстанавливаются использованием обогатителя содержания, восстанавливающего данные, на основании квитанции на получение.

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

---

Заключение

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

Согласно Robert Shimp, вице-президенту Technology Marketing в Oracle: "EAI требует определенного предварительного знания о том, что обеспечивает каждое приложение. SOA рассматривает каждое приложение как поставщика услуг и допускает динамический самоанализ сервисов посредством директории общих сервисов, Universal Description Discovery and Integration of Web services (UDDI)."

Передача сообщений - основа SOA. Steven Cheah, директор Software Engineering and Architecture в Microsoft Singapore, утверджает: "Мы теперь наконец имеем стандартное транспортное средство для того, чтобы добиться SOA. Теперь мы можем определить стандарты сообщения для SOA, использующего эти стандарты Веб-служб."

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

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

Ссылки

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


• Service Oriented architecture: A Primer, Michael S Pallos, EAI Journal, December 2001


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


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


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


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


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


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


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


• Computerworld Year-End Special: 2004 Unplugged, Vol. 10, Issue No. 10, 15 December 2003 - 6 January 2004, http://www.computerworld.com.sg/pcwsg.nsf/currentfp/fp


• Applying UML and Patterns – An introduction to OOA/D and the Unified Process, Craig Larman, 2001

Объявление авторских прав

G Hohpe & B Woolf, ENTERPRISE INTEGRATION PATTERNS, (adapted material from pages 59-83), © 2004 Pearson Education, Inc. Reproduced by permission of Pearson Education, Inc. Publishing as Pearson Addison Wesley. Все права защищены.

Об авторе

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