Seminar Großrechneraspekte Messaging Systeme MQSeries Doreen Baum

Überblick MQSeries-Architektur Kommunikation zwischen Queue-Managern Aktivieren von Applikationen Kommunikation zwischen Client und Server MQI (Message-Queuing-Interface) Code Fragment Zusammenfassung

MQ-Series – Architektur

Bausteine und Gesamtarchitektur

Bestandteile des Queuing-Systems Queue-Manager (MQM) Listener Trigger-Monitor Channel-Initiator Message-Channel-Agent (MCA oder Mover)

Kommunikation zwischen Queue-Managern

Kommunikation zwischen 2 Queue-Manager

Automatischer Kommunikationsstart

Möglichkeiten der Aktivierung Sobald die erste Nachricht auf die Xmit-Queue gelegt wird Jedesmal, wenn eine Nachricht auf die Xmit- Queue gelegt wird Erst wenn die Queue eine bestimmte Anzahl von Nachrichten enthält Queue-Manager startet das Channel-Programm:

Aktivierungsablauf

Aktivieren von Applikationen

Aktivieren einer Applikation

Aktivierungstypen every: es wird eine Nachricht in den Ziel-Queue geschrieben first: sobald die Ziel-Queue leer wird n messages: es befinden sich n Nachrichten in der Ziel-Queue Eine Trigger-Message wird in die Initiation-Queue geschrieben, wenn:

Kommunikation zwischen Client und Server

Arten von Clients 1.Fat-Client –Verfügen über lokalen Queue-Manager 2.Slim-Client oder MQSeries-Client –Haben keinen lokalen Queue-Manager –Nur arbeitsfähig, wenn Client mit einem Server verbunden ist

MQI und Massage-Channels

Rechner-Type MQSeries-Client  Slim-Client MQSeries-Server  Zwischen-Knoten Leaf-Node  Fat-Client

Client/Server-Kommunikation

Kommunikations-Modi synchron: –Applikation wartet auf eintreffende Nachrichten –Verarbeitung fortsetzen nach Eintreffen asynchron –Verarbeitung beginnt, wenn Applikation gestartet wird und eine Nachricht vorhanden ist

Massage-Queuing-Interface (MQI)

API-Calls MQCONN: Verbindung mit Queue-Manager herstellen MQCONNX:Verbindung mit Queue-Manager über eine schnelle Verbindung herstellen MQBEGIN:startet eine Arbeitseinheit, die von einem Queue-Manager koordiniert wird

API-Calls MQOPEN:öffnet eine Queue MQPUT:legt eine Nachricht auf eine Queue MQCLOSE:schließt eine Queue MQPUT1:Kombination von MQOPEN, MQPUT und MQCLOSE MQINQ:fordert Informationen über den Queue-Manager oder eines seiner Objekte an

API-Calls MQSET:verändert einige Attribute eines Objektes MQCMIT:abgelegte Nachrichten werden verfügbar gemacht und zurück gekommenen Nachrichten werden gelöscht MQBACK:abgelegte Nachrichten werden gelöscht und zurück gekommene Nachrichten werden wieder auf Queue gelegt

API-Calls MQDISC:trennt die Verbindung zum Queue-Manager

Code Fragment MQCONN HCON;// Connection handle MQHOBJ Hobj1;// Object handle for queue 1 MQHOBJ Hobj2;// Object handle for queue 2 MQLONG CompCode, Reason;// Return Codes MQOD od1 = {MQOD_DEFAULT};// Object Descriptor queue 1 MQOD od2 = {MQOD_DEFAULT};// Object Descriptor queue 2 MQMD md = {MQMD_DEFAULT};// Message Descriptor MQPMO pmo = {MQPMO_DEFAULT};// Put message options MQGMO gmo = {MQGMO_DEFAULT};// Get message options // Verbindung zu Queue-Manager herstellen strcpy(QMName, "MYQMGR"); MQCONN(QMName, &Hcon, &CompCode, &Reason);

Code Fragment // Queue für die Ausgabe öffnen strcpy(od1.ObjectName, "QUEUE1"); MQOPEN(Hcon, &od1, MQOO_OUTPUT, &Hobj1, &CompCode, &Reason); // Nachricht auf den Queue legen MQPUT(Hcon, Hobj1, &md, &pmo, 100, &buffer, &CompCode, &Reason); // Queue für die Ausgabe schließen MQCLOSE(Hcon, &Hobj1, MQCO_NONE, &CompCode, &Reason);

Code Fragment // Queue für die Eingabe öffnen options = MQCO_INPUT_AS_Q_DEF; strcpy(od2.ObjectName, "QUEUE2"); MQOPEN(Hcon, &od2, options, &Hobj2, &CompCode, &Reason); // Get Message gmo.Options = MQGMO_NO_WAIT; buflen = sizeof (buffer-1); memcpy(md.MSGId MQMI_NONE, sizeof (md.MsgId); memset(md.CorrelId, 0x00, sizeof (MQBYTE24)); MQGET(Hcon, &Hobj2, &md, &gmo, buflen, buffer, 100, MQOPEN, &CompCode, &Reason);

Code Fragment // Queue für die Eingabe schließen options = 0; MQCLOSE (Hcon, &Hobj2, options, &CompCode, &Reason); // Verbindung zum Queue-Manager trennen MQDISC(Hcon, &CompCode, &Reason);

Zusammenfassung MQSeries-Applikationen können mit minimalem Aufwand entwickelt und getestet werden Auf vielen Plattformen lauffähig, deshalb gute Kommunikation über Netzwerk mit unterschiedlichen Komponenten Konsistentes API auf allen Plattformen

Literatur Einführung in z/OS und OS/390 P.Herrmann/U.Kebschull/W.G.Spruth