Концепция SOA

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

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

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

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

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

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

Попытки обеспечения технической интероперабельности предпринимались на протяжении десятилетий; DCE, CORBA, DCOM и RMI до сих пор широко применяются для передачи вызовов между системами по сети. Но только с появлением Web-сервисов был найден стандарт, позволяющий объединить все корпоративные вычислительные платформы и инструментальные средства.

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

Возможно, именно технологии Web-сервисов сыграли свою роль в наименовании сервис-ориентированной архитектуры (service oriented architecture, SOA). На самом деле, принципы SOA вынашиваются в умах ее сторонников уже как минимум третье десятилетие, в то время как о Web-сервисах впервые заговорили только на рубеже столетий. На протяжении большей части этого времени доминировала объектно-ориентированная идеология построения систем, и задачи технической интероперабельности сводились главным образом к возможности вызова удаленных объектов. Постепенное развитие технологий взаимодействия привело к замене в этом контексте понятия распределенных объектов термином сервис, а объектная модель вернулась на уровень рассмотрения архитектуры самих сервисов — т.е. давно известных компонентов информационных систем.

Сами Web-сервисы не предполагают какого-либо архитектурного решения, в то время как именно архитектурой определяется стиль процессов взаимодействия. Стандарт ANSI/IEEE 1471-2000 определяет архитектуру, как «фундаментальный способ организации системы, продиктованный ее компонентами, их взаимным отношением друг к другу и к окружающей среде, а также принципами, в соответствии с которыми осуществляется ее проектирование и развитие». В этом Web-сервисы дополняют SOA как теория и практика построения распределенных архитектур с децентрализованным механизмом принятия решений. SOA не предписывает жесткой вертикальной («сверху вниз») методологии проектирования, внедрения или управления ИТ-инфраструктурой. Вместо этого, SOA ограничивается лишь рядом принципов, характеризующих каждый из этих процессов; поэтому ее иногда называют не архитектурой, а архитектурным стилем. Отметим некоторые из этих принципов.

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

Как бы неожиданно это ни показалось, перечисленные принципы были сформулированы американским архитектором Кристофером Александером в отношении архитектуры современного мегаполиса. В 1987 году он и его коллеги опубликовали работу под названием «Новая теория городского проектирования» (A New Theory of Urban Design), где излагались взгляды на возможность децентрализованного развития городов. В своей работе Александер показал, как можно осуществлять развитие городов с учетом существенной демографической разнородности жителей. Аналогичным образом SOA, основанная на адаптации этих принципов, позволяет объединить в общий взаимодействующий организм информационные системы, принадлежащие различным автономным организациям и их относительно автономным структурным подразделениям.

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

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

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

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

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

Подобные контракты существовали и до появления Web-сервисов. Например, в архитектуре CORBA для описания интерфейса объектов использовался язык IDL, который уступает WSDL по ряду существенных параметров. Главный из них — отсутствие поддержки XML и XML Schema, ставших наиболее распространенными языками разметки передаваемых по сети сообщений и представления моделей данных.

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

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

Рис. 1. Классическое представление SOA

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

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

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

Рис. 2. Профиль WS-I Basic Profile

Программный интерфейс реестра сервисов составляет часть стека протоколов взаимодействия. В наборе технологий Web-сервисов таким стандартом является UDDI (Universal Description, Discovery and Integration). Его спецификация является единственной из ядра основополагающих стандартов Web-сервисов, разработанной вне рамок консорциума World Wide Web Consortium. Таким ядром принято считать спецификации, входящие в профиль WS-I Basic Profile (рис. 2), призванный обеспечить общую для различных инструментальных платформ базу взаимно совместимых технологий описания, публикации, обнаружения и вызова сервисов.

Для разработки данной спецификации в 2000 году был сформирован Консорциум UDDI (UDDI.org), объединивший более 200 корпоративных членов. В соответствии со своим трехлетним мандатом, консорциум выпустил три версии спецификации и перестал существовать в 2003 году. Уже зрелый стандарт, реализованный многими разработчиками, UDDI был передан в организацию Organization for the Advancement of Structured Information Standards (OASIS), занимающую важное место в мире ИТ-стандартов. Текущей версией UDDI, официально принятой в качестве стандарта OASIS, является вторая; ратификация третьей версии ожидается в конце лета этого года, а технический комитет UDDI в составе OASIS уже разрабатывает очередную порцию нововведений.

UDDI обладает весьма развитой функциональностью, существенно более богатой чем, аналогичный компонент набора стандартов CORBA — CORBA Naming Service. В отличие от предыдущих поколений реестров, UDDI был изначально нацелен на применение как внутри организаций, так и между ними, поэтому реестры UDDI одинаково удобны для ведения информации о нескольких или о тысячах сервисах. Для этого UDDI предусматривает гибкую информационную модель и средства распределения доступа. Так, любой реестр может иметь своих авторизованных пользователей, каждый из которых может публиковать информацию о вверенных ему провайдерах сервисов. Каждый из них может быть классифицирован для облегчения обнаружения, причем спецификация включает четыре стандартных классификатора: UNSPSC 3.1, UNSPSC 7.3 (и старше), NAICS 1997, ISO 3166.

Индивидуальные сервисы также могут быть классифицированы. С этой целью, как правило, применяются дополнительные классификаторы, отражающие наиболее целесообразные способы структурирования информации о сервисах для конкретной организации, сообщества или отрасли. Но с точки зрения применимости UDDI в SOA, наиболее методологически значимым элементом информационной модели UDDI является возможность стандартизации типов сервисов (рис. 3). Интерфейс сервиса, описанный WSDL-документом, или даже отдельную его характеристику (скажем, стоимость или поддержка некоего протокола, такого, как HTTP Basic или WS-Security для авторизации) можно представить самостоятельным объектом метаданных в UDDI. Совокупность ссылок на такие объекты характеризует профиль интероперабельности данного сервиса. Используя те или иные параметры, потребитель может найти в реестре сервис, соответствующий его техническим или деловым потребностям.

Рис. 3. Стандартизация типов сервисов

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

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

С момента публичного представления первой версии UDDI функционирует общедоступный реестр UDDI Business Registry (UBR), который сейчас состоит из четырех географически распределенных реплицируемых узлов: Microsoft (западное побережье США), IBM (восточное побережье США), SAP (Европа) и NTT Telecom (Азия). Реестр UBR представляет собой Internet-инфраструктуру уровня Web-сервисов, нацеленную на обеспечение взаимодействия информационных систем с использованием существующих стандартов Сети от W3C и IETF, таких как DNS, HTTP и XML. Управлением UBR занимается Совет операторов, членство в котором открыто для любой организации, желающей стать оператором собственного узла UBR.

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

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

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

Остается надеяться, что в России интерес к этим технологиям будет отражать то активное участие, которое в их развитии приняли представители отечественной ИТ-индустрии.