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

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

Последние, кстати, со временем становятся все более категоричными. Если публикации о сервис-ориентированной архитектуре (Service-Oriented Architecture, SOA) двухлетней давности, например, от аналитической компании ZapThink, носили скорее рекомендательный характер, предлагая внимательно отнестись к возможностям SOA, то в отчетах текущего года аналитики настаивают, что у SOA в скором времени не будет альтернатив. В META Group, ныне ставшей частью Gartner, год назад предсказывали [1], что в 2005-м начнется повсеместная адаптация принципов SOA, а к 2007 году сервис-ориентированная архитектура станет основой для большинства корпоративных приложений и во многом изменит принципы их создания и эксплуатации. Имеет смысл внимательнее присмотреться, что же стоит за магической аббревиатурой SOA.

SOA — это неспроста

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

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

Сложности интеграции приложений значительно ограничивают возможность создания гибкой, динамичной ИТ-инфраструктуры. Существуют различные классы программных решений для интеграции, но большинство из них, даже те, которые наиболее близки по своим принципам к SOA, имеют ряд общих недостатков. Это прежде всего интеграция по принципу «сильной связанности» (tightly coupled), когда механизмы интеграции привязаны к коду интегрируемых приложений, в результате чего изменения в одном из них потребуют модификации других. Разнообразие способов интеграции, отсутствие стандарта, который удовлетворил бы приложения любых типов, приводят к необходимости специального программирования интеграционных интерфейсов для каждой пары взаимодействующих прикладных систем (см.рисунок).

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

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

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

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

Попытка определения

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

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

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

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

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

Слабая связанность (Loosely coupled). С точки зрения реализации сервисы в SOA независимы друг от друга: они выполняют определенные действия по запросам, полученным от других сервисов, и возвращают результаты. Все детали этого выполнения полностью скрыты: в концепции SOA сервисы — это «черные ящики». Отсюда следует, что изменения в реализации сервиса никак не повлияют на прикладной компонент, который этот сервис использует, и наоборот. Слабая связанность обеспечивает простую и быструю адаптацию системы к изменениям в структуре и принципах реализации сервисов.

«Крупнозернистая» (coarse-grained) структура сервисов. Сервисы в SOA представляют собой модули бизнес-логики достаточно высокого уровня, благодаря чему взаимодействие между ними сводится к ограниченному числу сообщений по содержанию бизнес-логики вместо множества низкоуровневых вызовов, учитывающих детали реализации сервисов. Такой подход снижает нагрузку на сеть и способствует более высокой производительности системы. На практике переход к SOA может начинаться с представления в виде сервисов бизнес- или системных функций низкого уровня, которые затем благодаря еще одному свойству сервисов — модульности будут компоноваться в высокоуровневые сервисы, реализующие определенные этапы бизнес-процесса или весь процесс целиком. Важно, что с точки зрения архитектуры сервис, независимо от внутренней структуры и языка реализации, выглядит как единое целое.