Як ви можете ефективно використовувати веб-сервіси у корпоративному середовищі, якщо ви не можете використовувати транзакції?

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

Я просто не бачу, як можна ефективно використовувати веб-сервіси для будь-якої серйозної роботи. Як я можу безпечно виконувати декілька службових дзвінків, якщо не можу використовувати транзакцію?

Скажімо, у мене є робота з крон, яка захоплює клієнтів з нашої бази даних, які відповідають певній умові, про яку їм потрібно повідомити. Їм надсилається факс, електронний лист та квиток, щоб відстежувати проблему всередині країни. Це 3 різні виклики служби, які відбудуться для кожного клієнта в циклі "for".

Якщо в будь-якому місці помилки трапляється десь, можливо, наприклад, факс та електронний лист надсилаються замовнику, але квиток не створюється. Або ще гірше, що ця робота з Cron може містити помилку, яка спричиняє невдачу кожного разу в одній точці, і вона неодноразово надсилає електронній пошті того ж клієнта. Якби всі бібліотеки були локальними, все можна було б просто загорнути в транзакцію, і нічого з цього не відбудеться. Але ми використовуємо веб-сервіси в цьому прикладі.

Зауважте, що методи електронної пошти та факсу фактично вставляють дані в таблиці, що підтримуються базами даних, які, в свою чергу, обробляються окремим процесом завдання Cron. Таким чином, дзвінки на послуги "надіслати електронну пошту" та "надіслати факс" можуть бути скасовані побічними ефектами, якщо це необхідно.

Опція полягає в тому, щоб весь цей фрагмент коду було розміщено в самій веб-службі, щоб веб-служба сама зателефонувала на електронну пошту, факс та методи створення квитків в транзакції. Але тоді ми створюємо метод веб-сервісу саме для використання транзакції; немає поважних причин, коли б нам насправді потрібно було викликати цей метод з будь-якого місця, крім цього одного сценарію cron.

Як би ви взагалі впоралися з цим методом?

Те, що ви описуєте, насправді є розподіленою транзакцією, що реалізує двофазну комісію . Деякі платформи обміну повідомленнями підприємств включають менеджерів транзакцій для підтримки подібних речей, але конкретні продукти залежать від платформи / мови. Я не маю конкретного досвіду роботи з такими інструментами, але сподіваюся, що ці покажчики допоможуть.

Цікаво, що, беручи участь у цьому конкретному запитанні, є схожа нитка щодо служб, що підтримують декілька платформ у списку розсилки DDD / CQRS, в якому я беру участь.

Одним із варіантів підтримки транзакцій у неоднорідному середовищі є використання транспортного механізму, який підтримує транзакції та підтримується на всіх платформах, з яких вони будуть використовуватися. Advanced Message Queue Protocol (AMQP) робить підтримку транзакції і є рідна API для майже будь-якої мови , який зазвичай використовується сьогодні. RabbitMQ - це сервер, який реалізує AMQP і пройшов перевірку в галузі як надійне рішення.

Використання системи, що базується на RabbitMQ, ставить вас на шлях до створення повного ESB, якщо вам потрібно, щоб перерости в нього. Ви публікуєте повідомлення на каналі та підписуєтесь на чергу. Якщо це стає справді потужним, це те, що між каналом і чергою ви можете виконати багато цікавого. Канал може подавати декілька черг (pub / sub), черга може подаватися кількома каналами, ви можете перенаправляти повідомлення до різних черг залежно від вмісту тощо.

Я просто читав про альтернативи транзакціям (які надходять із накладними витратами та перетворюють операцію асинхронізації в режим блокування). RabbitMQ підтримує те, що називається підтвердженням видавця . В основному це дозволяє зареєструвати зворотний виклик для опублікованого методу для обробки невдалої транзакції. У вашому випадку це може скасувати запити електронної пошти / факсу та видалити квиток.

Звичайно, кроляча нора (вибачте за каламбур) йде ще глибше звідти. Ви можете використовувати Кролика для створення складних оркестрацій як із внутрішніми, так і із зовнішніми веб-сервісами.

Для ваших громадських веб-служб це стає просто мертвим. Ваша служба (будь то SOAP, REST або JSON) просто публікує повідомлення у відповідній черзі обслуговування та нехай ваша внутрішня система обробляє її звідти.

Існує також функціональність для створення запиту / відповіді для тих сценаріїв, де ви очікуєте швидкої повернення інформації.

Ключові слова, які ви шукаєте, - "хореографія веб-служб".

Перегляньте статтю Вікіпедії про це.

Те, як я впорався з цим у написаному нами додатку до послуг, полягав у створенні обгортки для обробки необхідних транзакцій. У моєму випадку запит користувача, зроблений веб-сайтом, настільним додатком або службою Windows, повинен був запитувати веб-сервіс і, виходячи з результату та параметрів користувача, він повинен був оновити локальний БД і, необов'язково, віддалений через веб-сервіс. Тоді він повинен був створити звіт, який потрібно негайно повернути, надіслати електронною поштою та / або надіслати факсом. Я мав контроль над локальною БД, генерацією електронної пошти та звітів, але жодним чином не над веб-сервісами чи факс-сервером.

Створення обгортки дозволило покращити контроль транзакцій та обробляти помилки. Це також дозволило покращити безпеку, контролюючи доступ до внутрішніх мережевих служб із сторонніх джерел. Взагалі я бачу необхідність транзакцій та управління сервісом як поважна причина для створення відповідної обгортки для єдиного рішення до тих пір, поки код не буде використаний належним чином (немає кодування cut-n-paste).

Я просто не бачу, як можна ефективно використовувати веб-сервіси для будь-якої серйозної роботи. Як я можу безпечно виконувати декілька службових дзвінків, якщо не можу використовувати транзакцію?

Ви не можете.

Питання, яке вам слід задати, таке: як здійснити транзакції з веб-службою X? Зараз ви просто припускаєте, що це неможливо.