Dieses Dokument behandelt die folgenden Themen:
Ein Natural Subprogram Server ist eine Mehrbenutzer- und Multitasking-Anwendung. Er kann Natural-Sitzungen für mehrere Benutzer hosten und deren Anfragen parallel ausführen.
Das Konzept basiert auf dem "serverisierten" Natural-Laufzeitsystem. Seine
Architektur umfasst einen Server-Frontend-Stub (Subprogram Server Stub
NATRNPI), der das Natural-Frontend nutzt, um Natural-Sitzungen zuzuweisen
und Subprogramme innerhalb dieser Sitzungen auszuführen.
Die Architektur besteht im Wesentlichen aus:
Der Stub NATRNPI wird gestartet, um einen Natural Subprogram Server zu
initialisieren. Er überwacht eingehende Anfragen und initialisiert eine
Natural-Sitzung zur Ausführung des Subprogramms.
Das Frontend wird (zusammen mit dem Natural-Laufzeitsystem) vom Frontend-Stub zur Initialisierung bzw. Beendigung der Sitzung sowie zur Ausführung von Anfragen aufgerufen.
Das Modul NATGWNPI sorgt für die Interaktion zwischen dem
Natural-Laufzeitsystem und dem Frontend-Stub. NATGWNPI ist bereits im
Natural-Nukleus enthalten und wird vom Natural-Laufzeitsystem aufgerufen, um die
erforderlichen Anfragedaten auszutauschen.
Natural-Treiber
Natural wird vom Natural-Treiber NATOS bzw. NATOSL
gesteuert.
AnmerkungNATOSL ist eine Erweiterung von NATOS, die IBMs
Language Environment (LE) unterstützt. LE ermöglicht die Verwendung verschiedener
Programmiersprachen innerhalb einer einzigen Anwendung. Da der Server in C
implementiert ist und LE benötigt, muss das Natural-Frontend stets sowohl NATOS als
auch NATOSL enthalten.
Über einen Monitor-Task kann der Administrator die Serveraktivitäten überwachen und den gesamten Server herunterfahren usw.
NATRNPI ist ein Multi-User- und Multitasking-Frontend-Stub, der zur
Initialisierung eines Natural-Subprogram Servers gestartet wird.
Dieses Dokument behandelt die folgenden Themen:
Die Task, die die Serverinitialisierung durchführt, TMain, ist der
Haupt-Listener, der auf eingehende Anfragen vom Natural OpenAPI Server wartet. Sie
verwaltet ein Sitzungsverzeichnis, um mehrere Clients (Benutzer) und die dazugehörigen
Remote-Natural-Sitzungen zu verwalten. TMain hat die Aufgabe, alle
eingehenden Anfragen anzunehmen und an andere Subtasks (TWork)
weiterzuleiten. Der Ablauf ist wie folgt:
Zunächst verbindet sich der Natural OpenAPI Server mit TMain, um
eine Verbindung herzustellen.
Anschließend fügt TMain den Client in sein Sitzungsverzeichnis ein,
fügt eine neue TWork-Subtask hinzu und übergibt die Verbindung an
TWork.
TWork initialisiert eine neue Natural-Sitzung, verarbeitet die
Anfrage, sendet das Ergebnis an den Client zurück, beendet die Natural-Sitzung und
beendet sich selbst.
Jede Anfrage ist zustandslos. Für jede Anfrage wird eine separate Natural-Sitzung gestartet. Die Initialisierung der Sitzung wird jedoch beschleunigt, indem neue Sitzungen aus einer Master-Sitzung geklont werden. Bei der Serverinitialisierung wird eine Master-Sitzung initialisiert und in einem benutzerunabhängigen Zustand gehalten. Für eine neue Sitzung wird die Master-Sitzung einfach kopiert und mit der Benutzerkennung der Anfrage verknüpft.
Es ist aufwendig, für jede Anfrage eine neue Worker-Task zu erstellen. Es ist möglich,
erstellte Worker in einem Pool vorzuhalten, um sie für nachfolgende Anfragen
wiederzuverwenden. Wenn die Konfigurationsvariable
WORKER_DELAY auf einen Wert größer als Null gesetzt ist,
wartet ein Worker nach der Ausführung einer Anfrage für die festgelegte Zeit in
Sekunden. Der Worker-Pool passt seine Größe automatisch an die Auslastung des Servers
an. Bei vielen parallelen Anfragen vergrößert sich der Pool, um die erhöhte Last zu
bewältigen. Wenn die Auslastung sinkt, verkleinert sich der Pool entsprechend.
Innerhalb einer Natural OpenAPI Server-Sitzung werden die folgenden Natural-Systemvariablen verwendet:
*TPSYS enthält den Wert SERVSTUB.
*DEVICE enthält den Wert BATCH.
*SERVER-TYPE enthält den Wert CALLNAT.
Das aufgerufene Subprogramm darf keine Bildschirm-Ein-/Ausgaben durchführen. Falls dennoch eine Bildschirm-Ein-/Ausgabeverarbeitung stattfindet, schreibt der Server den Bildschirminhalt in seine Trace-Datei und bricht die Bildschirm-Ein-/Ausgabeverarbeitung ab.
Das für einen Natural-NPI-Server erforderliche Natural-Frontend ist ein Natural-Batch-Frontend-Treiber, der Language Envonment-fähig sein sollte. Weitere Informationen finden Sie in den Beispiel-Installationsjobs.
Das Gateway-Modul NATGWNPI ist bereits im Natural-Nukleus enthalten.
Damit der Administrator den Status des Natural NPI Servers überwachen kann, steht eine Monitor-Task zur Verfügung, die beim Serverstart automatisch initialisiert wird. Mithilfe der Monitor-Kommandos kann der Administrator die Serveraktivitäten steuern, den Server vollständig beenden usw. Weitere Informationen finden Sie unter Natural API Server > Natural Subprogram Server auf z/OS > Betrieb > Überwachung des Natural API-Servers > Monitor-Kommunikation.
Die folgende Grafik veranschaulicht die Interaktion zwischen dem Natural OpenAPI Server und einem Natural NPI Server.
Der Natural OpenAPI Server (der Client) empfängt einen REST-Aufruf. Er wandelt diesen in ein proprietäres Protokoll um und sendet ihn über die beim Natural OpenAPI Server angegebene Portnummer an den Natural OpenAPI Server.
Der Natural Subprogram Server initialisiert (klont) eine Natural-Sitzung unter
Verwendung des Natural-Frontend, das Sie mit dem Konfigurationsparameter FRONTEND_NAME des Natural NPI
Servers angegeben haben. In diesem Beispiel ist dies NATOS.
