Организация распределенной обработки

информации на основе Web-технологий

3.1. Особенности интеграции приложений

в сети Интернет

Рассмотренные в предыдущем разделе технологии и механизмы реализации распределенной обработки информации спроектированы главным образом для работы в масштабе отдельной локальной вычислительной сети. К настоящему времени особую актуальность приобрела необходимость автоматизации взаимодействия удаленных предприятий и компаний (а также их филиалов) посредством глобальной информационно-коммуникационной сети Интернет. Технически такое взаимодействие означает вызов службы, размещенной в другой компании. Расширение на Интернет достигается соединением нескольких систем друг с другом. В системах с брокерами объектов это делается с помощью обобщенного межброкерного протокола GIOP, который определяет, каким образом вызов от одного брокера передается другому и как назад отправляется ответ на вызов. Протокол GIOP расширен и превращен в межброкерный протокол Интернета IIОР (см. раздел 2.2). В протоколе IIОР определено, как транслировать вызовы протокола GIOP в вызовы стека протоколов TCP/IP (Transmission Control Protocol/Internet Protocol – протокол управления передачей/межсетевой протокол), которые уже можно посылать в Интернет.

На практике брокеры соединены с Интернетом через межсетевые экраны, которые существенно ограничивают взаимодействие. Межсетевой экран – барьер на пути нежелательного сетевого трафика, который блокирует многие коммуникационные каналы, в том числе почти все виды взаимодействия, предлагаемые традиционными продуктами интеграции предприятий. Поэтому в Интернете проблематично рассчитывать на использование удаленных вызовов процедур, удаленных обращений к методам и протоколов GIOP/IIOP. Другим препятствием является различие определений интерфейсов и форматов данных, применяемых в разных приложениях. При наличии межсетевых экранов также невозможно осуществлять прямое взаимодействие интегрируемых систем.

Для проникновения сквозь межсетевые экраны применяется, например, механизм так называемого туннелирования. Протоколы, которые могли бы быть заблокированы межсетевыми экранами, «скрываются» под протоколами, которые этими экранами допускаются. Чаще всего таким протоколом является HTTP (Hyper Text Transfer Protocol – протокол передачи гипертекста). В этом случае посредническая программа упаковывает исходное сообщение в документ на языке HTML, посылает его по протоколу HTTP, а после прихода документа к получателю извлекает сообщение.

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

Традиционные подходы к построению распределенных систем и традиционные методы интеграции приложений направлены на интеграцию автономных систем и автоматизацию бизнес-процессов, распространяющихся на несколько таких систем. Применение традиционных подходов требует от участников взаимодействия достижения соглашения по использованию и совместному управлению конкретной системной платформой. Этот подход не всегда пригоден, поскольку трудно достичь необходимого уровня доверия между участниками. Другой причиной непригодности традиционного подхода является неверность предположений, делавшихся при интеграции предприятий (длительность взаимодействия в сети Интернет препятствует применению традиционных протоколов типа 2РС – они блокируют ресурсы на слишком большой срок, делая невозможным параллельное выполнение других операций).

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

Протоколы, с которыми работают сетевые службы, должны быть пригодны для работы без выделенных серверов. Традиционные протоколы (2PC) работают с центральным транзакционным координатором, который обладает возможностями блокировать ресурсы. Протокол 2РС и другие протоколы взаимодействия и координации должны быть модифицированы, чтобы работать в децентрализованном режиме в отсутствии доверительных зон и гибко проводить блокировки.

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

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

3.2. Общая характеристика и архитектура сетевых служб

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

При описании сетевых служб применяется стек языков описания, в котором каждый элемент более высокого уровня использует и уточняет описание нижнего уровня. В качестве общего метаязыка в настоящее время используется язык XML, который широко распространен, имеет гибкий синтаксис и позволяет определять языки описания и протоколы служб. При описании интерфейсов сетевой службы дополнительно указывается ее адрес и транспортный протокол. Наиболее используемым является язык описания WSDL (Web-Service Definition Language – язык описания Web-служб). Обмены между службами, проходящие в определенном порядке, называются разговорами. Набор правил, регулирующих разговоры, называется бизнес-протоколом.

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

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

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

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

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

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

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

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

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

3.3. Механизм взаимодействия сетевых служб

по протоколу SOAP

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

Сетевые службы основывают взаимодействия на простом протоколе доступа к объектам SOAP (Simple Objekt Access Protocol). Этот протокол не детализирует свойства конкретного обмена информацией, а задает шаблон обобщенного сообщения. Для указания конкретных свойств над протоколом SOAP делаются дополнительные надстройки.

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

