Свойства веб-сервисов

Чтобы архитектура стала ориентированной на сервисы, сами сервисы должны удовлетворять следующим критериям.

Сервисы слабо связаны с бизнесом и между собой. В контексте автоматизации мера связанности отражает зависимость в отношениях между предметом автоматизации и поддерживающей автоматизируемые процессы логикой. В жестко связанных простых технических системах автоматизации эта связь является абсолютной; так было с первого регулятора Уатта и до современных технических систем. В конечном итоге степень связанности определяется природой автоматизируемого объекта: чем он проще, тем проще регулятор. Бизнес с системной точки зрения сложен, его можно представить в виде сервисов и автоматизировать посредством отдельных сервисов, отношения с которыми выстраиваются на основе определенных контрактов. Архитектура бизнеса нестабильна, он подвержен непрерывному потоку событий. Поэтому полноценным средством для его автоматизации может быть архитектура, управляемая или «движимая событиями» (Event Driven Architecture, EDA), а полноценно реализовать EDA можно только с использованием SOA. Смежный смысл словосочетания loose coupling относится к определению отношений между системными компонентами. Сегодня этот термин широко используется в лексиконе ИТ-специалистов. В то же время нет ничего удивительного в том, что впервые термин loose coupling предложил известный специалист по менеджменту Карл Вейк в статье «Управление изменениями в среде слабо связанных элементов» (The Management of Change Among Loosely Coupled Elements) в 1982 году. На примере этого качества сервисов мы видим, насколько сервисная идея близка и ИТ, и бизнесу.

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

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

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

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

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

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

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

Сервисы должны быть обнаруживаемыми. Это свойство сервисов в массовом порядке — пожалуй, даже чрезмерно — обсуждалось, начиная с первых шагов SOA наряду с протоколами SOAP, UDDI, WSDL. Суть его в том, что приложение, ориентированное на сервисы, не должно быть перегружено реестрами сервисов, механизмами их обнаружения. Для этой цели должна быть предусмотрена специальная поддержка, а приложение должно быть сосредоточено на собственном функционале. Условия, зафиксированные в предложении для контракта, должны позволять потенциальному клиенту найти нужный ему сервис и подключить его вручную или автоматически.

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