Какую технологию следует использовать для реализации надежного абонента, доступного из .NET? - PullRequest
2 голосов
/ 06 апреля 2009

Принимая во внимание проект «зеленого поля», какие технологии, библиотеки, промежуточное программное обеспечение и т. Д. Облегчили бы реализацию обмена сообщениями «публикация-подписка» с надежными подписками в Windows и .NET? Я нашел WCF Peer Channel, используя Google, который, кажется, делает большую часть того, что мне нужно, но я не думаю, что он гарантирует порядок сообщений и не сохраняет сообщения на диск для надежности. Microsoft говорит, что эти возможности могут быть многоуровневыми, но я искал что-то, что уже имеет их.

Списки рассылки MSMQ близки к тому, что я хочу, но я бы предпочел что-то, где уровень обмена сообщениями не должен был знать обо всех клиентах заранее.

Количество подписчиков невелико, вероятно, меньше 20.

И издатели, и подписчики реализованы в C # / .NET и работают в Windows.

РЕДАКТИРОВАТЬ: Я изучаю предложения по промежуточному программному обеспечению и служебной шине, ориентированные на сообщения. Я знаком с корпоративными продуктами в этом пространстве - я действительно ищу что-то простое и легкое. Чтобы взглянуть на каждый продукт, требуется время, но я постараюсь обобщить свои выводы.

Ответы [ 5 ]

3 голосов
/ 09 апреля 2009

Я сделал то же самое (издатели и потребители в C # на .Net), с большим количеством долговременных подписок, и я фактически использовал SonicMQ для этого. Несмотря на то, что он считается провайдером JMS, он имеет чистые клиентские библиотеки .net, которые очень похожи на API-интерфейсы JMS, которые работают исключительно хорошо.

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

В рамках этого проекта я оценивал ActiveMQ, Tibco EMS и FioranoMQ, и SonicMQ был, безусловно, лучшим решением, особенно для клиентов C #. Это дорого, но стоит посмотреть.

1 голос
/ 07 апреля 2009

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

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

1 голос
/ 06 апреля 2009

Вы смотрели на RabbitMQ ? Не могу сказать, что сам испытал это на себе, но когда ребята из Rabbit выступили с технологическим докладом на работе, они, казалось, знали, о чем говорили:)

0 голосов
/ 13 мая 2016

Мы написали одноранговую шину сообщений Zebus, основанную на ZeroMq (транспорт), Cassandra (одноранговое обнаружение и сохранение) и Protobuf (сериализация).

Это открытый исходный код и тестирование производства https://github.com/Abc-Arbitrage/Zebus

Зебус активно развивается и широко используется на производстве.

0 голосов
/ 08 апреля 2009

Apache ActiveMQ также поддерживает .NET (и многие другие языки). Открытый исходный код, а также доступны с коммерческой поддержкой.

http://activemq.apache.org

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

...