SQL Service Broker als generischer Enterprise Message Bus für .net

Question

Ich benötige eine Enterprise Service Bus/Message Queuing-Lösung für Publisher/Subscriber-Funktionalität. Ich weiß, VIELE existieren ... MSMQ, MS-Serie, RabbitMQ, NServiceBus, etc usw. ...

Meine eine Voraussetzung ist, dass in einer gemeinsamen Hosting-Lösung, die einzige Abhängigkeit, die ich garantieren kann, ist SQL 2005 und später ... das führt mich direkt zu SQL Service Broker.

Wenn es klingt wie ich versuche, ESB-Funktionalität in SSB zu Schuhanzieher ... Ich glaube, ich bin ...

Meine Frage ist: Wer weiß, einen .NET-API oder Framework, das auf der Oberseite sitzt von SQL Service Broker und bietet bereits viel von den Sanitäranlagen?

Wenn ich rein ADO.net verwenden, ich Artikel zu den Warteschlangen hinzufügen könnte durch eine gespeicherte Prozedur aufrufen, aber dann:

1. der Natur der Gespräche tun, würde ich ein Gespräch pro Nachricht machen ?
2. Wenn ja, verliere ich sequenzielle Nachricht Verarbeitung?
3. Wie bekomme ich Nachrichten (ich kenne die Empfangssyntax in t-SQL), rufe ich eine gespeicherte Prozedur wiederholt in einer Nachrichtenschleife an, um zu versuchen, eine Nachricht aus der Warteschlange zu bekommen?
4. Oder würde ich WAITFORever? Die Verbindung offen halten und die gespeicherte Prozedur für immer ausführen?
5. SQL Service Broker nicht Monolog Gespräche unterstützen, aber ich las sie umgesetzt werden kann ...

Es ist diese Art von Fragen, die ich dort machen wollen existierte eine .net-Lösung, die all dies bereits geschaffen .

Answer 1

Es gab eine Anstrengung, eine WCF Transport Channel for SQL Server Service Broker zu verpacken, aber, afaik, ist Abandonware.

Aber NServiceBus unterstützt Service Broker als Transport, siehe Using NServiceBus and ServiceBroker.net und es gibt github Projekte wie A simple wrapper API for SQL Service Broker and an ITransport plugin for NServiceBus. Obwohl es nicht gerade Mainstream ist, gibt es einige Support- und Community-Bemühungen.

Als ein ESB denke ich, dass Sie Probleme wegen des Mangels an echten Pub-Sub und Broadcast haben werden. SQL Server 2012 kann eine Nachricht an mehrere Ziele senden, siehe How to Multicast messages with SQL Server Service Broker, aber Sie müssen die Pub-Sub-Infrastruktur (Veröffentlichen von Themen, Abonnenten usw.) von Grund auf neu implementieren. MySpace tat das und war eine große Anstrengung, siehe Scale out SQL Server by using Reliable Messaging. Meine Beobachtung bezieht sich auf die direkte Verwendung von SSB auf niedriger Ebene. Ich habe NServiceBus nie benutzt, daher kann ich nicht sagen, wie gut es Unicast/Broadcast/Multicast/Pub-Sub über SSB abstrahiert/aussetzt.

Wie für Ihre spezifischen Fragen empfehle ich lesen Writing Service Broker Procedures und Reusing Conversations.