Протокол SOAP может использоваться двумя разными способами: в стиле документов и в стиле RPC. В первом случае происходит асинхронный обмен документами, второй случай отличается тем, как построено тело сообщения. В нем непосредственно содержатся имя вызываемого метода и его параметры. Дополнительные свойства удаленной процедуры (указание транзакционного контекста) содержатся в заголовке. Сообщения, пересылаемые по протоколу SOAP, подчиняются правилам кодирования, которые определяют, каким образом конкретная структура будет представлена в XML. Клиент и сервер должны договариваться о выбранном способе представления данных. Разные методы кодирования приводят к разному представлению сообщений в XML. Различия возникают на стадии принятия решения о том, как передаются параметры сообщений (удаленных процедур) – значениями атрибутов исходного элемента или в виде вложенных элементов.

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

Реализация взаимодействия на основе SOAP очень напоминает реализацию RPC. Клиент делает вызов процедуры, являющийся обращением к процедуре-заместителю, размещенной в переходнике. Переходник перенаправляет вызов в подсистему SOAP, где вызов преобразуется в XML-докуменг. Полученное сообщение преобразуется к формату HTTP и передается на удаленный сервер. Там происходят обратные преобразования: модуль HTTP, получив сообщение, передает его в подсистему SOAP, где снимается оболочка HTTP, извлекается XML-документ, а его содержимое передается серверному переходнику, который вызывает нужную процедуру. Обратно от сервера клиента в том же порядке передается результат работы процедуры.

Протокол SOAP может работать и в асинхронном режиме. При этом запросы отправляются с помощью системы очередей, а в качестве транспортного протокола используется протокол SMTP (Simple Message Transfer Protocol – простой протокол передачи сообщений).

3.4. Язык описания сетевых служб WSDL

Язык описания WSDL, основанный на XML, играет в сетевых службах такую же роль, как язык IDL в традиционных системах. Интерфейс описывается в терминах методов, которые поддерживаются сетевой службой, а каждый метод может принимать одно сообщение на входе и возвращать другое сообщение на выходе. В терминах удаленного вызова процедуры эти сообщения содержат входные и выходные параметры вызовов процедур. Файлы с описаниями транслируются в соответствующий язык программирования, при этом генерируются переходники и программы-посредники, делающие обращения к сетевым службам прозрачными. Язык WSDL прячет сетевые службы за некоторым интерфейсом, то есть вызовом метода. Инфраструктура сетевой службы использует WSDL и SOAP для конструирования заместителей объектов на сторонах поставщика и потребителя, поэтому разработчики могут программировать свои приложения так, как если бы они выполняли локальные вызовы. Кроме спецификации операций, предлагаемых службой (как в IDL), необходимо описывать механизм доступа к этой службе.

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

Спецификации WSDL делят на две части – абстрактную и конкретную (определяющую протоколы связывания и другую информацию). Абстрактная часть построена на определениях типов портов, аналогичных традиционным интерфейсам. Типы портов есть логические наборы операций, определяющих обмен сообщениями. Для правильной интерпретации данных на обоих концах взаимодействия необходимо определить их типы. Сообщения в WSDL представляют собой текстовые документы, разделенные на части, каждая из которых характеризуется именем и типом (тип ссылается на тип XML). Вызывая процедуру с двумя параметрами, надо определить сообщение из двух частей, одна из которых будет содержать первый параметр, а другая – второй.

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

Конкретная часть интерфейса WSDL определяется с помощью следующих трех конструкций. Интерфейсное связывание определяет тип кодирования сообщений и привязку к протоколу для всех операций и сообщений, заданных для данного типа порта. Можно определить, что данная операция имеет стиль удаленного вызова процедуры или стиль документа. Интерфейсное связывание может определять, что сообщения некоторой операции должны пересылаться с использованием протокола SOAP с привязкой к протоколу HTTP. Здесь же специфицируются правила кодирования, на основе которых сообщения сериализуются в XML. Порты соединяют информацию интерфейсного связывания с адресами сети. В традиционных системах это не нужно, но для сетевых служб – необходимо. Службы являются логическими группами портов. Это означает, что WSDL-служба может оказаться доступной в Интернете по разным адресам. На практике наиболее частой оказывается ситуация, в которой в одной службе группируются близкие по семантике порты, расположенные в одном месте. Часто в службу включаются порты одного типа, но имеющие привязки к разным протоколам.

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

3.5. Проблемы регистрации сетевых служб

Чтобы сетевые службы имели глобальный характер, процесс опубликования сведений о них и их поиск должны быть стандартизованы. Примером является универсальная система описания, поиска и взаимодействия UDDI (Universal Difinition Detection Integration), состоящая из реестра и прикладного программного интерфейса. Реестр эквивалентен серверу именования. Прикладной интерфейс UDDI определяет, как опубликовать службу, что необходимо для регистрации, как делать запросы к службе. Информация в реестре используется для написания клиентских программ и для обеспечения динамического поиска службы. Информация, занесенная в реестр UDDI, группируется в алфавитном порядке имен предприятий, поставляющих сетевые службы для использования, по тематике, к которой относится как деятельность поставщиков, так и сами сетевые службы, и по способам вызова сетевых служб (в виде ссылок на документы, хранящиеся вне реестра).

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

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

