SOA и распределенные транзакции

Распределенные транзакции очень часто используются в средах SOA. Если у вас составная служба, вызывающая несколько служб, вызовы базовой службы должны обрабатываться как одна транзакция. Бизнес-процессы должны допускать откат своих шагов. Если базовые ресурсы позволяют это, вы можете использовать двухфазную фиксацию, но во многих случаях это невозможно. В этих случаях компенсирующие действия должны выполняться в отношении служб / ресурсов, вызванных перед неудачным шагом. Другими словами, отмените выполненные шаги в обратном порядке.
Воображаемый пример: телекоммуникационная компания предоставляет новый продукт VoIP для клиента с 6 обращениями в службу поддержки:

1. запрашивает инвентаризацию, чтобы убедиться, что у клиента правильное оборудование
2. настраивает оборудование клиента через посредничество
3. обновить инвентарь с новой конфигурацией
4. настроить механизм оценки для подсчета CDR для клиента
5. настроить программное обеспечение для выставления счетов, чтобы взимать с клиента правильный тарифный план
6. обновить систему CRM с результатом процесса предоставления

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

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

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