Message Queuing (MQ) ist eine Form der Kommunikation, bei der Nachrichten (Messages) nicht unmittelbar, sondern über zwischengeschaltete Queues ausgetauscht werden. In openUTM sind mit dem Konzept der asynchronen Verarbeitung ausgereifte Message Queuing Funktionen integriert.
Der Begriff „asynchron“ wird oft für Programmierungsformen gebraucht, bei denen das Sender-Programm nach dem Verschicken einer Nachricht nicht auf die Antwort des Empfängers warten muss (non-blocking conversations). openUTM unterstützt natürlich auch diesen Programmierstil, bietet aber darüber hinaus ein breites und fein abgestuftes Spektrum an Steuerungsmöglichkeiten. Je nachdem, wer für die Verarbeitung der Nachrichten an einer Queue verantwortlich ist, unterscheidet man UTM-gesteuerte Queues und Service-gesteuerte Queues.
UTM-gesteuerte Queues
Eine UTM-gesteuerte Queue ist eine Message Queue, bei der der Abruf und die Weiterverarbeitung der Nachrichten vollständig durch openUTM gesteuert werden. UTM-gesteuerte Queues werden für Hintergrundaufträge und Ausgabeaufträge verwendet. Sämtliche MQ-Funktionen stehen sowohl sendeseitig als auch empfangsseitig zur Verfügung, daher müssen Sie derartige Queues und deren Queue-Manager nicht eigens generieren oder konfigurieren und auch keine speziellen Trigger- oder Polling-Mechanismen konstruieren.
Service-gesteuerte Queues
Eine Service-gesteuerte Queue ist eine Message Queue, bei der der Abruf und die Weiterverarbeitung der Nachrichten durch Services gesteuert werden. D.h. der Empfänger der Nachricht ist dafür verantwortlich, dass diese gelesen und verarbeitet wird. Servicegesteuerte Queues gibt es in den Varianten USER-Queue, TAC-Queue und Temporäre Queue:
Eine USER-Queue ist eine Benutzer-spezifische Message Queue. Jedem UTM-Benutzer steht automatisch eine eigene USER-Queue zur Verfügung. Mit USER-Queues können Sie z.B. Mailbox-Mechanismen für UTM-Benutzer realisieren.
Eine TAC-Queue muss explizit per KDCDEF generiert werden (Ausnahme: Dead-Letter-Queue). TAC-Queues können von jedem Service unter ihrem generierten Namen angesprochen werden. TAC-Queues werden z.B. dazu verwendet, um UTM-Meldungen an den grafischen Administrationsplatz WinAdmin oder die Web-Anwendung WebAdmin weiterzuleiten und dort zu archivieren.
Eine Temporäre Queue wird dynamisch per Programm erzeugt und kann auch per Programm gelöscht werden. Mit Hilfe von Temporären Queues kann z.B. ein Dialog zwischen zwei voneinander unabhängigen Services realisiert werden.
Transaktionsgesicherter Deferred Delivery Mechanismus
openUTM arbeitet bei allen Message Queues mit dem transaktionsgesicherten Deferred Delivery Mechanismus: Sender und Empfänger können zeitlich und räumlich entkoppelt ablaufen, die Übermittlung der Nachricht wird garantiert, unabhängig davon, ob gerade eine Netzverbindung besteht oder nicht. Nachrichten werden in eine Queue eingetragen und solange zwischengespeichert, bis Leitung und Empfänger einsatzbereit sind. Zusätzliche Flexibilität bietet openUTM durch die Möglichkeit, beim Message Queuing mit Zeitsteuerung und Priority Scheduling zu arbeiten oder maximale Wartezeiten für Servicegesteuerte Queues zu definieren.
Dialogverarbeitung und Message Queuing sind frei kombinierbar: Innerhalb eines Dialogservices können MQ-Aufträge abgesetzt werden, ein asynchron gestartetes Serviceprogramm wiederum kann einen synchronen Dialog (conversation) mit einem fernen Dialog-Service führen. Besonders umfangreiche oder zeitunkritische Aufgaben - wie z.B. langsame Druckausgaben, langlaufende Statistikberechnungen, Sortierarbeiten, etc. - lassen sich so von Online-Dialogen entkoppeln, ohne dass auf Transaktionssicherheit verzichtet werden muss.
Realisierung moderner Einsatzkonzepte
Mit seiner Message Queuing-Funktionalität ist openUTM hervorragend geeignet für moderne Einsatzkonzepte wie beispielsweise Workflow-Strategien: Betriebliche Arbeitsabläufe werden in Schritte gegliedert und Zwischenstände von Anwendung zu Anwendung weitergereicht. Das Absender-Programm erwartet dabei nicht unbedingt eine Antwort vom Empfänger und vielleicht muss der nächste Schritt nicht sofort begonnen werden. Absolut verlässlich muss jedoch sein, dass der Zwischenstand auch wirklich beim Empfänger eintrifft. Der transaktionsgesicherte Queuing-Mechanismus von openUTM gewährleistet dies. Auch wenn das Netz gerade nicht verfügbar oder die Empfänger-Anwendung offline ist: openUTM garantiert, dass keine Message verloren geht oder verdoppelt wird.
Durch diese Unabhängigkeit von der Qualität und Verfügbarkeit der Verbindungsstrecke bildet openUTM eine sichere Basis-Middleware für Mobile Computing: Mobile Clients, z.B. Anwendungen, die auf Laptops laufen, können mit Servern zusammenarbeiten, ohne hierzu ständig mit ihnen verbunden sein zu müssen. Durch die transaktionsgesicherte lokale Sammlung von Messages wird eine geblockte Übertragung ermöglicht. Aufschaltzeiten werden hierdurch reduziert und damit Leitungskosten gesenkt.
Durch den Einsatz von USER-Queues und TAC-Queues lassen sich fein abgestimmte Konzepte für Mailbox-Systeme und Alarm-Mechanismen entwickeln, in die auch die Clients mit einbezogen sind. Für die Benutzer der Anwendung steigert sich der Komfort erheblich - sowohl für Kunden als auch z.B. für Administratoren. Dies erhöht die Akzeptanz und die Zukunftssicherheit der Anwendung.
Auch Data Warehouse-Lösungen und Decision Support-Systeme werden durch die Message Queuing-Funktionen von openUTM wirkungsvoll unterstützt. Solche Anwendungen arbeiten in der Regel mit sehr großen und heterogenen Informationspools: unternehmensinterne und oft auch externe Datenbestände aus verschiedensten IT-Systemen müssen verknüpft und ausgewertet werden. Die Informationen sollen einer großen Zahl von Benutzern zur Verfügung stehen. Da besonders zeitintensive Aufgaben über Message Queuing von den Dialogen entkoppelt werden können, sorgt openUTM dafür, dass die Antwortzeiten kurz bleiben. Falls es sich um reine Retrieval-Anwendungen handelt, bei denen Wiederanlauf eine weniger wichtige Rolle spielt, kann mit der Funktionsvariante UTM-F (Fast) gearbeitet werden (siehe Abschnitt „Wiederanlauf mit UTM-F").
| Weitere Informationen zum Thema „Message Queuing“ finden Sie in diesem Handbuch im Kapitel „Message Queuing“. |