Работу с реестром могут проводить поставщики служб, клиенты и другие реестры. Для разных типов пользователей реестры поддерживают разные точки входа, взаимодействие с которыми осуществляется посредством обмена ХМL-документами (обычно по протоколу SOAP). Реестр имеет разные виды прикладного программного интерфейса. Интерфейс запросов реестра содержит операции для поиска записей и операции, позволяющие получить описания объекта. Интерфейс используется разработчиками и клиентами для динамической привязки. Интерфейс публикации реестра предназначен для поставщиков служб. Интерфейс безопасности реестра позволяет пользователям проходить аутентификацию. Интерфейс надзора и передачи прав владения реестра позволяет передавать часть своих прав от одного поставщика служб другим. В любых условиях владельцем записей в реестрах всегда является реестр, в котором запись была первоначально создана. Модификации записей проводятся только в реестрах-владельцах, но права можно передать другим реестрам в явном виде. Интерфейс подписки на реестр позволяет подписываться на новые или модифицированные службы. Интерфейс репликации помогает реплицировать информацию, обеспечивая синхронность различных реестров.

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

3.6. Координация работы сетевых служб

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

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

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

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

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

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

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

Стандарт WS-Coordination (координация Web-служб) определяет метод передачи уникальных идентификаторов сетевым службам, взаимодействующим между собой. В частности, при этом определяется координационный контекст и то, как он включается в заголовки сообщений SOAP. С помощью интерфейса регистрации портов определяется метод передачи контроллерам разговоров сведений о портах участников разговоров. С помощью интерфейса активации определяется метод передачи контроллерам разговоров сведений об их ролях в разговоре. Взаимодействие между координаторами и участниками разговоров может осуществляться централизованно и распределенно.

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

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

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

Отличие децентрализованной координации от централизованной заключается в том, что участники могут регистрироваться у разных координаторов (каждый из них создает свой контекст), а координаторы должны регистрироваться друг у друга (один из них объявляет себя координатором всего взаимодействия, а другие участвуют в качестве посредников). Таким образом могут строиться цепочки произвольной сложности. В соответствии со стандартом WS-Coordination координаторы могут транслировать сообщения одного протокола, получаемые от их участников, в сообщения другого протокола, передаваемые другому координатору. Это требует реализации зависящих от конкретных протоколов компонентов, выполняющих активацию и регистрацию.

3.7. Транзакции в сетевых службах

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

Стандарт WS-Transaction (транзакция Web-служб) определяет набор протоколов, требующих скоординированной работы нескольких сторон и строится на базе протокола WS-Coordination. Стандарт WS-Transaction предполагает существование набора сетевых служб, участвующих в транзакции и одного или нескольких координаторов (централизованных или распределенных). Стандарт WS-Transaction также определяет структуру координационного контекста и стандартные WSDL-интерфейсы, которые должны реализовываться участниками и координаторами. Стандарт WS-Transaction определяет стандартный протокол для долгих транзакций, называемых «бизнес-активностями». Для работы с короткими транзакциями в доверительных зонах стандарт WS-Transaction определяет также набор спецификаций, называемых атомарными транзакциями.

Тип атомарных транзакций состоит из нескольких координационных протоколов, исполняемых сетевыми службами – участниками или координаторами, в зависимости от того, что должно делаться на протяжении той или иной фазы распределенной транзакции. В этот координационный тип входят следующие протоколы: завершения, 2РС, завершения с уведомлением, нулевой фазы и уведомления о результате. Протокол завершения нужен для информирования координатора о необходимости инициирования протокола 2РС и опроса участников об успешности транзакции. В некоторых случаях координатор до выполнения протокола 2РС проводит с участником обмен по протоколу нулевой фазы, оповещая его о предстоящем начале выполнения протокола 2РС. Участник может провести подготовительные работы (например, сбросить информацию из буферов). Участник может запросить координатора о результате транзакции, выполняя протокол уведомления. Протокол завершения с уведомлением может инициироваться сетевой службой вместо обычного протокола завершения в тех случаях, когда нужно, чтобы координатор хранил результат транзакции, не уничтожая его до получения специального уведомления от сетевой службы о том, что этот результат ею получен. Для каждого из пяти протоколов стандарт вводит по два типа портов, которые должны быть реализованы координатором. Один из этой пары типов портов позволяет координатору выполнять протоколы в качестве координатора (для организации координационных цепочек), а второй – выполнять протоколы в качестве участника. Сетевые службы всегда являются только участниками взаимодействий.

