Dieses Dokument beschreibt die Implementierung des Transport Service auf Host-Systemen, bei denen Natural und Adabas installiert ist.
Dieses Dokument behandelt die folgenden Themen:
Die folgenden Begriffe werden im Zusammenhang mit dem Transport Service verwendet:
- Transport Service-Adresse
Bezeichnet Absender und Empfänger von Transportobjekten, die mit dem Transport Service verschickt werden. Die Adresse besteht aus zwei Bestandteilen: Knoten-ID und Anwendungs-ID (siehe unten).
- Knoten-ID
Bezeichnet einen Transport Service-Knoten. Die ID kann bis zu acht Zeichen lang sein.
- Anwendungs-ID
Bezeichnet eine Transport Service-Anwendung. Die ID kann bis zu acht Zeichen lang sein. In der Regel entspricht die Anwendungs-ID dem Con-nect-Knotentyp. Siehe Externen Knoten eingeben.
- Transportobjekt
Bezeichnet die mit dem Transport Service verteilten Daten. Ein Transportobjekt kann entweder ein Datenobjekt oder Statusobjekt sein (siehe unten).
- Datenobjekt
Ein Datenobjekt enthält Folgendes:
allgemeine Informationen über das Objekt, Ursprungsknoten und Anwendung;
eine Empfängerliste, die für jeden Empfänger spezielle Korrelationsdaten enthalten kann, deren Inhalt und Verwendung von der Anwendung bestimmt wird;
allgemeine Korrelationsdaten, deren Inhalt und Verwendung von der Anwendung stimmt wird; und
Benutzerdaten.
- Statusobjekt
Ein Statusobjekt enthält dieselben Informationen wie ein Datenobjekt, jedoch mit den folgenden Ausnahmen:
die allgemeinen Informationen enthalten einen Verweis auf das Datenobjekt und einen Statuscode, aus dem hervorgeht, ob das Datenobjekt erfolgreich oder erfolglos ausgeliefert wurde;
ein Statusobjekt enthält keine Benutzerdaten; und
für ein Statusobjekt gibt es nur einen Empfänger, es enthält jedoch die Empfänger- und Korrelationsdaten für jeden Empfänger des Datenobjekts.
- Empfänger
Eine Transport Service-Adresse. Jedes Transportobjekt enthält eine Liste der Empfänger, an die das Objekt geschickt werden soll. Der Begriff "Empfänger" steht in diesem Fall für eine Transport Service-Anwendung auf einem Transport Service-Knoten.
- Rückmeldungsempfänger
Die Transport Service-Adresse, an die die Statusobjekte eines Datenobjekts geschickt werden sollen. Diese Adresse kann von der des ursprünglichen Absenders abweichen.
Die folgende Abbildung veranschaulicht den Transport Service.
Nachstehend werden die folgenden Themen behandelt:
Der Transport Service verwaltet verschiedene Typen von Warteschlangen, in denen die Transportobjekte zwischen den einzelnen Verarbeitungsphasen aufbewahrt werden.
Die Eingangswarteschlange wird bei der Initialisierung des Transport Service erstellt. Es gibt nur eine Eingangswarteschlange. Alle Transportobjekte, die von anderen Knoten empfangen oder von lokalen Transportanwendungen erstellt und versendet werden, werden in die Eingangswarteschlange gestellt. Dort verbleiben sie bis zur späteren Verarbeitung durch TS_ROUTER. Dieser leitet die Transportobjekte entweder an lokale Anwendungen oder die entsprechende Ausgangswarteschlange weiter.
Die Ausgangswarteschlangen werden vom Administrator erstellt. Die Anzahl der erforderlichen Ausgangswarteschlangen hängt von der Konfiguration des Transport Service-Netzwerks ab. Für jeden Nachbarknoten im Transport Service-Netzwerk, mit dem (oder über den) der Transport Service kommuniziert, muss mindestens eine Ausgangswarteschlange erstellt werden.
Die Transportobjekte, die mit dem Transport Service versendet oder an andere Knoten weitergeleitet werden, werden in die entsprechenden Ausgangswarteschlangen gestellt. Dort verbleiben sie bis sie durch einen Server-Prozess an den nächsten Knoten im Zielpfad weitergeleitet werden.
Für die verschiedenen Transportmethoden der Warteschlangen-Server gibt es verschiedene Warteschlangentypen:
Die Anwendungswarteschlangen werden vom Administrator erstellt. Mit ihnen werden lokale Anwendungen (z.B. Con-nect) versorgt.
Die Objekte, die an eine lokale Anwendung geschickt werden, werden in eine Anwendungswarteschlange gestellt. Dort verbleiben sie bis zur späteren Verarbeitung durch TS_ROUTER.
Eine Anwendungswarteschlange gehört zum Typ APPL.
Die Empfangswarteschlangen werden vom Administrator erstellt. Sie sind nur dann erforderlich, wenn der lokale Knoten EntireX Broker Services (LU6.2 API oder LU6.2 ACI) der Software AG benutzt oder RDA (Remote Database Access). Mit den Empfangswarteschlangen werden Dämon-Prozesse gesteuert. Ein Dämon-Prozess wartet ständig auf Transaktionsanfragen der Nachbarknoten und führt das entsprechende TS_RECEIVE-Programm aus, sobald er eine Anforderung erhält.
Für die verschiedenen Transportmethoden der Warteschlangen-Server gibt es verschiedene Warteschlangentypen:
| RE62 | Eine Warteschlange für EntireX Broker Services (LU6.2 API und LU6.2 ACI). |
| RRDA | Eine RDA-Warteschlange (Remote Database Access). |
Wenn der Transport Service initialisiert wird, werden automatisch zwei Systemwarteschlangen vom Typ SYS erstellt:
| ***CR*** | Erstellungswarteschlange. In dieser Warteschlange werden die Transportobjekte während der Erstellungsphase vorübergehend aufbewahrt. CR steht für "Creation Queue". |
| ***UD*** | Fehlerwarteschlange. In dieser Warteschlange werden nicht zustellbare oder defekte Objekte aufbewahrt, damit sie zu einem späteren Zeitpunkt von Ihnen untersucht werden können. UD steht für "Undelivery Queue". |
Für die Systemwarteschlangen gibt es keine Warteschlangen-Server, die gestartet werden müssen.
Mit den Warteschlangen-Server-Programmen werden die Transportobjekte verarbeitet und über die verschiedenen Warteschlangen an ihren Bestimmungsort weitergeleitet.
Dieses Programm verarbeitet die Transportobjekte in der Eingangswarteschlange und leitet sie anhand der Informationen in der Routing-Tabelle (z.B. lokale Konfiguration und Empfängerinformation) an die entsprechende Ausgangswarteschlange oder Anwendungswarteschlange weiter. Das Routing erfolgt folgendermaßen:
Bei einem lokalen Empfänger (d.h. wenn eine Anwendungswarteschlange für den Empfänger definiert ist) wird das Transportobjekt in die entsprechende Anwendungswarteschlange kopiert.
Wenn die Routing-Tabelle einen Eintrag für den Empfängerknoten enthält, bestimmt der Wert im "Naechste Warteschlange"-Feld des "Routing-Eintrag"-Bildschirms in welche Ausgangswarteschlange das Transportobjekt kopiert wird, damit es an seinen Bestimmungsort weitergeleitet werden kann.
Wenn der Empfänger keine der oben genannten Bedingungen erfüllt, tritt ein Routing-Fehler auf. Anhand der Rückmeldungsoptionen wird eine Statusmeldung für das Transportobjekt erstellt und an den Absender zurückgeschickt.
Da ein Transportobjekt mehr als einen Empfänger haben kann, kann es auch in mehr als eine Anwendungswarteschlange und Ausgangswarteschlange gestellt werden. In diesem Fall (auch "Fan-out" genannt) erstellt der Router soviele Kopien von dem Transportobjekt wie erforderlich und setzt im Transportobjekt ein "Responsibility-Flag" für jede Warteschlange.
Das Starten des Router-Programms ist unter Starten der Warteschlangen-Server beschrieben.
Dieses Programm verarbeitet die Transportobjekte in einer Ausgangswarteschlange und leitet sie anhand der für diese Warteschlange definierte Transportmethode an andere Transport Service-Knoten weiter. Ein Warteschlangen-Server konvertiert ein Transportobjekt in ein Standardübertragungsformat und führt anschließend den eigentlichen Transport zu einem anderen Knoten durch.
LU6.2 (CICS) für Warteschlangentyp OC62 (der TS_SEND-Server einer LU6.2-Warteschlange kann unter CICS nur als "Started Task" laufen);
LU6.2 (EntireX) für Warteschlangentyp OE62; und
RDA (Remote Database Access) für Warteschlangentyp ORDA.
Für jeden Typ von Ausgangswarteschlange gibt es ein TS_SEND-Programm. Das Starten dieser Programme ist unter Starten der Warteschlangen-Server beschrieben.
Die von anderen Knoten verschickten Transportobjekte werden von verschiedenen Server-Programmen empfangen. Welches Server-Programm benutzt wird, wird durch die verwendete Transportmethode bestimmt und entspricht dem Typ des TS_SEND-Programms. Die Programme sind verantwortlich für den Empfang der Transportobjekte, die Konvertierung aus dem Übertragungsformat in ein internes Format, sowie das Stellen in die Eingangswarteschlange für die weitere Verarbeitung durch TS_ROUTER.
Je nachdem welche Übertragungsmethode vom externen TS_SEND-Programm benutzt wurde, wird eins der folgenden TS_RECEIVE-Programme benutzt:
- TS_RECEIVE LU6.2 (CICS)
Empfängt Transportobjekte von TS_SEND LU6.2-Programmen (CICS oder EntireX Broker Services (LU6.2 API oder LU6.2 ACI)). Hierbei läuft TS_RECEIVE als "Started Task" unter CICS.
- TS_RECEIVE LU6.2 (EntireX Broker Services (LU6.2 API))
Empfängt Transportobjekte von TS_SEND LU6.2-Programmen (CICS oder EntireX Broker Services (LU6.2 API)).
- TS_RECEIVE LU6.2 (EntireX Broker Services (LU6.2 ACI))
Empfängt Transportobjekte von TS_SEND LU6.2-Programmen (CICS oder EntireX Broker Services (LU6.2 ACI)).
- TS_RECEIVE RDA
Empfängt Transportobjekte von TS_SEND RDA-Programmen (d.h. die Transportobjekte werden lokal aus einer Zwischenwarteschlange in eine Eingangswarteschlange kopiert und reformatiert).
Die Anwendungen, die den Transport Service benutzen, agieren sowohl als Absender als auch als Empfänger:
- Absender
Erstellen Transportobjekte und übergeben sie dem Transport Service zur Auslieferung. Die Transportobjekte werden in die Eingangswarteschlange gestellt und von TS_ROUTER verarbeitet.
- Empfänger
Empfangen Transportobjekte, die vom Transport Service einer anderen Anwendung zugestellt werden. Die Transportobjekte werden von TS_ROUTER in die entsprechende Anwendungswarteschlange gestellt.
Die Warteschlangen-Server können folgendermaßen gestartet werden:
- Ereignisgesteuert
Der Server wird gestartet, sobald ein Transportobjekt in der Warteschlange ankommt.
- Intervallgesteuert
Der Server wird in den von Ihnen festgelegten Intervallen gestartet.
Die Warteschlangen-Server werden über den Status einer Warteschlange gesteuert: gesperrt, inaktiv, ereignisgesteuert und intervallgesteuert. Als Administrator sind Sie dafür verantwortlich, dass der richtige Mechanismus für die Warteschlangen-Server definiert und aktiviert wird. Welcher Mechanismus jeweils anzuwenden ist, hängt vom Ausgabestatus oder Reset-Status der jeweiligen Warteschlange ab.
Der Ausgabestatus bezieht sich auf den aktuellen Verarbeitungsstatus der Warteschlange. Der Reset-Status dagegen zeigt den Startmechanismus, der bei einer Warteschlange angewendet wird.
Der Zeitpunkt, an dem eine Warteschlange zuletzt gestartet und gestoppt wurde, wird gespeichert. Diese Zeitstempel werden im "Warteschlangen verwalten"-Bildschirm angezeigt. Siehe Warteschlangen verwalten.
Im Gegensatz zu anderen Warteschlangentypen sind die Empfangswarteschlangen intervallgesteuert. Ihr Status (inaktiv, ereignisgesteuert oder intervallgesteuert) ist hierbei nicht von Bedeutung. Die Verzögerung für die erneute Ausführung ist auf eine Minute festgelegt.
Die hier beschriebenen Startmechanismen und deren Steuerung durch die Administrationsfunktionen, stehen nur dann zur Verfügung wenn die Warteschlangen-Server in einer Umgebung wie Com-plete (die Server laufen als "Attached Tasks") oder CICS (die Server laufen als "Started Tasks") ausgeführt werden.
Wenn die Warteschlangen-Server im Batch-Modus ausgeführt werden, muss eine vereinfachte Methode angewandt werden, wobei von einem allgemeinen Server mindestens zwei Natural-Sessions benutzt werden, um die Warteschlangen regelmäßig und periodisch zu überwachen.
Bei Com-plete oder CICS kann ein Task-Reinitialisierungsprogramm (Watchdog) benutzt werden, um zu gewährleisteten, dass das regelmäßige Starten nicht durch temporäre Systemausfälle unterbrochen wird.
Zur Überwachung des Systems sollte der Administrator den Status der Warteschlangen sowie die Anzahl der Einträge in den Warteschlangen und deren Zeitstempel gelegentlich überprüfen.
Mit dem Transport Service wird elektronische Post zwischen verschiedenen Postsystemen ausgetauscht. In der Regel sind dies Con-nect selbst und die Gateways zu den Drittanbietersystemen. Der Transport Service gestattet einem einzelnen Gateway, von mehr als einem Con-nect-System benutzt zu werden, wobei sich das Gateway auf derselben Plattform wie Con-nect befinden kann oder auf einer anderen.
Wenn der Transport Service zur Unterstützung elektronischer Postsysteme benutzt wird, wird ein zweischichtiges Adressierschema benutzt. Die erste (oder äußere) Schicht der Adressinformation wird vom Transport Service beim Übertragen der Post (einschließlich Rückmeldungen) zwischen den verschiedenen Postsystemen ausgewertet. Die zweite (oder innere) Schicht wird von den externen Postsystemen ausgewertet, die den Transport Service benutzen.
Die zweite Schicht kann zum Beispiel einen Con-nect-Knoten mit Bürokennzeichen enthalten. Auch wenn der Transport Service keine Einschränkungen in Bezug auf die Adresse in der zweiten Schicht oder die Struktur der Empfänger geltend macht, unterstützt er die Verknüpfung der beiden Schichten, so dass die Statusinformation sowohl vom Transport Service als auch den externen Postsystemen ausgewertet werden kann.
Beim Transport Service sind Benennung und Adressierung auf die Basisbestandteile reduziert: auf Knoten und auf Anwendungen auf den Knoten. Die IDs für Knoten und Anwendungen haben das Format einer druckbaren Zeichenkette, die bis zu acht Zeichen lang sein kann. Wenn der Transport Service von den Con-nect-Gateways als "Electronic Mail Backbone" benutzt wird, muss die Anwendungs-ID genau ein Zeichen lang sein.
Es ist wichtig zu verstehen, dass die Transport Service-Adressen (d.h. Knoten-ID und Anwendungs-ID) unabhängig von den Namen sind, die von den darunter liegenden Netzwerk-Services (z.B. SNA-LU-Namen und OSI-SSAP-Adressen) und den bedienten elektronischen Postsystemen (z.B. Con-nect-Benutzernamen) benutzt werden.
Das Routing der Dateneinheiten, der so genannten Transportobjekte, geschieht anhand der Knotennamen, die den Ort angeben, an dem der entsprechende Service angeboten wird.
Beim Transport Service bestimmt die Anwendungs-ID den Knotentyp. Beispiel: A steht für einen externen Con-nect-Knoten.