Java-Anwendungen im VM Container 

Konzept

Der VMC-Applikationsserver hat die Aufgabe, vom Client Anfragen (Requests) entgegenzunehmen und Antworten (Responses) zurückzuschicken. Ein Request wird durch eine Bearbeitungsroutine (Handler) bearbeitet, der Teil einer Anwendung (Applikation) ist.

Eine Komponente ist eine gespeicherte Java-Anwendung (in der Datenbank oder im Dateisystem) mit den benötigten Bibliotheken. Die Komponente besteht also aus Java-Klassen und Dateien, die in Modulen zusammengefasst werden.

Ein Modul ist eine für sich deploybare Einheit. Als Menge von Dateien entspricht es einem Java-Archive (.jar-Datei) oder einem Verzeichnis.

Eine Aktivierung ist eine laufende Komponente mit einer Lebenszeit (begrenzt durch das Deployment einer neuen Version der Applikation), die Ressourcen (z.B. Cache) verwendet. Nach Ablauf der Lebenszeit werden die Ressourcen wieder freigegeben. Eine Aktivierung kann von allen VMs einer Instanz genutzt werden. Jeder Request wird jedoch von einem Handler in einer VM bearbeitet und ist damit ein VM-lokales Objekt.

Das Deployment einer Komponente in die Datenbank kann asynchron von einem beliebigen Applikationsserver durchgeführt werden. Wird die selbe Komponente erneut deployt, wird sie in der Datenbank als neue Version mit neuem Zeitstempel gespeichert. Die alte Version bleibt so lange erhalten, wie sie von noch genutzten Aktivierungen benötigt wird.

Die Anwendungsverwaltung im VM Container erfüllt folgende Anforderungen:

·        Das Deployment von Anwendungen in die Datenbank ist asynchron und nicht destruktiv.

·        Die Applikationsserver können Anwendungen sowohl laden als auch löschen. Sie erkennen neu deployte Anwendungen und können sich auf dem neuesten Stand der Datenbank halten.

·        Zwischen aktivierten Anwendungen ist durch getrennte Class-Loader Isolation gewährleistet, d.h. Java-Klassen verschiedener Versionen einer Anwendung können nicht gemischt werden..

·        Anwendungscode läuft im Kontext einer Java-VM. Es spielt für die Anwendung im VM Container keine Rolle, in welcher speziellen VM sie läuft, der VMC verhält sich für die Anwendung fast wie eine einzige Java-VM.

·        Eine Anwendung bestimmt selbst, welche Objekte sie mit anderen Anwendungen teilen will. Es gibt hier keine Vorgaben vom VM Container.

Design

Komponente

Eine Komponente ist eine benannte Einheit, die aus Modulen besteht. Der Name hat die Form /namespace/name, wobei der Namensraum maximal 8 Zeichen lang und der Name maximal 30 Zeichen (case-insensitive) lang sein kann. Für Namen, die mit Y oder Z beginnen, ist der Standardnamensraum /0CUST/, für alle anderen Namen /0SAP/.

Modul

Ein Modul ist eine deploybare Einheit, die Ressourcen und Bindungen enthält. Die Module sind als Entwicklungseinheiten im System allgemein sichtbar und können einzeln transportiert werden. Aus diesem Grund dürfen Modulnamen systemweit (über Komponentengrenzen hinweg) nur einmal vergeben werden. Das Format des Modulnamens ist das selbe wie für Komponenten.

Ressourcen sind gewöhnliche Dateien mit beliebig langen Namen (z.B. Java-Klassendateien).

Ein Modul als Sammlung von Ressourcen entspricht einer jar-Datei oder einem Verzeichnis.

Bindung

Die Bindungen dienen dazu, für einen Request den richtigen Handler zu finden: Der Name identifiziert den Request (z.B. den Namen des gerufenen Funktionsbausteins), der Wert der Bindung gibt normalerweise den Java-Klassennamen des Handlers an. 

Eine Bindung ist ein Name/Wert-Paar, wobei der Name ein 7-Bit-ASCII-String und der Wert ein Multistring ist (ein oder mehrere, durch Kommata getrennte Strings). Bindungen stehen in Text-Property-Dateien, die Ressourcen eines Moduls sind.

Datenfluss

Organisation in der Datenbank

Die Komponenten werden in verschiedenen Datenbanktabellen gehalten. Laufzeit-Tabellen dienen zum Classloading und Bindungs-Lookup; Transport-Tabellen werden für den Import/Export aus/in andere Systeme verwendet.

