Diplomarbeit - Technische Informatik

Diplomarbeit
Java Programmierung mit JDBC
Zugriff auf eine OS/390 DB2
Datenbank
Stefan Munz
April 2003
2
Ich versichere, die Arbeit selbständig verfasst und nur die angegebenen Quellen und
Hilfsmittel benutzt zu haben.
3
Danksagung
An dieser Stelle möchte ich mich bei allen bedanken, die durch ihre Hilfe und Unterstützung
dazu beigetragen haben, dass meine Diplomarbeit in dieser Form entstehen konnte.
Besonders danken möchte ich Herr Prof. Dr. rer. nat. Wolfgang Rosenstiel und Herr Prof.
Dr.-Ing. Wilhelm G. Spruth, die meine Diplomarbeit betreut haben. Herrn Spruth möchte ich
für die Vermittlung der vielen Kontakte danken, ohne die ich die Konfiguration des OS/390
Servers sicher nicht in der vorliegenden Form geschafft hätte.
Einige der OS/390 Spezialisten möchte ich besonders hervorheben:
Herr Greis und Herr Holliger von der Firma TPS-Data, die mir einen 2 tägigen,
arbeitsintensiven Zürichaufenthalt ermöglichten und die grundlegende Konfiguration von
Websphere und DB2 vornahmen.
Herr Breitenfeld, der mehrfach kritische DB2 und JDBC Einstellungen berichtigt hat.
Herr Böhm, der mir bei einem halbtägigen Aufenthalt im IBM Labor in Böblingen mit der
Websphere Konfiguration half.
Und natürlich Herr Drecker, der immer wieder telefonisch bei Websphere Problemen zur
Verfügung stand.
4
Inhaltsverzeichnis
1. Zusammenfassung.......................................................................................................................6
2. Einleitung.....................................................................................................................................8
2.1 Motivation für die Integration von OS/390 Mainframes in das Internet......................................8
2.2 Ziel der Diplomarbeit.............................................................................................................10
2.3 Aufbau der Diplomarbeit........................................................................................................10
3. Funktionsweise von Connectoren............................................................................................12
4. OS/390 Systemumgebung.........................................................................................................14
4.1 OS/390 Hardware..................................................................................................................14
4.2 Zugriff auf den OS/390 Server...............................................................................................15
4.3 OS/390 Software...................................................................................................................15
4.3.1 DB2...............................................................................................................................15
4.3.2 SQL Processor Using File Input (SPUFI)........................................................................15
4.3.3 Unix System Services (USS).........................................................................................16
4.3.4 Websphere....................................................................................................................17
5. Konfiguration der OS/390 Systemumgebung ..........................................................................19
5.1 JDBC Zugriff aus einem Java Programm auf DB2...............................................................19
5.1.1 Konfiguration von DB2 für den JDBC Zugriff aus einem Java Programm.......................20
5.1.1.1 db2jdbc.cursors Datei ............................................................................................20
5.1.1.2 Call Level Interface Konfigurationsdatei.................................................................22
5.1.1.3 .profile Datei..........................................................................................................22
5.1.1.4 GRANT Statement ausführen.................................................................................23
5.1.2 Beispielprogramm von IBM kompilieren und ausführen..................................................23
5.2 JDBC Zugriff aus einem Java Servlet....................................................................................26
5.2.1 Konfiguration von Websphere für den JDBC Zugriff aus einem Java Servlet.................27
5.2.1.1 was.conf Datei.......................................................................................................28
5.2.1.2 Websphere Startskript............................................................................................28
5.2.1.3 httpd.envvars Datei................................................................................................29
6. Entwicklungsumgebung auf der Workstation..........................................................................30
6.1 Eclipse vs. Visual Age for Java..............................................................................................30
6.2 Installation von VisualAge for Java und Eclipse.....................................................................31
6.3 Zugriff von der Entwicklungsumgebung auf eine OS/390 Datenbank.....................................33
6.3.1 DB2 Zugriff mit DB2Connect..........................................................................................34
6.3.2 DB2 Zugriff mit Hit JDBC Treiber...................................................................................35
6.3.3 Test der Installation mit JUnit Tests...............................................................................35
6.4 Programmierung....................................................................................................................37
6.4.1 HelloWorld Java Programm...........................................................................................37
6.4.1.1 Test in der Entwicklungsumgebung........................................................................39
6.4.1.2 Export in die Produktionsumgebung.......................................................................39
6.4.2 HelloWorld Java Servlet................................................................................................43
6.4.2.1 Test in der Entwicklungsumgebung........................................................................43
6.4.2.2 Export in die Produktionsumgebung.......................................................................44
7. Gästebuch Servlet......................................................................................................................45
8.Zusammenfassung und Ausblick...............................................................................................50
9. Literaturverzeichnis...................................................................................................................51
5
9.1 Referenzen aus Zeitschriften und Büchern.............................................................................51
9.2 Internet Referenzen...............................................................................................................51
10. Anhang.....................................................................................................................................54
10.1 Inhaltsverzeichnis der CD....................................................................................................54
11. Glossar.....................................................................................................................................56
Zusammenfassung
6
1. Zusammenfassung
Die vorliegende Arbeit befasst sich mit der Entwicklung von Java-Programmen und
-Servlets für OS/390 Großrechner. Daten, die auf dem OS/390 Server in einer DB2
Datenbank liegen, sollen über das Internet zugänglich gemacht werden. Es wird eine
einfache Anwendung entwickelt, bei der Präsentations- und Businesslogik in einem
einzigen Servlet enthalten sind.
Im Mittelpunkt der Arbeit steht die Konfiguration des OS/390 Servers und der Einsatz einer
effizienten Entwicklungsumgebung. Hierfür wird eine Workstation und alternativ die Java
Programmierumgebungen VisualAge bzw. Eclipse benutzt. In der Entwicklungsumgebung
fehlerfrei laufende Programme oder Servlets werden in die Produktionsumgebung (OS/390
Server) exportiert (s. Abbildung 1).
Klient
Browser
Workstation
OS/390 Server
(Entwicklungsumgebung)
(Produktionsumgebung)
Visual Age for Java / Eclipse
Servlet
Engine
Java
Servlet
Websphere
Java
Servlet
Java
Programm
Java
Programm
OS/390 JDBC Treiber
IBM JDBC
Treiber
Hit Treiber
DB2Connect
DB2
Abbildung 1 - Überblick über die Entwicklungs- und Produktionsumgebung
Der Zugriff auf die DB2 Datenbank erfolgt durch umgebungsspezifische Connectoren (vgl.
Kapitel 3). Java Programme oder -Servlets greifen aus der Entwicklungsumgebung über
den Hit Java Database Connectivity (JDBC) Connector oder mit dem IBM JDBC Connector
über DB2Connect auf die Datenbank zu. In der Produktionsumgebung wird hierzu der
OS/390 JDBC Connector von IBM verwendet. Diese Konstellation kombiniert die Vorteile
einer modernen, grafischen Entwicklungsumgebung (Debugger, übersichtliche Darstellung,
usw.) mit einem sehr einfachen Export der Programme in die Produktionsumgebung. Die
Zusammenfassung
7
fertigen Programme und Servlets werden per FTP auf den Server geladen und können dort
sofort ausgeführt werden.
In den folgenden Kapiteln wird die Konfiguration des OS/390 Servers (Websphere und
DB2), und der Workstation (VisualAge bzw. Eclipse, Websphere Testumgebung bzw.
Tomcat, DB2Connect und der Hit Treiber) beschrieben. Die aufgezeigten Konfigurationen
wurden anhand einer Anwendung (Gästebuch) evaluiert. Hierfür wurde die erforderliche
Datenbank eingerichtet, das Gästebuch Servlet entwickelt und in die Produktionsumgebung
exportiert.
Aus den oben genannten Arbeitsabläufen sind zwei Tutorials entstanden, die Schritt für
Schritt erklären, wie über ein Netzwerk auf eine OS/390 DB2 Datenbank zugegriffen und
das Java Programm auf den OS/390 Server exportiert wird (vgl. Kapitel 6). Die Entwicklung
des Gästebuchs beschreibt beispielhaft die Programmierung einer Internetanwendung in
einer modernen IDE mit der Java Servlet Technologie (vgl. Kapitel 7).
Ein weiteres Ziel dieser Diplomarbeit ist eine moderne Gestaltung, die digital gespeicherte
Daten möglichst benutzerfreundlich integriert. Deshalb wird der klassische Anhang durch
eine CD bzw. eine Internetseite ersetzt. Dadurch können Quellcode und
Konfigurationsdateien direkt am Computer angeschaut bzw. benutzt werden. An vielen
Stellen wird noch einmal speziell durch dieses Icon darauf hingewiesen (vgl. Kapitel 2.3):
Verzeichnis/Dokumentname
Einleitung
8
2. Einleitung
2.1 Motivation für die Integration von OS/390 Mainframes in das
Internet
Etwa 90 % der 2000 größten Unternehmen setzen einen S/390 Rechner als ihren zentralen
Server ein. Die Anzahl der weltweit stündlich durchgeführten S/390 CICS Transaktionen ist
etwa so groß wie die Anzahl der Zugriffe auf Seiten des World Wide Web [ CIC ] [ GRA ].
Vorgänge wie das Abheben eines Geldbetrages in der Bank, die Buchung eines Fluges im
Reisebüro oder das Bezahlen eines Einkaufs mit der EC Karte werden als Transaktionen in
einem zentralen Rechner mit Hilfe eines Transaktionsmonitors verarbeitet. CICS ist der mit
Abstand am weitesten verbreitete Transaktionsmonitor.
Von sogenannten Experten als Auslaufmodell bezeichnet, werden die Großrechner jedoch
laut den zuständigen IT-Verantwortlichen nach wie vor in großem Umfang eingesetzt. Die
Frage "Wann ersetzen Sie Ihre S/390-Anwendungen durch eine moderne Technologie?"
habe der IT-Veranwortliche einer deutschen Großbank so beantwortet: "Ich glaube nicht,
dass dies in den nächsten 50 Jahren geschehen wird" [ KEB ].
Bei einem Blick auf folgende Zahlen
•
Zwischen 65 und 70 % aller geschäftsrelevanten Daten werden im EBCDIC Format auf
S/390 Rechnern gespeichert,
•
60% aller geschäftsrelevanten Daten, auf die mittels des World Wide Web zugegriffen
werden kann, sind in Mainframe Datenbanken gespeichert, hauptsächlich DB2, IMS und
VSAM [ SP1 ],
wird klar, welche wichtige Stellung die Bereitstellung dieser Daten über das Internet, in
Zukunft und auch heute schon, einnimmt. Um diesem Umstand Rechnung zu tragen,
beschäftigt sich diese Diplomarbeit mit der Entwicklung von Java Servlets und deren Zugriff
auf OS/390 Großrechner. Bei der Wahl der Entwicklungsumgebung und -werkzeuge sowie
dem Produktionsablauf wird darauf geachtet, sich an der Entwicklung realer Projekte für
Großrechner zu orientieren. Deshalb hierzu noch einige Anmerkungen:
Es ist ausgesprochen unüblich, die Entwicklung neuer Anwendungen auf dem gleichen
Server zu betreiben, auf dem die Anwendungen später einmal laufen sollen. In einem
Unternehmen unterscheiden wir in der Regel zwischen dem/den Rechner/n einer
Entwicklungsumgebung, auf dem/denen neue Anwendungen entstehen, und dem/den
Rechner/n einer Produktionsumgebung, auf dem/denen die Anwendung später einmal
laufen sollen. Entwicklungen erfolgen meistens im Team. Die Entwickler haben jeder einen
leistungsfähigen Arbeitsplatzrechner, auf dem editiert, kompiliert und getestet wird. Alle
Arbeitsplatzrechner sind mit einem gemeinsamen Entwicklungsserver, dem Repository,
verbunden, auf dem Quellcode und Maschinencode in unterschiedlichen Versionen zentral
gespeichert werden. Auf dem Repository Rechner laufen Funktionen wie die zentrale
Steuerung des Entwicklungsprojektes, Backup Verwaltung und der Integrations- und
Systemtest der von den einzelnen Entwicklern erstellten Komponenten. Nach Abschluss
einer Entwicklung wird der so entstandene Code in die Produktionsumgebung exportiert.
Häufig wird noch eine Testumgebung zwischengeschaltet, welche die
Produktionsumgebung möglichst naturgetreu nachbildet.
Einleitung
9
Die Software der Entwicklungsumgebung unterscheidet sich erheblich von der Software der
Produktionsumgebung. Als Entwicklungsrechner werden Win 2000 Rechner oder Linux
Rechner eingesetzt. Das Repository befindet sich in der Regel auf einem getrennten Unix
oder Win 2000 Rechner. Bei der Produktionsumgebung unterscheiden wir zwischen einer
2-Tier und einer 3-Tier Konfiguration. Bei der 2-Tier Konfiguration laufen alle Anwendungen
auf dem zentralen OS/390 Rechner. Bei der 3-Tier Konfiguration läuft ein Teil der
Anwendungen auf einem getrennten Unix oder Win 2000 Server; auf dem OS/390 Rechner
befindet sich die zentrale Datenhaltung (z.B. DB2) und evtl. ein Teil der Anwendungen (z.B.
Java Servlets oder CICS Programme). Die Arbeitsplatzrechner der Benutzer der
Produktionsumgebung haben in der Regel nur eine geringe Funktionalität. In vielen Fällen
ist dies lediglich ein Browser (vgl. Abbildung 2).
Abbildung 2 - Alternativen für einen Servletzugriff auf eine OS/390 Datenbank
Einleitung
2.2 Ziel der Diplomarbeit
Das Ziel ist, mit Hilfe von Java und der JDBC Datenbankzugriffe auf einen OS/390
Großrechner durchzuführen, zuerst als Java Programm und im nächsten Schritt als Java
Servlet. Es handelt sich hierbei um eine 2-Tier Architektur; alle Anwendungen (Java,
Websphere und DB2) laufen auf dem OS/390 Server. Im Rahmen dieser Arbeit wurde
hierfür der OS/390 Rechner des Instituts für Informatik der Universität Leipzig,
jedi.informatik.uni-leipzig.de, eingesetzt. Die Entwicklungs- und
Produktionsumgebung soll dem bereits beschriebenen Szenario möglichst nahe kommen.
Die Entwicklung und der Test sollen deshalb auf einer Workstation mit modernen
Entwicklungswerkzeugen durchgeführt und die fertigen Programme dann auf den OS/390
Server exportiert werden. Sobald dies mit einfachen HelloWorld Programmen funktioniert,
soll ein komplexeres Servlet erstellt werden.
Die Diplomarbeit umfasst die Installation und Konfiguration aller Werkzeuge und
Systemkomponenten sowohl auf dem OS/390 Server als auch auf der Workstation sowie
die Programmierung bzw. Konfiguration aller verwendeten Programme.
Die Ergebnisse sollen so aufbereitet werden, dass sie im Rahmen des Client Server
Praktikums als Tutorials bzw. Übungsaufgaben den Studenten zur Verfügung gestellt
werden können [ TU2 ][ TU3 ][ TU4 ].
Folgende Systemumgebungen werden konfiguriert:
1. Die Test- und Entwicklungsumgebung: Alle Programme werden dabei auf der
Workstation ausgeführt, der Datenbankzugriff erfolgt auf den OS/390 Server.
2. Die „Produktionsumgebung“: Alle Programme und Datenbankzugriffe werden auf dem
OS/390 Server durchgeführt.
Am Ende der Diplomarbeit soll ein funktionsfähiges System mit folgenden
Leistungsmerkmalen zur Verfügung stehen:
1. Der OS/390 Server muss so konfiguriert sein, dass JDBC Zugriffe intern und aus dem
Internet möglich sind. Sowohl Java Programme als auch Java Servlets sollen JDBC
benutzen können.
2. Die Beispielprogramme müssen in der Entwicklungsumgebung auf der Workstation
ausgeführt und debuggt werden können.
3. Die Beispielprogramme müssen auf den OS/390 Server hochgeladen und dort
ausgeführt werden können.
2.3 Aufbau der Diplomarbeit
Die vorliegende Arbeit ist in 9 Hauptbereiche aufgeteilt:
Kapitel 3 beschreibt die grundlegende Funktionsweise von Connectoren. Der Zugriff auf
eine DB2 Datenbank mit den entsprechenden Connectoren ist Hauptgegenstand dieser
Arbeit.
Kapitel 4 enthält einen kurzen Überblick über die OS/390 Hard- und Software.
10
Einleitung
11
Kapitel 5 befasst sich mit der Konfiguration des OS/390 Großrechners. Zuerst wird der
Ablauf eines Zugriffs auf die Datenbank aus einem Java Programm und einem Servlet
beschrieben. Dann werden die dafür nötigen Konfigurationsschritte erläutert.
Kapitel 6 beschreibt die Installation und Konfiguration der Workstation. Schematisch wird
zuerst der theoretische Ablauf dargestellt. Dann werden die verwendeten Programme und
ihre Installation bzw. Konfiguration beschrieben.
Kapitel 7 erklärt den Produktionsablauf. Anhand eines Beispiels, einem Gästebuch Servlet,
wird erläutert, wie ein Projekt auf der Workstation entwickelt, getestet und dann in die
Produktionsumgebung exportiert wird.
Kapitel 8 beschreibt in einigen Schlussbemerkungen den Gesamteindruck des
Produktionsablaufs. Es werden auch einige Erweiterungen skizziert.
Kapitel 9 enthält das Literaturverzeichnis.
Kapitel 10 listet in tabellarischer Form den Inhalt der beigelegten CD bzw. der zugehörigen
Internetseite auf.
Kapitel 11 erklärt die wichtigsten Abkürzungen in einem Glossar.
Anmerkungen:
Bei der Beschreibung von Konfigurationsdateien oder Java Programmen werden bei
umfangreicheren Dateien jeweils nur die geänderten oder hinzugefügten Teile abgebildet.
Quellcode, Programm- und Verzeichnisnamen werden im Text durch die Schriftart
Courier gekennzeichnet. Zeilenumbrüche, die nur zur Lesbarkeit gemacht werden und in
den Orginaldateien zu Fehlern führen könnten, sind dadurch gekennzeichnet, dass keine
separate Zeilennummer eingefügt wird.
In dieser Diplomarbeit wird der klassische Anhang durch eine Referenz auf einer CD bzw.
Internetseite ersetzt. Der erstellte Quellcode, die angepassten Konfigurationsdateien und
alle im Literaturverzeichnis referenzierten Dokumente, die in digitaler Form verfügbar sind,
sind auf einer CD und zusätzlich auf einer Internetseite gespeichert. Im Text wird mit einem
Icon nochmals gezielt darauf hingewiesen:
Verzeichnis/Dokumentname
Das referenzierte Dokument kann auf der CD über das Menü oder direkt durch den Aufruf
des Dokuments Dokumentname im angegebenen Verzeichnis Verzeichnis geöffnet
werden. Es ist auch möglich, auf das Dokument über die URL:
http://www-ti.informatik.uni-tuebingen.de/~csp/diplom/munz
im Internet zuzugreifen.
Für das Verständnis der Diplomarbeit wird ein grundlegendes Wissen über die
Programmierung in Java und von Java Servlets vorausgesetzt. Es existieren zahlreiche
Bücher und Online Tutorials, die dem Leser einen Einstieg erleichtern [ JA1] [ JA2 ].
Funktionsweise von Connectoren
12
3. Funktionsweise von Connectoren
Zum Verständnis der Diplomarbeit sind grundlegende Kenntnisse über Connectoren
notwendig, da sie für alle Datenbankzugriffe verwendet werden. Es folgt hier ein kurzer
Überblick über deren Aufbau, Klassifizierung und Funktionsweise [ HER ]:
Bei den Implementierungen von e-Business- oder Web Commerce-Lösungen spricht man
von einem Frontend, das typischerweise mit einem Web Application-Server realisiert wird,
und einem Backend (Auftragseingang, Finanzbuchhaltung), wofür z.B. OS/390
Anwendungen eingesetzt werden. In vielen Fällen werden 20% des Projektaufwandes für
die Neuentwicklung des Frontends und 80% für dessen Integration in das vorhandene
Backend aufgewendet.
Connectoren sind Software-Programme, die ein Java-Programm, eine Web-Anwendung
oder einen Browser mit existierenden Backend-Anwendungen oder Daten verbinden,
beispielsweise über JDBC an eine OS/390 DB2 Datenbank (s. Abbildung 3). Wichtige
Gesichtspunkte für die Auswahl eines Connectors sind:
1. Leistungsanforderungen (Transaktionen pro Sekunde),
2. Sicherheitsanforderungen (z.B. SSL, einschließlich Einfluss auf das Leistungsverhalten),
3. 2-Tier versus 3-Tier-Überlegungen.
Connectoren lassen sich in drei Klassen aufteilen:
1. API Connectoren verwenden kein Java. Sie sind seit längerer Zeit verfügbar und haben
in der Regel eine schlechtere Portabilität und ein besseres Leistungsverhalten als die
Connectoren der beiden anderen Klassen. Existierende OS/390-Beispiele sind: CICS
Web Support (CWS), IMS TCP/IP OTMA Connection (IMS TOC), Net.Data sowie CWS
mit 3270 Bridge. In der Diplomarbeit wird auf dem OS/390 Server ebenfalls mit einem
JDBC API Connector gearbeitet. IBM bietet auch für Nicht-OS/390 Betriebssysteme nur
einen JDBC API Connector an, die entstehenden Probleme und Lösungsmöglichkeiten
werden in Kapitel 6.3 erläutert.
2. Java Connectoren verwenden Java. Für sie liegen ebenfalls Erfahrungen im
industriellen Einsatz vor. Für relationale Datenbanken existieren die JDBC- und SQLJConnectoren. CICS und IMS haben das CICS Transaction Gateway (CTG) und den IMS
TOC Connector for Java als Teil des Common Connector Framework (CCF) entwickelt.
Dieses Framework wird von den Websphere Java-AnwendungsEntwicklungswerkzeugen unterstützt, spezifisch VisualAge for Java. Host On-Demand ist
eine weitere Lösung für 3270-Anwendungen.
Der Vorteil von Connectoren der 2. Generation ist, dass sie vollständig
systemunabhängig sind. Eine Java Applikation, die JDBC benutzt, kann z.B. mit
minimalen Änderungen auf verschiedenen Plattformen laufen. Minimale Änderung
bedeutet, dass nur der Treibername und evtl. die URL für den Datenbankserver, die
meist zentral für die gesamte Applikation gesetzt werden, geändert werden müssen.
3. Enterprise JavaBeans Connectoren bauen auf der Java 2-Protokoll-Familie auf, z.B.
JMS, JDBC 2.0, und stellen eine Evolution der Java-Connectoren dar. Sie verfügen über
Funktionsweise von Connectoren
13
zusätzliche Transaktions- und Sicherheitseigenschaften auf der Thread-Ebene sowie
Daten-Persistenz als Teil des Programmiermodells. Sie sind derzeitig in der Entwicklung;
eine Reihe offener Fragen müssen noch geklärt werden. Sie sind als Teil des J2EEStandards in der Java Connector Architecture (JCA) Spezifikation definiert.
Da die auf dem OS/390 Server installierten Programmversionen von Websphere und
DB2 JDBC 2.0 nicht unterstützen, wird stattdessen JDBC 1.0 eingesetzt.
Abbildung 3 - Funktionsweise von Connectoren [ KO1 ]
OS/390 Systemumgebung
14
4. OS/390 Systemumgebung
4.1 OS/390 Hardware
Für Leser ohne Mainframe Erfahrung ist anzumerken, dass die Systemumgebung eines
Mainframes sich deutlich von einer Unix- oder Windowssystemumgebung unterscheidet.
Einige der besonders interessanten Eigenschaften der OS/390 Hardware werden in diesem
Kapitel vorgestellt. Eine umfassende Einführung in die OS/390 Hard- und Software findet
man in [ HER ].
1. Ein-/Ausgabe Architektur
Im Gegensatz zu den meisten anderen Rechnerarchitekturen verfügt S/390 über eine
eindeutig definierte Ein-/Ausgabe-Architektur mit einer überdurchschnittlich hohen
Leistung. Letztere hat einen besonderen Stellenwert bei Zugriffen auf Datenbanken und
bei der Transaktionsverarbeitung. Vorgänge wie das Abheben eines Geldbetrags in der
Bank, die Buchung eines Flugs im Reisebüro oder das Bezahlen eines Einkaufs mit der
EC-Karte werden als Transaktionen in einem zentralen Rechner mit Hilfe eines
Transaktions-Monitors verarbeitet. In solchen Fällen wird das Leistungsverhalten eines
Rechners nicht vorrangig durch die Leistungsfähigkeit der Zentraleinheit (CPU)
bestimmt, sondern dadurch, wie effektiv der Zugriff auf die gespeicherten Daten erfolgen
kann. E-Business und e-Commerce sind moderne Ausprägungen, deshalb ist das
OS/390 Betriebssystem besonders für die Webanbindung bestehender Daten mit Java
geeignet.
2. Datenspeicherung
Ein Dateisystem verbirgt die Eigenschaften des physikalischen Datenträgers
weitestgehend vor dem Anwender. Unix und Windows 2000 behandeln Dateien als
strukturlose Zeichenketten, die mittels Namen identifiziert werden. Dafür dienen
Dateiverzeichnisse, die auch wie Dateien aussehen und als solche behandelt werden
können. Während Dateien grundsätzlich sequentiell gelesen werden, sind Direktzugriffe
in der Regel nur mit Hilfe von speziellen Funktionen programmierbar.
Im Betriebssystem OS/390 ist das Dateisystem identisch mit dem Inhalt des
physikalischen Datenträgers. Bei der Formatierung einer Datei auf dem Plattenspeicher
wird die Dateistruktur festgelegt. Man unterscheidet Formatierungen für Dateien mit
direktem (DAM), sequentiellem (SAM) und index-sequentiellem (VSAM) Zugriff. Durch
diese Art der Dateistrukturierung kann der Benutzer selbst sehr genau festlegen, wie
jede Datei gespeichert werden soll. Dadurch kann die Dateifragmentierung verhindert
und die Speicherplatzzuordnung optimiert werden. Das Erstellen der richtigen
Dateistruktur ist eigentlich noch deutlich komplexer und erfordert viel mehr
Benutzervorgaben. Zum Verständnis der Diplomarbeit sind aber nur die daraus
resultierende Strukturierung in sog. Datasets im Gegensatz zu den von Unix oder
Windows bekannten Dateien und Verzeichnissen wichtig.
Die Darstellung und Speicherung von alphanumerischen Zeichen geht bei allen
Rechnerarchitekturen auf uralte Wurzeln zurück. Bei vielen Rechnern (u.a. bei allen PCs
mit Windows Betriebssystemen) ist dies die 7-Bit-ASCII-Darstellung, die ihren Ursprung
in den Lochstreifen der Teletype-Maschinen hat und nachträglich auf 8 Bit erweitert
wurde. Bei den OS/390- (und einigen anderen) Rechnern ist dies die 8-Bit-EBCDICDarstellung, die ihren Ursprung in den Lochkarten hat. Bei der Übertragung und
OS/390 Systemumgebung
15
Erstellung von Textdateien musste deshalb auf die korrekte Konvertierung von ASCII
nach EBCDIC und umgekehrt geachtet werden [ HER ] [ SP2 ].
4.2 Zugriff auf den OS/390 Server
Um die nachfolgenden Konfigurationsschritte durchzuführen, muss über das Internet auf
den OS/390 Server zugegriffen werden. Dafür wird ein 3270 Klient benötigt, der über das
3270 Übertragungsprotokoll mit dem OS/390 Communication Server Subsystem
kommuniziert. Das 3270 Übertragungsprotokoll setzt auf dem Telnet Protokoll auf und
verwendet wie dieses TCP/IP Port 23 auf der Serverseite. Der 3270 Klient wird allgemein
als 3270 Emulator bezeichnet. Zum Einsatz in der Diplomarbeit kommt vor allem der
Freeware Emulator QWS3270. Stellt man damit eine Verbindung zum OS/390 Server her,
bekommt man eine Terminaloberfläche mit 24 Zeilen a 80 Zeichen angezeigt. Damit kann
auf die verschiedenen OS/390 Subsysteme und das Betriebssystem zugegriffen werden.
Die Konfiguration des OS/390 Servers wird damit vollständig remote von einer Workstation
aus durchgeführt, ein Neustart oder eine Konfiguration vor Ort ist zu keinem Zeitpunkt
notwendig.
4.3 OS/390 Software
Um die Ausführung des kompilierten Quellcodes auf dem OS/390 Server zu verstehen, sind
grundlegende Kenntnisse über die verwendete Software bzw. die Laufzeitumgebung
notwendig. Die verwendeten Subsysteme werden im folgenden, soweit nötig, erklärt.
4.3.1 DB2
Bei allen Programmbeispielen findet ein Zugriff auf eine OS/390 Datenbank statt. DB2
Universal Database, auf dem Server in der Version 5 installiert, ist das OS/390 (objekt-)
relationale Datenbank-Produkt. Es ist in einer identischen Implementierung für alle UNIX-,
Linux-, OS/2-, und Windows-Betriebssysteme verfügbar. Eine zweite getrennte
Implementierung mit dem gleichen Namen ist für die S/390-Betriebssysteme verfügbar,
besonders für OS/390 und VSE. Obwohl es sich um zwei getrennte Implementierungen
handelt, ist der Funktionsumfang weitestgehend identisch und die Kompatibilität sehr gut.
DB2 ist eine Server-Anwendung, die grundsätzlich in einem getrennten Adressraum läuft.
Wie bei allen Server-Anwendungen ist ein Klient erforderlich, um auf einen DB2-Server
zuzugreifen. Der Zugriff kann mit Hilfe von SQL-Statements erfolgen, die z.B. in einem
Java-Anwendungsprogramm oder einem Java-Servlet eingebettet sind. Alternativ existieren
eine Reihe spezifischer SQL-Klienten-Anwendungen, wie z.B. SPUFI (vgl. folgendes
Kapitel) [ HER ].
4.3.2 SQL Processor Using File Input (SPUFI)
Wie im Kapitel zuvor beschrieben, gibt es verschiedene Möglichkeiten SQL Statements an
die DB2 Datenbank zu stellen. Die einfachste ist, das ISPF-Subsystem SPUFI zu
verwenden. Es handelt sich dabei um eine SQL-Klienten-Anwendung, die es dem Benutzer
erlaubt, SQL Statements, die in Datasets gespeichert sind, auszuführen. Nach der
Ausführung kann die Ausgabe angezeigt werden. Vor allem zur Erstellung von einfachen
Datenbanken zu Testzwecken und zur unkomplizierten Überprüfung von Tabellendaten ist
OS/390 Systemumgebung
16
SPUFI geeignet. Deshalb wurde SPUFI immer, wenn SQL Statements außerhalb von Java
Programmen abgesetzt werden mussten, verwendet.
4.3.3 Unix System Services (USS)
Bei den USS (früher Open Edition MVS) handelt es sich um ein funktionell eingeschränktes
aber vollwertiges Unix-Betriebssystem. Die USS sind in den OS/390-Kernel integriert und
haben deshalb die gleichen guten Zuverlässigkeits-, Robustheits- und
Skalierungseigenschaften wie das OS/390 Betriebssystem. Dem Benutzer stehen zwei
verschiedene Unix-Shells zur Verfügung. Die tcsh-Shell ist eine Erweiterung von csh, der
BerkleyUnix-C-Shell. Sie wird über einen rlogin- oder telnet-Klienten direkt aufgerufen und
unterstützt den vi-Editor. Die OS/390-Shell, auch als Ishell (ISPF-Shell) bezeichnet, basiert
auf der Unix System V-Shell mit Elementen der Korn-Shell. Sie wird über einen 3270Klienten auf dem Umweg über TSO und ISPF aufgerufen. Für den ISPF-Benutzer wird nach
der Eingabe des Kommandos TSO OMVS auf der Kommando-Zeile die Ishell initialisiert.
Nach Erscheinen des Shell-Prompts (#) können alle von Unix her bekannten Kommandos
verwendet werden. An Stelle des vi-Editors wird der ISPF-Editor benutzt [ HER ]. Die zuletzt
genannte Shell wurde während der gesamten Diplomarbeit zum Zugriff auf die USS
verwendet.
Zu beachten ist, dass die in den USS benutzten Dateien nicht, wie sonst bei dem OS/390
Betriebssystem üblich, in Datasets (z.B. VSAM), sondern im Hierarchical File System (HFS)
gespeichert werden. Das HFS von OS/390 verfügt über eine Directory-Struktur, die analog
zu den File-Systemen anderer Unix-Plattformen ist. Es wird in Containern implementiert.
Diese stellen ganz normale OS/390 Datasets dar. Innerhalb der USS kann der Benutzer
deshalb mit den gewohnten Befehlen „cd Verzeichnisname“in beliebige Verzeichnisse
wechseln und sich beispielsweise mit „ls -la“den Inhalt des aktuellen Verzeichnisses
anzeigen lassen.
Unter USS ist ein Java Development Kit (JDK) verfügbar (auf dem Server in Leipzig in der
Version 1.1.8), über das Java Programme kompiliert und ausgeführt werden können. Die
Syntax unterscheidet sich nicht von einem anderen Unix System, ein Programm wird mit
javac Programmname
kompiliert und mittels
java Programmname
ausgeführt. Der Compiler auf dem OS/390 Betriebssystem bietet mehrere Optionen, um
Java Programme auszuführen:
•
Java Klassen können interpretativ abgearbeitet werden. Dies war bei der Einführung von
Java der Standard und ist in einzelnen Fällen auch heute noch sinnvoll (z.B. bei sehr
kurzer Ausführungszeit des Programms oder sehr sequentiellem Programmablauf).
•
Seit geraumer Zeit wird aber für Java Programme auf allen Betriebssystemen ein sog.
Just In Time Compiler (JIT) verwendet. Dies ist auch die Standardeinstellung des OS/390
Java Compilers. Dabei wird der Java Bytecode beim Start einer Applikation mit ähnlichen
Verfahren wie bei Compilern anderer Programmiersprachen optimiert und kompiliert. Der
erzeugte Maschinencode wird dann ausgeführt und evtl. zur erneuten Verwendung
gecached. Der höhere Aufwand durch den zusätzlichen Schritt der Kompilierung lohnt
sich vor allem bei größeren Programmen wegen der deutlich kürzeren Ausführungszeit.
OS/390 Systemumgebung
•
17
Die dritte Möglichkeit, die es bei anderen Betriebssystemen nicht gibt, ist, den High
Performance Compiler for Java (HPCJ) zu verwenden. Dabei wird der Java Bytecode vor
der eigentlichen Ausführung spezifisch für OS/390 statisch kompiliert und in einem
Dataset gespeichert. Dadurch kann mehr Zeit für die Optimierung verwendet werden und
zur Ausführungszeit muss keine Java Virtual Machine mehr gestartet werden. Aus
diesen Gründen erhält man eine bessere Performance als bei der Verwendung des JIT
Compilers. Allerdings gilt dies nur für Anwendungen, die bestimmte Anforderungen (z.B.
kurze Ausführungszeit, möglichst nur ein Thread) erfüllen. Außerdem gibt es keinen
Servletsupport und die Java Spezifikation unterscheidet sich vom Sun Standard. Ab der
Version 2 des JDKs soll die Verwendung des HPCJ unnötig sein, da dort der neue JIT
Compiler ähnlich performant wie der HPCJ sein soll [ OLI ].
In der Diplomarbeit wird ausschließlich der JIT Compiler verwendet.
4.3.4 Websphere
Um bereits bestehende Daten und Anwendungen an das Internet anzubinden, wird eine
Möglichkeit zur Anzeige dynamischer HTML Seiten benötigt. Die zwei wichtigsten
Schnittstellen dafür sind das Common Gateway Interface (CGI) und (die in dieser
Diplomarbeit verwendeten) Java Servlets. Java Servlets haben einige Vorteile gegenüber
CGI Skripten [ HER ]:
•
Servlets sind vollwertige Java-Programme; sie verfügen über alle Java APIs,
einschließlich JDBC und SQLJ.
•
Im Gegensatz zu CGI erfordert das Java Servlet nur Light Weight Context Switches.
Daraus resultiert ein deutlich besseres Leistungsverhalten.
•
Da das Servlet im Hauptspeicher verbleibt, können Verbindungen (Connections) zur
Datenbank offen gehalten werden. Ein Servlet kann einen gemeinsamen Vorrat (Pool)
an Datenbankverbindungen verwalten, und diesen je nach Bedarf einzelnen
konkurrierenden Benutzern zuordnen. Dieses sog. Connection Pooling verbessert die
Antwortzeit des Servlets, da der Verbindungsaufbau durchaus länger (1-2 Sek. sind
realistische Werte) als die Ausführung des SQL Statements dauern kann. Einige JDBC
Treiber können nur wenige Verbindungen gleichzeitig offen halten und wären ohne
Connection Pooling auf sehr wenige, parallele Benutzer beschränkt [ TUR ].
•
Ein Servlet kann Objekte und Daten während einer Sitzung speichern, ohne dass diese,
wie bei CGI Skripten, in der HTTP Anfrage übergeben werden müssten.
•
Leistungsfähiges Fehler- und Type-Checking.
•
Umfangreiche (Remote-) Debugging Möglichkeiten.
Zur Ausführung der Servlets wird zusätzlich zum HTTP Server (der die statischen HTML
Anfragen beantwortet) ein Servlet Container (Laufzeitumgebung) benötigt. Alle Servlets
werden innerhalb des Servlet Containers ausgeführt. Üblich ist eine Bündelung des HTTP
Servers und des Servlet Containers zu einem Web Application Server (s. Abbildung 4).
Dabei stellt der HTTP Server anhand der URL fest, ob es sich um eine statische Anfrage
handelt, die er selbst beantwortet, oder eine dynamische, die er an den Servlet Container
weiterleitet. Der Web Application Server arbeitet meistens mit einem Backendsystem (im
Fall dieser Diplomarbeit eine DB2 Datenbank) zusammen. Der Servlet Container von IBM
für das OS/390 Betriebssystem heißt Websphere und ist in der Standardkonfiguration mit
OS/390 Systemumgebung
18
Abbildung 4 - Web Application Server auf OS/390
dem IBM HTTP Server als Web Application Server gebündelt. Es kann aber auch ein
anderer HTTP Server, wie z.B. Apache, eingebunden werden. Außerdem existieren
Application Server von Drittanbietern (z.B. Weblogic von der Firma BEA), die ausgezeichnet
mit dem OS/390 Betriebssystem zusammenarbeiten. Websphere läuft unter den USS und
benutzt das HFS um Daten zu lesen bzw. zu schreiben.
Die auszuführenden Java Servlets werden üblicherweise in dem Servletverzeichnis
unterhalb des Websphereverzeichnisses abgelegt (vgl. Kapitel 6.4.2.2). Weiterführende
Informationen über Web Application Server bzw. Websphere sind in [ HER ] zu finden.
Konfiguration der OS/390 Systemumgebung
19
5. Konfiguration der OS/390
Systemumgebung
In diesem Kapitel wird die Konfiguration des OS/390 Servers erklärt. Da zum Zeitpunkt der
Diplomarbeit kein zweiter OS/390 Server zur Verfügung stand, wurde die Konfiguration
direkt auf dem „Produktionssystem“durchgeführt. Auf dem Server lief parallel der
Praktikumbetrieb. Dabei wurde z.B. Websphere verwendet. Der fehlerfreie Betrieb des
Systems musste deshalb während der Konfiguration gewährleistet werden.
Da Fehler in einzelnen Konfigurationsschritten nicht ausgeschlossen werden können, ist die
ständige Sicherung aller geänderten Dateien und Datasets unabdingbar.
5.1 JDBC Zugriff aus einem Java Programm auf DB2
Zuerst wird die Produktionsumgebung genauer erläutert. Auf dem OS/390 Server läuft ein
Java Compiler, der so konfiguriert werden muss, dass mittels JDBC auf eine DB2
Datenbank zugegriffen werden kann (s. Abbildung 5).
Ein typischer Programmaufruf, der einen Datenbankzugriff enthält, läuft folgendermaßen
ab:
1. Das Java Programm wird mit dem Kommando java Programmname gestartet.
2. Das Programm reagiert auf evtl. zu tätigende Benutzereingaben.
3. Der Drivermanager lädt den angegebenen Treiber.
4. Das Programm stellt mit Hilfe der JDBC Treiber eine Verbindung zu DB2 her. Bei einem
Remotezugriff wird die Authentifizierung auf dem OS/390 Server von der Distributed
Data Facility (DDF) übernommen [ ALM ]. Dann wird die Verbindung zur DB2 Datenbank
aufgebaut.
5. Die SQL Anfrage wird an DB2 gestellt.
6. Das Programm gibt die erhaltenen Daten aus.
Konfiguration der OS/390 Systemumgebung
20
Abbildung 5 - Ablauf eines JDBC Zugriffs auf DB2 unter OS/390 [ KO3 ]
5.1.1 Konfiguration von DB2 für den JDBC Zugriff aus einem Java
Programm
Die Konfiguration von DB2 erfolgt an Hand der Beschreibung in [ KO1 ]. Um die oben
beschriebene Funktionalität zu erreichen, müssen einige DB2 Konfigurationsdateien
angepasst werden. Die Änderungen werden für jede Datei in einem eigenen Abschnitt
erläutert. Alle Konfigurationsdateien sind auf der CD im Verzeichnis /konfig gespeichert.
In den folgenden Kapiteln werden diese Konfigurationsschritte durchgeführt:
•
db2jdbc.cursors Datei anpassen
•
Call Level Interface Konfigurationsdatei anpassen
•
.profile Datei anpassen
•
GRANT Statement ausführen um die Zugriffsrechte entsprechend zu setzen
5.1.1.1 db2jdbc.cursors Datei
/konfig/db2jdbc.cursors) Datei wird festgelegt,
In der db2jdbc.cursors (
wieviele Cursor JDBC benutzen kann und welche Eigenschaften sie haben. Jeder von
einem JDBC Zugriff zurückgegebene Resultset benötigt einen Cursor. Die Anzahl der
Konfiguration der OS/390 Systemumgebung
21
Cursor legt also die max. Anzahl gleichzeitig zu beantwortender Anfragen fest. Ein Cursor
mit der Eigenschaft „hold“bleibt nach einem Commit oder Rollback offen. Die
Defaulteinstellung der DB2 Datenbank war, dass jeder Cursor nach einem Commit oder
Rollback geschlossen wird („no-hold“). Mit der installierten Version 5 von DB2 darf die
maximale Anzahl von 100 Cursorn nicht überschritten werden. Deshalb wird die Anzahl auf
jeweils 10 Cursor mit „no-hold“(s. Abbildung 6, Zeile 1-10) und 10 mit „hold“(s. Abbildung
6, Zeile 11-20) Attribut begrenzt.
(1)cursor=DB2OS390NOHOLD001:nohold
(2)cursor=DB2OS390NOHOLD002:nohold
(3)cursor=DB2OS390NOHOLD003:nohold
(4)cursor=DB2OS390NOHOLD004:nohold
(5)cursor=DB2OS390NOHOLD005:nohold
(6)cursor=DB2OS390NOHOLD006:nohold
(7)cursor=DB2OS390NOHOLD007:nohold
(8)cursor=DB2OS390NOHOLD008:nohold
(9)cursor=DB2OS390NOHOLD009:nohold
(10)cursor=DB2OS390NOHOLD010:nohold
(11)cursor=DB2OS390HOLD001:hold
(12)cursor=DB2OS390HOLD002:hold
(13)cursor=DB2OS390HOLD003:hold
(14)cursor=DB2OS390HOLD004:hold
(15)cursor=DB2OS390HOLD005:hold
(16)cursor=DB2OS390HOLD006:hold
(17)cursor=DB2OS390HOLD007:hold
(18)cursor=DB2OS390HOLD008:hold
(19)cursor=DB2OS390HOLD009:hold
(20)cursor=DB2OS390HOLD010:hold
Abbildung 6 - /usr/lpp/db2/db2510/classes/db2jdbc.cursors
/konfig/db2jdbc.cursors
Konfiguration der OS/390 Systemumgebung
22
5.1.1.2 Call Level Interface Konfigurationsdatei
(1); DB2 CLI configuration
(2);
(3); This is a comment line
(4);
(5); COMMON section for all subsystems
(6)[COMMON]
(7); DBA1 is our example DB2 subsystem
(8)MVSDEFAULTSSID=DBA1
(9); Configuration of our example DB2 subsystem
(10)[DBA1]
(11);MVSATTACHTYPE can be RRSAF or CAF
(12)MVSATTACHTYPE=CAF
(13)PLANNAME=DSNACLI
Abbildung 7 - /usr/lpp/db2/db2510/dsnaoini
/konfig/dsnaoini
In der Konfigurationsdatei des DB2 Call Level Interface (CLI) muss die Subsystem ID von
DB2 angepasst werden (s. Abbildung 7, Zeile 8). Dieser Wert ist installationsspezifisch und
für diesen OS/390 Server „DBA1“. Beim DB2 CLI handelt es sich um eine C/C++ API die
Funktionen zur Verarbeitung von dynamischen SQL Statements zur Verfügung stellt
[ CAL ]. Diese Schnittstelle ist produktspezifisch und wird vom OS/390 JDBC API Connector
benutzt um die SQL Statements an DB2 weiterzuleiten. Üblicherweise implementiert jedes
DBMS ein CLI, das dann von entsprechenden Connectoren verwendet wird.
5.1.1.3 .profile Datei
Nach diesen Anpassungen ist JDBC nun fertig eingerichtet. Um es aus Java Programmen
benutzen zu können, müssen noch einige Umgebungsvariablen exportiert werden. Am
/konfig/.profile) Datei
besten werden die Exportstatements in die .profile (
des entsprechenden Benutzers oder die Default .profile Datei eingefügt. Bei der
.profile Datei handelt es sich um eine Batchdatei, die beim Login des Benutzers
ausgeführt wird.
Konfiguration der OS/390 Systemumgebung
23
(1)export
(2)export
(3)export
(4)export
STEPLIB=DSN510.SDSNLOAD:DSN510.SDSNEXIT:$STEPLIB
PATH=$PATH:/usr/lpp/db2/db2510/bin
LIBPATH=$LIBPATH:/usr/lpp/db2/db2510/lib:.
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:
/usr/lpp/db2/db2510/lib
(5)CLASSPATH=$CLASSPATH:
/usr/lpp/db2/db2510/classes/db2jdbcclasses.zip
(6)CLASSPATH=$CLASSPATH:.
(7)export CLASSPATH
(8)export DSNAOINI=/usr/lpp/db2/db2510/dsnaoini
(9)export JAVA_HOME=/usr/lpp/java/J1.1
Abbildung 8 - /u/stefanm/.profile
/konfig/.profile
In den Exportstatements werden die Pfade zu den JDBC Treiberklassen und DLLs (s.
Abbildung 8, Zeile 1-5) gesetzt. Außerdem wird die zu verwendende CLI
Konfigurationsdatei (s. Abbildung 8, Zeile 8) angegeben.
5.1.1.4 GRANT Statement ausführen
Abschließend wird noch ein vorgegebenes SQL Statement ausgeführt, um allen Benutzern,
die DB2 Zugriffsrechte besitzen, die Nutzung von JDBC durch Gewährung der benötigten
zusätzlichen Rechte für den CLI Plan DSNACLI zu ermöglichen (s. Abbildung 9). Zur
Ausführung wird das bereits erwähnte ISPF Subsystem SPUFI benutzt. Die Ausführung von
SQL Statements in SPUFI ist in [ TU1 ] sehr detailliert beschrieben:
GRANT EXECUTE ON PLAN DSNACLI TO PUBLIC
Abbildung 9 - GRANT Statement
Damit auch über das Internet JDBC benutzt werden kann, muss unbedingt die Distributed
Data Facility (DDF) gestartet sein. Auf dem OS/390 Server war dies bereits der Fall (vgl.
Abbildung 5 auf Seite 6).
5.1.2 Beispielprogramm von IBM kompilieren und ausführen
Nachdem alle Anpassungen vorgenommen wurden, kann mit dem vorinstallierten
Beispielprogramm (s. Abbildung 10) ein erster Test der Installation durchgeführt werden.
Konfiguration der OS/390 Systemumgebung
(1)import java.sql.*;
(2)class sample01 {
(3)
static {
(4)
try {
(5)
//register DB2 for OS/390 driver withDriverManager
(6)
Class.forName("ibm.sql.DB2Driver");
(7)
} catch (ClassNotFoundException e) {
(8)
e.printStackTrace();
(9)
}
(10)
}
(11)
(12)
public static void main(String argv[]) {
(13)
try {
(14)
System.out.println("**** JDBC Entry within class
sample01.");
(15)
String url = "jdbc:db2os390:DBA1";
(16)
Connection con =
DriverManager.getConnection(url);
(17)
System.out.println("**** JDBC Connection to DB2
for OS/390.");
(18)
// Create the Statement
(19)
Statement stmt = con.createStatement();
(20)
System.out.println("**** JDBC Statement
Created");
(21)
// Execute a Query and generate a ResultSet
(22)
// The Query is a Select from SYSIBM.SYSTABLES
(23)
ResultSet rs = stmt.executeQuery("SELECT * FROM
SYSIBM.SYSTABLES");
(24)
System.out.println("****JDBC Result Set
Created");
(25)
// Print all of the table names to sysout
(26)
while (rs.next()) {
(27)
String s = rs.getString(1);
(28)
System.out.println("Table NAME = " + s);
(29)
}
(30)
System.out.println("**** JDBC Result Set output
completed");
(31)
// Close the statement
(32)
stmt.close();
(33)
System.out.println("**** JDBC Statement Closed");
(34)
(35)
// Close the connection
(36)
con.close();
(37)
System.out.println("**** JDBC Disconnect from DB2
for OS/390.");
(38)
(39)
} catch( Exception e ) {
(40)
e.printStackTrace();
(41)
}
(42)
(43)
System.out.println("**** JDBC Exit from class
sample01 - no Errors.");
(44)
}
Abbildung 10 - sample01.java
/java/sample01.java
24
Konfiguration der OS/390 Systemumgebung
25
Dafür muss das Java Programm kompiliert und ausgeführt werden. Das Programm stellt
eine Verbindung zum DB2 Subsystem her und greift auf eine Systemtabelle zu, die bei
jeder DB2 Installation vorhanden ist. Anhand dieses kurzen und einfachen
Beispielprogramms wird erklärt, wie ein JDBC Aufruf funktioniert. Dazu wird Schritt für
Schritt erläutert, was beim Ausführen des Quellcodes (s. Abbildung 10) passiert:
Zuerst müssen alle für JDBC Zugriffe benötigte Klassen importiert werden (Zeile 1).
Der richtige Treiber für einen Zugriff auf die DB2 Datenbank vom Betriebssystem OS/390
aus wird geladen (Zeile 4-11).
Aus den vorhergehenden Installationen und Konfigurationen ist bekannt, dass der Zugriff
auf das DB2 Subsystem mit der SSID DBA1 stattfindet. Daraus und aus der Art des Zugriffs
ergibt sich die in Zeile 16 gesetzte URL für das DB2 Datenbanksystem.
Eine Verbindung mit dem vorher geladenen Treiber und der erzeugten URL wird hergestellt
(Zeile 17).
Wenn bis jetzt keine Exception aufgetreten ist, wird das SQL Statement ausgeführt. Dazu
wird ein Instanz der Klasse Statement erzeugt, die von der zuvor erzeugten Verbindung
geliefert wird (Zeile 20).
Durch Aufruf der executeQuery Methode der Statementklasse mit dem SQL Statement
als Parameter, in unserem Fall der erwähnte Zugriff auf die Systemtabelle, wird der
Datenbankzugriff durchgeführt (Zeile 24).
Jetzt werden die erhaltenen Ergebnisse ausgegeben, hier die Namen aller Tabellen in der
DB2 Datenbank (Zeile 27-30).
Um die verwendeten Ressourcen wieder freizugeben, werden das Statement und die
Connection geschlossen. Das Testprogramm wurde fehlerfrei ausgeführt (Zeile 33-45).
Die Ausgabe für das Programm auf dem OS/390 Server ist in Abbildung 11 zu sehen.
Konfiguration der OS/390 Systemumgebung
26
STEFANM : /usr/lpp/db2/db2510/samples/sample01 >java sample01
**** JDBC Entry within class sample01.
**** JDBC Connection to DB2 for OS/390.
**** JDBC Statement Created
**** JDBC Result Set Created**** JDBC Result Set Created
Table NAME = SYSCOPY
Table NAME = SYSCOLAUTH
Table NAME = SYSCOLUMNS
Table NAME = SYSFOREIGNKEYS
Table NAME = SYSINDEXES
Table NAME = SYSINDEXPART
...
...
**** JDBC Result Set output completed
**** JDBC Stetement Closed
**** JDBC Disconnect from DB2 for OS/390.
**** JDBC Exit from class sample01 - no Errors.
Abbildung 11 - Ausgabe des JDBC Testprogramms auf dem OS/390 Server
Durch die korrekte Ausführung des Programms wurde verifiziert, dass JDBC Zugriffe von
lokal ausgeführten Java Programmen aus möglich sind.
5.2 JDBC Zugriff aus einem Java Servlet
Mit der im vorigen Kapitel beschriebenen Konfiguration kann bereits eine Java Applikation
mit Textinterface SQL Anfragen an die Datenbank stellen. Um der zunehmenden
Bedeutung des Internets und e-commerce Rechnung zu tragen, soll aber auch der Zugriff
über das Internet auf die Datenbank ermöglicht werden. Mit Java Servlets können
dynamische Webseiten erstellt werden, die auch bei mehreren tausend Zugriffen pro
Sekunde akzeptable Antwortzeiten liefern. Aus den bereits genannten Gründen (vgl. auch
Kapitel 4.3.4) sind Java Servlets sehr gut für zugriffsintensive Internetprojekte geeignet. Da
alle Anwendungen auf einem (2-Tier Architektur) oder zwei (3-Tier Architektur) Servern
ausgeführt werden, sind einige Sicherheitsaspekte einfacher zu handhaben als bei
Technologien, bei denen auf der Klientenseite Programme bzw. Programmteile ausgeführt
werden, wie z.B. Java Applets.
Konfiguration der OS/390 Systemumgebung
27
Websphere Application Server
Websphere
Servlet
Container
Abbildung 12 - Websphere und DB2 auf OS/390 [ AND ]
In Abbildung 12 wird die Konfiguration der verwendeten Subsysteme auf dem OS/390
Server detailliert dargestellt. Um HTTP Anfragen zu beantworten, läuft auf dem OS/390
Server der IBM HTTP Server, als Servlet Container wird der Websphere Applikationsserver
Version 1.2 verwendet. Über einen JDBC Connector wird auf eine DB2 Datenbank
zugegriffen.
Eine typischer Servletaufruf sieht dann folgendermaßen aus:
1. Der Klient stellt eine HTTP Anfrage.
2. Der Webserver bekommt die Anfrage und stellt fest, dass es sich um einen ServletAufruf handelt.
3. Die Servletengine (Websphere) wird gestartet und ruft das angeforderte Servlet auf
4. Das Servlet reagiert auf die Anfrage und stellt mit Hilfe des JDBC Connectors eine SQL
Anfrage an die Datenbank (für den Programmierer transparent und damit analog zum
Javaprogramm).
5. Die Datenbank liefert das Ergebnis zurück.
6. Das Servlet bereitet die Daten auf und bettet sie in HTML Code ein.
7. Websphere stellt die vom Servlet erzeugte (HTML-) Antwortseite dar.
5.2.1 Konfiguration von Websphere für den JDBC Zugriff aus einem
Java Servlet
Bevor mit Servlets auf Daten in der DB2 Datenbank zugegriffen werden kann, muss
Websphere in der Lage sein, die Datenbank zu finden und mit ihr zu kommunizieren. Die
Konfiguration von Websphere wurde an Hand der Beschreibung in [ WE1 ] durchgeführt.
In einzelnen müssen folgende Dateien angepasst werdent
•
was.conf Datei
Konfiguration der OS/390 Systemumgebung
•
Websphere Startskript
•
httpd.envvars Datei
28
5.2.1.1 was.conf Datei
Damit Websphere den JDBC Connector verwenden kann, wird in der Konfigurationsdatei
/konfig/was.conf) der Pfad zu den JDBC
was.conf (s. Abbildung 13,
Treiberdateien von DB2 an die Classpath Eigenschaft angehängt (Zeile 8 und 9). Zusätzlich
benötigt Websphere noch den Pfad zu den DLLs (für den JDBC Connector), er wird der
Libpath Eigenschaft hinzugefügt (Zeile 14).
(1)ncf.jvm.classpath=/web/serv1/ApplServer/lib/ibmwebas.jar:
(2)
/web/serv1/ApplServer/lib/jst.jar:
(3)
/web/serv1/ApplServer/lib/jsdk.jar:
(4)
/web/serv1/ApplServer/lib/x509v1.jar:
(5)
/web/serv1/ApplServer/lib/xml4j.jar:
(6)
/web/serv1/ApplServer/lib:
(7)
/web/serv1/ApplServer/web/classes:
(8)
/usr/lpp/java/J1.1/lib/classes.zip:
(9)
/usr/lpp/db2/db2510/classes/db2jdbcclasses.zip
(10)
(11)ncf.jvm.libpath= /usr/lpp/java/J1.1/lib:
(12)
/usr/lpp/java/J1.1/lib/mvs/native_threads:
(13)
/web/serv1/ApplServer/lib:
(14)
/usr/lib:/usr/lpp/db2/db2510/lib
Abbildung 13 - /web/serv1/ApplServer/properties/was.conf
/konfig/was.conf
5.2.1.2 Websphere Startskript
Das Websphere Startskript (
/konfig/wasStartskript.txt) musste ebenfalls
geändert werden. Da dieser Teil der Konfiguration sehr schwierig war, wurde das StandardStartskript kopiert und umbenannt. Immer wenn es Fehlkonfigurationen gab, konnte dann
auf das vorherige Startskript zurückgegriffen werden.
(1)//********************************************************
(2)//STEPLIB DD DSN=DSN510.SDSNLOAD,DISP=SHR
(3)//
DD DSN=DSN510.SDSNEXIT,DISP=SHR
(4)//SYSIN
DD DUMMY
(5)//OUTDSC
OUTPUT DEST=HOLD
(6)//* ------------------ *
(7)//* Starting variables *
(8)//* ------------------ *
(9)//WENV
DD PATH='/web/serv1/httpd.envvars_X'
Abbildung 14 - Websphere Startskript
/konfig/wasStartskript.txt
Letztendlich waren die notwendigen Änderungen das Einfügen der STEPLIP Variable (s.
Abbildung 14, Zeile 2) und das Setzen des Dateinamens für die Umgebungsvariablen auf
httpd.envvars_X (s. Abbildung 14, Zeile 9).
Konfiguration der OS/390 Systemumgebung
29
5.2.1.3 httpd.envvars Datei
Die Datei httpd.envvars (
/konfig/httpd.envvars_X) enthält die
Umgebungsvariablen für den Webserver. Wie bereits in Kapitel 5.1.1.3 für die .profile Datei
eines Benutzers, werden auch hier die Umgebungsvariablen für die JDBC Treiberklassen
und DLLs (s. Abbildung 15, Zeile 1-4) gesetzt. Außerdem wird die zu verwendende CLI
Konfigurationsdatei (s. Abbildung 15, Zeile 5) angegeben.
(1)LIBPATH=/usr/lpp/internet/bin:/usr/lpp/internet/sbin:
/usr/lpp/ldap/lib:
/usr/lpp/java/J1.1/lib/mvs/native_threads:
/usr/lpp/db2/db2510/lib
(2)LD_LIBRARY_PATH=/usr/lpp/db2/db2510/lib:$LD_LIBRARY_PATH
(3)CLASSPATH=.:/usr/lpp/internet/server_root/CAServlet:
/usr/lpp/java/J1.1/lib/classes.zip:
/usr/lpp/db2/db2510/classes/db2jdbcclasses.zip
(4)STEPLIB=DSN510.SDSNLOAD:DSN510.SDSNEXIT
(5)DSNAOINI=/usr/lpp/db2/db2510/dsnaoini
Abbildung 15 - /web/serv1/httpd.envvars_X
/konfig/httpd.envvars_X
Die Konfiguration von Websphere war sehr zeitaufwändig, da eine relativ frühe Version
(1.2) von Websphere auf dem OS/390 Server installiert war. Außerdem war die
Webanbindung von DB2 mit Servlets noch recht neu, deshalb gab es auch wenig Erfahrung
mit der hier geschilderten Software Konstellation.
Nach der erfolgreichen Konfiguration kann die Funktionalität mit Hilfe eines HelloWorld
/java/SMJDBCTestServlet.java) verifiziert werden. Der JDBC Zugriff
Servlets (
zum Testen läuft vollkommen analog zum HelloWorld Java Programm
(
/java/SMJDBCTestPrg.java) ab. Das Servlet produziert nur noch einen HTML
Rahmen um die Programmausgaben.
Entwicklungsumgebung auf der Workstation
30
6. Entwicklungsumgebung auf der
Workstation
Grundsätzlich kann die Entwicklung der Java Programme auch auf dem OS/390 Server,
z.B. unter Benutzung des ISPF Texteditors, durchgeführt werden. Da die Entwicklung auf
einer Workstation mit einer modernen Integrated Development Environment (IDE) viele
Vorteile für den Programmierer bietet, wurde für diese Diplomarbeit alternativ Visual Age for
Java von IBM, sowie Eclipse verwendet. Es handelt sich dabei um IDEs für Java, die
gegenüber der OS/390 Entwicklungsumgebung viele Vorteile haben. Einige der wichtigsten
sind:
1. Durch GUI basierte Entwicklung werden Klassen- und Projektstrukturen übersichtlich
dargestellt.
2. Die IDE bietet Hilfen zum Refactoring an, z.B. automatisches Umbenennen einer Klasse
und aller Referenzen auf sie.
3. Nutzung eines Debuggers um Laufzeitfehler aufzuspüren.
4. Integration eines Webservers und damit die Möglichkeit, Servlets und JSP Seiten zu
debuggen.
5. Einfache Einbindung vieler Tools, wie z.B. CVS (Concurrent Version System) zur
Versionskontrolle, UML Entwicklungsumgebungen, ... .
6. Die Möglichkeit, verschiedene JDKs für verschiedene Projekte zu benutzen und ein
Projekt zu Testzwecken mit verschiedenen JDKs zu kompilieren.
7. Integrierte Hilfe, sowohl zum vom Programmierer erstellten Quellcode (Highlighting von
Variablen und Anzeige des Variablentyps), als auch zum JDK.
Da nicht alle Features auf beide IDEs zutreffen, folgt ein kurzer Vergleich der
Entwicklungsumgebungen.
6.1 Eclipse vs. Visual Age for Java
Visual Age, aktuell in der Version 4 verfügbar, wurde von IBM entwickelt. Als großer
Pluspunkt von VisualAge for Java ist sicherlich die integrierte Websphere Testumgebung zu
sehen. Servlets, JavaBeans und JSPs lassen sich sofort in der Entwicklungsumgebung
ausführen und debuggen. Der eingebaute inkrementelle Compiler ermöglicht sog. „HotCode
Replace“: Der Quelltext lässt sich bereits im laufenden Betrieb modifizieren und erneut
testen, ohne dass ein Neustart erforderlich ist. Vor allem bei der Entwicklung von Servlets
und EJBs ist dies ein großer Vorteil, da das zeitaufwändige Starten des Web Application
Servers entfällt.
Speziell für die Entwicklung von Anwendungen für das OS/390 Betriebssystem ist die
Unterstützung des Common Connector Framework (CCF) und die damit verbundene hohe
Verfügbarkeit von Connectoren für unterschiedliche Backendsysteme wichtig. Das CCF
stellt eine gemeinsame Infrastruktur für die einzelnen Connectoren zur Verfügung.
Entwickelt wurde es von IBM, derzeitig entwickelt Sun es unter dem Namen J2EE
Connector Architecture (JCA) zu einer Standardschnittstelle der Java 2 Enterprise-Edition.
Entwicklungsumgebung auf der Workstation
31
Als zusätzlichen Vorteil stellt VisualAge eine umfangreiche Menge an Code-Generatoren
zur Verfügung, angefangen bei der Erstellung von Attributen, Methoden oder Klassen bis
hin zur Entwicklung von grafischen Benutzungsoberflächen, Servlets oder EJBs. Der
Entwickler wird durch eine Reihe von dialogbasierten Assistenten unterstützt. Auch die
Anbindung an andere Programmiersprachen, wie beispielsweise C++, oder die Integration
von Backend-Systemen läuft durch die Verwendung von entsprechenden Assistenten
weitestgehend automatisiert ab [ SCH ].
Trotz dieser Vorteile hat die Entwicklungsumgebung auch einige Schwächen, die den
Einsatz in der Praxis manchmal etwas schwierig gestalten. Als Erstes ist hier zu kritisieren,
dass von VisualAge 4.0 immer noch das bereits veraltete JDK 1.2.2 unterstützt wird, obwohl
von Sun bereits neuere Versionen des JDK zur Verfügung stehen. Außerdem ist der EJBStandard 1.1 noch nicht vollständig implementiert [ SCH ]. Ein weiterer Nachteil ist, dass in
Visual Age alle Java Dateien in einem Repository abgelegt werden, das nicht dateibasiert
ist. Zwar kann dadurch die Versionierung der Java Klassen sehr fein abgestimmt werden,
allerdings müssen andere Ressourcen anderweitig verwaltet werden. In der Praxis wird
deshalb trotz der Nachteile (keine vollständige Integration in VA, evtl. auch doppelte
Datenhaltung) oft auf externe Systeme, wie z.B. CVS zurückgegriffen.
Allerdings enden mit der Version 4 sämtliche Weiterentwicklungen an VisualAge for Java.
IBM wird in Zukunft alle Java Entwicklungsumgebungen auf Basis des Eclipse Frameworks
erstellen [ WE2 ]. Es beinhaltet neben einem komfortablen Text Editor mit Syntax
Highlighting, Such- und Ersetzungsfunktionen auch die Möglichkeit zur Anbindung an
gängige Software Configuration Management (SCM)-Systeme, wie z.B. CVS. Darüber
hinaus ist Eclipse so entwickelt, dass die verwendete Java-Laufzeitumgebung für jedes
Werkzeug bzw. jede Zielplattform unabhängig gewählt werden kann.
Ebenfalls interessant ist, dass Eclipse selbst in Java entwickelt wurde. Daraus ergeben sich
einige Vorteile, wie beispielsweise die Unabhängigkeit von der Zielplattform. Durch die
Verwendung einer eigens entwickelten Klassenbibliothek für die GUI Programmierung
(Standard Widget Toolkit) wurden die oft bei Java Programmen entstehenden Performance
Probleme elegant umgangen.
Um die Entwicklung und Integration von Zusatzwerkzeugen durch unabhängige Hersteller
noch schneller voranzutreiben, hat IBM das Framework als freie Software zur Verfügung
gestellt. Das zugehörige Open Source Projekt heißt Eclipse.org, weiterführende Information
findet man auf der Internetseite [ ECL ]. Dort kann die Entwicklungsumgebung kostenlos
herunterladen werden. Dass dieses Konzept aufgeht, scheint die schnell wachsende
Nutzerzahl von Eclipse zu bestätigen. Es befinden sich bereits zahlreiche Unterprojekte in
der Entwicklung, z.B. Entwicklungsumgebungen für C/C++ und Cobol [ ECL ]. Außerdem
sind viele Plugins erhältlich. Die Application Server BEA Weblogic, IBM Websphere und
der, in der Diplomarbeit auf der Workstation verwendete, Tomcat können mit Hilfe von
Plugins integriert werden. Da Eclipse als OpenSource Software verfügbar ist, bietet es sich
vor allem für den Praktikumbetrieb an.
6.2 Installation von VisualAge for Java und Eclipse
Die Arbeitsumgebung ist bei beiden IDEs sehr ähnlich. Bei der Entwicklung von Java
Programmen wird der Code komplett in der IDE ausgeführt. Soll ein Servlet entwickelt
werden, gibt es einige Unterschiede (s. Abbildung 16). Bei beiden IDEs wird ein Web
Application Server integriert, der das Ausführen und Debuggen der Servlets ermöglicht. Bei
Entwicklungsumgebung auf der Workstation
32
Visual Age ist die Websphere Testumgebung bereits enthalten, es wird keine separate
Webserver Installation benötigt. Eclipse verlangt dagegen eine vollständige Installation von
Apache Tomcat, der dann über ein Plugin den Servlet Code ausführt. Die Websphere
Testumgebung bzw. Tomcat erfüllen dann dieselben Aufgaben wie Websphere auf dem
OS/390 Server (bereits erläutert in Kapitel 4.3.4). Der Zugriff auf die OS/390 Datenbank
findet bei beiden IDEs mit Hilfe des Hit Treibers oder dem IBM Windows JDBC Treiber in
Verbindung mit DB2Connect statt. Über das Internet kann dann mit dem TCP/IP Protokoll
auf die DB2 Datenbank zugegriffen werden.
Abbildung 16 - JDBC Zugriff aus einem Servlet in den Entwicklungsumgebungen auf der
Workstation
Da die Installationsanleitung in Form eines Tutorials [ TU3 ] für den Praktikumbetrieb
vorliegt, wird hier nicht näher auf die einzelnen Installationsschritte eingegangen. Die
Tutorials sind im Anhang aufgeführt. Allerdings ist anzumerken, dass die Installation ohne
größere Probleme ablief, sofern jeweils die richtigen Programmversionen verwendet
wurden.
Durch die Verwendung des gleichen JDKs (Version 1.1.8) auf der Workstation und auf dem
OS/390 Server kann sichergestellt werden, dass Programme, die auf der Workstation
fehlerfrei kompiliert werden, dies auch auf dem Mainframe tun. Es muss nur darauf
Entwicklungsumgebung auf der Workstation
33
geachtet werden, dass der für das Betriebssystem richtige JDBC Treiber eingebunden wird.
Mit den folgenden Programmen und Servlets wird darüber hinaus verifiziert, dass der, auf
einer Windows Workstation kompilierte, Java Bytecode auf dem OS/390 Server sofort
(ohne Neukompilierung) ausgeführt werden kann. In den beiden folgenden Kapiteln 6.3 und
6.4 wird zuerst der Ablauf eines JDBC Zugriffs und die verwendeten Komponenten erklärt.
Anschließend werden die technischen Details und die eigentliche Programmierung erläutert.
6.3 Zugriff von der Entwicklungsumgebung auf eine OS/390
Datenbank
Um auf einer Workstation zu programmieren und dabei die OS/390 Subsysteme zu
benutzen, werden Connectoren verwendet. IBM liefert nur einen JDBC API Connector für
DB2 auf Windows und OS/390. JDBC auf dem OS/ 390 Betriebssystem baut auf der
Distributed Relational Database Architecture (DRDA) auf. Dabei handelt es sich um auf der
OS/390 Seite verwendete Protokolle, die zur Verbindung von RDBMS verwendet werden
[ KO2 ]. Da der Windows Treiber DRDA nicht unterstützt, kann mit dem JDBC Connector
nicht ohne zusätzliche Software von einer Windows Workstation auf einen OS/390 Server
zugegriffen werden.
Abbildung 17 - JDBC Connectoren unter
Windows
Im Wesentlichen gibt es deshalb zwei Möglichkeiten, von einer Workstation mit JDBC auf
eine DB2 Datenbank zuzugreifen (s. Abbildung 17). Zum einen bietet IBM DB2Connect an.
Dabei handelt es sich um ein Tool das den Zugriff auf eine OS/390 Datenbank (unter
Verwendung des IBM Windows JDBC Connectors) ermöglicht. Zum anderen kann ein
JDBC Java Connector von einem Drittanbieter benutzt werden. In dieser Arbeit wird der von
Entwicklungsumgebung auf der Workstation
34
IBM empfohlene Treiber der Firma Hit benutzt. Die Verwendung sowie die Vor- und
Nachteile beider Möglichkeiten werden in den folgenden zwei Kapiteln näher erläutert. Die
Installation beider Möglichkeiten liegt ebenfalls als Tutorial vor [ TU2 ] [ TU3 ]. Eine weitere
Möglichkeit ist die Nutzung von SQLJ zum Datenbankzugriff. SQLJ greift auf die JDBC
Treiber (für den Programmierer transparent) zu, um in den Java Quellcode eingebettete,
statische SQL Statements mit einem Präprozessor zu überprüfen und zu kompilieren. Da es
sich um statische SQL Anweisungen handelt, ist SQLJ performanter als JDBC. SQLJ hat
jedoch Softwarevoraussetzungen, die in der derzeitigen Version des OS/390 Servers der
Universität Leipzig nicht gegeben sind.
6.3.1 DB2 Zugriff mit DB2Connect
Abbildung 18 - Zugriff auf eine OS/390 Datenbank mit DB2Connect [ KO4 ]
Um die bereits beschriebene Problematik mit DRDA zu umgehen, kann die Software
DB2Connect von IBM verwendet werden. Eine Workstation, auf der DB2Connect installiert
ist, ermöglicht den Zugang zu DB2 Datenbanken auf Servern mit folgenden
Betriebssystemen: MVS/ESA, OS/390, OS/400, VM, VSE, Windows NT, UNIX und OS/2
[ KO4 ]. Dabei wird von DB2Connect sozusagen ein Datenbankproxy emuliert, der die
Konvertierungen zwischen der Datenbank und den Klienten vornimmt. Dafür wird einmalig
zu jeder genutzten Datenbank eine Verbindung definiert. Darin wird das
Entwicklungsumgebung auf der Workstation
35
Serverbetriebssystem, der Servername bzw. die IP Adresse, der DB2 Subsystemname, das
verwendete Protokoll usw. gespeichert.
Die Klienten benutzen dann den IBM Windows JDBC Treiber und greifen damit auf eine in
DB2Connect definierte Verbindung zu. Für die Klienten ist DB2Connect transparent, d.h. für
den Klienten ist diese Verbindung nicht von einer direkten Verbindung zur Datenbank zu
unterscheiden. DB2Connect transformiert die SQL Anfragen in das entsprechende Format
für das entsprechende Betriebssystem und leitet die Anfrage dann weiter. Die Antwort vom
Server wird für den Klienten aufbereitet und dann weitergeleitet.
Für den Programmierer hat das den Vorteil, dass er mit einer einzigen Installation von
DB2Connect und dem IBM Windows JDBC Treiber auf DB2 Datenbanken auf den
verschiedensten Servern zugreifen kann. DB2Connect gibt es auch in der Enterprise
Edition. Sie wird auf einem DB2Connect Server installiert, über den Workstations ohne
eigene DB2Connect Installation auf OS/390 Datenbanken zugreifen können. Da bei dieser
Lösung auf dem Klienten und auf dem Server Typ 1 Connectoren verwendet werden, ist
sie sehr performant.
6.3.2 DB2 Zugriff mit Hit JDBC Treiber
Die Firma Hit bietet einen (kostenpflichtigen) JDBC Treiber an, mit dem auf DB2
Datenbanken auf OS/390 zugegriffen werden kann. Der Treiber ist vollständig in Java
programmiert und wird als jar-Datei in den Classpath eingebunden.
Zu der oben vorgestellten Variante mit DB2Connect ändert sich nur wenig. Da mit dem Hit
Treiber direkt auf die DB2 Datenbank zugegriffen wird, ändert sich die URL der Datenbank.
Der Vorteil des Hit Treibers ist, dass er sehr leicht mit den entwickelten Programmen
mitgeliefert werden kann und es praktisch keinen Installationsaufwand gibt. Wenn ein CVS
System verwendet wird, reicht es, bei richtiger Konfiguration, das entsprechende Projekt
aus dem CVS auszuchecken. Außerdem ist diese Lösung vollkommen
betriebssystemunabhängig. Es ist sogar möglich, auf dem OS/390 Server den Hit Treiber
zu verwenden. Aus Performancegründen ist dies aber nicht sinnvoll.
6.3.3 Test der Installation mit JUnit Tests
Um eine einfache Überprüfung der Installation der Entwicklungsumgebung und aller
benötigten Klassen zu ermöglichen, wird eine, zu diesem Zweck programmierte, JUnit
/java/TestInstall.java) eingesetzt, die mit jedem Connector eine
Testklasse (
Verbindung aufbaut und sofort wieder schließt. Dabei wird überprüft, ob die Verbindung
zustande kommt. Sollte einer oder beide Connectoren nicht funktionieren, wird eine
entsprechende Fehlermeldung ausgegeben. Vor allem für die Verwendung im Praktikum ist
diese Testklasse sehr nützlich, da dort regelmäßig Neuinstallationen von Studenten
durchgeführt werden und diese einfach und automatisch auf die korrekte Funktionalität
geprüft werden können.
Zum Verständnis der Testklasse wird kurz erläutert, wie ein JUnit Test aufgebaut ist. Für
eine umfangreichere Einführung in das JUnit Framework lohnt sich ein Blick auf die
Homepage von JUnit [ JUN ], speziell das Tutorial [ WES ] ist für Einsteiger sehr nützlich.
Entwicklungsumgebung auf der Workstation
36
Das JUnit Framework stellt einige Super-Klassen zur Verfügung. Für diesen Test ist nur die
Klasse TestCase von Bedeutung. Von den vererbten Methoden sind die assert
Methoden die Wichtigsten. Mit assert Funktionen werden Annahmen formuliert, die JUnit
automatisch verifizieren wird. In der Klasse TestInstall (s. Abbildung 19) wird damit z.B.
in Zeile 3 mit assertTrue geprüft, ob die Funktion connectionTest True zurückgibt
und gegebenenfalls eine entsprechende Fehlermeldung ausgegeben.
(1)public void testDrivers() {
(2) // Windows => teste beide Connectoren , hit + DB2Connect
(3) assertTrue(
(4)
"Hit Treiber funktioniert nicht!",
(5)
connectionTest(
(6)
"hit.db2.Db2Driver",
(7)
"jdbc:db2://jedi.informatik.unileipzig.de:446;rdbname=DBA1"));
(8)
assertTrue(
(9)
"DB2Connect funktioniert nicht",
(10)
connectionTest(
(11)
"COM.ibm.db2.jdbc.app.DB2Driver",
(12)
"jdbc:db2:DBA1"));
(13) }
(14) public boolean connectionTest(String driver, String url)
{
(15)
try {
(16)
Connection con;
(17)
Class.forName(driver);
(18)
con = DriverManager.getConnection(url, user,
password);
(19)
if (con == null)
(20)
return false;
(21)
else
(22)
con.close();
(23)
} catch (Exception e) {
(24)
e.printStackTrace();
(25)
return false;
(26)
}
(27)
return true;
(28) }
Abbildung 19 - TestInstall.java
/java/SMJDBCTestPrg.java
Beim Aufruf mit dem JUnit Framework werden in einer von TestCase abgeleiteten Klasse
(hier:TestInstall) alle Funktionen, deren Namen mit „test“beginnen, in einer zufälligen
Reihenfolge ausgeführt. Die grafische Oberfläche zeigt dann an, ob Tests fehlgeschlagen
sind und wenn ja, welche (s. Abbildung 20). Für zusätzliche Informationen kann eine vom
Programmierer vorgegebene, dynamisch erzeugte Fehlermeldung ausgegeben werden.
Wird die TestInstall Klasse mit JUnit ausgeführt, startet das Framework die Funktion
testDrivers. In testDrivers wird mit der Methode assertTrue überprüft, ob die
Funktion connectionTest True zurückliefert. Es werden einmal die entsprechenden
Parameter für den Hit Treiber und einmal für DBConnect übergeben. Die Funktion
Entwicklungsumgebung auf der Workstation
37
connectTest lädt jeweils den Treiber und macht eine Verbindung zur übergebenen URL
auf. Kann die Verbindung hergestellt werden, wird True zurückgegeben.
Abbildung 20 - Der JUnitinstallationstest war erfolgreich, erkennbar am
grünen Balken!
Sind alle Tests erfolgreich durchgelaufen, meldet sich JUnit mit einem grünen Balken (s.
Abbildung 20). Unter Eclipse ist das Ausführen des Tests besonders einfach, da dort JUnit
bereits integriert ist.
Entwicklungsumgebung auf der Workstation
38
6.4 Programmierung
6.4.1 HelloWorld Java Programm
1. // Treiber und URL an die Benutzerauswahl anpassen:
2. if (sDriver.equals("1")) {
3.
//OS/390
4.
Class.forName("ibm.sql.DB2Driver");
5.
// Verbindung herstellen
6.
con = DriverManager.getConnection("jdbc:db2os390:DBA1", user,
7.
password);
8. } else if (sDriver.equals("2")) {
9.
// Hit Connector
10.
Class.forName("hit.db2.Db2Driver");
11.
// Verbindung herstellen
12.
con = DriverManager.getConnection(
13.
"jdbc:db2://jedi.informatik.uni-leipzig.de:446;rdbname=DBA1",
14.
user,
15.
password);
16.} else if (sDriver.equals("3")) {
17.
// IBM Windows Connector
18.
Class.forName("COM.ibm.db2.jdbc.app.DB2Driver");
19.
// Verbindung herstellen
20.
con = DriverManager.getConnection("jdbc:db2:DBA1", user,
21.
password);
Abbildung 21 - SMJDBCTestPrg.java
/java/SMJDBCTestPrg.java
Nachdem die Installation auf der Workstation und dem OS/390 Server durchgeführt und
verifiziert wurde, kann mit dem kompletten Produktionsablauf begonnen werden. Als erstes
wird dies mit einem HelloWorld (
/java/SMJDBCTestPrg.java) Programm
getestet. Es handelt sich dabei um eine modifizierte Version des Beispielprogramms, das in
Kapitel 5 verwendet wurde (s. Abbildung 21). Dieses Programm fragt den Benutzer nach
dem zu verwendenden Connector und führt dann die bereits in Kapitel 5 beschriebene SQL
Abfrage auf eine DB2 Systemtabelle durch.
Der wichtigste Teil der Erweiterung ist das dynamische Laden des JDBC Connectors und
das Setzen der Datenbank URL. In Zeile 4 wird beispielsweise der OS/390 JDBC
Connector geladen und dann in Zeile 5 damit eine Verbindung zur Datenbank aufgebaut.
Für den Hit (Zeile10-15) bzw. den IBM Windows Connector (Zeile 18-21) wird jeweils ein
anderer Treibername und eine andere URL verwendet. Durch die Benutzereingabe wird
eine der drei Alternativen ausgeführt und mit dem entsprechenden Connector eine
Verbindung zur Datenbank hergestellt.
6.4.1.1 Test in der Entwicklungsumgebung
Bei dem Test eines HelloWorld Programmes sind die Vorteile der Benutzung einer
modernen Entwicklungsumgebung noch nicht so offensichtlich, da das Programm einfach
zu kurz ist, als dass viele Probleme, wie z.B. Laufzeitfehler, auftreten würden. Trotzdem
kann mit dem Debugger zum Test und besseren Verständnis das Programm Zeile für Zeile
abgearbeitet werden. Nach dem Start des Programms in der Eclipse
Entwicklungsumgebung erscheint in der Console die Aufforderung, einen Connector
auszuwählen, in Abbildung 22 wird durch Eingabe der „2“der Hit Treiber zum Zugriff
Entwicklungsumgebung auf der Workstation
39
Abbildung 22 - Java Programm auf der Workstation mit JDBC Zugriff auf DB2
verwendet. Nach einem erfolgreichen Programmdurchlauf sieht man das erste Mal auf der
Workstation Daten, die aus der OS/390 DB2 Datenbank ausgelesen wurden (in Abbildung
22 in den Zeilen nach der Ausgabe **** JDBC Resultset Created).
6.4.1.2 Export in die Produktionsumgebung
Nach der erfolgreichen Ausführung des Programms ist als nächster Schritt das Exportieren
in die Produktionsumgebung geplant. Dabei gibt es grundsätzlich zwei verschiedene
Möglichkeiten: Entweder man exportiert den Quellcode und kompiliert ihn auf dem OS/390
Server, oder man exportiert gleich die Class Dateien und spart sich das erneute
Kompilieren auf dem Server. Bei beiden Methoden werden die Dateien mit Hilfe eines FTP
Programms übertragen. In der Diplomarbeit wird WSFTP Pro benutzt. Mit der kostenlosen
Version WSFTP LE können die hier beschriebenen Einstellungen ebenfalls verwendet
werden. An dieser Stelle treten auch einige OS/390 spezifische Probleme auf. Zuerst muss
sich der FTP Klient auf dem Mainframe einloggen. Dabei ist es wichtig zu wissen, dass es
verschiedene Möglichkeiten gibt, wo man auf dem OS/390 Server nach dem Login landet.
Auf Grund der vorliegenden Konfiguration des OS/390 Servers hat man, nach dem üblichen
Eingeben von IP Adresse, Login und Passwort, erstmal das OS/390 System vor sich. Dies
erkennt man an der Darstellung von OS/390 Datensätzen in der Form
DATASETNAME.MEMBER (s. Abbildung 23).
Entwicklungsumgebung auf der Workstation
40
Abbildung 23 - FTP Zugriff auf den OS/390 Server
Da Java und Websphere aber unter den USS laufen, müssen einige Einstellungen an dem
FTP Programm vorgenommen werden, um auf das HFS (vgl. Kapitel 4.3.3 und 4.3.4)
zuzugreifen. Durch die richtige Angabe eines externen Anfangsordners kann man
erzwingen, mit dem FTP Programm auf das HFS der USS zuzugreifen. In diesem Fall ist
der richtige Eintrag das Benutzerverzeichnis /u/stefanm (s. Abbildung 24).
Abbildung 24 - Externen Anfangsordner festlegen
Außerdem muss die automatische Erkennung des Hosttyps ausgeschaltet und von Hand
Unix gewählt werden (s. Abbildung 25).
Entwicklungsumgebung auf der Workstation
41
Abbildung 25 - Hosttyp Unix vorgeben
Nach diesen Einstellungen und einer erneuten Aufnahme der Verbindung, greift man nun
auf das angegebene Homeverzeichnis im HFS unter den USS zu (s. Abbildung 26).
Abbildung 26 - FTP Zugriff auf das HFS des OS/390 Servers
Nun kann mit dem Übertragen der Dateien begonnen werden. Dabei ist zu beachten, dass
bei Text Dateien eine Konvertierung von ASCII nach EBCDIC vorgenommen werden muss.
Es ist deshalb wichtig, entweder von Hand auf eine korrekte Einstellung des FTP
Programms zu achten, oder dem FTP Programm in den Einstellungen mitzuteilen, dass es
sich bei Dateien mit der Endung „java“um Textdateien handelt (s. Abbildung 27).
Jetzt sind alle wichtigen Einstellungen des FTP Programms vorgenommen, es kann mit
dem Export der Dateien begonnen werden. Nach dem erfolgreichen Upload der Dateien
kann die .class Datei sofort auf dem OS/390 Server ausgeführt werden. Die .java Datei
muss zuerst kompiliert werden; dabei sind jedoch keine Änderungen am Quellcode
notwendig.
Entwicklungsumgebung auf der Workstation
42
Abbildung 27 - Übertragungsmodus im FTP Programm einstellen
Um das hochgeladene Programm zu testen, muss man sich unter Verwendung des
QWS3270 Klienten (vgl. Kapitel 4.2) auf dem OS/390 Server einloggen und in die USS
Shell wechseln. Am schnellsten erreicht man dies durch die Eingabe des TSO Kommandos
tso omvs. Da die in dieser Arbeit entwickelten Programme in Packages organisiert sind,
wird das Programm mit folgendem Aufruf gestartet:
java sm390.SMJDBCTestPrg (
/java/SMJDBCTestPrg.java)
Nach dem Programmstart wählt man durch die Eingabe von „1“den OS/390 JDBC
Connector. Das Programm führt dann die bereits erklärte Testabfrage auf eine
Systemtabelle durch und gibt die Namen aller Tabellen aus (s. Abbildung 28). Wie erwartet,
erzeugt das Programm auf dem OS/390 Server die gleiche Ausgabe wie auf der
Workstation.
Entwicklungsumgebung auf der Workstation
43
Abbildung 28 - Java Programm auf dem OS/390 Server
6.4.2 HelloWorld Java Servlet
Der nächste Schritt ist, das Javaprogramm in ein Servlet umzuprogrammieren. Dabei wird
ein HTML Rahmen für die Programmausgabe erstellt und die bisher durch Texteingabe zu
tätigende Auswahl in Formularfelder umgewandelt. Damit auf der Workstation das Servlet
ausgeführt werden kann, muss zusätzlich ein Servlet Container installiert und konfiguriert
sein (vgl. Abbildung 16, Kapitel 6.2). Die Entwicklungsumgebung startet den Servlet
Container und führt darin den Code des Servlets aus, dabei kann das Servlet jederzeit mit
dem Debugger unterbrochen bzw. Schritt für Schritt abgearbeitet werden.
6.4.2.1 Test in der Entwicklungsumgebung
Wie beim Test des Javaprogramms, kann das Servlet komplett auf der Workstation
getestet, ausgeführt und debuggt werden. Es wird nur noch ein Browser benötigt, mit dem
das Servlet aufgerufen werden kann. In Visual Age kann der Browser direkt per Mausklick
auf die Serverklasse mit der richtigen URL gestartet werden. Das Servlet wird dann sofort
angezeigt. In Eclipse muss von Hand im Browser die richtige URL aufgerufen werden. Als
Server muss localhost (für die Entwicklungsworkstation) und Port 8080 angegeben
werden, damit die lokale Tomcat Installation die Anfrage beantwortet. Die URL sieht für das
/java/SMJDBCTestServlet.java) folgendermaßen aus:
HelloWorld Servlet (
http://localhost:8080/servlet/sm390.SMJDBCTestServlet
Nach der Angabe des Servers und Ports folgt das Schlüsselwort servlet/ das Tomcat
mitteilt, dass es sich bei der URL um ein Servlet handelt. Am Ende steht der Packagename
und der Name der Servletklasse, die durch einen „.“getrennt sind.
Entwicklungsumgebung auf der Workstation
44
Sobald das Servlet fehlerfrei läuft, kann mit dem Übertragen der Dateien auf den OS/390
Server begonnen werden.
6.4.2.2 Export in die Produktionsumgebung
Der Export in die Produktionsumgebung unterscheidet sich kaum vom Export des
Javaprogramms. Da das Servlet von Websphere ausgeführt wird, muss es in das
Servletverzeichnis von Websphere kopiert werden oder das Homeverzeichnis, in dem das
Servlet liegt, in den Classpath von Websphere übernommen werden. Letzteres hat aber
einen gravierenden Nachteil: Meist ist aus Performancegründen nur für das Websphere
Servletverzeichnis der automatische Reload von geänderten Servlets aktiviert. D.h. Servlets
in anderen Verzeichnissen werden nur einmal kompiliert, selbst wenn eine geänderte
Version erneut hochgeladen wird. Diese neue Version wird erst nach einem Neustart von
Websphere kompiliert und angezeigt. Da die wenigsten Benutzer das Recht haben,
Websphere neu zu starten, und der Neustart für jeden Servletupload auch nicht sinnvoll ist,
sollte das Servlet in das Websphereservletverzeichnis übertragen werden. Deshalb bleiben
alle Einstellungen des FTP Programms gleich wie in Kapitel 6.4.1.2, nur das Zielverzeichnis
wird auf:
/web/serv1/ApplServer/servlets
geändert.
Das übertragene Servlet kann durch Aufrufen der URL
http://jedi.informatik.unileipzig.de/servlet/sm390.SMJDBCTestServlet
in einem Browser angezeigt werden. Gerade beim Upload auf den Server sollte bei der
Behebung von evtl. auftretenden Laufzeitfehlern auf den Browser und Server Cache
geachtet werden. Es empfiehlt sich, z.B. durch die Ausgabe einer Debugmeldung mit einer
Versionsnummer, zu kontrollieren, dass der Server bereits die neueste Version anzeigt.
Gästebuch Servlet
45
7. Gästebuch Servlet
Nach dem erfolgreichen Test der Entwicklungsumgebung und des Exports in die
Produktionsumgebung soll eine einfache Anwendung mit Hilfe der bereits verifizierten
Abläufe programmiert werden. Ein Gästebuchservlet bietet sich auf Grund der
Anforderungen an (
/java/GuestBookServlet.java):
1. Persistenz ist zwingend notwendig.
2. Es demonstriert, wie man eine OS/390 Datenbank anlegt und auf sie zugreift.
3. Die Anwendung (und damit der Quellcode ) ist trotz der oben genannten Anforderungen
überschaubar.
Als erstes müssen die Anforderungen an die Datenbank spezifiziert werden. Für die
Gästebuchanwendung wird nur eine Tabelle benötigt, in der die Informationen zu den
einzelnen Einträgen gespeichert sind. Folgende Felder werden benötigt:
•
email-Adresse des Eintragenden
•
Name des Eintragenden
•
Eintragstext
•
Eintragsdatum
Alle Felder außer dem Eintragsdatum werden als String mit unterschiedlicher Länge
angelegt (vgl. Abbildung 32, Zeile 2-5). Für das Eintragsdatum eignet sich der Typ
TIMESTAMP, da darin ein Datum und eine Uhrzeit gespeichert werden (vgl. Abbildung 32,
Zeile 6).
Nach dieser Spezifikation wird eine DB2 Datenbank mit einer Tabelle angelegt.
Beim Anlegen der Datenbank sind einige Besonderheiten zu berücksichtigen. Eine
Einführung in die DB2 Datenbank ist unter [ VIS ] zu finden. Besondere Eigenschaften der
OS/390 Version sind in [ SLO ] abgehandelt. Neben den üblichen Angaben, z.B.
Feldspezifikationen, Namen der Datenbank und der Tabelle, müssen drei zusätzliche
Definitionen erstellt werden. Diese Definitionen enthalten:
1. Art, Ort (Bereich auf einem von mehreren Plattenspeichern), Größe und Eigenschaften
des Speicherplatzes, der die Datenbank aufnehmen soll. Dieser Speicherplatz wird als
Storage Group bezeichnet und erhält einen symbolischen Namen.
2. Eine Datenbank speichert normalerweise einen Teil der aktiven Daten innerhalb des
Hauptspeichers temporär ab (Cache). Dieser Cache wird allgemein als Bufferpool
bezeichnet und erhält ebenfalls einen symbolischen Namen.
3. Eine relationale Datenbank besteht aus mindestens einer, meistens aber aus mehreren
Tabellen (Relationen). Für jede Tabelle muss Speicherplatz, als Tablespace bezeichnet,
reserviert werden. Dieser erhält ebenfalls einen symbolischen Namen [ TU1 ].
Zuerst wird mit dem SQL Statement in Abbildung 29 der Speicherplatz (Storage Group)
festgelegt:
Gästebuch Servlet
46
(1)CREATE STOGROUP STOGR1 VOLUMES (SCPMV5) VCAT DSN510;
Abbildung 29 - SQL Statement zum Erstellen der STORAGE GROUP
Die Angaben für VOLUMES und VCAT sind installationsspezifisch und müssen vom
Systemadministrator vorgegeben werden. Für den in der Diplomarbeit verwendeten OS/390
Server gelten die Werte (SCPMV5) und DSN510.
Die Datenbank DIPLGB wird in dem zuvor reservierten Speicherplatz angelegt (s.
Abbildung 30).
(1)CREATE DATABASE DIPLGB STOGROUP STOGR1 BUFFERPOOL BP0;
Abbildung 30 - SQL Statement zum Erstellen der Datenbank
Der zugewiesene Hauptspeicher Cache (BUFFERPOOL) mit dem Namen BP0 exisitiert
bereits und kann von der neu angelegten Datenbank mitbenutzt werden. Damit die für das
Gästebuch benötigte Tabelle in der Datenbank angelegt werden kann, muss noch der
benötigte Tablespace angelegt werden (s. Abbildung 31).
(1)CREATE TABLESPACE SPAGB IN DIPLGB
(2) USING STOGROUP STOGR1
(3)
PRIQTY 20
(4)
SECQTY 20
(5)
ERASE NO
(6) BUFFERPOOL BP0
(7) CLOSE NO;
Abbildung 31 - SQL Statement zum Erstellen des Tablespace
Nachdem auch diese Definition erfolgreich angelegt wurde, kann die benötigte Tabelle
erstellt werden. Bei dem CREATE Statement muss auf jeden Fall die Datenbank und der
verwendete Tablespace angegeben werden (s. Abbildung 32, Zeile 6).
(1)CREATE TABLE GUESTBOOK (
(2)
EMAIL
CHAR(100),
(3)
NAME
CHAR(200),
(4)
COMMENT LONG VARCHAR,
(5)
CMT_DATE TIMESTAMP
(6)
) IN DIPLGB.SPAGB;
Abbildung 32 - SQL Statement zum Erstellen der Tabelle
Durch diese Definitionen erhält man eine hohe Kontrolle über das Verhalten jeder einzelnen
Datenbank, es gibt aber vor allem für Einsteiger mehr potentielle Fehlerquellen. Nach dem
Anlegen der für das Gästebuchservlet benötigten Tabelle, müssen noch die Zugriffsrechte
gesetzt werden. Damit auch der Webserver auf die Tabelle zugreifen kann, bekommt die
Benutzergruppe PUBLIC die Rechte zum Ändern und Anzeigen der Tabellendaten. Hierfür
wird das SQL Statement in Abbildung 33 ausgeführt.
Gästebuch Servlet
47
(1)GRANT UPDATE,SELECT ON STEFANM.GUESTBOOK TO PUBLIC
Abbildung 33 - SQL Statement zum Festlegen der Zugriffsrechte
Jetzt kann die Entwicklung auf der Workstation beginnen. Um sicherzustellen, dass von der
Workstation ebenfalls auf die Tabelle zugegriffen werden kann, wird das HelloWorld Servlet
so modifiziert, dass es auf die neu generierte Tabelle zugreift. Die, in Abbildung 34
abgedruckte, Änderung beschränkt sich auf das SQL Statement zum Auslesen der
Gästebuchtabelle.
(1) // SQL Query zum Zugriff auf die Tabelle des Gästebuchs:
(2)String sStdSql = "SELECT name, email, cmt_date, comment "
+ "FROM STEFANM.GUESTBOOK ORDER BY cmt_date";
Abbildung 34 - SQL Statement zum Zugriff auf die Gästebuch Tabelle
/java/GuestBookServlet.java
Damit besteht bereits ein rudimentäres Gerüst, um die bestehenden Einträge anzuzeigen.
Um auch neue Einträge anlegen zu können, muss die ausgegebene HTML Seite um ein
Formular mit Eingabefeldern und das Servlet um eine Funktion, die neue Einträge in die
Datenbank speichert, erweitert werden. Die Programmierung des Servlets ist vollkommen
unabhängig vom OS/390 Betriebssystem.
Einen Screenshot der fertigen Gästebuch Applikation zeigt Abbildung 35.
/java/GuestBookServlet.java)
(
Um den Aufwand für einen Export in die Produktionsumgebung möglichst gering zu halten,
wird im Servlet dynamisch der JDBC Treiber geladen und die URL zur Datenbank gesetzt.
Durch Auslesen der Systemeigenschaft os.name wird das verwendete Betriebssystem,
hier OS/390 oder Windows, bestimmt. Abhängig vom Betriebssystem wird dann der
richtige JDBC Treiber geladen und die URL in einer globalen Variablen gespeichert (s.
Abbildung 36, Seite 49).
Gästebuch Servlet
Abbildung 35 - Gästebuch Servlet auf dem OS/390 Server
48
/java/GuestBookServlet.java
Nach einem letzten Funktionstest wird das Servlet auf den OS/390 Server übertragen. Der
Upload wird, wie bereits in Kapitel 6.4.2.2 dargestellt, durchgeführt. Das Servlet ist ohne
Anpassungen sofort funktionsfähig. Das Servlet kann unter der URL:
http://jedi.informatik.unileipzig.de/servlet/sm390.GuestBookServlet
aufgerufen werden.
49
(1)private void loadJDBCDriver() throws ServletException {
(2) environment =
System.getProperties().getProperty("os.name");
(3) String db2Driver = null;
(4)
(5) // Treiber und URL entsprechend dem Betriebssystem
wählen:
(6) if (environment.equals("OS/390") ||
environment.equals("z/OS")) {
(7)
// OS/390
(8)
driverName = "ibm.sql.DB2Driver";
(9)
jdbcURL = "jdbc:db2os390:DBA1";
(10) } else if (environment.startsWith("Win")) {
(11)
// Windows (mit DB2Connect)
(12)
driverName = "COM.ibm.db2.jdbc.app.DB2Driver";
(13)
jdbcURL = "jdbc:db2:DBA1";
(14) }
(15) try {
(16)
driver = (Driver)
Class.forName(driverName).newInstance();
(17) } catch (Exception e) {
(18)
throw new ServletException(
(19)
"Konnte DB Treiber nicht laden: " +
e.getMessage());
(20)
}
(21) // Benutzername und Passwort für den JDBC Zugriff
(22) connectionProperties.put("user", "stefanm");
(23) connectionProperties.put("password", "sorrynopwdhere");
(24) }
Abbildung 36 - Dynamische Auswahl des JDBC Treibers an Hand des Betriebssystems
/java/GuestBookServlet.java
Zusammenfassung und Ausblick
50
8.Zusammenfassung und Ausblick
Bei der Programmierung des Gästebuchservlets hat sich gezeigt, dass auch komplexe
Anwendungen, die auf der Workstation programmiert werden, auf dem OS/390 Server
problemlos und ohne Änderungen funktionieren. Natürlich können auf dem OS/390
Betriebssystem auch Laufzeitprobleme auftreten, die auf der Workstation nicht vorhanden
sind, z.B. hervorgerufen durch die ASCII/EBCDIC Problematik [ SP2 ]. In diesem
Zusammenhang existieren in der OS/390 Umgebung umfangreiche Möglichkeiten für
automatische Tests. Zusätzlich ermöglicht die relativ leichte und plattformunabhängige
Integration von Backendsystemen mit Hilfe von Connectoren gute Möglichkeiten,
bestehende OS/390 Anwendungen und Daten an das Internet anzubinden.
Außerdem hat sich bei der Entwicklung auf der Workstation vor allem der Debugger positiv
bemerkbar gemacht. Mit dem Debugger konnte bei technischen Problemen auf dem
OS/390 Server schnell und sicher mit Hilfe der DB2 bzw. Websphere Dokumentation die
Ursache gefunden werden. Ab einer gewissen Größe eines Projekts ist schon alleine die
Darstellung und leichte Navigation in einer modernen Entwicklungsumgebung eine
wesentliche Arbeitserleichterung.
IBM bietet noch zwei weitere Tools an, die für große Projekte eine Arbeitserleichterung
versprechen. Die Installation und Konfiguration war in dieser Diplomarbeit leider nicht mehr
möglich. Diese sind:
Mit dem Distributed Debugger für Visual Age for Java von IBM kann ein Javaprogramm
während der Ausführung auf dem OS/390 Server von einer Workstation aus debuggt
werden. Dabei ist es möglich Laufzeitfehler, die bei der Ausführung auf der Workstation
noch nicht auftraten, nachzuvollziehen. Dies ist eine gute Möglichkeit, um die oben
beschriebenen Probleme mit den ASCII/EBCDIC Formaten aufzuspüren.
Mit dem Performanceanalyzer kann eine Anwendung auf das Laufzeitverhalten unter
vorgegebener Last untersucht werden. Dies ist zum Test einer fertigen Anwendung ebenso
nützlich wie zu einem Vorabtest, ob eine bestimmte Funktionalität unter hoher Last
überhaupt verwendbar ist. Gerade bei JDBC kann, vor allem bei schlechter
Programmierung, das Laufzeitverhalten sehr ungünstig ausfallen. Wenn bereits vor dem
Projektbeginn klar ist, welche Technologie (nicht) funktioniert, kann wertvolle
Entwicklungszeit gespart werden. Während der Entwicklung können mit dem
Performanceanalyzer potentielle Flaschenhälse aufgespürt, im Laufzeitverhalten überprüft
und evtl. verbessert werden.
Der Einsatz dieser Werkzeuge wäre eine interessante Fortsetzung dieser Arbeit.
Literaturverzeichnis
51
9. Literaturverzeichnis
9.1 Referenzen aus Zeitschriften und Büchern
[ ALM ] Maria Sueli Almeida, Charles E. Lewis, Uwe Sager, Pilar Sandoval: Accessing DB2
for OS/390 Data from the World Wide Web. IBM International Technical Support
Organization, November 1998. SG24-5273-00.
[ HER ] Dr.rer.nat. Paul Herrmann, Prof. Dr.rer.nat. Udo Kebschull, Prof. Dr.-Ing. Wilhelm G.
Spruth: Einführung in z/OS und OS/390. Oldenbourg-Verlag, Oktober 2002, ISBN 3-48627214-4.
[ KEB ] Dr.rer.nat. Udo Kebschull, Prof. Dr.-Ing. Wilhelm G. Spruth: Kommerzielle
Großrechner als Ausbildungsaufgabe an Universitäten und Fachhochschulen. SpringerVerlag, Informatik Spektrum, Band 24, Heft 3, Juni 2001.
[ KO1 ] Alex Louwe Kooijmans, Sonia Armengol, Montse Batalla, Dr. Abbas Birjandi,
Vaughn Burton, Patricia Lobao Pettersson, Thomas Nolting, Mats Pettersson: Java
Programming Guide for OS/390. IBM International Technical Support Organization,
Dezember 1999. SG24-5619-00.
[ KO2 ] Alex Louwe Kooijmans, Egide Van Aerschot, Mark Cathcart, Antonio Lopriore,
Frederic Mora, Elba van Zyl: Integrating Java with Existing Data and Applications on
OS/390. IBM International Technical Support Organization, Juli 1998. SG24-5142-00.
[ KO3 ] Alex Louwe Kooijmans, Kjell Andersen, Amr Khafagy, Simon McNab, Patrick Ryan,
Neil Shah: e-business Enablement Cookbook for OS/390 Volume II: Infrastructure for Javabased Solutions. IBM International Technical Support Organization, Dezember 2000. SG245981-00.
[ KO4 ] Alex Louwe Kooijmans, Felipe Liberman, Georg Nozicka: e-business Enablement
Cookbook for OS/390 Volume III: Java Development. IBM International Technical Support
Organization, Dezember 2000. SG24-5980-00
[ SLO ] Susan Sloan, Kilty Hernandez: An Introduction to DB2 for OS/390 Version 7.
Prentice Hall, 2001.
[ TUR ] Volker Turau, Krister Saleck, Marc Schmidt: Java Server Pages undJ2EE.
dpunkt.verlag, 2001.
[ VIS ] Susan Visser: DB2 Universal Database. SAMS Macmillan Computer Publishing, April
1998.
9.2 Internet Referenzen
Da bei den Internet Referenzen nicht sichergestellt werden kann, dass sie auch weiterhin
unter den angegebenen Links existieren, enthält die beigefügte CD Spiegelungen aller
referenzierten Internet Dokumente. Außerdem können die Dokumente über die Homepage:
http://www-ti.informatik.uni-tuebingen.de/~csp/diplom/munz
Literaturverzeichnis
abgerufen werden.
[ AND ] Glenn Anderson: Migration Strategies for WebSphere on OS/390 and z/OS.
http://www.share.org/proceedings/sh97/data/S2962.PDF
[ CAL ] IBM: Call Level Interface Guide and Reference.
ftp://ftp.software.ibm.com/software/db2storedprocedure/db2zos390/v5books/Dsncl0f6.pdf
[ CIC ] IBM: CICS – Powering 20 billion transactions a day across the world. 2000.
http://www.hursley.ibm.com/infopack/A33578.pdf
[ ECL ] Eclipse Homepage.
http://www.eclipse.org
[ GRA ] Jim Gray: How High is High Performance Transaction Processing? Oktober 1999.
http://research.Microsoft.com/~Gray/Talks/HPTS99.ppt
[ JA1 ] Sun: The Java Tutorial.
http://java.sun.com/docs/books/tutorial/index.html
[ JA2 ] Sun: Java Servlet API - Story of a Servlet: An instant tutorial
http://java.sun.com/products/servlet/articles/tutorial/
[ JUN ] JUnit Homepage.
http://www.junit.org
[ OLI ] M.F. Oliver: Java Positioning Paper. März 2000.
http://www-1.ibm.com/servers/eserver/zseries/software/java/position.html
[ SCH ] Stefan Schäffer, Walter Schilder: Im Blickpunkt: VisualAge for Java 4.0 und sein
Nachfolgeprodukt. JavaMagazin - Sonderdruck, Ausgabe 12.2001.
http://www.ars.de/ars/ars.nsf/files/pdf-artikel/$file/javamagazin-wsad.pdf
[ SP1 ] Prof. Dr.-Ing. Wilhelm G. Spruth :Client Server Systeme – Internetanwendungen
unter OS/390.
http://www-ti.informatik.uni-tuebingen.de/os390/foils/intro01.pdf
[ SP2 ] Prof. Dr.-Ing. Wilhelm G. Spruth: Client Server Systeme.
http://www-ti.informatik.uni-tuebingen.de/os390/foils/uss01.pdf
[ TU1 ] Tutorial 4 DB2.
http://jedi.informatik.uni-leipzig.de/nils/tutor4.pdf
[ TU2 ] Tutorial 8 Installation von DB2Connect.
http://jedi.informatik.uni-leipzig.de/degner/tutor8.pdf
[ TU3 ] Tutorial 9 Zugriff auf eine DB2 Datenbank über DB2Connect mittels Java unter
Verwendung von JDBC.
http://jedi.informatik.uni-leipzig.de/degner/tutor9.pdf
[ TU4 ] Tutorial 10 Zugriff auf DB2 mittels eines OS/390 Rechners.
http://jedi.informatik.uni-leipzig.de/degner/tutor10.pdf
52
Literaturverzeichnis
[ WE1 ] IBM: WebSphere Application Server for OS/390: Requirements for using the
Application Server with DB2.
http://www-3.ibm.com/software/webservers/appserv/doc/os390/wasdb2.pdf oder
http://www-3.ibm.com/software/webservers/appserv/doc/os390/wasdb2.htm
[ WE2 ] IBM: Websphere Studio Workbench Homepage
http://www-3.ibm.com/software/ad/workbench/about/
[ WES ] Frank Westphal: Unit Testing mit JUnit. Oktober 2002.
http://www.frankwestphal.de/UnitTestingmitJUnit.html
53
Anhang
54
10. Anhang
Der gesamte Anhang sowie die Diplomarbeit selbst ist auf der beigelegten CD im HTMLbzw. PDF-Format gespeichert. Auf einem Windows PC sollte nach dem Einlegen der CD
der Standardbrowser automatisch mit dem Inhaltsverzeichnis als HTML Datei geöffnet
werden. Das Inhaltsverzeichnis kann auch von Hand aufgerufen werden, indem die Datei
index.html im Hauptverzeichnis der CD gestartet wird.
Der CD Inhalt ist außerdem auf folgender Internetseite gespeichert:
http://www-ti.informatik.uni-tuebingen.de/~csp/diplom/munz/
10.1 Inhaltsverzeichnis der CD
Der folgende Überblick enthält die Verzeichnis- und Dateistruktur der CD. Es werden nur
die Dateien bzw. Verzeichnisse aufgelistet, die ein Benutzer direkt anwählen muss. Am
einfachsten können alle Dateien aber über das bereits erwähnte Menü geöffnet werden.
Verzeichnisse sind in der Form /Verzeichnisname relativ zum Hauptverzeichnis der CD
angegeben. Unterverzeichnisse und Dokumentnamen sind eingerückt dargestellt.
/java
GuestBookServlet.java
sample01.java
SMJDBCTestPrg.java
SMJDBCTestServlet.java
TestInstall.java
/konfig
.profile
db2jdbc.cursors
dsnaoini
httpd.envvars_X
was.conf
wasStartskript.txt
/literaturverzeichnis
/AND/S2962.PDF
/CAL/Dsncl0f6.pdf
/CIC/A33578.pdf
/ECL/index.html
/GRA/HPTS99.ppt
/JA1/index.html
/JA2/index.html
/JUN/index.html
/OLI/index.html
/SCH/javamagazin-wsad.pdf
/SP1/intro01.pdf
Quellcode aller Java Programme bzw. Servlets
Gästebuchservlet
Beispielprogramm für einen JDBC Zugriff auf
DB2 von IBM
Test Programm für JDBC Zugriff
Test Servlet für JDBC Zugriff
Testklasse zum Überprüfen der JDBC
Connectoren
Konfigurationsdateien auf dem OS/390 Server
Konfigurationsdatei für die JDBC Cursor
CLI Konfigurationsdatei
Konfigurationsdatei für die Umgebungsvariablen
des Webservers
Websphere Konfigurationsdatei
Websphere Startskript
Internet Referenzen. Es befindet sich jeweils
eine Referenz in einem Verzeichnis. Die
Namensgebung orientiert sich an den
Abkürzungen in Kapitel 9.2
Anhang
/SP2/uss01.pdf
/TU1/tutor4.pdf
/TU2/tutor8.pdf
/TU3/tutor9.pdf
/TU4/tutor10.pdf
/WE1/wasdb2.pdf
/WE2/index.html
/WES/index.html
55
Glossar
56
11. Glossar
ASCII
American Standard Code for Information Interchange
Code zur Darstellung von Zeichen als Zahlen, wird vor allem auf
Computern mit Windows, Mac oder UNIX Betriebssystemen verwendet.
CLI
Call Level Interface
Beim DB2 CLI handelt es sich um eine C/C++ API die Funktionen zur
Verarbeitung von dynamischen SQL Statements zur Verfügung stellt
CCF
Common Connector Framework
DLL
Dynamic Link Library
EBCDIC
Extended Binary Coded Decimal Interchange Code
IBM Code zur Darstellung von Zeichen als Zahlen, wird auf dem
OS/390 Betriebssystem verwendet.
GUI
Grafische Benutzeroberfläche, engl.:Graphical User Interface
HPCJ
High Performance Compiler for Java
IDE
Integrated Development Environment
ISPF
Interactive System Productivity Facility
OS/390 Subsystem, arbeitet im Fullscreen Modus, d.h. es können
Änderungen an verschiedenen Stellen des Bildschirms mit nur einer
Kommunikation zum System durchgeführt werden. Außerdem bietet die
ISPF dem Benutzer zahlreiche Utilities und
Programmierunterstützungen.
JDBC
Java Database Connectivity
JSP
Java Server Page
RDBM
Relationales Datenbanksystem, engl.: Relational Database
Management System
SSID
Subsystem Identifier
USS
Unix System Services
Ein in das OS/390 Betriebssystem integriertes, vollständiges UNIX
Betriebssystem. Unter den USS läuft z.B. der in der Diplomarbeit
verwendete Websphere Application Server.