Сегодня:

Моделирование ресурсов с состоянием посредством Web-служб

Ian Foster, Jeffrey Frey, Steve Graham, Steve Tuecke, Karl Czajkowski, Don Ferguson

Введение
Архитектура Web-служб [WS-ARCH] определяет ориентированную на службы модель распределённого компьютинга, в которой службы взаимодействуют, обмениваясь XML-документами. Базовые элементы архитектуры Web-служб определяют синтаксис для обмена информацией. В настоящее время ведутся различные исследования и разработки, направленные на развитие этой базовой архитектуры посредством дополнительных соглашений, позволяющих взаимодействующим службам, используя стандарты, демонстрировать более сложную функциональность, включая аутентификацию, транзакции и надёжную передачу сообщений [Web Services].
В этой статье мы предлагаем набор соглашений, направленных на формализацию взаимодействий с состоянием. Мотивация для этих новых предложений основана на понимании того факта, что есть много способов представления состояния в Web-службах, но не существует установленного соглашения, которое поддерживало бы интероперабельность между Web-службами и их взаимодействие с ресурсами, обладающими состоянием. Даже те реализации Web-служб, которые обычно рассматриваются как не имеющие состояния (stateless), часто используются для оперирования с состоянием, то есть значениями данных, которые сохраняются и изменяются в результате взаимодействий с этой Web-службой. Например, интерактивная система резервирования авиабилетов должна поддерживать состояние, описывающее статус рейсов, резервирование билетов клиентами, и саму систему: её текущее размещением, загрузку и работоспособность. Интерфейсы Web-служб, которые позволяют запрашивать статус рейсов, резервировать авиабилеты, изменять статус сделанных заказов и управлять самой системой резервирования, обязательно должны обеспечивать доступ к такому состоянию.
Суть того, что мы называем WS-ресурс подходом, состоит в моделировании состояния в виде ресурсов с состоянием и кодификации взаимосвязей между Web-службами и ресурсами с состоянием в терминах шаблона неявного ресурса - набора соглашений в рамках технологий Web-служб, в частности, таких как XML, WSDL, WS-Addressing. Мы описываем WS-ресурс в терминах ресурса с состоянием и Web-службы, связанной с ним. Мы также описываем подход к обеспечению доступа к свойствам WS-ресурса средствами интерфейса его Web-службы, и управления временем жизни WS-ресурса.
Эта работа содействует идущим в сообществе Web-служб обсуждениям вопроса, следует ли использовать Web-службы для представления состояния и как это сделать. В этих дебатах одна точка зрения состоит в том, что "Web-службы не имеют понятия состояния" [Vogels], и что "Взаимодействия с Web-службами не имеют состояния; при этом в качестве одного из способов моделирования взаимодействий с состоянием предлагается учет контекста" [Parastatidis]. В то же время другие, включая авторов, утверждают, что критически важная роль, которую играет состояние при распределённом компьютинге, требует, чтобы состояние учитывалось в рамках архитектуры Web-служб [Physiology]. Конструкция WS-ресурса может помочь примирить эти две позиции, показывая как можно прямо формализовать отношения между web-службами и состоянием, опираясь на другие спецификации Web-служб.
Мы рассматриваем в этой работе концепции и конструкции, которые лежат в основе  WS-ресурс  подхода,  не  отображая  его  в  терминах  конкретных  обменов сообщениями Web-служб. Конкретное отображение,  в виде набора спецификаций.
2 Истоки Web-служб
Прежде чем мы определим средства, с помощью которых Web-службы могут быть связаны с ресурсами, обладающими состоянием, нам необходимо пояснить несколько терминов и понятий.
2.1 Что такое Web-служба
Термин Web-службы появился в 2000 году в связи с введением таких технологий как SOAP, WSDL и UDDI. Одновременно с этим вошел в обращение термин ориентированная на службы архитектура, который использовался для описания общего подхода к построению слабо связанных распределённых систем, компоненты которых минимально согласованы между собой. Многочисленные публикации и практические разработки существенно продвинули понимание этих понятий участниками сообщества информационных технологий.
В то время как отдельные технологии, например, SOAP, WSDL и UDDI достаточно хорошо определены, пока не удаётся выработать повсеместно принятое определение термина:
Web-служба - это система программного обеспечения, предназначенная для поддержки интероперабельного взаимодействия между компьютерами в сети. Её интерфейс определен в удобном для компьютерной обработки формате (а именно, на языке WSDL). Другие системы взаимодействуют с Web-службой так, как это предписано ее описанием, и используют для этого SO AP-сообщения, обычно транспортируемые по протоколу HTTP совместно с другими Web-стандартами.
Ориентированная на службы архитектура определяет распределённую систему в виде совокупности агентов, известных как службы, действующих согласованно посредством обменов сообщениями. Процитируем ещё одно определение из [WS-Arch]:
представляет собой распределённую систему особого типа, в которой агентами являются "службы ". Служба - это программный агент, который выполняет строго определённую операцию (то есть "обеспечивает некую услугу") и может быть вызван вне контекста более крупной прикладной программы. Другими словами, хотя служба может быть реализована как экспонирование свойств более крупной прикладной программы, пользователям этой услуги необходимо всего лишь знать описание интерфейса данной службы. "Службы" имеют адресуемые в сети интерфейсы и общаются, используя стандартные протоколы и форматы данных.

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

