Создание и использование WEB-сервисов

Рис. 1: Стек технологий веб-сервисов

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

• технологии, обеспечивающие функциональность веб-сервисов (Functions);
• технологии, обеспечивающие качество сервиса веб-сервисов (Quality of service).

Эти составляющие в свою очередь образуются несколькими слоями (layers):

• технологии, обеспечивающие функциональность веб-сервисов:
• транспортный слой (transport layer);
• коммуникационный слой (service communication layer);
• слой описаний сервисов (service description layer);
• сервисный слой (service layer);
• слой бизнес-процессов (business process layer);
• слой реестров сервисов (service registry layer).
• технологии, обеспечивающие качество сервиса веб-сервисов:
• слой политик (policy layer);
• слой безопасности (security layer);
• слой транзакций (transaction layer);
• слой управления (management layer).

В целях понимания назначения слоев, дадим краткое описание каждого  из них.

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

Принципы взаимодействия веб-сервисов в рамках сервисно-ориентированной  архитектуры

В настоящее время  технологический фундамент веб-сервисов образуется следующими технологиями:

• eXtensible Markup Language (XML);
• Simple Object Access Protocol (SOAP);
• Universal Description, Discovery and Integration (UDDI);
• Web Services Description Language (WSDL).

Рис. 2: Взаимодействие между компонентами сервисно-ориентированной архитектуры

Различают следующие  три основных архитектурных компонента сервисно-ориентированной архитектуры:

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

Каждый компонент может  играть либо лишь одну роль (быть, например, только пользователем сервиса) либо одновременно сразу несколько ролей (например, быть провайдером одних  сервисов и пользователем других).

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

В ходе взаимодействия друг с другом компоненты сервисно-ориентированной архитектуры выполняют следующие основные операции:

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

Рассматривая взаимодействие компонентов сервисно-ориентированной  архитектуры необходимо отметить наличие (и различие) следующих двух артефактов:

• описание сервиса: определяет формат запроса и отклика при взаимодействии пользователя сервиса и провайдера сервиса, а также требуемое качество сервиса;
• сервис: собственно сервис, который может быть вызван и использован пользователем сервиса в соответствии с опубликованным интерфейсом сервиса.

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

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

Сервисы слабо  связаны с бизнесом и между  собой. В контексте автоматизации мера связанности отражает зависимость в отношениях между предметом автоматизации и поддерживающей автоматизируемые процессы логикой. В жестко связанных простых технических системах автоматизации эта связь является абсолютной; так было с первого регулятора Уатта и до современных технических систем. В конечном итоге степень связанности определяется природой автоматизируемого объекта: чем он проще, тем проще регулятор. Бизнес с системной точки зрения сложен, его можно представить в виде сервисов и автоматизировать посредством отдельных сервисов, отношения с которыми выстраиваются на основе определенных контрактов. Архитектура бизнеса нестабильна, он подвержен непрерывному потоку событий. Поэтому полноценным средством для его автоматизации может быть архитектура, управляемая или «движимая событиями» (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. Суть его в том, что приложение, ориентированное на сервисы, не должно быть перегружено реестрами сервисов, механизмами их обнаружения. Для этой цели должна быть предусмотрена специальная поддержка, а приложение должно быть сосредоточено на собственном функционале. Условия, зафиксированные в предложении для контракта, должны позволять потенциальному клиенту найти нужный ему сервис и подключить его вручную или автоматически.

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

WS-I Basic Profile 1.0

В заключение следует  сказать, что с целью выработки  и популяризации стандартов, описывающих  взаимодействие веб-сервисов в рамках сервисно-ориентированной архитектуры, создано международное объединение около 150 ведущих компаний, называющееся WS-I (Web Services Interoperability Organization). Важным результатом работы данного объединения стало создание и утверждение в 2003 году так называемого WS-I Basic Profile 1.0 - пакета базовых спецификаций веб-сервисов, взаимоувязанных с целью обеспечения широких возможностей взаимодействия веб-сервисов. В настоящее время в данный профиль входят следующие спецификации технологий:

• SOAP 1.1;
• WSDL 1.1;
• UDDI 2.0;
• XML 1.0;
• XML Schema Part 1: Structures;
• XML Schema Part 2: Datatypes;
• RFC2246: The Transport Layer Security Protocol 1.0;
• RFC2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile;
• RFC2616: HyperText Transfer Protocol 1.1;
• RFC2818: HTTP over TLS;
• RFC2965: HTTP State Management Mechanism;
• Secure Sockets Layer Protocol 3.0.