Отделяне на MSMQ чрез изпращане на съобщения чрез WCF услуга

Тъкмо завършвам огромен проект за компанията, в която работя, който е подобен на вашия.

Той разчита изцяло на WCF, използвайки NetTcpBinding и запазвайки цялата информация в база данни на Sql сървър.

Основната услуга на WCF е отговорна за запазването на информацията в базата данни. Други wcf услуги връщат данните на клиентите, които се нуждаят от тях (32" сензорен екран, окачен на стената ни, настолни джаджи, смартфони).

Има обща библиотека, която съдържа дефинициите на договора и всички свързани с клиента неща, които се използват от всички приложения тук (10+). Всички тези приложения записват всичко срещу услугата wcf (винаги в асинхронни операции): изключения, предупреждения, сърдечни удари, дори информация за отстраняване на грешки. Броят на клиентите тук не е голям, това са около 60 компютъра, работещи с 1 или 2 приложения едновременно.

Таблото за управление е WPF приложение, което продължава да се свързва с wcf услуга, за да знае дали има актуализации въз основа на приоритета и след това да ги показва в приятен потребителски интерфейс.

Между 60+ клиента имаме 15 RTU, които изпращат температура (ºC) и налягане (барове) на тръби за природен газ от 3 различни града до един и същи сървър, тази информация се получава от услуга на Windows чрез Tcp и след това се изпраща до услугата wcf (на същия сървър). Всички тези данни са критични!! Имаме дори друга услуга на Windows, която продължава да търси услуга wcf, за да намери важни събития и да изпрати SMS до лицата, свързани с този тип събитие.

Soooooo, IMO wcf е страхотна технология за постигане на вашите цели!

Ако искате да избегнете тясното свързване с MSMQ, бих предложил да използвате нещо като домашна автобусна абстракция, която приема съобщението и след това го изпраща на MSMQ по какъвто начин искате да го направите. По този начин винаги можете да включите различна реализация, която използва каквото желаете (RabbitMQ, някакво директно db persistence или каквото и да се сетите). В противен случай, лично аз бих се опитал да поддържам обработката на съобщенията възможно най-евтина и възможно най-кратка. Може също да искате да разгледате статии за производителност на msmq като тази.

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

Знам, че всички сме научени да избягваме свързването на всяка цена, сякаш е някаква болест, но едно от предимствата на използването на WCF на първо място е, че не сте трудно свързани с конкретен транспорт. Можете да замените MSMQ с TCP само с промени в конфигурацията.

Както предлага @nieve, чрез създаването на абстракция вие наистина се отделяте от подробностите за изпълнението, в този случай WCF. По-добре ли е обаче да се свържете с вашето абстрактно автобусно представяне? Може да получите по-малко „свързване“, но може би за сметка на по-голямо замъгляване.

Обаждането до MSMQ през WCF има предимството, че това е малко количество код и може лесно да бъде взето от други разработчици с почти нулеви разходи за анализ. Бих предположил плахо, че може би прекалявате с проектирането на решение на проблем, който всъщност не съществува.

Помислете за разработчици, които идват нови във вашия проект след около 12 месеца. Искате да изградите система, при която те не прекарват първите два месеца в учене, преди да могат да бъдат продуктивни. Използването на познати рамки, които са предназначени да ви отделят до известна степен, може донякъде да постигне това.

В моите тестове WCF и NetTcpBinding са доста бързи (‹ 1ms двупосочно време).
Като използвате async, вие избягвате заключването на приложение, когато някои връзки са неуспешни.
AsyncWcfLib може да помогне за повишаване на нивото на абстракция.