Откат транзакции и веб-сервисы - PullRequest
14 голосов
/ 12 января 2009

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

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

Ответы [ 3 ]

15 голосов
/ 13 января 2009

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

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

Протоколы 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

6 голосов
/ 13 января 2009

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

2 голосов
/ 08 сентября 2009

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

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

НТН

Guy

Отказ от ответственности: я работаю на Atomikos

...