Web-сервисы и транзакционные системы

ОБЗОРЫ

_____

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

В предыдущей части обзора мы рассмотрели типы протоколов координации транзакций в мире Web-сервисов (атомарные и бизнес-транзакции), а также спецификации в этой области, созданные компаниями IBM, Microsoft и BEA и реализуемые в их продукции. Однако год назад у описанных разработок появился серьезный конкурент, предложенный группой фирм во главе с Sun и Oracle. Кроме того, сохраняет популярность протокол Business Transaction Protocol (BTP), разрабатываемый органом отраслевой стандартизации OASIS. Все они имеют некоторые преимущества и недостатки, но вполне очевидно, что каждый из них также найдет применение в реальных системах.

Web Services Transaction Management (WS-TXM)

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

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

WS-TXM описывает более гибкую архитектуру, нежели та, что задается WS-Tx и ее производными. Эта архитектура состоит из наборов корневых инфраструктурных сервисов для WS-среды, которые вместе образуют службу транзакций (Transaction Service), определения ролей и ответственности транзакционных подкомпонентов, форматов сообщений, необходимых для осуществления координации действий, и форматов рабочих блоков данных - заголовка, контекста и пр. Для решения типовых задач спецификация вводит три модели.

Модель ACID-транзакций

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

ACID-модель допускает два стиля участия в ней сервиса: singleton, когда сервис (точнее, его "конечная точка") неявно ассоциируется только с одной транзакцией, и factory, когда один сервис-участник может управлять многими другими участниками, причем от имени многих разных транзакций. В последнем случае для разрешения потенциальных неоднозначностей все действия сервиса-участника всегда неявно ассоциируются текущим контекстом и участник по получаемому им контексту обязан уметь определять транзакцию, над которой ему предстоит работать. В каждом сообщении также передается уникальный идентификатор участника, которому оно предназначено.

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

Рис. 1. UML-диаграмма двухфазной транзакции в WS-TXM.

Так как WS-TXM основывается на WS-CF, допускается представление (interposition) координаторов. Подчиненные координаторы ответственны за сохранение данных, необходимых для отката транзакций, в частности за создание "контрольных точек". Восстанавливающиеся участники могут определять через механизмы WS-CF статус транзакции. (Хотя разработчики указывают, что в сложных системах восстановление автоматическими средствами не всегда возможно.)

Рис. 2. Диаграмма потоков сообщений двухфазной транзакции WS-TXM.

Штриховые линии обозначают сообщения, сгенерированные участником, сплошные - координатором

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

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

Модель длительных действий (Long running action, LRA)

LRA предназначена гарантировать, что совершенные в рамках бизнес-процессов (БП) отдельные шаги, или действия в терминологии WS-CF (см. предыдущие части обзора), могут быть компенсированы.

Рис. 3. Пример компенсационных действий в бизнес-транзакции.

Штриховые линии - направление исполнения при сбое этапа транзакции. Сплошные - при нормальном исполнении

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

Рис. 4. Выбор результата работы вложенных действий в действии LRA

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

Так как WS-TXM опирается на WS-CF, представление (interposition) координаторов допускается, но не требуется - индивидуальные координаторы могут являться подчиненными или выделяться в отдельный домен. В этом состоит отличие данной модели от модели бизнес-процесса (см. ниже).

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

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

Транзакционная модель бизнес-процесса (BP Model)

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

Рис. 5. Домены и координаторы в бизнес-транзакции модели WS-CTX

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

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

Ввиду деления на домены важное значение придается механизму представительства менеджеров, который аналогичен тому, что применяется WS-CF и пр. Каждый домен характеризуется наличием собственного координатора, скрывающего все детали процесса от внешнего мира. Он идентифицируется собственным URI, характеризуется собственным контекстом и может использовать собственные транзакционные протоколы (например, WS-AT или OASIS BTP). В последнем случае он действует как посредник при взаимодействии внутренних сервисов с внешним миром: снаружи неизвестно, реализация какой технологии используется внутри домена. Как правило, корневой координатор заботится лишь о том, обновлено ли состояние участвующих в БП систем, а также закончили ли они свою работу. Более детально внутреннее устройство домена (т. е. как определяется набор сервисов в нем) спецификацией не затрагивается.

