Хореография Web-сервисов: важен контекст

ОБЗОРЫ

Управление контекстами и транзакциями - новое поле, где идет борьба за контроль над WS-стандартами

_____

Продолжение. Начало см. PC Week/RE, N 27/ 2004, с. 20; N 28/2004, с. 19; N 29/2004, с. 18.

Протоколы координации бизнес-процессов с использованием контекста

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

Мы приходим к выводу, что в архитектуре WS должны быть описаны два момента - как группировать сервисы вместе и как передавать им контекст. Наличие явно определяемого контекста в последовательности работ - одно из главных отличий описываемых ниже спецификаций от BPEL4WS, рассмотренной в предыдущей части обзора. Конечно, этот контекст можно создать "руками" и в BPEL4WS - ведь последний фактически представляет собой язык программирования. Но зачем так поступать, если задача уже решена другими средствами?

В области управления контекстами сейчас два основных игрока - группа компаний, возглавляемая IBM, BEA и Microsoft (назовем ее условно IBM$), и группа, возглавляемая Sun и Oracle. Как будет происходить конвергенция их решений - пока не ясно. Решение Sun и Oracle более модульное и полное, хотя политические шансы на победу у набора IBM$ выглядят предпочтительнее.

Передача контекста в Web-сервисной среде

WS-Coordination

Авторы: IBM, BEA, Microsoft.

Статус: авторская спецификация, сентябрь 2003 г.

Связи: WS-Transaction, WS Atomic Transaction, WS Addressing.

Архитектура WS Coordination

Основная спецификация группы IBM$, описывающая механизмы координации Web-сервисных операций. Другие спецификации IBM$, в частности WS Transaction, WA Atomic Transaction и WS Business Activity Framework, опираются на нее и расширяют ее, распространяя на более узкие области управления атомарными и бизнес-транзакциями.

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

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

В среде должно быть три вида вспомогательных служб.

- Сервис активации (Activation Service) предоставляет функции для инициации потока координирующей активности (т. е. создания координатора) и создания контекста на базе указанного протокола координации.

В возвращаемый этим сервисом контекст включается глобально-уникальный URI-идентификатор действия (определяющий и сам контекст), URI координатора, адрес "конечной точки" сервиса регистрации, время жизни контекста, а также дополнительная информация, зависящая от приложений. Отличительной особенностью WS-Coordination является то, что весь контекст целиком передается внутри блока в заголовке SOAP-сообщений, посылаемых участникам (<wscoor:CoordinationContext>). Конкурирующие же спецификации способны передавать ссылку на контекст. В контексте содержится URI транзакции, время ее действия, адрес координатора (используется WS Address) и пр.

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

- Сервис регистрации (Registration Service) позволяет приложению (Web-сервису) регистрироваться для участия в реальных протоколах координации для получения сообщений, генерируемых в рамках этих протоколов. Форма такого участия может быть разной: простой участник, координатор или субкоординатор. Адрес "конечной точки", по которому производится обращение к сервису, получается от сервиса активации. Здесь также применяется асинхронный подход, т. е. приложение указывает адрес Web-сервиса, вызываемого извне для передачи данных внутрь себя. В заголовке запроса на регистрацию приложение посылает контекст действия, а в тело запроса оно включает URI координирующего протокола. В ответ возвращается ссылка на "конечную точку" сервиса координирующего протокола.

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

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

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

Помимо перечисленных возможностей WS-Coordination задает общие рамки для алгоритмов передачи между системами сведений о правах доступа. Для успешной работы требуется: гарантировать, что только авторизованные службы могут создавать координационный контекст и регистрироваться для участия в процессе координации; убедиться, что для регистрации используются только легитимные контексты; использовать существующие инфраструктуры обеспечения безопасности; механизм авторизации должен основываться на федеративном принципе (т. е. участники могут делегировать право гарантирования подлинности). Для решения этих задач WS-Coordination опирается на WS-Security, WS-Trust, WS-Policy и WS-SecureConversation.

Web Services Composite Application Framework (WS-CAF)

Авторы: Sun, Oracle, Iona, Arjuna, Fujitsu.

Статус: авторская спецификация, рабочий документ W3C.

Набор спецификаций на координацию деятельности Web-сервисов, альтернативный тому, что предлагает IBM$. WS-CAF - стандартный многоплатформенный механизм для управления коллективно используемым контекстом, гарантирующий, что бизнес-процесс достигнет предсказуемых результатов и восстановится в случае сбоя. WS-CAF является дополнительной по отношению к другим спецификациям в области безопасности, гарантированной доставки, дирижирования сервисами и транзакций. Немаловажное качество набора - его бесплатность.

WS-CAF делится на три части:

- Web Service Context (WS-CTX) - облегченная среда, просто обеспечивающая передачу контекста и управление им;

- Web Service Coordination Framework (WS-CF) - коллективно используемый механизм для управления расширением контекста и его жизненным циклом, а также гарантирования доставки сообщений;

