Опыт построения SOA с использованием шаблонов.

Марк М. Давыдов
Вице-президент и старший архитектор по предоставлению технологий Bank of America, отвечает за определение архитектуры доменов, процессы, относящиеся к жизненному циклу архитектур ПО. В его книге «Корпоративные порталы и интеграция электронного бизнеса» (Corporate Portals and e-Business Integration. McGraw-Hill, 2001) были впервые высказаны многие идеи, повлиявшие на развитие SOA и модели Web-сервисов.

При проектировании многократно используемых сервисов очень полезно обратиться к накопленному в отрасли опыту и отработанным шаблонам — они позволят получить лучшее решение на базе сервисно-ориентированной архитектуры и модели Web-сервисов. На основе опыта проектов в Bank of America и General Motors мы расскажем о построении сервисно-ориентированной архитектуры (SOA).

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

Критически важные факторы успеха

В первую очередь нужно удостовериться в том, что данный сервис действительно можно многократно использовать в разных областях бизнеса. Цель этой верификации — не допустить разработки сервисов, основанных на функциональных требованиях только для одного проекта, без проведения правильного «межобластного» анализа: такие сервисы почти наверняка не удастся эффективно использовать в других проектах — даже при корректном применении их интерфейсов и стандартов XML.

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

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

Шаблоны приходят на помощь

Со времени выхода в 1995 году основополагающей книги Эрика Гаммы, Ричарда Хелмса, Ральфа Джонсона и Джона Влиссидеса(1) (которых часто называют «бандой четырех») стимулирование многократного использования ПО при помощи шаблонов получило широкое распространение. Однако зачастую к шаблонам обращаются лишь для справки при решении определенных вопросов проектирования, тогда как их подлинная роль — выступать важнейшей составляющей архитектурных требований к SOA и служить отправной точкой при определении организации и структуры бизнес-сервисов.

В этой статье мы обсудим идентификацию и использование двух архитектурных шаблонов, важных для SOA, — деления на уровни/слои и медиатора (информационного брокера). Они прямо связаны со структурированием сервисов и именно поэтому выбраны из множества других, тоже значимых шаблонов, включая шаблон обмена сообщениями (Message Exchange Pattern, MEP), ряд шаблонов, входящих в состав ядра Java 2 Enterprise Edition (J2EE): делегат бизнеса (Business Delegate), фасад (Facade), Web-брокер (Web Broker), — и т. д.

Хотя о SOA есть много хороших статей — и в связи с этим автор предполагает, что у читателя есть общее знакомство с предметом, — почти ничего не написано о том, как определять ключевые элементы, существенные для архитектурного построения. Главный вопрос здесь в том, как правильно сконструировать высококачественное крупномасштабное приложение, распределив весь процесс обработки информации по N сервисно-ориентированным слоям. Как реализовать каждый слой многоуровневой схемы, чтобы гибкость архитектуры стала выше, а бремя обслуживания и поддержки — легче? Как в свете развивающихся технологий построения Web-сервисов правильно применить стандартные компоненты, где функции модулей ориентированы на бизнес-сервисы? В действительности даже если бы мы умели точно определять «сервисно-пригодные» бизнес-функции и располагали всеми необходимыми прикладными и промежуточными программными инструментами, нам все равно пришлось бы отвечать на главный вопрос: как при использовании Web-сервисов распределить функции приложения между разными процессорными элементами, чтобы добиться максимального качества?

Один уровень сервиса: этого мало

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

Рис. 1. Уровень сервиса.
Рисунок из книги: Martin Fowler. Patterns of Enterprise Application Architecture.
— Addison Wesley Professional, 2002.
(Русский перевод: Фаулер М. Архитектура корпоративных программных приложений.
— «Вильямс», 2006.)

Однако на практике, особенно при больших объемах бизнес-транзакций, одного уровня сервиса недостаточно. Самая частая ошибка здесь — создание уровня, представляющего собой непосредственную оболочку для всех «методов» из разнообразных компонентов, без какого бы то ни было дополнительного абстрагирования. В результате разработчики обходят принцип инкапсуляции и без необходимости дублируют функции, что приводит к избыточности кода. Приведем простой пример. Пусть у нас есть три компонента, поддерживающие три бизнес-объекта — заказы, товары и описания. И у заказов, и у товаров есть описания. При единственном уровне у нас могут получиться два сервиса — заказы и товары, причем оба с поддержкой описаний, т. е. в каждом будет нечто вроде метода addDescription().

Деление на уровни должно приводить к снижению общей сложности, однако в приведенном примере этого не происходит. Наоборот, при включении всех случаев использования в один и тот же уровень и вынесении их методов в прикладной интерфейс Web-сервисов образуется множество интерфейсов со сходным поведением (например, GetAccountBalance, UpdateAccountBalance, TransferFunds, ListAllAccountBalances и т. д.). В итоге сложность увеличивается, а не уменьшается.

Сущность уровней SOA