Спецификация определяет несколько подпротоколов: terminate-notification (используется участником для получения уведомлений о прекращении работы), businessProcess (посылает участникам сообщение WS-CF coordinate - "скоординироваться"), checkpoint (протокол передачи указаний о создании точки восстановления), restart (перезапуск процесса с точки восстановления и добавление участников), workStatus (определение того, может ли БП успешно завершиться как целое), completion (завершение активности).

BP Model поддерживает как синхронные, так и асинхронные взаимодействия. Но естественным предпочтением является асинхронный механизм, свойственный Web-сервисам, с эмуляцией синхронности через механизм подтверждений.

Примечание. Важное свойство спецификации - поставщики ПО могут реализовать ее бесплатно.

OASIS Business Transaction Protocol (BTP)

Статус: стандарт OASIS, 2002.

Эта спецификация возникла практически одновременно с WS-Tx и долго рассматривалась как единственный конкурент последней, к тому же не "закрытый" авторскими правами.

Главное свойство BTP состоит в том, что это универсальный протокол. Он используется не только для Web-сервисов, но и для любых систем, обменивающихся XML-отформатированными сообщениями. Поэтому BTP не опирается на существующие наработки в области WS, а создает собственный набор служб. При развертывании его в WS-среде многие из этих служб не нужны и даже могут конфликтовать с тем, что уже развернуто. Но создатели не рассматривали совместимость с действующими системами как необходимое качество протокола, и это также отложило на BTP отпечаток.

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

BTP поддерживает два типа транзакций: Atom ("атом") и Cohesion ("согласие"). Первый из них гарантирует атомарность операции для группы участвующих Web-сервисов, т. е. формирует "атомы". Эти атомы являются участниками транзакций другого типа - Cohesion. В них условие атомарности смягчается: для того чтобы приспособить двухфазный алгоритм к реализации долгоживущих транзакций, BTP позволяет бизнес-логике вклиниваться между фазами. Приложение имеет полный контроль над итогами подготовительной фазы, решая, какие из транзакций-участников подтвердить, а какие отменить. С этой целью пользователь формирует множество параметров разрешения утверждения и передачи его координатору. Получается, правда, что приложение находится в тесном взаимодействии с координатором. Это серьезное отклонение от стандартного алгоритма двухфазной транзакции, где приложение лишь инициирует транзакцию, а координатор весь дальнейший цикл реализует самостоятельно.

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

В BTP применено несколько оптимизаций базовых протоколов.

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

Autonomous participant decisions (участник принимает автономные решения). Современные системы 2PC позволяют участнику принимать одностороннее эвристическое решение об утверждении или откате транзакции. Если его решение не совпадет с итогом транзакции, то возникнет ошибка. В BTP этот подход расширен: участник обязан известить (через квалификаторы, см. ниже) координатора, сколь долго он может находиться в подготовленном состоянии и что он будет делать потом. Координатор использует эти данные для оптимизации обмена сообщениями. Правда, идеальной точкой назначения этой информации было бы бизнес-приложение, но как раз ему BTP эти сведения не передает.

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

One-phase. Если в транзакции один участник, то она становится однофазной.

Протокол BTP имеет много недостатков, на которые указывают конкуренты из IBM. Например, он не несет семантики транзакции ACID. Единственной его задачей является достижение консенсуса участников. Как именно осуществляются фазы подготовки, подтверждения и отмены, спецификация не описывает детально - эта задача перекладывается на разработчика конкретной реализации. Более того, стандартными средствами нельзя уведомить участников транзакции о том, какой выбор и как был сделан.

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

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

***

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

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