Откат транзакции и веб-сервисы
Учитывая пример вызова двух методов веб-служб из сеансового компонента, что, если между вызовами двух методов возникает исключение? В случае отказа от вызова веб-сервисов транзакция откатится, и никакого вреда не будет. Однако веб-служба не откатится. Конечно, даже с одним веб-сервисом есть проблема. Хотя это общий вопрос, меня интересуют решения, связанные с сессионными компонентами EJB.
Простым и индивидуальным ответом было бы добавление в веб-службу специального «метода отката» для каждого метода «реальной функциональности». Я прошу какой-нибудь стандартизированный способ сделать это.
Ответы 3
Ряд методов развивается, но проблема все еще остается настолько острой, что процесс стандартизации еще не предоставил нам полностью переносимое решение.
Вариант первый, вы можете сделать транзакцию веб-служб осведомленной. Это, конечно, предполагает, что вы контролируете их, хотя написание прокси-сервера с поддержкой транзакций для нетранзакционных служб также является вариантом в некоторых случаях.
Протоколы 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
Привет всем, этому ответу сейчас 5 лет, и он говорит: «JSR-156 еще не готов». Есть ли обновление к этому ?? есть ли теперь стандарт для обработки транзакций с помощью веб-сервисов мыла? заранее спасибо
В известных мне случаях используются спецификации координации веб-служб (WS-C) и транзакций веб-служб (WS-T), разработанные Microsoft, BEA Systems и IBM. Вы можете начать с чтения статей Транзакции веб-сервисов и Сравнение протоколов транзакций веб-сервисов, предоставленных IBM, чтобы прояснить это.
Ни одна из предоставленных вами ссылок больше не работает. Неудивительно, так как вы разместили это 8 лет назад :)
На самом деле, обычно вам нужен не просто настраиваемый метод отката, но и настраиваемый метод фиксации. В противном случае вы столкнетесь с проблемами, подобными тем, которые встречаются в стандарте WS-BA.
Just check out http://www.atomikos.com/Publications/TryCancelConfirm за подробную статью. Упомянутые там функции доступны в Atomikos ExtremeОперации ... Этот продукт также поддерживает транзакции веб-сервисов в классическом стиле «ACID».
HTH
Парень
Отказ от ответственности: я работаю в Atomikos
К счастью, мы используем JBoss, поэтому я склоняюсь к предлагаемым вами решениям, особенно к последней ссылке.