Eigenes Datenbank-Plug-in erstellen
Wenn Sie ein Plug-in für Ihre eigene Datenbank entwickeln möchten, erstellen Sie ein Plug-in, das auf dem Plug-in "wasdb2" basiert.
Das Plug-in wasdb2 enthält Komponenten für Verbindungen zu einer vorhandenen DB2® -oder Informix® -Datenbank. Es unterstützt auch Verbindungen mit einer über ein Muster implementierten DB2 -Datenbank. Dies bedeutet, dass eine virtuelle Maschine, auf der DB2 ausgeführt wird, in derselben virtuellen Anwendung implementiert wird wie die, auf der IBM® WebSphere® Application Serverausgeführt wird. Sie können eine oder beide Implementierungen in Ihr angepasstes Plug-in einschließen.
Für eine über Muster implementierte Datenbank gibt es zwei virtuelle Maschinen, eine mit WebSphere Application Server mit der Anwendung des Benutzers und die andere mit DB2 , um Daten für die Anwendung zu verwalten. Im vorliegenden Fall ist die Datenbank bereits auf einem anderen System betriebsbereit, entweder in der Cloud, als gemeinsam genutzter Service oder außerhalb der Cloud, die von Cloud Pak System Software für x86verwaltet wird. In beiden Fällen benötigt WebSphere Application Server die IP-Adresse, die Portnummer, den Datenbanknamen und die Datenbankberechtigungsnachweise (Benutzer-ID und Kennwort), um die Verbindung zur Datenbank herzustellen. Im Anwendungsmodell werden der WebSphere Application Server -Knoten und der Datenbankknoten als Komponenten modelliert. Der Link zwischen den beiden Komponenten im Anwendungsmodell stellt die Verbindung zwischen den beiden Komponenten dar und ist die Grundlage für die Datenübertragung der erforderlichen Zugriffsinformationen.
Über Muster implementierte Datenbankverbindung
Rollen bieten Funktionen für die
Koordination von Anwendungsstart, Lebenszyklusmanagement und Deimplementierung. Für eine mit IBM Web Application Patternimplementierte Datenbank verwaltet und interagiert eine WebSphere Application Server -Rolle mit einer WebSphere Application Server -Instanz, die auf ihrem Knoten implementiert ist, und eine DB2 -Rolle mit der DB2 -Instanz, die auf ihrem Knoten implementiert ist. Das Plug-in wasdb2 stellt einen Link zwischen den Komponenten WebSphere Application Server und DB2 bereit. Er fügt eine Abhängigkeit der Rolle WebSphere Application Server von der Rolle DB2 im Topologiedokument ein. Zu Beginn der Implementierung wird das Script WAS/DB2/changed.py ausgeführt, wenn die Rollen WebSphere Application Server und DB2 in den Status RUNNING wechseln. Die Lebenszyklusscripts für DB2 -Rollen exportieren DB2 -Merkmale wie den Hostnamen/die IP-Adresse, die Portnummer, den Datenbanknamen, die Benutzer-ID und das Kennwort, die erforderlich sind, um die DB2 -Datenbank in dieser implementierten Instanz zu verwenden. Das Script WAS/DB2/changed.py ruft diese exportierten Daten ab und übergibt die Werte an wsadmin -Scripts, um die Informationen so zu konfigurieren, dass Anwendungen auf dem WebSphere Application Server -Knoten auf die Datenbank zugreifen können.
Rollen können auch Operationen zum Implementierungseingang bereitstellen. Diese Operationen können verwendet werden, um die aktive Implementierung zu ändern. Sie können beispielsweise das Kennwort Ihrer DB2-Datenbank ändern. Das DB2 -Plug-in bietet diese Operation an, mit der das Datenbankkennwort geändert und diese geänderten Daten exportiert werden. Das Script WAS/DB2/changed.py wird über diese Aktualisierung benachrichtigt und ruft ein Script wsadmin auf, um das geänderte Kennwort in der WebSphere Application Server -Instanz zu aktualisieren, die die Datenbank verwendet.
Vorhandene Datenbankverbindung
Web Application Pattern unterstützt die Verbindung mit zwei vorhandenen Datenbanktypen: DB2 oder Informix. Für jeden der Typen wird eine Rolle verwendet: xDB2 und xInformix. Diese Rollen funktionieren wie die DB2 -Rolle, die für eine über Muster implementierte Datenbank verwendet wird. Im Teilfenster Mustererstellungsprogramm ist für jeden Datenbanktyp eine Anwendungsmodellkomponente mit den Attributen Hostname/IP-Adresse, Portnummer, Datenbankname sowie Benutzer-ID und Kennwort verfügbar. Diese Werte werden während des Entwurfs einer virtuellen Anwendung angegeben. Eine Linkumsetzung macht die Rolle WebSphere Application Server von diesen Rollen für vorhandene Datenbanken abhängig. Das Script xDB2 role start.py exportiert die Werte, die in der Komponente xDB2 im Teilfenster Pattern Builder angegeben sind, mit demselben Mechanismus und denselben Schlüsselnamen wie die DB2 -Rolle. Die vorhandenen Datenbankrollen bieten wie die DB2-Rolle Konfigurationseinstellungen und Änderungsoperationen für den Implementierungseingang an, um diese Konfigurationswerte dynamisch zu ändern. Wie bei einer über Muster implementierten DB2 -Datenbank rufen WAS/xDB/changed.py -Scripts die exportierten xDB -Werte (IP-Adresse, Portnummer, Datenbankname, Benutzer-ID und Kennwort) ab und rufen die entsprechenden Konfigurationsscripts von WebSphere Application Server auf, damit die Anwendungen auf dem WebSphere Application Server -Knoten auf die Datenbank zugreifen können.
- "asDependency": "DB"
- Normalerweise stellt jede abhängige Rolle ihre eigenen abhängigen Rollenscripts bereit. Das Plug-in "wasdb" stellt diese Scripts für alle Datenbanken als WAS/DB-Scripts bereit. Während das Topologiedokument die Rolle WebSphere Application Server hat, die von der entsprechenden Datenbankrolle (DB2, xDB2oder xInformix) abhängig ist, ordnet das Attribut "asDependency" alle Scriptaufrufe für abhängige Rollen WAS/DB zu, z. B. für changed.py. Datenbankabhängige Informationen, die für jede Datenbank eindeutig sind, werden in einem JSON-Objekt "dblink_metadata" an den wasdb-Link übergeben.
- "localOnly": true
- Dieses Attribut wird in den vorhandenen Ressourcen-oder Ersatzrolle -Fällen verwendet, um anzugeben, dass diese Rolle für den WebSphere Application Server -Knoten lokal ist. Bei der Skalierung ist es besonders wichtig, WAS/DB/changed.py nur einmal pro lokalem WebSphere Application Server -Knoten aufzurufen. Im nächsten Abschnitt werden Ersatzrollen beschrieben.
- dblink_metadata (erforderlich)
- JSON-Objekt mit zwei Elementen:
- packages (optional)
- Ein JSON-Array mit Paketnamen, die auf dem WebSphere Application Server -Knoten installiert werden sollen Die Pakete werden der Variablen $sourcePackages in der Velocity-Vorlage wasdb_link.vm auf gewöhnliche Weise hinzugefügt.
- parms (erforderlich)
- Die datenbankspezifischen Parameter, die von den Scripts benötigt werden, um Web Application Pattern für die Verbindung zur Datenbank zu konfigurieren.
- role (optional)
- Die Rolle, die in die WebSphere Application Server -Vorlage eingefügt wird Sie wird auch als abhängige Rolle für die WebSphere Application Server Rolle in der Quellenvorlage WebSphere Application Server definiert, wie dies bei Linkumsetzungen für Velocity-Vorlagen üblich ist. Das Element "role" wird bei einer vorhandenen Datenbank
für xDB2 oder xInformix verwendet.
Eine über Muster implementierte Datenbank benötigt keine zusätzliche Rolle. Sie verwendet die Rolle DB2 für die Rolle WebSphere Application Server , von der sie abhängig ist. Der Parameter targetRole ist im Element
dblink_metadata parmsfür eine über Muster implementierte Datenbank enthalten. Ihr Wert ist der Name der über Muster implementierten Datenbankrolle der Abhängigkeit, die der Rolle WebSphere Application Server hinzugefügt wurde.
Ersatzrollen verwenden
Die Ersatzrolle ist eine Option, wenn Ihr Plug-in für die Datenbankmusterimplementierung keine Rolle bereitstellt, die die DB2 -Rolle genau abbildet, oder wenn die Daten, die exportiert werden, nicht dieselben Namen wie die DB2 -Rolle und die xDB -Rollen verwenden. Eine Ersatzrolle wird hinzugefügt,
um dem Plug-in "wasdb" Status und Änderungen in der Zieldatenbankrolle in der vom Plug-in erwarteten Weise zurückzumelden. Angenommen, eine Datenbank mit dem Namen DB3 hat eine Rolle DB3, die Sie für Ihr Plug-in
"wasdb" verwenden möchten. Sie erstellen eine neue Rolle mit dem Namen DB3Surrogate,
die von der Rolle DB3 abhängig ist. Diese Rolle hat ein Script DB3Surrogate/DB3/changed.py, das geänderte exportierte
Daten von DB3 abruft. Die Rolle WebSphere Application Server ist von der Rolle DB3Surrogate abhängig, die geänderte Daten aus DB3exportiert, in Namen und Formate konvertiert, die von wasdb erwartet werden, und in Namen exportiert, die von wasdb erwartet werden. Um diese Konfiguration mit einem WASDB-Link zu realisieren, wird targetRole
im Element "parms" von "dblink_metadata" auf den Wert DB3 gesetzt, und die Rolle "DB3Surrogate" wird als Element
"role" übergeben.