Просто правя някои бързи скокове в евентуалното използване на система за съобщения за обработка на файлове, които са в добре отделена система за работен поток.
Какви са плюсовете и минусите, които хората са открили при използването на всяка от горните рамки? Какви са предимствата от използването им в сравнение с ръчно навита MSMQ система с WCF свързвания и/или не-MSMQ решения??
Бих препоръчал да стоите далеч от ръчно разработени решения, тъй като има куп доста трудни неща, които трябва да бъдат нагласени както трябва - като как се обработват транзакциите, как изключенията причиняват връщания назад, как да спрете безкрайното връщане назад (отровни съобщения), как да се интегрира с дълготрайни работни потоци, така че границите на управление на състоянието да се подредят и други.
Вероятно ще искате някакъв вид трайна/транзакционна инфраструктура за съобщения, така че ако не използвате MSMQ, ще останете със Service Broker на платформата на Microsoft или друга алтернатива като ActiveMQ. MSMQ има предимството, че вече е инсталиран на всички машини с Windows, за разлика от Service Broker, който не е.
По отношение на избора между NServiceBus, Mass Transit и Rhino Service Bus - този отговор на Stackoverflow сравняването на NServiceBus с MassTransit би бил добър място за начало..
В нашата версия 3.1 представяме NSB Studio – набор от интегрирани инструменти за моделиране на Visual Studio, които ви позволяват да моделирате вашата система на по-високо ниво на абстракция и голяма част от конфигурацията и инициализацията на NServiceBus да се извършва автоматично вместо вас. Бих казал, че това наистина накланя везните в полза на NServiceBus.
Надявам се това да помогне.
Отказ от отговорност: Аз съм автор на NServiceBus.
NServiceBus е добър продукт, но внимавайте за проблеми с лицензирането. Има тенденция да променя лицензионната си политика според желанието на авторите. Разгледайте например старата информация за лиценза.
Може да се случи, че по средата на разработването на вашия проект ще разберете, че трябва да платите много пари за NServiceBus.
Безплатната версия също има ограничения на производителността.
MassTransit е абсолютно безплатен с отворен код, няма ограничения и е под лиценз Apache 2.0.
Не съм използвал Rhino Service Bus.
Актуализация на състоянието на Rhino срещу NServicebus:
http://www.infoq.com/news/2012/04/nservicebus3-0
InfoQ към Ayende: Вие преди това сами сте написали сервизна шина за .NET, а именно Rhino Service Bus. Трябва ли сега потребителите на Rhino Service Bus да преразгледат и да преминат към NServiceBus?
Ayende: Създадох Rhino Service Bus около 2008 г. Направих го най-вече защото не бях доволен от състоянието на другите сервизни автобуси по това време. Имах различни притеснения и насоки при изграждането на моя служебен автобус, но това беше преди 4 години. През това време мисля, че NServiceBus направи големи крачки в превръщането си в по-лесен за използване продукт и има много по-добра история за разработка извън кутията. Ако днес започвах със служебни автобуси, силно се съмнявам, че щях да правя свои собствени.
потенциален недостатък на всичко, базирано на MSMQ, е ограничението за максимален размер на съобщението. IIRC е приблизително 4 MB, което лесно може да попаднете, ако имате работа с големи файлове и съхранявате съдържанието на файла в съобщението.