Этот интерфейс предполагает, что служба управляет набором документов, описывающих сделанные заказы. Программист может также извлечь идентификатор заказа из сообщений, объявленных в интерфейсе службы. Главное положение настоящей работы состоит в том, что желательно представлять такие отношения между Web-службами и состоянием явно и стандартным образом, вместо того, чтобы полагаться на интуитивные предположения. Мы утверждаем, что такое открытое и стандартизированное представление повысит интероперабельность служб, упростит определение интерфейсов новых служб и даст возможность создавать более совершенные средства обнаружения, управления службами и инструментарий для их разработки.
2.2 Среда Web-служб
Начнём с рассмотрения нескольких важных аспектов Web-службы, которые требуют дополнительного обсуждения. Они представлены в виде компонент среды Web-служб, показанной на Рис.1 и объясняются ниже.

Рисунок 1 — Компоненты, связанные с Web-службами

Здесь Web-служба (помечена 1) представляет собой программную компоненту, выполняющую некоторую функцию, например, оформляющую заказ на покупку. Web-службы могут проводить операции, которые имеют доступ к состоянию, хранящемуся на других ресурсах системы. Web-служба - это компонента, которая устанавливается в некоторой исполнительной среде (2), например, Web-сервера приложений, такого как IBM \?еЪ8рЬеге или JBoss. Эта среда обеспечивает размещение Web-службы и диспетчеризацию предназначенных ей сообщений. Исполнительная среда может также предоставлять Web-службе другие услуги, например, такие как обеспечение безопасности или обработка транзакций.
Интерфейс Web-службы (3), представленный на языке описания Web-служб, например, WSDL [WSDL 1.1], определяет функциональность Web-службы в терминах набора операций, которые могут быть вызваны другими сущностями в распределённой системе, называемыми заказчиками службы (service requestors). Каждая операция описывается в терминах конструкций обмена сообщениями, которые определяют как формат сообщения, используемого для вызова операции, так и форматы возможных ответных сообщений, в том числе сообщений об ошибках.
В исполнительной среде имеется средство (4) обработки сообщения, которое может получать сообщения (5) от заказчиков. Эта компонента способна поддерживать один или более сетевых транспортных протоколов, таких как HTTP, SMTP или IIOP, и на практике её часто называют крайняя точка (endpoint), поскольку именно эта компонента доступна распределенной компьютерной фабрике по конкретному сетевому адресу. Компонента крайней точки также осуществляет перевод конверта сообщения в формат, понимаемый службой (например, преобразует XML-посылку в набор Java-объектов), и (6) переправляет сообщение реализации целевой службы, которая идентифицируется адресом (URL) и другими частями сообщения. Следует отметить, что хотя Web-службы создаются (или, как мы иногда говорим, устанавливаются) в исполнительной среде по адресу конкретной крайней точки (то есть уникального в сети имени сообщения, обрабатываемого исполнительной средой), тем не менее, каждая Web-служба сама уникально идентифицируется посредством адреса, представляющего собой объединение адреса её крайней точки, по которой установлена служба, и некоторого дополнительного идентификатора, специфического для данной Web-службы.
Реализация Web-службы принимает сообщение, обрабатывает его, при этом, возможно взаимодействуя с другими службами и ресурсами с состоянием (7) - и, если это предусмотрено при данном обмене, форматирует и отправляет ответное сообщение. Многие Web-службы сами играют роль заказчика услуги, инициируя обмен сообщениями с другими Web-службами.
2.3 Краткая систематизация состояния и служб
Строгая систематизация интерфейса, состояния и экземпляров выходит за рамки настоящей работы. Тем не менее, чтобы подготовить контекст для следующего ниже материала, мы дадим краткий обзор возможных связей состояния с интерфейсом.

