HowTo: Messaging mit MSMQ, ein Einstieg
Erst vor kurzem bin ich auf MSMQ gestoßen. MSMQ ist vereinfach gesagt ein System, in dem Nachrichten in Queues, also Warteschlangen, verarbeitet (angelegt/ausgelesen) werden können.
Wofür überhaupt?
MSMQ ist ein Warteschlangen System. Man steckt Nachrichten ein und irgendeiner holt diese ab und verarbeitet diese. Die kann in verteilten Anwendungen z.B. praktisch sein. So kann man z.B. Emails generieren und diese in eine Queue schreiben und Stück für Stück langsam verschicken, damit der Email-Server nicht in die Knie geht. Es gibt bestimmt noch weit, weit mehr Szenarien, aber das soll nur ein Einstieg sein 
Weiter unten gehe ich noch weiter auf ein paar Vor- und evtl. Nachteile ein. Hier wäre ich auch sehr froh Feedback von euch zu bekommen
Voraussetzungen
Die Infrastruktur für MSMQ ist seit XP (?) überall dabei. Man muss es nur in den Windows Funktionen mit aktivieren:
Danach ist im Computer-Management und Services der MSMQ Dienst zu sehen:
Man kann über das Kontextmenü (Rechtsklick) auch neue Warteschlangen einrichten und in die Warteschlangen auch reinschauen.
Dort kann man auch die einzelnen Nachrichten ansehen:
Für mein Democode ist es notwendig, dass man unter den Privaten Warteschlangen die “Test” Queue erstellt.
Zum Code
Im .NET Framework gibt es in der System.Messaging Assembly bereits alles, was man zum Starten braucht:
Neue Message in die Queue schreiben:
MessageQueue queue = new MessageQueue(@".\private$\test");
queue.Send("test");
Message auslesen:
MessageQueue queue = new MessageQueue(@".\private$\test");
Console.WriteLine(queue.Receive().Body.ToString());
Easy, oder? Bei “Receive” wird die erste Nachricht aus der Queue genommen. Diese ist dann für andere Clients auch nicht mehr erreichbar.
Komplexe Datentypen
Man kann natürlich auch komplexe Datenstrukturen senden, diese werden dann über den XmlSerializer in die Nachricht geschrieben und ausgelesen.
Hier mein komplettes Beispiel:
using System;
using System.Collections.Generic;
using System.Messaging;
using System.Text;
namespace MSMQ
{
public class User
{
public string Name { get; set; }
public DateTime Birthday { get; set; }
}
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Simple Text");
Console.WriteLine("Input for MSMQ Message:");
string input = Console.ReadLine();
MessageQueue queue = new MessageQueue(@".\private$\test");
queue.Send(input);
Console.WriteLine("Press Enter to continue");
Console.ReadLine();
Console.WriteLine("Output for MSMQ Queue");
Console.WriteLine(queue.Receive().Body.ToString());
Console.ReadLine();
Console.WriteLine("Complex Text");
User tester = new User();
tester.Birthday = DateTime.Now;
tester.Name = "Test Name";
queue.Send(tester);
Console.WriteLine("Output for MSMQ Queue");
User output = (User)queue.Receive().Body;
Console.WriteLine(output.Birthday.ToShortDateString());
Console.ReadLine();
}
}
}
Funktioniert, und weiter? Warum MSMQ benutzen?
Man kann solche Queuing Geschichten natürlich auch durch SQL oder andere Eigenentwicklungen umsetzen. Lohnt sich der Blick auf MSMQ?
Vor- und Nachteile (von diesem Stackoverflow Thread)
Cons:
- Each queue can only be 2GB.
- Each message 4MB (altough the 4MB limit can be fixed by using MSMQ with WCF).
- Only for Windows so you’re limited to use it with .NET, C/C++ or COM library for COM-enabled environments.
Pros:
- Supports Windows Network Load Balancer.
- Supports Microsoft Cluster Service.
- Integrated with Active Directory.
- Ships with Windows.
- Supports transactions.
- MSMQ messages can be tracked by audit messages in the Windows Event log.
- Messages can be automatically authenticated (signed) or encrypted upon sending, and verified and decrypted upon reception.
Frage an euch…
Nutzt ihr MSMQ? Oder doch lieber eine simple SQL Datenbank und flache Tabelle dafür nutzen? Zwar klingen die Pros gut, aber könnte ich dies nicht alles auch mit einer SQL DB bekommen? Gibt es irgendwo komplexere Beispiele, mit Transaktionen etc.?
Wahrscheinlich kann man am Ende nicht direkt sagen, was besser ist. Aber vielleicht hat jemand von euch ein paar gute Zusatzframeworks parat oder sagt irgendwelche No-Gos
Links
- Programming MSMQ with .NET
- Sehr interessant ist auch die Kombination WCF + MSMQ
- Best Practices for Queued Communication
About the author
Written by Robert Mühsig
Robert Mühsig (@robert0muehsig) ist Webentwickler und beschäftigt sich mit Web-Frameworks (vor allem dem ASP.NET MVC Framework) und scheut sich auch nicht vor Javascript. Ansonsten bloggt er über all jene Probleme, die ihm über den Weg laufen. Seit 2008 ist er Microsoft MVP für ASP.NET und er arbeitet bei der T-Systems Multimedia Solutions GmbH in Dresden. Treffen kann man ihn online via Twitter (@robert0muehsig) oder dieser Seite oder bei der .NET User Group Dresden.
Robert Meyer
7. September 2010
Hi Robert,
schau dir mal NServiceBus näher an. Könnte dich gerade bei stark verteilten Anwendungen unterstützen, wenn Beispielsweise Datenbanken nicht erreichbar sind und die Daten gecacht werden müssen.
Gruß
Robert
Bernhard
8. September 2010
Hallo Robert,
wir benutzen MSMQ für die Kommunikation des Web-Frontends mit Hintergrunddiensten.
Die Webseite stellt die Arbeitspackete in die Messagequeue und der Windows-Dienst nimmt diese auf und verarbeitet sie.
Funktioniert schnell und einfach.
Gruß
Bernhard
Robert Mühsig
8. September 2010
Hallo Bernhard,
unter den “Pros” hab ich bei Stackoverflow auch gelesen, dass man die MSMQs Clustern kann – auf die schnelle konnte ich aber dazu nichts finden. Wie bekommt man denn die MSMQs ausfallsicher? Kann man Cluster bilden?
Viele Grüße,
Robert
Bernhard
8. September 2010
Bzgl. Clustering hab ich nichts eingesetzt.
Wir haben das jedoch so gelöst, dass der Webserver in die Lokale Queue des Servers schreibt, der den Windows Dienst beherbergt. Würde also der Server ausfallen ist nicht nur die Queue, sondern auch der Dienst weg.
Wir haben hier allgemein diverse manuelle “Failover” Szenarien implementiert.
Die Entscheidung für MSMQ ist eigentlich aufgrund der Einfachheit gefallen und da wir diese temporären Packetinfos nicht über die Datenbank lösen wollten.
Gruß
Bernhard
Oliver
23. September 2010
Echt netter Post, hat sich jemand sehr viel Zeit genommen
Danke
Thomas Kowalski
10. October 2010
+1 nServiceBus
Dazu empfehle ich noch die Videos von Udi Dahan auf InfoQ. Sind echt erleuchtend