ОБЗОРЫ

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

_____

     Продолжение обзора "Web-сервисы в корпоративной среде". Начало см. PC Week/RE, N 27/2004, с. 20; N 28/2004, с. 19; N 29/2004, с. 18; N 30/2004, с. 20.

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

Атомарные транзакции - это наборы операций, осуществляемые в рамках границ очень небольшого доверительного домена и имеющие свойство "все или ничего". Они характеризуются четверкой свойств ACID (atomicity, consistency, isolation, durability - атомарность, согласованность, изоляция данных промежуточных этапов от других процессов, надежность хранения окончательных итогов). Все действия в такой транзакции, осуществленные до операции ее утверждения, являются предварительными, т. е. не сохраняются на постоянном носителе и не видны другим процессам.

Рис. 1. Поток сообщений при оформлении атомарной транзакции в WS-Tх

Арр1 - инициатор транзакции, который начинает с того, что просит сгенерировать контекст у координатора А (самого главного координатора). Затем в А регистрируется и сервис RSa приложения Арр1, которому возвращается результат транзакции, проводимой А с контекстом С1. Координатор В подчинен А, он регистрируется в нем как участник двухфазной транзакции (2РС), а также просит информировать себя о начале равоты протокола 2PC (протокол PhaseZero). На самом деле он является представителем А для приложения Арр2, которое получило от Арр1 контекст С1 и на его основе заставило В сгенерировать новый контекст С2, Контекст С2 имеет тот же идентификатор транзакции, что и С1, но связан с новым адресом для посылки уведомлений - портом RSb приложения Арр2. Уведомления в адрес RSb нужны, чтобы сбросить кэш данных перед началом транзакции. Основываясь на значении идентификатора транзакции, координатор В передает полномочия для этой операции координатору А. Далее контекст С2 передается в СУБД, которая решает использовать свой координатор С как представителя В. На основе С2 генерируется новый контекст СЗ с тем же идентификатором транзакции, что и у С1 и С2. Формируется двухфазная транзакция с одним участником -сервисом . Координатор С не выполняет транзакции (он представитель), а передает полномочия координатору В, а тот возвращает их А.

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

Рис. 2. Потоки данных и команд во время транзакции со многими координаторами для системы с рис. 1.

Горизонтальные прямоугольники обозначают Web-сервисы, участвующие в транзакции

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

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

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

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

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

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

Усилиями вендоров ПО было создано несколько спецификаций, которые принесли свойства транзакционности в мир Web-сервисов. Наиболее заметные из них исходят от групп, возглавляемых IBM, BEA и Microsoft, а также Sun и Oracle, и соответственно называются WS-Tx и WS-CTX.

В последние два года произошла некоторая эволюция выдвинутых стандартов - в частности, WS-Tх развалился на две независимые составляющие.

WS-Transaction (WS-Tx)

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

Статус: версия (август 2002), на сегодняшний момент имеет унаследованное значение.

Связи: WS-Coordination.

Наиболее известная спецификация из области транзакций. Предшественник WS Atomic Transaction и WS BA Framework для среды, описываемой WS-Coordination.

Рис. 3. Диаграмма состояния двухфазной транзакции в WS-Transaction.

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

пунктирные - сгенерированные участником транзакции, овалы - состояния системы

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

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

WS-Tx описывает два множества координационных протоколов (они обозначаются специальным идентификатором типа контекста в заголовках SOAP-сообщений):

1) атомарные транзакции (AT). Задаются протоколы (см. примечание) 2PC (Double Two-phase Commit), Completion, PhaseZero и OutcomeNotification. Важно, что в рамках одной транзакции приложения могут регистрировать разные свои сервисы для участия в разных протоколах - координатор группирует их по общему контексту. Этот раздел частично перешел в спецификацию WS Atomic Transaction;

2) бизнес-дейстия (Business Activities), или бизнес-транзакции. Определяется два протокола - BusinessAgreement и BusinessAgreementWithComplete. Описания этих протоколов, полностью аналогичных данным, но имеющих несколько иное название, даны чуть ниже - в разделе про WS Business Activity Framework, в которую почти полностью перешла эта часть WS-Tx.

