Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

Beispielprogramme für Publish / Subscribe Server

Mit diesen Beispielprogrammen soll gezeigt werden, wie ein einfacher Publish- und Subsribe-Dienst in einer UTM-Anwendung realisiert werden kann.

Funktion

Ein Benutzer kann sich beim Dienst anmelden (subsrcibe). Er bekommt dann alle ab diesem Zeitpunkt veröffentlichten Nachrichten (publish) in seiner USER-Queue zugestellt.Die möglichen Kommandos an den Dienst sind:

  • help: Hilfetext holen

  • subscribe: Nachrichten abonnieren

  • unsubscribe: Nachrichten abbestellen

  • who: Namen der Abonnenten ausgeben

  • publish <message>: Nachricht veröffentlichen

Der Dienst wird von einem Asynchron-Vorgang mit dem TAC PUBSUBA erbracht, der ständig an der TAC-Queue PUBSUBMQ auf Aufträge wartet. Die Benutzer kommunizieren mit dem Dienst über den Dialog-Vorgang PUPSUBD. Auftragsbestätigungen werden an die USER-Queue des Benutzers gesendet und können z.B. mit dem Dialog-Programm UPDGET gelesen werden (siehe Beispielprogramme zur Asynchron-Verarbeitung für UPIC-Client). Außerdem kann in jedem Teilprogramm beim INIT PU abgefragt werden, ob Nachrichten in der Queue des Benutzers vorliegen.

Der Dienst muss nur einmal durch Aufruf des TAC PUBSUBA gestartet werden. Der offene Asynchron-Vorgang bleibt dann auch über den Anwendungslauf hinweg erhalten. Nach Neugenerierung wird er durch KDCUPD in die neue Anwendung übertragen.

Sollte sich durch einen Fehler der Asynchron-Vorgang abnormal beenden, so wird der zuletzt bearbeitete Auftrag in die Dead Letter Queue gestellt.

Auslieferung

Die Programme sind Bestandteil der Beispielanwendung und werden als pubsubd.c und pubsuba.c ausgelietert.

UTM-Generierung

Die Anweisungen für die Teilprogramme im KDCDEF-Lauf sind in den einzelnen Sourcen als Kommentar angegeben. Ebenso die Anweisung für die TAC-Queue „PUBSUBMQ“.

Es muss mindestens ein GSSB generiert werden (MAX GSSBS), da der Service zur Verwaltung der Abonnenten den GSSB „PUBSUBGB“ verwendet.

Soll nach Abbruch des Service der zuletzt bearbeitete Auftrag in die Dead Letter Queue gestellt werden, so muss MAX REDELIVERY = (...,0) generiert werden. Ansonsten bleibt er in der Auftragsqueue PUBSUBMQ.