Основные технологии web-сервисов
eXtensible Markup Language (XML);
— рекомендованный Консорциумом Всемирной паутины язык разметки, фактически представляющий собой свод общих синтаксических правил. XML предназначен для хранения структурированных данных (взамен существующих файлов баз данных), для обмена информацией между программами, а также для создания на его основе более специализированных языков разметки (например, XHTML), иногда называемых словарями.
Simple Object Access Protocol (SOAP);
— протокол обмена структурированными сообщениями в распределённой вычислительной среде.
Universal Description, Discovery and Integration (UDDI);
— инструмент для расположения описаний веб-сервисов (WSDL) для последующего их поиска другими организациями и интеграции в свои системы.
Web Services Description Language (WSDL).
— язык описания веб-сервисов, основанный на языке XML.
11
Взаимодействие между компонентами сервисно-ориентированной архитектуры
12
пользователь сервиса: приложение, программный модуль либо сервис, осуществляющий поиск и вызов необходимого сервиса из реестра сервисов по описанию сервиса, а также использующий сервис, предоставляемый провайдером сервиса, в соответствии с интерфейсом сервиса;
провайдер сервиса: приложение, программный модуль либо сервис, осуществляющий реализацию сервиса в виде веб- сервиса, прием и исполнение запросов пользователей сервиса, а также публикацию сервиса в реестре сервисов;
реестр сервисов: библиотека сервисов, предоставляющая пользователям сервиса средства поиска и вызова необходимого сервиса и принимающая запросы провайдеров сервисов на публикацию сервисов.
Каждый компонент может играть либо лишь одну роль (быть, например, только пользователем сервиса) либо одновременно сразу несколько ролей (например, быть провайдером одних сервисов и пользователем других).
13
Взаимодействие между компонентами сервисно-ориентированной архитектуры
В ходе взаимодействия друг с другом компоненты сервисно-ориентированной архитектуры выполняют следующие основные операции:
публикация: для того, чтобы сервис был доступным (вызываемым) пользователям сервиса, необходимо сделать его интерфейс известным им;
поиск: пользователь сервиса должен иметь возможность найти в реестре сервисов необходимый сервис, удовлетворяющий заданным критериям;
связывание и вызов: после получения описания сервиса, пользователь сервиса должен иметь возможность вызвать и использовать сервис в соответствии с описанием сервиса.
Рассматривая взаимодействие компонентов сервисно-ориентированной архитектуры необходимо отметить наличие (и различие) следующих двух артефактов:
описание сервиса: определяет формат запроса и отклика при взаимодействии пользователя сервиса и провайдера сервиса, а также требуемое качество сервиса;
сервис: собственно сервис, который может быть вызван и использован пользователем сервиса в соответствии с опубликованным интерфейсом сервиса.
14
Свойства веб-сервисов
Чтобы архитектура стала ориентированной на сервисы, сами сервисы должны удовлетворять следующим критериям:
Сервисы слабо связаны с бизнесом и между собой
Взаимодействие сервисов определяется контрактами
Сервисы изолируют внутреннюю логику от окружающего мира
Сервисы допускают возможность композиции
Сервисы могут использоваться многократно
Сервисы являются самоуправляемыми
Сервисы не имеют собственного состояния
Сервисы должны быть обнаруживаемыми
15
Сервисы слабо связаны с бизнесом и между собой
В контексте автоматизации мера связанности отражает зависимость в отношениях между предметом автоматизации и поддерживающей автоматизируемые процессы логикой. В жестко связанных простых технических системах автоматизации эта связь является абсолютной; так было с первого регулятора Уатта и до современных технических систем. В конечном итоге степень связанности определяется природой автоматизируемого объекта: чем он проще, тем проще регулятор. Бизнес с системной точки зрения сложен, его можно представить в виде сервисов и автоматизировать посредством отдельных сервисов, отношения с которыми выстраиваются на основе определенных контрактов.
16
Взаимодействие сервисов определяется контрактами
Базисом для сервисов, в зависимости от их природы, могут быть узаконенная (допустимая) или техническая совокупность правил. Это положение относится прежде всего к сервисному контракту. В этом контракте в случае технических сервисов, определен программный интерфейс, коммуникационные требования, ограничения, свойства, политика использования и даже определенные преференции. Тот программный модуль, который хочет стать пользователем сервиса, должен следовать контрактным условиям, причем он должен рассчитывать и на возможную недостаточную «компетентность» сервиса, то есть на его неспособность в полной мере выполнить желания заказчика.
17
Сервисы изолируют внутреннюю логику от окружающего мира
Вся информация о сервисах, за исключением контрактной, скрыта от окружения; этим, собственно, и обеспечивается слабая связанность и возможность интерпретировать сервис как «черный ящик». Преимущество такого представления заключается в минимизации влияния на клиентские программы, использующие сервисы, в случае каких-то действий по модернизации внутри сервисов.
18
Перечисленные признаки сервисов — слабая связанность, контрактное взаимодействие и внутренняя замкнутость — образуют триаду, на основе которой строится взаимодействие между сервисами. Такое взаимодействие отличается предсказуемостью, но одновременно обладает достаточным потенциалом для динамической перестройки инфраструктуры. Эта триада обеспечивает главные достоинства SOA.
19
Сервисы допускают возможность композиции
Изолированность внутреннего содержания сервисов не исключает возможности для инкапсуляции. Композиция из нескольких сервисов может быть оформлена в виде сервиса следующего уровня, предназначенного для решения определенной задачи.
20