Neben der transaktionsorientierten verteilten Verarbeitung, die höhere Kommunikationsprotokolle voraussetzt, kann eine UTM-Anwendung ohne globale Transaktionssicherung auch mit Anwendungen kommunizieren, die direkt auf der Transportsystemschnittstelle aufsetzen. Beispiele für solche Anwendungen sind CMX-Anwendungen auf Unix-, Linux- oder Windows-Systemen, DCAM-Anwendungen auf BS2000-Systemen oder beliebige TCP/IP-Socket-Anwendungen. UTM unterstützt auf Socket-Verbindungen das Protokoll HTTP sowie das UTM-spezifische UTM Socket Protokoll (USP). Im Folgenden werden Socket-Anwendungen, die über HTTP mit der UTM-Anwendung kommunizieren, als HTTP-Clients bezeichnet (siehe Kapitel "Kommunikation mit HTTP-Clients"), während Transportsystem-Anwendungen, die über USP mit der UTM-Anwendung kommunizieren, als Socket-USP-Anwendungen bezeichnet werden.
Da keine höheren Protokolle verwendet werden, ist bei der Kommunikation mit Transportsystem-Anwendungen eine Unterstützung globaler Transaktionen nicht möglich. openUTM kann in diesem Fall nur lokale Transaktionssicherheit gewährleisten.
Bei Störungen im Transportsystem oder bei abnormalem Ende der UTM-Anwendung ist nicht sichergestellt, dass eine Nachricht, die an eine TS-Anwendung gesendet wurde, von dieser auch empfangen und verarbeitet werden konnte. In diesem Fall ist sowohl ein Verlust als auch eine Verdoppelung der Nachricht möglich.
Im Folgenden ist beschrieben, was bei der Zusammenarbeit einer UTM-Anwendung mit Transportsystem-Anwendungen zu beachten ist.
Verbindungsaufbau
Die Initiative zum Verbindungsaufbau kann von der anderen Transportsystem-Anwendung oder von der UTM-Anwendung ausgehen. Bei Kommunikation mit HTTP-Clients geht die Initiative zum Verbindungsaufbau immer vom HTTP-Client aus.
Anmelden an die UTM-Anwendung
Baut die Transportsystem-Anwendung die Verbindung auf, dann wird sie unter einer fest dem Partner zugeordneten Benutzerkennung, der so genannten Verbindungs-Benutzerkennung, bei der UTM-Anwendung angemeldet.
Besitzt die UTM-Anwendung einen selbsterstellten Anmeldedialog (Event-Service SIGNON, siehe "Zugangskontrolle (Identifizierung und Authentisierung)"), dann wird dieser auch beim Anmelden von Transportsystem-Anwendungen (außer für HTTP-Clients) durchlaufen. Dieser Anmeldedialog kann z.B. dazu genutzt werden, der Transportsystem-Anwendung für die nachfolgende Verarbeitung eine echte Benutzerkennung zuzuweisen.
Transportsystem-Anwendungen können die „Multi-Signon“-Funktion nutzen, d.h. es können sich gleichzeitig mehrere Transportsystem-Anwendungen unter derselben echten UTM-Benutzerkennung anmelden, wenn für diese Benutzerkennung auf den Vorgangswiederanlauf verzichtet wird.
Eine Transportsystem-Anwendung kann unter demselben Anwendungsnamen mehrere parallele Transportverbindungen zu einer UTM-Anwendung aufbauen („Multi-Connect“).
Bearbeitung von Aufträgen
Eine Transportsystem-Anwendung (ungleich HTTP-Client) kann sowohl Asynchron- als auch Dialog-Aufträge an die UTM-Anwendung richten. Ein HTTP-Client kann nur Dialog-Aufträge an die UTM-Anwendung richten. Dabei muss Folgendes beachtet werden:
Die Aufträge von Transportsystem-Anwendungen (ungleich HTTP-Client) müssen in der von openUTM erwarteten Weise formuliert sein; d.h. die ersten acht Zeichen der Nachricht müssen den Transaktionscode enthalten, unter dem der zu startende Service bei openUTM generiert wurde. Ob es sich bei diesem Service um einen Dialog- oder einen Asynchron-Service handelt, erkennt openUTM anhand des Transaktionscodes.
Socket-USP-Anwendungen schicken einen Byte-Strom, während openUTM nachrichtenorientiert arbeitet. Damit die UTM-Anwendung Nachrichtengrenzen erkennen kann, muss eine Socket-USP-Anwendung das UTM Socket Protokoll (USP) verwenden, aus dem sich die Länge einer Nachricht erkennen lässt. Mit USP lassen sich auch Nachrichten in mehreren Teilen schicken, so dass die Gesamtnachricht größer sein kann als die maximale Größe des Eingabepuffers. Das USP kann wahlweise auch für die Ausgabe verwendet werden.
HTTP-Clients schicken ebenfalls einen Byte-Strom, der aber durch das HTTP-Protokoll beschrieben wird. openUTM analysiert das HTTP-Protokoll und übergibt dem Anwenderprogramm die Query und den Message Body des HTTP-Requests als Nachrichtenteile. Über einen HTTP-Exit kann eine Nachricht an ein Teilprogramm in mehrere Nachrichtenteile aufgeteilt werden.
Bei Dialog-Aufträgen muss für die Einhaltung des von openUTM geforderten strengen Dialogs gesorgt werden; d.h. die Partner-Anwendung muss den Empfang einer Antwort von der UTM-Anwendung abwarten, bevor sie die nächste Nachricht senden darf.
openUTM sendet keine Nachrichten der Länge 0 an Transportsystem-Anwendungen. Obwohl eine Nachricht der Länge 0 nicht gesendet wird, wechselt bei einer solchen Nachricht das Senderecht und openUTM wartet danach auf eine Nachricht der Transportsystemanwendung. Deshalb ist es notwendig, bei Mehrschritt-Dialogen auf die Logik des Dialogablaufs zu achten. An HTTP-Clients können grundsätzlich keine Nachrichten der Länge 0 geschickt werden.
Die Nachrichtenlängen bei Kommunikation mit HTTP-Clients und Nicht-Socket-Partnern sind durch die Größe des Ein-/Ausgabepuffers beschränkt.
Bei Kommunikation über das USP-Protokoll können die Nachrichten fragmentiert werden, siehe obiger Hinweis zu USP. Dabei wird nur die Länge eines Fragments beschränkt, die Länge der Gesamtnachricht ist hingegen unbeschränkt.
openUTM führt bei Nachrichten, die für andere Anwendungen bestimmt sind, keine Formatierung durch, d.h. die andere Anwendung erhält die Nachricht so, wie sie vom Teilprogramm im Nachrichtenbereich bereitgestellt wurde.
Es kann per Generierung eine automatische Code-Umsetzung (ASCII-EBCDIC) veranlasst werden.
Restart-Fähigkeit: Gegebenenfalls wird ein Service-Wiederanlauf für Dialog-Services durchgeführt und dabei die letzte Ausgabe-Nachricht wiederholt.
Während des Betriebs einer UTM-Anwendung können Meldungen erzeugt werden, die den Kommunikationspartner der UTM-Anwendung betreffen. Dabei werden den Kommunikationspartnern nur diejenigen UTM-Meldungen zugestellt, für die in dem UTM-Meldungsmodul das Ziel PARTNER angegeben wurde. Durch Erzeugen eines eigenen Meldungsmoduls kann dieses Meldungsziel für weitere Meldungen hinzu- oder aber auch von Meldungen weggenommen werden (siehe jeweiliges openUTM-Handbuch „Meldungen, Test und Diagnose“). Diese UTM-Meldungen können innerhalb oder außerhalb eines Dialogs auftreten. Der Kommunikationspartner muss auf die Meldungen entsprechend reagieren können. An HTTP-Clients werden nur die Meldungen K017 und K034 gesendet unabhängig davon ob das Meldungsziel PARTNER angegeben wurde.
Werden von einer anderen Anwendung openUTM-Benutzerkommandos gesendet, so werden diese von openUTM nicht als solche interpretiert.
Verbindungsabbau
Den Anstoß zum Verbindungsabbau kann die andere Transportsystem-Anwendung oder die UTM-Anwendung geben. Soll der Verbindungsabbau durch die UTM-Anwendung erfolgen, so kann dies entweder durch direkte Eingabe eines Administrationskommandos geschehen, oder aus einem Teilprogrammlauf mittels eines Administrationsaufrufs oder eines KDCS-Aufrufs (SIGN OF). Für HTTP-Clients baut UTM nach jedem Vorgang die Verbindung ab, sofern der Connection-Header im HTTP-Request nicht mit "Keep-Alive" versorgt wird.
| Mehr über Kopplungen mit Socket-USP-Anwendungen finden Sie im openUTM-Handbuch „Anwendungen generieren“. |