В данной работе мы рассматриваем вопросы, касающиеся третьей модели. Мы считаем, что подходы, основанные на передаче контекста исполнения в заголовках сообщений, подобные тем, что введены спецификациями WS-Coordination, WS-Context и WS-Policy, обеспечивают средства, с помощью которых можно реализовать вторую модель.
2.4 Реализации без состояния, интерфейсы с состоянием
Необходимо подчеркнуть, что, говоря в третьей модели о службе, которая работает с ресурсами, обладающими состоянием, мы имеем в виду службу, чья реализация (implementation), оперирует с динамическим состоянием, то есть состоянием, за которое служба несёт ответственность между обменами сообщениями с её заказчиками.
Служба, которая оперирует с ресурсами, обладающими состоянием, может быть описана как не имеющая состояния ("stateless"), если она делегирует ответственность за управление состоянием другой компоненте, например, базе данных или файловой системе. Отсутствие состояния при реализации службы имеет своей целью повышение степени надёжности и масштабируемости: Web-службу без состояния можно повторно запустить после отказа, не заботясь при этом, какова история её предыдущих взаимодействий, а при изменении нагрузки можно создать (а впоследствии уничтожить) и новые копии такой Web-службы. Поэтому отсутствие состояния, вообще говоря, рассматривается как хорошее инженерное решение при реализации Web-служб.
Следствием отсутствия состояния является то, что любое динамическое состояние, необходимое для выполнения данной операции обмена сообщениями, должно быть:

Конечно, Web-служба может быть реализована так, что она может работать со статическим состоянием (например, с заранее конфигурированными ссылками на другие системные компоненты).
Третья модель характеризует службу, которая оперирует с ресурсами, обладающими состоянием, и допускает, что реализация Web-службы без состояния будет часто использовать и обновлять динамическое состояние, поддерживаемое в других системных компонентах, например, в базе данных. В таких случаях уникальное имя элемента(ов) состояния может либо быть передано в сообщении запроса, либо поддерживаться как статические данные Web-службой. Интерфейс, предлагаемый такой Web-службой, конечно, обладает состоянием в том смысле, что его поведение определено с учётом нижележащего состояния.
3 Моделирование состояния в Web-службах
Мы уже отмечали, что даже тогда, когда сама реализация Web-службы может быть описана как не обладающий состоянием процессор сообщений, обмены сообщениями, которые он реализует (как это определено его интерфейсом), часто предназначены для обеспечения возможности доступа и/или обновления состояния, поддерживаемого другими системными компонентами, будь то база данных, файловые системы или другие объекты.
Учитывая ту существенно важную роль, которую играет доступ к состоянию во многих интерфейсах Web-служб, важно идентифицировать и стандартизировать шаблоны, используя которые можно представлять и обрабатывать состояние, так чтобы облегчить построение и использование интероперабельных служб.
С этой целью мы предлагаем подход к моделированию ресурсов с состоянием в инфраструктуре Web-служб, основанный на конструкции, которую мы называем WS-ресурс (WS-Resource). Более конкретно, мы предлагаем средства, с помощью которых:

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

