Всем привет,
возникла необходимость в передаче сообщений от одного приложения к другому.
Схема такая: есть основное приложение (WCF-сервис на IIS), в котором работает бизнес-логика, время от времени ей нужно запульнуть сообщение о каком-то событии в другое приложение. То другое приложение как-то обрабатывает такие сообщения, там своя логика.
Первым решением данной задачи было использовать RPC: приложение-приёмник было реализовано самостоятельным WCF-сервисом, а запуливание сообщения сводилось к вызову его метода.
У этого решения есть ряд недостатков, самым важным из которых оказалось отсутствие поддержки транзакций: вызов происходил внутри транзакции, которая после вызова могла откатиться, в итоге приложение-приёмник получало недействительное сообщение.
Вариант использовать распределённые транзакции не рассматривается как слишком дорогой и не необходимый, т.к. не требуется чтобы сообщение было обработано в одной транзакции с основной бизнес-операцией.
Подумав, пришли к выводу что нужен какой-то механизм, реализующий следующее поведение:
— основное приложение бросает событие на шину в рамках транзакции
— если транзакция завершилось успехом, то сообщение попадает в какую-то персистентную очередь
— из этой очереди в фоновом режиме сообщение передаётся другому приложению для обработки
— передача должна исключать потерю сообщений и их повторную обработку
Есть мнение что эта задача неуникальна и что-то такое уже давно реализовано. В голову приходят всякие ESB, но опыта работы с ними ни у кого в команде нет.
Прошу совета — какие готовые решения посмотреть? Естественно, интересуют максимально удовлетворяющие заявленным требованиям.
В идеале видится такой компонент, который умеет складывать (с учётом существующей транзакции) сообщения в указанную ему таблицу базы SQL Server, а потом как-то доставлять их обработчикам в другом процессе.
P_K>Есть мнение что эта задача неуникальна и что-то такое уже давно реализовано. В голову приходят всякие ESB, но опыта работы с ними ни у кого в команде нет.
Здравствуйте, Poul_Ko, Вы писали:
P_K>возникла необходимость в передаче сообщений от одного приложения к другому.
P_K>...
P_K>Есть мнение что эта задача неуникальна и что-то такое уже давно реализовано. В голову приходят всякие ESB, но опыта работы с ними ни у кого в команде нет. P_K>Прошу совета — какие готовые решения посмотреть? Естественно, интересуют максимально удовлетворяющие заявленным требованиям.
Посмотрите на Service Bus For Windows 1.1 Вам потребуется реализовать отправителя сообщения в очередь и потребителя, который бы читал и обрабатывал эти сообщения. Всем остальным требованиям он полностью удовлетворяет.
Здравствуйте, Poul_Ko, Вы писали:
P_K>Прошу совета — какие готовые решения посмотреть? Естественно, интересуют максимально удовлетворяющие заявленным требованиям.
Windows Service Bus
Основной плюс — совместим с azure и сиквел умеет с ней работать.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Спасибо. Посмотрел — выглядит как полуживой монстр от Microsoft
Пока сложилось впечатление что для моей задачи это несколько избыточное решение. Хочется чего-то более простого и легковесного, типа подключил библиотеку, настроил — заработало...
Я так понял что это по сути то же самое что Service Bus For Windows 1.1, который рекомендовали ранее. Только более живое и для облака.
На текущий момент исследования показывают, что для достижения предъявленных требований может использоваться либо DTC, либо транспорт сообщений через базу. К сожалению, ни то ни другое не является приемлемым...
А чем конкретно Azure Service Bus не подошел? Защита от потери сообщений есть, от повторной обработки тоже. Так же можно использовать
— сессии и получить внутри них гарантию очередности
— топики, и тогда сортировать сообщения в разные очереди
P_K>В идеале видится такой компонент, который умеет складывать (с учётом существующей транзакции) сообщения в указанную ему таблицу базы SQL Server, а потом как-то доставлять их обработчикам в другом процессе.
Если база данный Microsoft SQL то ничего идеальнее чем очереди Sql Server-а не придумать.
В одном процессе ты транзакционно делаешь send а в другом соответственно читаешь из очереди.
Сообщение получается только если транзакция комитится
Здравствуйте, Tom, Вы писали:
P_K>>В идеале видится такой компонент, который умеет складывать (с учётом существующей транзакции) сообщения в указанную ему таблицу базы SQL Server, а потом как-то доставлять их обработчикам в другом процессе. Tom>Если база данный Microsoft SQL то ничего идеальнее чем очереди Sql Server-а не придумать. Tom>В одном процессе ты транзакционно делаешь send а в другом соответственно читаешь из очереди. Tom>Сообщение получается только если транзакция комитится
Да, но это всё будет свой велосипед. Вопрос был в том нет ли уже готового.
Здравствуйте, Doc, Вы писали:
Doc>А чем конкретно Azure Service Bus не подошел?
Насколько я понял это только для облака, а у нас не облачное решение.
Для не-облака вроде бы есть аналог — Service Bus For Windows — но выглядит он как какой-то полуживой монстр... Одна инструкция по установке чего стоит. И нет никакой уверенности что оно будет работать без DTC.
Здравствуйте, Poul_Ko, Вы писали:
Tom>>Если база данный Microsoft SQL то ничего идеальнее чем очереди Sql Server-а не придумать. P_K>Да, но это всё будет свой велосипед. Вопрос был в том нет ли уже готового.
Здравствуйте, seregaa, Вы писали:
S>Здравствуйте, Poul_Ko, Вы писали:
Tom>>>Если база данный Microsoft SQL то ничего идеальнее чем очереди Sql Server-а не придумать. P_K>>Да, но это всё будет свой велосипед. Вопрос был в том нет ли уже готового.
S>Наверное Tom имел ввиду SQL Server Service Broker. Это не велосипед, а готовое решение — https://technet.microsoft.com/en-us/library/bb522893(v=sql.105).aspx
Спасибо, посмотрел, интересно.
Вроде бы это не совсем то что нужно — Service Broker передаёт сообщения от одного Sql Server другому, а мне нужно передавать приложению. Можно конечно реализовать передачу через БД, но как-то это не вяжется с существующей архитектурой, да и в настройке сложнее.
P_K>Да, но это всё будет свой велосипед. Вопрос был в том нет ли уже готового.
Это и есть максимально готовое, самое простое решение, максимально пригодное в случае если база у вас мс сиквел