Предусмотрен также механизм расширений - для описания других типов транзакций помимо указанных.

Примечание. Атомарные транзакции в WS-Transaction бывают следующих типов.

Completion (завершение): один участник (обычно тот, который создал транзакцию) регистрируется у координатора так, что получает право требовать утверждения транзакции (Commit) или отката ее (Rollback). Ему возвращается результат выполнения этих операций.

CompletionWithAck: аналогична Completion, но координатор должен помнить результат транзакции, пока участник, зарегистрированный по этому протоколу, не подтвердит ему получение уведомления, содержащего статус завершения операции.

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

PhaseZero: участник требует от координатора, чтобы тот известил его о моменте, когда 2PC-протокол начинает работу. Типичный пример: приложение, кэширующее данные, обязано записать их в БД прежде, чем в той начнется транзакция.

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

WS Atomic Transaction

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

Статус: авторский протокол, версия (сентябрь 2003).

Связи: WS-Coordination в области передачи контекста и модели безопасности.

Подмножество спецификации WS-Transaction, которое было решено выделить в самостоятельную спецификацию и несколько переработать. Она определяет протоколы для короткоживущих атомарных транзакций в среде, описываемой WS-Coordination. По сравнению с WS-Transaction в ней изменились число и состав этих протоколов. Теперь их три: Completion (однофазная транзакция), Durable 2PC (двухфазная транзакция для постоянных хранилищ данных вроде СУБД) и Volatile 2PC (двухфазная транзакция для нестабильных хранилищ данных вроде кэширующих систем).

Volatile 2PC и Durable 2PC - варианты одного координационного протокола 2PC. Они часто сосуществуют в рамках одной транзакции, т. е. участникам передается общий контекст. Последовательность операций в 2PC такова: получив от инициатора (Commit) команду утверждения результатов. координатор начинает подготовительную фазу для всех участников Volatile 2PC. Так как "нестабильным" участникам не гарантируется посылка уведомления об исходе транзакции, все они обязаны ответить на запрос координатора прежде, чем тот решит перейти к новому этапу - работе над подготовительной фазой протокола Durable 2PC. На первой фазе Durable 2PC все участники, зарегистрированные по этому протоколу, обязаны ответить сообщениями Prepared (готовы) или ReadOnly (только читают данные). И уже после этого регистратор выдает им команду подтверждения транзакции.

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

WS Business Activity Framework (WS-BAF)

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

Статус: авторский протокол, версия (сентябрь 2003).

Связи: WS-Coordination.

Описывает так называемые бизнес-транзакции, обладающие свойствами, которые были перечислены во введении. Протоколы спецификации Business Activity позволяют системам управления бизнес-процессами и workflow "обертывать" свои частные механизмы в платформенно-независимый Web-сервисный вид и взаимодействовать за пределами своих доверительных границ.

Рис. 4. Структура бизнес-транзакции со сбоем

В основе модели координации, описываемой спецификацией, лежат следующие конструктивные требования:

- все изменения состояний систем (в том числе состояние приложений и координационные метаданные) должны сохраняться на надежных носителях;

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

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

Бизнес-транзакция в модели WS-BAF разделяется на ограниченные группы операций, в рамках которых формируется общий согласованный результат. Эти группы именуются действиями (activities), а элементарные "кирпичики", из которых они строятся, - задачами. Действия могут обладать или не обладать свойствами ACID, но отдельные задачи, как правило, всегда ими обладают. Действия характеризуются границами (scope), в частности началом и концом. Кроме того, действия могут вкладываться друг в друга. Спецификация требует, чтобы система, ее реализующая, позволяла определять результат работы группы - например, путем выбора его из результатов работы входящих в нее действий.

Рис. 5. Диаграмма состояния бизнес-транзакции.

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

пунктирные - сгенерированные участником транзакции, овалы - состояния системы

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

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

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

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

В целом этот протокол следует правилам, установленным WS-Coordination: создается специальный контекст (BusinessActivityCoordinationContext), он и передается всем потенциальным участникам транзакции.

***

В следующей части будут рассмотрены предложения конкурентов группы IBM, Microsoft и BEA - технологии WS-TXM (Sun/Oracle) и BTP (OASIS).

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