Что же реально означает разделение на уровни в контексте SOA? В чисто структурном смысле уровень сервиса, скрывающий реализацию самого сервиса, должен быть разделен еще на несколько уровней (подуровней), которые помещаются друг над другом таким образом, что сервисы (N+1)-го уровня по большей части состоят из сервисов, представленных на фасаде уровня N (см. рис. 2). Не «умножая», а вкладывая друг в друга фасады, мы в состоянии управлять «зернистостью» сервисов — крупной, средней и мелкой. Под «крупнозернистым» понимается более формальный, обобщенный интерфейс, дающий абстрактное представление подсистемы (например, управление заказами, учетными записями или расценками). Главная идея при этом — использовать достаточное сочетание нескольких фасадов, за которыми скрыты все детали бизнес-логики, составляющей основу сервиса. Только так можно существенно продвинуться к решению, полностью соответствующему архитектуре SOA.

Рис. 2. Обобщенная модель уровней сервиса

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

Обобщение с точки зрения случаев использования показывает, таким образом, что уровни, выделенные согласно архитектуре SOA, образуют внутри предприятия некую иерархию. Рассмотрение SOA-модели предприятия принято начинать с его процессов, а также с видов деятельности, которые интерпретируются как бизнес-сервисы, сообщающие этим процессам специфическую функциональность многократного использования. Бизнес-сервисы составляют самый верхний уровень иерархии сервисов и служат механизмом для конкретного воплощения и эксплуатации сервисов нижележащего уровня, часто именуемых «ядерными» или «базовыми» (к примеру, «Учетные записи» или «Заказы»). Те с большой вероятностью являются общими для разных бизнес-процессов и сами зависят от элементарных сервисов системного типа, таких как регистрация или сохранение состояния (persistence), а они, в свою очередь, — от низкоуровневых инфраструктурных сервисов (обслуживающих передачу сообщений, обращение к базам данных и т. п.). Наиболее ценны базовые и элементарные сервисы; их возможности критически важны для полного проведения стратегии SOA.

Рис. 3. Многоуровневая модель сервисов с медиаторами

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

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

Медиаторы в иерархии сервисов

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

Однако достаточно ли такой схемы, чтобы обеспечить возможность многократного использования и гибкость? На самом деле нет — многоуровневость сама по себе не гарантирует многократного использования, так как в дополнение к делению на уровни необходимо правильно спроектировать все фасады. Если говорить более конкретно, то нужна всеохватывающая инкапсуляция интерфейсов сервисов. И здесь огромную помощь оказывает понятие «медиатора».

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

В архитектуре SOA шаблон медиатора применяется в похожем, но значительно более широком контексте. Поскольку первичной задачей здесь является всеохватывающая инкапсуляция сервисов (в понимании объектно-ориентированного проектирования), медиаторы выступают как фасады сервисов, которые делегируют (передают) их от одной системы к другой. Таким образом, медиатор проектируется «фасадным» (front end-able) для всякого сервиса, что достигается путём делегирования: к нему поступают запросы на обслуживание, адресованные другому уровню. В терминах реализации он получает XML-сообщения от реквесторов сервиса и посылает сообщения соответствующим провайдерам.

Как это показано на рис. 3, медиаторы играют роль «изоляторов» между уровнями в иерархической модели корпоративных сервисов. Именно здесь используются такие элементарные сервисы, как регистрация и кэширование. Также следует сказать, что в архитектурном смысле медиаторы располагаются над промежуточным ПО передачи сообщений (которому соответствует уровень «чистого» обмена сообщениями) и традиционными интеграционными брокерами. Они работают с бизнес-процессами, лежащими в основе сервиса, т. е. с отдельными операциями типа «запрос — ответ» в рамках процессов.

Сложности многоуровневого подхода

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

На пути перехода к многоуровневости стоит несколько «тормозящих факторов», и чтобы получить цельное SOA-решение для предприятия, ИТ-подразделения должны их учитывать. Назовём эти проблемы.

Культура. До сих пор существуют люди, сопротивляющиеся внедрению многоуровневого подхода к сервисам. Обычно они выдвигают два аргумента.

1. «Это все теория, нет необходимости беспокоиться о ее практическом применении». Кому-то, может, и не стоит. По крайней мере пока. Однако многоуровневый подход, включая применение шаблона медиатора, уже реализован в General Motors, Объединенном банке Швейцарии и Ericsson Telecom AB. Кроме того, группа по новым технологиям и инфраструктурам при генеральном директорате Еврокомиссии по информационному обществу определила сервисы с медиацией как основную архитектуру своего проекта «Среда совместной работы следующего поколения» (Next Generation Collaborative Working Environments), реализация которого намечена на 2005—2010 годы.

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

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

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

Технические сложности. Инфраструктура для поддержки многоуровневой схемы на уровне сервисов/компонентов и промежуточного ПО часто отсутствует. Увы, нет принятых стандартов, которые гарантировали бы «гладкость» совместного использования технических платформ для оркестровки сервисов и построения их сочетаний. Серьезную проблему представляет и большое количество унаследованных систем, обладающих собственной инфраструктурой.

***

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

(1)Erich Gamma, Richard Helms, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. — Addison-Wesley, 1995. (Русский перевод: Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. — «Питер», 2006.)