Your Browser is not longer supported

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

{{viewport.spaceProperty.prod}}

Kommunikationsmodelle

&pagelevel(3)&pagelevel

Für die Client-Server-Kommunikation hat der Programmierer drei Kommunikationsmodelle zur Auswahl:

  • Synchrones Request-Response-Modell: Einschritt-Dialog
    Der Client ist nach dem Senden der Service-Anforderung bis zum Eintreffen der Antwort blockiert.

  • Asynchrones Request-Response-Modell: Einschritt-Dialog
    Der Client ist nach dem Senden der Service-Anforderung nicht blockiert.

  • Conversational Modell: Mehrschritt-Dialog
    Client und Server können beliebig Daten austauschen.

Die für diese Kommunikationsmodelle notwendigen XATMI-Funktionen werden im Folgenden nur skizziert, dabei wird die C-Notation verwendet. Die genaue Beschreibung der XATMI-Funktionen finden Sie in der X/Open-Spezifikation „Distributed Transaction Processing: The XATMI Specification“.

Synchrones Request-Response-Modell

Für die Kommunikation wird im Client nur ein einziger tpcall()-Aufruf benötigt.

Der tpcall()-Aufruf adressiert den Service, schickt genau eine Nachricht an diesen ab und wartet solange, bis ihn die Antwort erreicht, d.h. tpcall() wirkt blockierend.

Bild 17: Synchrones Request-Response-Modell

In diesem Bild bezeichnet svc den intern verwendeten Namen des Services, svcinfo die Service-Info-Struktur mit dem Service-Namen und tpservice den Programmnamen der Service-Routine. Die Service-Info-Struktur ist Bestandteil der XATMI-Schnittstelle.

Bei diesem Modell muss auf der in der UTM-Anwendung ein Dialog-TAC für den angeforderten Service generiert sein.

Asynchrones Request-Response Modell

Bei diesem Modell wird die Kommunikation in zwei Schritten abgewickelt. Im ersten Schritt wird der Service mit dem Aufruf tpacall() adressiert und die Nachricht abgeschickt. Zu einem späteren Zeitpunkt wird im zweiten Schritt mit dem Aufruf tpgetrply() die Antwort abgeholt, siehe folgendes Bild.

Bild 18: Asynchrones Request-Response-Modell

In dem Bild bezeichnet svc den intern verwendeten Namen des Services, cd den prozesslokalen Communication Descriptor, svcinfo die Service-Info-Struktur mit dem Service-Namen und tpservice den Programmnamen desr Service-Routine.

tpacall() ist nicht blockierend, d.h. der Client kann in der Zwischenzeit weitere lokale Verarbeitungen durchführen, jedoch keinen weiteren Service parallel aufrufen, da bei Verwendung des Trägersystems UPIC zu einem Zeitpunkt nur ein Auftrag erlaubt ist.
Wenn der Client mehrere Services parallel beauftragen soll, müssen Sie das Trägersystem OpenCPIC verwenden.

tpgetrply() hingegegen ist blockierend, d.h. der Client wartet solange, bis die Antwort eingetroffen ist.

Bei diesem Modell muss auf in der UTM-Anwendung für den Service ein Dialog-TAC generiert sein (wie beim synchronen Request-Response).

Conversational Modell

Für verbindungsorientiertes Arbeiten („Conversation“) bietet XATMI das Conversational Modell an.

Dieses Modell kann z.B. verwendet werden, um große Datenmengen in mehreren Teilschritten zu übertragen. Damit können Probleme vermieden werden, die beim synchronen Request-Response Modell (Aufruf tpcall()) wegen der Größenbegrenzung der lokalen Datenpuffer auftreten könnten.

Beim Conversational Modell wird die Conversation zu einem Service explizit mit dem Aufruf tpconnect() aufgebaut. Solange sie besteht, können Client und Server mit tpsend() und tprecv() Daten austauschen. Dieser „Dialog“ ist jedoch kein Dialog im Sinne von OSI-TP und es kann nur eine Transaktion abgewickelt werden.
Beendet wird die Conversation, wenn der Server (d.h. die UTM-Anwendung) mit tpreturn() das Ende signalisiert; der Client erhält dann beim tprecv() in der Variablen tperrno einen entsprechenden Code. Daher muss das Client-Programm mindestens einen tprecv()-Aufruf enthalten.

Bild 19: Conversational Modell

In dem Bild bezeichnet svc den lokalen Namen des Services, cd den prozesslokalen Communication Descriptor, tpservice den Programmnamen der Service-Routine und svcinfo die Service-Info-Struktur mit dem Service-Namen und dem Communication Descriptor.

Bei dem Modell muss auf in der UTM-Anwendung für den Service ein Dialog-TAC generiert sein.
In Fehlerfällen kann der Client den Abbruch einer Conversation mit dem Aufruf tpdiscon() erzwingen.