Motivation
Stellen Sie sich vor, sie entwickeln eine Applikation für ein Unternehmen, z.B. eine Versicherung, das Außendienstmitarbeiter beschäftigt, um neue Kunden zu akquirieren oder Schadensberichte zu erstellen. Mit seinem Laptop füllt dieser Außendienstler die erforderlichen Formulare aus und sendet sie an das Unternehmen - wenn eine Verbindung zum Firmennetz besteht, wovon man nicht immer ausgehen kann. Der Auftrag kann also unter Umständen nicht abgeschlossen werden. Es ist jedoch kaum zumutbar, dass die Anwendung so lange blockiert ist, bis wieder eine Verbindung zum Firmennetzwerk besteht. Noch schlimmer wäre es, wenn die Aufträge verloren gingen, da sie nicht gesendet werden können. Auch soll der Außendienstmitarbeiter nicht damit belästigt werden, immer daran denken zu müssen, alle Aufträge manuell an das Unternehmen zu übermitteln, sobald er die Möglichkeit dazu hat. Vielmehr ist es wünschenswert, dass das Abschicken des Auftrags sowohl für den Nutzer als auch für Ihre Applikation transparent geschieht.Allein an diesem Gedankenspiel lässt sich schnell erkennen, dass Applikationen, die zur Unterstützung der Geschäftsabläufe eines Unternehmens eingesetzt werden, sich wesentlich von Applikationen unterscheiden, die auf einem Einzelplatz-System zum Einsatz kommen. Diese Anwendungen zeichnen sich dadurch aus, dass sie gleichzeitig von vielen Benutzern genutzt werden, oft über große Entfernungen verteilt sind und mit unternehmenskritischen Daten arbeiten.
Entwickler von verteilten, unternehmenskritischen Applikationen sehen sich daher mit einer Vielzahl von Anforderungen konfrontiert, die nicht nur die funktionalen Eigenschaften sondern auch nicht-funktionale Eigenschaften der Anwendung betreffen. Funktionale Eigenschaften entsprechen der Funktionalität, die von einer Anwendung zur Verfügung gestellt wird; nicht-funktionale Eigenschaften hingegen betreffen die Qualitätsattribute einer Software wie z.B. Zuverlässigkeit und Verfügbarkeit, aber auch Performance und Skalierbarkeit.
Middleware
Die zentrale Eigenschaft der hier genannten Anforderung ist die Unabhängigkeit von einem konkreten Unternehmen und einem konkreten Einsatzfeld. Sie bezieht sich nicht explizit auf Geschäftsprozesse und Funktionen sondern auf technische Rahmenbedingungen. Es bietet sich daher an, Anwendungs- und Infrastrukturkomponenten getrennt voneinander zu betrachten. Anwendungskomponenten realisieren die Anwendungslogik einer Applikation, d.h. sie sind für die Abwicklung von Geschäftsprozessen verantwortlich und stellen die gewünschten Funktionen zur Verfügung. Infrastrukturkomponenten werden in der Literatur oft unter dem Begriff Middleware-Plattform zusammengefasst. Middleware-Plattformen zeichnen sich dadurch aus, dass sie Anwendungskomponenten eine Reihe von anwendungsunabhängigen Diensten zur Verfügung stellen, um Sie als Anwendungsentwickler zu entlasten. Anstatt zusätzlichen Aufwand in die Infrastruktur zu stecken, können sie sich ganz auf die Entwicklung der Anwendungslogik konzentrieren.Die Art der Middleware-Plattform, die ich Ihnen in diesem Artikel vorstellen möchte, wird als Message-oriented Middleware (MOM) bezeichnet.
Message-orientierte Middleware
Message-oriented Middleware stellt dem Entwickler eine Möglichkeit zur asynchronen, zuverlässigen Übertragung von Nachrichten zur Verfügung. Kurz gesagt, Applikationen kommunizieren miteinander, indem sie Nachrichten austauschen (siehe Abb. 1)
Das Verschicken und Empfangen von Nachrichten wird durch Nachrichtenschlangen, so genannte Message Queues, organisiert. Möchte eine Anwendung eine Nachricht verschicken, dann wird diese mit Angabe der Message Queue an das Message Queuing-System übergeben, das die Lokalisierung des Empfängers und das Verschicken der Nachricht übernimmt
Abpictureung 2 zeigt, wie die Kommunikation über Queues aus Abpictureung 1 implementiert werden kann und welche Komponenten daran beteiligt sind. Das Message Queuing-System ist für das Entgegennehmen, Weiterleiten und Zustellen von Nachrichten verantwortlich. Jede Applikation, die Nachrichten versenden oder empfangen möchte, muss mit einem Queuing Server verbunden sein. Der Queue Manager ist die zentrale Komponente des Queuing Servers; dieser kommuniziert mit den Applikationen und anderen Queuing Servern, um eine Nachricht vom Sender zum Empfänger zu leiten. Er hat Zugriff auf einen Speicher, das Message Repository, in dem Nachrichten zwischengespeichert werden können - dies ist unter anderem immer dann nötig, wenn eine Nachricht nicht augenblicklich weitergeleitet oder zugestellt werden kann.
Mit Hilfe von Message Queuing-Systemen können beinahe beliebig komplexe Anwendungsszenarien realisiert werden. Egal wie komplex Ihre Kommunikationsstruktur auch sein mag, sie lässt sich auf wenige Modelle zurückführen. Abpictureung 3 zeigt einen Überblick über die grundlegenden Kommunikationsmodelle.
Gängige Message Queuing-Systeme bieten Ihnen eine Vielzahl von Möglichkeiten, den Versand von Nachrichten zu konfigurieren. Einige davon möchte ich Ihnen im folgenden Abschnitt vorstellen.
Transportmodus
Beim Versenden einer Nachricht können Sie entscheiden, wie diese Nachricht gesendet werden soll. Sie können eine Nachricht im Express-Modus verschicken, was bedeutet, dass die Message direkt vom Sender über die Queue Manager an den Empfänger weitergeleitet wird - eine Zwischenspeicherung der Nachricht im Message Repository findet nicht statt! Die Intention dahinter ist, wie der Name bereits vermuten lässt, maximale Performance bei der Nachrichtenübertragung. Da die Message nicht lokal zwischengespeichert werden muss, ist der Versand einer Nachricht ausgesprochen schnell. Das bedeutet aber auch, dass das Message Queuing-System keine Garantie übernimmt, ob Ihre Nachricht gesendet wird. Eine Message geht verloren, wenn z.B. der Queue Manager zum Sendezeitpunkt nicht über eine Netzwerkverbindung verfügt und somit Ihre Nachricht nicht weiterleiten kann. Um zu verhindern, dass Ihre Nachricht verworfen wird, müssen Sie eine Message im Recoverable-Modus versenden. Dann garantiert Ihnen das Message Queuing-System, dass Ihre Nachricht genau einmal beim Empfänger ankommt. Um diese Garantie übernehmen zu können, wird eine Nachricht jedoch bei jedem Queue Manager zwischengespeichert, der an der Weiterleitung beteiligt ist - diese Tatsache hat allerdings signifikante Auswirkung auf die Geschwindigkeit der Nachrichtenübermittlung.Transaktionen
Wie Sie gerade gesehen haben, werden Nachrichten im Recoverable-Modus zuverlässig versandt. Dies schützt Ihr System jedoch keineswegs vor Inkonsistenzen! Stellen Sie sich vor, Ihre Anwendung liest Bestellungen aus einer Queue, verarbeitet diese und schreibt Aufträge in Queues einzelner Fachabteilungen, die für die Weiterverarbeitung verantwortlich sind. Tritt nun währenddessen ein Fehler auf, kann es passieren, dass die Bestellung bereits aus der Queue entnommen wurde und einige, aber noch nicht alle Aufträge an die beteiligten Abteilungen gesandt wurden. Um solche oder ähnliche Inkonsistenzen zu verhindern, können Nachrichten innerhalb einer Transaktion gesendet bzw. empfangen werden. Innerhalb der Transaktionsgrenzen werden entweder alle oder keine Nachrichten gesendet bzw. konsumiert.Scheduling
Ein weiteres Feature, das Message Queuing-Systeme anbieten, ist das Scheduling von Nachrichten. Oftmals ist es wünschenswert, dass Nachrichten nicht in der Reihenfolge, in der sie versendet wurden, zugestellt werden (FIFO = First In First Out). Stattdessen sollen sie z.B. gemäß ihrer Priorität bevorzugt oder zurückgestellt werden (Priority Scheduling). Denken Sie z.B. an ein Job Scheduling-System: Eine eingehende Nachricht stellt einen Auftrag dar, der abgearbeitet werden soll. Anhand der Priorität kann das Message Queuing-System entscheiden, welcher der Aufträge, die bereits in der Queue angelaufen sind, als nächstes zu bearbeiten ist - und das, ohne dass weitere Applikationslogik entwickelt werden müsste.Konsequenzen
Die Verwendung von Message Queuing-Systemen hat für Ihre Applikation verschiedene Konsequenzen, Vorteile wie auch Nachteile. In den folgenden Abschnitten wollen wir zunächst die Vorteil betrachten.Asynchrone Kommunikation
Anwendungen kommunizieren, indem sie Nachrichten in Message Queues hinterlegen. Dies bringt den Vorteil, dass keine direkte Verbindung zwischen den einzelnen Applikationen benötigt wird und Programme somit nicht zur selben Zeit ablaufen müssen. Eine Applikation kann beschäftigt sein, während eine Nachricht in deren Queue hinterlegt wird - dies beeinflusst jedoch in keiner Weise die Ausführung gegenwärtiger Prozesse. Konkret bedeutet dies, dass zwei Anwendungen asynchron zueinander arbeiten und unabhängig davon sind, wann eine Nachricht übermittelt wird.Offlinebetrieb und Fehlertoleranz
Da die Kommunikation nicht direkt, sondern indirekt stattfindet und das Message Queuing-System die Möglichkeit hat, Nachrichten zwischenzuspeichern, ist es für Ihre Applikation nicht notwendig, über eine ständige Verbindung zum Rest des Systems zu verfügen. Dieser Fall ist insbesondere für mobile Endgeräte interessant, die nicht immer an ein Netzwerk angeschlossen sind. Ein lokaler Queuing Server kann Nachrichten entgegennehmen und automatisch weiterleiten, wenn wieder eine Netzwerkverbindung besteht. Aber auch für nicht mobile Systeme ist diese Option durchaus wertvoll. In einer traditionellen Client/Server-Umgebung ist ein Client ständig auf die Erreichbarkeit des Servers angewiesen. Sind die Netzwerkverbindung zum Server oder der Server selbst ausgefallen, kann auch der Client seine Arbeit nicht fortsetzen. Die Zwischenspeicherung von Nachrichten garantiert Ihnen, dass in dieser Situation keine Nachricht verloren geht und, sobald das System wieder funktionsfähig ist, die Message versandt wird - und dies geschieht für den Client völlig transparent!Lose Kopplung
In einer klassischen Client/Server-Umgebung kommunizieren Applikation direkt miteinander - in letzter Konsequenz über entfernte Methodenaufrufe. Man spricht in diesem Fall davon, dass sie eng aneinander gekoppelt sind. Ein Dienstnutzer muss dabei mindestens zwei Dinge über einen Dienstanbieter wissen: zum einen, wo der Dienst zu finden ist, und zum anderen, welches Interface ein Dienst bereitstellt. Durch den Einsatz einer Service-orientierten Architektur [3, 4] können Sie vermeiden, dass ein Dienstnutzer die Verbindungsinformationen zu allen benötigten Diensten vorab kennen muss - diese können zur Laufzeit dynamisch ermittelt werden. Sie können aber nicht verhindern, dass der Dienstnutzer bereits zur Compilezeit (!) die Interfaces aller Dienste, die er nutzen wird, kennen muss.Indem Applikationen indirekt, also über Message Queues miteinander kommunizieren, können Sie ein Höchstmaß an loser Kopplung erzielen. Zum einen übernimmt das Message Queuing-System die Lokalisierung des Empfängers und zum anderen ist eine Anwendung nicht länger an die Interfaces anderer Anwendungen gebunden - sie kommuniziert jetzt über das Message Queuing-Systems mit diesen. Anwendungen sind damit nicht länger von einander, sondern von den auszutauschenden Nachrichtenformaten abhängig.
Interoperabilität
Viele Unternehmen gehen heute dazu über, ihre Geschäftspartner (z.B. Kunden und Lieferanten) in die eigenen Geschäftsprozesse einzubeziehen. Um höchste Effizienz zu garantieren und den viel beschworenen Medienbruch zu vermeiden, müssen die (Legacy-)Systeme beider Parteien in der Lage sein, miteinander zu interagieren (Enterprise Application Integration). Dies stellt insbesondere dann ein Problem dar, wenn die beteiligten Applikationen auf völlig unterschiedlichen Plattformen wie z.B. Windows und Unix laufen. Als Anwendungsentwickler sehen Sie sich vor die Aufgabe gestellt, Interoperabilität zwischen beiden Anwendungen sicher zu stellen. Wenn Sie sich für Message Queuing-Systeme entscheiden, ist die Schlacht schon fast gewonnen. Da die einzelnen Anwendungen nicht direkt miteinander kommunizieren, ist es nicht notwendig, dass sie kompatibel sind - Sie müssen nur gewährleisten, dass sie dieselben Nachrichten(-formate) verarbeiten können. Aber auch da können Ihnen Message Queuing-Systeme Arbeit abnehmen. Viele Systeme erlauben Ihnen, Transformationen zu definieren. So kann eine Nachricht während der Übertragung vom Quellformat des Senders in das Zielformat des Empfängers transformiert werden.Rückgabewerte
So viel zu den Vorteilen von Message Queuing-Systemen. Im Folgenden soll allerdings auch kurz auf einige ihrer Nachteile eingegangen werden.Asynchrone Kommunikation gestaltet sich erheblich komplizierter als synchrone Kommunikation sobald Rückgabewerte ins Spiel kommen. Es liegt in der Natur einer asynchronen Nachricht, dass der Empfänger keinen direkten Rückgabewert liefern kann. Stattdessen müssen Rückgaben durch eine weitere asynchrone Nachricht simuliert werden. Folglich muss Ihre Applikation zusätzliche Logik zur Synchronisierung beider Kommunikationspartner implementieren.
Komplexität
Der Einsatz von Message Queuing-Systemen mag zwar für Sie in der Rolle als Anwendungsentwickler viele Vorteile bereitstellen; dennoch muss man sich der Tatsache bewusst sein, dass die Komplexität des Gesamtsystems durch den Einsatz zusätzlicher Middleware steigt. Die Wartung des Gesamtsystems ist womöglich aufwändiger und damit auch teurer. Es ist daher unerlässlich, genauestens zu prüfen, ob der Einsatz von Message Queuing-Systemen in einem gegebenen Fall gerechtfertigt ist.Fazit
Mit diesem Artikel wollte ich Ihnen die fundamentalen Konzepte Message-orientierter Middleware aufzeigen. Sie haben gesehen, wie der Einsatz von Message-orientierter Middleware Ihnen dabei helfen kann, die Anforderungen von verteilten, unternehmenskritischen Applikationen zu erfüllen. Nachdem die theoretischen Grundlagen der Anwendungsentwicklung rund um Messaging Systeme gelegt worden sind, ist es an der Zeit, das Gelernte praktisch umzusetzen. Im zweiten Teil des Artikels möchte ich Ihnen daher die Welt der Microsoft Message Queues (MSMQ) vorstellen und wie Sie deren Möglichkeiten als Anwendungsentwickler für die .NET-Plattform nutzen können.Links und Literatur
- [1] Helmut Balzert, Lehrbuch der Software-Technik, Spektrum, 2000
- [2] Shahram Dustdar et al., Software-Architekturen für verteilte Systeme, Springer, 2003
- [3] Matthew MacDonald, Microsoft .NET Distributed Applications, Microsoft Press, 2003
- [4] Dominik R. Tornow, Dienstleistungsgesellschaft: Service-orientierte Architekturen und Web Services, in dot.net magazin 1.2004
- [5] Dominik R. Tornow, Rahmenbedingungen: Erstellung eines Service-orientierten Frameworks mit .NET Remoting, in dot.net magazin 3.2004