Примерами системных компонент, которые могут моделироваться как ресурсы с состоянием, являются файлы в файловой системе, строки в реляционных базе данных и инкапсулированные объекты, например такие, как сущности Entity Enterprise Java beans. Ресурс с состоянием также может быть совокупностью или группой других ресурсов с состоянием.
Следует подчеркнуть, что это определение касается того, как ресурс с состоянием моделируется, а не того, как он реализован или представлен. Конкретное состояние ресурса может быть реализовано в виде фактически существующего XML-документа, который хранится в памяти, в файловой системе, в базе данных или в некотором XML-репозитарии. Альтернативно, тот же самый ресурс с состоянием может быть реализован в виде некой логической проекции данных, динамически сконструированной или сформированной из объектов языка программирования (например, такого как J2EE EJB Ешігу Bean) или из данных, полученных в результате обращения по частному коммуникационному каналу к обычной системе данных или приложению.
Для данного типа ресурса с состоянием может быть создано и уничтожено множество независимых экземпляров. Как мы покажем в Разделе 4, экземпляр ресурса с состоянием может быть создан с помощью Web-службы, называемой фабрикой ресурсов с состоянием.
В Разделе 5 мы покажем, что ресурс с состоянием определяется посредством глобальной декларации элемента (Global Element Declaration - GED) XML в заданном пространстве имён. Эта декларация определяет тип корневого элемента XML-документа ресурса и, следовательно, тип самого ресурса с состоянием.
Сущность, создающая экземпляр ресурса с состоянием, может присвоить ему уникальное имя. Приложения, использующие этот ресурс, также могут присваивать ему дополнительные уникальные имена (псевдонимы). Конкретная форма уникального имени ресурса с состоянием может конфиденциально использоваться одной или несколькими реализациями Web-служб, чтобы идентифицировать его при выполнении данного обмена сообщениями. Использование идентификатора ресурса с состоянием при обработке сообщения Web-службы обсуждается в следующем разделе.
3.2 Шаблон неявного ресурса
Определив способ моделирования элементов состояния ресурсов с состоянием, вернёмся к вопросу о том, как заказчики Web-служб могут ссылаться на ресурсы с состоянием. Для того чтобы описывать конкретный вид отношения между Web-службой и одним или более ресурсами с состоянием, мы предлагаем использовать конструкцию, называемую шаблон неявного ресурса (implied resource pattern).
Шаблон неявного ресурса указывает на механизм, используемый для связывания ресурса с состоянием с выполнением обменов сообщениями, реализуемым Web-службой.
Термин неявный используется потому, что при выполнении запроса ресурс с состоянием, связанный с данным обменом, трактуется как неявный ввод. Используя слово неявный, мы хотим подчеркнуть, что заказчик услуги не указывает в теле запроса идентификатор этого ресурса в качестве явного параметра. Вместо этого, ресурс неявно ассоциируется с выполнением обмена. Это может быть осуществлено либо статически, либо динамически. Мы говорим, что ресурс с состоянием ассоциируется с Web-службой статически, если связывание происходит при установке Web-службы. Мы говорим, что ресурс с состоянием ассоциируется с Web-службой динамически, когда связывание происходит во время выполнения обмена сообщениями. При динамическом связывании идентификатор ресурса служит указанием того, что этот неявный ресурс, может быть инкапсулирован в предусматриваемой WS-Addressing-спецификацией ссылке на крайнюю точку, которая используется для адресации целевой Web-службы.
Мы используем термин шаблон, чтобы показать, что отношения между Web-службами и ресурсами с состоянием подчиняются набору соглашений, касающихся использования существующих технологий Web-служб, в частности XML,
Определенная в спецификации WS-Addressing ссылка на крайнюю точку представляет собой XML-сериализацию глобального сетевого указателя Web-службы. Этот указатель может быть возвращен в качестве результата обращения к фабрике Web-служб с запросом о создании нового ресурса, или как результат запроса на поиск в реестре ресурсов, или же, как результат выполнения некоторого специфического Web-приложения.
Спецификация WS-Addressing стандартизирует конструкцию ссылки на крайнюю точку, используемую для представления адреса Web-службы, установленной в данной сетевой крайней точке. Ссылка на крайнюю точку кроме адреса крайней точки Web-службы может содержать другие метаданные, ассоциированные с Web-службой, например такие, как информацию описания службы и свойства ссылки, которые помогают определить контекстуальное использование ссылки на крайнюю точку. Свойства ссылки на крайнюю точку играют важную роль в шаблоне неявного ресурса.
Отметим, что для обеспечения доступа к ресурсам с состоянием можно использовать и другие шаблоны. Например, Web-служба могла бы управлять уникальным именем ресурса, в виде статического состояния службы, тем самым, устраняя необходимость передачи этого имени в WS-Addressing-ссылке на крайнюю точку. Выбор такой конструкции подразумевает взаимно-однозначное отображение множества ссылок на крайние точки Web -служб на множество ресурсов с состоянием и, тем самым, необходимость в уникальной крайней точке Web-службы для каждого ресурса с состоянием.
3.3 WS-ресурс и спецификация WS-Addressing
Мы называем WS-ресурсом компоненту, которая представляет собой композицию Web-службы и связанного с ней ресурса с состоянием, участвующего в шаблоне неявного ресурса.
Рассмотрим соглашения, касающиеся использования спецификации WS-Addressing в шаблоне неявного ресурса. На Рисунке 2 WS-Addressing-ссылка на крайнюю точку удовлетворяет соглашениям о шаблоне неявного ресурса.

