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

Несмотря на то что в аббревиатуре 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 может начинаться с представления в виде сервисов бизнес- или системных функций низкого уровня, которые затем благодаря еще одному свойству сервисов — модульности будут компоноваться в высокоуровневые сервисы, реализующие определенные этапы бизнес-процесса или весь процесс целиком. Важно, что с точки зрения архитектуры сервис, независимо от внутренней структуры и языка реализации, выглядит как единое целое.

Стандартные интерфейсы (standards-based).

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

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

Web-сервисы и их предшественники

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

На самом деле попытки реализовать архитектуру приложений, в которой распределенные прикладные модули представлены как объекты, взаимодействующие посредством четко описанных интерфейсов, предпринимаются уже довольно давно и с определенным успехом. Чтобы убедиться в этом, достаточно вспомнить хорошо известные ИТ-специалистам модели построения компонентных приложений Common Object Request Broker Architecture (CORBA) и Microsoft Distributed Component Object Model (DCOM). Внешне они действительно похожи на SOA, но более детальный анализ показывает, что в этих ранних подходах к сервисной ориентации программных систем не выполняются или выполняются с определенными ограничениями базовые принципы SOA. Так, в CORBA и DCOM взаимодействующие объекты являются сильносвязанными, и внесение изменений в реализацию программных компонентов, предоставляющих и использующих определенный сервис, должны быть скоординированы между собой. Запросы к объектам (сервисам) в этих архитектурах, как правило, содержат небольшой объем информации, учитывающей специфику реализации сервисов («мелкозернистая» — fine-grained — структура сервисов), и потому порождают значительный сетевой трафик между поставщиком и потребителем сервиса. В DCOM взаимодействие программных компонентов основано на закрытых интерфейсах Microsoft. CORBA не принадлежит частной компании, эта архитектура — плод усилий международного консорциума OMG, который ставил своей целью создание универсальной платформы интеграции разнородных программных компонентов на базе стандартного языка описания интерфейсов. Однако реализации спецификаций CORBA сильно варьируются в продуктах разных производителей, что ограничивает интероперабельность систем на базе CORBA. Кроме того, и CORBA, и DCOM имеют существенные ограничения по поддержке действительно распределенных систем, их протоколы взаимодействия объектов слишком сложны для организации производительной связи сервисов, реализованных на разных машинах.

С появлением XML открылся путь к созданию интерфейсов, нейтральных к платформе реализации. Основанный на XML язык описания Web-сервисов WSDL и использование XML для обмена сообщениями между сервисами обеспечивают тот универсальный механизм взаимодействия разнородных компонентов, без которого невозможна SOA. Стандартный протокол SOAP обеспечивает простую связь между сервисами по сети. Реестр сервисов, построенный по стандарту UDDI, позволяет компонентам системы получить информацию о доступных сервисах. Таким образом, Web-сервисы обеспечивают базовые технологии для создания приложений по принципам архитектуры SOA. Эти технологии будут эволюционировать и в перспективе могут оказаться вытесненными другими, более прогрессивными решениями, что не изменит общей сущности SOA, хотя, возможно, внесет коррективы в подходы к реализации этой архитектуры.

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

«Дорожная карта» SOA

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

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

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

Аналитики ZapThink ([2]) выделяют несколько основных этапов реализации сервисного подхода в корпоративной архитектуре, каждый из которых должен дать положительный показатель возврата на инвестиции, чтобы оправдать дальнейшие вложения в SOA:

  • базовая реализация Web-сервисов;
  • статические сервисы, имеющие критическое значение для бизнеса;
  • пилотные проекты SOA;
  • корпоративная инфраструктура SOA;

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

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

Будущее — за SOA

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

Литература:
  1. Daniel Sholler. Making SOA real. META Group, June, 2004.
  2. Growing an agile service-oriented architecture. Zapthink LLC, September, 2003.

Наталья Дубова — научный редактор журнала «Открытые системы», dubova@osp.ru

Стандарты для SOA

На данном этапе своего развития сервис-ориентированные архитектуры для описания и организации взаимодействия используют базовые стандарты Web-сервисов:

  • eXtensible Markup Language (XML) — для представления данных;
  • Web Services Definition Language (WSDL) — для описания доступных Web-сервисов;
  • Universal Description, Discovery, Integration (UDDI) — для создания каталога доступных по сети Web-сервисов;
  • Simple Object Access Protocol (SOAP) — для обмена данными.

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

Технологии реализации

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

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

Инфраструктура интеграции и управления сервисами. Для организации взаимодействия сервисов необходима среда, которая обеспечит динамическую маршрутизацию запросов от прикладного компонента — потребителя сервиса и получение результатов от приложения — провайдера сервиса. Для этого может потребоваться поддержка синхронных и асинхронных коммуникаций более низкого уровня между приложениями, трансформация и высокоскоростное распределение данных, трансляция протоколов, кэширование функций Web-сервисов, виртуализация ввода/вывода и т. д. Для решения этих задач все большее распространение получает технология корпоративной сервисной шины (Enterprise Service Bus, ESB), которая предоставляет единый механизм для передачи запросов и получения результатов сервисов, выполнения необходимых преобразований сообщений и транспортных протоколов и управления потоком обращений к сервисам.

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

Инфраструктура автоматизации и управления бизнес-процессами. Конечная цель SOA — обеспечить представление бизнес-процессов как взаимодействующих сервисов. Средства управления бизнес-процессами обеспечивают интеграцию в нужной последовательности сервисов, которые могут быть как локальными — реализованными в ИТ-инфраструктуре компании, так и удаленными, если процесс на определенных этапах обращается к ресурсам партнерских компаний. Стандартом для такой интеграции, которая в профессиональном лексиконе обозначается терминами «хореография» или «оркестровка» сервисов, становится разработанный IBM и Microsoft язык Business Process Execution Language (BPEL).

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

IBM, BEA Systems, Progress Software, TIBCO, Oracle включают в свои платформы интеграции приложений инструменты для реализации принципов SOA. В средах управления ИТ-инфраструктурой от Hewlett-Packard, Computer Associates, IBM, BMC Software появляются не только средства управления Web-сервисами, но и более комплексные предложения для мониторинга и контроля ресурсов в SOA. Интегрированные среды разработки приложений от IBM и Microsoft предоставляют возможности создания сервисов в идеологии SOA.

Наконец, одна из наиболее интересных тенденций последнего времени — обращение к SOA традиционных поставщиков ERP-систем, которые стремятся перейти от монолитных, громоздких решений к более гибким композитным приложениям, собираемым из компонентов-сервисов. Достаточно упомянуть платформу SAP NetWeaver, которая поддерживает интеграцию модулей, разработанных SAP и партнерами компании. SAP с ее стратегией развития корпоративной сервисной архитектуры (Enterprise Services Architecture, ESA) аналитики AMR Research (см. опубликованный 13 декабря 2004 года отчет SAP NetWeaver's Next Move: Navigating Standards-Based Interoperable Infrastructure) включают в немногочисленную групп вендоров, продукты которых смогут обеспечить полную экосистему разработки, развертывания и поддержки SOA. В эту группу входят также BEA, IBM, Microsoft и Oracle.