- Web Services Transaction Management (WS-TXM) - включает три различных протокола для обеспечения взаимодействия разных транзакционных менеджеров и поддерживает многие транзакционные модели (а именно двухфазное подтверждение, длительные транзакции и потоки бизнес-процессов).

Очевидно, что главное отличие от продукта IBM$ - это разделение инфраструктуры управления контекстами и координации. Отдельные части WS-CAF совместимы с технологиями конкурентов - BPEL4WS,WSCI и WS-Choreography, а также с технологиями безопасности Web-сервисов WS-Security и WS-Reliability. Преимуществом своей технологии авторы называют легкость внедрения - можно начать с WS-CTX для простого управления контекстом, затем добавить WS-CF, а потом и WS-TXM. Насколько это важно - неясно, так как все эти технологии будут реализовываться самими вендорами.

Web Service Context (WS-CTX)

Авторы: Sun, Oracle, Iona, Arjuna, Fujitsu.

Статус: авторская спецификация, рабочий документ W3C, 28 июля 2003 г.

Соответствие сервисов разного уровня в модели CTX

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

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

Пример последовательности действий (в том числе вложенных друг в друга)

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

Таким образом, в модели распределенного приложения, опирающегося на WS-CTX, выделяются три главных компонента:

1) контекст - базовая информация о структуре действия, идентифицируемая при помощи URI и передаваемая в приложения внутри сообщений. Контекст может динамически расширяться приложениями;

2) сервис контекстов (Context Service, CS) - следит за границами действия, отвечает за регистрацию, поддержку ссылок на контекст и передачу контекста участникам активности. Сервис контекстов оформлен спецификацией как Web-сервис (CTXService). Пользовательский сервис может выступать как активный клиент CS, а может получать от него сообщения. В последнем случае он должен реализовать определенный callback-интерфейс (UserCTXService).

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

3) сервисы жизненного цикла активности (Activity Lificycle Service, ALS) - это вспомогательные Web-сервисы, организующие работу внутри действия. Они регистрируются в CS особым образом и получают от CS информацию о жизни действия - когда оно начинается, когда кончается и пр. Также они могут дополнительно расширять систему интерфейсами более высокого уровня. Типичным примером ALS является транзакционный сервис, предоставляющий свой интерфейс, но опирающийся на CS для управления контекстами.

CS имеет механизм создания композитного контекста: когда требуется контекст данной активности, CS вызывает зарегистрированные ALS для получения от каждого из них дополнений к контексту, а затем объединяет их. Естественно, сервис ALS должен реализовывать ряд описанных спецификацией интерфейсов.

В дополнение к описанным выделяются прикладные сервисы. Они задействованы внутри границ действия и используются им для решения бизнес-задачи.

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

Web Service Coordination Framework (WS-CF)

Эта спецификация задает правила координации сервисов. Под координацией понимаются некоторые действия агента (координатора), гарантирующие, что все участники получат определенное сообщение. Координатор, в частности, ответственен за отсылку им контекста действия. Однако просто координационным протоколом нельзя охватить все возможные конфигурации систем, поэтому предлагается инфраструктура координации - WS-CF, позволяющая пользователям статически и динамически настраивать ее свойства для каждого отдельного сервиса и приложения. WS-CF базируется на WS-CTX (расширяет контекст) и поддерживает WS-TXM, а также другие WS-стандарты в областях дирижирования сервисами, workflow и транзакций.

UML-диаграмма координации workflow в WS-CF

В WS-CF определены следующие главные компоненты:

1) участник - пользовательский сервис, вызываемый в процессе координации;

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

Логические границы координации могут не совпадать с границами действия - в течение своей жизни оно может использовать разные координационные протоколы. Стоит отметить, что возможны координации, реализуемые через координаторы-посредники - механизм, полностью аналогичный представителям в WS-Coordination;

3) координационный сервис (Coordination Service, CrS) определяет поведение и итог специфической модели координации. Фактически они задают протоколы координации сервисов. Пример - сервис двухфазных транзакций с операциями подготовки, утверждения и отката. В одном приложении или домене может быть несколько координационных сервисов. При этом WS-CF не определяет реализаций CrS, а лишь предоставляет необходимые стандартные интерфейсы. Для того чтобы обеспечить совместимость с существующими CrS, которые могут уже иметь определенные интерфейсы для координатора и участника, от WS-CF-совместимой реализации требуется только реализация сервиса ALS. Протокол координации может меняться в ходе жизненного цикла активности.

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

WS-CF не диктует какого-либо транспортного протокола - может использоваться HTTP, SMTP и пр. Она также не определяет механизмов восстановления от сбоев, но требует от входящих сервисов наличия таких механизмов. Частично забота об этом перекладывается на сервис координации.

***

В следующей части мы наконец доберемся до самой интересной области - спецификаций разметки транзакций.

(Продолжение следует)