Dieses Kapitel behandelt die folgenden Themen:
Der Natural Remote Procedure Call (RPC) ermöglicht es einem
Natural-Client-Programm ein CALLNAT-Statement abzusetzen,
um ein Subprogramm in einem Natural-Server aufzurufen. Die Natural-Client- und
Server-Sitzungen können auf demselben oder auf einem anderen Computer laufen.
So kann beispielsweise ein Natural-Client-Programm auf einem Windows-Computer
ein CALLNAT-Statement an einen Großrechner-Server senden, um Daten
aus einer Großrechner-Datenbank abzurufen. Derselbe Windows-Computer kann als
Server fungieren, wenn ein Natural-Client-Programm, das z. B. unter UNIX läuft,
ein CALLNAT-Statement absetzt, um Daten von diesem Natural-Server
anzufordern.
Beim Natural RPC werden die Vorteile des Client-Server-Computing genutzt. In einem typischen Szenario greift Natural auf einem Windows-Client-Computer über eine Middleware-Schicht auf Serverdaten von einem Natural auf einem Großrechner zu. Daraus ergeben sich folgende Vorteile:
Der Endbenutzer auf der Client-Seite kann eine Natural-Anwendung mit einer grafischen Benutzeroberfläche nutzen.
Der Zugriff auf eine große Datenbank kann auf einem Großrechner-Server erfolgen.
Der Netzwerkverkehr kann minimiert werden, wenn nur relevante Daten vom Client zum Server und zurückgesendet werden.
Der Natural RPC bietet folgende Betriebsarten:
Nicht-konversationeller Modus (in den folgenden Texten ist, wenn nicht anders angegeben, dieser Modus gemeint)
Diese Betriebsarten werden in den folgenden Abschnitten beschrieben. Eine Gegenüberstellung der Vor- und Nachteile dieser Betriebsarten finden Sie unter Konversationeller versus nicht-konversationeller Modus.
Sie können den Natural RPC auf verschiedenen Plattformen unter den folgenden Betriebssystemen verwenden:
z/OS
z/VSE
BS2000
Natural RPC auf Großrechnern wird unter den folgenden TP-Monitoren unterstützt:
Com-plete
CICS
IMS TM
TSO
TIAM
openUTM
Natural RPC ist auch im Batch-Modus verfügbar.
Windows
UNIX
OpenVMS
Auf all diesen Plattformen kann Natural sowohl als Client-Natural als auch als Server-Natural fungieren.
Nicht-Natural-Umgebungen (3GL und andere Programmiersprachen) werden sowohl auf der Client- als auch auf der Server-Seite unterstützt. So kann ein Nicht-Natural-Client mit einem Natural RPC Server und ein Natural-Client mit einem Nicht-Natural-RPC-Server kommunizieren. Ermöglicht wird dies durch die Verwendung des EntireX RPC.
Der nicht-konversationelle Modus sollte nur verwendet werden, um einen einzelnen Datenaustausch mit einem Partner durchzuführen. Siehe auch Konversationeller versus nicht-konversationeller Modus.
Die Natural RPC-Technik verwendet das Natural-Statement
CALLNAT, so dass
sowohl lokale als auch entfernte Subprogramm-Aufrufe parallel abgesetzt werden
können. Entfernte Programmaufrufe arbeiten synchron. Als entfernter
Prozeduraufruf würde ein CALLNAT, einfach ausgedrückt, den
folgenden Weg nehmen:
Das vom Natural-Client abgesetzte CALLNAT wird über
eine Middleware-Schicht an den Natural-Server geleitet, der die Daten an den
Client zurückgibt.
In der Regel besteht die Middleware-Schicht aus dem Software AG-Produkt EntireX Broker, das das ACI-Protokoll verwendet. EntireX Broker verwendet entweder Entire Net-Work oder TCP/IP als Kommunikationsschicht.
Ein detailliertes Beispiel für den RPC-Kontrollfluss wird im Folgenden beschrieben.
Einzelheiten des CALLNAT-Kontrollflusses in
einer Remote-Prozedur werden im Folgenden dargestellt. Aus Gründen der
Übersichtlichkeit ist der Rückweg nicht dargestellt, aber er verläuft analog;
die Zahlen beziehen sich auf die Beschreibung:
Vom Natural-Client aus sendet das Programm PGM1
einen CALLNAT an das
Subprogramm SUB1. PGM1 weiß nicht, ob das Ergebnis
seines CALLNAT ein lokales oder ein entferntes
CALLNAT sein wird.
Da sich das Ziel SUB1 auf einem Server befindet,
greift das CALLNAT stattdessen auf ein Interface-Objekt
SUB1 zu. Dieses Client-Interface-Objekt wurde automatisch oder
manuell (mit der Funktion
Interface
Object Generation (IG) der SYSRPC-Utility)
erstellt.
Das Interface-Objekt hat den gleichen Namen wie das
Ziel-Subprogramm und enthält Parameter, die mit den im Programm
PGM1 und auf dem Server im Ziel-Subprogramm SUB1
verwendeten Parametern identisch sind. Außerdem enthält es Steuerinformationen,
die intern vom RPC verwendet werden.
Wenn der Schlüsselwort-Subparameter
AUTORPC
des Natural-Profilparameters RPC oder des
Parametermakros NTRPC auf ON gesetzt ist
und Natural das Subprogramm in der lokalen Umgebung nicht finden kann,
interpretiert Natural dies als Remote Procedure Call und generiert den
Parameterdatenbereich
(PDA) dynamisch zur Laufzeit.
Außerdem versucht Natural, dieses Subprogramm im
Service
Directory NATCLTGS zu finden.
Weitere Informationen zur
Interface-Objekt-Generierungsfunktion der
SYSRPC-Utility
siehe Interface-Objekte
erstellen.
Wenn Sie ohne Interface-Objekte arbeiten wollen, lesen Sie bitte den Abschnitt Mit automatischer Natural RPC-Ausführung arbeiten.
Das Interface-Objekt richtet dann ein CALLNAT zu
einer RPC-Client-Service-Routine ein.
Die Client-RPC-Laufzeit überprüft im Service Directory
NATCLTGS, auf welchem Knoten und Server das CALLNAT
ausgeführt werden soll und ob eine Anmeldung erforderlich ist.
Die CALLNAT-Daten einschließlich der
Parameterliste und, falls erforderlich, der Anmeldedaten werden an eine
Middleware-Schicht übergeben.
In diesem Beispiel besteht die Middleware-Schicht aus dem
Software AG-Produkt EntireX Broker. Daher werden die CALLNAT-Daten
zunächst an einen EntireX Broker Stub auf dem Client übergeben.
Vom EntireX Broker Stub aus werden die
CALLNAT-Daten an den EntireX Broker weitergeleitet. Der EntireX
Broker ist ein Produkt, das an folgenden Stellen installiert sein kann:
auf dem Client-Computer,
auf dem Server-Computer oder
auf einer dritten Plattform.
Damit die Daten erfolgreich weitergeleitet werden können, muss
der Server SRV1 in der EntireX Broker-Attributdatei definiert sein
und SRV1 muss bereits aktiv sein, sich also beim EntireX Broker
registriert haben.
Informationen zur Definition von Servern in der EntireX Broker-Attributdatei finden Sie in der EntireX Broker-Dokumentation.
Von der Middleware-Schicht werden die
CALLNAT-Daten an den EntireX Broker-Stub auf der Natural
Server-Plattform und von dort an die RPC-Server-Service-Routine
weitergeleitet.
Die RPC-Server-Service-Routine validiert die Anmeldedaten (falls vorhanden) und führt eine Anmeldung durch (falls angefordert).
Die RPC-Server-Service-Routine ruft das Ziel-Subprogramm
SUB1 auf und übergibt die Daten, falls angefordert.
Zu diesem Zeitpunkt verfügt das Ziel-Subprogramm
SUB1 über alle erforderlichen Daten zur Ausführung, als ob es von
einem lokalen Programm PGM1 aufgerufen worden wäre.
Dann kann das Subprogramm SUB1 z.B. ein
FIND-Statement an die Adabas-Datenbank des Servers senden.
SUB1 weiß nicht, ob es von einem lokalen oder von einem entfernten
CALLNAT gestartet wurde.
Adabas findet die Daten und übergibt sie an
SUB1.
Anschließend gibt SUB1 die Adabas-Daten an die
aufrufende Server-Service-Routine zurück. Von dort werden sie über die
Middleware-Schicht an PGM1 zurückgegeben. Dies geschieht auf
demselben Weg wie in den Schritten 1 bis 8 beschrieben, jedoch in umgekehrter
Reihenfolge.
Ein konversationeller RPC ist eine statische Verbindung von
begrenzter Dauer zwischen einem Client und einem Server. Sie bietet eine Reihe
von Diensten (Subprogrammen), die vom Client definiert werden und die alle
innerhalb einer Server-Task ausgeführt werden, die für die Dauer der
Konversation ausschließlich dem Client zur Verfügung steht. Sie wird in einem
Programm mit einem OPEN
CONVERSATION-Statement und einem
CLOSE
CONVERSATION-Statement implementiert.
Es können mehrere Verbindungen (Konversationen) gleichzeitig bestehen. Sie werden vom Client mit Hilfe von Konversationskennungen (Conversation-IDs) verwaltet, und jede von ihnen wird auf einem anderen Server ausgeführt. Remote Prozeduraufrufe, die nicht zu einer gegebenen Konversation gehören, werden innerhalb einer anderen Server-Task auf einem anderen Server ausgeführt.
Während einer Konversation können die entfernten Subprogramme auf der Serverseite einen Datenbereich, den sogenannten Kontext-Bereich, definieren und gemeinsam nutzen. Weitere Informationen finden Sie unter Definition von Kontext-Variablen für den Natural RPC in der Natural Statements-Dokumentation.
Definieren von Kontextvariablen für Natural RPC in der Dokumentation Natural Statements.
Eine Conversation kann lokal oder remote sein.
OPEN CONVERSATION USING SUBPROGRAM 'S1''S2'
CALLNAT 'S1' PARMS1
CALLNAT 'S2' PARMS2
CLOSE CONVERSATION ALL
Beide Subprogramme (S1 und S2) müssen an der gleichen Stelle aufgerufen werden, d.h. entweder lokal oder fern (remote). Es ist nicht zulässig, lokale und ferne CALLNATs innerhalb einer Konversation zu vermischen. Wenn die Subprogramme fern ausgeführt werden, werden beide Subprogramme von derselben Server-Task ausgeführt.
So wie bei nicht-konversationellen RPC-CALLNATs können
Konversationen zunächst lokal geschrieben und getestet und dann an die Server
übertragen werden.
Wenn Sie Subprogramme lokal ausführen, gilt die folgende Regel:
Ein Subprogramm darf kein anderes Subprogramm aufrufen, das Teilnehmer der Konversation ist.
Andere Subprogramme, die nicht in dem
OPEN
CONVERSATION-Statement aufgeführt sind, können aufgerufen
werden. Sie werden jedoch im
nicht-konversationellen
Modus ausgeführt.
Wenn Sie Subprogramme remote ausführen, gilt die folgende Regel:
A subprogram S1 may call another subprogram
S2 which is a member of the conversation.
Ein Subprogramm S1 darf ein anderes Subprogramm
S2 aufrufen, das Teilnehmer der Konversation ist.
Dieses CALLNAT wird im nicht-konversationellen
Modus ausgeführt, da es indirekt aufgerufen wurde. Das Subprogramm
S2 hat also keinen Zugriff auf den Kontextbereich.
In einer Client-Server-Umgebung, in der mehrere Clients im
nicht-konversationellen Modus auf mehrere Server zugreifen, kann es zu dem
Problem kommen, dass identische CALLNAT-Anforderungen von
verschiedenen Clients auf demselben Server ausgeführt werden.
Das bedeutet z.B., dass ein CALLNAT 'S1' von Client 1
das Subprogramm S1 auf Server 1 ausführt (S1 schreibt
einen Datensatz in die Datenbank). Die Transaktion für Client 1 ist noch nicht
abgeschlossen (kein END
TRANSACTION), wenn Client 2 ebenfalls einen CALLNAT 'S1' an
Server 1 sendet und damit die Daten von Client 1 überschreibt. Sendet Client 1
daraufhin ein CALLNAT 'S2' (d.h. END TRANSACTION),
geht Client 1 davon aus, dass seine Daten korrekt gespeichert wurden, obwohl in
Wirklichkeit die Daten des identischen CALLNAT von Client 2
gespeichert wurden.
Das folgende Diagramm veranschaulicht dies mit zwei Clients und zwei
Servern. In einem solchen Szenario können Sie nicht kontrollieren, ob zwei
identische CALLNATs von zwei verschiedenen Clients auf dasselbe
Subprogramm auf demselben Server zugreifen:
Im obigen Beispiel kann CALLNAT 'S2' von Client 1 auf
das Subprogramm S2 auf Server 1 und auf Server 2 zugreifen.
CALLNAT 'S2' von Client 2 hat die gleiche Wahl.
Ähnlich könnte CALLNAT 'S1' von Client 1 auf das
Subprogramm S1 auf Server 1 und auf Server 2 zugreifen, während
CALLNAT 'S1' von Client 2 die gleiche Wahl hat.
Es ist offensichtlich, dass es hier zu Überschneidungen kommen kann, wenn die Subprogramme so konzipiert sind, dass sie innerhalb eines Server-Task-Kontextes ausgeführt werden.
Sie können die potenziellen Probleme eines nicht-konversationellen RPC vermeiden, indem Sie eine komplexere RPC-Transaktion im konversationellen Modus definieren:
Dazu eröffnen Sie eine Konversation. Dazu wird auf der Client-Seite
das OPEN
CONVERSATION-Statement verwendet, das sich auf CALLNAT
'S1' und CALLNAT 'S2' bezieht. Durch das Eröffnen einer
solchen Konversation wird eine ganze Server-Task (z. B. Server 1) reserviert,
und keine anderen entfernten CALLNATs dürfen diese Konversation
auf diesem Server unterbrechen, bevor diese Konversation geschlossen wurde.
Zusätzlich können Sie mit dem DEFINE DATA
CONTEXT-Statement einen gemeinsamen Kontextbereich für die
beiden Subprogramme auf der Server-Seite definieren.
Als allgemeine Regel gilt Folgendes:
Verwenden Sie konversationellen RPC, um sicherzustellen, dass eine definierte Liste von Subprogrammen ausschließlich in einem Kontext ausgeführt wird.
Verwenden Sie nicht-konversationellen RPC, wenn jedes Ihrer Subprogramme innerhalb einer anderen Server-Task verwendet werden kann oder wenn sich die Transaktion nicht über mehr als einen Server-Aufruf erstreckt. Dies hat den Vorteil, dass kein Server über einen längeren Zeitraum blockiert und Sie nur eine relativ geringe Anzahl von Server-Tasks benötigen.
Ein möglicher Nachteil von konversationellen RPCs ist, dass Sie
eine ganze Server-Task reservieren und damit alle anderen Subprogramme auf
diesem Server blockieren. Dies kann dazu führen, dass andere
CALLNATs warten müssen oder weitere Server-Tasks gestartet werden
müssen.
Die Datenbank-Transaktionen auf der Client- und der Server-Seite
laufen unabhängig voneinander. Das heißt, ein
END TRANSACTION oder
BACKOUT TRANSACTION,
das auf der Server-Seite ausgeführt wird, hat keinen Einfluss auf die
Datenbank-Transaktion auf der Client-Seite und umgekehrt.
Am Ende jedes nicht-konversationellen CALLNAT und am
Ende jeder Konversation wird auf der Server-Seite ein implizites BACKOUT
TRANSACTION ausgeführt. Um die von dem/den entfernten
CALLNAT(s) vorgenommenen Änderungen zu übernehmen, haben Sie
folgende Möglichkeiten:
Nicht-konversationelles CALLNAT
Führen Sie ein explizites END TRANSACTION aus, bevor Sie
den CALLNAT verlassen.
Setzen Sie den Natural-Profilparameter
ETEOP auf
ON. Dies führt zu einem impliziten END TRANSACTION am
Ende eines jeden nicht-konversationellen CALLNATs.
Je nach Einstellung des Subparameters
SRVCMIT
wird das END TRANSACTION entweder vor dem Senden der Antwort an
den Client (SRVCMIT=B) oder nach dem erfolgreichen Senden der
Antwort an den Client (SRVCMIT=A) ausgeführt.
SRVCMIT=B ist die Standardeinstellung und ist mit früheren
Versionen des RPC kompatibel.
Konversationelles CALLNAT
Führen Sie ein explizites END TRANSACTION aus, bevor die
Konversation durch den Client beendet wird.
Setzen Sie den Natural-Profilparameter
ETEOP auf
ON. Dies führt zu einem impliziten END TRANSACTION am
Ende jeder Konversation.
Je nach Einstellung des Subparameters
SRVCMIT
wird das END TRANSACTION entweder vor dem Senden der Antwort an
den Client (SRVCMIT=B) oder nach dem erfolgreichen Senden der
Antwort an den Client (SRVCMIT=A) ausgeführt.
SRVCMIT=B ist die Standardeinstellung und ist mit früheren
Versionen des RPC kompatibel.
Bevor Sie das CLOSE CONVERSATION-Statement
ausführen, rufen Sie die Anwendungsprogrammierschnittstelle
USR2032N auf
der Client-Seite auf. Dadurch wird am Ende der einzelnen Konversation ein
implizites END TRANSACTION ausgelöst.
The following Natural limits apply to each individual remote
CALLNAT execution on the Natural RPC Server:
Die folgenden Natural-Limits gelten für jede einzelne Remote-CALLNAT-Ausführung auf dem Natural RPC Server:
| Natural-Profilparameter | Art des Limits |
|---|---|
LT |
Limit für Verarbeitungsschleifen |
MADIO |
Maximale Anzahl der DBMS-Aufrufe zwischen Bildschirm-Ein-/Ausgaben |
MAXCL |
Maximale Anzahl an Programmaufrufen |
MT |
Maximale CPU-Zeit |
Diese Limits werden nach jeder
Remote-CALLNAT-Ausführung zurückgesetzt, und Sie können bestimmte
Limits für jede Remote-CALLNAT-Ausführung erzwingen.
Diese Maßnahme trägt dazu bei, unvorhersehbare Fehlersituationen zu vermeiden, wenn die Ausführung einer Client-Anforderung aufgrund der Verarbeitung einer früheren Client-Anforderung eines der Limits erreicht
Die beiden Subprogramme S1 und S2 (in der obigen Abbildung
dargestellt) müssen am selben Ort aufgerufen werden, d.h. entweder lokal oder
entfernt (remote). Lokale und entfernte CALLNATs dürfen innerhalb
einer Konversation nicht vertauscht werden. Wenn die Subprogramme entfernt
ausgeführt werden, werden beide Subprogramme von der gleichen Server-Task
ausgeführt.
Die folgende Tabelle enthält wichtige Schlüsselbegriffe, die in der
SYSRPC Utility und in der Natural RPC-Dokumentation verwendet
werden:
| Begriff | Erklärung |
| Client-Stub | Veralteter Begriff, siehe Client-Interface-Objekt. |
| EntireX Broker Stub | Schnittstelle zwischen der Natural RPC-Laufzeit und der EntireX Broker-Transportschicht, die umgewandelten ("marshalled") Daten zwischen Client und Server austauscht. |
| Client-Interface-Objekt | Nimmt die CALLNAT-Anforderungen auf der
Client-Seite entgegen, wandelt das Format der übergebenen Parameter um
("marshalling"),
überträgt die Daten durch die Natural RPC-Laufzeit und die Transportschicht zum
Remote-Server, wandelt das Ergebnis zurück ("unmarshalling") und gibt es an
den Aufrufer zurück.
Der Interface-Objekt-Stub ist das lokale Subprogramm, über das das Server-Subprogramm aufgerufen wird. Das Client-Interface-Objekt hat den gleichen Namen und enthält die gleichen Parameter wie das entsprechende Server-Subprogramm. |
| Impersonation | Impersonation setzt voraus, dass der Zugriff auf das Betriebssystem, auf dem ein Natural RPC Server läuft, durch ein SAF-konformes externes Security-System kontrolliert wird. Die Benutzerauthentifizierung wird von diesem externen Security-System durchgeführt. Impersonation bedeutet, dass nach erfolgreicher Authentifizierung und Feststellung der Identität des Benutzers alle nachfolgenden Berechtigungsprüfungen auf der Grundlage dieser Identität durchgeführt werden. Dazu gehören auch Berechtigungsprüfungen für den Zugriff auf externe Ressourcen (z. B. Datenbanken oder Arbeitsdateien). Nach erfolgreicher Authentifizierung kann der Benutzer "seine Identität nicht ändern", d. h. er kann keine andere Benutzerkennung verwenden. Siehe Impersonation in Verwendung von Security. |
| Interface-Objekt | In früheren Versionen von EntireX wurde der Begriff "Stub" auch für anwendungsabhängige, von der Workbench generierte Codestücke zum Absetzen und Empfangen von Remote Procedure Calls verwendet. Diese Objekte werden jetzt als "Interface-Objekte" bezeichnet. |
| Knotenname | Der Name des Knotens, an den der
Remote-CALLNAT gesendet wird.
Bei der Kommunikation über den EntireX Broker ist der
Knotenname beispielsweise der Name des EntireX Brokers, wie er in der EntireX
Broker-Attributdatei im Feld |
| Marshalling | Beim Marshalling werden Schnittstellendaten in RPC-Pakete verpackt, die über Prozess- und Netzwerkgrenzen hinweg übertragen werden. Dazu gehört die Konvertierung von Daten von ihrem eigentlichen Datentyp in eine interne Darstellung. Die Umwandlung aus einer internen Darstellung in ihren eigentlichen Datentyp wird als Unmarshalling bezeichnet. |
NATCLTGS |
Der Name des Natural-Subprogramms, das mit der SYSRPC Utility generiert wurde, um das Diensteverzeichnis (Service Directory) zu implementieren (siehe unten). |
| RPC-Parameter | Alle Parameter, die zur Steuerung eines Natural RPC zur
Verfügung stehen, sind in der Natural
Parameter-Referenz-Dokumentation ausführlich beschrieben.
Siehe Abschnitt Profilparameter.
Die RPC-Parameter sind im Parameter-Makro
Siehe RPC - Remote Procedure Call-Einstellungen und NTRPC-Macro-Syntax (in der Natural Parameter-Referenz-Dokumentation). |
| RPC-Server | Ein RPC-Server ist entweder ein Natural-Server oder ein EntireX RPC-Server. |
| Service Directory | Das Diensteverzeichnis (Service Directory) enthält
Informationen über die Services, d.h. Dienste (Subprogramme), die ein Server
anbietet. Es kann lokal auf jedem Client-Knoten verfügbar sein oder sich auf
einem Remote Directory Server befinden, auf den unter Windows, UNIX und OpenVMS
durch den Profilparameter RDS und auf Großrechnern durch den entsprechenden
Schlüsselwort-Unterparameter RDS
des Profilparameters RPC oder des
Parameter-Makros
NTRPC
verwiesen wird.
|
| Servername | Der Name des Servers, auf dem der CALLNAT
ausgeführt werden soll.
Bei der Kommunikation über EntireX Broker ist der
Servername der Name, der in der EntireX Broker-Attributdatei im Feld
|
| Server-Task | Eine Natural-Task, die Services, d.h. Dienste (Subprogramme), anbietet. Dies ist typischerweise eine Batch-Task oder eine asynchrone Task. Sie wird durch einen Servernamen identifiziert. |