Откат транзакций и веб-сервисы

Question

Учитывая пример вызова двух методов веб-служб из сессионного компонента, что, если между вызовами двух методов возникает исключение?В случае отказа от вызова веб-служб транзакция будет откатана, и никакого вреда не будет причинено.Однако веб-служба не выполнит откат.Конечно, даже с одним веб-сервисом возникает проблема.Хотя это общий вопрос, меня интересуют решения, связанные с сессионными компонентами EJB.

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

Answer 1

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

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

Протоколы WS-AT и WS-BA являются ведущими стандартами для транзакционных веб-сервисов.К сожалению, они указывают только протокол, а не языковые привязки.Другими словами, на уровне языка программирования не существует стандартного API.Для Java ближайшим вариантом является JSR-156, но он еще не готов.

Тогда проблема становится:как привязать EJB (т. е.JTA /XA) транзакция к WS-транзакции.Поскольку модели, используемые протоколами WS-AT и XA, тесно связаны, этого можно достичь с помощью моста протоколов.Несколько серверов приложений предоставляют что-то одно в этих строках.JBoss представила свои разработки на JavaOne - см. http://anonsvn.jboss.org/repos/labs/labs/jbosstm/workspace/jhalliday/txbridge/BOF-4182.odp

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

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

WS-BA использует модель, основанную на компенсации, которую сложнее запрограммировать.По сути, это основано на технике, о которой вы упомянули:эффект методов обслуживания отменяется вызовом метода компенсации.Это может быть сложно сделать правильно, но стажер JBoss создал довольно приятную структуру аннотаций, которая позволяет вам определять методы компенсации с минимальными усилиями и управлять ими автоматически.Это не стандартизировано, но стоит проверить, если вы выберете такой подход: http://www.jboss.org/jbosstm/baframework

Answer 2

Спецификации координации веб-сервисов (WS-C) и транзакций веб-сервисов (WS-T), разработанные Microsoft, BEA Systems и IBM, используются в таких случаях, насколько мне известно. Вы можете начать с чтения транзакций веб-служб и Сравнение статей протоколов транзакций Web-сервисов , предоставленных IBM, чтобы прояснить это.

Answer 3

На самом деле, обычно вам нужен не только пользовательский метод отката, но и пользовательский метод фиксации.В противном случае вы столкнетесь с проблемами, подобными тем, что описаны в стандарте WS-BA.

Просто посмотри http://www.atomikos.com/Publications/TryCancelConfirm для получения подробной статьи.Упомянутые там функции доступны в Экстремальные транзакции Atomikos...Этот продукт также поддерживает классические транзакции веб-сервиса в стиле ACID.

HTH

Парень

Отказ от ответственности:Я работаю на Атомикос