Управление транзакциями в веб-сервисах

Question

Наш клиент следует принципам SOA и имеет очень тонко детализированные веб-сервисы, такие как createCustomer, deleteCustomer и т.д.например, если бизнес-требование - это каждый Клиент должен иметь адрес при его создании.Таким образом, в этом случае компонент представления сначала вызовет createCustomer, а затем createAddress.Сервисы внутренне используют простой JDBC для обновления соответствующих таблиц в БД.Поскольку служба вызывается внешним компонентом, у нее нет способа выполнить транзакционное требование, т. Е. В случае сбоя createAddress операция createCustomer должна быть откатана.

Полагаю, один из подходов для решения этой проблемы заключается в разработке разрозненных служб (которые создают Customer и связанный с ним адрес в одной транзакции JDBC), или, возможно, в простом создании службы обращения (deleteCustomer), котораяотменяет действие createCustomer.

любые предложения.спасибо

Answer 1

Краткий ответ: услуги должны быть разработаны для удобства обслуживания клиента. Если клиенту говорят «позвони, тогда не забудь позвонить, что» ты делаешь жизнь слишком трудной. Должен быть грубый сервис.

Длинный ответ: можно ли разумно ввести клиента без адреса? Итак, мы называем

createCustomer( stuff but no address)

и результат является действительным (если не идеальным) состоянием для клиента. Позже мы называем

changeCustomerAddress ( customerId, Address)

и теперь постоянный клиент более полезен.

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

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

Альтернативы:

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

б). Интерфейс с отслеживанием состояния (работа, работа, фиксация), упомянутый @mtreit. Вообще говоря, Statefulness либо добавляет сложность, либо препятствует масштабируемости. Где сервис держит промежуточное состояние? Если в памяти, то мы требуем сродства к конкретному экземпляру службы и, следовательно, ввести проблемы масштабирования и надежности. Если в какой-либо базе данных State или незавершенного производства у нас есть существенная дополнительная сложность реализации.

Answer 2

Хорошо, давайте начнем:

Наш клиент следует принципам SOA и имеет очень тонкие веб-службы разработки, такие как createCustomer, deleteCustomer и т. Д.

Нет,клиент забыл достичь принципов SOA и создать то, что делает большинство людей - куча плохо определенных интерфейсов.В соответствии с принципами SOA, клиент использовал бы более грубый интерфейс (такой как, например, механизм OData для обновления данных) или следовал советам любой книги по многоуровневой архитектуре, написанной, как за последние 25 лет.SOA - это еще одно слово для того, что было изобретено с помощью CORBA, и все ошибки, которые парни из SOA совершают сегодня, когда в основном известны глупости проектирования 10 лет назад с CORBA.Не то чтобы кто-либо из людей, занимающихся SOA сегодня, когда-либо слышал о CORBA.

Я не уверен, желательны ли мелкозернистые сервисы, поскольку они создают проблемы, связанные с транзакциями.

Только для пользователей и платформ, не поддерживающих веб-сервисы.Шутки в сторону.Естественно, вы получаете транзакционные проблемы, если вы игнорируете транзакционные проблемы в своем программировании.Хитрость в том, что люди, находящиеся дальше по пищевой цепочке, этого не делали, просто ваш клиент решил игнорировать общеизвестные знания (опять же, смотрите мое первое замечание о Corba).

Люди, разрабатывающие веб-сервисы, хорошо знали о транзакционных проблемах.Именно поэтому спецификация веб-службы (WS *) фактически содержит механизмы для обработки целостности транзакций путем перемещения операций фиксации до клиента, вызывающего веб-службу.Конкретная спецификация, которую должен прочитать ваш клиент, - это WS-Atomic.

Если вы используете текущую технологию для представления своего веб-сервиса (также как WCF на платформе MS, аналогичные технологии существуют в мире Java), тогда вы можетепредоставить клиенту информацию о потоке транзакции и позволить клиенту обрабатывать демаркацию транзакции.У него есть свои проблемы, такие как клиенты, которые держат транзакции открытыми злонамеренно, но все же это единственный способ обработки транзакций, которые определены в клиенте.

Поскольку вы не предоставляете платформу и просто упоминаете Java,Я указываю вам на пример MS, как это может выглядеть: http://msdn.microsoft.com/en-us/library/ms752261.aspx

Веб-сервисы, в общем, гораздо более мощные и намного более продуманные, чем думают большинство людей, занимающихся SOA.Большинство проблем, которые они видят, были решены давно.Но тогда, SOA - это просто модное слово для многоуровневой архитектуры, но большинство людей думают, что это величайшая вещь, так как нарезанный хлеб просто не знает, что было около 10 лет назад.

Как ваш клиент, я был бынамного больше заботиться о производительности.Мелкозернистые несемантические веб-сервисы, как он определяет, являются скачком производительности для не случайного использования, потому что количество раз, когда вы пересекаете сеть, чтобы запрашивать / обновлять мелкие мелкие мелкие мелочи, заставляет задержку сети убивать вас.В этом сценарии создание заказа на примерно 10 товаров может легко занять 30-40 сетевых звонков, что действительно может занять много времени.SOA с самого начала проповедует (если вы игнорируете разговоры тех, кто не знает истории), чтобы НЕ использовать мелкозернистые вызовы, а идти на грубый обмен документами и / или семантический подход, очень похожий на систему OData.

Answer 3

Если требуется транзакционность, более грубая одиночная операция, которая может реализовать семантику транзакций на сервере, определенно будет намного проще реализовать.

При этом, безусловно, можно построить некоторую схемугде цель операций не фиксируется до тех пор, пока все необходимые детальные операции не будут выполнены успешно.Например, имейте операцию Commit, которая проверяет некоторый флаг, связанный с объектом на сервере;флаг не устанавливается до тех пор, пока не будут выполнены все необходимые шаги в транзакции, и не будет выполнена фиксация, если флаг не установлен.

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