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

8

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

Meine einzige Anforderung ist, dass in einer Shared-Hosting-Lösung die einzige Abhängigkeit, die ich garantieren kann, SQL 2005 und höher ist ... dies führt mich direkt zu SQL Service Broker.

Wenn es sich anhört, als würde ich versuchen, die ESB-Funktionalität in SSB zu schüren ... Ich nehme an, ich bin ...

Meine Frage ist: Kennt jemand eine .NET API oder ein Framework, das auf SQL Service Broker sitzt und bereits einen Großteil der Installation bereitstellt?

Wenn ich reines ADO.net verwenden wollte, konnte ich den Warteschlangen Elemente hinzufügen, indem ich eine gespeicherte Prozedur aufruft, aber dann:

  1. Mache ich zu der Art von Gesprächen, würde ich eine Unterhaltung pro Nachricht führen?
  2. Wenn ja, verliere ich die sequentielle Nachrichtenverarbeitung?
  3. Wie bekomme ich Nachrichten (ich kenne die Empfangssyntax in t-SQL), rufe ich eine gespeicherte Prozedur wiederholt in einer Nachrichtenschleife auf, um zu versuchen Erhalten Sie eine Nachricht aus der Warteschlange?
  4. Oder würde ich WARTEN? Die Verbindung offen halten und die gespeicherte Prozedur für immer ausführen?
  5. SQL Service Broker unterstützt keine Monolog-Konversationen, aber ich habe gelesen, dass sie implementiert werden können ...

Es sind solche Fragen, die mich wünschen, dass es eine .net-Lösung gäbe, die das alles schon geschafft hat.

    
Novox 13.05.2014, 14:38
quelle

1 Antwort

7

Es wurde versucht, einen WCF-Transportkanal für SQL Server Service Broker zu packen, aber afaik heißt abandonware.

Aber NServiceBus unterstützt Service Broker als Transport, siehe Mit NServiceBus und ServiceBroker.net und es gibt github-Projekte wie Eine einfache Wrapper-API für SQL Service Broker und ein ITransport-Plugin für NServiceBus . Obwohl es nicht gerade Mainstream ist, gibt es einige Support- und Community-Bemühungen.

Als ESB denke ich, dass Sie Probleme haben werden, weil es keine echten Pub-Subs und Broadcasts gibt. SQL Server 2012 kann eine Nachricht an mehrere Ziele senden. Weitere Informationen finden Sie unter Multicast-Nachrichten mit SQL Server Service Broker , aber Sie müssen die Pub-Sub-Infrastruktur (Veröffentlichung Themen, Abonnenten usw.) von Grund auf neu zu implementieren. MySpace hat das gemacht und war eine große Anstrengung, siehe Scale out SQL Server mithilfe von zuverlässigem 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.

Was Ihre spezifischen Fragen anbelangt, empfehle ich Schreiben von Service-Broker-Verfahren und Wiederverwenden von Konversationen .

    
Remus Rusanu 13.05.2014, 18:35
quelle

Tags und Links