SOA и распределенные транзакции - PullRequest
5 голосов
/ 01 апреля 2010

Когда распределенные транзакции имеют смысл в сервис-ориентированной архитектуре?

Ответы [ 2 ]

2 голосов
/ 04 апреля 2010

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

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

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

1 голос
/ 27 мая 2010

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

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

...