Рисунок 2 - Ссылка на крайнюю точку, содержащая идентификатор ресурса с
состоянием.

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

В XML-сериализации идентификатора ресурса с состоянием содержится специальный XML-элемент для представления информации об идентификаторе ресурса, которая должна игнорироваться заказчиком службы. Приложения заказчика службы не должны проверять или пытаться интерпретировать содержимое идентификатора ресурса с состоянием. Идентификатор ресурса с состоянием понятен только Web-службе и используется ею для идентификации WS-ресурса, связанного с ресурсом с состоянием, который нужен для выполнения поступившего запроса, так, как это принято в реализации данной Web-службы.
Идентификатор ресурса с состоянием должен идентифицировать уникальный ресурс с состоянием, который будет использоваться при выполнении поступившего запроса. Не требуется, чтобы значение этого идентификатора было уникальным вообще, но оно должно быть пригодным для Web-службы настолько, чтобы она могла использовать его для однозначной идентификации имеющегося в виду WS-ресурса, связанного с ресурсом с состоянием. Другими словами область действия идентификатора ресурса с состоянием должна быть уникальной внутри области действия Web-службы и может быть уникальной вне этой области. Кроме того, различные идентификаторы внутри области действия Web-службы могут ссылаться на один и тот же WS-ресурс.
С точки зрения заказчика ссылка на крайнюю точку представляет собой указатель (pointer) на WS-ресурс, включающий Web-службу, которая в дальнейшем, возможно, будет настроена на обмен сообщениями с конкретным ресурсом с состоянием. Заказчик услуги должен понимать, что ссылка на крайнюю точку указывает на WS-ресурс. Другими словами заказчик услуги должен распознать, что ссылка на крайнюю точку является квалифицированной ссылкой на крайнюю точку WS-ресурса. Использование квалифицированной ссылки на крайнюю точку WS-ресурса иллюстрируется на Рисунке 3.

Рисунок 3 - Использование квалифицированной ссылки на крайнюю точку WS-ресурса.

Приложения заказчика услуги должны использовать ссылку на крайнюю точку (помеченную 1 на Рисунке 3), чтобы посылать сообщения (2) идентифицированной Web-службе (3). Поскольку в ResourceProperties-компоненте ссылки на крайнюю точку WS-ресурса содержится идентификатор ресурса с состоянием, то всякий запрос, направленный службе, использующей эту ссылку на крайнюю точку, должен включать идентификатор ресурса с состоянием.
Заметим, что \У8-К.е8оигсеРгорегіїе8-компонента \У8-Асісіге88Іп§ сообщения обрабатываются в соответствии с конкретным способом связывания. WS-Addressing-спецификация предусматривает, что ResourceProperties-компонента ссылки на крайнюю точку должна являться частью любого сообщения, посланного Web-службе, идентифицированной ссылкой на крайнюю точку. Каждый тип WSDL-связывания должен декларировать как должны представляться дочерние элементы ResourceProperties-элемента в сообщениях, использующих такое связывание. Например, спецификация WS-Асісіге88Іп§ устанавливает, что КезоигсеРгорегиез-элементы должны появиться в сообщении в виде элементов SOAP-заголовка. На Рисунке 3 компонента, помеченная (4) показывает использование SOAP-заголовка для передачи идентификатора ресурса с состоянием, в данном случае представляющего ресурс с именем "С". Web-служба (3) затем извлекает идентификатор ресурса из SOAP-сообщения и использует его для определения местоположения ресурса, необходимого для выполнения поступившего запроса.

[первоисточник]