Должны ли веб-сервисы быть транзакционными?

Question

Я занимаюсь написанием веб-сервисов для приложения. В этом приложении мы делаем все внутри транзакций, так как «единицы работы» - это часто не отдельные объекты, а несколько объектов, охватывающих несколько таблиц. Есть ситуации, когда мы хотим «Все или ничего», и транзакция имеет смысл. Однако я не совсем уверен, как это сделать в веб-сервисе, и даже не должен ли я это делать.

Мне кажется, что веб-сервисы должны быть без сохранения состояния, и предоставляемый API должен быть построен на основе для каждой сущности, но я не уверен, как обрабатывать «единицы работы», которые в случае сбоя одной части, должны произойти откат.

Должны ли веб-сервисы быть транзакционными? Как бы вы реализовали транзакции, было бы что-то вроде отправки «НАЧАЛА СДЕЛКИ» и заканчивая «ЗАВЕРШЕНИЕ СДЕЛКИ»?

Если веб-сервисы не имеют состояния, как вы справляетесь с «единицами работы», которые не являются независимыми? Есть ли определенная литература, которую я могу прочитать по этой теме?

спасибо,

Answer 1

Одной из канонических статей по этому вопросу является «1001 * Жизнь за пределами распределенных транзакций»: мнение отступника Настоятельно рекомендуется.

Answer 2

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

Если вы хотите, чтобы клиент знал о поведении фиксации / отката, вы должны предоставить «компенсирующие транзакции» как часть вашего API. Таким образом, если один вариант использования создает новую транзакцию, вы должны предоставить дополнительный метод для ее удаления и сообщить пользователю, если создание прошло успешно или не удалось. То же самое со всеми другими методами.

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

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

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