Стандарт WS-Transaction определяет структуру транзакционного контекста. Эта структура возвращается координатором в ответ на запрос о создании координационного контекста. Она же передается как часть заголовков сообщений SOAP и показывает, что сообщение посылается в рамках некоторого разговора.

Для управления длительными бизнес-транзакциями без блокировки ресурсов используется протокол 2РС и координационный тип, называемый бизнес-активностью, который содержит два протокола: бизнес-соглашение и бизнес-соглашение с завершением. Протокол бизнес-соглашения проводится участником для информирования координатора о состоянии выполнения (прервано, завершено, завершено с ошибкой). Координатор отвечает всем участникам сообщениями типа «закрыть», «завершить», «компенсировать» или «забыть». Протокол бизнес-соглашения с завершением отличается тем, что дает возможность участнику подготовиться к операциям завершения или компенсации. Координатор соответственно имеет две пары типов портов (одна пара – для простого соглашения, а вторая – для соглашения с завершением).

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

3.8. Композиция сетевых служб

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

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

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

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

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

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

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

Компонентная модель определяет объединяемые элементы в терминах предположений о таких компонентах. Оркестровая модель определяет абстракции и языки, используемые для определения порядка вызова служб. Модель данных и доступа к данным определяет методы описания данных и обмена данными между компонентами. Модель выбора службы определяет способ статической или динамической привязки. Транзакционная модель определяет транзакционную семантику, которая ассоциирована с композицией.

В компонентной модели одни службы отличаются от других типами компонентов и предположениями об этих компонентах. Модель может предполагать, что компоненты реализуют некоторый набор стандартов (HTTP, SOAP, WSDL и WS-Transaction). Такие предположения снижают гетерогенность системы. Предположения можно ограничить, приняв, что компоненты обмениваются XML-сообщениями. Преимущество – большая общность модели, недостаток – усложнение работы из-за гетерогенности. Могут применяться промежуточные решения, приводящие к использованию сложных языков и сложных систем с множеством форматов и протоколов.

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

В модели данных и доступа к данным все данные, используемые при композиции служб, делятся на данные приложений (прикладные данные) и управляющие данные. Прикладные данные – это параметры, посылаемые или получаемые в сообщениях. Управляющие данные используются для вычисления условий перехода, они также используются композиционным мотором при выполнении процесса. Обычно переменных процесса не много и их типы ограничены строковыми, целыми, вещественными, а иногда и составными типами. Значения управляющих данных обычно извлекаются из сообщений, получаемых сетевыми службами. Прикладные данные более сложны и разнообразны.

Для передачи данных между активностями существуют два подхода: журнальный подход и подход явного потока данных. Журнальный подход аналогичен языкам программирования: все данные композитной службы именуются и перечисляются явно. Модификации переменных выполняются при получении сообщения «атомарно», прежние значения переменных стираются. Активности могут иметь разный уровень доступа к переменным (чтение/запись или только чтение). Каждый запуск активности заводит отдельный журнал. Подход явного потока данных требует, чтобы в дополнение к потоку управления явным элементом композиции был поток данных. На диаграммах активностей прорисовываются линии, и разработчик указывает, что входные данные одной активности (используемые, например, для сообщений, составляющих операции) должны выбираться из результатов ранее выполненной активности. Потоки данных гибче журналов, но сложнее: они создают неявные управляющие зависимости, поскольку активности, являющиеся источниками данных, должны завершаться до начала работы активностей, которые эти данные получают.

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

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

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

Резюме

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

Сетевые службы играют ту же роль, что и традиционные промежуточные слои программного обеспечения, но имеют гораздо более широкий масштаб. Сетевые службы основывают взаимодействия на простом протоколе доступа к объектам SOAP. Роль, отведенную в традиционных системах языкам IDL, играет для сетевых служб язык описания WSDL, основанный на XML. Чтобы сетевые службы имели глобальный характер, процесс опубликования сведений о них и их поиск должны быть стандартизованы.

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

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

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

Контрольные вопросы и задания

1. Раскройте содержание понятия «сетевая служба».

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

3. Представьте общую характеристику и архитектуру сетевых служб.

4. Опишите механизм взаимодействия сетевых служб по протоколу SOAP.

5. Охарактеризуйте язык описания сетевых служб WSDL.

6. Перечислите и дайте описание типов базовых операций, имеющихся в языке WSDL.

7. Укажите порядок регистрации сетевых служб.

8. Каким образом осуществляется координация работы сетевых служб?

9. Опишите стандарт координации сетевых служб WS-Coordination.

10. Охарактеризуйте процедуру транзакции в сетевых службах.

11. В чем заключается композиция сетевых служб и каковы ее свойства?