technologien java, jdbc und

Diplomarbeit
Fachhochschule Karlsruhe
Karlsruhe University of Applied Sciences
KOMPONENTENBASIERTE ABFRAGE
UND VISUALISIERUNG RELATIONALER
DATENBANKEN MIT DEN INTERNETTECHNOLOGIEN JAVA, JDBC UND
XML
Jürgen Baier
Steinbeis Transferzentrum für industrielle
Datenverarbeitung und Automation (STZ-IDA)
Dauer: 01. März 1999 bis 31. August 1999
Referent: Prof. Klaus Gremminger
Coreferent: Prof. Dr. Peter Henning
Betreuer: Sascha Ehrenfried Mink
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Eidesstattliche Erklärung
2
Eidesstattliche Erklärung
Hiermit erkläre ich, daß ich die vorliegende Diplomarbeit mit dem Titel "Komponentenbasierte
Abfrage und Visualisierung relationaler Datenbanken mit den Internet-Technologien Java, JDBC
und XML" selbständig und ausschließlich unter Verwendung der angegebenen Literatur verfaßt
habe. Die Arbeit wurde in gleicher oder ähnlicher Form keiner anderen Prüfungsbehörde zum
Erlangen eines akademischen Grades vorgelegt.
-------------------------
----------------------------------------
Datum
Unterschrift
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Inhaltsverzeichnis
3
Inhaltsverzeichnis
KOMPONENTENBASIERTE ABFRAGE UND VISUALISIERUNG RELATIONALER
DATENBANKEN MIT DEN INTERNET-TECHNOLOGIEN JAVA, JDBC UND XML 1
EIDESSTATTLICHE ERKLÄRUNG _____________________________________ 2
INHALTSVERZEICHNIS _____________________________________________ 3
ZUSAMMENFASSUNG ______________________________________________ 7
ABBILDUNGSVERZEICHNIS _________________________________________ 8
VERZEICHNIS DER CODEBEISPIELE _________________________________ 10
TABELLENVERZEICHNIS ___________________________________________ 11
TEIL II: EINLEITUNG _______________________________________________ 12
1
Web-Informationssysteme__________________________________________________________ 12
2
2.1
2.2
2.3
Aufgabenbeschreibung ____________________________________________________________
Eingabeschnittstelle für die Formulierung von DB-Queries _______________________________
Umsetzung der Anfrageergebnisse nach XML (mit serverseitiger Java-Technologie) ___________
Visualisierung der Anfrageergebnisse und Konfigurierbarkeit der Ausgabeschnittstelle _________
12
13
13
13
3.1
3.2
3.3
3.4
3.5
Gliederung der Diplomarbeit _______________________________________________________
Teil II: Grundlagen ______________________________________________________________
Teil III: Anforderungsanalyse und Systemspezifikation __________________________________
Teil IV: Design _________________________________________________________________
Teil V: Implementierung __________________________________________________________
Teil VI: Anhang_________________________________________________________________
14
14
14
14
15
15
3
TEIL III:GRUNDLAGEN _____________________________________________ 16
1
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1.8
1.9
1.10
XML – eXtensible Markup Language ________________________________________________
Einleitung _____________________________________________________________________
Wozu XML? ___________________________________________________________________
Dokumente ____________________________________________________________________
HTML, SGML und XML – Eine Einordnung __________________________________________
Struktur, Darstellung und Inhalt ____________________________________________________
XSL – Extensible Stylesheet Language_______________________________________________
XML und Java __________________________________________________________________
Dokumenttyp-Definition (DTD) ____________________________________________________
Parsen von XML-Dokumenten _____________________________________________________
Weitere Einsatzmöglichkeiten von XML ___________________________________________
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
16
16
17
19
22
24
27
30
30
32
35
Inhaltsverzeichnis
2
4
2.1
2.2
2.3
2.4
Komponententechnologien _________________________________________________________
Einleitung _____________________________________________________________________
Komponentenorientierte Softwareentwicklung _________________________________________
Komponenten, Frameworks, Bibliotheken – Eine Einordnung _____________________________
Komponenten-Frameworks und Komponenten-Bibliotheken ______________________________
38
38
39
39
41
3.1
3.2
3.3
3.4
JavaBeans _______________________________________________________________________
Einführung in JavaBeans __________________________________________________________
Das JavaBeans Komponentenmodell_________________________________________________
Eigenschaften___________________________________________________________________
Entwicklung von JavaBeans _______________________________________________________
43
43
44
45
47
4.1
4.2
4.3
4.4
4.5
RMI – Remote Method Invocation___________________________________________________
Verteilte Objekte ________________________________________________________________
Verteilte Anwendungen mit RMI ___________________________________________________
Programmieren mit RMI __________________________________________________________
Übergabe von Objekten ___________________________________________________________
Komponentenbasierte Entwicklung von RMI-Anwendungen ______________________________
49
49
50
51
54
55
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
EJB - Enterprise JavaBeans ________________________________________________________
Überblick über Enterprise JavaBeans ________________________________________________
Vorteile von EJB ________________________________________________________________
Nachteile von EJB _______________________________________________________________
Rollen bei der EJB-Entwicklung ____________________________________________________
EJB Architektur _________________________________________________________________
Session und Entity-Beans _________________________________________________________
Dienste________________________________________________________________________
Überblick über Klassen und Schnittstellen der EJB-API__________________________________
Überblick über die Entwicklung von Enterprise JavaBeans _______________________________
Szenario eines EJB-Methodenaufrufs (bei zustandsbehafteten Session-Beans) ______________
56
56
59
60
61
62
67
69
72
73
74
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
JDBC – Java Database Connectivity _________________________________________________
Was ist JDBC?__________________________________________________________________
JDBC/ODBC ___________________________________________________________________
Warum JDBC verwenden? ________________________________________________________
JDBC-Treibertypen ______________________________________________________________
Überblick über die wichtigsten Klassen und Schnittstellen der JDBC-API ___________________
Programmieren mit JDBC _________________________________________________________
Transaktionen und Stored Procedures ________________________________________________
Metadaten _____________________________________________________________________
76
76
77
78
78
80
82
84
84
3
4
5
6
TEIL IV:ANFORDERUNGSANALYSE UND SYSTEMSPEZIFIKATION ________ 87
1
Analyse der Anforderungen ________________________________________________________ 87
2
2.1
2.2
2.3
2.4
Analyse der Webarchitekturen______________________________________________________
Systemanforderungen ____________________________________________________________
Java Server Pages (JSP) und EJBs (3- bzw. logische 4-Tier-Architektur) ____________________
Enterprise JavaBeans (3-Tier-Architektur) ____________________________________________
Java-Applikation (3-Tier-Architektur) _______________________________________________
3.1
3.2
Analyse existierender Benutzeroberflächen ___________________________________________ 94
Web-basiert: Oracle WebDB_______________________________________________________ 94
Benutzerfreundlich: Microsoft Access _______________________________________________ 97
3
4
89
89
89
90
92
Use-Cases _______________________________________________________________________ 99
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Inhaltsverzeichnis
5
TEIL V: DESIGN __________________________________________________ 101
1
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1.8
Grobentwurf____________________________________________________________________
Verteilungsdiagramm ___________________________________________________________
Grobstruktur der Anwendung _____________________________________________________
Graphisches User-Interface (GUI)__________________________________________________
XML als Übertragungsprotokoll ___________________________________________________
XML-Verarbeitung mit JavaBeans _________________________________________________
Applet oder Applikation? ________________________________________________________
Auswahl des JDBC-Treibers ______________________________________________________
Einbindung eines XSL-Prozessors__________________________________________________
101
101
102
104
114
118
118
119
120
2.1
2.2
2.3
2.4
2.5
2.6
2.7
Feinentwurf ____________________________________________________________________
Pakete und Komponenten ________________________________________________________
xqt.client _____________________________________________________________________
xqt.converter __________________________________________________________________
com.microstar.xml.AElfred _______________________________________________________
tdg.Perspective_________________________________________________________________
xqt.server _____________________________________________________________________
xqt.QueryBean_________________________________________________________________
122
122
122
123
124
124
125
127
2
TEIL VI:IMPLEMENTIERUNG _______________________________________ 128
1
1.1
1.2
1.3
Verwendete Hard- und Software ___________________________________________________
Rechnerausstattung und Betriebssystem _____________________________________________
Entwicklungsumgebung _________________________________________________________
Applikationsserver______________________________________________________________
128
128
128
128
2.1
2.2
2.3
Implementierungsdetails __________________________________________________________
xqt.XMLConverter _____________________________________________________________
xqt.server.XQTServer ___________________________________________________________
xqt.QueryBean_________________________________________________________________
129
129
130
131
3.1
3.2
3.3
3.4
Probleme bei der Implementierung _________________________________________________
Verschiedene Java-Versionen _____________________________________________________
Installation der HTML-Seite auf dem OAS___________________________________________
Netscape Navigator 4.6 und Internet Explorer 5 _______________________________________
Probleme mit Oracle's JDeveloper 2.0_______________________________________________
135
135
135
135
136
2
3
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Inhaltsverzeichnis
6
TEIL VII: ANHANG _______________________________________________ 137
1
1.1
1.2
1.3
1.4
Überblick über XML-Software_____________________________________________________
XML-Parser ___________________________________________________________________
XSL-Prozessoren _______________________________________________________________
XML-Browser _________________________________________________________________
Sonstige XML-Software _________________________________________________________
137
137
138
138
138
2.1
2.2
2.3
2.4
2.5
Überblick über EJB-Produkte _____________________________________________________
Persistence PowerTier ___________________________________________________________
BEA WebLogic Application Server ________________________________________________
Oracle Application Server 4.0.7 (OAS)______________________________________________
EJBoss Version 0.7 _____________________________________________________________
EJBHome Version 0.5.1 _________________________________________________________
140
140
140
141
141
141
2
3
Zuordnung SQL/Java-Datentypen __________________________________________________ 142
4
Literatur _______________________________________________________________________ 143
5
Glossar ________________________________________________________________________ 154
6
Index __________________________________________________________________________ 157
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Zusammenfassung
7
Zusammenfassung
Deutsch
Diese Diplomarbeit beschäftigt sich mit Web-Informationssystemen, insbesondere mit den
Möglichkeiten der Abfrage und Visualisierung von relationalen Datenbanken über ein Netzwerk. In
den Grundlagenkapiteln werden die für die Implementierung eines Query-Tools interessanten
Technologien näher beschrieben. Im einzelnen geht es um XML, Komponententechnologien,
JavaBeans, der Remote Method Invocation (RMI), der Java-Datenbank-Schnittstelle JDBC und um
Enterprise JavaBeans (EJB).
Ziel der Diplomarbeit ist die Implementierung eines Web-Informationssystems – eines QueryTools – und der Nachweis der Funktionsfähigkeit oben beschriebener Technologien – insbesondere
der Datenübertragung mit XML.
Der Prototyp des Query-Tools arbeitet mit XML als Datenaustauschformat und JDBC, um auf eine
Oracle-Datenbank zuzugreifen. Das Kommunikationsprotokoll zwischen Client und Server ist
RMI. Es werden auf Client- und Serverseite JavaBeans – jedoch keine Enterprise JavaBeans –
eingesetzt. Zur Visualisierung der Ergebnisse der Datenbankanfragen wird ein Java-Applet mit
einer integrierten JavaBean zur Darstellung von Charts verwendet.
English
The subject of this thesis is web information systems, in particular tools for querying and
visualizing rational databases. In the theoretical part of the thesis technologies are described in
detail that are relevant for the implementation of query tools. XML, component technologies,
JavaBeans, Remote Method Invocation (RMI), the Java Database Connectivity (JDBC) and
Enterprise JavaBeans (EJB) are covered.
The aim of the thesis is twofold: Firstly to demonstrate the implementation of a web informations
system or query tool. Secondly the proof of concept of the technologies described in the theoretical
chapters, and in particular XML-technology.
The prototype of the query tool works with XML as a data exchange format, and with JDBC to
access an Oracle database. The communication protocol of the application is RMI. JavaBeans - not
Enterprise JavaBeans - are used both on the client- and on the serverside of the application. A Java
applet with an integrated JavaBean for viewing charts is used to visualize the results of database
queries.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Abbildungsverzeichnis
Abbildungsverzeichnis
Abbildung III-1: Geschäftsprozesse mit EDI _____________________________________18
Abbildung III-2: Geschäftsprozesse mit EDI und XML _____________________________19
Abbildung III-3: Komponenten eines Dokuments _________________________________21
Abbildung III-4: HTML-Dokument als Text, Schachtelbild und Strukturbaum ____________21
Abbildung III-5: Einordung von SGML, XML und HTML____________________________23
Abbildung III-6: Struktur, Darstellung und Inhalt mit der XML ________________________24
Abbildung III-7: XSL und Untermengen_________________________________________27
Abbildung III-8: Überblick über das XSL Verarbeitungs-Modell (aus [Holman 99])________28
Abbildung III-9: Struktur, Darstellung und Inhalt mit der XML ________________________33
Abbildung III-10: Ablauf der XML-Verarbeitung___________________________________33
Abbildung III-11: Die zwei Teile der DOM Level 1-Spezifikation ______________________34
Abbildung III-12: Speichern und Laden von JavaBeans ____________________________36
Abbildung III-13: Softwarewartung ____________________________________________38
Abbildung III-14: Generische Komponentenbibliotheken ___________________________41
Abbildung III-15: Vergleich des Codumfanges ___________________________________42
Abbildung III-16: Reflexion und Introspektion ____________________________________45
Abbildung III-17: Client/Server-Anwendungen und RMI ____________________________50
Abbildung III-18: Funktionsweise von RMI – Stub und Skeleton______________________52
Abbildung III-19: Anwendung von RMI _________________________________________53
Abbildung III-20: Komponententechnologie und RMI ______________________________55
Abbildung III-21: Warum 3-stufige Architekturen verwenden? _______________________58
Abbildung III-22: Überblick über die EJB-Architektur ______________________________62
Abbildung III-23: UML-Klassendiagramm der EJB-Architektur _______________________62
Abbildung III-24: Aufbau eines EJB-Containers __________________________________64
Abbildung III-25: Detaillierter Aufbau eines EJB-Containers_________________________65
Abbildung III-26: Session-Beans und Entity-Beans________________________________67
Abbildung III-27: Verwendung von Entity-Beans__________________________________69
Abbildung III-28: EJBObject, EJBHome, EJBMetaData ____________________________72
Abbildung III-29: EnterpriseBean und Subklassen ________________________________73
Abbildung III-30: EJB-Methodenaufruf bei zustandsbehafteten Session-Beans__________75
Abbildung III-31: JDBC Typ 1-Treiber (JDBC-ODBC-Bridge) ________________________78
Abbildung III-32: JDBC Typ 2-Treiber (JDBC-native API-Bridge) _____________________79
Abbildung III-33: JDBC Typ 3-Treiber (Nativer Protokolltreiber) ______________________79
Abbildung III-34: JDBC Typ 4-Treiber (Netzwerktreiber)____________________________80
Abbildung III-35: JDBC-API__________________________________________________81
Abbildung III-36: Sequenzdiagramm einer SQL-Anfrage ___________________________84
Abbildung III-37: Metadaten einer Datenbank____________________________________85
Abbildung IV-1: Java Server Pages und Enterprise JavaBeans ______________________89
Abbildung IV-2: 3-Tier-Architektur mit Enterprise JavaBeans ________________________91
Abbildung IV-3: 3-Tier-Architektur mit Enterprise JavaBeans ________________________92
Abbildung IV-4: Oracle WebDB: Anzeige der Tabellen des Benutzers BAIER ___________94
Abbildung IV-5: Oracle WebDB: Formular für DB-Anfragen _________________________95
Abbildung IV-6: Oracle WebDB: Dialog "Tables and Views"_________________________96
Abbildung IV-7: Oracle WebDB: Dialog "Join Conditions" __________________________96
Abbildung IV-8: Microsoft Access: Anzeige aller Tabellen einer Datenbank_____________97
Abbildung IV-9: Microsoft Access: GUI zur Erstellung einer Abfrage __________________98
Abbildung IV-10: Use-Case-Diagramm _________________________________________99
Abbildung V-1: Systemarchitektur - Verteilungsdiagramm _________________________101
Abbildung V-2: Paket-/Komponentendiagramm der Anwendung ____________________103
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
8
Abbildungsverzeichnis
Abbildung V-3: Benutzeroberfläche des Query-Tools _____________________________105
Abbildung V-4: Report-Registerkarten des Query-Tools___________________________106
Abbildung V-5: Mapping der Spalten der Rückgabetabelle_________________________107
Abbildung V-6: Visualisierung der Ergebnisse mit der ChartBean ___________________107
Abbildung V-7: Screenshot des Login-Dialogs (Use-Case "Login") __________________109
Abbildung V-8: Aktivitätsdiagramm für Use-Case "Login"__________________________110
Abbildung V-9: Aktivitätsdiagramm für Use-Case "Generate Query" _________________111
Abbildung V-10: Tabellenbaum für den User "baier"______________________________112
Abbildung V-11: Spalten-Frame für die Tabelle COFFEES ________________________112
Abbildung V-12: Aktivitätsdiagramm für den Use-Case "Manage Query" ______________113
Abbildung V-13: Aktivitätsdiagramm für die " Chart"-Use-Cases ____________________114
Abbildung V-14: Struktur, Darstellung und Inhalt mit der XML ______________________116
Abbildung V-15: Klassendiagramm des Clients _________________________________122
Abbildung V-16: Klassendiagramm der XMLConverter-Komponente _________________123
Abbildung V-17: Klassendiagramm von AElfred _________________________________124
Abbildung V-18: Klassen-/Komponentendiagramm des Servers ____________________126
Abbildung V-19: Implementierung des Fassade-Patterns durch die QueryBean ________127
Abbildung VI-1: Konvertierung eines XML-Dokumentes in eine Swing-Tabelle _________129
Abbildung VI-2: Sequenzdiagramm des Serverstartes ____________________________131
Abbildung VI-3: Sequenzdiagramm des Datenbank-Logins ________________________132
Abbildung VII-1: Tengah EJB Deployment Wizard _______________________________140
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
9
Verzeichnis der Codebeispiele
Verzeichnis der
Codebeispiele
Codebeispiel III-1: Shakespeare-DTD__________________________________________25
Codebeispiel III-2: Struktur von Kochrezepten mit XML ____________________________29
Codebeispiel III-3: XSL-Pattern_______________________________________________29
Codebeispiel III-4: Anwendung eines Patterns ___________________________________29
Codebeispiel III-5: Transformation von XML in HTML _____________________________29
Codebeispiel III-6: DTD und äquivalente BNF ___________________________________31
Codebeispiel III-7: SAX-Beispieldokument ______________________________________34
Codebeispiel III-8: Parsen mit SAX ____________________________________________35
Codebeispiel III-9: GUI-DTD für Swing _________________________________________35
Codebeispiel III-10: XML-Dokument zur GUI-DTD ________________________________35
Codebeispiel III-11: Dynamisches Laden von Swing-Klassen _______________________36
Codebeispiel III-12: Ausschnitt aus der XMI-DTD_________________________________37
Codebeispiel III-13: Ausschnitt aus der UXF-DTD ________________________________37
Codebeispiel III-14: Anwendung der UXF-DTD __________________________________37
Codebeispiel III-15: Manifest-File _____________________________________________47
Codebeispiel III-16: XML-basierter Deployment-Descriptor _________________________66
Codebeispiel III-17: Methodendeklaration zur Primärschlüssel-Abfrage________________68
Codebeispiel III-18: Laden eines JDBC-Treibers _________________________________82
Codebeispiel III-19: Verbindungsaufbau zur Datenbank mit JDBC____________________82
Codebeispiel III-20: Erzeugung von Statement und ResultSet _______________________83
Codebeispiel III-21: Auslesen der Anfrageergebnisse _____________________________83
Codebeispiel III-22: Datenbankzugriff mit JDBC __________________________________83
Codebeispiel III-23: Metadaten-Abfrage mit JDBC ________________________________85
Codebeispiel V-1: Login-DTD _______________________________________________115
Codebeispiel V-2: SQL-Query-DTD __________________________________________115
Codebeispiel V-3: DTD-Schablone für Abfrageergebnisse _________________________115
Codebeispiel V-4: DTD-Beispiel für eine SQL-Query _____________________________118
Codebeispiel VI-1: Konstruktor von XML2TableConverter _________________________129
Codebeispiel VI-2: Callback-Methode endElement von XML2TableConverter__________130
Codebeispiel VI-3: Callbackmethode convertData von XML2TableConverter __________130
Codebeispiel VI-4: Starten des Servers _______________________________________131
Codebeispiel VI-5: Login in die Datenbank _____________________________________132
Codebeispiel VI-6: Datenbankzugriff und Generierung des XML-Dokumentes _________133
Codebeispiel VI-7: Übernahme des JDBC-ResultSets in das XML-Dokument__________133
Codebeispiel VI-8: Generierung einer DTD_____________________________________134
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
10
Tabellenverzeichnis
11
Tabellenverzeichnis
Tabelle III-1: Unterschiede zwischen CSS und XSL _______________________________26
Tabelle IV-1: Analyse der Anforderungen _______________________________________87
Tabelle IV-2: Systemanforderungen ___________________________________________89
Tabelle IV-3: Verfügbare EJB-Server __________________________________________91
Tabelle VII-1: Zuordnung SQL/Java-Datentypen ________________________________142
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil II: 1. Web-Informationssysteme
Teil II:
12
Einleitung
1 Web-Informationssysteme
Cyberspace is
"A graphic representation of data abstracted from the banks of every computer in the human
system. Unthinkable complexity. Lines of light ranged in the nonspace of the mind, clusters
and constellations of data. Like city lights, receding."
William Gibson
Das Thema dieser Diplomarbeit lautet "Komponentenbasierte Abfrage und Visualisierung
relationaler Datenbanken mit den Internettechnologien Java, JDBC und XML". Hintergrund dieses
Themas ist ein Paradigmenwechsel, der sich bei der Softwareentwicklung für das Internet
vollzogen hat. Der Trend geht dahin, plattformunabhängige Technologien zu verwenden, die – und
das ist eine wesentliche Forderung – in weiten Bereichen skalierbar, portierbar und erweiterbar
sind.
Inzwischen wenden immer mehr Unternehmen Datenbank- und Internettechnologien intern und
extern an. Beispiele hierfür sind Groupware-Systeme wie Lotus Notes, mit denen eine
Kommunikationsinfrastruktur implementiert werden kann, deren Spektrum von elektronischen
Schwarzen Brettern bis hin zum Dokumentenaustausch via E-Mail und zu Videokonferenzen geht.
Der elektronische Handel (E-Commerce) wird immer beliebter und zwingt Firmen, derartige
Systeme einzuführen, um wettbewerbsfähig zu bleiben. In einigen Bereichen (vor allem im
Vertrieb von Software und von Büchern) ist eine völlige Umstrukturierung des Marktes möglich.
Schon jetzt ist Software von kleineren Firmen nur noch über das Internet zu bekommen. Auch die
Online-Bestellung von Büchern mit 24-Stunden Lieferservice ist oftmals bequemer, als zum
Buchladen in die Stadt zu gehen.
Aber das Thema sind Web-Informationssysteme im engeren Sinne. Wie auch immer mögliche
Implementierungen aussehen, eines haben sie alle gemeinsam: Es sollen Daten, welche in einer
Datenbank gespeichert sind, über ein Netzwerk gelesen und vor allem visualisiert werden können.
Die heutige Datenvielfalt macht es jedoch schwierig, überhaupt etwas mit den Daten anzufangen.
Deshalb liegt heute der Schwerpunkt von Web-Informationssystemen nicht im Umgang mit
operativen Daten, sondern vielmehr in der post-operativen Datenanalyse und der
benutzerspezifischen Aufarbeitung der gewünschten Daten (z.B. betriebswirtschaftliche
Kennzahlen oder deren Visualisierung).
2 Aufgabenbeschreibung
Ziel dieser Diplomarbeit ist die Implementierung des Prototyps eines Web-Informationssystems
und der Nachweis der Funktionsfähigkeit; besonders im Hinblick auf die Verwendung von XML
als Datenaustauschformat. Das zu implementierende Informationssystem ist ein einfaches, Javabasiertes Query-Tool, das es ermöglichen soll, über Internet oder Intranet eine relationale
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil II: 2. Aufgabenbeschreibung
13
Datenbank abzufragen. Aus den Ergebnissen der Anfrage soll ein XML-Dokument generiert und
über JavaBeans visualisiert werden.
Die folgenden Unterkapitel wurden direkt aus der Aufgabenstellung entnommen und sind als eine
Art Lastenheft anzusehen.
2.1 Eingabeschnittstelle für die Formulierung von DBQueries
Die Eingabeschnittstelle für die Formulierung der Datenbankanfragen ist ein Java-Applet. Die
Erstellung von Datenbankanfragen soll auf zwei Arten erfolgen können:
•
manuelle Eingabe der SQL-Kommandos
•
automatische Generierung der SQL-Kommandos über eine intuitiv zu nutzende grafische
Benutzeroberfläche
Die resultierende SQL-Query soll dann XML-codiert und an den Server des Query-Tools geschickt
werden.
2.2 Umsetzung der Anfrageergebnisse nach XML (mit
serverseitiger Java-Technologie)
Die Ergebnisse der Anfrage sollen nun XML-codiert werden. Dazu muß für jede Anfrage eine neue
Dokumenttyp-Definition generiert werden (auf der Basis eines DTD-Templates), welche den
prinzipiellen Aufbau des XML-Dokuments beschreibt. Dieses XML-Dokument muß wohlgeformt
und gültig (siehe XML-Kapitel) sein, damit die spätere Weiterverarbeitung unproblematisch ist.
Insbesondere sollte eine Validierung durch den clientseitigen Parser nicht nötig sein.
2.3 Visualisierung der Anfrageergebnisse und
Konfigurierbarkeit der Ausgabeschnittstelle
Das Anfrageergebnis wird – wie schon zuvor beschrieben – XML-codiert zurückgegeben. Das
heißt, daß zur Auswertung des Ergebnisses ein XML-Parser benötigt wird. Da der Client des
Query-Tools ein Java-Applet ist, das im Kontext eines Web-Browsers läuft, muß dieser Parser
möglichst klein sein. Viele Parser (z.B. von Sun, IBM oder Oracle) sind viel zu groß, um in ein
Applet integriert werden zu können. Deshalb bietet sich hier der freie, nicht-validierende XMLParser AElfred von Microstar an. In jedem Fall muß das zurückgegebene XML-Dokument geparst
und die extrahierte Information von JavaBeans visualisiert werden. Es ist angedacht, zumindest
zwei Beans zur Visualisierung anzubieten: eine Bean für die Ausgabe einer Tabelle und eine Bean
zur Ausgabe eines Diagramms (z.B. Balken- oder Kuchendiagramm). Es existieren verschiedene
kommerzielle JavaBeans, die gegen eine entsprechende Lizenzgebühr ins Applet integriert werden
können.
Eine solche JavaBean sollte vollständig vom Benutzer konfigurierbar sein, um individuelle
Auswertungen der operativen Daten vornehmen zu können.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil II: 3. Gliederung der Diplomarbeit
3 Gliederung
14
der Diplomarbeit
3.1 Teil II: Grundlagen
In Teil II dieser Diplomarbeit werden die Grundlagen für das zu implementierende Query-Tool
beschrieben. Diese Grundlagenkapitel sind als allgemeine Einführung zu sehen und nicht als
Analysephase der Diplomarbeit.
In Kapitel 1 geht es um die Extensible Markup Language (XML), ihre Bedeutung und ihre
Auswirkungen. Da XML ein zentrales Thema dieser Diplomarbeit ist, wird der praktischen
Anwendung – generieren und parsen von XML-Dokumenten – ein Großteils des Kapitels
eingeräumt.
Kapitel 2 befaßt sich allgemein mit Komponententechnologien und versucht, das Paradigma der
komponentenorientierten Softwarentwicklung näher zu erläutern. Außerdem wird hier noch eine
Einordnung und ein Vergleich mit etablierten Methoden des Software-Engineerings vorgenommen.
JavaBeans als populäre, Java-basierte Komponententechnologie wird im folgenden Kapitel
besprochen. Dabei werden nach einigen wenigen Grundlagen praktische Aspekte bei der
Entwicklung mit JavaBeans angesprochen.
Das vierte Kapitel gibt eine Einführung in die Remote Method Invocation (RMI). Diese Javabasierte Kommunikationstechnologie ist die Grundlage für die Entwicklung von verteilten
Anwendungen mit Java – insbesondere auch für die Entwicklung von Enterprise JavaBeans (EJBs).
Um EJBs geht es in Kapitel 5. Enterprise JavaBeans ist eine recht junge Technologie, deren
Spezifikation noch nicht vollständig abgeschlossen ist, die aber schon jetzt als wichtige Alternative
zu herkömmlichen Server-Technologien betrachtet wird. Hier wird neben der üblichen Einführung
in Theorie und Praxis auch ein knapper Überblick über verfügbare Tools und Applikationsserver
gegeben.
Als Abschluß des Grundlagenteils gibt das sechste Kapitel eine detaillierte Einführung in die Java
Database Connectivity (JDBC). Diese viel verwendete und mittlerweile etablierte Technologie
ermöglicht den bequemen Zugriff auf relationale Datenbanken aus einer Java-Anwendung heraus.
3.2 Teil III: Anforderungsanalyse und Systemspezifikation
In diesem Teil wird nach einer knappen Zusammenfassung der Anforderungen eine Analyse der
möglichen Systemarchitekturen für das Query-Toll vorgenommen. Hier werden auch die
Grundlagenentscheidungen für die weitere Entwicklung des Tools getroffen und auf der Basis
dieser Entscheidung die Use-Cases (Anwendungsfälle) ermittelt.
3.3 Teil IV: Design
Im der Phase des Grobentwurfs werden die Use-Cases näher untersucht und – falls nötig – mit
Zustands- oder Aktiviätsdiagrammen näher beschrieben. Außerdem werden verschiedene
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil II: 3. Gliederung der Diplomarbeit
15
Benuteroberflächen auf der Basis von existierenden Query-Tools (Seagate Crystal Reports und
Oracle Databrowser) diskutiert und verschiedene Prototypen mit dem GUI-Bilder der
Entwicklungsumgebung JDeveloper erstellt.
Der Feinentwurf enthält verschiedene Klassen- und Komponentendiagramme, welche die
Grundlage für die spätere Implementierung bilden. Dabei wird auch die Einbindung von externen
JavaBeans besprochen.
3.4 Teil V: Implementierung
Hier wird ein grober Überblick über die verwendeten Entwicklungstools gegeben. Außerdem
werden Probleme mit den verschiedenen Java-Versionen und den Web-Browsern näher
beschrieben.
Eine Dokumentation mit Installationshinweisen und Screenshots bildet den Abschluß dieses Teils
der Diplomarbeit.
3.5 Teil VI: Anhang
Im Anhang sind Informationen über das Mapping von SQL-Datentypen zu Java-Datentypen zu
finden. Außerdem wird die – direkt und indirekt – zitierte Literatur aufgeführt und näher
beschrieben.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 1. XML – eXtensible Markup Language
Teil III:
16
Grundlagen
1 XML
– eXtensible Markup
Language
Hypertext is not Technology but Literature. The design of tomorrow's literature determines
what the human race will be able to keep track of and understand. These are not issues to be
left to "technologists"
Ted Nelson
Ted Nelson schrieb als "hypertext guru" Computergeschichte. Er führte den Begriff Hypertext
bereits 1960 ein; 1965 erschien seine erste Veröffentlichung. Nelson's Name ist eng verbunden mit
dem "hypertext and interactive multimedia system" Xanadu, dessen Möglichkeiten weit über das
hinausgehen (sollten), was wir heute als Internet kennen:
Xanadu was meant to be a universal library, a worldwide hypertext publishing tool, a system
to resolve copyright disputes, and a meritocratic forum for discussion and debate...
Die Idee Nelson's war dabei, ein Computer-System zu entwickeln, das die verschlungenen und
divergenten Pfade des menschlichen Denkens nachvollziehen kann. Damit ist gemeint, daß
Information – repräsentiert als Text – inhärent nicht-linear ist. Linearer Text ist das, was wir heute
mit Textverarbeitungssoftware schreiben – ausschließlich zum Ausdruck auf Papier gedacht. Von
diesem Standpunkt aus gesehen ist HTML – und im übrigen auch XML – noch weit davon entfernt,
nicht-lineare Information darzustellen. Viele weitere Informationen und Publikationen von Ted
Nelson sind unter [Nelson 99] zu finden.
Dieses Kapitel führt in das Thema XML (Extensible Markup Language) ein, erklärt die
Unterschiede und Gemeinsamkeiten zwischen HTML, SGML und XML und beschreibt die
Bedeutung dieser Meta-Auszeichnungssprache. Auch wenn ich gelegentlich geschichtliche
Rückblicke eingeschoben habe, soll der Schwerpunkt dieser Einführung nicht auf der
Vergangenheit, sondern in der Zukunft der multimedialen Dokumente liegen.
1.1 Einleitung
Über XML wird in letzter Zeit viel diskutiert. Viele Firmen beschäftigen sich mit XML und sind
dabei, XML-Tools zu entwickeln oder bereits vorhandene Tools auf XML umzustellen. Fast alle
großen Datenbankhersteller bieten bereits die Möglichkeit, XML-Dokumente zu speichern oder
XML-Dokumente aus Tabellen (relationale Datenbanken) oder aus persistenten Objekten
(objektorientierte Datenbanken) zu generieren.
Der Wirbel, der um XML gemacht wird, läßt fast vergessen, daß XML eigentlich auf alten
Konzepten und Ideen basiert. XML ist eine Teilmenge der viel mächtigeren MetaAuszeichnungssprache SGML, die gerade im Verlagswesen breite Verwendung findet. Aufgrund
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 1. XML – eXtensible Markup Language
17
der zu großen Komplexität von SGML wurde eine "SGML-light"-Variante für das Internet
entwickelt: XML.
1.2 Wozu XML?
XML ist also eine für das Internet entwickelte Teilmenge von SGML, die vor allem zur
Speicherung, Übertragung und Darstellung von Informationen dienen soll. Setzt sich XML auf
breiter Ebene durch (das gilt als relativ sicher, da viele große Softwareentwickler wie Microsoft,
Oracle und Sun ihre Unterstützung zugesichert haben), dann bietet XML ein enormes Potential.
Basis für eCommerce
Elecronic Commerce ist ein wichtiger Einsatzort für XML. Es geht beim elektronischen Handel
nicht nur darum, dem Kunden bunte HTML-Seiten zu präsentieren, sondern auch darum, es dem
Kunden einfach zu machen, die gewünschten Artikel zu finden und z.B. Preisvergleiche
anzustellen.
Die Möglichkeit von XML, Metadaten (Daten über Daten) bereitzustellen, ermöglicht es Kunden,
genau die Informationen und Artikel zu finden, die sie suchen. Um mit HTML-basierten
Suchmaschinen gut umgehen zu können und die gewünschten Informationen zu finden, bedarf es
großer Geduld und einiger Erfahrung. Mit XML sollte es erheblich einfacher sein, gewünschte
Informationen zu finden.
Die Mitglieder der (englischsprachigen) XML-Mailinglist von Roger Costello haben ein Projekt
initiiert, das als Referenzimplementierung und Musterbeispiel für eine XML-basierte eCommerceWebsite dient [Costello 99]. Diese Referenz-Website demonstriert eindrucksvoll die Möglichkeiten
und Chancen, die XML dem Electronic Commerce bietet.
Datenaustausch mit EDI und XML
Electronic Data Interchange (EDI) besteht aus einer Sammlung von Nachrichtenformaten und
einem Dictionary, um Daten zwischen Geschäftspartnern auszutauschen. Damit ermöglicht EDI die
Automatisierung von Geschäftsprozessen und bietet damit ein enormes Einsparpotential für
Firmen. Folgende Abbildung (nach [XML/EDI 99]) zeigt die Möglichkeiten, die EDI bietet:
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 1. XML – eXtensible Markup Language
18
Web-Server
E-Mail
Web-Content
+ Catalogue
Customers
Application
Database
Customers
HTML
Order
EDIFACT
Order
Accounting
Database
E-Mail
EDIFACT
Confirm
EDIFACT
Confirm
Billing
Notification
EDI API
EDIFACT
Confirm
Suppliers
EDIFACT
Order
Order
processing
Application
Database
Abbildung III-1: Geschäftsprozesse mit EDI
EDI konnte sich allerdings bislang nur bei großen Firmen durchsetzen, da die nötigen
Implementierungs- und Betriebskosten als sehr hoch eingeschätzt werden [Buxmann 99]. XML soll
nun als Grundlage der Beschreibung von EDI-Dokumenten dienen, um eine einfache und dabei
flexible Möglichkeit der Weiterverarbeitung von Daten zu bieten.
Mit der weiter wachsenden Bedeutung des Internet und damit von XML als universelle WebSprache könnte EDI einen neuen Anstoß geben. Einer der Vorteile, die XML bietet, ist der Zugriff
auf kostengünstige, plattformunabhängige Software, der es auch kleinen Unternehmen möglich
macht, von den Vorteilen des Internet und von EDI zu profitieren [Buxmann 99]. Folgende
Abbildung zeigt die Kombination von XML und EDI, wie sie von der XML/EDI-Group
[XML/EDI 99] beschrieben wird:
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
19
EDIFACT
XML/EDI
Intranet
XML/EDI
XML/EDI
Web Browsers
Communications
Catalogues/Push
XML/EDI
Business Applications
Content/Docs
XML/EDI
XML/EDI
XML/EDI
XML/EDI
Teil III: 1. XML – eXtensible Markup Language
Web Server
Repository/Search
Abbildung III-2: Geschäftsprozesse mit EDI und XML
Diese Grafik macht vor allem deutlich, daß eine XML/EDI-Kombination die Basis für eine sowohl
interne als auch externe Kommunikation bietet. So können auch Firmen ohne teure EDISpezialsoftware in den elektronischen Datenaustausch eingebunden werden.
Plattform- und Medienunabhängiges elektronisches Publishing
Online-Publishing ist oftmals eine schwierige Sache. Die zahlreich vorhandenen
Textverarbeitungsprogramme mit ihren proprietären Formaten machen es schwierig, Dokumente
ins Netz zu bringen, die wirklich auf jedem System angezeigt werden können. Aus diesem Grund
wählt man für Online-Dokumente meist Formate wie Adobe's PDF oder Postscript, die auf nahezu
allen Plattformen gelesen werden können. Leider ist auch hier nicht gewährleistet, daß jeder User
die entsprechenden Dokumente lesen kann, obwohl beispielsweise der Acrobat Reader von Adobe
(zum Lesen von PDF-Dokumenten) zur Basissoftware eines jeden Rechners gehört und auf den
meisten Systemen vorinstalliert ist. Und Postscript ist ohnehin kein gutes Datenaustauschformat, da
Postscript zunächst einmal ein Druckerformat zur Ausgabe von Dokumenten auf einem PostscriptDrucker ist
XML ist hier ein Ausweg aus dem Dschungel der Textformate. Bei Textformaten wie HTML geht
– gerade bei der Generierung aus Dokumenten eines bestimmten Textverarbeitungsprogrammes –
fast immer Information verloren, während mit XML jede nur denkbare Information gespeichert
werden kann. Hersteller von Textverarbeitungsprogrammen wie Microsoft haben bereits
angekündigt, daß in zukünftigen Versionen ihrer Software Export- und Importmöglichkeiten für
XML-Dokumente integriert sein sollen.
1.3 Dokumente
Dieses Unterkapitel nimmt zwar stets Bezug auf XML, dient aber ganz allgemein dazu, erste
Begriffe aus dem Bereich der Dokumentenverarbeitung einzuführen und zu erklären. Was versteht
man nun unter einem Dokument? Ein (Online-) Dokument, wie es etwa in einem Web-Browser
angezeigt wird, besteht aus verschiedenen Elementen – meist noch aus Text, zunehmend aber auch
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 1. XML – eXtensible Markup Language
20
aus multimedialen Elementen wie Sounds und Grafiken; sogar interaktive Filme sind möglich.
Diese Beispiele zeigen, daß der Begriff des Dokumentes, wie er gewöhnlich gebraucht wird, zu
einschränkend ist. Also läßt sich definieren:
Ein Dokument besteht aus dem eigentlichen Inhalt, sowie aus Struktur- und
Darstellungsinformationen. Inhalte sind nicht auf Text eingeschränkt und können multimedialer
Art sein.
Diese Definition macht eines klar: ein solches multimediales Dokument ist nicht als BildschirmPreview eines auszudruckenden Textes, sondern als interaktives Medium zu sehen.
Aufbau von Dokumenten
Prinzipiell lassen sich die Bestandteile eines Dokumentes in drei Gruppen einteilen:
•
Strukturelemente
•
Darstellungsinformationen
•
Inhalt
Die Struktur eines Dokumentes wird durch Strukturelemente wiedergegeben. In XML sind solche
Strukturelemente Tags, in die der eigentliche Inhalt eingefügt wird. Beispiel:
<Überschrift_1> ... </Überschrift_1>
Wie diese Strukturtags genau angeordnet sind und wie sie verschachtelt werden können, wird in
der Dokumenttyp-Definition (DTD) eines XML-Dokumentes angegeben.
Struktur
Wie ist das
Dokument
aufgebaut?
A
B
C
B
C
C
B
C
C
C
Darstellungsinformationen
<Überschrift>
<Standard>
<Code>
Fett
Standard
Wie werden
die Strukturelemente
tatsächlich
dargestellt?
Courier
Inhalt
Text
texttexttexttextte
xttextexttexttextt
exttexttextxttextt
exttexttexttextext
texttexttexttextte
xt
Bilder
Was ist der
Inhalt des
Dokumentes?
- Text
- Bilder
- Multimedia
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 1. XML – eXtensible Markup Language
21
Abbildung III-3: Komponenten eines Dokuments
Für die Darstellung des Dokumentes wird eine Stylesheet-Sprache (z.B. XSL oder CSS)
verwendet, mit der die Bildschirmdarstellung erzeugt wird. Die XML benutzt für die Darstellung
die Extensible Stylesheet Language (XSL), deren Spezifikation zur Zeit (Mitte 1999) leider noch
nicht abgeschlossen ist.
Strukturelemente
Strukturelemente dienen dazu, den inneren Aufbau bzw. die logische Struktur des Dokumentes zu
beschreiben. Die folgende Abbildung (entnommen aus dem iX-Artikel "Revolution der Experten"
[Macherius 97]) zeigt die Struktur eines HTML-Dokumentes. Problematisch ist, daß HTML nicht
nur Strukturelemente bietet, sondern auch Tags, die Darstellungsinformationen beinhalten, die also
für das Layout zuständig sind.
<html>
<html>
<head>
<title>
<head>
HTML
<title>
INHALT
INHALT
</title>
</head>
<body>
<table>
<tr>
<td>
HEAD
BODY
TITLE
TABLE
PCDATA
TR
<body>
<table>
<tr>
<td>
INHALT
INHALT
</td>
<td>
INHALT
TD
TD
PCDATA
PCDATA
<td>
INHALT
</td>
</tr>
</table>
</body>
</html>
Abbildung III-4: HTML-Dokument als Text, Schachtelbild und Strukturbaum
Darstellungselemente
Diese Elemente geben konkret an, wie der Dokumenteninhalt auf dem Bildschirm ausgegeben
werden soll, d.h. ob beispielsweise Text in Standardschrift oder kursiv ausgegeben werden soll. In
HTML sind Layout und Struktur eines Dokumentes untrennbar miteinander verbunden. Es besteht
in HTML allerdings auch die Möglichkeit, Cascading Style Sheets (CSS) zu verwenden, was zu
einer größeren Flexibilität führt.
Generic Markup
Was bedeutet nun der Begriff Generic Markup? Markup bedeutet "Auszeichnung" und generic
heißt übersetzt "artmäßig". Markup ist jede zusätzliche Information, die über den reinen Inhalt
eines Dokumentes hinausgeht – also etwas über die Art der Textstelle aussagt. In diesem Sinne
werden Schriftarten, Schriftgröße, aber auch erweiterte Features wie Fußnoten oder
Inhaltsverzeichnisse als Markup bezeichnet.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 1. XML – eXtensible Markup Language
22
1.4 HTML, SGML und XML – Eine Einordnung
HTML
Die Sprache des Internet ist HTML. Fast alle Internet-Seiten verwenden diese
Auszeichnungssprache, um Dokumente im Netz darzustellen. HTML ist 1989 aus der SGML
(Standard Generalized Markup Language) entstanden und hat seitdem eine große Verbreitung
gefunden. Offensichtlicher Vorteil von HTML ist die Einfachheit der Sprache, d.h. es ist relativ
einfach, ein HTML-Dokument zu erstellen, sofern nicht ohnehin ein WYSIWYG-Editor verwendet
wird.
Leider hat HTML auch viele Nachteile. So gibt es nur eine beschränkte Anzahl von Elementtypen
(z.B. <TITLE>, <HEAD> und <BODY> für die Strukturierung oder <EM> und <SUB> für
Hervorhebungen, also für Darstellungsinformationen). Da diese wenigen Elementtypen nicht
ausreichten, um komplexere Dokumente zu erstellen, wurde der HTML-Standard vor allem von
den großen Browser-Firmen (Netscape und Microsoft) ständig erweitert und läuft nun Gefahr, in
verschiedene Dialekte auseinander zu driften. Auf vielen Websites findet man Hinweise wie "Best
viewed with XXX Version YYY". Der Internet-Surfer, der gerade nicht den richtigen Browser oder
die richtige Version desselben hat, kann die Seite meist nur eingeschränkt lesen – obwohl die
relevante Information ohnehin meist nur aus Text besteht.
HTML basiert auf einer einzigen Dokumenttyp-Definition (DTD) der SGML. Das heißt, daß alle
möglichen Web-Dokumente auf einer einzigen Struktur basieren (bzw. basieren sollten). Das
Spektrum der Internet-Anwendungen reicht jedoch von einfachen Textdokumenten ohne Grafiken
bis hin zu komplexen, grafischen Web-Seiten mit multimedialen Elementen und interaktivem
Inhalt. So ist es kein Wunder, daß HTML in seiner einfachsten Form nur noch von wenigen WebSeiten verwendet wird. 1
Ursprünglich sollte HTML nur Informationen zur Struktur und zum Inhalt des Dokuments
kodieren. Allerdings wurden schon recht schnell Stilelemente wie <EM> oder <SUB> für
Hervorhebungen eingeführt. Um weitere HTML-Beschränkungen zu umgehen, führten Microsoft
und Netscape noch eigene Skriptsprachen (JavaScript, VBScript (VB: Visual Basic)) ein, was nun
endgültig dazu führte, daß Firmen mit eigener Web-Page mehrere Versionen ihrer Seite schreiben
müssen, um auch wirklich jeden Browser in jeder Version zu unterstützen.
Ein anderes Problem mit HTML ist die Implementierung von professionellen WebInformationssystemen, da eine Nutzung der mit HTML dargestellten Daten (die z.B. aus einer
Datenbank generiert wurden) nicht möglich ist. Es bleibt nur das Cut & Paste in eine Anwendung
(z.B. Microsoft Excel) und die aufwendige (größtenteils manuelle) Aufbereitung der
Informationen. So ist es schwierig, Web-Informationssysteme zu entwickeln, die tatsächlich die
Daten nicht nur darstellen, sondern auch analysieren, speichern und weiterverarbeiten können. Eine
Lösung dieses Problems wäre die Benutzung von SGML (vgl. folgenden Abschnitt).
SGML
SGML ist eine umfangreiche, komplexe Meta-Auszeichnungssprache, mit der Dokumente aller
Bereiche und Medien beschrieben werden können. SGML (auch bekannt als ISO-Norm 8879,
nachzulesen unter [ISO 8879]) ist allerdings eine Sprache, zu deren Beherrschung man viel Zeit
1
Viele Seiten verwenden sogar spezielle Plug-Ins wie Macromedia Shockwave, die zwar beeindruckende
Effekte (audiovisuell) erlauben, aber eben eigenständige, plattformabhängige Programme sind und von daher
fürs Web eigentlich nicht geeignet sind. Man muß allerdings dazu sagen, daß die meisten relevanten PCPlattformen von Macromedia unterstützt werden.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 1. XML – eXtensible Markup Language
23
investieren muß. Für das Internet ist SGML eindeutig zu kompliziert,
komplizierten Aspekte von SGML kaum verwendet werden.
zumal gerade die
Die Komplexität von SGML war der Grund für die Entwicklung von XML. Das Ziel, eine
mächtige Meta-Auszeichnungssprache für das Internet zu schaffen, ohne die Beschränkungen von
HTML und ohne die Komplexität von SGML wurde gut erreicht: Die wesentlichen Bestandteile
und Ideen von SGML (Trennung von Struktur, Layout und Inhalt) wurden beibehalten. Das
Ergebnis war eine Sprache, deren formale Spezifikation auf 33 Seiten Platz findet – die SGMLSpezifkation benötigt 500 Seiten... [Macherius 97].
Nähere Informationen zu SGML findet man im iX-Artikel "Revolution der Experten" [Macherius
97] (daraus stammen auch die meisten Informationen dieses Abschnitts) und auf der SGML/XMLSeite [SGML/XML 99].
Einordnung von SGML, XML und HTML
Die Unterschiede und Gemeinsamkeiten zwischen SGML, XML und HTML lassen sich einfach
auf den Punkt bringen: HTML ist eine Anwendung von SGML, XML ist eine Teilmenge von
SGML. Da SGML eine Metasprache ist, impliziert der Ausdruck Teilmenge, daß auch XML eine
Metasprache ist. Zur besseren Übersicht des Sachverhalts dient folgende Grafik:
SGML
ist
Teilmenge
von
ist
Anwendung
von (DTD)
DSSL
Teil der
Funktionen
von
XSL
XML
ist (bald)
Anwendung
von (DTD)
CSS
HTML
Abbildung III-5: Einordung von SGML, XML und HTML
Für HTML existiert eine sogenannte Dokumenttyp-Definition (DTD), die in SGML geschrieben
wurde und sämtliche HTML-Elemente (Tags) definiert - theoretisch zumindest. In der Praxis
werden aufgrund proprietärer Erweiterungen der Hersteller der großen Web-Browser weitaus mehr
Tags verwendet.
Entwurfsziele von XML
Es dürfen natürlich in keiner Arbeit zum Thema XML die Entwurfsziele fehlen. So auch nicht in
dieser Diplomarbeit:
1. XML soll sich im Internet auf einfache Weise nutzen lassen.
2. XML soll ein breites Spektrum von Anwendungen unterstützen.
3. XML soll zu SGML kompatibel sein.
4. Es soll einfach sein, Programme zu schreiben, die XML-Dokumente verarbeiten.
5. Die Zahl optionaler Merkmale in XML soll minimal sein, idealerweise Null.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 1. XML – eXtensible Markup Language
24
6. XML-Dokumente sollten für Menschen lesbar und angemessen verständlich sein.
7. Der XML-Entwurf sollte zügig abgefaßt sein.
8. Der Entwurf von XML soll formal und präzise sein.
9. XML-Dokumente sollen leicht zu erstellen sein.
10. Knappheit von XML-Markup ist von minimaler Bedeutung.
Diese deutsche Übersetzung stammt aus [BehmeMintert 98b] und ist in englischer Sprache unter
[W3C 98a] zu finden.
1.5 Struktur, Darstellung und Inhalt
Da XML eine Metasprache zur Beschreibung von Auszeichnungssprachen ist, läßt sie sich nicht
"direkt" wie etwa HTML verwenden. Also muß man eigene Auszeichnungssprachen definieren,
was nicht so schwierig ist, wie es sich anhört. Ein XML-Dokument besteht per Definition aus den
Komponenten Struktur, Darstellung und Inhalt. Folgende Abbildung gibt einen Überblick:
XML
Struktur
Dokumenttyp-Definition (DTD)
.DTD
Darstellung
Extensible Stylesheet Language (XSL)
.XSL
Inhalt
XML-Daten (XML-Instanz)
.XML
Abbildung III-6: Struktur, Darstellung und Inhalt mit der XML
XML-Daten (oder XML-Instanzen) lassen sich nur formatiert anzeigen, wenn die entsprechenden
Darstellungsinformationen gegeben sind. Sind XML-Daten und Informationen für die Darstellung
vorhanden, wird das XML-Dokument wohlgeformt genannt. Eine DTD ist zur formatierten
Ausgabe auf dem Bildschirm also nicht unbedingt erforderlich. Soll ein XML-Dokument auch
gültig sein, muß allerdings die DTD vorhanden sein. XML-Parser, die eine DTD lesen und sie mit
der tatsächlichen Struktur des Dokuments vergleichen, heißen validierende Parser; andernfalls
werden sie nicht-validierend genannt.2
Die folgenden Abschnitte gehen etwas genauer auf die einzelnen Bestandteile eines XMLDokumentes ein. Hier werden auch konkrete Beispiele für DTDs, Stylesheets und XML-Daten
aufgelisted.
Struktur: Dokumenttyp-Definition (DTD)
Die DTD dient dazu, eine bestimmte XML-Sprache zu definieren. Sie beschreibt also den
strukturellen Aufbau und die logischen Elemente eines Dokumenttyps. Ein Dokumenttyp ist eine
2
Die HTML-Arbeitsgruppe des W3C ist zur Zeit (Mitte 1999) dabei, HTML als Satz von XML-DTDs neu
zu definieren. Beispiele für DTD-Module sind Tabellen, Mathematik und Multimedia. Grund für den
modularen Aufbau ist, die Komplexität der HTML-DTD überschaubar zu halten und es gleichzeitig HTMLAutoren zu ermöglichen, die einzelnen Module in ihre Dokumente einzubinden. Warum wird HTML
überhaupt noch einmal neu in XML definiert? Diese Neu-Definition ist als langsamer Umstieg auf XML
gedacht. HTML-AutorInnen müssen sich, wenn die entsprechenden DTDs einmal vorliegen, nicht mehr um
XML als Sprache kümmern. Sie können einfach weiter in HTML ihre Websites schreiben – die
zugrundeliegende XML bleibt also für Web-AutorInnen vollkommen transparent.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 1. XML – eXtensible Markup Language
25
Klasse von Dokumenten gleicher Struktur. Die DTD ist also nützlich und sinnvoll, wenn mehrere
isomorphe (strukturgleiche) XML-Dokumente geschrieben werden müssen. So könnte einE
ProfessorIn beispielsweise eine DTD für den Aufbau von Diplomarbeiten schreiben, die dann
Studierende verwenden müssen.
Eine solche DTD würde dann dazu führen, daß die Diplomarbeiten zwar die gleiche Struktur, aber
nicht notwendigerweise das gleiche Aussehen haben, da die Formatierung mit einem Stylesheet
(z.B. XSL) erfolgt.
Folgende DTD stammt von einer populären XML-Website [Bosak 99] mit den Texten von
Shakespeare:




<!ELEMENT PLAY (TITLE, FM, PERSONAE, SCNDESCR, PLAYSUBT,
INDUCT?, PROLOGUE?, ACT+, EPILOGUE?)>
<!ELEMENT TITLE (#PCDATA)>
<!ELEMENT FM
(P+)>
<!ELEMENT P
(#PCDATA)>
<!ELEMENT PERSONAE (TITLE, (PERSONA | PGROUP)+)>
<!ELEMENT PGROUP (PERSONA+, GRPDESCR)>
<!ELEMENT PERSONA (#PCDATA)>
<!ELEMENT GRPDESCR (#PCDATA)>
<!ELEMENT SCNDESCR (#PCDATA)>
<!ELEMENT PLAYSUBT (#PCDATA)>
<!ELEMENT INDUCT (TITLE, SUBTITLE*,
(SCENE+|(SPEECH|STAGEDIR|SUBHEAD)+))>
<!ELEMENT ACT
(TITLE, SUBTITLE*, PROLOGUE?, SCENE+,
ILOGUE?)>
<!ELEMENT SCENE (TITLE, SUBTITLE*, (SPEECH | STAGEDIR |
SUBHEAD)+)>
<!ELEMENT PROLOGUE (TITLE, SUBTITLE*, (STAGEDIR | SPEECH)+)>
<!ELEMENT EPILOGUE (TITLE, SUBTITLE*, (STAGEDIR | SPEECH)+)>
<!ELEMENT SPEECH (SPEAKER+, (LINE | STAGEDIR | SUBHEAD)+)>
<!ELEMENT SPEAKER (#PCDATA)>
<!ELEMENT LINE (#PCDATA | STAGEDIR)*>
<!ELEMENT STAGEDIR (#PCDATA)>
<!ELEMENT SUBTITLE (#PCDATA)>
<!ELEMENT SUBHEAD (#PCDATA)>
Codebeispiel III-1: Shakespeare-DTD
Komplexe DTDs wie die Shakespeare-DTD zu schreiben, erfordert also Programmierkenntnisse.
Allerdings gibt es bereits jetzt im Internet eine Vielzahl von frei verfügbaren DTDs für die
verschiedensten Zwecke.
Die DTD ist also eine Grammatik, deren Produktionsregeln einen bestimmten Dokumenttyp
definieren. Schreibt man ein wohlgeformtes XML-Dokument, d.h. insbesondere, daß alle
geöffneten Tags auch wieder geschlossen werden müssen, dann benötigt man die DTD nicht
unbedingt für die Ausgabe des Dokumentes, da die Strukturinformationen des Dokumentes ja
implizit im XML-Dokument vorhanden sind. Aus diesem Grund unterscheidet man auch
validierende und nicht-validierende XML-Parser. Die validierenden Parser lesen sowohl die XMLDaten als auch die DTD und prüfen, ob die XML-Instanz gültig ist. Nicht-validierende Parser sind
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 1. XML – eXtensible Markup Language
26
sinnvoll, wenn nur eine einzige Instanz eines Dokumenttyps geschrieben wurde, also keine
strukturelle Übereinstimmung mit einer bestimmten DTD vorhanden sein muß.
Darstellung: Extensible Stylesheet Language (XSL)
Zur Darstellung von XML-Dokumenten soll die Extensible Stylesheet Language (XSL) verwendet
werden. Wozu dient nun ein solches, z.B. in XSL verfaßtes Stylesheet? Mit einem Stylesheet ist es
möglich, die Art der Darstellung auf dem Bildschirm genau zu spezifizieren. Der Vorteil eines
Stylesheets ist, daß das Aussehen eines Dokumentes beliebig verändert werden kann, ohne seine
Struktur zu ändern. Wird beispielsweise CSS (Cascading Style Sheet) zur Darstellung von HTMLDokumenten verwendet, dann kann man sein Dokument relativ frei gestalten, ohne dabei neue,
darstellungspezifische HTML-Tags verwenden zu müssen. Dies führt – bei einer entsprechenden
Verbreitung von Stylesheet-Prozessoren (z.B. durch Implementierung in einem Web-Browser) – zu
einer weitgehenden Plattformunabhängigkeit.
Für die Formatierung von SGML-Dokumenten ist die DSSSL (Document Style Semantics and
Specification Language) zuständig. Die DSSSL basiert auf einem Lisp-Dialekt namens Scheme.
Scheme ist somit eine deklarative Programmiersprache; ideal um Formatierungsangaben zu
deklarieren, leider jedoch zu kompliziert, um sie Nicht-Fachleuten zumuten zu können.
Aus diesem Grund wurde speziell für XML die Extensible Stylesheet Language (XSL) entwickelt,
die allerdings auch alles andere als leicht verständlich ist. Wie auch immer, XSL ist also die
Sprache, in der XML-Darstellungsinformationen deklariert werden. Leider ist der Entwurf von
XSL noch nicht abgeschlossen, was auch in näherer Zukunft ein Problem für EntwicklerInnen
bleiben wird.
Wozu wurde überhaupt XSL entwickelt, wo doch schon seit längerem an CSS gearbeitet wird und
CSS auch verwendet werden kann, um XML-Dokumente anzuzeigen? Hauptunterschied zwischen
CSS und XSL ist die Möglichkeit von XSL, Dokumente in ein anderes Format zu transformieren.
Mit XSLT (XSL Transformations) - einer Untermenge von XSL - können XML-Dokumente z.B. in
HTML/CSS-Dokumente umgewandelt werden.
Tatsächlich ist die Möglichkeit der Transformation zur Zeit der Hauptgrund für die Verwendung
von XSL. Der Internet Explorer 5.0 z.B. verwendet XSL, um XML-Dokumente in HTML/CSSDokumente umzuwandeln und am Bildschirm anzuzeigen. Es wird also kein "echtes" XML
dargestellt, sondern lediglich ein HTML-Dokument. Die Unterschiede zwischen CSS und XSL
werden in folgender Tabelle (aus [W3C 97]) nochmals dargestellt:
CSS
XSL
Verwendung mit HTML?
ja
nein
Verwendung mit XML?
ja
ja
Dokument-Transformation möglich?
nein
ja
Syntax
CSS
XML
Tabelle III-1: Unterschiede zwischen CSS und XSL
Nähere Einzelheiten zu XSLT (Transformation) und XSL (Formatierungssemantik) sind im
folgenden Unterkapitel zu finden.
Inhalt: XML-Daten
Der Inhalt eines Dokumentes kann sowohl textueller als auch multimedialer Art sein. Will man
beispielsweise ein MPEG-Video in das Dokument einbauen, so muß dieses Video zuvor als Enitity
deklariert werden:
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 1. XML – eXtensible Markup Language
27
<!ENTITY mein_video SYSTEM "videos/video1.mpeg" NDATA MPEG>
Eine solche Entity kann dann über &mein_video im Hauptteil des XML-Dokumentes
angesprochen werden. Um obige Entity-Deklaration aber auch verwenden zu können, muß eine
(möglichst externe) Notations-Deklaration geschrieben werden, damit z.B. ein Web-Browser zur
Darstellung dieses Inhalts ein Plug-In laden kann:
<!NOTATION MPEG SYSTEM "C:\winnt\system32\mplay32.exe">
Will man also Daten ins XML-Dokument einbinden, die nicht Bestandteil von XML sind, so muß
man den Typ NDATA verwenden. NDATA zeigt an, daß es sich bei dem Datentyp der
entsprechenden Entity nicht um XML-Daten handelt, sondern um ein beliebiges anderes
Datenformat, das (zumeist extern) deklariert wird. In obigem Beispiel wird der Datentyp MPEG
deklariert und näher beschrieben.
1.6 XSL – Extensible Stylesheet Language
Die Extensible Stylesheet Language (XSL) war ursprünglich sowohl zur Formatierung von
Objekten als auch zur Transformation von einer XML-Instanz (oder XML-Sprache) in eine andere
XML-Instanz gedacht. Prinzipiell ist dies immer noch richtig, allerdings hat das W3C jetzt (April
1999) eine Aufteilung der XSL in zwei Untermengen beschlossen:
•
XSL für die Formatierung von Objekten
•
XSLT für die Transformation in eine andere XML-Sprache
Außerdem wurde die XML Path Language (XPath) aus der XSL-Spezifikation herausgenommen.
Dieser Teil der XSL ist jetzt in einer eigenen Spezifikation zu finden.
XSL und XSLT
Die Extensible Stylesheet Language besteht also aus
Formatierungsspezifikation
von
XSL
(Semantik
der
Transformationsspezifkation, die jetzt den Namen XSLT trägt:
zwei Untermengen:
Formatierung)
und
Der
der
XSL
XSL
Transformationsspezifikation
(XSLT)
XSL
Formatierungsspezifikation
Abbildung III-7: XSL und Untermengen
XSLT dient dazu, einen XML-Strukturbaum in einen anderen XML-Strukturbaum umzuwandeln.
Der entstehende neue Strukturbaum kann dabei völlig vom Original verschieden sein. Die
Formatierungsspezifikation dient dazu, einen solchen Strukturbaum am Bildschirm darzustellen.
Die Trennung von Transformation und Formatierung macht es möglich, eine XML-Sprache in eine
andere mittels XSLT umzuwandeln und für die Darstellung eine andere Stylesheet-Sprache (z.B.
CSS) zu verwenden. XSLT ist also (zumindest prinzipiell) unabhängig von der
Formatierungsspezifikation.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 1. XML – eXtensible Markup Language
28
CSS und XSL
Die Aufteilung der XSL-Spezifikation in zwei Teile macht es leichter möglich, CSS und XSL
zusammen zu verwenden. So kann mit XSLT eine komplexere Transformation durchgeführt und
mit CSS am Bildschirm formatiert dargestellt werden. XSL und XSLT sind jedoch
zusammengenommen sehr viel mächtiger als eine CSS/XSLT-Kombination, da bei einer reinen
XSL-Beschreibung ausschließlich die XML-Sprache verwendet werden muß. So hat sich eigentlich
nicht viel geändert; es wurde lediglich eine Aufteilung einer umfangreichen Spezifkation in zwei
(komplementäre) Untermengen vorgenommen.
Transformationen mit XSLT
Soll eine XML-Instanz in eine andere XML-Instanz transformiert werden, so wird eine XSL(T)
Engine (XSL Prozessor) eingesetzt. Der genaue Transformationsvorgang ist in folgender
Abbildung (aus [Holman 99]) gut dargestellt:
Abbildung III-8: Überblick über das XSL Verarbeitungs-Modell (aus [Holman 99])
Das Transformationsmodell basiert auf sogenannten Templates. Die Verarbeitung eines Source
Node Trees (der Baumdarstellung der Struktur des XML-Dokumentes) geschieht über den
Vergleich dieses Baumes mit dem Stylesheet Node Tree. Der Source Node Tree wird also mit dem
Template – dem Stylesheet Node Tree – verglichen und in einen Result Node Tree umgewandelt.
Dieses Ergebnis ist wohlgemerkt kein XML-Dokument sondern lediglich eine Repräsentation des
Ergebnisdokumentes. Der Result Node Tree muß nun – beispielsweise über CSS – für den
Bildschirm (oder für den Drucker) formatiert werden.
Hauptvorteil der Transformation ist, daß ein einziges XML-Dokument die Basis für mehrere
verschiedene Dokumente sein kann. Es ist damit möglich, aus einem einfach strukturierten
Dokument zusätzliche Informationen zu gewinnen. Man kann z.B. ein Inhaltsverzeichnis oder eine
Tabelle mit allen Web-Links des Dokumentes automatisch erstellen. Gerade bei umfangreichen
Web-Präsenzen mit täglicher Aktualisierung kann man durch die Automatisierung der Web-SeitenErstellung viel Zeit einsparen.
XML-Dokumente mit XSL in HTML transformieren
Die in diesem Abschnitt gezeigten Beispiele wurden aus dem XSL-Tutorial von Norman Walsh
[WalshGrosso 99] entnommen. Empfehlenswert ist aus Microsoft's XSL-Tutorial [Microsoft 99].
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 1. XML – eXtensible Markup Language
29
XSL(T) ist ein sehr mächtiges Hilfsmittel zur Darstellung von XML-Dokumenten. Der folgende
Text soll deshalb nur die prinzipielle Funktionsweise von XSL erläutern. Für weiterführende
Informationen und komplette Beispiele sei auf [WalshGrosso 99] und [Microsoft 99] verwiesen.
Es geht in folgendem Beispiel um die Transformation von Kochrezepten. Kochrezepte haben
prinzipiell folgende Struktur:
<recipe><name>...</name>
<description>...</description>
<note>...</note>
<note status="credit"><name>Cookbook</name> source credit</note>
<ingredient-list yields="...">
<ingredient quantity="..." units="...">...</ingredient>
...
</ingredient-list>
<preparation preptime="...">
<step>...</step>
...
</preparation>
</recipe>
Codebeispiel III-2: Struktur von Kochrezepten mit XML
Es können nun über sogenannte Patterns bestimmte Elemente kontextbezogen aus dem Dokument
gefiltert werden:
<element type="recipe">
<target-element type="name"/>
</element>
Codebeispiel III-3: XSL-Pattern
Mit diesem Pattern werden nur Namenselemente erfaßt, die unmittelbar nach dem recipe-Element
stehen:
<?xml version="1.0">
<recipe servings="25"><name>Fried Vegetables</name>
<description>
...
</description>
<note status="credit"><name>The Indian Cookbook</name>
by Sumana Ray.</note>
Codebeispiel III-4: Anwendung eines Patterns
Durch Anwendung obigen Musters erhält man also nur Fried Vegetables, nicht aber The Indian
Cookbook. Nun kann man das XML-Dokument z.B. in HTML transformieren:
<rule>
<element type="recipe">
<target-element type="name"/>
</element>
<H1 STYLE="color: red"><children/></H1>
</rule>
Codebeispiel III-5: Transformation von XML in HTML
Mit diesem Code werden Rezeptnamen in roter Schrift und als Überschrift (<H1>) dargestellt. In
ähnlicher Weise ist es auch möglich, XML-Dokumente z.B. in RTF- oder PDF-Dokumente zu
transformieren. Bei komplexen Dokumenten ist dabei ein relativ hoher Programmieraufwand nötig.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 1. XML – eXtensible Markup Language
30
1.7 XML und Java
Java software is portable code ... XML is portable data.
Dave Brownell, Designer von Sun's Project X
Dave Brownell hat es hier treffend dargestellt: Java und XML sind geradezu ideal
aufeinander abgestimmt. Mit Java kann Code über das Internet als Applet in einem Web-Browser
ausgeführt werden. Als universelles Datenübertragungsformat zur Darstellung von Text, Grafiken
und Multimedia dient XML.
Ein weiterer Grund für die Beliebtheit von Java im XML-Umfeld ist, daß sowohl XML als auch
Java sämtliche Unicode-Zeichen erlauben. Es ist kaum möglich, XML-konforme Applikationen zu
schreiben, wenn die verwendete Programmiersprache die Unicode-Zeichensätze nicht unterstützt.
Von Vorteil ist dies besonders, wenn die XML-Applikation z.B. asiatische Zeichensätze
verarbeiten muß – der Programmierer muß keinen speziellen Zusatzcode schreiben.
Die Firma Sun Microsystems bietet einen in Java implementierten XML-Parser unter dem Namen
"Project X" an. Das Ziel ist die vollständige Integration von XML in Java als Klassenbibliothek.
Zur Zeit (August 1999) existieren allerdings noch keine Informationen, wann mit einer solchen
Integration zu rechnen ist.
1.8 Dokumenttyp-Definition (DTD)
Formale Strukturen zu isolieren, bedeutet zugleich, ihre Relevanz zu erkennen; relevant aber
sind sie nur im Hinblick auf eine umfassende Hypothese, in welcher der Sinn des Kunstwerks
bereits antizipiert wird.
Umberto Eco
Dies ist ein eher formales Unterkapitel, das zu einem guten Teil aus Definitionen und
Beschreibungen der XML-Grammatik besteht, das jedoch viele wichtige und gerade im nächsten
Kapitel zahlreich verwendete Begriffe näher erklärt.
Grammatik
Eine (natürliche oder formale) Sprache basiert auf einer Grammatik. Eine Grammatik besteht aus
Regeln, die die Syntax einer Sprache beschreiben. Die Spezifikation, die die korrekte Konstruktion
von Sätzen beschreibt, nennt man Syntax einer Sprache. Die Spezifikation der Bedeutung der Sätze
nennt man Semantik.
Die Grammatik einer formalen Sprache wie XML besteht aus folgenden Bestandteilen:
•
Einer Menge von Terminalsymbolen. Terminalsymbole sind bei einer Programmiersprache
Zeichen oder Zeichenfolgen wie if, then oder ==.
•
Einer Menge von Nichtterminalsymbolen. Nichtterminalsymbole sind z.B. <Anweisung>,
<Programm> oder <Klasse>. Zur Unterscheidung von Terminalsymbolen setzt man
Nichtterminalsymbole meist in <spitze Klammern>.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 1. XML – eXtensible Markup Language
31
•
Einer Menge von Grammatikregeln (Produktionssystem), welche die Syntax der Sprache
festlegen oder die beschreiben, wie man aus bereits bestehenden Konstrukten neue
Konstrukte gewinnen kann.
•
Ein Startsymbol oder Axiom, das stets ein Nichtterminalsymbol ist. In
Programmiersprachen wie Java ist das Startsymbol meist <Programm>, in XML ist das
Startsymbol der sogenannte <Prolog>.
Man unterscheidet nun verschiedene Arten von Grammatiken: kontextfreie, kontextsensitive,
lineare und reguläre Grammatiken. Für (imperative) Programmiersprachen verwendet man
kontextfreie Grammatiken. Kontextfreie Grammatiken (oder Typ-2-Grammatiken in der ChomskyHierarchie) können z.B. in Backus-Naur-Form (BNF) oder in Form eines Syntaxbaumes dargestellt
werden. Auch die XML-DTD ist eine solche Grammatik, die als Strukturbaum dargestellt werden
kann.
Eine Grammatik ist dann kontextfrei, wenn ein Nichtterminalsymbol vom entsprechenden
Produktionssystem unabhängig vom benachbart stehenden Zeichen – also unabhängig vom Kontext
– ersetzt wird. Ableitungen in solchen Grammatiken lassen sich stets als Ableitungsbäume
darstellen. Eine Sprache, die durch eine kontextfreie Grammatik erzeugt wird, nennt man
kontextfreie Sprache.
DTD: Grammatik für XML
Die XML-DTD ist eine Grammatik, die auch als BNF oder als Syntaxbaum darstellbar ist. Mit
einer solchen DTD wird eine XML-Instanz erzeugt. Man kann beispielsweise eine DokumenttypDefinition für HTML schreiben, um in HTML gültige XML-Dokumente zu verfassen. In dieser
Diplomarbeit werden SQL-Anfragen gegen eine relationale Datenbank gestellt. Die
Anfrageergebnisse sollen XML-codiert an den Client weitergegeben werden. Dazu muß für jede
Anfrage eine neue DTD generiert werden, um etwa die Spaltennamen zu integrieren. Da die zu
generierenden DTDs prinzipiell ähnlich aufgebaut sind (sie unterscheiden sich lediglich in einigen
Element- und Attributnamen), läßt sich eine Schablone verwenden, bei der nur die betreffenden
Namen ausgetauscht werden. Näheres dazu ist im XML-Kapitel des Grobentwurfs zu finden.
Es ist auch möglich (und sinnvoll), DTDs zu verschachteln. Denkbar ist beispielsweise eine BasisDTD, die – kontextbezogen – auf andere DTDs verweist.
Anzumerken ist noch, daß XML-Dokumente prinzipiell nur ein Wurzelelement haben. Das macht
es erheblich einfacher zu verifizieren, daß ein Dokument vollständig ist. In dieser Diplomarbeit
wird davon ausgegangen, daß nur eine einzige Tabelle zurückgegeben wird.
Es ist prinzipiell möglich, eine DTD in eine äquivalente BNF (Backus Naur Form) zu
transformieren. Ein Beispiel:
<!ELEMENT row (columnName)*>
Diesen DTD-Ausschnitt kann man in BNF so schreiben:
row ::= (columnName)*
Codebeispiel III-6: DTD und äquivalente BNF
Die Äquivalenz von DTD und BNF ist in der Praxis oft nützlich. So existieren zahlreiche
Grammatiken in BNF, die sich leicht in eine XML-DTD transformieren lassen.
Wohlgeformtheit
Dem Begriff der Wohlgeformtheit begegnet man im XML-Bereich recht häufig. Unter einem
wohlgeformten Dokument versteht man ganz allgemein ein Dokument, das sich fehlerfrei parsen
läßt, d.h. das in sich schlüssig und fehlerfrei ist. Wichtig ist zu beachten, daß XML fordert,
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 1. XML – eXtensible Markup Language
32
geöffnete Tags auch wieder zu schließen. Bei HTML sind solche Fehler oft unproblematisch; bei
XML verletzen sie die Wohlgeformtheitsregel.
Gültigkeit
Die Gültigkeit eines wohlgeformten XML-Dokumentes wird von einem validierenden Parser
aufgrund einer bestimmten DTD nachgewiesen. Das heißt, der Parser vergleicht den strukturellen
Aufbau des XML-Dokumentes mit einer vorgegebenen Dokumenttyp-Definition. Geprüft wird im
einzelnen:
•
Sind alle verwendeten Tags in der DTD deklariert?
•
Stimmt die Struktur des XML-Dokumentes mit der DTD überein?
Was bringt es nun, gültige XML-Dokumente zu haben? Zum Beispiel kann man die
entsprechendende DTD als Vorlage für eine Reihe strukturgleicher Dokumente verwenden.
Wichtig ist dies gerade, wenn XML als firmeninternes Datenaustauschformat verwendet werden
soll. Die MitarbeiterInnen einer Firma können sich also darauf verlassen, daß ihre Dokumente zum
Firmenstandard konform sind.
1.9 Parsen von XML-Dokumenten
Dieses Unterkapitel beschreibt auf der Grundlage der Theorie des vorigen Unterkapitels die
softwaretechnische Umsetzung. Es existieren zahlreiche – und meist freie – XML-Parser, und zwar
sowohl von den großen Softwarefirmen (Sun, Microsoft, IBM, Oracle, ..) als auch von kleinen
Anbietern oder unabhängigen Entwicklern (Microstar, James Clark, ..) Die XML-Parser von Sun,
IBM und Oracle sind zwar am komfortabelsten, haben aber leider einen großen Nachteil: Sie sind
meist sehr umfangreich – zu umfangreich für ein Java-Applet, das aus dem Web heruntergeladen
werden muß.
Im folgenden werden die zwei prinzipiellen Arten von XML-Schnittstellen beschrieben: DOM und
SAX. DOM (Document Object Model) ist eine Spezifikation des W3C [W3C 1998b], die eine
einheitliche, objektorientierte Schnittstelle auf ein XML-Dokument zur Verfügung stellt. SAX
(Simple API for XML) ist eine ereignisbasierte API, welche von Mitgliedern der XML-DEV
Mailingliste entwickelt wurde, um XML-Dokumente zu parsen, ohne einen aufwendigen
Strukturbaum generieren zu müssen.
XML-Verarbeitung
Zur Verarbeitung von XML-Dokumenten (d.h. vor allem: zum Parsen) benötigt man eine API,
welche als Schnittstelle zwischen Dokument und Verarbeitungssoftware fungiert. Prinzipiell
unterscheidet man dabei zwei Arten von XML APIs:
•
baumbasierte APIs und
•
ereignisbasierte APIs
Eine baumbasierte API generiert aus einem XML-Dokument eine Baumstruktur, deren Knoten von
Objekten oder Komponenten (d.h. JavaBeans bei Verwendung von Java) repräsentiert werden. Die
Anwendung kann dann die Dokumentstruktur analysieren und den Baum beliebig traversieren.
Das W3C hat in seiner DOM-Spezifikation [W3C 98b] einen Standard für eine baumbasierte
Schnittstelle zu XML entwickelt. Die Implementierungungen dieser Spezifikation sind
typischerweise recht komfortabel, haben aber einen erheblich größeren Codeumfang als die
entsprechenden SAX-Implementierungen.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 1. XML – eXtensible Markup Language
33
Problematisch bei baumbasierten APIs ist außerdem eine gewisse Ineffizienz in bestimmten Fällen.
Wenn das XML-Dokument sehr groß ist, sind die Kosten für die Generierung eines Strukturbaumes
sehr hoch. Bei großen Dokumenten ist es oft am sinnvollsten, die Struktur direkt auf der
Festspeicherplatte zu generieren und auch von dort wieder einzulesen. Bei einer reinen
Strukturtransformation ist dies oftmals zu aufwendig.
Ereignisbasierte APIs (z.B. SAX) erlauben die Registrierung einer Anwendung beim SAX-Parser,
um Callback-Aufrufe (also Ereignisse) zu erhalten. Hier gibt es Standardmethoden, die bei einem
Start- oder Endtag oder bei Auflösung externer Entitäten aufgerufen werden. Auf diese Weise kann
natürlich auch ein Strukturbaum aufgebaut werden; meist ist dies jedoch nicht notwendig, da viele
Anwendungen lediglich an Daten einzelner Elemente interessiert sind.
DOM
DOM ist ein Akronym für Document Object Model. Dieses Document Object Model ist eine API,
das den Zugriff auf Struktur und Inhalt eines Dokumentes ermöglicht. DOM-basierte Parser
compilieren das vorgegebene XML-Dokument in eine Baumstruktur, welche dann mit StandardAlgorithmen traversiert werden kann:
XMLDokument
DOM
Compilierung in
eine Baumstruktur
Traversierung des
Strukturbaumes
durch die
Applikation
Abbildung III-9: Struktur, Darstellung und Inhalt mit der XML
Man kann also zwei prinzipielle Verarbeitungsschritte unterscheiden:
Schritt 1:
Dokumentanalyse, optionale
Gültigkeitsprüfung, Generierung
eines Parse-Baumes
Schritt 2:
Verarbeitung des Parse-Baumes
(Zugriff z.B. mit DOM-Interface)
Abbildung III-10: Ablauf der XML-Verarbeitung
Im ersten Schritt wird ein XML-Dokument analysiert. In diesem Schritt ist es möglich zu prüfen,
ob das XML-Dokument gültig ist, d.h. ob das Dokument zu seiner DTD konform ist. Wenn das
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 1. XML – eXtensible Markup Language
34
Dokument zumindest wohlgeformt (d.h. syntaktisch korrekt) ist, dann wird ein Parse-Baum
generiert, dessen Knoten den Tags des XML-Dokumentes entsprechen.
Anschließend werden im zweiten Schritt die so gewonnen Informationen extrahiert und
weiterverarbeitet (traversiert).
Die DOM Level 1-Spezifikation [W3C 98b] beschreibt also eine plattform- und
sprachenunabhängige Schnittstelle zum Zugriff auf XML-Dokumente. Der Hauptvorteil dieser
Spezifikation ist tatsächlich die weitgehende Unabhängigkeit von proprietären APIs und Standards.
Es ist so kein großes Problem, in einer Applikation den verwendeten XML-Parser auszutauschen,
wenn beide Parser DOM unterstützen.
Die Spezifikation gliedert sich in zwei Teile: "Core" und "HTML":
DOM Level 1
HTML
Core
Abbildung III-11: Die zwei Teile der DOM Level 1-Spezifikation
Der Core-Teil definiert eine minimale Funktionalität, um auf XML-Dokumente zugreifen zu
können. Mit dem HTML-Kapitel werden HTML-spezifische Erweiterungen beschrieben, die
zusätzlich zum Core implementiert werden müssen.
Die Spezifikation von DOM Level 2 beschreibt auf der Grundlage der Level 1-Spezifikation etliche
Erweiterungen. Zu diesen Erweiterungen gehören z.B. XML-Namensräume, Stylesheets und
Ereignisse. Die Spezifikation ist unter [W3C 99c] zu finden.
SAX
SAX (Simple API for XML) ist eine ereignisbasierte API zur Verarbeitung von XMLDokumenten, die von den Mitgliedern der XML-DEV-Mailingliste entwickelt wurde.
Hintergrund der Entwicklung dieser einfacheren API (im Vergleich zu DOM) ist, daß hier viel
weniger Resourcen verbraucht werden als bei der DOM-API. Es ist so möglich, XML-Dokumente
zu parsen, die erheblich größer sind als der verfügbare Arbeitsspeicher des Rechners.
In vielen Anwendungen – insbesondere in dieser Diplomarbeit – werden lediglich bestimmte
Elementnamen und die entsprechenden Informationen gesucht. Will man z.B. nur den Namen des
Autors eines Dokumentes ermitteln, kann man mit der SAX-API einfach nach dem entsprechenden
Tag suchen und muß nicht den gesamten Strukturbaum aufbauen. Ein Beispiel:
<?xml version="1.0">
<example>
<title> Testdocument </title>
<body> Hi, everybody ! </body>
</example>
Codebeispiel III-7: SAX-Beispieldokument
Mit der SAX-API könnte man folgende Ausgabe erzeugen:
start document
start element: example
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 1. XML – eXtensible Markup Language
35
start element: title
char: Testdocument
end element: title
start element: body
char: Hi, everybody !
end element: body
end element: example
end document
Codebeispiel III-8: Parsen mit SAX
Ein Beispiel für einen SAX-basierten Parser ist Microstar's AElfred [Microstar 99]. Auf dieser
Website ist auch die SAX-Spezifikation zu finden.
1.10
Weitere Einsatzmöglichkeiten von XML
Dynamisches Nachladen von Java-Klassen
Java bietet die Möglichkeit, Klassen zur Laufzeit dynamisch nachzuladen. Diese Fähigkeit läßt sich
vielfältig nutzen: man kann z.B. JDBC-Treiber oder JavaBeans dynamisch nachladen. In
Verbindung mit XML bietet das dynamische Nachladen von Klassen ungeahnte Möglichkeiten.
Eine Anwendung wäre beispielsweise eine benutzerdefinierte Oberfläche, die im XML-Format
abgespeichert und wieder nachgeladen werden kann. Die dafür zuständige DTD könnte etwa so
aussehen:
<?xml version="1.0"?>
<!DOCTYPE SWINGGUI [
<!ELEMENT SWINGGUI(JFRAME)+>
<!ELEMENT JFRAME ( JLABEL | JTEXTFIELD | JBUTTON | ... )*>
<!ATTLIST JFRAME
LAYOUT ( Border | Flow | Gridbag) "Gridbag"
TITLE CDATA "JFrame"
>
...
]>
Codebeispiel III-9: GUI-DTD für Swing
Ein auf Swing basierendes GUI besteht also aus mindestens einem Frame (JFrame, um genau zu
sein). Jedes Frame besteht wiederum aus beliebigen Kombinationen von Labeln, Textfeldern,
Buttons und weiteren Elementen (die ich hier nicht mehr aufgeführt habe). Man kann nun eine GUI
folgendermaßen in XML beschreiben:
<SWINGGUI>
<JFRAME TITLE="MyFrame">
<JBUTTON TITLE="Are you really sure"/>
...
</JFRAME>
</SWINGGUI>
Codebeispiel III-10: XML-Dokument zur GUI-DTD
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 1. XML – eXtensible Markup Language
36
Ein solches XML-Dokument wird also von einer Java-Applikation geparst und gegebenenfalls
validiert. Wird ein GUI-Element erkannt, kann der Tag-Name an eine Methode übergeben werden,
welche die benötigte Swing-Klasse nachlädt und die Parameter entsprechend übergibt:
myElement = (JButton)Class.forName(element.getTagName()).newInstance();
Codebeispiel III-11: Dynamisches Laden von Swing-Klassen
Bei entsprechendem Programmieraufwand ist es also möglich, ganze GUIs im XML-Format
abzuspeichern und wieder nachzuladen. Wünschenswert wäre natürlich die Integration in
Entwicklungsumgebungen wie JDeveloper. Aber auch bei der Entwicklung von Tools, die
vollständig vom Benutzer konfigurierbar sein sollen, ist XML als flexibles Beschreibungsformat
eine große Hilfe. Eine interessante Anwendung dieser Idee wird im folgenden Abschnitt näher
beschrieben.
Speichern und Laden von JavaBeans
In der Online-Zeitschrift JavaWorld [JavaWorld 99] wurde ein Verfahren beschrieben, mit dem
man JavaBeans zur Laufzeit mit allen relevanten Eigenschaften (Properties) im XML-Format
abspeichern und wieder nachladen kann (Serialisierung/Deserialisierung). Folgende Abbildung
(aus [Johnson 99]) illustriert das Prinzip dieses Verfahrens:
XMLBeanWriter
Running
JavaBean
<JavaBean CLASS=Arabica>
<Properties>
<Property NAME="Roast">Dark</Property>
...
<JavaBean CLASS=Arabica>
<Properties>
<Property NAME="Roast">Dark</Property>
...
XMLBeanWriter
Running
JavaBean
Abbildung III-12: Speichern und Laden von JavaBeans
Der genaue Mechanismus (mit komplettem Sourcecode) wird in [Johnson 99] näher erklärt.
XML und UML
Es gibt Bestrebungen, die Unified Modeling Language (UML) als XML-DTD zu definieren und
damit ein Austauschformat für UML-Modelle festzulegen. Die Vorteile eines StandardAustauschformates für UML liegen auf der Hand:
•
Unabhängigkeit vom verwendeten Case-Tool
•
Bequemer Informationsaustausch zwischen Entwicklern
Der zweite Punkt ist besonders interessant für LeserInnen von OO-Mailinglisten. Hier wird
regelmäßig versucht, mit ASCII-Text UML-Klassendiagramme zu "zeichnen", die sehr schlecht
lesbar sind. Problematisch bei einem XML-Dokument zur Beschreibung von UML-Modellen ist
natürlich die Formalisierung des Sachverhaltes – hier ist eine gute Tool-Unterstützung nötig.
Es gibt im wesentlichen zwei verschiedene DTDs zur Beschreibung von UML: das UML Exchange
Format (UXF), welches von der Keio University in Japan entwickelt wird [UXF 99] und das XMI
(XML Metadata Interchange), welches von der OMG mit der Unterstützung verschiedener
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 1. XML – eXtensible Markup Language
37
Softwarefirmen (Oracle, IBM, Rational, ...) entwickelt wird [XMI 99]. Im folgenden ein Ausschnitt
aus der (sehr umfangreichen) XMI-DTD, der Grundlage für die Beschreibung eines Use-Cases ist:
<!ENTITY % extensionPoint 'extensionPoint' >
<!ELEMENT extensionPoint (#PCDATA) >
<!ENTITY % UseCaseProperties '%ClassifierProperties;, %extensionPoint;' >
<!ENTITY % UseCaseAssociations '%ClassifierAssociations;' >

<!ENTITY % UseCaseCompositions '%ClassifierCompositions;,
ViewElement*' >
<!ELEMENT UseCase (%remoteContent; |
(%UseCaseProperties;,
%UseCaseAssociations;,
%UseCaseCompositions;)) >
<!ATTLIST UseCase
%XMI.ElementAttributes;
>
Codebeispiel III-12: Ausschnitt aus der XMI-DTD
Die XMI-DTD ist sehr komplex und umfangreich, während die UXF-DTD mit gerade mal einer
Seite auskommt. Hier ein Ausschnitt aus der UXF-DTD:
<!ELEMENT Class
(TaggedValue?, (Attr
|Operation
|Generalization
|Association
|Dependency
|Note)* )>
<!ATTLIST Class
NAME
CDATA
ABSTRACT (true|false)
VISIBILITY (public|private)
ACTIVE
(true|false)
#REQUIRED
"false"
#REQUIRED
#IMPLIED>
Codebeispiel III-13: Ausschnitt aus der UXF-DTD
Damit können einfache UML-Modelle beschrieben werden:
<Class NAME
= "Triangle"
VISIBILITY = "public">
<Generalization FROM = "Polygon"/>
</Class>
Codebeispiel III-14: Anwendung der UXF-DTD
Dieses XML-Dokument ist leicht zu lesen: Der Klassenname Triangle ist eine Erweiterung der
Polygon-Klasse mit einer public-Sichtbarkeit.
Prinzipiell ist XMI das bessere Format für den Austausch komplexer Meta-Informationen (XMI
basiert auf dem UML-Metamodell), während UXF für den einfachen Austausch von Diagrammen
besser geeignet ist (UXF basiert auf den UML-Diagrammen und nicht auf dem UML-Metamodell).
Anzumerken ist jedoch, daß es eher unwahrscheinlich ist, daß UXF sich durchsetzen wird, da XMI
von der OMG spezifiziert wird und führende Hersteller von Case-Tools (Rational) XMI
unterstützen.
Für nähere Informationen sind die Papers, Dokumentationen und Spezifikationen auf den Websites
[UXF 99] und [XMI 99] zu empfehlen.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 2. Komponententechnologien
38
2 Komponententechnologien
A component is a pre-written piece of software that exposes a set of functionality through a
standard interface.
aus Sun's JavaBeans Spezifikation
2.1 Einleitung
Seit den Anfängen der Softwareentwicklung gab es immer wieder neue Entwicklungen und
Paradigmenwechsel. Der Übergang von reinen Assemblersprachen zu Hochsprachen wie
ALGOL68 bis hin zu den ersten objektorientierten Sprachen (Simula67, Smalltalk76) brachte
Verbesserungen in der Lesbarkeit und Wartbarkeit von Software [Gmeiner 99]. Konzepte wie
strukturierte und später objektorientierte Programmierung führten zum Software-Engineering als
eigenständiger Disziplin innerhalb der Informatik.
Man spricht davon, daß die Wartung von Software etwa 70 % der Entwicklungskosten verschlingt
[Brügge 98]. Folgende Grafik (ebenfalls aus [Brügge 98]) offenbart interessante Hintergründe:
Wartung:
35..40%
Entwicklung
Wartung:
40..60%
Wartung:
70..80%
Entwicklung
1970
1980
1990
Abbildung III-13: Softwarewartung
Vor dem Hintergrund immer besserer und schnellerer Hardware, ständig verbesserten
Entwicklungsumgebungen (IDEs), eleganteren Programmiersprachen und besser durchdachten
Programmierkonzepten ist diese Tendenz erschreckend – aber verständlich. Von heutiger Software
wird viel erwartet:
•
einfache Bedienbarkeit
•
ansprechendes User-Interface (z.B. Grafik)
•
hohe Funktionalität
•
Konfigurierbarkeit durch den Benutzer
•
...
Diese Punkte führen zu einer höheren Komplexität von Software, obwohl viele grundlegende
Algorithmen seit den Zeiten der ersten Implementierungen von Algorithmen unverändert geblieben
sind. Die folgenden Unterkapitel sollen nun ein neues Paradigma näher erläutern, das mittlerweile
als "Buzzword" jede neue Software ziert: die komponentenorientierte Softwareentwicklung.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 2. Komponententechnologien
39
2.2 Komponentenorientierte Softwareentwicklung
Heutige Software wird zunehmend komplexer. Ein Grund dafür ist die zunehmende Integration von
Anwendungen in Netzwerkstrukturen wie dem Internet. Ein anderer Grund ist der steigende Bedarf
an benutzerfreundlichen Anwendungen, welche mit Wizards und Agenten versuchen, die
Benutzung einfacher zu machen. Durch das Internet ist auch die Integration von Techniken zur
Internationalisierung von Software wichtig geworden. So können auch kleine Tools schnell zu
großen, monolithischen Anwendungen werden, die als Ganzes kaum noch überschaubar sind.
Natürlich werden Anwendungen objektorientiert entwickelt, was sicherlich zu einer
Produktivitätssteigerung und zu besserem, verständlicherem Programmcode führt. Die
objektorientierte Softwareentwicklung ist dennoch an ihre Grenzen gestoßen. Die
Wiederverwendung von Klassen hat sich zu einem großen Teil als Illusion herausgestellt.
Heutzutage gibt es kaum Programme, die auch nur annähernd fehlerfrei sind. Auffällig ist, daß
gerade große, komplexe Softwarepakete enorme Probleme verursachen. Es existieren in diesen
Softwarepaketen Fehler, welche schon etliche Jahre bekannt sind und mit deren Behebung die
EntwicklerInnen sich offenbar recht schwer tun. Dafür könnte es folgende Gründe geben:
•
der Fehler hängt von vielen einzelnen Punkten ab, die für sich unproblematisch sind, als
Ganzes jedoch zu einem solchen Bug führen
•
die Behebung des Fehlers ist nur möglich, wenn dabei andere – weitgehend fehlerfreie –
Programmteile geändert und evt. dadurch instabil werden.
Derartige Probleme treten typischerweise bei komplexen Softwaresystemen auf, die im Laufe der
Jahre gewachsen sind und deren "Komponenten" so sehr ineinander verzahnt sind, daß auch
kleinste Änderungen Auswirkungen auf die Stabilität des Gesamtsystems haben (können).
Aus diesen Gründen wird in letzter Zeit die komponentenorientierte Softwareentwicklung als neues
Paradigma diskutiert. Komponententechnologien wie JavaBeans oder ActiveX sind dabei nur ein
Hilfsmittel, um das eigentliche Ziel zu erreichen: Entwicklung von großen, komplexen Systemen
aus einfachen, wiederverwendbaren Bausteinen. Eine Komponente im objektorientierten Sinne
kann aus einer einzelnen Klasse oder einem umfangreichen Klassenpaket mit vielleicht mehreren
hundert Klassen bestehen. Eines haben derartige Komponenten jedoch stets gemeinsam: Sie
fungieren als black-box mit einer wohldefinierten Benutzerschnittstelle.
Das Paradigma der komponentenorientierten Entwicklung von Software löst wohlgemerkt
keineswegs die Objektorientierung ab. Komponententechnologien sind vielmehr ein höheres
Konzept, das auf objektorientierten Methoden aufbaut (oder aufbauen sollte). Also kein
Paradigmenwechsel, sondern lediglich eine Weiterentwicklung bestehender Konzepte.
2.3 Komponenten, Frameworks, Bibliotheken – Eine
Einordnung
Diskussion des Komponentenbegriffs
In vielen Artikeln und Büchern wird versucht, Komponententechnologien genau zu definieren und
einzuordnen. Offensichtlich besteht hier noch erheblicher Erklärungsbedarf, zumal sich hier die
Experten oftmals gegenseitig widersprechen.
Komponenten müssen weder objektorientiert noch strukturiert entwickelt worden sein, sie müssen
auch nicht in binärer Form vorliegen. Sie müssen lediglich gut durchdachte, Bug-freie (darüber läßt
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 2. Komponententechnologien
40
sich streiten, aber ich bin der Ansicht, daß auf Komponenten, die nicht im Quellcode vorliegen,
hundertprozentiger Verlaß sein muß) und über wohldefinierte Schnittstellen ansprechbare "Black
Boxes" sein.
Was heißt nun "Black Box"? Es heißt nicht "in binärer Form vorliegend" oder "nie mehr
veränderbar", sondern vor allem verläßlich in dem Sinne, daß man auf die Funktionalität vertrauen
kann und die interne Funktionsweise einer Komponente nicht verstehen muß, um sinnvoll damit
arbeiten zu können.
Ein wichtiger Punkt ist das Konzept der Kapselung. Kapselung von Komponenten ist wichtig, um
die Unabhängigkeit einer Komponente vom Kontext zu unterstreichen. Der Zugriff auf
Komponenten sollte stets über die (gut dokumentierten) Schnittstellen stattfinden und
kontextunabhänig sein.
Komponenten können durchaus im Sourcecode vorliegen. In diesem Fall lassen sie sich
individuellen Erfordernissen anpassen. Es gibt jedoch zahlreiche Autoren, welche die binäre
Ausführbarkeit als wichtigsten Punkt der Komponentendefinition ansehen. Argumentiert wird
zumeist, daß bei eventuellen Sourcecodemodifikationen der vielleicht wichtigste Punkt der
Kompoentenorientierung – der Black-Box-Gedanke – in Frage gestellt wird.
Einordnung von Komponenten, Bibliotheken und Frameworks
An dieser Stelle soll der Versuch einer Einordnung gemacht werden: Der Unterschied zwischen
Komponenten, Klassenbibliotheken und Frameworks ist oftmals schwer durchschaubar. Aus [GoF
96] stammt folgende Definition:
Eine Klassenbibliothek besteht aus einer Menge von verwandten und wiederverwendbaren
Klassen, die entworfen wurden, um nützliche und allgemeine Funktionaliät zur Verfügung zu
stellen.
Stichwort hierbei ist die Wiederverwendung von Programmcode. Man denkt dabei nicht an ein
Plug & Play von Klassen, sondern lediglich an eine Nutzung von bereits entwickelten Klassen.
Bibliotheken sind also einfach Sammlungen von nützlichen Klassen, welche die Programmierung
einfacher machen, da man nicht jedesmal das Rad neu erfinden muß.
Frameworks dagegen implizieren eine bestimmte Struktur (bzw. Architektur) der Anwendung, die
auf dem entsprechenden Framework aufbaut. Ein Framework ist also eine Art Grundgerüst für eine
Anwendung.
Die Gang of Four [GoF 96] meint hierzu:
Ein Framework besteht aus einer Menge von zusammenarbeitenden Klassen, die einen
wiederverwendbaren Entwurf für eine bestimmte Klasse von Software darstellen".
Bei Frameworks geht es also nicht primär um die Wiederverwendung von Programmcode, sondern
um die Wiederverwendung von Entwürfen und Architekturen.
An dieser Stelle soll einmal der Versuch der Definition einer Komponente gemacht werden:
Eine Komponente ist Software, die eine in sich geschlossene Funktionalität bietet und diese
Funktionalität über wohldefinierte Schnittstellen nach außen hin anbietet. Dabei ist die eigentliche
Funktionsweise der Komponente idealerweise irrelevant, in jedem Falle aber für den Entwickler
vollkommen transparent. Eine Komponente sollte jedoch in einem gewissen Rahmen
benutzerspezifisch konfigurierbar sein.
Inwiefern aktuelle Komponententechnologien derartige akademische Definitionen implementieren
sei einmal dahingestellt, aber zum Abschluß möchte ich noch einen Punkt erwähnen, der mir sehr
wichtig erscheint:
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 2. Komponententechnologien
41
Komponenten sollten unabhängig von der verwendeten Programmiersprache und
Entwicklungsplattform sein. Bei Microsoft's Komponententechnologien (z.B. ActiveX) war dies
wohl nicht der grundlegende Ansatz, aber bei Sun's (Enterprise) JavaBeans kann man durchaus von
einer Unabhängigkeit von Programmiersprache und Entwicklungsplattform sprechen.
Programmiersprachenunabhängigkeit wegen der Möglichkeit der CORBA-Einbindung bei
Enterprise JavaBeans und wegen der Möglichkeit der Verwendung von JavaBeans in ActiveXUmgebungen. Plattformunabhängigkeit wegen der Verwendung von plattformunabhängigem
Bytecode.
Utopie ist zur Zeit leider noch die absolute Transparenz nicht nur von Funktionsweise, sondern
auch von Programmiersprache und Implementierungsplattform. Fraglich ist dabei auch, ob die
Softwarefirmen ein solches Modell überhaupt anstreben, da die Bindung der Kunden an eine
bestimmte Komponententechnologie sicherliche eine erfolgversprechende Strategie darstellt.
2.4 Komponenten-Frameworks und KomponentenBibliotheken
Schon jetzt existieren umfangreiche Komponentenbibliotheken und -frameworks. Einige dieser
Bibliotheken sind in kommerzielle Entwicklungsumgebungen integriert (JBuilder, VisualCafe);
viele Bibliotheken können aber auch gekauft und aus dem Internet heruntergeladen werden. Es ist
abzusehen, daß in Zukunft ein Komponentenmarkt entstehen wird, der den Entwicklungsaufwand
stark reduzieren wird.
Generische
Komponentenbibliothek
Anwendung A
Anwendung B
Abbildung III-14: Generische Komponentenbibliotheken
Es ist bei der Verwendung derartiger Bibliotheken wichtig, die entsprechenden Komponenten nach
Aktualisierungen, Performanceverbesserungen, etc. auch in der Bibliothek selbst zu aktualisieren.
Im Laufe der Zeit ist es so möglich, firmenspezifische Bibliotheken zu generieren, die es
ermöglichen, schneller und effizienter Software zu entwickeln.
Klassen-Frameworks vs. Komponenten-Frameworks
Der Hauptunterschied zwischen Komponenten-Frameworks und Klassen-Frameworks ist die
stärkere Beschränkung der Freiheit des Softwareentwicklers bei Verwendung von KomponentenFrameworks. Bei derartigen Frameworks müßte genauer spezifiziert werden, welche Komponenten
sinnvoll in Verbindung mit anderen Komponenten eingesetzt werden können.
Klassen-Bibliotheken vs. Komponenten-Bibliotheken
Bei Komponenten-Bibliotheken sieht es ähnlich wie bei Komponenten-Frameworks aus:
Komponenten schränken die Freiheit des Entwicklers stärker ein als bei der reinen
objektorientierten Entwicklung mit Klassenbibliotheken. Probleme können bei der Integration von
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 2. Komponententechnologien
42
Komponenten verschiedener Hersteller auftreten. Insbesondere kann es passieren, daß eine
bestimmte Grundfunktionalität gleich von mehreren Komponenten implementiert wird, was zu
einem größeren Codeumfang führt (vgl. den folgenden Abschnitt).
Granularität von Komponenten
Bei der Entwicklung von Komponenten stellt sich die Frage nach deren Granularität. Ist es z.B.
sinnvoll, Komponenten einzusetzen, welche aus mehr als 50 Klassen bestehen und evt. sogar aus
verschiedenen Sub-Komponenten zusammengesetzt wurden? Problematisch bei der Integration von
mehreren Mammut-Komponenten ist, daß oftmals gewisse Basisfunktionalitäten in mehreren
Komponenten vorhanden sind, d.h. daß der Codeumfang einer komponentenbasierten Anwendung
in vielen Fällen größer ist als bei der Verwendung gewöhnlicher objektorientierter
Klassenbibliotheken:
Codeumfang
Makro-Komponenten
Komponenten
Klassen
Abbildung III-15: Vergleich des Codumfanges
Es ist anzunehmen, daß sich firmenspezifisch gewisse Standards zur Komponentengranularität
entwickeln werden. Sinnvoll ist natürlich auch eine genaue Prüfung der Komponentenfunktionalität
bei "fremden" Komponenten, um etwaige Funktionsüberschneidungen zu ermitteln und
gegebenfalls andere Komponenten einzukaufen (oder selbst zu entwickeln).
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 3. JavaBeans
43
3 JavaBeans
JavaBeans sind wohldefinierte Komponenten, die aus Java-Klassen bestehen, beliebig
wiederverwendet und in neue Anwendungen integriert werden können. Mit der JavaBeansSpezifikation [Sun 99a] in die Programmiersprache, hat Sun Microsystems eine wichtige Lücke in
der Java-Programmiersprache geschlossen.
3.1 Einführung in JavaBeans
Wie funktioniert's?
JavaBeans sind eine oder mehrere Java-Klassen, die als eine Einheit – als Komponente – zu sehen
sind. Was unterscheidet nun JavaBeans von einem gewöhnlichen Klassenpaket? Wird ein
gewöhnliches Java-Programm geschrieben, ist die Wieder- bzw. Weiterverwendung problematisch.
Es ist meist unklar, wie die Applikation angesprochen werden kann, wie die Schnittstellen definiert
sind und ganz allgemein, ob die Applikation überhaupt weiterverwendet werden kann. JavaBeans
wurden entwickelt, um genau diese Fragen beantworten zu können, ohne den Quellcode der
Anwendung (direkt) analysieren zu müssen.
Die Spezifikation von JavaBeans definiert genau, wie sich eine Bean verhalten soll. Es gibt also
eine Anzahl Regeln und Richtlinien, die von einer JavaBean befolgt werden müssen. Das heißt
also, daß eine JavaBean-Komponente bestimmte Methoden zur Verfügung stellen muß, die der
Kommunikation innerhalb des Komponenten-Frameworks dienen und die es möglich machen, an
der Komponentenstruktur zu partizipieren.
An dieser Stelle soll allerdings ausdrücklich erwähnt werden, daß die Unterschiede zwischen einer
JavaBeans-Komponente und einer gut durchdachten, sauber programmierten Java-Klasse nicht
besonders groß sind. So ist es prinzipiell einfach, Klassen oder Klassenpakete in JavaBeans
umzuwandeln, falls dies sinnvoll ist.
Elemente des JavaBeans Komponentenmodells
Das JavaBeans-Komponentenmodell besteht aus zwei Elementen:
•
den Komponenten selbst und
•
den Behältern
Die JavaBeans-Komponenten sind Java-Klassen, die bestimmten Konventionen genügen müssen,
um von einem Behälter als Bean erkannt zu werden. Behälter sind – zum Teil sehr komplexe –
Tools, die es ermöglichen, verschiedene Beans zu einer einzigen Anwendung (bzw. Komponente)
zu verknüpfen. Beispiel hierfür ist die Entwicklung eines graphischen User-Interfaces (GUIs) aus
bestimmten Komponenten wie Frames oder Buttons.
Visuelle Präsentation
Die visuelle Präsentation von Komponenten ist eine der wichtigsten Funktionen einer
Komponenteninfrastruktur. Es muß möglich sein, Komponenten in einem Container visuell zu
modellieren (natürlich gibt es auch Komponenten ohne grafische Repräsentation, z.B.
Netzwerkkomponenten). Java bietet die Möglichkeit der visuellen Modellierung über die Java
Foundation Classes (JFC) und die darin enthaltenen Pakete AWT oder Swing. So kann man
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 3. JavaBeans
44
beispielsweise Component (oder JComponent bei Swing) als Grundlage für eigene grafische
JavaBeans verwenden.
Unterstützung visueller Programmierung
Visuelle Programmierung bedeutet, daß sich Anwendungen (Komponenten) rein visuell mittels
Drag & Drop zusammenbasteln lassen. Ein Beispiel hierfür ist das Entwicklungstool JBuilder, mit
dem sich komplexe (grafische) Anwendungen erstellen lassen. Der Entwickler wählt einfach
Komponenten aus einer Toolbox aus und plaziert sie in einen Container. Eventuell werden dann
noch die Komponenten an eigene Anforderungen angepaßt (z.B. Ändern der Größe oder der
Schriftart). Die notwendigen Sourcecodeänderungen werden vom Entwicklungstool automatisch
vorgenommen.
3.2 Das JavaBeans Komponentenmodell
Das JavaBeans Komponentenmodell besteht nicht nur aus Spezifikationen, nach denen die
Elemente (Komponenten und Behälter) entwickelt werden müssen, sondern auch aus Diensten, die
zur Verfügung gestellt werden. Die Bestandteile des Komponentenmodells werden im folgenden
beschrieben.
Eigenschaften
Eigenschaften (Properties) kann man als Untermenge des Zustands einer Komponente verstehen.
Über Eigenschaftsänderungen läßt sich somit das Verhalten einer Bean ändern. Eigenschaften
können bei einer Bean für den Datenbankzugriff etwa username und password sein. Bei
graphischen Beans (z.B. Buttons) sind die Eigenschaft font oder lookAndFeel (Windows, Motif,
...) denkbar.
Reflexion und Introspektion
Introspektion (Introspection) ist ein Begriff aus dem Lateinischen und bedeutet soviel wie
Selbstbeobachtung. Selbstbeobachtung – dieser Begriff impliziert eine vorhandene Infrastruktur,
d.h. die Komponente muß bestimmte Methoden bieten, um interessierten Anwendungen die
Erkennung ihrer Funktionalität zu erleichtern. Die Spezifikation eines Komponentenmodells muß
die Zugriffsmechanismen, über die auf eine Komponente zugegriffen werden kann, definieren.
Diese Zugriffsmechanismen sind normalerweise öffentliche Methoden, die bestimmten
Namenskonventionen (getXXX, setXXX) genügen. Es ist aber auch möglich, die
Komponentenschnittellen explizit in einer speziellen BeanInfo-Klasse anzugeben. Die
Spezifikation legt also die Schnittstellen einer Komponente nach außen fest, um es einem
(visuellen) Tool einfach zu machen, mittels Introspektion die innere Struktur einer Komponente zu
analysieren. Damit ein Stück Software als JavaBeans-Komponente bezeichnet werden kann, muß
sie also Introspektion unterstützen. Der Introspektionsmechanismus baut auf der Reflexion auf:
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 3. JavaBeans
45
Introspektion
Mechanismus zur
Ermittlung von
Eigenschaften,
Ereignissen und
Zugriffsmethoden
Reflexion
Mechanismus zur
Ermittlung Klassen,
Konstruktoren und
Datenfeldern
Abbildung III-16: Reflexion und Introspektion
Mit Reflexion (Reflection) bezeichnet man die Möglichkeit, eine Klasse zur Laufzeit zu
untersuchen und Informationen über die Daten, den Konstruktor und andere Methoden zu erhalten.
Die Reflexion wird von der Introspektion benutzt, um Informationen über die speziellen
Eigenschaften und deren Zugriffsmethoden zu bekommen. Die Klasse Class aus dem java.lang.*Paket bietet aus diesem Grund etliche Methoden, um die Reflexion zu unterstützen. Mit
forName(String className) – einer vielverwendeten Methode – kann man ein Class-Objekt der
in className spezifizierten Klasse erhalten. Ähnliche Methoden gibt es, um Constructor- oder
Field-Objekte zu einer bestimmten Klasse zu ermitteln.
Ereignisse
Wenn sich der Ist-Zustand einer Komponente ändert, wird von der Komponente eine
Ereignismeldung generiert. Andere Komponenten, die sich für ein solches Ereignis interessieren,
können sich bei der Komponente registrieren und werden dann benachrichtigt. Genauso wird beim
AWT-Ereignismodell von Java 1.1 und höher vorgegangen: die jeweiligen Komponenten (hier:
Buttons und sonstige grafische Komponenten) registrieren sich bei einem Listener, um über
bestimmte Ereignisse (Mausklicks, etc) benachrichtigt zu werden.
Persistenz
Jede Instanz einer JavaBean-Komponente ist zustandsbehaftet. Das heißt, sie befindet sich zu
jedem beliebigen Zeitpunkt in einem definierten Zustand. Es ist nun gelegentlich wünschenswert,
diesen aktuellen Zustand abzuspeichern und wiederherstellen zu können. Java bietet zum Glück
einen Mechanismus, der das bequeme Abspeichern (Serialisieren) und Wiederherstellen
(Deserialisieren) eines Bean-Zustandes erlaubt.
Damit der Zustand eines Objektes abgespeichert werden kann, muß die entsprechende Java-Klasse
die Schnittstelle Serializable implementieren. Diese Schnittstelle deklariert zwei Methoden:
readObject und writeObject. Mit writeObject ist die Serialisierung des Objekts möglich; mit
readObjekt kann man ein Objekt wieder herstellen (Deserialisierung).
Bei der Serialisierung wird der Objektzustand in einen Stream geschrieben (der üblicherweise mit
einem File assoziiert ist) und vice versa. Die (De-)Serialisierung ist ein wichtiger und integraler
Bestandteil der Java-Programmiersprache, ohne den beispielsweise keine Objekte mittels RMI über
ein Netzwerk übertragen werden könnten.
3.3 Eigenschaften
Durch Eigenschaften (Properties) wird der innere Zustand einer Bean beschrieben. Eigenschaften
sind Attribute einer Bean, die Auswirkungen auf das Erscheinungsbild und das Verhalten haben.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 3. JavaBeans
46
Diese Attribute können Standardtypen wie int oder boolean sein, können aber auch Klassen- und
Schnittstellen-Typen haben.
Eigenschaften visueller Beans (Buttons oder Anzeigebeans) bestehen oft zu einem großen Teil aus
diskreten Attributen, die das äußere Erscheinungsbild festlegen. So kann eine grafische
Komponente z.B. ein (boolesches) Attribut Orientierung haben, das festlegt, ob die Bean horizontal
oder vertikal am Bildschirm dargestellt wird. Die Zugriffsmethoden dienen also zwei Zwecken:
•
Introspektion zur Designzeit
•
Eigenschaftsänderungen zur Laufzeit
Es müssen nun bestimmte Schnittstellen existieren, die den Zugriff auf diese Attribute erlauben.
Diese Schnittstellen sind öffentliche Zugriffsmethoden, die das Lesen oder Schreiben eines
Attributwertes ermöglichen. Es gibt bestimmte Namenskonventionen für Zugriffsmethoden. So
müssen Schreibmethoden mit set und Lesemethoden mit get beginnen. Methoden zur
Manipulation des Attributs der Eigenschaft Orientierung würden somit getOrientation und
setOrientation heißen.
Man unterscheidet folgende Arten von Eigenschaften:
•
einwertige Eigenschaften
•
indizierte Eigenschaften
•
gebunde Eigenschaften
•
Eigenschaften mit Constraints
Indizierte Eigenschaften enthalten mehrere Attribute gleichen Typs, die über einen ganzzahligen
Index ausgewählt werden können. Ein Beispiel hierfür wären Koordinatenangaben bei einer Bean
zur Darstellung dreidimensionaler Grafiken. Die Zugriffsmethoden sind dann
public float getCoordinate(int index, float position)
public float[] getCoordinate()
public void setCoordinate(int index, float value)
public void setCoordinate(float[] values).
Codebeispiel III-15: JavaBean-Zugriffsmethoden
Gebunde Eigenschaften sind Eigenschaften, die registrierte Beobachter (Listener) bei einer
Änderung ihrer Attributwerte benachrichtigen. Diese Eigenschaften sind hilfreich, wenn etwa
mehrere Beans in ein gemeinsames Frame integriert werden und bestimmte Bean-Eigenschaften
(z.B. die Größe oder das Layout der Darstellung) auch die Umgebung und damit andere Beans
beeinflussen. So können z.B. bei einer Größenänderung einer Bean auch die Größe des
Containerfensters und die Position der anderen Beans angepaßt werden.
Eigenschaften mit Constraints kann man als Erweiterung der gebundenen Eigenschaften verstehen.
Wird versucht, eine solche Eigenschaft zu ändern, wird der entsprechende Listener benachrichtigt.
Im Unterschied zu gebundenen Eigenschaften kann der Beobachter ein Veto einlegen, wenn die
Eigenschaftsänderung nicht erwünscht ist. Nützlich ist diese Funktionalität bei der Einbindung
externer Beans, die möglicherweise Eigenschaften besitzen, die unverändert bleiben sollen (z.B. ist
bei internationalisierten Beans eine Umschaltung der Sprache sinnlos, wenn die Umgebung aus
Beans besteht, die keine solche Funktionalität zur Verfügung stellen).
Es ist nicht immer möglich, auf nicht-triviale Eigenschaften mit einem Bean-Tool zuzugreifen. Die
BeanBox von Sun beispielsweise erlaubt keinen Zugriff auf indizierte Eigenschaften. In einem
solchen Fall ist es möglich, spezielle Klassen zur Eigenschaftsänderung (Customizer) zu schreiben.
Nähere Informationen zu Customizer-Klassen sind im Unterkapitel "Entwicklung von JavaBeans"
(übernächstes Kapitel) zu finden.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 3. JavaBeans
47
3.4 Entwicklung von JavaBeans
Die Entwicklung von Beans unterscheidet sich nicht wesentlich von der Entwicklung von anderer
objektorientierter Software. Es ist z.B. auch problemlos möglich, eine Klassenstruktur mit einer
bestimmten Funktionaliät zu einer JavaBeans-Komponente zu machen. Was zunächst erstaunt ist,
daß eine JavaBeans-Komponente keine bestimmte Klasse erweitert und auch keine spezielle BeanSchnittstelle implementiert. Tatsächlich ist es gerade deswegen so einfach, JavaBeans – auch aus
bereits bestehenden Klassen – zu entwickeln. Die Unterschiede von Beans zu Klassenpaketen sind
eher gering:
•
Die Klassen einer JavaBean sind in einem JAR-Archiv zusammengefaßt.
•
Dieses JAR-Archiv enthält ein Manifest-File, in der das Bean beschrieben wird.
•
Eine Bean muß Introspektion unterstützen. Das geschieht am einfachsten über die
Verwendung der Namenskonventionenen.
•
Eine Bean-Klasse muß einen parameterlosen Konstruktor enthalten.
•
Eine Bean-Klasse hat keine öffentlichen Variablen (auf Variablen, die als BeanEigenschaften gelten, wird mit öffentlichen Methoden zugegriffen)
Das war's auch schon. Zu den einzelnen Punkten:
JAR-Archiv
JAR ist sowohl ein Akronym für Java Archive als auch ein Wortspiel (Jar = Krug oder Topf). Ein
solches Archiv kann mehrere Dateien enthalten und kann (muß aber nicht) komprimiert sein. Für
die Komprimierung werden die Standard-Algorithmen für ZIP-Dateien verwendet. Die meisten
Entwicklungstools (so auch JDeveloper) bieten die Möglichkeit, über einen Deployment-Wizard
mehrere Klassen in einem solchen Archiv zusammenzufassen.
Üblicherweise sind in einem solchen Archiv nicht nur die CLASS-Dateien und das Manifest-File
sondern auch noch die JAVA-Dateien (also der Sourcecode) und verschiedene .html-Dateien zur
Dokumentation der Bean. Bei bestimmten Multimedia-Anwendungen enthält das JAR-Archiv auch
noch Grafiken, Sound- und Video-Dateien.
Manifest-File
Dieses File wird zumeist automatisch vom Entwicklungstool generiert. Falls nicht, kann man es
leicht selbst schreiben. Bei einer Bean, die aus der Klasse TestBean besteht und im Verzeichnis test
liegt, sieht das Manifest-File so aus:
Name: test/TestBean.class
JavaBean: True
Name: test/TestBeanInfo.class
Codebeispiel III-16: Manifest-File
Das Manifest-File dient eigentlich nur dazu, Tools einen kurzen Überblick über die Dateien – oder
vielmehr über die Beans - des Archivs zu geben. In obigem Beispiel ist die Klasse TestBeanInfo
also keine JavaBean (aber wohl ein integraler Bestandteil der Bean).
Interessant ist noch, daß die Dateien in einem JAR-Archiv auch eine digitale Signatur haben
können. Damit kann verifiziert werden, daß die Dateien von einer bestimmten Firma oder
Organisation stammen und vor allem, daß sie nicht geändert wurden. Die Einträge im Manifest-File
enthalten dann unter anderem noch Informationen über den benutzten Algorithmus.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 3. JavaBeans
48
Unterstützung von Introspektion
Es gibt mehrere Methoden, die Introspektion zu unterstützen. Am sinnvollsten und am einfachsten
ist es, sich einfach an die Namenskonventionen zu halten. Oftmals wird auch eine BeanInfoKlasse geschrieben, welche Auskunft über die entsprechende JavaBean gibt. Vorteil ist hier, daß
man sich bei der Bean-Entwicklung nicht an die Namenskonventionen halten muß.
Parameterloser Konstruktor
Beans müssen einen parameterlosen Konstruktor haben. Der Grund dafür ist offensichtlich: bei
graphischen Beans klickt man sich seine Komponenten mittels Drag & Drop zusammen. Plaziert
man nun eine neue Bean auf der graphischen Oberfläche, um die Bean zu instanziieren, dann sind
die entsprechenden Eigenschaften der Bean noch nicht bekannt. Das Tool zur Bean-Entwicklung
muß die Bean also parameterlos instanziieren und später die Möglichkeit bieten, die Eigenschaften
der Bean zu ändern.
Keine öffentlichen Variablen
In einer JavaBean-Komponente ändert man die Eigenschaften über die öffentlichen
Zugriffsmethoden, die bestimmten Namenskonventionen genügen müssen. Im übrigen ist es auch
sonst (d.h. wenn keine Komponenten programmiert werden) sinnvoll, auf öffentliche Variablen zu
verzichten und stattdessen Methoden zur Manipulation anzubieten.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 4. RMI – Remote Method Invocation
4 RMI
49
– Remote Method Invocation
Remote Method Invocation provides a way to build wormholes to join the object galaxies
contained in different Virtual Machines.
Gerald A. de Jong, JavaWorld Magazine
In der heutigen Welt objektorientierter Systeme werden Modelle benötigt, die eine verteilte ObjektObjekt-Kommunikation erlauben. Bei der Verwendung von Low-Level-Konzepten wie der SocketProgrammierung
wird
das
objektorientierte
Paradigma
einer
objektorientierten
Programmiersprache wie Java durchbrochen. Wenn bei der Softwareentwicklung auf derartige
Konzepte zurückgegriffen wird, dann kann eine einfache Anwendung schnell zu kompliziertem
und schwer lesbaren Code führen, der der Anwendung nicht angemessen ist. Aus diesem Grund
exisitieren Modelle wie RMI oder CORBA, welche eine transparente Objekt-ObjektKommunikation ermöglichen – im Falle von CORBA sogar über Programmiersprachengrenzen
hinweg.
4.1 Verteilte Objekte
If the meaning of the destination is isomorphic with the meaning of the source which
originated the act, then communication can be said to have taken place.
Melvin L. De Fleur, Sandra Ball-Rokeac (Theories of Mass Communication)
RMI ist ein Akronym für Remote Method Invocation, also für einen entfernten Methodenaufruf.
Mit RMI ist es möglich, mit einem Objekt, das in einer Virtuellen Maschine (VM) läuft, Methoden
eines Objekts einer anderen VM aufzurufen. Im Gegensatz zu CORBA müssen bei RMI sowohl
Client als auch Server in Java implementiert werden.
Für die Entwicklung von reinen Java-Anwendungen ist RMI besser geeignet als CORBA, da zum
einen keine Schnittstellendefinitionen in einer anderen Programmiersprache (IDL) geschrieben
werden müssen und zum anderen ist RMI bei vergleichbarem Funktionsumfang leichter zu
handhaben.
Wichtigstes Designziel bei RMI war, den Verteilungsaspekt möglichst transparent zu halten, also
dafür zu sorgen, daß sich ein entferntes Objekt genauso verhält wie ein lokales Objekt und ebenso
angesprochen werden kann.
Für den Entwickler ist der Hauptunterschied zwischen lokalen und entfernten Methodenaufrufen
die Geschwindigkeit. Entfernte Aufrufe können – je nach Netzbelastung – sehr viel länger dauern
als lokale Aufrufe. Verteilte Anwendungen müssen auch sehr sorgfältig geplant werden, da schnell
komplexe, unüberschaubare Klassen entstehen können, die dem objektorientieren Paradigma
widersprechen. Eine strenge Trennung von lokalen und entfernten Objekten ist also notwendig.
Dies geschieht am sinnvollsten durch eine Adapterklasse als Schnittstelle zwischen entferntem und
lokalem Objekt.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 4. RMI – Remote Method Invocation
50
Client
Java Virtual
Machine
Server
Java Virtual
Machine
Local
Objekt
RMI
Local
Objekt
Local
Objekt
Remote
Objekt
RMI
RMI Registry
Abbildung III-17: Client/Server-Anwendungen und RMI
Übliches Einsatzszenario für RMI ist eine Client/Server-Verbindung. Der Server instanziert ein
Remote Object und sorgt dafür, daß der Zugriff auf die Objektreferenzen über das Netz möglich ist.
Eine Client-Applikation benutzt nun die Objektreferenzen, um Methoden der entfernten Objekte
aufzurufen. Objekte, die an einer solchen lokationstransparenten Objekt-Objekt-Kommunikation
teilhaben, werden in der Literatur zumeist als Verteilte Objekte bezeichnet.
4.2 Verteilte Anwendungen mit RMI
Welche Aufgaben übernimmt nun RMI in einer verteilten Anwendung? RMI bietet eine
Infrastruktur, die primär dazu dient, entfernte Objekte zu registrieren (RMI Registry), die ObjektObjekt-Kommunikation transparent zu halten (RMI Protokoll) und einen Mechanismus für die
Übertragung von Objekten zur Verfügung zu stellen (Objektserialisierung). Im folgenden werden
diese drei Aufgaben von RMI näher betrachtet.
Registrierung
Eine verteilte Anwendung besteht (per Definition) aus einer Client- und einer Serverkomponente.
Die Serverkomponente ruft nun die Registrierung auf und registriert die entsprechenden Remote
Objects. Prinzipiell wird dabei einem Remote Object (also einer Instanz) der (Klassen-)Name
zugeordnet und in der Registrierung eingetragen. Um eine Methode eines Remote Object aufrufen
zu können, muß sich ein Client zunächst eine Objektreferenz auf das gewünschte Objekt
beschaffen; danach ist ein Methodenaufruf möglich.
Protokoll
Das RMI-Protokoll basiert auf der Java-Objektserialisierung und dem HTTP-Protokoll. Dabei wird
die Objektserialisierung benutzt, um die Daten für den Methodenaufruf vorzubereiten (Marshaling,
Unmarshaling). Bei entfernten Methodenaufrufen versucht die Transportschicht des RMIProtokolls zuerst, die Methodenaufrufe über Sockets abzusetzen. Falls es Probleme mit einer
Firewall gibt, wird Tunneling mit HTTP (entweder HTTP-to-Port oder HTTP-to-CGI) verwendet.
Man hat auch die Möglichkeit, eine RMI-over-IIOP-Implementierung zu verwenden. Dabei wird
CORBA's IIOP zur Übertragung verwendet, während der Entwickler mit der RMI-API
programmieren kann. Nähere Informationen zum RMI-Protokoll sind unter [Sun 99b] und auf der
RMI-FAQ zu finden.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 4. RMI – Remote Method Invocation
51
Objektserialisierung
Es ist mit RMI möglich, den Bytecode der Klasse des Remote Objects dynamisch aus dem Netz zu
laden. Damit ist es möglich, bequem den Typ eines Objekts zu übergeben, der auf der Clientseite
unbekannt ist.
4.3 Programmieren mit RMI
Die Entwicklung von verteilten Java-Programmen mit RMI ist eigentlich nicht schwierig.
Allerdings muß bei der Entwicklung der Anwendung der Verteilungsaspekt genau geplant werden;
etwa welches Entwurfsmuster als Grundlage dient. Es ist im allgemeinen nicht sinnvoll, eine
Anwendung für eine Virtuelle Maschine zu programmieren und später RMI-Schnittstellen zu
implementieren. Im folgenden werden deshalb – neben der Beschreibung der wichtigsten Klassen
und Schnittstellen der RMI-API – auch Designaspekte berücksichtigt.
RMI-API
Die RMI-API besteht aus insgesamt vier Paketen:
•
java.rmi.*
•
java.rmi.server.*
•
java.rmi.registry.*
•
java.rmi.dgc.*
Den Kern von RMI bildet das Paket java.rmi. Es besteht aus einer Schnittstelle (Remote), zwei
Klassen (RMISecurityManager und Naming) und 16 Exceptions.
Das java.rmi.registry-Paket besteht aus nur 2 Schnittstellen (Registry und RegistryHandler) und
einer Klasse (LocateRegistry) mit denen typische Registrierungs-Aufgaben wie Kreieren einer
Registry oder Registrieren bei einer vorhandenen Registry durchgeführt werden können.
Das java.rmi.dgc-Paket wird normalerweise nicht vom Entwickler benötigt. Es dient zur verteilten
Garbage Collection.
Das rmi.server-Paket enthält Klassen wie RemoteObject und RemoteStub, wird also für die
Erweiterung von lokalen Methodenaufrufen um verteilte Aspekte verwendet.
Funktionsweise von RMI – Stubs und Skeletons
Sollen nun die Methoden eines lokalen Objekts z.B. über ein Netzwerk anderen Objekten zur
Verfügung gestellt werden, so muß die Schnittstelle Remote um die entsprechenden Methoden
erweitert werden (jede Methode muß eine java.rmi.RemoteException werfen). Ein Objekt, das
diese Schnittstelle implementiert, gilt als Remote Object.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 4. RMI – Remote Method Invocation
52
Client
Server
Java Virtual
Machine
Client
Objekt
Java Virtual
Machine
Stub
(Proxy)
RMI
Skeleton
Server
Objekt
Abbildung III-18: Funktionsweise von RMI – Stub und Skeleton
Trotz der gewünschten Lokationstransparenz der Objekte behandelt RMI lokale Objekte anders als
entfernte Objekte. Es wird z.B. keine Kopie des Serverobjekts zum Client geschickt, sondern
lediglich ein lokaler Stellvertreter (Proxy oder Stub) für das entfernte Objekt. Dieser Stub
implementiert – ebenso wie das Remote Object – die Remote-Schnittstelle bzw. eine Erweiterung
davon.
Eine Client-Anwendung, die entfernte Methoden aufrufen will, ruft also die entsprechenden
Methoden des Stubs auf, der sich um die Weiterleitung an das Remote Object kümmert. Ein
solcher Stub hat also folgende Aufgaben:
•
Annahme eines Methodenaufrufs als Stellvertreter des Remote Objects
•
Serialisierung der zu übergebenden Argumente und Senden zum Server
•
Deserialisierung der Antworten
Das Skeleton auf der Serverseite hat dementsprechend die Aufgaben
•
Annahme eines Methodenaufrufs
•
Deserialisierung der Argumente
•
Serialisierung der Antwort und Zurücksenden an den Client
Stub und Skeleton werden von rmic (einem RMI Compiler) aus der Implementierung des Remote
Interfaces generiert.
Anwendung von RMI
Folgende Abbildung zeigt, wie das RMI-Paket in Standard-Anwendungen verwendet wird. Hier
wird das Adapter-Designmuster verwendet, mit dem die Methoden des Remote Objects von einem
speziellen Adapter "umwickelt" werden. Vorteil bei diesem Design ist, daß Serverklassen wie
lokale Klassen entwickelt werden können. Der Verteilungsaspekt kommt erst mit dem Adapter
hinzu.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 4. RMI – Remote Method Invocation
53
java.lang.
Object
java.rmi.
Naming
java.lang.
SecurityManager
<<interface>>
java.rmi.Remote
java.rmi.
RMISecurityManager
<<interface>>
MyRemoteInterface
Der RemoteAdapter (auch:
RemoteWrapper) adaptiert die
entsprechenden Methoden
und hält so den
Verteilungsaspekt vor der
RemoteImplemention
vollkommen transparent
java.rmi.server
UnicastRemoteObject
RemoteAdapter
adapts
RemoteImplementation
Abbildung III-19: Anwendung von RMI
Um hier keine Verwirrung zu stiften: in vielen Büchern zu RMI wird kein Adapter-Muster
verwendet. In solchen Fällen sind RemoteAdapter und RemoteImplementation aus obiger
Abbildung identisch, d.h. die RemoteImplementation wird nicht als lokale Klasse entwickelt,
sondern speziell für die Anwendung als entferntes Objekt. Ein solches Design führt zu
verschiedenen Problemen, die z.B. in [JavaWorld 99] diskutiert werden.
Installation von RMI-Anwendungen
Die Konzepte von RMI sind relativ simpel. Dennoch kann es bei der Installation von RMIAnwendungen Probleme geben. Es folgt ein kurzer Überblick über die einzelnen Schritte bei der
Entwicklung und Installierung von RMI-Programmen.
1. Schreiben eines Remote Interfaces.
2. Schreiben eines RemoteAdapters, der das RemoteInterface implementiert und die
eigentliche Implementierung (RemoteImplementation) adaptiert.
3. Schreiben der Serveranwendung, also der RemoteImplementation. Diese Implementierung
bietet die eigentlich Funktionalität des Programms. Sie sollte als lokales Objekt entwickelt
werden, da der RemoteAdapter als Remote Object fungiert.
4. Schreiben des Clientprogramms.
5. Compilierung der Klassen.
6. Generierung von Stub und Skeleton mit dem rmic-Tool aus der Klasse RemoteAdapter.
7. Die CLASS-Files in die entsprechenden Verzeichnisse auf den Client- und auf den
Serverrechner kopieren.
8. Starten der RMI Registry auf dem Server mit dem Kommando start rmiregistry (Windows
NT). Die Registry kann übrigens auch direkt aus der Serveranwendung heraus gestartet
werden.
9. Starten der Serveranwendung, die dann den RemoteAdapter bzw. das RemoteInterface bei
der RMI Registry registriert.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 4. RMI – Remote Method Invocation
54
10. Starten der Clientanwendung.
Nun kann der Client die entfernten Methoden des Servers aufrufen. Natürlich ist es auch möglich,
Anwendungen zu schreiben, bei denen Client und Server ihre Rollen tauschen können, d.h. einmal
Dienste eines Servers anzufordern und auch selbst Dienste anzubieten. Die Entwicklung ist dann
etwas aufwendiger, da z.B. sowohl auf Client- als auch auf Serverseite eine RMI Registry gestartet
werden muß und auch Stubs und Skeletons für jede Seite doppelt generiert werden müssen.
4.4 Übergabe von Objekten
Mit RMI ist es möglich, nicht nur elementare Datentypen zu übergeben, sondern auch Objekte,
welche auf der Clientseite nicht bekannt sind. Dazu wird das zu übergebende Objekt serialisiert
und über das Netzwerk verschickt. Nach der Deserialisierung steht das Verhalten und der Typ eines
Objekts vollständig zur Verfügung. Die Möglichkeit, unbekannte Klassen (Objekte) während der
Laufzeit zu laden, wird dynamisches Laden von Klassen oder dynamic class loading genannt.
Wichtigster Vorteil ist, daß bei der Übertragung an eine andere Virtuelle Maschine weder Typ noch
Verhalten des entsprechenden Objekts geändert werden.
Übergabe von Objekten
Bei den zu übergebenden Objekten wird zwischen
•
primitiven Datentypen (int, lang, ..)
•
serialisierbaren und
•
entfernten
Objekten unterschieden.
Primitive Datentypen sind problemlos als Argumente für RMI-Aufrufe verwendbar. Entfernte
Objekte werden als Referenz übergeben. Die Referenz auf ein entferntes Objekt ist dabei ein
clientseitiger Stellvertreter (Proxy) für das entfernte Objekt. Lokale Objekte können nur übergeben
werden, wenn sie serialisierbar sind (also wenn sie die Serializable-Schnittstelle implementieren).
Übergabe "by-reference"
Diese Übergabevariante ist bei RMI Standard. Remote Objects werden hier prinzipiell als Referenz
übergeben. Wie schon weiter oben beschrieben ist die Referenz auf ein Remote Object der
clientseitige Stub, also das entsprechende lokale Stellvertreter-Objekt.
Der Unterschied zur Argumentübergabe "by-value" ist, daß bei Änderungen des Objektzustandes
auch der Zustand des referenzierten Objektes geändert wird.
Zu beachten ist, daß nur auf Methoden zugegriffen werden kann, die auch im Remote Interface
deklariert sind. Enthält das Remote Object also noch weitere Methoden (z.B. Implementierungen
von lokalen Schnittstellen), dann sind diese Methoden für den Client nicht verfügbar.
Übergabe "by-value"
Lokale Objekte werden normalerweise "by-value" übergeben. Das heißt, daß eine reine
Wertübergabe stattfindet: das zu übergebende Objekt wird kopiert und ist vollkommen unabhängig
vom Original-Objekt. Die Kopie eines solchen lokalen Objekts wird durch die Objektserialisierung
erstellt.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 4. RMI – Remote Method Invocation
55
4.5 Komponentenbasierte Entwicklung von RMI-Anwendungen
In diesem Unterkapitel wird kurz darauf eingegangen, wie die Konzepte der
Komponententechnologie auch bei Client/Server-Anwendungen verwendet werden können. Hier
soll ausdrücklich nicht von Enterprise JavaBeans (EJB) die Rede sein, sondern vom JavaBeans
Komponentenmodell.
Client-Komponenten
Am einfachsten ist die Verwendung der Komponententechnologie auf der Clientseite. Hier ist
meist ein GUI vorhanden, das beispielsweise Abfrageergebnisse visualisiert. Der Client kann
problemlos als JavaBean entwickelt werden. Als Bean Properties kommen z.B. der Hostname des
Servers oder Username und Paßwort in Frage. Eine solche Client-Bean kann somit problemlos an
den Server angepaßt werden, z.B. bei einer Neuinstallation des Servers auf einem neuen Rechner.
Client
Server
Java Virtual
Machine
ClientBean
Java Virtual
Machine
RMI
ServerBean
(DB-Zugriff)
JDBC
DB
Abbildung III-20: Komponententechnologie und RMI
Ansonsten benutzt das clientseitige GUI selbst wieder JavaBeans, um graphische Komponenten
darzustellen. Auch eine konfigurierbare Ausgabeschnittstelle z.B. zur Visualisierung der
Ergebnisse von entfernten Methodenaufrufen läßt sich so gut integrieren.
Server-Komponenten
Auf der Serverseite ist es schwieriger, JavaBeans zu entwickeln. Vorstellbar ist hier z.B. eine Bean
zur Datenbankabfrage, bei der die Properties dann eben die IP-Adresse der Datenbank und
Username und Paßwort sind.
Sun Microsystems bietet mit Enterprise JavaBeans (EJB) eine Spezifikation für
Serverkomponenten an. Dieses Modell beinhaltet typische Serverfunktionalitäten wie
Transaktionen und Sicherheit (wird im folgenden Kapitel näher besprochen).
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 5. EJB - Enterprise JavaBeans
5 EJB
56
- Enterprise JavaBeans
Professionelle serverseitige Anwendungen müssen skalierbar, flexibel
und hochperformant sein. Sie sollen auf verschiedenen Plattformen – nach Möglichkeit ohne
Quellcodeänderungen – lauffähig sein und auch hochgradig heterogene Umgebungen unterstützen.
Die Enterprise JavaBeans (EJB) Spezifikation von Sun Microsystems definiert eine
Komponentenarchitektur, die speziell für Webserver entwickelt wurde und hervorragend für
derartige Anwendungen geeignet ist. Enterprise JavaBeans sind eine Kompoenentenarchitektur, die
eine verteilte Objektarchitektur nutzt und für n-stufige (n-Tier) Applikationen verwendet werden
kann.
Noch eine Anmerkung: Dieses Kapitel wurde nach dem Erscheinen von [Monson-Haefel 99]
nochmals leicht überarbeitet. Es wurde aus Gründen der besseren Lesbarkeit darauf verzichtet, bei
jeder vorgenommenen Änderung auf dieses Buch zu verweisen.
5.1 Überblick über Enterprise JavaBeans
Einführung in Enterprise JavaBeans
Enterprise JavaBeans ist eine relativ junge Technologie, die eine Abstraktion für Component
Transaction Monitors (CTMs) bietet [Monson-Haefel 99]. Der Begriff CTM wurde Anfang 1999
von Anne Thomas (Patricia Seybold Group) geprägt, um die Integration von verteilten
Objektdiensten wie CORBA's ORB (Object Request Broker) in herkömmliche
Transaktionsmonitore zu beschreiben. Ein EJB-Server ist also ein CTM, der zu der EJBSpezifikation konform ist. EJB bietet damit die Möglichkeit, serverseitige Anwendungen zu
schreiben und sich dabei ausschließlich auf die Geschäftslogik konzentrieren zu können.
Als EntwicklerIn kann man mit EJB auf komplexe CTM-Dienste wie Transaktionsmanagement,
Sicherheit, Persistenz und Nebenläufigkeit auf einer hohen Abstraktionsebene zugreifen, was die
Entwicklung stark vereinfacht.
Definitionen
Die beiden folgenden Definitionen von Enterprise JavaBeans stammen aus [Monson-Haefel 99].
Sun Microsystems hat Enterprise JavaBeans wie folgt definiert:
The Enterprise JavaBeans architecture is component architecture for the development and
deployment of object-oriented distributed enterprise-level applications. Applications written using
the Enterprise JavaBeans architecture are scalable, transactional, and multi-user secure. These
applications may be written once and deployed on any server platform that supports the Enterprise
JavaBeans specification.
Diese ausführliche Definition wurde von Richard Monson-Haefel etwas verkürzt:
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 5. EJB - Enterprise JavaBeans
57
Enterprise JavaBeans is a standard server-side component model for component transaction
monitors (CTMs).
Wie schon in der Einführung beschrieben, sind CTMs eine neue Bezeichnung für
Transaktionsmonitore, die mit verteilten Objekttechnologien arbeiten. Nähere Informationen zu
CTMs sind in [Monson-Haefel 99] zu finden.
Unterschiede zwischen JavaBeans und Enterprise JavaBeans
JavaBeans ist die Spezifikation des Komponenentenmodell für Java. Auch Enterprise JavaBeans
(EJB) ist eine Spezifikation für ein Komponentenmodell, das sich jedoch in einigen Punkten vom
JavaBeans-Modell unterscheidet. Ziel von JavaBeans war, für Java eine Komponentenarchitektur
zur Verfügung zu stellen, mit der gerade die visuelle Entwicklung von Beans möglich sein sollte.
Diese Technologie steht somit in Konkurrenz zu Microsoft's ActiveX-Komponentenmodell.
Die EJB-Architektur hingegen wurde nicht für visuelle Entwicklung von Komponenten entwickelt.
Das Ziel war vielmehr, eine Architektur zu schaffen, in die verteilte Java-Komponenten portierbar
eingefügt werden können.
Vor der Diskussion der Unterschiede zwischen beiden Komponentenarchitekturen sind zunächst
die Gemeinsamkeiten zu betrachten. JavaBeans und EJBs spezifizieren Modelle für Komponenten.
Komponenten unterscheiden sich von normalen Klassen (aus denen sie ja bestehen) hauptsächlich
dadurch, daß sie externe Schnittstellen haben (Properties oder Eigenschaften), über die sie sich in
anderen Umgebungen anpassen können. Damit ein Container (z.B. eine Entwicklungsumgebung)
eine Bean oder eine Enterprise Bean analysieren kann, müssen bestimmte Punkte, z.B.
Namenskonventionen bei der Entwicklung berücksichtigt werden. Eine wichtige Gemeinsamkeit ist
beiden Modellen, daß während der Entwicklung mehrere Komponenten miteinander bequem
verkettet werden können. Populär ist dies gerade bei graphischen JavaBeans-Komponenten, mit
denen schnell GUIs "zusammengeklickt" werden können. Allerdings müssen JavaBeans
keineswegs immer einen graphischen Aspekt haben.
Enterprise JavaBeans sind dagegen nicht-visuelle Komponenten, die für den serverseitigen Einsatz
entwickelt wurden und die als Remote Objects von Clients aufgerufen werden. Der DeploymentDescriptor der Enterprise Beans dient dem gleichen Zweck wie die Properties der JavaBeans: einer
definierten Umgebung (Container) die Möglichkeit zu geben, die Eigenschaften zu ermitteln und
die Komponente gegebenfalls anzupassen.
Der erwähnte Deployment-Descriptor (Deployment ist der EJB-Ausdruck für die Installation auf
einem Server) der Enterprise Beans enthält Informationen zu speziellen, für den Server-Einsatz
wichtigen Eigenschaften, z.B. zum Transaktionsverhalten, zur Sicherheit oder zur Persistenz. EJBServer verfügen meist über Administrationstools, die es erlauben, die Eigenschaften einer
Enterprise Bean zu lesen und sie in einem Container zu installieren.
Es ist wichtig, sich vor Augen zu halten, daß sowohl JavaBeans also auch EJB Spezifikationen für
Komponentenmodelle sind, die jedoch unterschiedliche Ziele verfolgen. JavaBeans können sowohl
auf Client- als auch auf Serverseite eingesetzt werden. Und zwar für visuelle und nicht-visuelle
Anwendungen. Will man allerdings Serveranwendungen mit JavaBeans schreiben, muß man sich
um Low-Level-Details wie Transaktionsverwaltung selbst kümmern – und das kann aufwendig
werden.
Kommunikation mit anderen Komponentenmodellen
Die eigentliche Stärke von JavaBeans liegt darin, daß die Kommunikation mit anderen
Komponentenmodellen wie CORBA oder Microsoft's DCOM (mehr oder weniger) problemlos
möglich ist. Anwendungen, die diese alternativen Komponentenmodelle verwenden, sind somit in
der Lage, mit JavaBeans-Komponenten zu kommunizieren oder sogar (über Standardinterfaces)
Beans zu verwenden.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 5. EJB - Enterprise JavaBeans
58
Besonders interessant ist hier natürlich die Interaktion von Enterprise Beans auf der Serverseite mit
den clientseitigen JavaBeans. Das könnte in Zukunft dazu führen, daß auch komplexe, mehrstufige
Anwendungen entwickelt werden können, ohne Sourcecode zu programmieren.
Migration von Legacy-Anwendungen zu Java-basierten Systemen
Für viele Firmen, die noch alte Hard- und Software verwenden, sind Enterprise JavaBeans eine
Möglichkeit, Schritt für Schritt die alten Systeme abzulösen und auf eine moderne Client/ServerArchitektur und Java umzusteigen. Dazu wird um einzelne Module des bestehenden Systems eine
EJB-Schicht programmiert, die die Kommunikation mit modernerer Komponentensoftware erlaubt.
So kann die alte Software mit neuen Tools bearbeitet und in eine heterogene Rechnerstruktur
integriert werden. Das ist keine leichte Aufgabe, ist aber bei entsprechender Sorgfalt gut möglich.
Im Laufe der Zeit können dann einzelne alte Softwareteile durch "echte" JavaBeans-Komponenten
abgelöst werden. Dies ist für das System vollkommen transparent und ermöglicht den Umstieg auf
Java-basierte Technologien ohne Unterbrechungen und Störungen des Geschäftsablaufs.
3-stufige Architekturen
Enterprise JavaBeans werden zumeist in 3-stufigen Architekturen als Middle-Tier verwendet. Der
Grund für die Verwendung von 3-stufigen Architekturen ist die heutige Vielfalt an Client- und
Serversystemen. Für die Kommunikation zwischen Client-Systemen wie HTML, Java Applets,
CORBA/COM oder PDAs und Server-Systemen wie relationalen und objektorientierten
Datenbanken, Filesystemen und Legacy-Anwendungen ist eine Zwischenstufe notwendig: der
Applikationsserver. Folgende Abbildung stellt diesen Sachverhalt nochmals dar (nach [Javaworld
99]):
WITHOUT AN APPLICATION SERVER
Client
Backend
HTML
CICS,
3270, other
legacy
apps
Java
CORBA
COM
Special
Devices
PDAs, Web
phones,
Kiosks, Smart
Cards, SetTop Boxes,...
?
WITH AN APPLICATION SERVER
Client
Middle Tier
HTML
Application Server
-
Java
-
CORBA
COM
-
Special
Devices
-
DB
Files
PDAs, Web
phones,
Kiosks, Smart
Cards, SetTop Boxes,...
-
Web: HTTP,
CGI/Servlets, JSP
Componentes:
CORBA, EJB/RMI,
DCOM
Data Access: JDBC
Transaction
Management: XA,
JTS/JTA
Security: SSL, ..
Directory/Naming:
JNDI
Fault Tolerance
Load Balancing
Resource Pooling
Auditing, Logging
Monitoring
...
Backend
CICS,
3270, other
legacy
apps
DB
Files
Abbildung III-21: Warum 3-stufige Architekturen verwenden?
Aus heutiger Sicht führt an einem Middle-Tier kein Weg mehr vorbei. Die Integration zahlreicher
verschiedener heterogener Systeme mit modernen EJB-Anwendungen oder alten Legacy-Systemen
ist kaum möglich ohne eine 3-stufige Architektur.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 5. EJB - Enterprise JavaBeans
59
5.2 Vorteile von EJB
An dieser Stelle sollen die Vorteile bei der Verwendung der EJB-Technologie einmal
zusammengefaßt werden. Im wesentlichen handelt es sich bei diesen Vorteilen um Skalierbarkeit,
Resourcenmanagement, Portabilität, Integration von Komponententechnologien, Sicherheit und
verteilte Transaktionen.
Skalierbarkeit
Im Unterschied zu den schlecht skalierbaren CGI-Anwendungen lassen EJBs kaum noch Wünsche
offen. Als AnwendungsentwicklerIn muß man sich hier kaum Gedanken über Möglichkeiten der
Skalierbarkeit3 machen, da die relevante Funktionalität vom EJB-Server implementiert werden
muß.
Resourcenmanagement
Das Resourcenmanagement bleibt für den Anwendungsentwickler wegen der Verlagerung der
Problematik in den EJB-Server transparent. So werden Enterprise JavaBeans nach Bedarf
instanziert und auch wieder zerstört.
Portabilität
Gut geschriebene EJBs laufen nahezu ohne Codeänderungen auf allen Webservern, welche die
EJB-Spezifikation korrekt implementieren. Bei einem Wechsel des EJB-Servers dürften eigentlich
lediglich Änderungen am Deployment-Descriptor notwendig werden – und bei modernen EJBServern ist die Generierung eines Deployment-Descriptors in Form von Wizards oder anderen
Installationstools bequem möglich.
Komponententechnologie
Die EJB-Komponententechnologie macht es möglich, sehr komplexe Anwendungen portabel zu
entwickeln. Bei einem Einsatz von clientseitiger Komponententechnologie (JavaBeans) ist die
gesamte verteilte Anwendung komponentenbasiert, was zu schnelleren Entwicklungszyklen führt.
Insbesondere können einzelne EJB-Komponenten ohne allzu großen Aufwand und vor allem ohne
Änderungen der Systemarchitektur hinzugefügt, geändert oder entfernt werden (Plug & Play von
Komponenten). Die wohldefinierten Schnittstellen machen also Änderungen möglich, ohne sich
mit dem Quellcode befassen zu müssen.
Mit dem EJB-Komponentenmodell ist auch die Kommunikation mit anderen
Komponentenmodellen (CORBA, DCOM/ActiveX) möglich. Dies führt zu einer großen
Flexibilität bei der Integration heterogener Systeme. Besondere Vorteile bietet die EJBKomponententechnologie bei clientseitiger Verwendung von JavaBeans, da hier eine
Komponenten-Komponenten-Interaktion ohne Paradigmenbrüche realisiert werden kann.
3
Wenn man im Serverbereich von Skalierbarkeit spricht, dann bezieht man sich zumeist darauf,
•
wie viele Clients das System parallel benutzen können.
•
wie viele Objekte (hier: Beans) in einer bestimmten Zeit instanziert werden können.
•
wie viele Transaktionen pro Sekunde möglich sind.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 5. EJB - Enterprise JavaBeans
60
Ausfallsicherheit
Bei serverseitigen Anwendungen ist eine möglichst große Ausfallsicherheit wichtig. Mit Enterprise
Beans kann man redundante Komponenten in die Systemarchitektur einplanen. Damit ist es
möglich beim Ausfall von einzelnen Komponenten auf die redundanten Komponenten
auszuweichen (mehrere Redundanzebenen).
Unterstützung verteilter Transaktionen
Die EJB-Spezifikation delegiert schwierige Probleme an die Hersteller von EJB-Servern. Als
AnwendungsentwicklerIn kann man so auf komplexe Features wie verteilte Transaktionen oder ein
erweitertes Sicherheitsmodell zugreifen. Es ist so z.B. möglich, in einer Session-Bean eine
Methode einer anderen Session-Bean aufzurufen, die im selben Transaktionskontext ausgeführt
wird, ohne daß man sich um Details kümmern muß.
5.3 Nachteile von EJB
Einige lesenswerte Artikel zum Thema sind auf den Websites [Microsoft 98], [ObjectWatch 98a],
[ObjectWatch 98b], [Chappell 98] und [Cleeland 99] zu finden. Diese Artikel vergleichen zumeist
MTS mit Enterprise JavaBeans.
Hohe Komplexität
Ein wesentlicher Nachteil von Enterprise JavaBeans ist die hohe Komplexität. Im Vergleich zum
DCOM-basierten MTS (Microsoft Transaction Server) ist die EJB-Spezifikation – gerade im
Bereich der Transaktionen - sehr viel komplexer – allerdings auch flexibler. Man kann diesen
Nachteil allerdings relativieren: Eine größere Flexibilität impliziert normalerweise eine höhere
Komplexität und ist im allgemeinen eher wünschenswert.
Fixierung auf die Java-Programmiersprache
Ein anderes Problem ist die Fixierung auf eine Programmiersprache (Java) und ein
Übertragungsprotokoll (RMI oder RMI-over-IIOP). Hier bietet z.B. der MTS eine größere
Flexibilität, da Anwendungen in mehren Programmiersprachen (z.B. C++ und Visual Basic)
geschrieben werden können.
Keine Referenzimplementierung
Da keine Referenzimplementierung existiert, besteht die Gefahr, daß Sun's EJB-Spezifikation von
Herstellern aufgeweicht und/oder erweitert wird. Die Administration von EJB-Anwendungen
unterscheidet sich von Hersteller zu Hersteller zum Teil gravierend.
Spezifikation wird von Sun geschrieben
Leider wird die EJB-Spezifkation nicht von der OMG (Object Management Group) geschrieben
oder erweitert, sondern ausschließlich von Sun Microsystems. Natürlich arbeiten auch andere
Hersteller zusammen mit Sun an der Spezifikation, aber Sun entscheidet am Ende alleine über die
Spezifikation.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 5. EJB - Enterprise JavaBeans
61
5.4 Rollen bei der EJB-Entwicklung
Sun Microsystems hat in der EJB-Spezifikation verschiedene Rollen bei der Entwicklung,
Installation und Administration von Enterprise JavaBeans definiert [Sun 99c]. In der Praxis sind
jedoch Überschneidungen möglich. So sind z.B. EJB Provider und Application Assembler
normalerweise eine Person bzw. ein Team. Auch werden die Aufgaben des Deployers zumeist vom
System Administrator übernommen.
Im folgenden werden die englischen Begriffe aus der Spezifikation unübersetzt übernommen. Die
Bezeichnungen in Klammern stammen aus dem EJB-Guide von Nova [Nova 99] und beschreiben
die jeweilige Rolle meistens besser.
EJB Provider (EJB Developer)
Mit diesem Begriff meint Sun einen Entwickler von Enterprise JavaBeans. Typischerweise muß
man sich als EJB-Entwickler nicht mit Low-Level-Details wie Transaktionen oder Sicherheit
befassen, weil diese Bereiche laut EJB-Spezifikation vom Container Provider übernommen
werden.
Application Assembler (Application Developer)
Ein Application Assembler schreibt keine neuen Enterprise Beans sondern kombiniert verschiedene
Beans (unter Umständen von verschiedenen EJB Providers) und paßt sie an die spezifischen
Anforderungen an. Das Ergebnis ist zumeist ein JAR-File, welches die angepaßten und aufeinander
abgestimmten EJBs enthält. Zu den Aufgaben des Application Assemblers gehört auch das
Schreiben eines Deployment-Descriptors oder die Integration von EJBs in eine bestehende
Infrastruktur (z.B. Java Server Pages).
Deployer (EJB Deployer)
Der Deployer ist zuständig für die Installation (Deployment) von Enterprise JavaBeans in einem
firmenspezifischen EJB-Container. Dazu werden die EJBs als JAR-File direkt vom Application
Assembler oder EJB Provider übernommen und in die entsprechenden Verzeichnisse installiert.
Gegebenenfalls muß noch eine Anpassung an das entsprechende Betriebssystem und eine
Optimierung vorgenommen werden. Zu den Aufgaben des Deployers gehört auch die Übertragung
von Sicherheitsrechten an bestimmte Benutzergruppen.
Server/Container Provider (Server/Container Vendor)
Der Server/Container Provider ist üblicherweise ein Hersteller von Betriebssystemen, Datenbanken
oder Applikationsservern und entsprechend ein Experte für Transaktionen und Sicherheit. Ein
solcher Provider stellt Tools zur Verfügung, mit denen EJBs installiert und angepaßt werden
können. In welchem Umfang weitere Tools existieren, bleibt dem Provider überlassen. Er muß
jedoch einen EJB-Container zur Verfügung stellen, der die jeweilige EJB-Spezifikation umsetzt.
System Administrator
Der System Administrator ist für die Überwachung und Optimierung von installierten EJBs
zuständig. Normalerweise werden dafür spezielle Tools vom Server/Container Provider zur
Verfügung gestellt.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 5. EJB - Enterprise JavaBeans
62
5.5 EJB Architektur
Überblick
Enterprise JavaBeans werden meistens in 3-stufigen Architekturen als Middle-Tier verwendet.
Folgende Abbildung zeigt den prinzipiellen Aufbau einer solchen Architektur:
EJB Server
EJB Container
Client
Sicht des Clients
DB
EJB
EJB
EJB
Dienste
Transaction, Naming,
Persistence
Abbildung III-22: Überblick über die EJB-Architektur
Wie man sieht enthält der EJB Server (mindestens) einen Container, in dessen Kontext sich die
Enterprise Beans befinden. Wie diese Beans von einem Client angesprochen werden können, wird
in den folgenden Unterkapiteln beschrieben.
Folgendes UML-Klassendiagramm beschreibt die Beziehungen zwischen einem EJB-Server und
einem EJB-Container:
EJBServer
1
enthält
0..*
EJBContainer
1
verwaltet
0..*
EnterpriseBean
EntityBean
SessionBean
Abbildung III-23: UML-Klassendiagramm der EJB-Architektur
In diesem Diagramm wird nicht zwischen einer zustandslosen und einer zustandsbehafteten
Session-Bean unterschieden. Der Unterschied zwischen beiden Beantypen ist, daß bei einer
Zustandsbehaftung der Kontext der Sitzung abgespeichert werden muß. In einer konkreten
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 5. EJB - Enterprise JavaBeans
63
Implementierung muß beispielsweise bei einer SessionBean noch eine Zustandsklasse
dazukommen, die den Kontext der Sitzung verwaltet. Aber das soll nicht das Thema dieser
Diplomarbeit sein.
EJB Server
Der EJB Server ist eine Middleware (etwa ein Applikationsserver), die eine Infrastruktur zur
Ausführung von EJBs zur Verfügung stellt. In Sun's EJB Spezifikation heißt es lediglich, daß
Hersteller von EJB Servern Session- und/oder Entity-Container gemäß der Spezifikation [Sun 99c]
implementieren müssen. Es wird zwar erwähnt, daß eine zukünftige EJB Spezifikation die
Schnittstellen zwischen EJB-Server und -Container möglicherweise näher spezifizieren wird,
tatsächlich jedoch gibt es zur Zeit keine Hinweise darauf, wie solche standardisierten Schnittstellen
aussehen sollen. Entsprechend gibt es verschiedene Ansätze für die Architektur von EJB-Servern.
Der Oracle-Applikationsserver etwa bietet neben den üblichen Features (z.B. Cartridges für HTTPRequests) auch eine Cartridge für Enterprise JavaBeans an. Der PowerTier-Server von Persistence
ist ein reiner EJB-Server, d.h. es werden nur EJBs unterstützt.
Ein EJB Server muß einen oder mehrere EJB Container zur Verfügung stellen, in denen die
Enterprise Beans installiert werden können.
EJB Container
Ein EJB Container muß die installierten Enterprise Beans verwalten. Dazu muß er folgende
Funktionalitäten bieten:
•
Registrierung der EJB
•
Verwaltung des EJB-Lebenszyklus
•
Persistenz für Entity-Beans
•
Transaktionsmanagement (Koordinierung verteilter Transaktionen)
•
Bereitstellung eines Remote Interfaces
Die EJB-Spezifikation läßt Herstellern viele Freiheiten bei der Implementierung von EJBServern/Containern. Wichtig ist nur, daß ein EJB-Container stets im Kontext eines Servers läuft.
Ob der Server ein reiner EJB-Server ist oder noch weitere Standards unterstützt ist dabei nicht
relevant.
Folgende Abbildung zeigt den internen Aufbau eines Containers für Enterprise Beans:
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 5. EJB - Enterprise JavaBeans
Sicht des
Clients
64
EJB Server
EJB Container
Methoden
Remote
Interface
Client
create()
find()
remove()
Home
Interface
Deployment
Descriptors
Enterprise
Bean
Environment
Dienste
Bean
Identifier
Transaction
Naming
Persistence
Abbildung III-24: Aufbau eines EJB-Containers
Wie aus obiger Abbildung ersichtlich, dient der EJB-Container als Schnittstelle zwischen dem
Client und der Enterprise JavaBean. Der Container generiert das Home-Interface automatisch,
wenn der EJB-Server gestartet wird. Diese Schnittstelle dient nicht dem Aufruf von AnwendungsMethoden sondern um EJB-Instanzen zu kreieren, aufzufinden und zu entfernen. Die ObjektSchnittstelle dient zum Zugriff auf die eigentliche Anwendungslogik (Business Objects).
Remote Interface
Das Remote Interface erweitert das EJBObject-Interface und bietet eine Auflistung aller
Methoden der betreffenden Enterprise Bean. Das Remote Interface wiederum wird vom ClientStub implementiert (diese Implementierung wird mit dem rmic-Tool automatisch generiert). Der
Client verwendet dann diese Implementierung, um auf die Business-Methoden der Enterprise Bean
zuzugreifen. Das heißt also, daß der Client keinen direkten Zugriff auf eine Instanz einer EJB hat.
Es muß stets das Remote Interface (bzw. dessen Implementierung) verwendet werden. Folgende
Abbildung macht den Sachverhalt klarer:
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 5. EJB - Enterprise JavaBeans
65
EJB Server
EJB Container
Client
EJB Home
Stub
Deployment
Descriptor
RMI/CORBA
EJB-Home
create()
find()
remove()
EJB Remote
Stub
Enterprise
Bean
Environment
RMI/CORBA
EJB-Object
BusinessMethods
Dienste
Transaction
Naming
Persistence
Abbildung III-25: Detaillierter Aufbau eines EJB-Containers
Auch die serverseitige Implementierung des Remote Interfaces (das sogenannte Skeleton) wird
automatisch vom rmic-Tool (oder einem entsprechenden Tool des Container-Herstellers)
generiert.4
Home Interface
Diese Schnittstelle dient zum Kreieren, Auffinden und Entfernen von EJB-Klassen. Die
Implementierung dieser Schnittstelle wird EJB-Home genannt. Ist ein Client daran interessiert, die
Dienste einer EJB in Anspruch zu nehmen, muß die create-Methode der EJB-Home-Klasse
aufgerufen werden. Diese Methode instanziert das EJB-Object (die Implementierung des Remote
Interfaces) und die Bean-Klasse. Die Referenz auf die Bean-Klasse wird dann an das EJB-Object
4
Es gibt für den Container-Hersteller verschiedene Strategien, Stubs und Skeletons zu generieren (aus
[Monson-Haefel 99]):
•
Das Skeleton ist eine Implementierung des Remote Interfaces. Es hat eine Referenz auf die Enterprise
JavaBean-Klasse.
•
Das Skeleton implementiert das Remote Interface, erweitert jedoch zusätzlich die EJB-Klasse (d.h. es ist
keine explizite Referenz auf das Bean vorhanden).
•
Das Skeleton implementiert das Remote Interface und die javax.ejb.EnterpriseBean-Schnittstelle. Das
heißt, daß die eigentliche Bean-Klasse nicht mehr im Modell enthalten ist. Hier hat das Skeleton also
sowohl eine proprietäre Implementierung des Remote Interfaces als auch eine Implementierung der
Bean-Methoden.
Die meisten Hersteller verwenden die erste Strategie. Wichtig ist jedoch, sich klarzumachen, daß das EJBObject zwar stets vorhanden ist, daß die eigentliche Implementierung aber herstellerspezifisch ist und
automatisch generiert wird.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 5. EJB - Enterprise JavaBeans
66
weitergegeben. Anschließend wird die ejbCreate-Methode der Bean aufgerufen (bei Entity-Beans
wird ein neuer Datensatz in die Datenbank eingefügt und bei Session-Beans wird eine
Initialisierung durchgeführt).
Deployment-Descriptor
Jede Enterprise Bean hat eine Vielzahl von Eigenschaften. Session-Beans können z.B. zustandslos
oder zustandsbehaftet sein und einen bestimmten Timeout festlegen. Diese Informationen sind
nicht in der Bean selbst enthalten, sondern in einem sogenannten Deployment-Descriptor. Ein
Deploment Descriptor wird zusammen mit der entsprechenden Bean in ein JAR-File gepackt und
im Server installiert. In ihm sind Konfigurationsinformationen vorhanden, die von der Enterprise
Bean benötigt werden.5
Mit dem Deployment-Descriptor ist es möglich, wichtige Informationen über die Bean zu erhalten
und mit bestimmten Methoden auch zu manipulieren. Idealerweise verfügt der Applikationsserver
über ein geeignetes Tool, mit dem sich leicht bestimmte Eigenschaften – z.B. der Timeout einer
Sitzung – ändern lassen. Dazu sind lediglich Kenntnisse über Server-Administration nötig – es muß
kein Sourcecode geändert werden.
Der Deployment-Descriptor ist ein XML-Dokument, das zu der Dokumenttyp-Definition (DTD) in
der EJB-Spezifikation [Sun 99c] konform ist. Üblicherweise bieten die Hersteller von EJBServern/Containern Tools zur Erstellung des Deployment-Descriptors an. Möglich ist jedoch auch
die manuelle Erstellung. Um die Gültigkeit (im XML-Sinne) eines Deployment-Descriptors zu
verifizieren, plant Sun Microsystems, ein spezielles Tool zur Verfügung zu stellen. Zur Zeit
(August 1999) ist jedoch noch kein Veröffentlichungstermin bekannt. Folgender Codeausschnitt
zeigt, wie ein konkreter Deployment-Descriptor aussehen könnte:
<!DOCTYPE ejb-jar PUBLIC “-//Sun Microsystems, Inc.//DTD Enterprise
JavaBeans 1.2//EN” “http://java.sun.com/j2ee/dtds/ejb-jar_1_2.dtd”>
<ejb-jar>
<description></description>
<enterprise-beans>
<session>
<description></description>
<ejb-name>EmployeeService</ejb-name>
<home>com.wombat.empl.EmployeeServiceHome</home>
<remote>com.wombat.empl.EmployeeService</remote>
<ejb-class>com.wombat.empl.EmployeeServiceBean</ejb-class>
<session-type>Stateful</session-type>
<transaction-type>Bean</transaction-type>
...
</session>
...
</ejb-jar>
Codebeispiel III-17: XML-basierter Deployment-Descriptor
Dieser Deployment-Descriptor ist ein kurzer Ausschnitt aus dem kompletten Beispiel, das in der
Spezifikation [Sun 99c] abgedruckt ist. In der Spezifikation kann man auch die gut kommentierte
DTD finden.
5
In der Version 1.0 der EJB-Spezifikation war ein Deployment-Descriptor noch eine serialisierte Instanz von
javax.ejb.deployment.DeploymentDescriptor. Das javax.ejb.deployment-Paket wurde in der Version 1.1 der
Spezifikation durch einen XML-basierten Deployment-Descriptor ersetzt.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 5. EJB - Enterprise JavaBeans
67
5.6 Session und Entity-Beans
An enterprise Bean that implements a business task is a session Bean, and an enterprise
Bean that implements a business entity is an entity bean.
Monica Pawlan
Überblick
Für komplexe Server-Anwendungen existieren zwei verschiedene Modelle:
1) Die Serverkomponente ist eine Anwendung, die Requests des Clients bearbeitet
2) Eine Serverkomponente repräsentiert eine Entität in einer Datenbank
Das erste Modell ist ein eher klassischer Client/Server-Ansatz. Der Client nimmt Dienste (z.B.
Datenbankanfragen) des Servers in Anspruch. Eine Komponente des Servers (z.B. eine EJB)
repräsentiert eine (transiente) Sitzung. In einer solchen Sitzung können z.B. Datenbankanfragen
gestellt oder Metainformationen über die Datenbank abgerufen werden. Diese Datenbankzugriffe
werden also im Kontext einer Sitzung durchgeführt. Bei einem client- oder serverseitigen Crash
gehen die Daten verloren.
EJB Server
EJB Container
Client A
Client B
Session
Bean
(Zustandslos)
Session Bean
(Instanz 1)
Entity Bean
(Instanz 1)
Relation
Tupel 1
Tupel 2
...
Tupel n
Entity Bean
(Instanz 2)
Entity Bean
(Instanz n)
Client C
JDBC
RMI
Session Bean
(Instanz 2)
Abbildung III-26: Session-Beans und Entity-Beans
Das zweite Modell wird heutzutage primär bei objektorientierten Datenbanken verwendet. Ein
Serverobjekt ist eine Repräsentation von Daten in einer Datenbank. Beispielsweise könnte ein
Adreßbuch durch die EJB Addressbook repräsentiert werden. Addressbook ist eine Relation in
einer relationalen Datenbank; jeder Adreßbucheintrag ist ein Tupel dieser Relation. Die Enterprise
Bean bietet nun Methoden zur Manipulation der Daten an. Sinnvoll ist z.B. eine Funktion zum
Einfügen neuer Adressen oder zur Änderung bestehender Adressen.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 5. EJB - Enterprise JavaBeans
68
Session-Beans
Session-Beans dienen zur Workflow-Modellierung, implementieren also die sogenannte Business
Logic. Man unterscheidet zustandsbehaftete und zustandslose Session-Beans.
Zustandsbehaftetete Session-Beans
Ist eine Session-Bean zustandsbehaftet, muß für jede Sitzung eine neue Instanz kreiert werden.
Eine Instanz dieser Bean wird auf die Anfrage eines Clients instanziert und existiert nur für die
Dauer der Sitzung. Zustandsbehaftete (Stateful) Session-Beans sind normalerweise nicht persistent;
der Zustand wird lediglich im Hauptspeicher des Servers festgehalten. Falls der Server (oder der
Container) abstürzt, ist der Zustand verloren.
Zustandslose Session-Beans
Eine Instanz einer zustandslosen Session-Bean kann gleichzeitig mehrere Anfragen
(Methodenaufrufe) verschiedener Clients entgegennehmen und bearbeiten. Zustandslose SessionBeans nehmen Client-Anfragen entgegen und führen sie aus. Es ist vollkommen irrelevant, ob die
Bean zwischen zwei Anfragen (z.B. aus Speichergründen) vom Container entfernt und
wiederhergestellt wurde, oder ob sie sich dauerhaft im Speicher befindet. Es können also keine
Sitzungsinformationen auf Klassen- oder Instanzenebene gespeichert und wiederhergestellt
werden. Die Zustandslosigkeit der Beans impliziert auch, daß bei der Instanziierung über die
create-Methode der Home Schnittstelle keine Parameterübergabe stattfinden darf.
Entity-Beans
Entity-Beans sind zustandsbehaftet und persistent, d.h. der Zustand der Sitzung wird dauerhaft
abgespeichert und kann – z.B. nach einem Neustart des Servers – wieder hergestellt werden. Eine
Entity-Bean wird normalerweise als Tupel einer Relation (bzw. als Objekt in einem OODBMS)
abgespeichert und hat demzufolge einen eindeutigen Primärschlüssel bzw. eine eindeutige ObjektID. Die Schnittstelle javax.ejb.EntityContext deklariert folgende Methoden, um den
Primärschlüssel zu setzen bzw. abzufragen:
public abstract Object getPrimaryKey();
public abstract void setPrimaryKey(Object primaryKey);
Codebeispiel III-18: Methodendeklaration zur Primärschlüssel-Abfrage
Es ist wichtig, sich klarzumachen, daß Entity-Beans nicht einfach Session-Beans sind, deren
Zustand dauerhaft abgespeichert wird, sondern ein anderes Modellierungskonzept beinhalten.
Entity-Beans bieten eine objektorientierte Sicht auf relationale Datenbanken und halten den
eigentlichen Datenbankzugriff (über JDBC) für den Entwickler transparent. Folgende Abbildung
soll dieses Konzept verdeutlichen:
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 5. EJB - Enterprise JavaBeans
69
Direkter Zugriff
auf eine Entity
Bean
EJB Server
EJB Container
Client
Entity Bean
(Instanz 1)
JDBC
Client startet eine
Sitzung
Entity Bean
(Instanz 2)
Session Bean
(Instanz 1)
Die Session Bean
benutzt Entity Beans,
um auf die Daten
zuzugreifen
Relation
Tupel 1
Tupel 2
...
Tupel n
Datenmanipulation
mit JDBC
Abbildung III-27: Verwendung von Entity-Beans
Entity-Beans werden eingesetzt, wenn bei der Entwicklung eine Trennung von Geschäftslogik und
JDBC-Code angestrebt wird. Session-Beans werden von einem Client instanziert und benutzen
Entity-Beans, um auf die Datenbank zuzugreifen. Natürlich kann der Client auch direkt auf EntityBeans zugreifen. EJB-Anwendungen werden allerdings zumeist so modelliert, daß Clients
ausschließlich über Session-Beans zugriff auf Entity-Beans haben.
5.7 Dienste
Persistenz
Entity-Beans dienen zur persistenten Speicherung von Informationen in Datenbanken. Sie
repräsentieren keine Geschäftsprozesse sondern Entitäten. Man unterscheidet bei der Persistenz
von Entity-Beans beanverwaltete und containerverwaltete Persistenz. Normalerweise wird man
sich aus Effizienz- und Zeitgründen für die containerverwaltete Persistenz entscheiden, sofern diese
Option vom Container-Hersteller angeboten wird.
Beanverwaltet (bean-managed)
Bei beanverwalteter Persistenz muß der Entwickler selbst Maßnahmen zur persistenten
Speicherung der Bean in der Datenbank ergreifen. Normalerweise geschieht dies mit der
Datenbank-API JDBC. Beanverwaltete Persistenz muß verwendet werden, wenn der Container
keine containerverwaltete Persistenz anbietet. Werden EJBs zum Zugriff auf LegacyAnwendungen verwendet, ist zumeist eine manuelle Programmierung der Persistenz nötig, da nur
wenige Container-Hersteller den Zugriff auf diese Systeme implementieren.
Containerverwaltet (container-managed)
Die containerverwaltete Persistenz spart viel Arbeit bei der Entwicklung, weil keine
Sicherungsmechanismen von Hand programmiert werden müssen. Ein Beispiel für einen EJB-
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 5. EJB - Enterprise JavaBeans
70
Containerhersteller, der containerverwaltete Persistenz verwendet, ist PowerTier von Persistence.
PowerTier implementiert ein Konzept, das unter dem Namen Object-to-relational persistence
bekannt ist [Monson-Haefel 99]. Dabei wird einer Entity-Bean ein Tupel einer relationalen
Datenbank zugeordnet. Die Variablen der Bean entsprechen dann den Attributen oder Spalten der
Tabelle. Ein anderes (und eleganteres) Konzept ist die Object database persistence, also die
Speicherung von Entity-Beans als Objekte in einer objektorientierten Datenbank.
Nebenläufigkeit
Nebenläufigkeit wird nur von Entity-Beans unterstützt. Bei Session-Beans ist dies nicht notwendig,
da
•
zustandsbehaftete Session-Beans ohnehin nur von einem bestimmten Client instanziert und
freigegeben werden und
•
zustandslose Session-Beans keine Zustandsvariablen haben, auf die mehrere Clients
zugreifen könnten.
Da bei Entity-Beans ein nebenläufiger Zugriff mehrerer Clients möglich ist, sind Mechanismen zur
Konsistenzsicherung notwendig. Deshalb sind Entity-Beans laut Spezifikation [Sun 99c]
wiedereintrittsinvariant.
Wiedereintrittsinvarianz von Entity-Beans
Normalerweise sind Entity-Beans wiedereintrittsinvariant. Das heißt, daß innerhalb eines
Transaktionskontextes nur eine Client-Anfrage bearbeitet wird. Wenn eine Entity-Bean ein Request
eines Clients bearbeitet und ein weiterer Client-Request im selben Transaktionskontext eintrifft,
wirft der EJB-Container eine java.rmi.RemoteException. Nähere Informationen zur
Wiedereintrittsinvarianz sind in der EJB-Spezifikation [Sun 99c] zu finden.
Transaktionen
Das EJB-Transaktionsmodell JTS ist eine Implementierung
Transaktionsmodells OTS (Object Transaction Service).
des
CORBA/OMG-
Einführung
Transaktionen sind prinzipiell als atomare Einheit zu sehen. Es können mehrere Operationen im
Kontext einer Transaktion ausgeführt werden. Diese Operationen werden im Rahmen einer
Transaktion entweder alle vollständig und fehlerfrei ausgeführt und entsprechend mit einem
commit-Befehl bestätigt oder bei Problemen mit dem rollback-Befehl rückgängig gemacht.
Eine gute Transaktionsverwaltung ist sehr aufwendig, besonders bei Operationen auf großen
Datenbanken mit einem nebenläufigen Zugriff mehrerer Clients. Je nach verwendeter
Sperrgranularität werden einzelne Tupel oder ganze Relationen für die Dauer der Transaktion
gesperrt, um Inkonsistenzen zu verhindern. Schwierig ist bei solchen Transaktionskonzepten
besonders der Mittelweg zwischen Sicherheit und Performanz.
Transaktionsverhalten
Das Transaktionsverhalten von Enterprise JavaBeans läßt sich über das Transaktions-Attribut des
Deployment-Descriptors einstellen. Es sind 6 Werte möglich:
•
TX_NOT_SUPPORTED
•
TX_SUPPORTS
•
TX_REQUIRED
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 5. EJB - Enterprise JavaBeans
•
TX_REQUIRES_NEW
•
TX_MANDATORY
•
TX_BEAN_MANAGED
71
Mit diesen Integerkonstanten kann einE EntwicklerIn nun für jede Methode in der EJB eine
bestimmte Transaktionsvariante festlegen. TX_NOT_SUPPORTED bedeutet natürlich, daß diese
Methode nicht im Kontext einer Transaktion laufen sollte. Mit TX_SUPPORTS wird angezeigt,
daß für die entsprechende Methode kein Transaktionkontext benötigt wird, daß der laufende
Thread sich aber in einem Transaktionskontext befinden kann. Wird TX_REQUIRED verwendet,
dann muß eine Transaktion laufen. Wenn der gerade aktuelle Thread im Kontext einer Transaktion
läuft, dann kann er in die Methode eintreten. Besitzt er keine laufende Transaktion, startet er eine
Transaktion. Ist für die auszuführende Methode TX_REQUIRES_NEW festgelegt, so muß der
aktive Thread eine neue Transaktion starten, auch wenn bereits eine vorhanden ist. Mit
TX_MANDATORY wird eine weitere Restriktion angezeigt: der aktive Thread muß bereits im
Besitz einer Transaktion sein wenn die Methode aufgerufen wird, da ansonsten eine Ausnahme
geworfen wird. TX_BEAN_MANAGED formuliert keine neuen Restriktionen, sondern sagt
lediglich aus, daß der Container sich nicht um die Transaktionsverwaltung für diese Methode
kümmern soll, da die Bean sich selbst darum kümmert. Eine Methode, die diese
Transaktionsvariante für sich festlegt, muß selbst eine neue Transaktion kreieren und zerstören,
wenn sie aufgerufen wird.
Java Transaction Service: JTS
Der Java Transaction Service (JTS) ist eigentlich kein eigener Transaktionsservice. Er ist lediglich
eine Schnittstelle zur Transaktionsverwaltung des EJB-Containers. Es soll hier nicht näher auf
Implementierungsdetails eingegangen werden, aber es ist klar, daß die Schnittstelle
(javax.jts.UserTransaction) unter anderem die Methoden begin, commit und rollback
bereitstellt. Bestandteil des Pakets sind auch einige spezielle Ausnahmen, die beim Aufruf dieser
Methoden abgefangen werden müssen.
Verteilte Objekte
Die bekanntestens Dienste für verteilte Objekte sind CORBA, RMI und DCOM. Die Enterprise
JavaBeans-Spezifikation verwendet der Einfachheit wegen Java's RMI (Remote Method
Invocation). Nähere Informationen zu RMI sind im RMI-Kapitel dieser Diplomarbeit zu finden.
Namensdienst
Als Namensdienst (z.B. zum Auffinden von EJBs) dient das Java Naming and Directory Interface
(JNDI). Dieser Dienst wird im Unterkapitel "Szenario eines EJB-Methodenaufrufes" näher
beschrieben.
Sicherheit
Bei EJBs müssen die Sicherheitsrichtlinien nicht im Sourcecode deklariert werden. Die
Sicherheitsrichtlinien werden vielmehr über entsprechende Tools der Container-Hersteller
deklariert. Dabei können laut Spezifikation verschiedenen Benutzergruppen Sicherheitsrollen, die
den Zugriff auf bestimmte Methoden regeln, zugeordnet werden.
Im O'Reilly-Buch "Enterprise JavaBeans" [Monson-Haefel 99] werden drei Arten von Sicherheit
unterschieden:
•
Authentifizierung (Validierung der Benutzeridentität)
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 5. EJB - Enterprise JavaBeans
72
•
Zugriffskontrolle (Sicherheitsrichtlinien, um den Zugriff bestimmter Benutzer zu
bestimmten Methoden einzuschränken)
•
Sichere Kommunikation (Sicherung des Kommunikationskanals zwischen Client und
Server, z.B. durch Verschlüsselung)
In der Version 1.0 der EJB-Spezifikation [Sun 99c] ist nur die Zugriffskontrolle durch die oben
beschriebenen Sicherheitsrollen geregelt. Allerdings bieten viele EJB-Server auch eine sichere
Kommunikation mit SSL (Secure Socket Layer) an.
Authentifizierung wird in der EJB-Spezifikation nicht näher beschrieben, ist allerdings indirekt
über JNDI (Java Naming and Directory Service) möglich.
5.8 Überblick über Klassen und Schnittstellen der EJB-API
Dieses Unterkapitel bezieht sich auf die Version 1.1 der EJB-Spezifikation [Sun 99c]. Einer der
Hauptunterschiede zwischen den Versionen 1.0 und 1.1 ist das Wegfallen des
javax.ejb.deployment-Paketes durch einen XML-basierten Deployment-Descriptor.
Überblick über die EJB-API
Das API der Enterprise JavaBeans besteht aus dem Paket javax.ejb Das Paket
javax.ejb.deployment wurde aus der Spezifikation entfernt, da mit der Version 1.1 ein XMLbasierter Deployment-Descriptor verwendet wird.
Das Paket javax.ejb besteht aus der Schnittelle EnterpriseBean und deren Subschnittstellen
(EntityBean, SessionBean), den entsprechenden Kontext-Schnittstellen (EntityContext,
SessionContext), den Interfaces EJBObject und EJBHome sowie mehreren Exceptions. Dabei
ist vor allem anzumerken, daß die EJBObject-Schnittstelle ein Subinterface von java.rmi.Remote
ist, was die enge Verknüpfung von Enterprise JavaBeans (EJB) mit der Remote Method Invocation
(RMI) deutlich macht.
<<interface>>
java.rmi.Remote
<<interface>>
java.ejb.EJBHome
<<interface>>
java.ejb.EJBObject
<<interface>>
MyHomeInterface
<<interface>>
MyRemoteInterface
HomeImplementation
<<interface>>
java.ejb.EJBMetaData
Remote Interface und Home
Interface müssen vom
Entwickler geschrieben
werden. Die Implementierung
wird von Tools generiert.
RemoteImplementation
Abbildung III-28: EJBObject, EJBHome, EJBMetaData
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 5. EJB - Enterprise JavaBeans
73
Bei der Entwicklung von Enterprise Beans müssen nun das Home Interface und das Remote
Interface geschrieben werden. Die Implementierung dieser Schnittstellen wird automatisch von
einem Tool generiert.
Es ist wichtig sich klarzumachen, daß die Schnittstelle MyRemoteInterface aus obiger Abbildung
zwar vom Container implementiert wird, daß aber diese Implementierung lediglich die
korrespondierenden Business-Methoden der Enterprise Bean aufruft.
Die folgende Abbildung zeigt die beiden verschiedenen Arten von Enterprise Beans: Entity-Beans
und Session-Beans. Jede dieser EJBs hat einen spezifischen Kontext, der durch die Schnittstellen
EntityContext und SessionContext, beides Subschnittstellen von EJBContext, repräsentiert
wird:
<<interface>>
java.io.Serializable
Implementierung
durch den Container
Implementierung
durch den Container
<<interface>>
java.ejb.EnterpriseBean
SessionContext
hasContext
<<interface>>
java.ejb.SessionBean
<<interface>>
java.ejb.EntityBean
MySessionBean
MyEntityBean
<<interface>>
java.ejb.SessionContext
<<interface>>
java.ejb.EJBContext
EntityContext
hasContext
<<interface>>
java.ejb.EntityContext
Abbildung III-29: EnterpriseBean und Subklassen
Mit den Schnittstellen EJBContext und den Subinterfaces SessionContext und EntityContext
kann auf den Kontext, den der EJB-Container der Instanz der Enterprise Bean zur Verfügung stellt,
bequem zugegriffen werden. Eine typische Methode, die in EJBContext definiert ist, ist
getEJBHome (Referenz auf die Implementierung des Home Interfaces).
SessionContext fügt lediglich die Methode getEJBObject hinzu, um eine Referenz auf das
EJBObject zu erhalten, welches mit der Instanz der Enterprise Bean assoziiert ist. Auch
EntityContext enthält eine getEJBObject-Methode, definiert aber zusätzlich noch
getPrimaryKey, da eine Entity-Bean Daten einer Datenbank repräsentiert.
5.9 Überblick über die Entwicklung von Enterprise
JavaBeans
Dieser Abschnitt soll lediglich einen knappen Überblick über die Programmierung von EJBs
geben;
Die Entwicklung läuft nun so ab:
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 5. EJB - Enterprise JavaBeans
74
•
Programmierung einer Enterprise Bean mit den Standard-Methoden (d.h. den Methoden die
aus der Schnittstelle SessionBean oder EntityBean implementiert werden müssen) und
der eigentlichen Geschäftslogik.
•
Programmierung des Home Interfaces als Subschnittstelle von EJBHome, mit dem die
entsprechenden Beans instanziert und zerstört werden können.
•
Programmierung des Remote Interfaces, in dem alle Methoden, welche ein Client aufrufen
kann, definiert sind. Die Implementierung dieser Schnittstelle wird vom Container
übernommen.
•
Compilierung der Klassen.
•
Schreiben des XML-basierten Deployment-Descriptors (wird in der Regel von einem Tool
des Server-Herstellers übernommen).
•
Generierung eines JAR-Files, das die oben beschriebenen Files enthält.
•
Installation des generierten JAR-Files im EJB-Server (Deployment). Die genaue
Vorgehensweise ist abhängig vom EJB-Server.
Das war der serverseitige Teil der Entwicklung. Nun muß ein Client programmiert werden, der die
Business-Methoden der Enterprise Bean aufruft.
5.10 Szenario eines EJB-Methodenaufrufs (bei
zustandsbehafteten Session-Beans)
Enterprise JavaBeans werden auf unterschiedliche Art und Weise instanziert und angesprochen.
Zustandslose Session-Beans beispielsweise, werden nicht vom Client instanziert sondern vom EJBContainer. Entity-Beans wiederum verhalten sich völlig anders wie beide Arten von Session-Beans.
In der EJB-Spezifikation [Sun 99c] und in Monson-Haefel's EJB-Buch [Monson-Haefel 99] sind
deshalb zahlreiche Zustands- und Sequenzdiagramme abgebildet, welche die unterschiedliche
Behandlung der verschiedenen Enterprise Beans deutlich machen. An dieser Stelle soll nur einmal
das Szenario eines Methodenaufrufs bei einer zustandsbehafteten Session-Bean vorgestellt werden.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 5. EJB - Enterprise JavaBeans
75
Folgendes Kollaborationsdiagramm gibt einen Überblick über einen typischen Methodenaufruf bei
zustandsbehafteten Session-Beans:
Factory
Pattern
EJB Container
Client
concreteProducer
concreteProduct
1. create()
:MyClient
:HomeImplementation
3. Class.
newInstance()
8. remove()
4. setSessionContext()
:MyEnterpriseBean
9. remove()
2. Class.
newInstance()
6. aBusinessMethod()
5. ejbCreate()
:RemoteImplementation
7. aBusinessMethod()
10. ejbRemove()
subject
proxy
Proxy
Pattern
Abbildung III-30: EJB-Methodenaufruf bei zustandsbehafteten Session-Beans
Man kann hier recht deutlich erkennen, daß ein Großteil der EJB-Komplexität vor dem Client
verborgen wird. Für den Aufruf einer EJB-Methode sind lediglich zwei Methodenaufrufe nötig; ein
Methodenaufruf zur Instanzierung und einer zum Aufruf der gewünschten Business-Methode.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 6. JDBC – Java Database Connectivity
76
6 JDBC
– Java Database
Connectivity
Errors using inadequate data are much less than those using no data at all.
Charles Babbage
In dieser Diplomarbeit geht es unter anderem um die Abfrage
relationaler Datenbanken. Da das zu implementierende Query-Tool datenbankunabhängig sein soll,
muß ein offener Standard verwendet werden, der von möglichst vielen Datenbankherstellern
unterstützt wird. JDBC (Java Database Connectivity) ist ein solcher Standard, der problemlosen
Zugriff auf die populärsten relationalen Datenbanken ermöglicht. Die breite Akzeptanz von JDBC
seitens der Industrie hat dazu geführt, daß nahezu jeder wichtige Datenbankhersteller JDBCTreiber in seine Produktpalette aufgenommen hat.
In den folgenden Unterkapiteln soll die grundlegende Funktionsweise dieser Technologie – auch
anhand von Code-Beispielen – erklärt werden.
6.1 Was ist JDBC?
JDBC ist ein datenbankunabhängiger Standard für den Zugriff auf relationale Datenbanksysteme
aus einem Java-Programm heraus. Das Akronym JDBC steht für Java Database Connectivity und
ist ein Paket aus Klassen und Schnittstellen, die der Programmierer in Java-Programmen
verwenden kann. Dieses Application Programming Interface (API) ist der de-facto Standard für
den Datenbankzugriff unter Java und wird von den meisten Datenbankherstellern unterstützt.
Embedded SQL (ESQL)
Embedded SQL (ESQL) ist ein internationaler Standard (ISO SQL-92), der die Einbettung von
SQL-Anweisungen in (imperative) Programmiersprachen regelt. Erfaßte Programmiersprachen
sind C, C++, COBOL, FORTRAN, PL/1, Pascal, MUMPS und Ada. Für Java existiert eine ESQLImplementierung namens SQLJ, die 1997 von Oracle, Tandem und IBM vorgestellt wurde.
SQLJ
SQLJ ist eine offene ESQL-Implementierung für Java. Mit SQLJ können SQL-Anweisungen in
Java-Programme eingebettet werden. Der entsprechende Java-Quellcode wird von einem Compiler
(bei Oracle sinngemäß sqlj genannt) vorübersetzt und in überprüfte, statische JDBC-Anweisungen
umgewandelt.
Warum sollte man SQLJ überhaupt verwenden? Nun, wenn in einem Java-Programm sehr
komplizierte und/oder umfangreiche SQL-Anweisungen verarbeitet werden, entsteht schnell ein
kaum noch überschaubarer Code, in dem sich auch nach der x-ten Überprüfung noch Fehler
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 6. JDBC – Java Database Connectivity
77
verstecken. Die eingebetteten SQL-Anweisungen sind viel einfacher zu lesen und werden vor allem
beim Compilieren auf Plausibilität überprüft.
SQLJ und JDBC ergänzen sich geradezu ideal: SQLJ ist für statische SQL-Anweisungen gedacht,
die bereits zum Übersetzungszeitpunkt bekannt sind und JDBC ist für dynamisches SQL besser
geeignet.
Natürlich gibt es auch Probleme:
•
Die Zieldatenbank muß zum Übersetzungszeitpunkt bekannt und verfügbar sein.
•
Üblicherweise sind (trotz gegenteiliger Versprechungen) die SQLJ-Präcompiler an eine
bestimmte Datenbank gebunden; d.h. daß das SQLJ-Programm für jeden Datenbankserver
neu compiliert werden muß
•
SQLJ unterstützt keine datenbankunabhängigen Metadaten
Da SQLJ noch eine relativ junge Technologie ist, bleibt abzuwarten, in welchem Umfang sich ein
wirklich offener Standard entwickelt.
6.2 JDBC/ODBC
JDBC ist ein portables Call Level Interface (CLI), das ähnlich wie ODBC aufgebaut ist. ODBC
(Version 3.0) ist ein prozedurales CLI für den Zugriff auf relationale Datenbanken. Trotz seiner
Microsoft-Herkunft hat sich ODBC zu einem weitgehend offenen Standard entwickelt und auch
außerhalb der Windows-Welt weite Verbreitung gefunden. Wozu sollte man also JDBC
verwenden? Das hat verschiedene Gründe, die hier im folgenden kurz aufgeführt werden.
Die Spezifikation wird von Microsoft geschrieben und ständig erweitert.
Das ist der vielleicht wichtigste Nachteil von ODBC: der ODBC-Standard wird vollkommen von
Microsoft kontrolliert. Wie in der Vergangenheit schon mehrfach geschehen, ist es möglich, daß
Microsoft aus dem weitgehend offenen ODBC mit SQL3-Unterstützung eine proprietäre
Erweiterung von OLE macht. Möglich ist auch ein vollständiger Ersatz des prozeduralen ODBC
durch das objektbasierte OLE/DB. Bei Microsoft als Firma ist – wie die Erfahrung zeigt – ein
gesundes Mißtrauen angebracht, gerade was proprietäre Erweiterungen betrifft.
ODBC ist prozedural
ODBC ist ein prozedurales API, was bei der Entwicklung von objektorientierter Software
problematisch ist; es werden z.B. Zeiger auf Strukturen statt Referenzen auf Objekte zur Verfügung
gestellt. Das bedeutet, daß es nicht möglich ist, die Vorteile des objektorientierten Paradigmas voll
auszuschöpfen.
ODBC erfordert nativen Code in der Anwendung
Damit ist ein Java-Programm nicht mehr plattformunabhängig und kann z.B. nicht mehr in Form
eines Applets aus dem Web geladen werden.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 6. JDBC – Java Database Connectivity
78
6.3 Warum JDBC verwenden?
Der Hauptgrund für die Verwendung von JDBC ist sicherlich der vom DBMS unabhängige Zugriff
auf relationale Datenbanken. Die Datenbank, auf die zugegriffen wird, ist also beliebig
austauschbar, zumindest wenn sie Standard-SQL verwendet. Ein JDBC-Treiber muß zumindest
ANSI SQL92 Entry Level-Funktionalität bieten, sozusagen als kleinster gemeinsamer Nenner.
6.4 JDBC-Treibertypen
Um die JDBC Schnittstellen zu implementieren, ist ein JDBC-Treiber nötig. Es gibt vier
verschiedene Treibertypen:
Typ 1: JDBC-ODBC-Bridge
Dieser Treiber ist eine JDBC-ODBC-Bridge, die es ermöglicht, über JDBC auf beliebige ODBCDatenbanken zuzugreifen. Vorteilhaft ist hier natürlich der bequeme Zugriff auf die weit
verbreiteten ODBC-Datenbanken.
Java-Applikation
JDBC API
CLIENT
JDBC-Treibermanager
JDBC Treiber API
JDBC-ODBCBridge
ODBCTreiber
ODBC
DATABASE
DBMS
Abbildung III-31: JDBC Typ 1-Treiber (JDBC-ODBC-Bridge)
Die Funktion dieser Bridge ist die Umsetzung von JDBC-Aufrufen in ODBC-Aufrufe. Da dieser
Treibertyp aus einem in Java geschriebenen JDBC-Teil und einem ODBC-Teil – zumeist in C
implementiert – besteht, ist er plattformabhängig.
Problematisch ist auch, daß der entsprechende ODBC-Treiber auf jedem Client-System installiert
und konfiguriert werden muß. Das führt auch dazu, daß solche Typ 1-Treiber auch nicht von JavaApplets in einem Browser zu gebrauchen sind, da Applets keinen nativen Code laden können.
Von daher kann dieser Treibertyp für eine portable Anwendung nur eine Übergangslösung
darstellen.
Typ 2: JDBC-native API-Bridge
Ein Typ 2-Treiber (ebenfalls eine Bridge) besteht aus einem datenbankabhängigen Treiber und
einer JDBC-Schicht. Der Treiber konvertiert – wie auch schon bei der JDBC-ODBC-Bridge –
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 6. JDBC – Java Database Connectivity
79
JDBC-Aufrufe in Aufrufe für die API der Datenbank (z.B. Oracle, Informix, ...). Auch hier wird
nativer, clientseitiger Code benötigt, der von Applets nicht geladen werden kann.
Java-Applikation
JDBC API
JDBC-Treibermanager
JDBC Treiber API
CLIENT
JDBC-Treiber
für DBMS A
(Java)
Treiber für
DBMS A
(nativ)
Protokoll der Datenbank
DBMS
DATABASE
Abbildung III-32: JDBC Typ 2-Treiber (JDBC-native API-Bridge)
Typ 3: Nativer Protokolltreiber (100% Java)
Dieser Treibertyp ist in 100% Java implementiert und verwendet zum Datenbankzugriff das
Netzwerkprotokoll der Datenbank. Der Treiber besteht aus einem JDBC-Client und einem JDBCServer, wobei JDBC-Aufrufe in ein natives (datenbankabhängiges) Netzwerkprotokoll konvertiert
werden und zur Datenbank übertragen werden.
Java-Applet/Applikation
JDBC API
CLIENT
JDBC-Treibermanager
JDBC Treiber API
Nativer
Protokolltreiber
Protokoll der Datenbank
DATABASE
DBMS A
Abbildung III-33: JDBC Typ 3-Treiber (Nativer Protokolltreiber)
Hauptvorteil dieses Treibers ist, daß keine zusätzliche Client-Software vorhanden sein muß. Die
Datenbank muß allerdings auf demselben Rechner wie der Webserver (von dem das Applet
geladen wurde) liegen. Ein Typ 3-Treiber ist eine gute Lösung für ein Intranet, um über JavaApplets direkt auf eine Datenbank zuzugreifen.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 6. JDBC – Java Database Connectivity
80
Typ 4: Netzwerktreiber (100% Java)
Auch dieser Treiber besteht zu 100% aus Java und ist komplett in den Client integriert. Hier wird
die Verbindung zum Server über Java's Standard-Protokolle aufgebaut. Die MiddlewareKomponente übersetzt die Befehle in das Netzwerkprotokoll der Datenbank.
Java-Applet/Applikation
JDBC API
JDBC-Treibermanager
CLIENT
JDBC Treiber API
Netzwerktreiber
RMI
Middleware
SERVER
Netzwerkprotokoll der DB
DATABASE
DBMS A
DBMS B
DBMS C
Abbildung III-34: JDBC Typ 4-Treiber (Netzwerktreiber)
Der Unterschied zum Typ 3-Treiber ist, daß hier nicht direkt auf die Datenbank zugegriffen werden
kann, sondern eine Middleware benötigt wird (3-Tier-Architektur). Die Datenbank muß sich dabei
nicht auf dem Middleware-Rechner befinden.
6.5 Überblick über die wichtigsten Klassen und
Schnittstellen der JDBC-API
Die wichtigsten Schnittstellen und Klassen sind DriverManager, Connection, Statement und
ResultSet. Interessant sind auch zwei Unterklassen von Statement: PreparedStatement und
CallableStatement. Für die Abfrage von Metadaten ist die Schnittstelle ResultSetMetaData
wichtig. Alle genannten Schnittstellen sind dem Namensraum java.sql.* zugeordnet. Die Klasse
XXXDriver repräsentiert einen datenbankspezifischen Treiber, ist also kein Bestandteil der JDBCAPI.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 6. JDBC – Java Database Connectivity
Es müssen natürlich auch
noch die StatementUnterklassen vom
XXXDriver implementiert
werden
81
<<interface>>
DatabaseMetaData
<<interface>>
Driver
XXXDriver
load Driver
<<interface>>
ResultSet
executeQuery
getMoreResults
<<interface>>
Statement
DriverManager
createStatement
getConnection
executeQuery
getXXX
<<interface>>
PreparedStatement
prepareStatement
<<interface>>
Connection
setXXX
prepareCall
Data types: Date,
Time, DateStamp, ...
<<interface>>
CallableStatement
Abbildung III-35: JDBC-API
In den folgenden Abschnitten wird die Funktion der abgebildeten Klassen und Schnittstellen näher
erklärt.
DriverManager
Mit dem DriverManager werden Treiber-Klassen geladen und Datenbankverbindungen aufgebaut.
Driver
Die Driver-Schnittstelle muß von jedem JDBC-Treiber implementiert werden und deklariert
entsprechende Standard-Methoden.
XXXDriver
Datenbankspezifischer Treiber, welcher die eigentliche Funktionalität implementiert. Ein solcher
JDBC-Treiber (z.B. OracleDriver) wird für eine bestimmte Datenbank geschrieben und
implementiert zumindest die Schnittstellen Driver, ResultSetMetaData und DatabaseMetaData
vollständig. Es müssen auch die Interfaces ResultSet, Statement, PreparedStatement,
CallableStatement und Connection implementiert werden – allerdings nicht unbedingt
vollständig, da hier einige optionale Methoden deklariert sind. Für Informationen zu TreiberDetails ist [Sun 99e] empfehlenswert. In diesem Dokument für Treiber-EntwicklerInnen sind die zu
implementierenden Schnittstellen und Methoden sehr ausführlich beschrieben.
Connection
Die Connection-Schnittstelle repräsentiert eine Verbindung zu einer bestimmten Datenbank.
Statement
Ein Statement-Interface dient dazu, statische SQL-Befehle auszuführen. Voraussetzung ist das
Vorhandensein einer Datenbank-Verbindung (repräsentiert durch Connection).
PreparedStatement
Das PreparedStatement wird zur Ausführung von vorübersetzten SQL-Befehlen verwendet.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 6. JDBC – Java Database Connectivity
82
CallableStatement
Mit dem CallableStatement können Stored Procedures der Datenbank ausgeführt werden.
ResultSet
Das ResultSet repräsentiert die Ergebnismenge eines SQL-Befehls (Statement). Das ResultSet
ist Tupel-basiert, speichert also Ergebniszeilen ab.
ResultSetMetaData
Über ResultSetMetaData kann auf Datenbank-Metadaten zugegriffen werden.
6.6 Programmieren mit JDBC
Die Programmierung von kleineren JDBC-Anwendungen ist relativ unkompliziert. Allerdings
existieren eine Vielzahl von komplexen, erweiterten Features, die für kleinere Anwendungen nicht
benötigt werden, mit denen man sich aber bei größeren Datenbank-Anwendungen vertraut machen
sollte. Im folgenden wird lediglich beschrieben, wie eine Verbindung zu einer Datenbank
aufgebaut wird und wie SQL-Kommandos gegen die Datenbank geschickt werden.
Laden des Treibers
Da Java in der Lage ist, zur Laufzeit dynamisch Klassen nachzuladen, ist das Laden des Treibers
einfach, zumindest wenn man einen solchen besitzt und auch im richtigen Verzeichnis installiert
hat. Um den Thin-Treiber (Typ 4) von Oracle zu laden ist folgender Code nötig:
Class.forName("jdbc:oracle:thin");
Die Syntax ist dabei stets jdbc:<subprotocol>:<subname>. Gewöhnlich wird der zu benutzende
Klassenname in der Dokumentation des Herstellers erwähnt. Normalerweise wird nach dem Laden
des Treibers die Klasse Driver instanziert, die sich mit DriverManager.registerDriver(driver)
beim Treibermanager registriert. In Einzelfällen muß die Registrierung von Hand vorgenommen
werden:
DriverManager.registerDriver(new oracle.jdbc.driver.OracleDriver());
Codebeispiel III-19: Laden eines JDBC-Treibers
Jetzt ist es möglich, eine Verbindung zum DBMS aufzubauen.6
Verbindungsaufbau zur Datenbank
Der zweite Schritt ist der Aufbau der Verbindung zur Datenbank (bzw. zur entsprechenden
Middleware). Dazu muß man den URL (uniform resource locator) des betreffenden Rechners
wissen. Nun kann die Verbindung aufgebaut werden.
url="jdbc:oracle:thin:@d1sun137:5521:soll"
Connection conn=DriverManager.getConnection(url, login, password);
Codebeispiel III-20: Verbindungsaufbau zur Datenbank mit JDBC
6
Es ist möglich, mehrere (Typ 3-)Treiber für verschiedene Datenbanken parallel beim Treibermanager zu
registrieren und damit verschiedene Datenbanken zu verwalten. Benutzt man eine Middleware, so muß nur
ein JDBC-Treiber geladen werden. Die Middleware ist dann in der Lage, verschiedene Datenbanken
gleichzeitig anzusprechen.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 6. JDBC – Java Database Connectivity
83
Wenn einer der registrierten Treiber den URL kennt, baut dieser Treiber die Verbindung zum
DBMS auf.
Anfragen gegen die Datenbank
Über die nun bestehende Verbindung zur Datenbank können Anfragen gegen die Datenbank
gestellt werden. Dazu wird ein Statement-Objekt erzeugt, das die entsprechende SQL-Anfrage
enthält. Anschließend muß die gewünschte Anfrage ausgeführt werden. Das Ergebnis wird von
JDBC über ein ResultSet-Objekt zurückgegeben. Auf dieses ResultSet (hier: rs) kann nun mit
rs.getXXX zugegriffen werden (kann nahezu jeder Java-Datentyp sein). Zum jeweils nächsten
Datensatz kann mit rs.next gesprungen werden.
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select name, price from coffee");
Codebeispiel III-21: Erzeugung von Statement und ResultSet
Das Auslesen der Anfrageergebnisse kann also z.B. so erfolgen:
while(rs.next()) {
String name = rs.getString("Bezeichnung");
float price = rs.getFloat("Preis für 1 kg");
System.out.println(name, " ", price);
}
Codebeispiel III-22: Auslesen der Anfrageergebnisse
Es muß also das ResultSet Tupel für Tupel durchgegangen und der entsprechende Attributwert
ausgelesen werden. Die Methode next bewegt den sogenannten Cursor in die nächste Zeile.
Normalerweise werden die offenen Verbindungen danach geschlossen:
rs.close();
conn.close();
Codebeispiel III-23: Datenbankzugriff mit JDBC
Abschließend ist noch zu sagen, daß die SQL-Datentypen nicht immer mit den Java-Datentypen
übereinstimmen. Im Anhang habe ich deshalb eine Tabelle beigefügt, die die Zuordnung der
entsprechenden Datentypen zeigt.7
Seit der Version 2.0 des JDBC API ist es möglich, den Cursor rückwärts oder zu bestimmten
Positionen im ResultSet zu bewegen, und zwar sowohl relativ als auch absolut.
Sequenzdiagramm einer typischen Anfrage gegen die Datenbank
Dieses Sequenzdiagramm zeigt den zeitlichen Ablauf des weiter oben beschriebenen Programms.
Die durchgezogenen Pfeile symbolisieren dabei Funktionsaufrufe (die leeren Klammern sind nur
Kosmetik, hier werden natürlich diverse Parameter übergeben), die gestrichelten Pfeile sind
Rückgabewerte.
7
Nach der Initialisierung befindet sich der Cursor über der ersten Zeile; d.h., daß mit dem ersten next-Aufruf
zum ersten Tupel der Rückgabemenge gesprungen wird. Ist das letzte Tupel erreicht, gibt next den Wert false
zurück.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 6. JDBC – Java Database Connectivity
:Client
:DriverManager
84
conn:Connection
stmt:Statement
rs:ResultSet
registerDriver()
getConnection()
conn
createStatement()
stmt
executeQuery()
rs
*next()
*getString()
name
*getFloat()
price
close()
close()
Abbildung III-36: Sequenzdiagramm einer SQL-Anfrage
6.7 Transaktionen und Stored Procedures
JDBC Transaktionen
Nach dem Verbindungsaufbau zur Datenbank ist der Transaktionsstatus automatisch im
autocommit-Modus. Das heißt, daß nach der Ausführung eines Statements automatisch die
Änderungen durch ein commit festgeschrieben werden. Um innerhalb einer Transaktion mehrere
Statements auszuführen, muß also das autocommit abgeschalten und von Hand ein commit/rollback
durchgeführt werden.
Stored Procedures
Mit JDBC können natürlich auch gespeicherte Prozeduren aufgerufen werden. Problematisch ist
natürlich, daß diese stored procedures oft datenbankspezifisch sind und deshalb im Rahmen dieser
Diplomarbeit nicht verwendet werden.
6.8 Metadaten
Es kann schwierig sein, im Rahmen eines datenbankunabhängigen Web-Informationssystems
Informationen über die Datenbank selbst zu erhalten. Es existiert kein SQL-Standard, um z.B. den
Namen einer Tabelle zu ermitteln. Die Informationen über die Relationen und deren Attribute sind
meist in speziellen Tabellen abgespeichert, deren Namen sich von DBMS zu DBMS zum Teil stark
unterscheiden. Die folgende Abbildung bezieht sich auf die Oracle-Datenbank. Die Daten auf der
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 6. JDBC – Java Database Connectivity
85
linken Seite sind die Tabellen eines bestimmten Benutzers, die Metadaten auf der rechten Seite
verwendet Oracle, um z.B. Benutzerdaten zu verwalten.
DATEN
METADATEN
(User: baier)
COFFEES
USER
COF_NAME SUP_ID PRICE SALES TOTAL
---------------------------------...
USER# NAME
TYPE PASSWORD
...
---------------------------------0
sys
1
skdajfiuasd
1
public 0
isnull=true
...
15
baier 1
jfskfjsklkd
CHARTDATA
ALL_CATALOG
PRODUCT_NAME TURNOVER_JANUARY ...
---------------------------------...
OWNER TABLE_NAME
TABLE_TYPE
---------------------------------baier coffees
table
baier testtable
table
...
sys
table_privileges
view
...
Abbildung III-37: Metadaten einer Datenbank
Zum Glück bietet JDBC die Möglichkeit, derartige Metadaten einfach und bequem zu erhalten. Es
existiert ein Interface DatabaseMetaData, welches 133 (!) Methoden deklariert. Der JDBCTreiberhersteller muß also eine Klasse schreiben, die alle diese Methoden implementiert. Ist diese
Klasse vorhanden, so läßt sich einfach ein Objekt dieser Klasse instanzieren und die gewünschte
Methode aufrufen:
String url = "jdbc:oracle:thin:@d1sun137:5521:soll";
Connection conn = DriverManager.getConnection (url, login, password);
DatebaseMetaData metadata = conn.getMetaData();
String version = metadata.getDatabaseProductVersion();
Codebeispiel III-24: Metadaten-Abfrage mit JDBC
Das ist natürlich nicht immer so einfach wie hier. Die Methode getTables gibt zum Beispiel die
Namen von sämtlichen gespeicherten Tabellen aus; das heißt, daß diese Daten mit dem zuvor
bereits besprochenen ResultSet Zeile für Zeile ausgelesen werden müssen.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil III: 6. JDBC – Java Database Connectivity
86
Interessant sind auch die Methoden der Schnittstelle ResultSetMetaData. Diese Schnittstelle
ermöglicht es, auf ResultSet-spezifische Ergebnisse zuzugreifen. Beispiele für Methoden dieser
Klasse sind:
•
getColumnCount (wie viele Rückgabespalten gibt es)
•
getColumnName(n) (wie ist der Name der n-ten Spalte)
•
getTables(...) (Zugriff auf Tabellen, z.B. eines bestimmten Benutzers)
Problematisch ist leider, daß man sich nicht immer darauf verlassen kann, daß auch wirklich alle
Methoden vom Treiber implementiert sind. Im Zweifelsfall sollte man sich die TreiberDokumentation genau ansehen und auf zu spezielle Methoden verzichten. Auf Sun's JDBCWebsite findet man nähere Informationen darüber, welche Methoden unbedingt und welche nur
optional vom Treiber zu implementieren sind.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil IV: 1. Analyse der Anforderungen
87
Anforderungsanalyse
und Systemspezifikation
Teil IV:
1 Analyse
der Anforderungen
Hier folgt nun nochmals eine kurze Liste mit den Anforderungen, die vom Prototypen des QueryTools zu implementieren sind.
#
Requirement-Bezeichnung
A1
Eingabeschnittstelle für die Formulierung von Datenbank-Queries (Client)
A2
Umsetzung der Eingabe in XML und Transport zum Server (Client)
A3
Auswertung der XML-Queries und Ausführung über JDBC (Server)
A4
Umsetzung der Anfrageergebnisse nach XML mit serverseitiger Java-Technologie und
Transport zum Client (Server)
A5
Visualisierung sowohl textueller als auch grafischer Information auf der Basis des
übermittelten XML-Dokumentes mit JavaBeans (Client)
A6
Konfigurierbarkeit der Ausgabeschnittstelle (Client)
Tabelle IV-1: Analyse der Anforderungen
A1: Eingabeschnittstelle (Client)
Die Eingabeschnittstelle für die Datenbank-Queries soll leicht und intuitiv zu bedienen sein. Wenn
sich ein Benutzer bei der Datenbank angemeldet hat, dann sollte das Query-Tool Informationen
über die vorhandenen Tabellen des Benutzers am Bildschirm darstellen (dazu werden JDBCMetadaten verwendet). Aus diesen Tabellen kann eine Tabelle ausgewählt werden, worauf die
entsprechenden Spaltennamen angezeigt werden. Es können nun die verschiedenen Spalten
angeklickt werden (z.B. mit Checkboxes), worauf die eigentliche Datenbankanfrage startet.
A2: Umsetzung der Eingabe in XML und Transport zum Server (Client)
Die Eingabe des Benutzers wird nun nach XML umgesetzt und als Argument übergeben.
A3: Auswertung der Argumente und Ausführung der Queries (Server)
Die Anfragen, welche über die Eingabeschnittstelle (A1) eingegeben und über A2 an den Server
übergeben werden, sollen nun auch ausgeführt werden. Dazu wird natürlich JDBC verwendet.
A4: Umsetzung der Anfrageergebnisse in XML (Server)
In einer relationalen Datenbank werden die Ergebnisse als Tabellen zurückgegeben. Aus einem
solchen Ergebnis soll nun ein gültiges XML-Dokument generiert werden, damit die Daten von
entsprechenden XML-fähigen Komponenten eingelesen werden können.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil IV: 1. Analyse der Anforderungen
88
A5: Visualisierung der Abfrageergebnisse (Client)
Die Abfrageergebnisse sollen nun nicht nur als XML-Dokument auf dem Bildschirm erscheinen,
sondern mittels JavaBeans angezeigt werden. Denkbar ist beispielsweise eine Bean, welche das
XML-Dokument als Tabelle anzeigt. Weitaus interessanter ist es natürlich, ein solches XMLDokument grafisch darzustellen, z.B. als Balken- oder Tortendiagramm, oder sogar mit einer
anwendungsdefinierten Grafik.
A6: Konfigurierbarkeit der Ausgabeschnittstelle (Client)
In A5 wurde bereits die Visualisierung der Abfrageergebnisse mit JavaBeans beschrieben. Die
Beans sollten nun den Bedürfnissen des Benutzers angepaßt werden (können). Das JavaBeans
Komponentenmodell bietet hierfür spezielle Mechanismen (vgl. das Kapitel über JavaBeans), die
eine individuelle Konfiguration ermöglichen.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil IV: 2. Analyse der Webarchitekturen
2 Analyse
89
der Webarchitekturen
Dieses Kapitel rekapituliert die Ergebnisse der Untersuchungen verschiedener Architekturen (EJB,
JSP, Servlets, ..) und versucht Vor- und Nachteile aufzuzeigen. Es geht dabei nicht um eine
prinzipielle Bewertung der einzelnen Architekturen sondern lediglich um die Eignung für den
Prototypen des Query-Tools.
2.1 Systemanforderungen
In Teil II dieser Diplomarbeit wurden verschiedene Architekturen für ein Web-Informationssystem
vorgestellt und beschrieben. Web-Informationssysteme entstehen jedoch nicht "auf der grünen
Wiese", sondern müssen sich in bestehende Strukturen einfügen. In der folgenden Tabelle werden
die Systemanforderungen kurz aufgezählt.
#
Komponente
Systemanforderung
SA1
Entwicklungsplattform
Windows NT 4.0 (Service Pack 3)
SA2
Entwicklungsumgebung
JDeveloper 2.0 mit Java 1.1.7
SA3
Applikationsserver
Oracle Application Server (OAS) 4.0.7
SA4
Datenbank
Oracle 7.3.4
Tabelle IV-2: Systemanforderungen
Diese Anforderungen führen natürlich zu bestimmten Beschränkungen. So ist z.B. der OAS in der
Version 4.0.7 nicht vollständig EJB-konform.
2.2 Java Server Pages (JSP) und EJBs (3- bzw. logische
4-Tier-Architektur)
Java Server Pages (JSP) sind eine Spezifikation von Sun (eine Erweiterung der Servlet-API), die
als Antwort zu Microsoft's Active Server Pages (ASP) gedacht ist. JSP funktionieren wie ASP: auf
einem Server sind verschiedene HTML-Seiten (auch XML ist möglich) abgelegt, deren relevanter
Inhalt dynamisch aus Datenbank-Anfragen generiert wird. Bei komplexerer Business Logic ist eine
Einbindung von Enterprise JavaBeans möglich. Die über JSP generierte HTML-Seite wird über das
Netz übertragen und in einem Browser angezeigt.
EJB Server
JSP Server
JSP Directory
WebBrowser
HTTP
EJB Container
RMI
JDBC
EJB
EJB
DB
EJB
Abbildung IV-1: Java Server Pages und Enterprise JavaBeans
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil IV: 2. Analyse der Webarchitekturen
90
Dieser Ansatz ist leider für ein Query-Tool, wie es in dieser Arbeit beschrieben wird, nur
eingeschränkt geeignet. Erstens kann man hier nicht von einer Komponentenarchitektur sprechen
(EJBs auf Serverseite sind möglich, aber keine clientseitigen JavaBeans). Zweitens ist die
Verwendung von XML problematisch, da auch der bislang einzige XML-fähige Browser (Internet
Explorer 5.0) gewisse Einschränkungen hat (z.B. bei Verwendung von XSL). Und drittens läßt sich
die Ausgabeschnittstelle nicht konfigurieren (XML-Files werden angezeigt; die Daten können
jedoch nicht benutzerdefiniert visualisiert werden, z.B. als Diagramm).
Vorteilhaft ist jedoch die Möglichkeit der Einbindung von Enterprise JavaBeans. So kann man die
Java Server Pages quasi als Frontend für die Enterprise Beans verwenden, was gerade dann
praktisch ist, wenn zwar umfangreiche und komplexe Business Logic vorhanden ist, die
Abfrageergebnisse jedoch nur in einem Web-Browser in Form von HTML/XML-Dokumenten
angezeigt werden sollen.
Vorteile
•
einfache Handhabung, schnelle Ergebnisse
•
optimale Lösung bei einer reinen XML-Ausgabe im Web-Browser
•
JSP als elegantes Frontend zu Enterprise JavaBeans
•
Client/Server-Kommunikation über HTTP
•
kein Java-Code (Ladezeiten) auf der Clientseite
Nachteile
•
Für ein Query-Tool nur eingeschränkt geeignet
•
Clientseitige Konfigurierbarkeit ist nicht möglich
•
Keine direkte Auswertung der Daten (also externe Analysetools notwendig)
•
Erhöhung der Komplexität
•
Keine durchgängige Komponentenarchitektur
•
Anzeige von XML im Web-Browser nur eingeschränkt möglich
•
bei Verwendung von HTML Weiterverarbeitung der Informationen problematisch
Fazit
Für das Query-Tool dieser Diplomarbeit sind JSP nicht besonders geeignet. Die Verwendung von
JSP als EJB-Frontend ist zwar eine sehr praktische Lösung für viele Anwendungen, aber die
Aufbereitung der XML-Daten muß dann von externen Applikationen vorgenommen werden.
Außerdem liegt der Sinn eines Query-Tools ja gerade darin, bequem Datenbankanfragen
"zusammenzuklicken" und das Ergebnis der Anfrage individuell und problembezogen ausgewertet
zu bekommen.
2.3 Enterprise JavaBeans (3-Tier-Architektur)
Dies ist eine typische 3-Tier-Architektur mit den Enterprise Beans als Middletier. Der Client kann
dabei entweder eine Java-Applikation oder ein Java-Applet sein.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil IV: 2. Analyse der Webarchitekturen
91
EJB Server
EJB Container
RMI
Client
JDBC
DB
EJB
EJB
EJB
Abbildung IV-2: 3-Tier-Architektur mit Enterprise JavaBeans
Will man Enterprise JavaBeans einsetzen, benötigt man einen EJB-Server, in dessen Container die
Beans installiert werden. Viele EJB-Server sind Erweiterungen bestehender Applikationsserver.
Ein Beispiel hierfür ist Oracle's Applikationsserver. Dieser Server bietet zahlreiche Möglichkeiten,
serverseitige Anwendungen zu entwickeln und auszuführen. Das hat natürlich seinen Preis – die
Lizenzgebühren sind hier sehr hoch. Alternativ gibt es freie EJB-Server (EJBHome, XS), die zum
Teil sogar im Sourcecode vorliegen (ejboss). Stabilität und Zuverlässigkeit lassen hier allerdings zu
wünschen übrig. Folgende Tabelle gibt einen Überblick über einen Teil der verfügbaren EJBServer:
Hersteller
Name
kostenlos
erhältlich
Sourcecode
verfügbar
reiner EJBServer (nur
EJBs
möglich)
Stabilität
und
Zuverlässi
gkeit
Unterstützung
Javader
EJB Version
Spezifikation (1.0)
Oracle
OAS 4.0.7
nein
nein
nein
hoch
teilweise
1.1.6
Persistence
PowerTier 5
nein
nein
ja
hoch
vollständig
2
BEA
WebLogic
Server 4.0
nein
nein
nein
hoch
vollständig
2
Iona
EJBHome
0.5.1
ja
nein
ja
mittel
vollständig
2
ejboss.org
ejboss 0.5
ja
nein
ja
mittel
vollständig
2
Tabelle IV-3: Verfügbare EJB-Server
Die prinzipiellen Unterschiede dieser EJB-Server liegen in der Unterstützung der EJBSpezifikation, der Java-Version und dem Preis. Preislich gibt es zwar große Unterschiede zwischen
den kommerziellen Servern, aber eines trifft auf alle kommerziellen EJB-Server zu: sie sind nicht
billig. Die kostenlosen EJB-Server sind oft relativ stabil und bieten eine erstaunlich vollständige
Unterstützung der Spezifikation. Leider sind alle freien Server noch in einem relativ frühen
Entwicklungsstadium, d.h. es kann problematisch sein, diese Server als Basis für ein kommerzielles
Produkt zu nehmen.
In den beiden folgenden Abschnitten werden nur die konzeptuellen Nachteile bei der Verwendung
von Enterprise Beans aufgezählt, d.h. Stabilität und Spezifikationsunterstützung soll hier kein KOKriterium sein.
Vorteile der EJB-Architektur
•
Komponentenbasierte Softwareentwicklung
•
Plattform- und serverunabhängige Komponentenarchitektur
•
Hohe Skalierbarkeit
•
Technologievorsprung (Enterprise Beans als Schlagwort)
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil IV: 2. Analyse der Webarchitekturen
92
Nachteile der EJB-Architektur
•
Theorie und Praxis der Portierbarkeit auf andere Server und Plattformen
•
Hohe Lizenzkosten für EJB-Server bzw. ungenügende Stabilität der freien Server
•
Die Vorteile der EJB-Architektur (z.B. Transaktionen) werden bei einem einfachen QueryTool nicht ausgenutzt
•
Paradigmen und Entwurfsmuster für EJBs sind noch nicht gut verstanden
•
Designfehler führen zu einer hohen Serverbelastung
Fazit
Für die vorliegende Diplomarbeit sind Enterprise Beans ein interessanter Ansatz. Es stellt sich
allerdings die Frage, ob die Komplexität bei der Bean-Entwicklung und insbesondere die
Lizenzkosten für die EJB-Server für ein einfaches Query-Tool angemessen sind. Andererseits sind
Komponentenarchitekturen heutzutage ein modernes Schlagwort und ein vollständig
komponentenorientiertes Modell (EJBs und JavaBeans) läßt sich besser vermarkten, da man so
einen Technologievorsprung für sich in Anspruch nehmen kann. Eine Weiterentwicklung des
Prototyps läßt sich mit EJBs einfacher gestalten und ein (weitgehend) unproblematischer Wechsel
zu einem anderen (günstigeren, stabileren, ...) Applikationsserver erlaubt eine Integration des
Query-Tools in bestehende Web-Infrastrukturen. Eine Firma, die ohnehin Lizenzkosten für einen
Applikationsserver zahlt, kann die EJBs bequem einbinden und profitiert dann von den Vorteilen
der EJB-Architektur.
2.4 Java-Applikation (3-Tier-Architektur)
Diese Lösung unterscheidet sich deutlich von den anderen Lösungen in diesem Kapitel. Der
Hauptunterschied ist, daß hier auf der Serverseite kein Applikationsserver verwendet wird. Größter
Vorteil ist natürlich die Einsparung der Lizengebühren für einen Server. Der Client kann sowohl
als Java-Applet oder als Java-Applikation entwickelt werden.
Client
RMI
JDBC
ServerApplikation
DB
Abbildung IV-3: 3-Tier-Architektur mit Enterprise JavaBeans
Auf der Serverseite steht eine sehr komplexe Anwendung, die schwieriger zu warten ist als z.B.
eine Lösung mit Enterprise JavaBeans. Sollen Änderungen und Erweiterungen vorgenommen
werden, ist dies mit einem relativ großen Aufwand verbunden. Die Architektur dieses Systems hat
einen weiteren Schwachpunkt: für das Internet ist sie weniger geeignet. Neben allgemeinen
Sicherheitsbedenken im Internet ist auch eine reine Intranetlösung unter Umständen problematisch.
Wenn sehr viele Datenbankanfragen gestellt werden, leidet die Performanz erheblich. Bei EJBs
kümmert sich der Server um eine möglichst hohe Leistung; z.B. entscheidet er, wieviele Instanzen
einer zustandslosen Session-Bean nötig sind, um die aktuelle Zahl der Client-Anfragen zu
bearbeiten.
Die Server-Applikation müßte für realistische Anwendungen (z.B. in einem Firmennetzwerk mit
zahlreichen Datenbankanfragen) im Hinblick auf eine möglichst gute Skalierbarkeit entwickelt
werden. Hilfreich sind dabei sicherlich die Multithreading-Fähigkeiten von Java.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil IV: 2. Analyse der Webarchitekturen
93
Vorteile
•
Keine Kosten für einen Webserver
•
Unproblematische Installation
Nachteile
•
höhere Komplexität
•
geringere Performanz
•
schlechte Skalierbarkeit
Fazit
Diese Architektur erscheint für den Prototypen des Query-Tools am besten geeignet. Es muß
jedoch angemerkt werden, daß in einer prototypischen Implementierung Sicherheits- und
Skalierbarkeitsaspekte in den Hintergrund treten. Bei einer professionellen Weiterentwicklung des
Prototypen ist die Einbettung in eine Architektur mit integrierter Skalierbarkeit (z.B. Enterprise
JavaBeans) ratsam.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil IV: 3. Analyse existierender Benutzeroberflächen
94
3 Analyse
existierender
Benutzeroberflächen
In diesem Kapitel werden die Benutzeroberflächen von drei kommerziellen Programmen mit Query
& Report-Funktionalität untersucht. Anzumerken ist, daß diese Softwarepakete einen sehr großen
Funktionsumfang bieten und die Query & Report-Funktionalität oft nur ein zusätzliches Feature
darstellt. Es geht in dieser Analyse jedoch lediglich um die Visualisierung von Tabellen und Views,
um die Generierung von Datenbankanfragen und um die Weiterverarbeitung der
Anfrageergebnisse.
Diese Untersuchung findet vor dem Hintergrund einer Realisierung mit den Swing-Klassen von
Java statt, mit denen sich beliebige professionelle GUIs problemlos programmieren (oder visuell
zusammensetzen) lassen.
3.1 Web-basiert: Oracle WebDB
WebDB ist ein Tool für die Administration von Oracle-Datenbanken über das Internet. Die
Oberfläche ist dementsprechend HTML-basiert und bietet so ein einheitliches Look & Feel. Auf
Java-Applets wurde verzichtet. Zur Bedienung von WebDB muß lediglich eine Web-Adresse
eingegeben werden. Nach der Benutzername/Paßwort-Verifikation ist eine bequeme
Administration und/oder Benutzung der entsprechenden Datenbank möglich. Folgende Abbildung
zeigt sämtliche Tabellen des Users BAIER.
Abbildung IV-4: Oracle WebDB: Anzeige der Tabellen des Benutzers BAIER
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil IV: 3. Analyse existierender Benutzeroberflächen
95
Die Toolbar am unteren Rand der HTML-Seite bietet neben Funktionen zur Administration einer
Oracle-Datenbank auch die Möglichkeit, Reports und Charts zu erstellen.
Für schnelle Datenbankanfragen gibt es ein spezielles Formular:
Abbildung IV-5: Oracle WebDB: Formular für DB-Anfragen
WebDB bietet auch umfangreiche Query- und Reportfunktionen an. Bei der Erstellung eines
Reports hat man die Möglichkeit, entweder einen Report-Wizard zu verwenden oder manuell die
entsprechenden SQL-Befehle einzugeben. Dabei fallen zwei Punkte auf: zum einen hat man sehr
weitreichende Möglichkeiten der Gestaltung von Reports – gerade im Hinblick auf die
Datenbankanfrage – und zum anderen ist die Bedienung relativ umständlich, d.h. sie ist wenig
intuitiv und verlangt einige Einarbeitungszeit.
Der Report-Wizard ermöglicht eine relativ bequeme Erstellung eines eigenen Reports. Dabei
werden im ersten Schritt die Tabellen und Sichten des betreffenden Benutzers angezeigt, aus denen
eine Auswahl getroffen werden kann:
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil IV: 3. Analyse existierender Benutzeroberflächen
96
Abbildung IV-6: Oracle WebDB: Dialog "Tables and Views"
Wurde mehr als eine Tabelle ausgewählt, so müssen im folgenden Dialogschritt die JOINBedingungen angegeben werden:
Abbildung IV-7: Oracle WebDB: Dialog "Join Conditions"
Anschließend kann man aus einer Liste die gewünschten Spalten auswählen. Die ausgewählten
Spalten können nun einzeln mit Bedingungen (NOT NULL, >= 1000, ...) versehen werden.
Danach werden nochmals sämtliche Spalten angezeigt. Hier ist eine Angabe der Formatierung des
Reports für jede Spalte möglich (z.B. Ausrichtung links oder rechts). Es folgt ein Dialog, in dem
nähere Daten zum gewünschten Layout eingegeben werden können, z.B. die Farbe einer Spalte
oder das Ausgabeformat (HTML, ASCII, Excel).
Unangenehm fällt hier auf, daß die Erstellung von Queries und Reports nicht gerade
benutzerfreundlich gelöst wurde. Unerfahrene BenutzerInnen könnten hier vermutlich keinen
Report "auf die Schnelle" entwickeln. Man muß dazu allerdings auch erwähnen, daß WebDB
primär als Adminstrationstool und nicht als Query-und-Report-Tool gedacht ist.
Interessant ist, daß die erstellten Reports in lediglich drei Formaten ausgegeben werden können:
HTML, ASCII und Microsoft Excel. HTML eignet sich nur zur formatierten Darstellung auf dem
Bildschirm, kann also nicht direkt weiterverarbeitet werden. Lediglich die Wahl von Microsoft
Excel bietet die Möglichkeit einer sinnvollen Weiterverarbeitung der Daten, z.B. zur Erstellung
von Charts oder zum Speichern in einer lokalen Datenbank.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil IV: 3. Analyse existierender Benutzeroberflächen
97
3.2 Benutzerfreundlich: Microsoft Access
MS Access ist als Bestandteil von Microsoft's Office-Paket eine weitverbreitete Datenbank für den
(semi)-professionellen Einsatz. Gerade deshalb ist eine Untersuchung des GUI interessant, da hier
ausdrücklich BenutzerInnen angesprochen werden sollen, welche die Datenbank lediglich zur
Speicherung von wenigen, kleinen Tabellen (CD-Sammlung, Verwaltung von Kundendaten bei
Kleinfirmen, ..) verwenden. Die folgende Abbildung zeigt die Beispieldatenbank NORDWIND in
einem eigenen Fenster:
Abbildung IV-8: Microsoft Access: Anzeige aller Tabellen einer Datenbank
Dieses Frame verwendet Registerkarten, um unterschiedliche Sichten auf die Datenbank zu bieten.
Es gibt je eine Registerkarte für Tabellen, Abfragen, Formulare, Berichte, Makros und Module. Die
Tabellen-Registerkarte zeigt eine Liste mit den verfügbaren Tabellen der Datenbank. Ein
Doppelklick auf eine Tabelle führt das SQL-Kommando SELECT * FROM ... aus. Es können an
dieser Stelle auch neue Tabellen kreiert und bestehende Tabellen geändert werden.
Das Erstellen von Abfragen geschieht entweder über die manuelle Eingabe von SQL-Befehlen oder
über einen speziellen Dialog:
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil IV: 3. Analyse existierender Benutzeroberflächen
98
Abbildung IV-9: Microsoft Access: GUI zur Erstellung einer Abfrage
In der oberen Hälfte des Fensters sind die ausgewählten Tabellen zu sehen. Join-Bedingungen (in
der Abbildung: Bestelldetails.Artikel-Nr = Artikel.Artikel-Nr) sind übersichtlich dargestellt. In
der unteren Fensterhälfte können über Drag-Listen die Attribute der angezeigten Tabellen einzeln
angewählt werden. Der SQL-Befehl ORDER BY ist in der Zeile "Sortierung" ins GUI integriert.
Zusätzliche Kriterien bzw. einschränkende Bedingungen können separat angegeben werden. Den
SQL-Code wird automatisch generiert und kann nachträglich manuell bearbeitet werden.
Die Datenbankanfragen können nun in Berichte oder Formulare "eingebaut" werden. Hier
existieren zahlreiche Vorlagen und Beispiele, so daß die Erstellung professioneller Berichte kein
Problem darstellt.
Als Fazit läßt sich sagen, daß auch unerfahrene BenutzerInnen mit MS Access schnell
Datenbankanfragen zusammenstellen können. SQL-Erfahrung ist dabei nicht nötig – die
Codegenerierung läuft völlig transparent im Hintergrund ab. Für komplexere Datenbankanfragen
kann SQL-Code direkt eingegeben werden. Leider wird hier keine weitere Unterstützung geboten,
d.h. der SQL-Code wird unformatiert und schwer lesbar in einem separaten Textfenster angezeigt.
Bei einer manuellen Änderung des SQL-Codes hat die GUI Probleme, die Änderungen zu
übernehmen.
Die Anfrageergebnisse können in andere Datenbanken exportiert oder in HTML-Tabellen
umgewandelt werden. Eine weitergehende Nutzung der Daten ist nur über die Verwendung der
Tabellenkalkulation MS Excel möglich (natürlich bietet auch dieses Produkt Exportmöglichkeiten).
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil IV: 4. Use-Cases
99
4 Use-Cases
Grundlage für die Erstellung dieser Use-Cases (Anwendungsfälle) sind die gestellten
Anforderungen, die im vorigen Kapitel näher beschrieben wurden.
Generate
Query
<<include>>
Input/Edit
Query
Login
<<extend>>
Manage
Query
User
Input Query und Edit Query
wurden zusammengefaßt, da in
der derzeitigen Implementierung
eine Unterscheidung nicht
relevant ist.
<<extend>>
Manage Query enthält
Funktionen wie Load
Query, Save Query,
Execute Query.
Configure
Chart
Create
Chart
<<include>>
Map to
Chart
Abbildung IV-10: Use-Case-Diagramm
Die Anwendungsfälle sind also "Generate Query", "Input/Edit Query", "Login", "Manage Query",
"Configure Chart", "Create Chart" und "Map to Chart". Diese Use-Cases lassen sich grob in zwei
Gruppen unterteilen: Query-Anwendungsfälle und Report-Anwendungsfälle. Zu "Report" zählen
die "XXX Chart"-Anwendungsfälle, die übrigen Use-Cases können unter "Query" eingeordnet
werden.
Login (Query)
Es wird hierbei lediglich ein Dialogfenster angezeigt, in das Username, Paßwort, Datenbank-URL,
JDBC-Treibername und Server-URL eingegeben werden können. Anzumerken ist hier noch, daß
die Daten zum Einloggen in die Datenbank nicht auf dem (zustandslosen) Server gespeichert
werden, sondern vielmehr bei jeder Datenbank-Anfrage mit übergeben werden.
Input/Edit Query (Query)
Hier soll einE BenutzerIn die gewünschte Anfrage rein textuell eingeben können. Bei
entsprechender Übung kann man so sicherlich schneller SQL-Anfragen zusammenstellen als mit
den (mehr oder weniger) umständlichen Mausklicks des Anwendungsfalles "Generate Query".
Das Textfeld, in dem die generierte Query angezeigt wird ist editierbar, d.h. es ist möglich, auch
automatisch generierte oder geladene Queries zu editieren. Aus diesen Eingaben wird dann eine
SQL-Anfrage generiert und XML-codiert.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil IV: 4. Use-Cases
100
Generate Query (Query)
Dieser Anwendungsfall ist kein durchgehender Dialog. Vielmehr ist hier eine bequeme
Generierung von SQL-Anfragen mit wenigen Mausklicks möglich. Nach dem Login werden hier
sämtliche Tabellen angezeigt, auf die der Benutzer Zugriff hat. Die Tabellen werden als Blätter
eines Baumes (ähnlich der Anzeige der Verzeichnisstruktur im Windows-Explorer) angezeigt.
Wird ein Tabellenname angeklickt, wird eine entsprechende Anfrage gegen die Datenbank
geschickt und das Ergebnis – die Spaltennamen der entsprechenden Tabelle – in einem eigenen
Fenster angezeigt.
Durch Anklicken der Checkboxes neben den Spaltennamen kann nun eine SQL-Anfrage
zusammengestellt werden. Diese SQL-Anfrage kann auch von Hand editiert werden (vgl. den
Anwendungsfall "Input/Edit Query").
Manage Query (Query)
Dieser Anwendungsfall enthält die "Sub-Anwendungsfälle" Load, Save, Execute Query. Ist eine
Query vorhanden (z.B. aufgrund einer Benutzereingabe), dann kann sie gespeichert und wieder
geladen werden. Das Ausführen einer Abfrage setzt ebenfalls das Vorhandensein einer Query
voraus.
Map to Chart (Report)
Dieser Use-Case fordert das Vorhandensein von gültigen Ergebnissen einer Datenbankanfrage.
Liegt ein solches Ergebnis vor, so können die relevanten XML-Tags einzelnen Parametern der
Chart-Bean zugewiesen werden.
So kann man sich bequem seine eigenen Charts aus den vorhandenen Daten zusammenstellen und
sich dann jeweils das Ergebnis anzeigen lassen.
Create Chart (Report)
Mit diesem Anwendungsfall ist die Visualisierung der Anfrageergebnisse auf der Clientseite
gemeint. Erforderlich ist ein vorheriges Mapping der XML-Tags auf die Parameter der Chart-Bean
(siehe Anwendungsfall "Map to Chart").
Configure Chart (Report)
Dieser Anwendungsfall erweitert den "Create Chart"-Anwendungsfall um eine
Konfigurationskomponente. Es ist nun möglich, den Chart besser den eigenen Wünschen
anzupassen, z.B. Änderung des Chart-Layouts, der verwendeten Farben und vielen Punkten mehr.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil V: 1. Grobentwurf
Teil V:
101
Design
1 Grobentwurf
Der Grobentwurf beschreibt die allgemeine Architektur des implementierten Query-Tools. Diese
Systemarchitektur wird in Form von Verteilungs-, Komponenten- und Paketdiagrammen in der
UML-Notation beschrieben. Die Use-Cases des Design-Teils werden hier detailliert mit UMLAktivitätsdiagrammen beschrieben. Anschließend wird die Verwendung von XML als
Übertragungsprotokoll diskutiert, wobei verschiedene DTDs und DTD-Schablonen vorgestellt
werden. Mit JavaBeans zur XML-Verarbeitung befaßt sich das folgende Kapitel. Abschließend
wird noch analysiert, ob clientseitig ein Java-Applet oder eine Java-Applikation verwendet werden
soll.
1.1 Verteilungsdiagramm
Das folgende Verteilungsdiagramm gibt Auskunft über die physiche Verteilung der einzelnen
Komponenten des Systems. Wie man sieht, handelt es sich um eine logische 3-Tier Architektur.
Logisch in dem Sinne, daß die Datenbank durchaus auch auf dem Server-Rechner laufen kann und
die Client-Anwendung über ein Netzwerk mit der restlichen Applikation kommuniziert.
Datenbankserver
Oracle 7.3.4
Datenbank
DB
Client
com.microstar.xml.
AElfred
JDBC
Server
XMLConverter
com.microstar.xml.
AElfred
QueryBean
RMI
XQTClient
RMI
xqt.server
XMLBarChart
XMLConverter
...
RMI
Abbildung V-1: Systemarchitektur - Verteilungsdiagramm8
8
Das Verteilungsdiagramm – wie auch alle folgenden UML-Diagramme – verwendet zur Paketbeschreibung
die Java-Notation. So sind Pakete hierarchisch angeordnet; Paketnamen werden klein geschrieben. Die
Namen von Klassen oder Komponenten werden groß geschrieben.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil V: 1. Grobentwurf
102
Wie man sieht, ist dieses Verteilungsdiagramm eine vereinfachte Darstellung des Sachverhalts. Auf
der Clientseite wurde z.B. nicht berücksichtigt, daß das Applet im Kontext eines Web-Browsers
läuft und zunächst über HTTP vom Server geladen werden muß.
RMI statt CORBA
Der vielleicht wichtigste Punkt in obigem Verteilungsdiagramm ist die Verwendung von Java's
RMI (Remote Method Invocation). Das bedeutet insbesondere, daß auf CORBA/IIOP als
Kommunikationsbasis verzichtet wird. Es gibt zwei Gründe für diese Entscheidung:
•
Mit RMI läßt sich unter Java erheblich einfacher programmieren als mit CORBA, da keine
Schnittstellendefinitionen in CORBA's IDL geschrieben werden müssen
•
Es besteht keine Notwendigkeit für CORBA, da das Web-Informationssystem eine
klassische Client/Server-Architektur ist und beide Seiten in Java implementiert werden.
Bleibt anzumerken, daß in einer kommerziellen Implementierung die Verwendung von CORBA
sinnvoller ist, da dann eine bessere Anbindung an andere Komponentenarchitekturen möglich ist.
Verwendung des Fassade-Patterns für den Datenbankzugriff
Der Datenbankzugriff mit der Java-Datenbank-API JDBC ist schwierig und fehleranfällig. JDBC
besteht aus einer Vielzahl von Klassen und Schnittstellen, der JDBC-Code ist relativ schwierig zu
lesen und das Exception-Handling ist aufwendig. Deshalb ist es sinnvoll, diese Komplexität in
einer speziellen Fassade-Klasse zu verbergen, die als Schnittstelle zwischen der eigentlichen
Anwendung und dem JDBC-Paket verwendet wird. So ist es möglich, auf einer relativ hohen
Abstraktionsebene auf die Datenbank zuzugreifen, ohne sich um Low-Level-Details wie SQLBefehle oder Ausnahmebehandlung kümmern zu müssen.
Anzumerken ist hier allerdings, daß die hier implementierte Komponente (QueryBean) erstens
nicht den Zugriff auf alle (nicht einmal auf besonders viele) Funktionen bietet und zweitens
natürlich primär für die Diplomarbeit geschrieben wurde, d.h. durchaus auch Funktionen
beinhaltet, die in einem anderen Kontext wenig Sinn ergeben. Ein interessanter Aspekt bei meiner
Implementierung ist allerdings, daß die Ergebnisse der Datenbankanfrage als gültiges XMLDokument zurückgeliefert werden.
XML Parser
Die gesamte Kommunikation innerhalb des Query-Tools soll in XML erfolgen. Somit wird sowohl
auf Client- als auch auf Serverseite ein XML-Parser benötigt, der zumindest auf der Clientseite nur
aus wenigen Klassen besteht. Der einzige Parser, der diese Anforderung erfüllt (die Parser von Sun,
IBM oder Oracle sind gewaltige Pakete, deren Größe (und damit deren Download-Zeit) in keinem
Verhältnis zum Nutzen steht) ist der freie, nicht-validierende XML-Parser AElfred von Microstar
[Microstar 99].
Da AElfred auf Callback-Basis arbeitet, muß eine eigene Klasse geschrieben werden, welche die
erforderlichen Callback-Methoden implementiert. Hier bietet sich natürlich eine Realisierung in
Form einer JavaBean an, die beliebig erweitert werden kann und den Zugriff zum eigentlichen
Parser transparent hält (nähere Infos dazu im Feinentwurf-Kapitel).
1.2 Grobstruktur der Anwendung
Die Grobstruktur der gesamten Anwendung ist in obigem Verteilungsdiagramm schon recht genau
beschrieben. In diesem Unterkapitel werden die Komponenten bzw. Pakete genauer beschrieben.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil V: 1. Grobentwurf
103
Zunächst jedoch noch ein Komponentendiagramm, das die Abhängigkeiten zwischen den
Komponenten aufzeigen soll. Anzumerken ist bei folgendem Diagramm noch, daß Komponenten
der Standard-API sowie der Java Foundation Classes (JFC) – insbesondere das Swing-Paket – nicht
dargestellt werden, da diese Abhängigkeiten vom Compiler selbstständig erkannt und von daher
auch mit Case-Tools nicht modelliert werden.
Client
com.microstar.xml.
AElfred
xqt.converter.
XMLConverter
Server
xqt.client
xqt.server
tdg.Perspective
QueryBean
(Chart-Bean von Three
D Graphics)
xqt.converter.
XMLConverter
com.microstar.xml.
AElfred
Abbildung V-2: Paket-/Komponentendiagramm der Anwendung
In den folgenden Abschnitten werden die Pakete und Komponenten kurz beschrieben (mehr
Informationen sind im Implementierungskapitel zu finden).
com.microstar.xml. AElfred
AElfred ist ein frei verfügbarer SAX-Parser der Firma Microstar [Microstar 99]. Dieser Parser ist
relativ klein (4 Klassen und eine Schnittstelle mit gerade mal 23k Codeumfang als JAR-File) und
aufgrund der ereignisbasierten API problemlos einzubinden. Wegen des geringen Codeumfangs ist
AElfred besonders für die Einbindung in Java-Applets geeignet.
Da der (DOM-basierte) XML-Parser von Sun vermutlich in einer der nächsten Java-Versionen in
die Klassenbibliothek integriert wird, ist es möglich, AElfred später auszutauschen und stattdessen
auf den Sun-Parser zuzugreifen.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil V: 1. Grobentwurf
104
xqt.converter.XMLConverter
Der XMLConverter ist die Schnittstelle der Client-Anwendung zu Microstar's XML-Parser
AElfred. Die Realisierung dieses Konverters als JavaBean erlaubt eine unproblematische
Verwendung von AElfred in anderen Anwendungen.
Das ganze Konverter-Paket besteht aus einer abstrakten und mehren nicht-abstrakten Klassen,
welche das Entwurfsmuster "Erbauer" implementieren. Eine Erweiterung des Paketes ist durch das
Schreiben konkreter Konverter-Klassen möglich.
xqt.client
Dieses Paket besteht aus zwei Klassen: XQTClient und XQTFrame. XQTClient wurde als JavaApplet entwickelt und hat einen relativ geringen Codeumfang. Der gesamte GUI-Code wurde in
die Klasse XQTFrame verlagert, um durch die Trennung von Anwendung und GUI-Code eine
bessere Austauschbarkeit der Klassen zu erreichen. Denkbar wäre beispielsweise, den Client nicht
als Applet sonderen als Applikation zu entwickeln. Hier müßte dann nur noch die Klasse
XQTClient ausgetauscht werden.
tdg.Perspective
Diese kommerzielle Chart-Bean von Three D Graphics [Three D Graphics 99] ist im Lieferumfang
von Oracle's JDeveloper 2.0 enthalten und kann als JavaBean in eigene Programme eingebunden
werden. Perspective for Java ist eine sehr mächtige Komponente, welche die Einbindung von 3DCharts, Kuchen- oder Balkendiagrammen ermöglicht. Sämtliche Eigenschaften (Farbe, Aussehen,
..) können über Bean-Properties manipuliert werden. Erweiterte Features wie verschiedene
Rotationswinkel bei 3D-Charts zeigen die Leistungsfähigkeit dieser Bean.
Leider führt diese große Leistungsfähigkeit auch zu Problemen: der Codeumfang der ClientAnwendung steigt um ein Vielfaches an (das gesamte Perspective-Klassenpaket ist unkomprimiert
824k groß – die gesamte restliche Anwendung ist 199k groß). Bei einer Weiterentwicklung des
Query-Tools ist zu überlegen, ob diese Chart-Bean wirklich so ausgenutzt werden kann, daß dieser
Code-Overhead zu vertreten ist. Ansonsten hat man die Möglichkeit, entweder auf eine andere
Chart-Bean umzusteigen oder sich von Three D Graphics eine individuelle Bean mit dem
gewünschten Funktionsumfang zusammenstellen zu lassen.
xqt.server
In diesem Java-Paket sind die serverseitigen Klassen und Schnittstellen des Query-Tools
zusammengefaßt. Kern des Serverpaketes ist die Klasse XQTServer, mit deren main-Methode der
Server gestartet wird. Ansonsten enthält das Paket noch einen Adapter für die einzubindende
QueryBean (vgl. den folgenden Abschnitt) und ein RemoteInterface, um den Zugriff über RMI zu
ermöglichen.
xqt.QueryBean
Diese Bean enthält alle Methoden, die benötigt werden, um über JDBC auf eine relationale
Datenbank zuzugreifen. Das Ergebnis einer Datenbankanfrage wird in Form eines gültigen XMLDokumentes zurückgegeben.
1.3 Graphisches User-Interface (GUI)
Die Schnittstelle zum Benutzer besteht aus einem Java-Programm, welches sowohl als Applet als
auch als Applikation verwendet werden kann. Es bietet eine graphische Oberfläche, die mit dem
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil V: 1. Grobentwurf
105
Swing-Paket entwickelt wurde. Die Aufteilung des Clients in XQTClient und XQTFrame dient
der Übersichtlichkeit, da der – recht umfangreiche – Code zur Generierung der graphischen
Benutzerschnittstelle vom eigentlichen Programm entkoppelt und entsprechend einfacher zu warten
ist.
Aufbau der GUI
Die im Analyseteil beschriebenen Benutzeroberflächen haben alle ihre Vor- und Nachteile.
Sinnvoll ist in jedem Fall die Verwendung von Registerkarten, wie sie etwa MS Access verwendet.
Allerdings ist eine einfache Trennung von Query- und Report-Funktionalität etwas übersichtlicher.
Seagate's Crystal Report z.B. hat nur die Registerkarten "Query" und "Report".
Als grundlegendes Look & Feel für das Query-Tool dieser Diplomarbeit dienen die SwingKlassen, die ab dem JDK 1.1.7 vollständig in die Sprache integriert sind. Folgende Abbildung zeigt
den prinzipiellen Aufbau der Benutzeroberfläche:
Abbildung V-3: Benutzeroberfläche des Query-Tools
Neben einer Menüleiste mit Standard-Funktionen und einer ebensolchen Toolbar fällt die strikte
Trennung der Anwendung in einen Query- und in einen Reportteil mittels Registerkarten auf. Die
Query-Oberfläche ist somit relativ übersichtlich und einfach zu bedienen. Der Baum im linken
oberen Teil der Oberfläche zeigt die Tabellen und Sichten des entsprechenden Benutzers an. Durch
einfaches Anklicken wird im rechten oberen Teil ein sogenanntes internes Frame generiert, das die
Spaltennamen der Tabelle anzeigt. Zur Generierung des SELECT-Teils der Datenbankanfrage
können nun einzelne Spalten ausgewählt werden. Der im unteren Frame angezeigte SQL-Code
kann nun – falls erforderlich – noch nacheditiert werden oder gleich mit dem EXECUTE-Button an
die Datenbank geschickt werden.
Nach einer erfolgreichen Ausführung der Anfrage sollen die zurückgegebenen (XML-codierten)
Daten weiterverarbeitet werden. Dies geschieht über die Optionen der "Report"-Registerkarte. In
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil V: 1. Grobentwurf
106
folgender Abbildung sieht man drei weitere Registerkarten: Table, Perspective Chart und XML
Source:
Abbildung V-4: Report-Registerkarten des Query-Tools
Im Frame der Table-Karte erscheint stets die Rückgabetabelle, die clientseitig aus dem XML-Code
generiert wird. Die Registerkarte "XML Source" zeigt den reinen XML-Code in einem Textfenster,
der z.B. mittels Cut & Paste in andere Programme übernommen werden (und übrigens auch editiert
werden) kann.
"Perspective Chart" ist die Registerkarte des Chart-Beans von Three D Graphics [Three D Graphics
99]. Diese Chart-Bean bietet umfangreiche Möglichkeiten der Gestaltung von Charts, die dann
auch als Grafik abgespeichert werden können.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil V: 1. Grobentwurf
107
Abbildung V-5: Mapping der Spalten der Rückgabetabelle
Zuvor müssen jedoch die Spalten der Rückgabetabelle auf die entsprechenden Parameter der ChartBean übertragen werden. Nach dem Mapping der Spalten auf die Bean-Schnittstelle kann man sich
den Chart anzeigen lassen:
Abbildung V-6: Visualisierung der Ergebnisse mit der ChartBean
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil V: 1. Grobentwurf
108
Ganz allgemein läßt sich also die Funktionalität der Client-Komponente des Query-Tools in zwei
Teile aufspalten:
•
Query und
•
Report
Das Report-Frame bietet mindestens zwei Registerkarten: zur Darstellung des Ergebnisses in Form
einer Tabelle und als XML-Quelltext. Sollen JavaBeans eingebunden werden, so ist dies
problemlos möglich – zumindest wenn schon eine brauchbare visuelle Schnittstelle zur Bean zur
Verfügung steht.
Menüs
Die Menüstruktur ist relativ einfach gehalten. Im "File"-Menü werden Funktionen zum Laden und
Speichern von Queries angeboten. Das Menü "Basic Functions" enthält sämtliche relevanten
Funktionen zum Einloggen in die Datenbank, zum Testen der Verbindung zum Server und zum
Ausführen von Queries. Im "Tools"-Menü steht derzeit nur die Umschaltung zwischen
verschiedenen Look & Feel-Standards (Windows, Motif, Java) zur Verfügung.
Anmerkungen zu den Aktivitätsdiagrammen der Use-Cases
Aktivitätsdiagramme sind eine UML-Notation zur Beschreibung von nebenläufigen Zuständen und
Aktivitäten (Aktivitäten sind Zustände mit einer internen Aktion).
In allen folgenden Aktivitätsdiagrammen ist eine Aktivität "GUI" spezifiziert. Damit ist stets das
ganze grafische User-Interface gemeint. Es wurde darauf verzichtet, diesem GUI spezielle
Zustände zuzuordnen, um den Überblick einfacher zu machen. Dennoch sind die "GUI"Aktivitäten der folgenden Diagramme nicht äquivalent, sondern unterscheiden sich z.B. darin, daß
einzelne Menüpunkte "ausgegraut" - also nicht anwählbar - sind. Die Transitionen der GUIAktiviät sind stets Kommandos, wobei nicht zwischen der Anwahl eines Menüpunktes und
sonstigen GUI-Aktionen (Anklicken eines Buttons, Drag&Drop, ...) unterschieden wird.
Ebenfalls aus Gründen der Übersichtlichkeit wurden nicht alle zu einem bestimmten Zeitpunkt
anwählbaren Menüpunkte modelliert. Klar ist jedoch, daß beispielsweise der Menüpunkt "Quit" zu
jedem beliebigen Zeitpunkt angewählt werden kann.
Die rechteckigen Kästen geben den jeweiligen Objektzustand an. Diese Angabe des
Objektzustandes ist nicht unbedingt nötig und dient nur dazu, den semantischen Gehalt der
Diagramme zu erhöhen.
Use-Case "Login" (Dialog)
Dieser Anwendungsfall besteht aus einem einfachen Dialog. Wird Login angeklickt, so erscheint
ein Dialogfenster, in das der Benutzer seinen Benutzernamen, sein Paßwort, den URL der
Datenbank, den Namen des JDBC-Treibers und den URL des Servers.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil V: 1. Grobentwurf
109
Abbildung V-7: Screenshot des Login-Dialogs (Use-Case "Login")
Für die Felder "Database-URL", "Name of the JDBC Driver" und "Server-URL" wurden
Vorschlagslisten (Combo Boxes) verwenet. Zu diskutieren ist allerdings noch, ob diese erweiterten
Dialogpunkte nicht für den "normalen" Anwender transparent gehalten (sprich: weggelassen)
werden sollten.
Beim Abschluß dieses Dialogs mit OK werden automatisch Benutzername und Paßwort verifiziert
und es wird eine Anfrage gegen die Datenbank gestellt, um die dem Benutzer zugeordneten
Tabellen zu ermitteln:
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil V: 1. Grobentwurf
110
start
Initialize
System
[ok]
GUI
[command:login]
[notOk]
Verify
Login
[ok]
[ok]
Login
[verified]
[notOk]
Query
Tables
[ok]
[ok]
Tables
[available]
Abbildung V-8: Aktivitätsdiagramm für Use-Case "Login"
Wie man sieht, überschneidet sich dieser Anwendungsfall mit dem Use-Case "Generate Query".
Dennoch erschien mir die Unterscheidung zwischen einer Benutzernamen/Paßwort-Verifikation
und dem zugehörigen Login und der ersten Datenbankanfrage sinnvoll.
Use-Case "Input/Edit Query"
Dieser Anwendungsfall ermöglicht eine manuelle Eingabe einer Datenbankabfrage in einem
Textfeld. Es ist auch möglich, eine generierte Query (siehe Anwendungsfall "Generate Query") zu
editieren.
Use-Case "Generate Query"
"Generate Query" steht in einer include-Beziehung zu "Input/Edit Query". Wenn über das
Anklicken der Tabellen und Spalten eine Query generiert wird, wird automatisch das Textfeld von
"Input/Edit Query" geändert. Man beachte, daß zur Zeit noch keine Analyse der Query im Textfeld
stattfindet, d.h. daß manuelle Änderungen im Textfeld von diesem Anwendungsfall nicht erkannt
werden und somit z.B. keine Spalten-Deselektionen stattfinden.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil V: 1. Grobentwurf
111
Login
[verified]
Aktivität des Use
Cases "Login". Die
Use Cases "Login"
und "Generate
Query" überlappen
sich etwas.
[loginVerified]
Query
Tables
[notOk]
[ok]
[ok]
Initialize
System
Create
Table-Tree
Tables
[available]
GUI
[createdColumnFrame]
[command:select
column]
[command:select
table]
Query
[generated]
Update
Query-Field
Query
Columns
[ok]
Create
Column-Frame
Column-Frame
[created]
Abbildung V-9: Aktivitätsdiagramm für Use-Case "Generate Query"
Bevor eine Query-Generierung möglich ist, muß der Benutzer in die Datenbank eingelogged sein
[loginVerified]. Nach dem Login wird automatisch eine Anfrage gegen die Datenbank gestellt, um
alle Tabellen eines Benutzers anzuzeigen. Wenn auf diese Anfrage keine geeignete Ergebnismenge
zurückgeliefert wurde, dann muß sich der Benutzer erneut einloggen (siehe Use-Case "Login").
Wenn die Tabellen korrekt zurückgeliefert wurden, wird ein Tabellenbaum mit der DatenbankURL als Wurzelelement kreiert:
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil V: 1. Grobentwurf
112
Abbildung V-10: Tabellenbaum für den User "baier"
Wird nun ein Blatt dieses Baumes (also eine Tabelle) angeklickt, so wird automatisch eine neue
Datenbankanfrage gestartet, welche die Spalten der ausgewählten Tabelle in einem internen Frame
anzeigt:
Abbildung V-11: Spalten-Frame für die Tabelle COFFEES
Es können nun einzelne Spaltennamen angeklickt werden, um so die Query zu generieren. Sobald
eine Spalte angeklickt wurde, existiert eine ausführbare Query. Wird nun über einen Menüpunkt
oder einen Button Execute Query angeklickt, so wird diese Anfrage gegen die Datenbank geschickt
(vgl. Use-Case "Manage Query").
Zur Zeit lassen sich SQL-Queries nur eingeschränkt generieren. Es ist lediglich möglich, die
Spalten bestimmter Tabellen auszuwählen. Wünschenswert ist z.B. die Auswahl von mehreren
Tabellen und deren automatische Verknüpfung über SQL-Joins.
Manage Query
"Manage Query" enthält im wesentlichen drei untergeordnete Anwendungsfälle:
•
Load Query
•
Save Query
•
Execute Query
In folgendem Aktiviätsdiagramm wird der Zustand Query [generated] eingeführt. Man beachte, daß
dieser Zustand auch in den Use-Cases "Input/Edit Query" und "Generate Query" vorkommt. Der
Zustand der Query ist in allen Aktivitätsdiagrammen äquivalent und ist prinzipiell als
Voraussetzung für die Ausführung des Befehls "execute" zu sehen.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil V: 1. Grobentwurf
113
Der Zustand Query
[generated] kann natürlich
auch über andere Aktivitäten
als "Load Query" erreicht
werden (vgl. z.B. Use Case
"Input/Edit Query")
[command:
load]
Load
Query
[ok]
[ok]
Query
[generated]
GUI
[command:
save]
Save
Query
[command:
execute]
Execute
Query
[ok]
[ok]
Query
[saved]
Results
[available]
Abbildung V-12: Aktivitätsdiagramm für den Use-Case "Manage Query"
Diese Anwendungsfälle können über das "File"-Menü (und über die Toolbar) ausgewählt werden.
"Load Query" führt zum Öffnen einer Filedialog-Box, die eine bequeme Auswahl einer Query
ermöglicht. Mit "Save Query" wird die aktuelle Query (die im Textfenster des "Input/Edit Query"Anwendungsfalles angzeigt wird) gespeichert. Durch Anwahl von "Execute Query" schließlich
wird die aktuelle Query gegen die Datenbank geschickt. Die Kommandos "Execute Query" und
"Save Query" sind nur anwählbar, wenn auch tatsächlich eine Query im Textfenster angezeigt wird
(also der Zustand "Query [generated]" zutrifft).
Map to Chart, Create Chart, Configure Chart
"Map to Chart", "Create Chart" und "Configure Chart" beziehen sich auf das Mapping, das
Zeichnen und die Konfiguration des Perspective-Beans von Three D Graphics [ThreeDGraphics
99]. Folgendes Aktivitätsdiagramm beschreibt die Aktivitäten, die mit diesen Use-Cases
zusammenhängen:
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil V: 1. Grobentwurf
114
[resultsAvailable]
Create
Table-Frame
Create
Map-Frame
GUI
[command:
mapResults]
Create
Chart
Create
Config.-Frame
Abbildung V-13: Aktivitätsdiagramm für die " Chart"-Use-Cases
Man beachte, daß hier (wie auch bei allen anderen Anwendungsfällen) ein kreiertes Frame solange
gültig bleibt, bis es (z.B. hier durch Änderung der Chart-Parameter) überschrieben wird.
Die Aktivitäten "Create Table-Frame" und "Create Map-Frame" werden unmittelbar nach dem
Vorhandensein der Anfrage-Resultate ausgeführt, da die Anzeige der Ergebnisse in Form einer
Tabelle und in Form von "Plain XML" ohne großen Aufwand durchführbar ist und in der Regel
vom Benutzer gewünscht wird. Übrigens werden die XML-codierten Ergebnisse, die im
entsprechenden Textfenster angezeigt werden, auch genau hier gespeichert. D.h., daß eine
Weiterverarbeitung (z.B. Mapping auf die Chart-Bean) stets auf der Basis der XML-Ergebnisse
dieses Textfensters erfolgt.
1.4 XML als Übertragungsprotokoll
XML ist die Kommunikationsbasis des Query-Tools. Wichtig ist deshalb, vor einer
Implementierung die zugrundeliegenden DTDs genau zu überprüfen. Insbesondere die
Aufwand/Nutzen-Relation ist wichtig, da die Übertragung von einfachen Parametern oder gar
reinem Text keiner aufwendigen DTD bedarf.
Ein XML-Dokument wird dabei in einem StringBuffer-Objekt gespeichert und über RMI
übertragen. Im folgenden werden die verwendeten Dokumenttyp-Definitionen (DTDs) kurz
beschrieben.
Login
Hier wird eine einfache, geschachtelte DTD verwendet, welche die Möglichkeit bietet, den
Benutzernamen (userName), das Paßwort (password), den Datenbank-URL (databaseURL)
und den JDBC-Treibernamen (driverName) zu übertragen.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil V: 1. Grobentwurf
115
<!ELEMENT login (userName, password, databaseURL, driverName,
serverURL)>
<!ELEMENT userName (#PCDATA)>
<!ELEMENT password (#PCDATA)>
<!ELEMENT databaseURL (#PCDATA)>
<!ELEMENT driverName (#PCDATA)>
<!ELEMENT serverURL (#PCDATA)>
Codebeispiel V-1: Login-DTD
Diese Login-DTD hat durchaus Mängel: So ist z.B. vorstellbar, daß die Datenbank-URL und der
JDBC-Treibername im Applet hart-codiert sind und nicht geändert werden können. In einer
professionellen Anwendung wäre es ohnehin wünschenswert, lediglich Vorschlagslisten mit
konkreten, firmenspezifischen Datenbanknamen (z.B. "Customer Database" oder "Accounting
Database") anzubieten und die Auflösung dieser Namen auf die Serverseite zu verlagern. Der
Serverteil der Anwendung kann dann den entsprechenden JDBC-Datenbanktreiber dynamisch
laden und die Datenbankanfrage ausführen.
SQL-Query
Mit der SQL-DTD wird ein SQL-Befehl XML-codiert und zum Server übertragen.:
<!ELEMENT query (querystring)>
<!ELEMENT querystring(#PCDATA)>
Codebeispiel V-2: SQL-Query-DTD
Diese DTD wurde bewußt einfach gehalten, um auch komplexe SQL-Befehle zu ermöglichen. Eine
für ein professionelles Produkt sinnvollere DTD wäre eine komplette Beschreibung der SQLGrammatik. Der Aufwand zum Schreiben einer solchen DTD ist allerdings sehr hoch; zumal die
Generierung bzw. Auswertung der entsprechenden Query relativ aufwendig zu implementieren
wäre. Für den Prototyp des Query-Tools habe ich mich deshalb entschieden, lediglich einen String
für die gesamte Anfrage zu verwenden.
Anfrageergebnisse
Für jede Datenbankanfrage wird eine neue DTD generiert. Die DTDs folgen alle folgendem
Schema:
<!ELEMENT database (records)*>
<!ATTLIST database URL CDATA #REQUIRED>
<!ELEMENT table (row)*>
<!ATTLIST table QUERY CDATA #REQUIRED>
<!ELEMENT row (columnName)*>
<!ATTLIST row key ID #REQUIRED
foreignKeys IDREFS #IMPLIED>
<!ELEMENT columnNameXXX (#PCDATA)>
<!ATTLIST columnNameXXX
TYPE CDATA #FIXED [Datentyp, z.B. VARCHAR2]
NAME CDATA #FIXED [Üblicherweise identisch mit dem columnName]
ISNULL (true|false) #IMPLIED
>
[hier folgen die weiteren Spaltennamen mit ihren Attributlisten]
<!ELEMENT column (#PCDATA)>
Codebeispiel V-3: DTD-Schablone für Abfrageergebnisse
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil V: 1. Grobentwurf
116
Diese einfache DTD-Schablone genügt als Austauschformat für zweistellige relationale Strukturen.
Derartige Strukturen lassen sich als Syntaxbaum wie folgt darstellen (etwas vereinfacht):
DATA
BASE
TABLE
ROW
ROW
COLUMN
PC
DATA
COLUMN
PC
DATA
COLUMN
COLUMN
PC
DATA
PC
DATA
COLUMN
PC
DATA
COLUMN
PC
DATA
Abbildung V-14: Struktur, Darstellung und Inhalt mit der XML
Wie man sieht, wird als Wurzelelement der Name der Datenbank verwendet. Dieses Element hat
lediglich ein Attribut: den URL der Datenbank. Wegen den zu erwartenden Sonderzeichen ist der
Typ des Attributs CDATA, also Character Data – im Gegensatz zu PCDATA (Parsable Character
Data).
Der Hauptunterschied zwischen CDATA und PCDATA ist, daß bei CDATA der Text wörtlich
übernommen wird und nicht wie bei PCDATA die Entity-Referenzen ersetzt werden. CDATA wird
z.B. von Büchern über XML verwendet, bei denen XML-Tags im Text selbst vorkommen und
nicht ersetzt werden sollen, da sie ja nur Beispiele sind.
Zurückgegeben wird stets eine Tabelle, deren einziges Attribut die SQL-Anfrage selbst ist
(SELECT ... FROM ... WHERE ...). Eine Tabelle kann aus einem oder mehreren Datensätzen
(Tupeln oder Zeilen) bestehen. Ein Tupel ist eindeutig identifizierbar durch einen Primärschlüssel
(key), der unbedingt erforderlich (#REQUIRED) ist. Fremdschlüssel (foreignKeys) sind
Primärschlüssel anderer Relationen und haben deshalb eine ID, welche auf diese anderen
Relationen eindeutig verweist. Die Spalten oder Attribute jedes Tupels sind vom Typ PCDATA.
Das Attribut ISNULL hat keinen Default-Wert. Es ist aber unbedingt erforderlich, aus der Auswahl
(true, false) einen Wert zu nehmen (#IMPLIED). Der folgende Codeausschnitt zeigt ein Beispiel
für den generierten XML-Code aus der Datenbankanfrage SELECT * FROM COFFEES:
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil V: 1. Grobentwurf
<?xml version="1.0" encoding="UTF-8"?>
<-- generated by XQT -->
<!DOCTYPE database [
<!ELEMENT database (table)>
<!ATTLIST database URL CDATA #REQUIRED>
<!ELEMENT table (row)*>
<!ATTLIST table QUERY CDATA #REQUIRED>
<!ELEMENT row (COF_NAME, SUP_ID, PRICE, SALES, TOTAL)>
<!ELEMENT COF_NAME (#PCDATA)>
<!ATTLIST COF_NAME
TYPE CDATA #FIXED "VARCHAR2"
NAME CDATA #FIXED "COF_NAME"
ISNULL (true|false) #IMPLIED
>
<!ELEMENT SUP_ID (#PCDATA)>
<!ATTLIST SUP_ID
TYPE CDATA #FIXED "NUMBER"
NAME CDATA #FIXED "SUP_ID"
ISNULL (true|false) #IMPLIED
>
<!ELEMENT PRICE (#PCDATA)>
<!ATTLIST PRICE
TYPE CDATA #FIXED "NUMBER"
NAME CDATA #FIXED "PRICE"
ISNULL (true|false) #IMPLIED
>
<!ELEMENT SALES (#PCDATA)>
<!ATTLIST SALES
TYPE CDATA #FIXED "NUMBER"
NAME CDATA #FIXED "SALES"
ISNULL (true|false) #IMPLIED
>
<!ELEMENT TOTAL (#PCDATA)>
<!ATTLIST TOTAL
TYPE CDATA #FIXED "NUMBER"
NAME CDATA #FIXED "TOTAL"
ISNULL (true|false) #IMPLIED
>
]>
<database URL="jdbc:oracle:thin:@192.168.1.153:1526:ORCL">
<table QUERY="select * from coffees">
<row>
<COF_NAME> Espresso </COF_NAME>
<SUP_ID> 123 </SUP_ID>
<PRICE> 456 </PRICE>
<SALES> 789 </SALES>
<TOTAL> 12 </TOTAL>
</row>
<row>
<COF_NAME> Brasilian </COF_NAME>
<SUP_ID> 123 </SUP_ID>
<PRICE> 456 </PRICE>
<SALES> 789 </SALES>
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
117
Teil V: 1. Grobentwurf
118
<TOTAL> 12 </TOTAL>
</row>
</table>
</database>
Codebeispiel V-4: DTD-Beispiel für eine SQL-Query
Wie man sieht, wurde hier eine sogenannte interne DTD generiert, die ins XML-Dokument selbst
eingefügt wurde. Zur Zeit ist allerdings noch kein Algorithmus implementiert, der Fremdschlüssel
als solche erkennt und behandelt.
1.5 XML-Verarbeitung mit JavaBeans
Ursprünglich war geplant, eine Funktionalität zum dynamischen Nachladen von JavaBeans zur
Verfügung zu stellen. Die Idee dabei ist, daß nicht jeder Benutzer alle verfügbaren Beans benötigt
und daß diese je nach Bedarf vom Server heruntergeladen werden können.
Der Server müßte also Methoden anbieten, mit denen die verfügbaren Beans ermittelt und ggf.
heruntergeladen werden können. Die verfügbaren Beans können dann – am besten in Form von
Icons – im Client-GUI angezeigt und bei Mausklick dynamisch nachgeladen werden.
Das typische Szenario beim Nachladen von Beans wäre dann:
•
Anfrage des Clients an den Server, welche Beans verfügbar sind
•
Antwort des Servers und Anzeige als Icons im Client-GUI
•
Anforderung einer Bean durch den Benutzer
•
Automatische Installation der Bean im Client
•
Konfiguration der Bean durch den Benutzer
Das Problem ist, daß für jede Bean eine eigene GUI-Schnittstelle erforderlich ist, um die
entsprechenden Funktionen anwählen zu können. Dies könnte am einfachsten realisiert werden,
indem das GUI der Report-Registerkarte von einer (dynamisch geladenen) Java-Klasse generiert
wird.
Eine andere Möglichkeit wäre, die GUI-Daten der Bean in Form eines XML-Dokumentes zu
übergeben. Dieses XML-Dokument müßte dann gesondert ausgewertet werden, um das GUI der
Report-Registerkarte neu zu zeichnen.
Die Möglichkeit des Nachladens von JavaBeans wurde in den Prototypen des Query-Tools aus
Zeitgründen nicht integriert. Bei einer Weiterentwicklung des Tools ist jedoch eine frühzeitige
Architekturänderung notwendig, um dieses Feature zu integrieren.
1.6 Applet oder Applikation?
Eine zentrale Frage für die Entwicklung der Anwendung ist, ob clientseitig ein Applet (im Kontext
eines Webbrowsers ausführbar) oder eine Applikation (von einer lokal installierten Virtuellen
Maschine ausführbar) verwendet werden soll.
Das – inzwischen prototypisch fertiggestellte – Query-Tool wurde clientseitig als Java-Applet, das
im Kontext eines Web-Browser ausgeführt wird, entwickelt. An dieser Stelle soll nun untersucht
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil V: 1. Grobentwurf
119
werden, welche Vor- und welche Nachteile ein Java-Applet im Gegensatz zu einer JavaApplikation hat.
Mobilität
Zu den Vorteilen der Realisierung als Applet gehört die größere Mobilität. Es ist z.B. möglich, auf
fremden Rechnern mit Web-Zugang das Applet auszuführen und die erhaltenen Daten zu
analysieren. Problematisch ist natürlich, daß ein Java-Applet auf die Virtuelle Maschine des
Browsers angewiesen ist. So benötigt man für verschiedene Web-Browser auch in der aktuellsten
Version spezielle Plug-Ins, die jedoch nicht auf jedem Rechner installiert sind. Das schränkt
natürlich gerade den Entwickler ein: man ist gezwungen, mit älteren Java-Versionen zu arbeiten,
bis die neueren Java-Versionen in die Browser integriert sind. Und auch hier ist mit Problemen zu
rechnen, da einige Browser nicht die vollständige Spezifikation umsetzen. So ist beispielsweise der
Internet Explorer 5.0 im Auslieferungszustand nicht RMI-fähig.
Sicherungsaufwand
Java-Applets haben ein gut durchdachtes Sicherheits-Konzept, das den Benutzer vor schädlichen
Applets schützen sollen. Diese Einschränkungen sind aber im vorliegenden Fall problematisch. Das
Speichern und Laden von Datenbankanfragen als Text-Files auf der Festspeicherplatte sollte schon
möglich sein, um den Nutzen nicht einzuschränken.
Die Sicherheitsrichtlinien können aber auch aufgeweicht werden. Möglich ist z.B. eine AppletZertifizierung, um etwa Queries abspeichern und laden zu können. Allerdings ist es eben etwas
aufwendiger, Applets zu zertifizieren und neue Sicherheitsrichtlinien zu entwickeln, als eine
Applikation zu schreiben, die ohnehin keine Einschränkungen hat.
Administration und Aktualität
Gerade im rasanten Web-Umfeld, in dem neue Versionen bestehender Applikationen oft im
Halbjahreszyklus erscheinen, ist eine ständige Pflege und Erweiterung der Software notwendig.
Dies läßt sich am ehesten bei der Verwendung von Java-Applikationen erreichen. Schreibt man
eine neue Version eines Query & Report-Tools, dann kann z.B. auf neuere Java-Bibliotheken und
–Klassen zurückgreifen, ohne sich über inkompatible Web-Browser Sorgen machen zu müssen.
Falls das Query-Tool eine neuere Java-VM zur Ausführung benötigt, dann wird diese neue JavaVersion eben gleich mitinstalliert.
Bei Java-Applets sieht es etwas anders aus. Hier gibt es zahlreiche Probleme mit den bekannten
Web-Browsern (Navigator, Explorer, Opera). Teilweise ist die aktuelle Java-Spezifikation nur
unvollständig oder fehlerhaft unterstützt und manchmal wird nicht einmal ein Plug-In angeboten,
das neuere Java-Applets ausführen kann. Der Entwickler kann hier also nicht die aktuellsten
Bibliotheken verwenden, sondern muß sich bezüglich der Java-Version an die Vorgaben der
Kunden halten, auf deren Web-Browsern das Applet ja ausgeführt werden soll.
Allerdings ist die Administration von Applets einfacher, wenn der Kunde nicht auf bestimmte
Browser bzw. Browserversionen festgelegt ist. Dann kann man beispielsweise dem Kunden
nahelegen, auf eine neuere Browserversion umzusteigen, um mit der neuen Version des QueryTools arbeiten zu können.
1.7 Auswahl des JDBC-Treibers
Da diese Diplomarbeit zwar datenbankunabhängig sein soll, aber der Prototyp der Implementierung
mit einer Oracle-Datenbank arbeitet, folgt nun ein kurzer Abschnitt über die JDBC-Treiber von
Oracle. Oracle bietet drei verschiedene Treiber an: einen Typ 4-Treiber, der komplett in Java
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil V: 1. Grobentwurf
120
implementiert und z.B. für Applets gedacht ist (Thin Driver), einen OCI-basierten Treiber, der für
den Einsatz in einer Middleware gedacht ist und einen serverseitigen JDBC-Treiber, der für den
Einsatz in Oracle 8i gedacht ist.
Thin Driver
Wie schon erwähnt, ist dies ein Typ 4-Treiber, der aus 100% Java besteht und für Anwendungen
gedacht ist, die aus dem Netz geladen werden. Dieser Treiber ist etwas langsamer als Oracle's Fat
Driver (was auch nicht verwundert, da ein Teil dieses Treibers in C implementiert wurde).
Fat Driver
Der Fat Driver ist ein Typ 2-Treiber, der für den Einsatz in einer Middleware gedacht ist. Er basiert
auf dem Oracle Call Interface (OCI), das in C geschrieben und deshalb nicht portabel ist. Auf das
OCI ist dann natürlich noch eine JDBC-Schicht gelegt, um JDBC-Aufrufe verarbeiten zu können.
Serverside Driver
Dieser Treiber ist für die Version 8i der Oracle-Datenbank gedacht. Es ist möglich, innerhalb
dieser Datenbank Java-Anwendungen laufen zu lassen. Das heißt, das Java-Programm läuft im
selben Prozeß und benutzt den gleichen Adreßraum wie die Datenbank. Hier muß natürlich keine
Verbindung mehr zur Datenbank aufgebaut werden. Im Rahmen dieser Diplomarbeit wird
allerdings Oracle 7 verwendet, weshalb diese Möglichkeit nicht mehr angesprochen wird.
Welcher Oracle-Treiber soll verwendet werden?
Das hängt davon ab, ob die Anwendung zu 100% aus Java bestehen soll, welche Systemarchitektur
verwendet wird und welche Oracle-Version installiert ist. Im Query-Tool der Diplomarbeit wird
kein clientseitiger Treiber zum Direktzugriff auf eine Datenbank verwendet. So können sowohl der
Typ 2- als auch der Typ 4-Treiber verwendet werden. Um allerdings eine reine Java-Anwendung
zu entwickeln, wird in der Diplomarbeit der Typ 4-Treiber (Thin Driver) benutzt.
1.8 Einbindung eines XSL-Prozessors
Die formatierte Anzeige der Query-Ergebnisse anhand eines XSL-Stylesheets ist eine der
wichtigsten Funktionen, die noch implementiert werden müssen. Allerdings könnte es Probleme
mit dem Programmumfang geben, wenn noch ein XSL-Prozessor – z.B. als JavaBean eingebunden wird. Hier bietet sich natürlich der Lotus XSL-Prozessor [alphaWorks 99] von IBM
an. Dieser Prozessor kann auf drei Arten verwendet werden: als JavaBean, als Java-Applet oder als
Kommandozeilen-Programm.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil V: 1. Grobentwurf
121
Eine Option ist dabei natürlich, fremde Anzeigeprogramme (z.B. Internet Explorer) zur
Formatierung und Darstellung der XML-Daten mittels XSL zu verwenden.
Zur Zeit werden die XML-Dokumente, welche die Anfrageergebnisse enthalten, mit dem
XMLConverter in ein spezielles Swing-Tabellenmodell konvertiert. Hier wäre eine Darstellung in
HTML/XML sinnvoller, da so eine weitere Verarbeitung besser möglich ist. Es könnte z.B. zu
jeder Datenbankanfrage nicht nur das XML-Ergebnisdokument sondern auch ein individuelles
Stylesheet zurückgeliefert werden, mit dem sich die XML-Daten als HTML/XML-Tabelle
anzeigen lassen.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil V: 2. Feinentwurf
122
2 Feinentwurf
In diesem Kapitel werden die Klassendiagramme der Client- und Serverkomponenten
entwickelt.Mit Sequenzdiagrammen werden interessante Client/Server-Interaktionen näher
beschrieben.
2.1 Pakete und Komponenten
Einen Überblick über die Pakete und Komponenten des Query-Tools geben
Verteilungsdiagramm und das Paket/Komponentendiagramm des Grobentwurf-Kapitels. In
folgenden Unterkapiteln werden die Klassendiagramme zu den einzelnen Paketen
Komponenten entwickelt. Weitere Codedetails und Sequenzdiagramme sind
Implementierungsteil zu finden.
das
den
und
im
2.2 xqt.client
Klassendiagramm
Der Kern der clientseitigen Software ist das Applet XQTClient. Diese Klasse dient zur
Verknüpfung der einzelnen Komponenten und zum Verbindungsaufbau zum Server. Die
Komponente XMLConverter verwendet den freien XML-Parser AElfred und dient dazu, die
XML-Dokumente so zu verarbeiten, daß z.B. die Perspective-ChartBean die Daten auswerten
kann.
com.microstar.xml.
AElfred
(XML-Parser from Microstar)
xqt.converter.
XMLConverter
(Schnittstelle zwischen AElfred
und XQTClient)
javax.swing.JApplet
javax.swing.JFrame
xqt.client.
XQTClient
xqt.client.
XQTFrame
tdg.Perspective
(Chart-Bean von Three D
Graphics)
Abbildung V-15: Klassendiagramm des Clients
Das Paket xqt.client besteht also aus zwei Klassen und den eingebundenen JavaBeans. Die Klasse
XQTClient wurde als Java-Applet realisiert und dient hauptsächlich zur Initialisierung der
Anwendung. XQTFrame wurde zu einem großen Teil mit dem GUI-Builder von Oracle's
JDeveloper-Entwicklungsumgebung generiert.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil V: 2. Feinentwurf
123
2.3 xqt.converter
Diese JavaBeans-Komponente besteht aus einer abstrakten Klasse und vier nicht-abstrakten
Klassen. Das dem Klassenmodel zugrunde liegende Entwurfsmuster (Builder oder Erbauer) stammt
aus [GoF 96]. Der XMLReader fungiert dabei als Direktor: er registriert sich selbst beim AElfredParser als XmlHandler (er implementiert die Schnittstelle XmlHandler). Der XMLReader enthält
mehrere Callback-Methoden, die von AElfred aufgerufen werden (so z.B. startDocument). Diese
Callback-Methoden rufen ihrerseits wiederum den gewünschten XMLConverter auf, der dann das
XML-Dokument in das von der entsprechenden Anwendung gewünschte Format konvertiert.
Nähere Informationen über die Funktionsweise dieser Komponente sind im folgenden Unterkapitel
zu finden.
com.microstar.xml.
AElfred
(XML-Parser from Microstar)
registers
director
Builder
Pattern
XMLReader
builder
product
concreteBuilder
XML2TableConverter
produces
javax.swing.table.
TableModel
XMLConverter
{abstract}
XML2TreeConverter
produces
javax.swing.tree.
TreeModel
XML2LoginConverter
produces
StringBuffer
(enthält die Login-Daten)
Abbildung V-16: Klassendiagramm der XMLConverter-Komponente
Diese Komponente unterstützt zur Zeit lediglich den XML-Parser AElfred. Zwar ist es theoretisch
leicht möglich, beliebige (SAX-)Parser einzubinden, aber die Methodenaufrufe und Rückgabewerte
unterscheiden sich oftmals (wenn auch nur minimal). Idealerweise könnte man die Komponente an
die populärsten Parser anpassen, so daß der Anwender nur noch den gewünschten Parser als BeanProperty einstellen muß.
Die Produkte, die von den konkreten Konverterklassen produziert werden, sind Objekte der JavaKlassenbibliothek. XML2TableConverter produziert ein Modell, das Swing zur Generierung einer
Tabelle verwendet. Mit dem XML2TreeConverter wird analog ein Modell zur Generierung eines
Verzeichnisbaumes produziert. Der XML2LoginConverter liest aus einem entsprechenden XMLDokument lediglich die benötigten Werte aus (z.B. Username oder Paßwort), die dann als StringParameter an die passende Methode übergeben werden.
An diesem Beispiel läßt sich das im Grundlagenteil diskutierte Problem bei der
komponentenorientierten Softwareentwicklung gut erklären. Diese Komponente wird sowohl auf
Client- als auch auf Serverseite verwendet. Der Server benötigt jedoch nur von den konkreten
Erbauern nur die XML2LoginConverter-Klasse (die wiederum vom Client nicht benötigt wird).
Also entsteht ein gewisser Code-Overhead, der sich hier zwar nicht so stark bemerkbar macht, aber
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil V: 2. Feinentwurf
124
bei einer Erweiterung der Konverter-Komponente um allgemeinere Erbauer-Klassen zu
berücksichtigen ist. Sinnvoll wäre dann eine Trennung in Client-Konverter und Server-Konverter.
2.4 com.microstar.xml.AElfred
AElfred wurde speziell für die Einbindung in Java-Applets entwickelt und besteht aus lediglich 4
Klassen und einer Schnittstelle. Im folgenden Klassendiagramm sind die AElfred -Klassen grau
unterlegt. Die Klasse XMLReader ist von mir implementierte Schnittstelle zu AElfred. Sie
implementiert den XmlHandler und registriert sich beim XmlParser, um Callback-Aufrufe zu
erhalten.
<interface>
XmlHandler
implements
HandlerBase
SAXDriver
XMLReader
registers
XmlException
XmlParser
Exception
Abbildung V-17: Klassendiagramm von AElfred
Der Microstar-Parser basiert auf der ereignisbasierten SAX-API [SAX 98] der XML-DEVMailingliste. Das Prinzip ist relativ einfach: Eine Konverter-Klasse der Anwendung registriert sich
beim Parser und ruft dessen parse-Methode mit dem entsprechenden XML-Dokument als
Argument auf. Die Konverter-Klasse muß nun bestimmte Callback-Methoden zur Verfügung
stellen, die dann vom XML-Parser aufgerufen werden.
Hauptvorteil bei der Verwendung der SAX-API ist der geringe Codeumfang und der sparsame
Umgang mit Resourcen (z.B. wird nicht der ganze – und evt. sehr umfangreiche – Strukturbaum
aufgebaut).
2.5 tdg.Perspective
Die Chart-Bean Perspective for Java von Three D Graphics [ThreeDGraphics 99] besteht aus 5
Klassen und 5 Schnittstellen. Dabei hält die Klasse Perspective die anderen Klassen und
Schnittstellen weitgehend transparent; man muß sich also nur die Methoden und Variablen dieser
Klasse näher ansehen. Perspective bietet umfangreiche Bean-Eigenschaften, die vom Query-Tool
zur Zeit nur zum Teil direkt über ein GUI-Elements geändert werden können. Auf eine detaillierte
Darstellung des Perspective-Beans in Form eines Klassendiagramms soll hier verzichtet werden.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil V: 2. Feinentwurf
125
Bislang wurde nur ein kleiner Teil der Funktionen des Chart-Beans ausgenutzt. Es ist z.B. möglich,
noch zahlreiche andere Charts (nicht nur 3D) und Parameter einzustellen, so daß eine wirklich
nutzbringende Nachbearbeitung der operativen Daten möglich ist.
Auch das Speichern der Chart-Grafiken in verschiedenen Grafikformaten (GIF, JPEG, ..) wurde
bislang nicht realisiert. Ebenso sollte es möglich sein, Grafiken nach der Bearbeitung auszudrucken
oder gleich per E-Mail zu verschicken.
2.6 xqt.server
Überblick
Nach den prinzipiellen Architekturentscheidungen waren im Laufe des Projekts beim Serverpaket
kaum noch wesentliche Änderungen nötig. Hauptgrund dafür war die Verwendung des FacadePatterns [GoF 96] in der Serverkomponente QueryBean. Diese Komponente erwartet XMLcodierte SQL-Befehle, welche zu einer einfachen XML-DTD konform sind. So muß nur noch diese
DTD decodiert und (ohne eine weitere Prüfung) die entsprechende SQL-Anfrage gegen die
Datenbank gestellt werden. Falls ein Fehler auftritt, wird der Fehler wieder XML-codiert und als
Anfrageergebnis zum Client zurückgesandt.
Klassendiagramm
Das Server-Paket besteht aus lediglich zwei Klassen und einer Schnittstelle: der Klasse
XQTServer, welche den RMI-Server startet und die Registrierung vornimmt, der Klasse
QueryAdapter, und der Schnittstelle QueryRemote, die für entfernte Methodenaufrufe zuständig
ist. Integraler Bestandteil der Serverapplikation ist die QueryBean, welche den Datenbankzugriff
transparent hält und aus (in XML-Form vorliegenden) SQL-Anweisungen XML-Dokumente
generiert. Der QueryAdapter dient als Schnittstelle zur Bean (er adaptiert die QueryBean), wobei
das Entwurfsmuster Adapter (aus [GoF 96]) verwendet wurde. Sinn dieses Entwurfsmusters ist die
Anpassung der QueryBean-Schnittstelle an die vom Client erwartete Schnittstelle. Im
QueryAdapter werden also alle für den Client relevanten Methodenaufrufe an die QueryBean
weitergeleitet.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil V: 2. Feinentwurf
126
<<interface>>
java.rmi.Remote
java.rmi.server
UnicastRemoteObject
<<interface>>
QueryRemote
QueryAdapter
adapts
AElfred
QueryBean
0..1
adapter
(XML-Parser from
Microstar)
0..1
XMLConverter
adaptee
Adapter
Pattern
XQTServer
(Schnittstelle zwischen
AElfred und XQTClient)
Abbildung V-18: Klassen-/Komponentendiagramm des Servers
In diesem Diagramm wurde darauf verzichtet, Details zum Datenbankzugriff (also die Verbindung
zur JDBC-API) einzuzeichnen. Diese Feinheiten der QueryBean-Komponente werden im
nächsten Unterkapitel detaillierter behandelt.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil V: 2. Feinentwurf
127
2.7 xqt.QueryBean
Die QueryBean-Komponente besteht aus lediglich einer Klasse, die zugleich als JDBC-Fassade
fungiert. Jeglicher Zugriff auf die Datenbank via JDBC läuft ausschließlich über diese Klasse ab.
Dabei wird kein komplettes Wrapping der JDBC-API, sondern lediglich eine Auswahl von JDBCKlassen und –Funktionen geboten.
JDBC - Subsystem
ResultSet
ResultSetMetaData
QueryBean
Statement
ResultSet
Abbildung V-19: Implementierung des Fassade-Patterns durch die QueryBean
Der zugrundeliegende Fassade-Pattern ist in [GoF 96] gut beschrieben.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil VI: 1. Verwendete Hard- und Software
Teil VI:
128
Implementierung
Software is like Entropy: it's hard to grasp, weighs nothing and obeys the Second Law of
Thermodynamics, i.e. it always increases.
Norman Augustine
1 Verwendete
Hard- und Software
1.1 Rechnerausstattung und Betriebssystem
Zur Entwicklung wurde ein Pentium II-Rechner mit 333 MHz Taktfrequenz, einem Arbeitsspeicher
von 128 MB RAM und einer 4-Gigabyte-Festspeicherplatte verwendet. Als Betriebssystem stand
Windows NT 4.0 mit dem Service Pack 3 zur Verfügung.
1.2 Entwicklungsumgebung
Zur Programmierung des Query-Tools wurde Oracle's JDeveloper 2.0 verwendet. Der JDeveloper
verwendet lizensierte Technologie von Borland und ist somit in Aufbau und Funktionsweise
weitgehend mit dem JBuilder identisch. Oracle bietet zusätzlich Wizards für die bequeme
Erstellung von Web-Anwendungen. So existieren mächtige Werkzeuge, mit denen sich problemlos
Enterprise JavaBeans, Servlets oder CORBA-Anwendungen erstellen lassen. Interessant ist auch
die vollständige Integration von SQLJ. Bei der Verwendung von SQLJ-Anweisungen innerhalb
eines Java-Programms muß so auf kein externes Tool zurückgegriffen werden.
JDeveloper 2.0 bietet die Wahl zwischen zwei Java-Versionen: Java 1.1.7 und 1.2. Da es leider
noch immer Probleme bei der Ausführung von Java 1.2-Applets in den großen Web-Browsern gibt,
wurde das Query-Tool komplett in Java 1.1.7 entwickelt.
Als Web-Browser wurden Netscape Navigator 4.6 und Internet Explorer 5.0 verwendet. Für die
korrekte Ausführung von Java-Applets war die Installation des Plug-Ins von Sun erforderlich (siehe
Kapitel "Probleme bei der Implementierung").
1.3 Applikationsserver
Als Applikationsserver wurde der Oracle Application Server (OAS) 4.0.7, als Datenbank die
Oracle Datenbank 7.3.4 verwendet. Die Installation verlief ohne Probleme; bei der Benutzung
traten keine Fehler auf.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil VI: 2. Implementierungsdetails
129
2 Implementierungsdetails
In diesem Kapitel werden die Abläufe verschiedener Operationen (Einloggen, Ausführung einer
Abfrage) anhand von Codebeispielen und Sequenzdiagrammen dargestellt. Die Codebeispiele
wurden ohne Exception-Handling abgedruckt, um die Übersichtlichkeit zu verbessern.
2.1 xqt.XMLConverter
Konvertierung eines XML-Dokumentes in eine Swing-Tabelle
Die vorliegende Implementierung arbeitet nach folgendem Schema:
Server
DB
XML-Dokument
Java-Objekt
(TableModel)
Swing-Tabelle
Abbildung VI-1: Konvertierung eines XML-Dokumentes in eine Swing-Tabelle
Problematisch (und noch weiter zu analysieren) ist die Verarbeitung von Entitäten, die nicht aus
Text bestehen (z.B. Grafiken). Es müßte eine Routine eingefügt werden, die entsprechende NichtText-Entitäten erkennt und separat abspeichert. Folgender Codausschnitt stammt aus der Klasse
XML2TableConverter und zeigt die wichtigsten Variablen und die Konstruktor-Methode:
DefaultTableModel model;
Vector columnVector;
Vector dataVector;
boolean columnNamesSet = false;
boolean rowElement = false;
boolean columnElement = false;
public XML2TableConverter()
{
model = new DefaultTableModel(); // neues Swing-TableModel
columnVector = new Vector(); // zur Speicherung der Spaltennamen
dataVector = new Vector(); // zur Speicherung der Attributwerte
}
Codebeispiel VI-1: Konstruktor von XML2TableConverter
Bei der Initialisierung wird also ein neues Swing-DefaultTableModel erstellt. Die Elementnamen
der Rückgabespalten (also die XML-Tags) werden in einem Vektor (columnVector) gespeichert
und am Ende des ersten Row-Tags (</row>) ins DefaultTableModel übernommen. Am Ende
jedes Row-Tags wird der Vektor für die Attributwerte (dataVector) mit addRow(dataVector)
dem DefaultTableModel hinzugefügt.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil VI: 2. Implementierungsdetails
130
public void endElement(String element)
{
if (element.equals("row")) {
rowElement=false;
if (columnNamesSet==false) {
model.setColumnIdentifiers(columnVector);
columnNamesSet=true;
}
model.addRow(dataVector);
dataVector = new Vector();
}
columnElement = false;
}
Codebeispiel VI-2: Callback-Methode endElement von XML2TableConverter
Die folgende Callback-Methode wird beim Parsen von Daten (also den Werten zwischen Start und
Ende eines Tags) aufgerufen:
public void convertData(String name)
{
if (name.equals("")) return;
if (columnElement==true)
dataVector.addElement(name);
}
Codebeispiel VI-3: Callbackmethode convertData von XML2TableConverter
Diese Daten werden dann in den dataVector übernommen und nach dem Durchlauf aller Spalten
in der oben beschriebenen Methode endElement in das DefaultTableModel übernommen.
Da die Swing-API komplett nach dem MFC (Model-View-Controller)-Entwurfsmuster aufgebaut
ist, ist es einfach, derartige XML-Dokumente z.B. in ein anderes Swing-Modell zu konvertieren.
Die Klasse XML2TreeConverter, die für die Darstellung von Tabellen in Form eines SwingBaumes zuständig ist, unterscheidet sich nur minimal von XML2TableConverter.
2.2 xqt.server.XQTServer
Starten des Servers
Bevor ein Client Datenbankanfragen stellen kann, muß der Server gestartet werden. Folgendes
Sequenzdiagramm illustriert den Ablauf:
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil VI: 2. Implementierungsdetails
:XQTServer
:LocateRegistry
131
localRegistry
:Registry
adaptee
:QueryBean
adapter
:QueryAdapter
createRegistry(Registry.REGISTRY_PORT)
localRegistry
rebind("QueryRemote", adapter)
Abbildung VI-2: Sequenzdiagramm des Serverstartes
Zum Starten des Servers muß die main-Methode von XQTServer ausgeführt werden. Zuerst wird
der SecurityManager gesetzt, anschließend wird versucht, eine lokale Registry zu kreieren.
Danach werden die QueryBean und die Adapterklasse QueryAdapter instanziert. Ist die
Anwendung komplett initialisiert, muß die Registry auf den neuesten Stand gebracht werden.
if (System.getSecurityManager() == null) {
System.setSecurityManager(new RMISecurityManager());
} // Setzen des SecurityManagers
Registry localRegistry =
LocateRegistry.createRegistry(Registry.REGISTRY_PORT); // kreieren
// einer lokalen Registry
adaptee = (QueryBean) Beans.instantiate(
getClass().getClassLoader(), QueryBean.class.getName());
adapter = new QueryAdapter(adaptee);
localRegistry.rebind("QueryRemote", adapter); // updaten der Registry
Codebeispiel VI-4: Starten des Servers
Ab jetzt kann der Server Client-Anfragen bearbeiten.
2.3 xqt.QueryBean
Einloggen in die Datenbank
Folgendes Sequenzdiagramm beschreibt den Ablauf des Einloggens in die Datenbank. Grundlage
ist der Anwendungsfall "Login".
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil VI: 2. Implementierungsdetails
:XQTClient
132
:LocateRegistry
remoteRegistry:Registry
db:QueryRemote
getRegistry(...)
remoteRegistry
lookup("QueryRemote")
db
login()
Abbildung VI-3: Sequenzdiagramm des Datenbank-Logins
Falls die QueryBean feststellt, daß die Daten (Username, Paßwort, Datenbank-URL, Name des
JDBC-Treibers) nicht korrekt sind, wird ein XML-Dokument mit der entsprechenden
Fehlermeldung zurückgegeben. Wenn die Daten korrekt waren, dann werden die entsprechenden
Variablen im Client gültig gesetzt. Für jede weitere Anfrage gegen die Datenbank werden dann
diese Login-Daten verwendet. Nach dem Einloggen bleibt die Verbindung nicht aufgebaut. Die
Login-Daten müssen bei jeder Datenbankanfrage wieder mit übergeben werden. Der Use-Case
"Login" dient also primär zur Verifikation der Login-Daten.
Beim Login werden zwei Methoden aufgerufen:
•
connect2Server
•
login
Die Methode connect2Server versucht zunächst, die Registry auf dem entsprechenden ServerHost zu finden. Anschließend wird die Remote-Schnittstelle QueryRemote angefordert.
Registry remoteRegistry = LocateRegistry.getRegistry(serverName); // finden
// der Registry
QueryRemote db; // Remote-Schnittstelle
db = (QueryRemote)remoteRegistry.lookup("QueryRemote");
db.login(buffer); // Übergabe der Login-Daten an den Server
Codebeispiel VI-5: Login in die Datenbank
Falls hier keine Ausnahme auftritt, geht XQTClient davon aus, daß die im Remote-Interface
definierten Methoden gültig und ausführbar sind. Die login-Methode selbst übergibt nur die LoginDaten an den Server.
Die Variable buffer enthält dabei das XML-Dokument mit den Login-Daten. Anschließend wird
automatisch die infoTables-Methode aufgerufen, die eine Anfrage gegen die Datenbank stellt, um
sämtliche dem jeweiligen Benutzer zugeordneten Tabellen und Sichten zu ermitteln. Der Ablauf
einer solchen Datenbankanfrage wird im folgenden Abschnitt beschrieben.
Datenbankzugriff
Mit der Methode connect2DB wird die Verbindung zur Datenbank aufgebaut. Hier wird zuerst der
JDBC-Treiber geladen. Die Registrierung beim Treibermanager ist beim JDBC-Treiber nicht
notwendig. Die Methode executeQuery (in der dritten Zeile) wird zur Ausführung von SQLKommandos verwendet.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil VI: 2. Implementierungsdetails
133
Class.forName(driverName); // Laden des Treibers
stmt = conn.createStatement();
rs = stmt.executeQuery(query);
meta = rs.getMetaData();
dbmeta = conn.getMetaData();
int columnCount = meta.getColumnCount();
buffer.append(generateDTD(columnCount)); // Rückgabewert mit DTD füllen
buffer.append("<database URL=\""+dbmeta.getURL()+"\">"+"\n");
buffer.append(" <table QUERY=\""+query+"\">"+"\n");
Codebeispiel VI-6: Datenbankzugriff und Generierung des XML-Dokumentes
Interessant sind dabei die untersten drei Zeilen. Hier wird der StringBuffer (für den Rückgabewert)
gefüllt. Dabei wird zuerst die generateDTD-Methode aufgerufen, die eine eigene DokumenttypDefinition für die Datenbankanfrage generiert (vgl. folgenden Abschnitt). In einer while-Schleife
werden anschließend die Ergebnisse der Anfrage in den StringBuffer übernommen:
while (rs.next()) {
buffer.append(" <row>"+"\n");
for (int i = 1; i <= columnCount; i++) {
obj = rs.getObject(i);
buffer.append(" <"+meta.getColumnName(i));
if (rs.wasNull()) {
buffer.append(" ISNULL=\"true\">");
}
else {
buffer.append("> ");
buffer.append(obj.toString());
}
buffer.append(" </"+meta.getColumnName(i)+">"+"\n");
}
buffer.append(" </row>"+"\n");
}
buffer.append(" </table>"+"\n");
buffer.append("</database>");
Codebeispiel VI-7: Übernahme des JDBC-ResultSets in das XML-Dokument
Falls ein Fehler auftritt, so wird der StringBuffer gelöscht und mit einem XML-Dokument, das die
Fehlerbeschreibung enthält, gefüllt.
Generierung einer Dokumenttyp-Definition (DTD)
Die Generierung einer DTD für die Ergebnisse von Datenbankanfragen ist aufwendig. Folgender
Codausschnitt zeigt, daß die Methode generateDTD nur für einen eingeschränkten
Anwendungsbereich geeignet ist. So sind z.B. die XML-Version und die Codierung bereits
festgelegt.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil VI: 2. Implementierungsdetails
134
buffer.append("<?xml version=\"1.0\" encoding=\"UTF-8\"?>"+"\n");
buffer.append("<-- generated by XQT -->"+"\n");
buffer.append("<!DOCTYPE database ["+"\n");
buffer.append(" <!ELEMENT database (table)>"+"\n");
buffer.append(" <!ATTLIST database URL CDATA #REQUIRED>"+"\n");
buffer.append(" <!ELEMENT table (row)*>"+"\n");
buffer.append(" <!ATTLIST table QUERY CDATA #REQUIRED>"+"\n");
buffer.append("<!ELEMENT row (");
obj = meta.getColumnName(1);
buffer.append(obj.toString());
for (int i=2; i<=columnCount; i++)
{
obj = meta.getColumnName(i);
buffer.append(", "+obj.toString());
}
buffer.append(")>"+"\n");
for (int i=1; i<=columnCount; i++)
{
buffer.append(" <!ELEMENT "+meta.getColumnName(i)
+"(#PCDATA)>"+"\n");
buffer.append(" <!ATTLIST "+meta.getColumnName(i)+"\n");
buffer.append(" TYPE CDATA #FIXED\""
+meta.getColumnTypeName(i)+"\""+"\n");
buffer.append(" NAME CDATA #FIXED \""
+meta.getColumnName(i)+"\""+"\n");
buffer.append(" ISNULL (true|false) #IMPLIED"+"\n");
buffer.append(" >"+"\n");
}
buffer.append("]>"+"\n\n");
Codebeispiel VI-8: Generierung einer DTD
Wie man sieht, wird keine Fremdschlüssel-Auflösung vorgenommen. Diese Funktionalität wurde
aus Zeitgründen weggelassen.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil VI: 3. Probleme bei der Implementierung
3 Probleme
135
bei der Implementierung
In diesem Kapitel werden einige unvorhergesehene Probleme mit Sun's Remote Method Invocation
(RMI) und der Installation des Query-Tools in Form eines JAR-Files beschrieben. Der Serverteil
der Anwendung konnte problemlos installiert und gestartet werden. Lediglich der Clientteil (also
das Java-Applet) verursachte Probleme, die zum Teil auf fehlerhafte oder unvollständige RMIUnterstützung der Web-Browser zurückzuführen waren (dem konnte mit dem Java Plug-In Abhilfe
geleistet werden). Probleme gab es auch mit der Entwicklungsumgebung JDeveloper, die wichtige
CLASS-Dateien beim Deployment nicht ins JAR-File gepackt hat.
3.1 Verschiedene Java-Versionen
Zu Beginn der Implementierungsphase wurde Borland's JBuilder 2.0 verwendet. Diese
Entwicklungsumgebung unterstützt Java 1.1.6. Problematisch dabei war, daß die Swing-Klassen zu
diesem Zeitpunkt noch dem Namensraum com.sun.java.* zugewiesen waren. Die Swing-Klassen
sind ab Java 1.1.7 dem Namensraum javax.swing.* zugeordnet. Um nicht gleich zu Beginn der
Implementierung mit inkompatiblen Namensräumen arbeiten zu müssen, wurde beschlossen, auf
Oracle's JDeveloper 2.0 umzusteigen.9
Der JDeveloper lizensiert Technologie von Borland, sieht dem Borland-Produkt JBuilder also recht
ähnlich. Die Oracle-Version bietet neben besseren Möglichkeiten der Datenbankanbindung auch
die Entwicklung in Java 1.1.7 und Java 1.2.
Auf die Implementierung in Java 1.2 wurde verzichtet, da verschiedene Probleme bei den aktuellen
VM-Implementierungen (und Plug-Ins) für die Web-Browser bekannt sind.
3.2 Installation der HTML-Seite auf dem OAS
Es hat sich herausgestellt, daß das Laden der HTML-Seite mit dem clientseitigen Applet von der
lokalen Festplatte nicht möglich ist. Aus diesem Grund wurden die Dateien im Oracle Application
Server (OAS) installiert. Dieser Teil der Installation verlief problemlos.
3.3 Netscape Navigator 4.6 und Internet Explorer 5
Plug-In für Java 1.1
Da die Version 4.6 des Navigators nur Java 1.1.5 unterstützt, muß ein spezielles Java Plug-In
installiert werden. Dieses Plug-In kann von Sun's Java-Website (http://java.sun.com)
9
Es ist natürlich möglich, andere Java-Versionen (z.B. eben 1.1.7) in den JBuilder zu integrieren.
Problematisch ist es allerdings, den integrierten GUI-Builder auf den neuen Namensraum "umzurüsten". Von
daher ist es sicher sinnvoller, auf eine Entwicklungsumgebung umzusteigen, welche die gewünschte JavaVersion bietet.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil VI: 3. Probleme bei der Implementierung
136
heruntergeladen und problemlos installiert werden. Allerdings ist zusätzlich eine Änderung im
HTML-Code der entsprechenden Web-Seite nötig. Diese Änderung kann manuell durchgeführt
werden, ist allerdings relativ kompliziert. Deshalb findet man auf derselben Website noch einen
HTML-Converter (htmlconv10-win32.exe), der vor dem Start des Applets das Plug-In startet.
Der Internet Explorer 5 unterstützt prinzipiell kein RMI, weshalb auch hier das Java Plug-In nötig
ist. Will man dieses Plug-In nicht verwenden (aus entsprechenden Newsgroups geht hervor, daß bei
der Verwendung des Plug-Ins Probleme bei der Verwendung von JavaScript auftreten können) muß
man ein spezielles RMI-Paket installieren. Dieses Paket (rmi.zip) zu finden ist relativ schwierig;
die genaue Adresse ist ftp://ftp.microsoft.com/developr/ MSDN/UnSup-ed/rmi.zip.
3.4 Probleme mit Oracle's JDeveloper 2.0
Es hat sich herausgestellt, daß das Deployment-Tool des JDeveloper nicht ganz korrekt arbeitet.
Unter Umständen muß das Deployment-Profile von Hand nachgebessert werden. Im einzelnen
mußte hinzugefügt werden:
•
Das JBCL-Paket von Borland (bei der Verwendung des GUI-Builders). Hier sollte man aber
die nicht benötigten Dateien aus dem ZIP-File entfernen.
•
Das Stub-File des QueryAdapters
•
Das Remote-Interface QueryRemote
•
Verschiedene Inner Classes von XQTFrame
•
Das JAR-File des Microstar-Parsers AElfred
•
Das JAR-File des ChartBeans Perspective
Insgesamt gesehen keine unlösbaren Probleme, auch wenn es etwas seltsam ist, daß die Installation
eines JAR-Files bei einer professionellen Entwicklungsumgebung von Oracle nicht
unproblematischer ist.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil VII: 1. Überblick über XML-Software
Teil VII:
137
Anhang
1 Überblick
über XML-Software
Die Seite http://www.stud.ifi.uio.no/~lmariusg/linker/XMLtools.html bietet eine hervorragende
Übersicht über frei verfügbare XML-Software. Die Seite wird regelmäßig auf den neuesten Stand
gebracht und kann als vollständige Übersicht bezeichnet werden. Eine weiter wichtige XML-Seite
mit
zahlreichen
Tools
ist
die
AlphaWorks-Seite
von
IBM:
http://www.alphaworks.ibm.com/tech/xmitoolkit.
Die im folgenden angegebenen Links wurden am 30. August 1999 aktualisiert und sind größtenteils
auf oben genannten Websites zu finden.
1.1 XML-Parser
Es existieren zahlreiche XML-Parser und andere XML-Tools zum Programmieren oder Editieren.
Die XML-Parser unterstützen eine breite Palette von Programmiersprachen (C, C++, Delphi, Java,
Python, ...) und können – zumeist im Sourcecode – kostenfrei aus dem Web heruntergeladen
werden.
AElfred Version 1.2a
In Java implementierter, SAX-basierter XML-Parser von Microstar. Zu finden unter [Microstar
99]. Dieser Parser ist aufgrund des geringen Codeumfangs (56k) vor allem zur Verwendung in
Java-Applets geeignet.
expat Version 1.1
Expat ist ein nicht-validierender XML-Parser von James Clark. Der Parser ist in C geschrieben; die
Java-Version heißt XP. Zu finden auf http://www.jclark.com/xml/expat.html.
Microsoft's XML-Parser
Dieser Parser wurde als COM-Komponente realisiert. Zu finden auf Microsoft's Website:
http://msdn.microsoft.com/downloads/tools/xmlparser/xmlparser.asp. Auch als Java-Version – und
hier sogar im Sourcecode – erhältlich.
Project X Technology Release 2
Der XML-Parser von Sun liegt hier im "Technology Release 2" unter dem Codenamen Java Project
X vor. Es ist anzunehmen, daß dieses Klassenpaket in zukünftigen Java-Versionen fester
Bestandteil der API wird. Der Project X-Parser ist vollständig in Java implementiert und liegt im
Quellcode vor. Der DOM-basierte Parser ist optional validierend oder nicht-validierend. Online
erhältlich unter http://developer.java.sun.com/developer/earlyAccess/xml/.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil VII: 1. Überblick über XML-Software
138
XML Parser Component for Delphi Version 2.0
Die Firma ICOM Datenverarbeitungs GmbH bietet Komponenten zur XML-Verarbeitung für
Delphi4 zum Download an. Der Quellcode dieser Komponenten ist allerdings kostenpflichtig.
Online erhältlich unter http://www.icom-dv.de/xml/.
XP Version 0.5
Java-Version von expat. Zu finden unter http://www.jclark.com/xml/xp/.
1.2 XSL-Prozessoren
Alle hier vorgestellten Prozessoren können als Java-Servlet eingesetzt werden. Damit ist die
serverseitige Konvertierung von XML in HTML kein Problem mehr.
LotusXSL
Dieser
DOM-basierte
XSL-Prozessor
ist
auf
IBM's
AlphaWorks-Seite
unter
http://www.alphaworks.ibm.com/formula/LotusXSL zu finden. Schön ist, daß auch eine ServletImplementierung erhältlich ist.
XT
XT ist der SAX-basierte XSL-Prozessor von James Clark. Auch hier ist ein Servlet-Wrapper zur
Verwendung
von
XT
als
Java-Servlet
vorhanden.
Zu
finden
auf
http://www.jclark.com/xml/xt.html.
1.3 XML-Browser
Microsoft Internet Explorer 5.0
Bester verfügbarer XML-Browser. Ein XML-Dokument kann entweder als Parse-Baum oder
HTML-Dokument angezeigt werden. Für die Transformation in HTML wird CSS und XSLT
verwendet. Online erhältlich unter http://www.microsoft.com/windows/ie/default.htm.
Mozilla (Netscape Navigator Version 5) – Milestone 9
Mozilla ist zwar online erhältlich (http://www.mozilla.org/projects/seamonkey/release-notes/),
allerdings ist diese Version noch nicht einmal eine Alpha-Release. Schade ist auch, daß trotz der
erheblichen Verspätung zum Microsoft-Browser keine neuere Technologie (XSL) angewandt wird,
sondern lediglich XML-Dokumente mit CSS in HTML umgewandelt werden.
1.4 Sonstige XML-Software
Clip! Version 1.52
Clip! ist ein schöner XML-Editor der Firma Techno2000, der inzwischen in der Version 1.52
erhältlich ist. Die kalifornische Firma bietet auch XML-Consulting zu Themen wie DTD-Design
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil VII: 1. Überblick über XML-Software
139
an. Finden kann man den XML-Parser unter http://www.t2000-usa.com/product/clip_index.html.
Es ist möglich, eine 30-Tage-Demoversion herunterzuladen.
Im Gegensatz zu vielen anderen XML-Editoren ist dies kein aufgerüsteter HTML-Editor sondern
ein professioneller XML-Editor mit Funktionen zur Validierung eines XML-Dokumentes oder zur
Generierung einer DTD aus einem wohlgeformten XML-Dokument. Programmiert wurde Clip! in
Java.
DB2XML
Sehr schönes Query-Tool von Volker Turau, mit dem Datenbankabfragen mit anschließender
XML-Generierung möglich sind. Die DB2XML-Website ist http://www.informatik.fhwiesbaden.de/~turau/DB2XML/. Dieses Tool arbeitet ähnlich wie der Prototyp meiner
Diplomarbeit und ist ebenfalls in Java geschrieben. Schwerpunkt ist allerdings die Transformation
von Anfrageergebnissen in XML; eine Report-Funktionalität ist nicht vorhanden.
RTF2XML Version 0.6
Dieser freie (GNU-Lizenz) RTF-Konvertierer ist in der Version 0.6 erhältlich. Man benötigt
allerdings noch die OmniMark-Programmiersprache (http://www.omnimark.com/) dazu. Die
Entwicklungsumgebung OmniMark Home and School ist in einer Vollversion kostenlos erhältlich.
Ausprobiert habe ich RTF2XML allerdings nicht. Erhältlich auf der Seite
http://www.xmeta.com/omlette/.
XMI Toolkit
Mit diesem Toolkit sind Konvertierungen zwischen den Case-Tools von Rational Rose und XMI
möglich. Online erhältlich unter http://www.alphaworks.ibm.com/tech/xmitoolkit.
XML Notepad Version Beta 1.5
Microsoft's XML-Editor ist noch im Beta-Stadium, läuft aber schon recht stabil. Es ist möglich,
XML-Dokumente in Baumansicht zu editieren. In Verbindung mit dem Internet Explorer 5.0 ist
eine Validierung möglich. Zu finden unter http://msdn.microsoft.com/xml/notepad/intro.asp.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil VII: 2. Überblick über EJB-Produkte
2 Überblick
140
über EJB-Produkte
2.1 Persistence PowerTier
Dieses Tool ist eine Kombination aus Applikationsserver und EJB-Entwicklungstool. Der Kern von
PowerTier ist das Mapping eines Objektmodells in Relationen einer Datenbank. Man kreiert also
einige Klassen, definiert die Beziehungen (1..*, 0..1, ...) und klickt auf "Generate Code". PowerTier
generiert den gesamten Code in einem Schritt und konfiguriert gleichzeitig den Deskriptor und
entsprechende Umgebungsvariablen. Damit ist der Zugriff auf die Datenbank vollkommen
transparent. Relationen werden wie Objekte angesprochen; die Attribute der Relation sind aus der
Sicht des Entwicklers einfach Variablen und Tupel der Relation sind Instanzen der entsprechenden
Klasse.
Das Konzept der PowerTier-Software ist sinnvoll, wenn schnelle Lösungen präsentiert werden
sollen. Der Entwicklungsaufwand ist gering und die Entwicklungszeit ist niedrig. Probleme macht
allerdings die feste Abbildung der Datenbanktabellen in Enterprise JavaBeans – nicht sehr flexibel.
Persistence-Website: http://www.persistence.com/.
2.2 BEA WebLogic Application Server
Dieser Applikationsserver ist einer der wenigen Server, die schon jetzt eine vollständige
Unterstützung der EJB-Spezifikation 1.0 (einschließlich Entity-Beans) bieten. WebLogic liefert
sogar einen komfortablen Deployment Wizard für Enterprise JavaBeans mit:
Abbildung VII-1: Tengah EJB Deployment Wizard
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil VII: 2. Überblick über EJB-Produkte
141
Leider bieteten die mitgelieferten Tools keine Unterstützung für die Entwicklung von Enterprise
JavaBeans. Auf der BEA-Website (http://www.beasys.com/) sind nicht nur zahlreiche Papers zu
finden, man kann den Webserver sogar in einer 30-Tage-Version herunterladen.
2.3 Oracle Application Server 4.0.7 (OAS)
Der OAS ist ein weitverbreiteter, stabiler und erprobter Applikationsserver für EnterpriseAnwendungen. In der Version 4.0.7 gibt es allerdings nur eine eingeschränkte Unterstützung von
Enterprise JavaBeans. So werden beispielsweise keine Entity-Beans unterstützt und auch die
Installation von EJB-Komponenten gestaltet sich schwierig. Ein Deployment Wizard wie ihn etwa
BEA Weblogic anbietet, wäre hier eine wichtige Unterstützung für den Entwickler. OracleWebsite: http://www.oracle.com/.
2.4 EJBoss Version 0.7
Der EJBoss-Server ist ein interessantes Open-Source-Projekt. Scheint allerdings noch in einem
relativ frühen Entwicklungsstadium zu sein, ist also für professionelle Projekte (noch) kaum zu
gebrauchen. Zu finden auf http://www.ejboss.org.
2.5 EJBHome Version 0.5.1
Freier EJB-Server mit schöner Dokumentation und gut lesbarem Tutorial. Erhältlich unter
http://ejbhome.iona.com.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil VII: 3. Zuordnung SQL/Java-Datentypen
3 Zuordnung
142
SQL/Java-Datentypen
Die folgende Tabelle wurde aus [OrfHar 98] entnommen.
SQL Datatype
Java Datatype
Notes
char
String
varchar
String
Typically, up to 32K characters.
longvarchar
String
Multimegabytes. Can be retrieved using Java
streams.
numeric
java.math.BigDecimal
Fixed point. Used for currency.
decimal
java.math.BigDecimal
Fixed point. Requires absolute precision. Can be
used for currency.
bit
boolean
tinyint
byte
8-bit values.
smallint
short
16-bit values.
integer
int
32-bit values.
bigint
long
64-bit values.
real
float
7 digits of mantissa precision.
double
double
15 digits of mantissa precision.
float
double
15 digits of mantissa precision.
binary
byte[]
varbinary
byte[]
Typically, up to 32 Kbytes.
longvarbinary
byte[]
Multimegabytes. Can be retrieved using Java
streams.
date
java.sql.Date
Uses ISO "yyyy-mm-dd"
time
java.sql.Time
Uses ISO "hh-mm-ss"
timestamp
java.sql.Timestamp
Provides nanosecond precision.
Tabelle VII-1: Zuordnung SQL/Java-Datentypen
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil VII: 4. Literatur
143
4 Literatur
"In der Wissenschaft lese man vorzugsweise die neuesten Werke, in der Literatur die
ältesten."
Edward George Bulwer-Lytton
Anmerkung zu den Literaturangaben: "Online erhältlich" bedeutet stets, daß die entsprechende
Literatur kostenlos heruntergeladen werden kann. Ist eine HTML-Adresse ohne diesen Zusatz
angegeben, dann ist sie lediglich als Referenz auf die Homepage bzw. die Firma der Autorin oder
des Autoren zu verstehen.
[alphaWorks 99]
Lotus XSL Prozessor v0.17.4
IBM alphaWorks 1999
Online erhältlich: http://www.alphaworks.ibm.com/tech/LotusXSL
Dieser XSL-Prozessor unterstützt den Working Draft des W3C vom 24. April 1999 [W3C 99a].
Die empfehlenswerte alphaWorks-Seite von IBM gibt EntwicklerInnen die Möglichkeit, aktuelle
IBM-Technologien einzusetzen, die IBM gerade aktuell erforscht.
[Appleton 97]
Patterns and Software: Essential Concepts and Terminology
Brad Appleton
Online erhältlich: http://enteract.com/~bradapp/docs/patterns-intro.html
[Behme 98a]
Mauerwerk en détail (Fortschritte im XML-Umfeld: Metadaten)
Henning Behme
iX-Artikel in Ausgabe 1/98
Online erhältlich: http://www.heise.de/ix/raven/Web/xml/papers.html
[Behme 98b]
Daten verpflichten (XSL: die Stil-Sprache für XML)
Henning Behme
iX-Artikel in Ausgabe 5/98
Online erhältlich: http://www.heise.de/ix/raven/Web/xml/papers.html
[Behme 98c]
Faulheit siegt (HTML-Seiten aus Datenbeständen über XML generieren)
Henning Behme
iX-Artikel in Ausgabe 11/98
Online erhältlich: http://www.heise.de/ix/raven/Web/xml/papers.html
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil VII: 4. Literatur
144
[Behme 99a]
Ein Titel ist ein Titel (Namensräume in der Extensible Markup Language)
Henning Behme
iX-Artikel in Ausgabe 5/99
Online erhältlich: http://www.heise.de/ix/raven/Web/xml/papers.html
[BehmeMintert 98a]
Klammern gehört zum Handwerk (DSSSL: XML-Dokumente fürs Web formatieren)
Henning Behme, Stefan Mintert
iX-Artikel in Ausgabe 3/98
Online erhältlich: http://www.heise.de/ix/raven/Web/xml/papers.html
[BehmeMintert 98b]
XML in der Praxis
Stefan Mintert, Henning Behme
Addison-Wesley 1998, http://www.mintert.com/xml
[BerRauSih 97]
Using UML for Modeling a Distributed Java Application
Klaus Bergner, Andreas Rausch, Marc Sihling
Technische Universität München 1997
Online erhältlich: http://www4.informatik.tu-muenchen.de
[Bosak 97]
XML, Java and the Future of the Web
Jon Bosak
Seybold Publications, O'Reilly & Associates, Inc. 1997
Online erhältlich: http://www.xml.com/xml/pub/w3j/s3.bosak.html
[Bosak 99]
The Shakespeare XML demo
John Bosak
Online erhältlich: http://www.hypermedic.com/style/shakespeare/index.htm
Hier kann man Shakespeare's Werke in XML herunterladen. Auch die Bibel und der Koran sind
erhältlich.
[Bray 98]
An Introduction to XML Processing with Lark and Laval
Tim Bray
Textuality 1998,
Online erhältlich: http://www.textuality.com/Lark/
Von dieser Seite lassen sich auch die entsprechenden Tools herunterladen.
[Brügge 98]
Componend-based Software Development
Bernd Brügge, Technische Universität München
Online erhältlich: http://wwwbruegge.in.tum.de/teaching/lectures/cbse98/schedule.html
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil VII: 4. Literatur
145
[Buschmann 98]
Pattern-orientierte Sofware-Architektur
Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal
Addison-Wesley 1998, http://www.addison-wesley.de
[Buxmann 99]
Peter Buxmann
XML – Die Extensible Markup Language
Johann Wolfgang Goethe-Universität Frankfurt, Lehrstuhl für Betriebswirtschaftslehre 1999
Booklet aus mehreren Artikeln des Competence Centers XML.
Online erhältlich: http://xml.cnec.org
Eine der besten Veröffentlichungen zum Thema XML – und noch dazu kostenlos erhältlich.
[Chappell 98]
MTS vs. EJB
David Chappel
Online erhältlich: http://www.chappellassoc.com/art5.htm
[Clark 98]
XML Resource Center
James Clark
1998, http://www.jclark.com/xml/
Kein Artikel oder Paper, sondern verschiedene freie und sehr populäre XML-Tools zum
herunterladen.
[Cleeland 99]
A Response to David Chappell's "MTS versus EJB" [Chappell 98]
Chris Cleeland
Online erhältlich: http://siesta.cs.wustl.edu/~cleeland/ejbmts-response.html
[Costello 99]
Cellphone Project
Roger Costello et al
Mitwirkende: http://www.geocities.com/ResearchTriangle/Facility/5136/contributors.html
Referenzimplementierung: http://128.191.16.34:8080/supplier/cprus/login.htm
Herausragende E-Commerce-Implementierung auf XML-Basis. Professionell und sehr aufwendig
gestaltet. Verwendet sehr ausgiebig JavaScript und XML (z.B. Drag'n Drop von Produkten in einen
Warenkorb mit automatischer Berechnung des Gesamtpreises).
[Cover 99]
The SGML/XML Web Site
Robin Cover, 1999
Online erhältlich: http://www.oasis-open.org/cover/
Referenz-Seite mit allen wichtigen Informationen, Spezifikationen, Links und Beispielen zu SGML
und XML.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil VII: 4. Literatur
146
[Englander 97]
Developing Java Beans
Robert Englander
O'Reilly & Associates, Inc., 1997, http://www.oreilly.com
[Flanagan 97]
Java in a Nutshell, 2nd edition
David Flanagan
O'Reilly & Associates, Inc., 1997, http://www.oreilly.com
Unentbehrliches Java-Handbuch aus der O'Reilly Nutshell-Edition.
[Flanagan 98]
Java Examples in a Nutshell
David Flanagan
O'Reilly & Associates, Inc., 1997, http://www.oreilly.com
Bestes erhältliches Java-Programmierhandbuch mit
Programmbeispielen. Gute Ergänzung zu [Flanagan 97].
vielen
(auf
Anhieb
lauffähigen)
[Gmeiner 99]
Objektorientierte Softwareentwicklung, Skriptum
Lothar Gmeiner, FH Karlsruhe, 1999
FH Karlsruhe, Fachbereich Informatik: http://www.fh-karlsruhe.de/fbi/html/Welcome.html
[GoF 96]
Entwurfsmuster
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (Gang of Four)
Addison-Wesley 1996, http://www.addison-wesley.de
Auch Jahre nach der Erstveröffentlichung ist das Entwurfsmusterbuch der Gang of Four (GoF) das
beste Buch zum Thema Software-Engineering überhaupt.
[Gremminger 98a]
Datenbanken, Skriptum
Klaus Gremminger, FH Karlsruhe, 1999
FH Karlsruhe, Fachbereich Informatik: http://www.fh-karlsruhe.de/fbi/html/Welcome.html
[Gremminger 98b]
Verteilte Informationssysteme, Skriptum
Klaus Gremminger, FH Karlsruhe, 1999
FH Karlsruhe, Fachbereich Informatik: http://www.fh-karlsruhe.de/fbi/html/Welcome.html
[Hobbs 97]
Datenbanken programmieren mit JDBC
Ashton Hobbs
SAMS Publishing 1997, http://www.mut.com
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil VII: 4. Literatur
147
[Holman 99]
What's the Big Deal with XSL?
G. Ken Holman
Crane Softwrights Ltd. 1999
Online erhältlich: http://www.xml.com/1999/04/holman/gkh-19990418.xml
[ICOM 99]
XML Parser Component for Delphi
ICOM Datenverarbeitungs GmbH, 1998, http://www.icom-dv.de/xml/
Delphi/C++ Komponenten zum Parsen von XML-Dokumenten.
[Idris 99]
XML and Java Tutorial Part 1,2,3
Nazmul Idris
The Bean Factory 1999,
http://developerlife.com/ibmvssunparsercomparison/sunVsIbm.html
[ISO 8879]
ISO (International Organization for Standardization).
ISO 8879:1986(E). Standard Generalized Markup Language (SGML).
First edition - 1986-10-15.
[Javaworld 99]
The state of Java Middleware, Part 2: Enterprise JavaBeans
Javaworld 1999, http://www.javaworld.com
Online erhältlich: http://www.javaworld.com/javaworld/jw-04-1999/jw-04-middleware.html
Bestes Online-Magazin zum Thema Java-Entwicklung. Die Artikel sind prinzipiell aus der
Entwicklersicht geschrieben, d.h. sie enthalten getestete Codebeispiele oder andere
Programmierhinweise.
[JEDI 99]
Projekt JEDI (Java Extraktion und Dissemination von Information)
GMD – German National Research Center for Information Technology
http://www.darmstadt.gmd.de/oasys/projects/jedi/jedid.html
[Johnson 99]
XML JavaBeans Part 1,2,3
Mark Johnson
JavaWorld 7/1999, http://www.javaworld.com
Online unter: http://www.javaworld.com/javaworld/jw-07-1999/jw-07-beans.html
[Klute 98]
JDBC in der Praxis
Rainer Klute
Addison-Wesley 1998, http://www.addison-wesley.com
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil VII: 4. Literatur
148
[Koh 99]
Sun vs. IBM XML Parser : A performance comparison
Sun Koh
The Bean Factory 1999,
http://developerlife.com/ibmvssunparsercomparison/sunVsIbm.html
[KolBusRos 96]
Discrete Mathematical Structures, 3rd edition
Bernard Kolman, Robert C. Busby, Sharon Ross
Prentice Hall 1996
[Larman 98]
Applying UML and Patterns
Craig Larman
Prentice Hall 1998
[Light 97]
Presenting XML
Richard Light
Sams.net Publishing 1997, http://www.samspublishing.com
[Macherius 97]
Revolution der Experten
Ingo Macherius
iX-Artikel in Ausgabe 6/97
Online erhältlich: http://www.heise.de/ix/raven/Web/xml/papers.html
[Microsoft 98]
Comparing Microsoft Transaction Server to Enterprise JavaBeans
Microsoft Corporation 1998
Online erhätlich: http://outlook.microsoft.com/com/wpaper/mts-ejb.asp
[Microsoft 99]
Getting Started with XSL
Microsoft Corporation 1999
Online erhältlich: http://msdn.microsoft.com/xml/XSLGuide/xsl-overview.asp
Sehr gute XSL-Einführung, die besonderen Wert auf schnelle Ergebnisse bei der Transformation
von XML in HTML legt. Schon das erste Beispiel zeigt, wie man mit XML-Daten HTML-Tabellen
erstellt und auffüllt.
[Microstar 99]
AElfred
1999, Microstar
Online erhältlich (Doku und Software): http://www.microstar.com/aelfred.html
Frei verfügbarer, SAX-basierter XML-Parser.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil VII: 4. Literatur
149
[Mintert]
siehe [BehmeMintert]
[Monson-Haefel 99]
Enterprise JavaBeans
Richard Monson-Haefel
O'Reilly 1999, http://www.oreilly.com
Bislang einziges in Deutschland erhältliches Buch über Enterprise JavaBeans (das leider erst nach
weitgehender Fertigstellung meiner Diplomarbeit erschienen ist). Neben zahlreichen (getesteten)
Codebeispielen und einer umfassenden Einführung gibt es viele Abbildungen (z.B. Sequenz- und
Zustandsdiagramme). Insgesamt gesehen ein sehr gutes Buch zum Thema, das sich vor allem mit
komplexen Beispielen und Anwendungen aus der Praxis befaßt.
[MowMal 97]
CORBA Design Patterns
Thomas J. Mowbray, Raphael C. Malveau
Wiley Computer Publishing 1997, http://www.wiley.com/compbooks
[Müller 99]
Objektorientierte Prozeßmodelle
Gunter Müller-Ettrich
Addison-Wesley, 1998 http://www.addison-wesley.de
[ObjectWatch 98a]
CORBA vs. EJB vs. MDCA: The Battle For The Middle Tier
ObjectWatch Newsletter Number 12
Online erhältlich: http://www.objectwatch.com/issue12.htm
[ObjectWatch 98b]
In The Fishbowl: Scalability in EJB and MTS
ObjectWatch Newsletter Number 18
Online erhältlich: http://www.objectwatch.com/issue18.htm
[OrfHar 98]
Client/Server Programming with Java and CORBA, 2nd edition
Robert Orfali, Dan Harkey
Wiley Computer Publishing, 1998, http://www.wiley.com/compbooks
[SAX 98]
SAX 1.0: The Simple API for XML
David Megginson und andere
Online erhältlich: http://www.megginson.com/SAX
SAX ist eine ereignisbasierte API, die von den Mitgliedern der XML-DEV Mailingliste entwickelt
wurde. Die API selbst ist Public Domain; es existieren verschiedene freie Implementierungen (z.B.
Microstar's AElfred -Parser [Microstar 99]).
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil VII: 4. Literatur
150
[SouGar 99]
Formal Modeling of the Enterprise Java Beans(tm) Component Integration Framework
Joao Pedro Sousa, David Garlan
Carnegie Mellon University (Pittsburgh),
Online erhältlich: http://pecan.srv.cs.cmu.edu/afs/cs/project/able/www/able/papers_bib.html
[Sun 99a]
JavaBeans Specification 1.01
Sun Microsystems, 1999
Online erhältlich: http://java.sun.com/beans/docs/spec.html
[Sun 99b]
Remote Method Invocation Specification
RMI Whitepapers
RMI Examples
RMI Specification
Sun Microsystems, 1999
Online erhältlich: http://java.sun.com/products/jdk/1.1/docs/guide/rmi/index.html
[Sun 99c]
Enterprise JavaBeans Specification 1.1, Public Draft 3
Sun Microsystems, 1999
Online erhältlich: http://java.sun.com/products/ejb/docs.html
[Sun 99d]
JDBC 2.0 Core API Specification
JDBC 2.0 Standard Extension Specification
Sun Microsystems, 1999
Online erhältlich: http://java.sun.com/products/jdbc/download.html
[Sun 99e]
JDBC Data Access API - For Driver Writers
Sun Microsystems, 1999
Online erhältlich: http://java.sun.com/products/jdbc/driverdevs.html
[Thomas 98a]
Enterprise JavaBeans Technology – Server Component Model for the Java Platform
Anne Thomas
Patricia Seybold Group 1998, http://www.psgroup.com
Online erhältlich: http://java.sun.com/ejb
[Thomas 98b]
Container-Managed Persistence – EJB Persistence Mechanisms
Anne Thomas
Patricia Seybold Group 1998, http://www.psgroup.com
Online erhältlich: http://www.persistence.com
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil VII: 4. Literatur
151
[Thomas 98c]
Selecting Enterprise JavaBeans Technology
Anne Thomas
Patricia Seybold Group 1998, http://www.psgroup.com
Online erhältlich: http://www.weblogic.com
[ThreeDGraphics 99]
Three D Graphics
Web: http://www.threedgraphics.com/
Hersteller des Chart-Beans "Perspective", das in der Diplomarbeit verwendet wurde.
[Tichy 99]
Entwurfsmuster, Foliensammlung
Walter Tichy
Universität Karlsruhe (TU) 1999, http://www.uni-karlsruhe.de
Online erhältlich: http://wwwipd.ira.uka.de/~tichy/
Sehr schöne Foliensammlung zur Vorlesung. Mit vielen Anwendungsbeispielen.
[TichyUngerGramberg 98]
Informatik 1, Skriptum
Walter Tichy, Barbara Unger, Oliver Gramberg
Universität Karlsruhe, http://www.uni-karlsruhe.de
Skriptum online unter http://wwwipd.ira.uka.de/~info1/
Skriptum zur Softwareentwicklung mit Java, Einführung in objektorientierte Softwareentwicklung,
Einführung ins Java-Swing/AWT-Paket und im Theorieteil unter anderem Grammatiken,
Rekursion und Datenstrukturen.
[UXF 99]
UML Exchange Format & Pattern Markup Language
Keio University, Yokohama
Online erhältlich: http://www.yy.cs.keio.ac.jp/~suzuki/project/uxf/
Regelmäßig aktualisierte UXF-Website mit allen wichtigen Dokumenten und Spezifikationen zum
Thema.
[WalshGrosso 99]
XSL Tutorial
Norman Walsh, Paul Grosso
XML Conference in Seattle, 24. März 1998
Online erhältlich: http://www.nwalsh.com/docs/tutorials/xml98/index.html
Hervorragendes XSL-Tutorial mit vollständigen XML- und XSL-Dokumenten, zahlreichen
Beispielen und Erklärungen. Beste XSL-Einführung, die mir bekannt ist.
[WillMoran 97]
Java Database Programming: Servlets & JDBC
Alan R. Williamson, Ceri L. Moran
Prentice Hall, 1997
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil VII: 4. Literatur
152
[Wired 95]
The Curse of Xanadu
Gary Wolf
Wired Magazine 1997, http://www.wired.com/wired/archive/people/ted_nelson/
[W3C 97]
Web Style Sheets
World Wide Web Consortium (W3C), http://www.w3.org
W3C 1997 (Massachusetts Institute of Technology, Institut National de Recherche en Informatique
et en Automatique, Keio University)
Online erhältlich: http://www.w3.org/Style/
Viele Links zu XSL, DSSL und CSS.
[W3C 98a]
XML 1.0 Recommendation
World Wide Web Consortium (W3C), http://www.w3.org
W3C 1998 (Massachusetts Institute of Technology, Institut National de Recherche en Informatique
et en Automatique, Keio University)
Online erhältlich: http://www.w3.org/TR/1998/REC-xml-19980210 (englisch)
http://www.mintert.com/xml/trans/REC-xml-19980210-de.html (deutsche Übersetzung)
[W3C 98b]
Document Object Model (DOM) Level 1 Specification
World Wide Web Consortium (W3C), http://www.w3.org
W3C 1998 (Massachusetts Institute of Technology, Institut National de Recherche en Informatique
et en Automatique, Keio University)
Online erhältlich: http://www.w3.org/TR/REC-DOM-Level-1/
[W3C 99a]
Extensible Stylesheet Language (XSL) Specification
World Wide Web Consortium (W3C), http://www.w3.org
W3C 1998 (Massachusetts Institute of Technology, Institut National de Recherche en Informatique
et en Automatique, Keio University)
Online erhältlich: http://www.w3.org/TR/WD-xsl/
[W3C 99b]
XSL Transformations (XSLT) Version 1.0
World Wide Web Consortium (W3C), http://www.w3.org
W3C 1998 (Massachusetts Institute of Technology, Institut National de Recherche en Informatique
et en Automatique, Keio University)
Online erhältlich: http://www.w3.org/TR/WD-xslt
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil VII: 4. Literatur
153
[W3C 99c]
Document Object Model (DOM) Level 2 Specification
World Wide Web Consortium (W3C), http://www.w3.org
W3C 1998 (Massachusetts Institute of Technology, Institut National de Recherche en Informatique
et en Automatique, Keio University)
Online erhältlich: http://www.w3.org/TR/WD-DOM-Level-2/
[XMI 99]
DSTC's Meta-Object Facility Publications
Online erhältlich: http://www.dstc.edu.au/Research/Projects/MOF/Publications.html
Informationen zum XMI-Format (XML-Based Metadata Interchange).
[XML/EDI 99]
Guidelines for using XML for Electronic Data Interchange
XML/EDI-Group
http://www.geocities.com/WallStreet/Floor/5815/guide.htm
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil VII: 5. Glossar
154
5 Glossar
Hier sind einige ausgewählte Middleware-Begriffe zusammengestellt. Ich habe mich hier auf die
englischsprachigen Bezeichnungen beschränkt.
Application Server
Ein Applikationsserver (z.B. Oracle Application Server) ist eine Serversoftware, die eine
Infrastruktur zur Installation von Server-Komponenten (z.B. Enterprise JavaBeans oder HTMLSeiten) bietet und entsprechende Dienste über ein Netzwerk zur Verfügung stellt.
Bean-managed Persistence
Eine EJB verwaltet ihren Zustand selbst (im Unterschied zu Container-managed persistence).
Component Transaction Manager (CTM)
Komponentenbasierter Transaktions-Manager, der verteilte Transaktionen koordiniert.
Container-managed Persistence
Die Zustandsverwaltung einer EJB wird vom EJB-Container bzw. vom EJB-Server übernommen.
CORBA
OMG-Standard für verteilte Objektdienste. Akronym für Common Object Request Broker
Architecture.
CTM
Component Transaction Manager
DCOM
Microsoft's Modell für verteilte Objektdienste. Akronym für Distributed Component Object Model.
DTD
Dokumenttyp-Definition.
EJB
Enterprise JavaBeans.
Enterprise JavaBeans
Sun's Standard für Serverkomponenten.
Entity-Bean
Eine EJB, die Daten einer Datenbank repräsentiert (vgl. Session-Bean).
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil VII: 5. Glossar
155
IIOP
CORBA-Protokoll zur Kommunikation verschiedener ORBs. Akronym für Internet Inter-ORB
Protocol.
Java Naming and Directory Interface (JNDI)
Java-API zum Zugriff auf verteilte Dienste.
JDBC
Java-API zum Datenbankzugriff. Akronym für Java Database Connection.
JNDI
Java Naming and Directory Interface.
JVM
Java Virtual Machine.
Middleware
Serversoftware, die für die Kommunikation zwischen Client- und Serverapplikationen inklusive
Datenbankzugriff zuständig ist. Beispiele: EJB, CORBA, RMI.
OMG
Organisation, die Standards für objektorientierte Anwendungen entwickelt. Akronym für Object
Management Group.
Persistence
Erhalten eines bestimmten Zustandes über längere Zeit. Üblicherweise wird für das Speichern eines
Zustandes eine Datenbank benutzt.
RMI
Java-Protokoll für einen entfernten Methodenaufruf. Akronym für Remote Method Invocation.
RMI over IIOP
Verwendung des CORBA-Protokolls IIOP von einer RMI-Schnittstelle aus.
Session-Bean
Eine EJB, die normalerweise Geschäftsprozesse implementiert und Sitzungen mit Clients
verwaltet.
Skeleton
Serverkomponente, die entfernte Methodenaufrufe entgegennimmt.
SQLJ
Standard für die Einbettung von SQL-Befehlen in ein Java-Programm
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil VII: 5. Glossar
156
Stub
Clientseitiges Gegenstück zum Skeleteon. Dient als Schnittstelle zwischen Client-Software und
dem serverseitigen Skeleton.
XML
Extensible Markup Language.
XSL
Extensible Stylesheet Language. Stylesheet-Sprache für XML.
XSLT
Untermenge von XSL zur Transformation von Strukturbäumen.
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil VII: 6. Index
157
6 Index
3
3-stufige Architekturen ................................................. 57
A
Application Assembler.................................................. 59
B
EJB Server.....................................................................61
EJB-API ........................................................................69
EJB-Transaktionsmodell ...............................................67
Electronic Data Interchange ..........................................17
Embedded SQL .............................................................73
Entity-Beans ..................................................................66
Entwicklung von Beans.................................................46
Entwurfsziele.................................................................23
ereignisbasierte API ......................................................31
ESQL.............................................................................73
Extensible Stylesheet Language ..............................25, 26
F
baumbasierte API.......................................................... 32
beanverwalteter Persistenz............................................ 67
Beziehungen zwischen einem EJB-Server und einem EJBContainer.................................................................. 60
C
Call Level Interface....................................................... 74
Cascading Style Sheet................................................... 25
CLI................................................................................ 74
Component Transaction Monitors................................. 55
containerverwaltete Persistenz ...................................... 67
CSS ............................................................................... 25
CTM.............................................................................. 55
D
Definitionen von Enterprise JavaBeans ........................ 55
Deployment Descriptor ................................................. 64
Document Object M...................................................... 31
Document Object Model............................................... 32
Document Style Semantics and Specification Language25
Dokument ..................................................................... 19
Dokumenttyp-Definition............................................... 30
DOM....................................................................... 31, 32
DSSSL .......................................................................... 25
DTD ........................................................................ 24, 30
dynamic class loading ................................................... 52
dynamisches Laden von Klassen .................................. 52
E
EDI................................................................................ 17
Eigenschaften................................................................ 45
Eigenschaften mit Constraints ...................................... 46
einwertige Eigenschaften .............................................. 46
EJB Container ............................................................... 61
EJB Provider................................................................. 59
Framework ....................................................................40
G
gebunde Eigenschaften..................................................46
Gebunde Eigenschaften .................................................46
Generic Markup.............................................................21
Grammatik.....................................................................30
Gültigkeit.......................................................................31
H
Home Interface ..............................................................63
HTML............................................................................21
Hypertext.......................................................................16
I
indizierte Eigenschaften ................................................46
Indizierte Eigenschaften ................................................46
Installation von RMI-Anwendungen .............................52
Introspektion..................................................................44
J
JAR................................................................................47
Java Database Connectivity...........................................73
JavaBeans ......................................................................43
JDBC .............................................................................73
JDBC-API .....................................................................77
JDBC-Treibertypen .......................................................75
K
Klassenbibliothek ..........................................................40
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences
Teil VII: 6. Index
158
Komponente.................................................................. 40
Komponenten................................................................ 39
Komponentenbibliotheken ............................................ 41
Komponenten-Bibliotheken .......................................... 41
Komponenten-Frameworks........................................... 41
M
Manifest-File................................................................. 47
Metasprache .................................................................. 23
Migration von Legacy-Anwendungen zu Java-basierten
Systemen .................................................................. 57
N
Nachteile von EJB ........................................................ 59
Nelson........................................................................... 16
O
Stylesheet Node Tree.....................................................28
System Administrator....................................................60
T
Templates ......................................................................28
Transaktionen und Stored Procedures ...........................80
Transaktionsverhalten von Enterprise JavaBeans..........68
Transformation ..............................................................26
U
UML..............................................................................35
UML Exchange Format .................................................36
Unified Modeling Language..........................................35
Unterschiede zwischen JavaBeans und Enterprise
JavaBeans .................................................................56
UXF...............................................................................36
V
ODBC ........................................................................... 74
Verarbeitung von XML-Dokumenten ...........................31
visuelle Präsentation von Komponenten........................43
Visuelle Programmierung..............................................44
P
Programmieren mit JDBC............................................. 78
Programmierung von EJBs ........................................... 71
Properties ...................................................................... 45
W
Wartung von Software...................................................38
Wiedereintrittsinvarianz von Entity-Beans....................67
Wohlgeformtheit ...........................................................31
R
Reflection...................................................................... 45
Reflexion....................................................................... 44
Remote Method Invocation........................................... 48
Result Node Tree .......................................................... 28
RMI............................................................................... 48
RMI Registry ................................................................ 49
RMI-API ....................................................................... 50
Rollen bei der EJB-Entwicklung................................... 59
S
SAX ........................................................................ 31, 33
Server/Container Provider............................................. 60
Session-Beans ............................................................... 65
SGML ........................................................................... 22
Simple API for XML .............................................. 31, 33
Source Node Trees........................................................ 28
SQLJ ............................................................................. 73
Strukturelemente ........................................................... 21
Stylesheet ...................................................................... 25
X
Xanadu ..........................................................................16
XMI...............................................................................36
XML..............................................................................16
XML Metadata Interchange...........................................36
XML-Instanz .................................................................26
XML-Parser...................................................................31
XML-Strukturbaum.......................................................27
XSL .........................................................................25, 26
XSLT.............................................................................26
Z
Zustandsbehaftetete Session-Beans ...............................65
Zustandslose Session-Beans ..........................................65
Fachhochschule Karlsruhe – Karlsruhe University of Applied Sciences