Тема номера: Web-сервисы

Майк Леманн

Кому нужны web-сервисные транзакции?
(Who Needs Web Services Transactions?
by Mike Lehmann)

Источник: журнал Oracle Magazine, no.6 2003, http://otn.oracle.com/oramag/oracle/03-nov/o63dev_web.html

Поддержка транзакций появляется в стандартах web-сервисов.

Думая о транзакциях в бизнес-приложениях, вы немедленно думаете о банках, фондовых биржах и системах бронирования авиабилетов: это классические крупномасштабные высокоуровневые промышленные системы, в которых некорректно введенная информация может иметь серьезные последствия

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

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

История web-сервисных транзакций

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

Много ранних web-сервисных проектов было сфокусировано на перенацеливании уже испытанных web-архитектур типа “запрос-ответ”, где поддержка транзакций была либо явно закодирована на уровне приложения с использованием классических Web-технологий, таких как HTTP sessions or cookies, или явно исключена предоставлением приложению доступа только на чтение в серверных бизнес-системах. Но много разработчиков создали проекты, которые достигли границ возможностей простых web-сервисов, предприняли несколько попыток стандартизации привнесения транзакционной семантики в web-сервисы.

В 2000 году несколько крупных поставщиков написали спецификацию, названную Transaction Authority Markup Language (язык разметки транзакционных полномочий). В 2001 BEA создала спецификацию, названную Business Transaction Protocol (протокол бизнес-транзакций). В 2002 IBM и Microsoft создали WS-Transaction и WS-Coordination как часть языка исполнения бизнес-процессов для web-сервисов - Business Process Execution Language for Web Services (BPEL4WS). И в августе 2003 консорциум производителей, в том числе и Oracle, представил структуру композитных web-сервисных приложений - Web Services Composite Application Framework (WS-CAF), включающий в себя эти предварительные усилия.

Транзакции: нужны или нет?

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

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

Рис 1: Бизнесмен взаимодействует с агентом бюро для планирования командировки

Данный сценарий представляет собой набор действий.

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

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

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

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

Связывая Транзакции с Web-сервисами

Когда агент бюро работает с такой транзакцией, каждое действие может требовать человеческого вмешательства. В web-сервисах, однако, отдельные шаги часто автоматизированы для снижения необходимости человеческого вмешательства.

Большинство предлагаемых спецификаций web-сервисных транзакций включают и атомарные транзакции и деловые операции, так как они неизбежно идут вместе в web-сервисных сценариях. Фактически, BPEL4WS была реализована вместе с WS-Transaction и WS-Coordination спецификациями из-за очевидного отношения транзакций с бизнес процессами.

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

В отличие от классического координатора распределенных транзакций в атомарной транзакционной среде, такой как Oracle Database, координатор web-сервисных транзакций сам является web-сервисом, взаимодействующим посредством SOAP-сообщений. Действуя как транзакция, координатор не определяет, однако, какой должен быть транзакционный протокол. Это обычно определено в спецификациях, дополнительных к координационным, например, WS-Transaction и WS-Transaction Management. Эти спецификации проясняют, как реализации web-сервисов описывают обычные транзакционные операции такие, как "begin," "commit" и "rollback" в контексте, как атомарных транзакций, так деловых операций.

Закругляя требования к реализации web-сервисных транзакций, транзакционный протокол сам не определяет разделяемый контекст, который идентифицирует уникальность отдельной деловой или атомарной трнзакции среди конкурирующих взаимодействий. WS-Context (из WS-Composite Application Framework) описывает, как создать общий разделяемый контекст, который может быть использован для хранения информации, используемой различными web-сервисами. Рис. 2 демонстрирует взаимодействующие части исходного сценария нашего делового путешествия.

Рис 2: Web-сервисные транзакции для деловой поездки

Деловые операции и компенсирующие транзакции

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

Следующие шаги ПРОЧИТАЙ о web-сервисах otn.oracle.com/tech/webservices о web-сервисных транзакциях otn.oracle.com/tech/webservices/htdocs/spec/ws-caf.html www.oasis-open.org

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

Компенсирующие транзакции настолько фундаментальны для автоматизации бизнес-процессов, что BPEL4WS включила подробный декларативный механизм для включения их в откатываемые web-сервисные операции, такие как наш сценарий.

Будут ли они базироваться на стандартах?

Вы могли заметить, что в этой статье имелись ссылки на WS-Transaction/WS-Coordination и WS-CAF как на спецификации, а не стандарты. В то время, когда статья была уже написана, WS-CAF была отправлена в OASIS, и это хороший знак для организаций, которые готовы перейти от web-сервисов, как базовой фундаментальной технологии, к критически важным технологиям, связанным с разработкой и интеграцией приложений масштаба предприятия.

Просматривая Oracle Technology Network, Вы можете видеть, что Oracle не только продолжает поддерживать стандарты web-сервисов, такие как WS-CAF, но также начинает предлагать предварительные реализации поддержки web-сервисных транзакций в Oracle Application Server 10g.

Майк Леманн (mike.lehmann@oracle.com) главный менеджер по продуктам Oracle Application Server Containers для J2EE 10g.