Транзакции в сетевых службах

Протокол WS-Coordination создает основу реализации других протоколов сетевых служб, в том числе для тех важнейших протоколов, которые смогут поддерживать транзакционный обмен. В августе 2002 года фирмы IBM, Microsoft и BEA предложили на базе протокола WS- Coordination набор спецификаций, создавших новый стандарт WS-Transaction.

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

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

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

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

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

Атомарные транзакции

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

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

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

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

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

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

Сообщение ReadOnly показывает, что участник голосует за подтверждение, но сам не нуждается в дальнейшем участии в протоколе. Сообщение Aborted показывает, что участник голосует против подтверждения и не нуждается в дальнейшем участии в протоколе. Кроме протоколов, стандарт WS-Transaction определяет структуру транзакционного контекста. Именно эта структура возвращается координатором в ответ на запрос о создании координационного контекста. Она же передается как часть заголовков сообщений SOAP и показывает, что сообщение посылается в рамках некоторого разговора.

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

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

Бизнес активности

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

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

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

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

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

Источники

http://sp.cmc.msu.ru/courses/sdpi/mdwrbook.pdf

http://www.complexdoc.ru/pdf/%D0%93%D0%9E%D0%A1%D0%A2%20%D0%A0%20%D0%98%D0%A1%D0%9E%7C%D0%9C%D0%AD%D0%9A%2010746-1-2004/gost_r_iso/mek_10746-1-2004.pdf - сам гост