Laufzeit-Tabellen

Die Komponenten werden in Tabellen in der Datenbank gehalten.

Da jedes Modul mit einem Zeitstempel versehen ist, kann die Datenbank in Schichten dargestellt werden, wobei jeder Zeitstempel eine Schicht bildet.

Es existieren zwei Versionen des Moduls A=/0SAP/TEST (einschließlich aller Ressourcen und Bindungen). Die erste wurde mit Zeitstempel T1 abgespeichert, die zweite mit T2.

Der Applikationsserver kennt den Zeitstempel der Komponente, die er aktivieren will. Er sieht alle aktuellen (neuesten) Module, die einen älteren (oder gleichen) Zeitstempel besitzen.

Die Datenbank enthält also zu einem Zeitstempel immer die neueste Version jedes Moduls. Dieses Beispiel zeigt die Module A, B und C einer Komponente.

Zeitstempel	Modul A	Modul B	Modul C
T1	v.1		v.1
T2	v.2
T3	v.3	v.1	v.2
T4		v.2
...	...	...	...

Der Applikationsserver kennt den Zeitstempel t der Komponente, die er aktivieren will. Er sieht dann alle aktuellen Module, deren Zeitstempel kleiner (älter) oder gleich t sind. Wäre also in diesem Beispiel t =T2, würde er Version 2 von Modul A und Version 1 von Modul C aktivieren. Modul B hätte er nicht.

Transport-Tabellen

Die Transport-Tabellen werden für Import und Export von Modulen von/in andere SAP-Systeme benötigt. Sie werden nicht zum Classloading verwendet und nicht in dem Zeitstempel-Schichten-Modell organisiert.

Die Transport-Tabellen werden gemeinsam mit den Laufzeit-Tabellen während des Deployments modifiziert. Beim Transfer aus anderen Systemen wird in die Transport-Tabellen geschrieben, die dann als Datenquelle für die Integration in die Laufzeit-Tabellen dienen.

Operationen

Es gibt folgende Datenbankoperationen für Komponenten.

●     Deployment, einschließlich Einspielen von Patches und löschen von Anwendungen

●     Integration

●     Verdichtung

Diese Operationen sind als SQL-Transaktionen implementiert.

Deployment

Deployment wird dann genützt, wenn direkt in dem betroffenen System installiert wird (im Gegensatz zum Import eines transportierten Moduls).

Die Deployment-Transaktion ermöglicht folgende Aktionen.

●     Deployment ganzer Komponenten

●     Patchen von einzelnen Modulen einer Komponente

●     Löschen von Komponenten und Modulen

Die Transaktion ändert sowohl Laufzeit- als auch Transport-Tabellen. Bei den Transport-Tabellen werden bei allen Operationen die vorhandenen Module physikalisch aus der Tabelle gelöscht und gegebenenfalls neue Komponenten oder Patches eingefügt.

Bei den Laufzeit-Tabellen ist die Modifikation nicht-destruktiv. Es wird kein Datensatz gelöscht, weil andere Applikationsserver potentiell darauf zugreifen, falls die zugehörige Anwendung noch ausgeführt wird. Nur Datensätze mit neuen Zeitstempeln können hinzugefügt werden. Das Löschen wird durch das Einfügen „leerer“ Module simuliert. Im einzelnen funktioniert die Modifikation wie folgt.

●     Beim Deployment einer Komponente werden alle existierenden nichtleeren Module außer denen, die deployt werden sollen, verborgen. Die zu deployenden Module werden mit neuem Zeitstempel eingefügt.

●     Beim Patchen eines Moduls, wird dieses einfach mit neuem Zeitstempel eingefügt.

●     Beim Löschen einer Komponente werden alle ihre nichtleeren Module verborgen. 

Integration

Integration wird genutzt, wenn Transporte in das System eingespielt werden.

Die Integrations-Transaktion kopiert importierte Module aus den Transport-Tabellen in die Laufzeit-Tabellen.

Verdichtung

Aufgrund des nicht-destruktiven Vorgehens in den Laufzeit-Tabellen wachsen diese an. Die Verdichtung entfernt die veralteten Module, die von keinem Applikationsserver mehr verwendet werden.

Weitere Informationen

Lebenszyklus laufender Anwendungen

VMC Systemadministration (SM53): Anwendungen anzeigen