Meine Diplomarbeit zum Thema "Entwicklung eines webbasierten CORBA-Clients mit Java Servlets im Umfeld betrieblicher Standardsoftware". Vorgelegt dem Fachbereich Wirtschaftsinformatik der Universität-Gesamthochschule Siegen zum Erlangen des Grades Diplom Wirtschaftsinformatiker im Jahr 2002.

1. Diplomarbeit
Entwicklung eines webbasierten CORBA-Clients mit
Java Servlets im Umfeld betrieblicher
Standardsoftware
vorgelegt
dem Fachbereich Wirtschaftsinformatik
der Universit¨t-Gesamthochschule Siegen
a
zum Erlangen des Grades Diplom Wirtschaftsinformatiker
von
Markus M¨ller
o
Hagener Str. 404
57223 Kreuztal
Matrikelnummer 539623
Betreuender Professor:
Prof. Dr. Bernd Freisleben
Betreuende Firma:
Varial Software AG, Hauptstrasse 18, 57074 Siegen
Bearbeitungszeitraum: 2.5.2002 - 2.9.2002

2. INHALTSVERZEICHNIS i
Inhaltsverzeichnis
1 Einleitung 3
2 Technologie 5
2.1 Java Servlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Entstehungsgeschichte . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2 Alternative Ans¨tze . . . . . . . . .
a . . . . . . . . . . . . . . . . . . . 5
2.1.3 Die Zukunft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 Die OMG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.2 Object Management Architecture . . . . . . . . . . . . . . . . . . . . . 12
2.2.3 Interface Definition Language . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.4 Alternative Ans¨tze . . . . . . . . .
a . . . . . . . . . . . . . . . . . . . 16
2.2.5 Vorteile von CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3 Verbindung von Java Servlets und CORBA . . . . . . . . . . . . . . . . . . . 25
3 Varial World Edition 26
3.1 Leistungsumfang VWE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Das Web-Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4 Anforderungen an das Web-Interface 31
4.1 Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Internationalisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
¨
4.2.1 Ubersetzung der sprachlichen Inhalte . . . . . . . . . . . . . . . . . . . 38
4.2.2 Zeichens¨tze . . . . . . . . . . . . .
a . . . . . . . . . . . . . . . . . . . 40
4.2.3 L¨nderspezifische Formate . . . . . .
a . . . . . . . . . . . . . . . . . . . 41
4.2.4 Lokalisierung der fachlichen Inhalte . . . . . . . . . . . . . . . . . . . . 41
4.3 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3.1 Verteiltes Rechnen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3.2 Verteilung von Server-Last . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3.3 Komprimierte Inhalte . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3.4 Zwischenspeicherung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4 Anpassbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4.1 Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4.2 Corporate Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.5 Analogie zu bestehender VWE-Ober߬che . a . . . . . . . . . . . . . . . . . . . 47
5 Konzeptioneller Neuentwurf eines Web-Interfaces 50
5.1 Multi-Tier-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.2 Das MVC-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.2.1 Model – Das Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2.2 View – Die Ansicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2.3 Controller – Die Steuerung . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2.4 Zusammenspiel der Komponenten . . . . . . . . . . . . . . . . . . . . 52

3. INHALTSVERZEICHNIS ii
5.2.5 Vorteile von MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.3 HTTP und das Session-Problem . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.4 Business-Objekt und Enumerations . . . . . . . . . . . . . . . . . . . . . . . . 55
5.5 Das Callback-Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.5.1 Daten sammeln und erst komplett an Browser ubergeben¨ . . . . . . . 68
5.5.2 Server Push . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.5.3 Client Pull . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.5.4 Client Pull + DHTML . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.5.5 Daten ungepuffert schreiben . . . . . . . . . . . . . . . . . . . . . . . . 70
5.5.6 Daten ungepuffert schreiben + viele kleine Tabellen . . . . . . . . . . 70
5.5.7 Daten ungepuffert schreiben + Tabelle imitieren . . . . . . . . . . . . 71
5.5.8 Asynchrones Warten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.6 Tabsheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.7 Multimedia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.7.1 MIME-Typen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.7.2 Bilderzeugung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.7.3 Excel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.7.4 WAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.8 Darstellung mit verschiedenen Browsern . . . . . . . . . . . . . . . . . . . . . 79
6 Die VWE-Web-API 82
6.1 Das Packet com.varial.base . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.1.1 VServlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.1.2 VListServlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.1.3 VDetailServlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.1.4 VSelectServlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.1.5 VChartServlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.1.6 VState . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.1.7 VListState . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.1.8 VDetailState . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.1.9 VSelectState . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.1.10 VContext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.1.11 Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.1.12 BO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.1.13 VBean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
6.1.14 VException . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
6.1.15 TempData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.1.16 AbstractCallback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
6.1.17 VListStateThread . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
6.1.18 ExceptionHelper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
6.1.19 StringMapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
6.1.20 VCurrency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.1.21 VNumber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
6.1.22 VDate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
6.2 Das Packet com.varial.translation . . . . . . . . . . . . . . . . . . . . . . . . . 110

4. INHALTSVERZEICHNIS iii
6.2.1 Translator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.2.2 TranslatorCache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
6.3 Das Packet com.varial.gui . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
6.3.1 GuiHelper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
6.3.2 VGuiBean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
6.3.3 LabeledTextField . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
6.3.4 LabeledNumberField . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
6.3.5 LabeledCurrencyField . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
6.3.6 LabeledTextField . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
6.3.7 LabeledMemo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
6.3.8 LabeledButtonTextField . . . . . . . . . . . . . . . . . . . . . . . . . . 129
6.3.9 LabeledCheckBox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
6.3.10 LabeledRadioButton . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
6.3.11 LabeledComboBox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
6.3.12 LabeledEditableComboBox . . . . . . . . . . . . . . . . . . . . . . . . 130
6.3.13 LabeledListBox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
6.3.14 LabeledListBoxButtons . . . . . . . . . . . . . . . . . . . . . . . . . . 131
6.3.15 LabeledGrid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
6.3.16 GridBean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
6.3.17 DivGridBean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
6.3.18 GraphBean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
6.3.19 ImageBean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
6.3.20 TabSheetBean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
6.3.21 MenuBarBean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
6.3.22 MenuEntryTreeBean . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
6.3.23 MenuEntry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
6.3.24 MenuBarComponentInterface . . . . . . . . . . . . . . . . . . . . . . . 139
6.3.25 SelectCompanyBean . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
6.3.26 SelectOkCancelButtonBean . . . . . . . . . . . . . . . . . . . . . . . . 140
6.3.27 SelectSearchBean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
6.3.28 JavaScriptBean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
6.3.29 JavaScriptHelper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
6.3.30 Theme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
6.4 Das Packet com.varial.taglib . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
6.4.1 varial.tld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
6.4.2 VComponent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
6.4.3 VTextField . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
6.4.4 VNumberField . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
6.4.5 VCurrencyField . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
6.4.6 VDateField . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
6.4.7 VMemo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
6.4.8 VButtonTextField . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
6.4.9 VCheckBox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
6.4.10 VRadioButton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
6.4.11 VComboBox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

5. INHALTSVERZEICHNIS iv
6.4.12 VEditableComboBox . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
6.4.13 VListBox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
6.4.14 VGrid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
6.4.15 VGraph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
6.4.16 VImage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
6.4.17 Empty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
6.4.18 Vspacer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
6.4.19 TabSheetControl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
6.4.20 TabSheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
6.4.21 MenuBar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
6.4.22 SelectOkCancel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
6.4.23 SelectSearch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
6.4.24 HeadLine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
6.4.25 LastChange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
6.4.26 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
6.4.27 CssLink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
6.4.28 HiddenField . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
6.4.29 HiddenExtraField . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
6.4.30 Translator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
6.4.31 LanguageString . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
7 Beispiel f¨r die Verwenung der VWE-Web-API
u 163
7.1 Vorbereitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
7.1.1 Die IDL-Beschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
7.1.2 Die Server-Funktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
7.1.3 Die Client-BOs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
7.1.4 Die Enumerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
7.2 Listen-Ansicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
7.2.1 Das ListServlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
7.2.2 Der ListState . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
7.2.3 Die JSP-Listen-Seite . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
7.2.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
7.3 Detail-Ansicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
7.3.1 Das DetailServlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
7.3.2 Die JSP-Detail-Seite . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
7.3.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
7.4 Auswahl-Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
7.4.1 Das SelectServlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
7.4.2 Der SelectState . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
7.4.3 Die JSP-Auswahl-Seite . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
7.4.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
7.5 Abschluss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
8 Aufbau und Bedienung der Web-Ober߬che
a 196

6. INHALTSVERZEICHNIS 1
9 Zusammenfassung und Ausblicke 197
A Anhang 199
Tabellenverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
A.1 Abbildungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
A.2 Glossar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

7. Vorwort
Die vorliegende Diplomarbeit beschreibt die Entwicklung einer Internet-Schnittstelle f¨r
u
das ERP-System Varial World Edition“. Angefertigt wurde die Arbeit bei der Varial
”
Software AG in Kaan Marienborn, bei der ich bereits zuvor als Werkstudent besch¨ftigt
a
war. Aus meinem Interesse sowohl an modernen Internet-Technologien als auch an der Java-
¨
Programmierung und den strategischen Uberlegungen des Unternehmens Varial entstand
die Idee, eine Anbindung der World Edition f¨r das World Wide Web zu konstruieren. Der
u
Grundstein f¨r VWE-Web war gelegt.
u
Die Arbeit ist schließlich recht umfangreich ausgefallen, da sie neben den verwendeten
Technologien sowohl die Bedienung des Web-Interfaces als auch dessen Entwicklung be-
schreibt. Durch die Dokumentation aller wichtigen Klassen und die beispielhafte Umsetzung
einer Anwendung, soll es dem Leser erm¨glicht werden, die entwickelte API selbstst¨ndig zu
o a
verwenden und mit ihrer Hilfe weitere Funktionalit¨ten der World Editon zu implementieren.
a
Danken m¨chte ich Herrn Prof. Freisleben f¨r die Betreuung der Diplom-Arbeit. Ein
o u
besonderer Dank geht ebenso an meine Kolleginnen und Kollegen der Varial Software AG,
die mir mit Rat und Tat zu Seite standen und die durch ihr freundliches Miteinander ein
sehr gutes Arbeitsklima f¨r das Heranreifen des Projekts schufen.
u
Weiterhin ist es mir ein Bed¨rfnis, Ina daf¨r zu danken, dass sie ihre Freizeit f¨r das
u u u
Korrekturlesen der Arbeit opferte. Auch bei meinen Kommilitonen Maik, der neben der
Korrektur f¨r viele interessante fachliche Diskussionen zur Stelle war, und Tobi f¨r seine
u u
Erkl¨rungen zu DCOM, SOAP & Co m¨chte ich mich an dieser Stelle herzlich bedanken.
a o
Ihr wart mir eine große Hilfe.
Ebenfalls haben die vielen unz¨hligen User diverser Internet-Foren, wie vorzugweiße dem
a
SELFHTML-Forum, zum Gelingen dieser Arbeit beigetragen. Danke f¨r die vielen guten
u
Ratschl¨ge, Meinungen und Kritiken.
a
Außerdem sei meinen Mitmenschen gedankt, die mich in den letzen Monaten unterst¨tzt, u
gelobt, ertragen und getr¨stet haben und mit ihrem Verst¨ndnis den n¨tigen Freiraum f¨r
o a o u
die Erstellung der Arbeit gegeben haben und damit deren Realisierung erst erm¨glichten. Zu
o
guter Letzt gilt mein besonderer Dank nat¨rlich Julia, die mir nicht nur in Zeiten technischer
u
Schwierigkeiten die n¨tige Hardware zur Verf¨gung stellte, sondern auch mit einem Mix
o u
u u u ¨
aus R¨cksicht und Zuneigung entscheidende Motivationssch¨be f¨r das Uberwinden mancher
Tiefphase und f¨r die Fertigstellung der Arbeit lieferte. Danke!
u

8. 1 Einleitung
Die Industrie befindet sich zur Zeit im Wandel. Die traditionelle Wirtschaft bewegt sich
hin zur Digital Economy“, einem System, in dem alle Teilnehmer der Wertsch¨pfungskette
o
”
auf digitalem Wege, mit Hilfe des Internets, kommunizieren und ihre Transaktionen uber
¨
das World-Wide-Web ausf¨hren. Das Internet etabliert sich immer mehr als das globale
u
Informations- und Kommunikationsmedium schlechthin.
W¨hrend vor Jahren das Internet lediglich statische Inhalte zur Verf¨gung stellte, nimmt
a u
mittlerweile mehr und mehr dynamischer Content das Netz ein. Das Potential reicht jedoch
weit uber die M¨glichkeiten eines einfachen eShops oder eines G¨stebuchs hinaus. So bieten
¨ o a
sich auch einem modernen ERP-System interessante M¨glichkeiten, das Internet f¨r eine
o u
unternehmens- und weltweite Abwicklung von Gesch¨ftsf¨llen zu nutzen.
a a
Diese Diplomarbeit beschreibt hierzu die Entwicklung eines Systems, mit dessen Hilfe
webbasierte Benutzerschnittstellen f¨r das ERP-System Varial World Edition“ (VWE)
u
”
erstellt werden k¨nnen.
o
VWE ist eine von dem Unternehmen Varial Software AG entwickelte ERP-Software.
Hierbei handelt es sich um eine verteilte Anwendung, die mit CORBA realisiert wird. Der
Server wird in Java implementiert, w¨hrend clientseitig C++ zum Einsatz kommt.
a
Im Rahmen der Diplomarbeit wird die Software um die M¨glichkeit erweitert, auf aus-
o
gew¨hlte Datenbest¨nde mittels Web-Browser zugreifen zu k¨nnen. Auf diese Weise wird
a a o
es dem Benutzer erm¨glicht, VWE via Intra-, Extra- oder Internet von jedem beliebigen
o
Arbeitsplatz zu nutzen. Hierbei kommen Java Servlets zum Einsatz.
Die Arbeit gliedert sich in neun Abschnitte. Nach dieser Einf¨hrung werden im zweiten
u
Kapitel zun¨chst die beiden Techniken CORBA und Java Servlets vorgestellt. Hierbei werden
a
insbesondere Alternativen zu diesen Technologien aufgezeigt und diskutiert. Die Vorteile des
verwendeten L¨sungsansatzes werden herausgestellt und die Entscheidung f¨r CORBA und
o u
Java Servlets begr¨ndet.
u
Kapitel 3 beschreibt das ERP-System VWE. Es wird ein Einblick in den Leistungsumfang
und den Aufbau von VWE gegeben. Außerdem wird gezeigt, wie ein Web-Interface die
bestehenden Funktionalit¨ten sinnvoll erweitern bzw. erg¨nzen kann.
a a
Das vierte Kapitel fasst anschließend alle Anforderungen, die an eine Browser-Oberfl¨che
a
gestellt werden, zusammen. Kapitel 5 zeigt, wie diese Anforderungen umgesetzt wurden und
welche Fragestellungen und Probleme sich bei der Entwicklung ergaben.
Kapitel 6 erl¨utert die Komponenten, die zur Realisierung entwickelt wurden. Zentrale
a
Packete werden aufgef¨hrt und die Funktionen der Klassen im Einzelnen erl¨utert.
u a
Im siebten Kapitel wird aufgezeigt, wie die entwickelten Komponenten zur Realisierung
eines Use-Cases eingesetzt werden k¨nnen. Hier wird eine kleine Anwendung beispielhaft
o

9. 4
umgesetzt.
Kapitel 8 widmet sich der Bedienung der Web-Ober߬che. Der Aufbau sowie die
a
Handhabung des Web-Interfaces werden erl¨utert.
a
Das abschließende neunte Kapitel fasst noch einmal alle gewonnenen Erkenntnisse
zusammen und bietet einen Ausblick auf zuk¨nftige Entwicklungen.
u

10. 2 Technologie
2.1 Java Servlets
Servlets sind Java-Programme, die auf einem Web-Server laufen.
W¨hrend Java urspr¨nglich f¨r den Einsatz in Embedded-Systemen entwickelt wurde, wuchs
a u u
sp¨ter das Interesse an Java durch den Einsatz als Applets. Bei Applets handelt es sich um
a
Java-Code, der in einem Web-Umfeld clientseitig, also im Browser, ausgef¨hrt wird. Dank
u
Javas Plattformunabh¨ngigkeit ist der Byte-Code auf jedem Betriebssytem ausf¨hrbar. Dies
a u
f¨hrte zusammen mit der Tatsache, dass eine solche Funktionalit¨t im Browser bislang
u a
unbekannt war, zu einem regelrechtem Java-Boom.
Mit Java-Servlets halten Java und seine Vorteile nun auch Einzug auf der Serverseite.
Was Applets f¨r den Browser sind, sind Servlets f¨r den Web-Server. Prinzipiell sind Servlets
u u
keinesfalls auf die Behandlung von HTTP-Anfragen beschr¨nkt. Denkbar w¨re auch, ein
a a
Servlet in einen Mail- oder FTP-Server einzubetten, um dessen Funktionalit¨t zu erweitern.
a
In der Praxis bilden solche Einsatzm¨glichkeiten jedoch eher die Ausnahme, so dass Servlets
o
uberwiegend f¨r HTTP-Anfragen verwendet werden.
¨ u
2.1.1 Entstehungsgeschichte
Urspr¨nglich bestand die Aufgabe des Internets darin, Informationen in Form von statischen
u
Seiten zur Verf¨gung zu stellen. Der Web-Server konnte die Anfrage eines Clients durch
u
¨
die einfache Ubermittlung vorgefertigter Dokumente befriedigen. Mittlerweile hat sich das
Internet jedoch stark gewandelt, so dass die Bereitstellung statischer Seiten u.U. nicht mehr
ausreichend ist, sondern dass f¨r jede Anfrage eine andere Seite generiert werden muss. Es
u
gibt mehrere Gr¨nde f¨r die Generierung dynamischer Seiten:
u u
• Die Web-Seite basiert auf Benutzereingaben
Die Ergebnisseiten von Suchmaschinen sind hierf¨r ein typisches Beispiel. Je nach Such-
u
begriff wird dem Benutzer eine andere Seite pr¨sentiert.
a
• Die Web-Seite beinhaltet Daten, die sich oft ¨ndern
a
Ein Beispiel hierf¨r ist eine Unternehmensseite, die den aktuellen Aktienkurs angibt,
u
oder die Web-Seite einer Zeitung, die die neusten Schlagzeilen und den Wetterbericht
darstellt.
• Die Web-Seite verwendet Informationen aus serverseitigen Quellen
Typisches Beispiel hierf¨r w¨re ein eCommerce-Seite, die eine Liste von Produkten und
u a
deren Preise aus einer Datenbank generiert.
Auf Grund der neuen Anforderungen wurde nach neuen L¨sungsans¨tzen, die dem Wunsch
o a
nach dynamischen Web-Seiten entsprachen, gesucht.
2.1.2 Alternative Ans¨tze
a
Common Gateway Interface Das Common Gateway Interface (CGI) war die erste Techno-
logie, die das Erzeugen von dynamischen Web-Seiten erm¨glichte.
o
5

11. 2.1 Java Servlets 6
Bei CGI nimmt der Web-Server wie gewohnt eine Client-Anfrage entgegen, startet dann aber
ein externes Programm und leitet die Bearbeitung an dieses Programm weiter. Das Programm
generiert daraufhin die Antwortseite. Diese Seite kann nun vom Web-Server an den Client
gesendet werden.
Mit CGI k¨nnen dynamsiche Seiten in fast jeder Programmiersprache erzeugt werden. CGI
o
ruft lediglich ein Programm auf und erwartet eine R¨ckgabe, die an den Browser geschickt
u
wird. In welcher Sprache das Programm geschrieben ist spielt hierbei keine Rolle. Allerdings
hat sich Perl als Programmiersprache durchgestetzt, da Perl m¨chtige Befehle zur Verar-
a
beitung von Texten bereitstellt (u.a. Regular Expressions), die sich im Umfeld von CGI als
große Hilfe herausstellen. Auf diese Weise war es erstmals m¨glich, dynamsiche Seiten zu
o
erzeugen. Schnell verbreitete sich CGI und immer mehr Web-Server stellten dieses Interface
zur Verf¨gung.
u
Der Nachteil von CGI ist jedoch, dass nicht gerade sparsam mit Serverresourcen umgegangen
wird. F¨r jede Anfrage wird das verarbeitende Programm als eigener Prozess gestartet. Bei
u
hochfrequentierten Servern kann es somit vorkommen, dass viele Prozesse gleichzeitig laufen,
was schnell zu einer hohen Serverlast f¨hren kann. Um z.B. ein Perl-Skript auszuf¨hren, muss
u u
bei CGI jedesmal der Perl-Interpreter gestartet werden. Abbildung 1 zeigt die Funktionsweise
von CGI.
Abbildung 1: Web-Server mit CGI
Ein anderer Nachteil von CGI ist, dass CGI-Programme nicht mit dem Server intera-
gieren k¨nnen, da sie in einem eigenen Prozess gestartet werden. Ein CGI-Skript kann so
o
beispielsweise nicht in das Logfile des Servers schreiben. Außerdem k¨nnen CGI-Skripte nur
o
recht schwer Daten untereinander austauschen oder zwichen zwei Anfragen persistent halten,
da der Prozess nach Abarbeitung der Anfrage beendet wird.
Um die Performance von CGI zu verbessern wurden mehrere L¨sungsans¨tze entwickelt:
o a
Die Firma Open Market entwickelte eine Alternative namens FastCGI, die im Gegensatz zu
CGI ein Programm immer im selben Prozess laufen l¨sst. So wird nur noch ein Prozess pro
a
Programm, und nicht mehr pro Anfrage gestartet. Dies f¨hrt zwar zu einer Performance-
u
Verbesserung, erzeugt u.U. aber immer noch eine Reihe von Prozessen auf dem Server. Ab-
bildung 2 zeigt einen Web-Server mit FastCGI-Unterst¨tzung.
u

12. 2.1 Java Servlets 7
Speziell f¨r Perl-Skripte auf dem Apache-Server wurde mod perl entwickelt. Bei mod perl
u
Abbildung 2: Web-Server mit FastCGI
handelt es sich um ein Modul f¨r den Apache-Server, das den Perl-Interpreter direkt in den
u
Server einbettet. Perl-Skripte laufen so wesentlich schneller als zuvor. Dieser Ansatz ist jedoch
ausschließlich f¨r Perl-Skripte, die auf dem Apache-Server laufen, geeignet.
u
Server-Extension-API Einige Serverhersteller entwickelten sog. Extension-APIs f¨r ihre
u
Web-Server. Auf diese Weise k¨nnen Server um weitere Funktionalit¨ten erweitert werden.
o a
Beispiele hierf¨r sind ISAPI f¨r Microsofts Internet Information Server (IIS) oder WAI (ur-
u u
spr¨nglich ver¨ffentlicht unter der Bezeichnung NSAPI) von iPlanet/Netscape f¨r deren Ser-
u o u
ver. Abbildung 3 stellt die Funktionsweise der Server-Extensions dar.
Diese Erweiterungen sind i.d.R. in C++ geschrieben, was eine hohe Performance zur Folge
hat. Jedoch hat auch diese L¨sung einige Nachteile: Durch die enge Verbindung mit dem Web-
o
Server kann eine abgest¨rzte Server-Erweiterung den kompletten Server lahm legen. Außer-
u
¨
dem sind Erweiterungen immer auf einen bestimmten Servertyp festgelegt. Eine Ubertragung
auf andere Server ist somit nicht m¨glich.
o
Server Side Includes Mit Hilfe von Server Side Includes (SSI) k¨nnen dynamische Infor-
o
mation direkt innerhalb von HTML-Dateien eingebunden werden. Server Side Includes sind
generell dazu gedacht, kleinere Teile einer HTML-Seite dynamisch einzubinden. Ein typisches
¨
Beispiel ist die Angabe des letzten Anderungsdatums einer Seite.
SSI wird von sehr vielen Servern unterst¨tzt und ist deshalb meist von Server zu Server
u
ubertragbar. Jedoch ist der Funktionsumfang recht beschr¨nkt, so dass SSI nicht f¨r gr¨ßere
¨ a u o
Projekte geeignet ist.
ASP, PHP, SSJS Eine weitere M¨glichkeit zum Erstellen dynamischer Web-Seiten bieten
o
die Technologien ASP (Active Server Pages), PHP (benannt nach einem Vor¨ngerprodukt
a
namens Personal Homepage) oder auch SSJS (Server Side JavaScript).
Bei dieser Technik werden Code-Fragmente in HTML-Seiten eingebettet. Wird eine Seite

13. 2.1 Java Servlets 8
Abbildung 3: Web-Server mit Server-Extension-API
angefordert, wird der eingebettete Code zuerst vom Web-Server ausgef¨hrt, bevor er zum
u
Client geschickt wird.
Diese Technik ist vor allem hilfreich bei Seiten, die nur sehr wenig dynamischen Inhalt bieten
und uberwiegend aus statischen Teilen bestehen, da hier lediglich ein paar zus¨tzliche Zeilen
¨ a
in den bestehenden HTML-Code eingef¨gt werden m¨ssen. Ein Beispiel ist ein Seite, die den
u u
Besucher namentlich begr¨ßt, sonst aber keine benutzerabh¨ngigen Informationen enth¨lt.
u a a
Ein anderes Beispiel ist ein Besucherz¨hler auf einer sonst statischen Seite.
a
Besteht die Seite jedoch aus sehr vielen dymanischen Teilen, zeigen sich die Schw¨chen dieser
a
Technologie. Durch die Vermischung von statischen Inhalt und Funktionalit¨t ist eine Pflege
a
¨
des Codes recht schwierig, da die Ubersichtlichkeit stark leidet. Außerdem ist es so nur schwer,
wenn uberhaupt m¨glich, die Arbeit von Entwicklern und Designern zu trennen.
¨ o
Außerdem sind ASP und SSJS serverabh¨ngig. So verwendet ASP in der Regel VBScript
a
oder JScript und l¨uft nur auf Microsofts IIS. Zwar gibt es bereits kommerzielle Software wie
a
z.B. InstantASP von Halcyon Software oder OpenASP von ActiveScripting.org, die ASP auch
auf anderen Servern m¨glich macht, jedoch ist dies mit großem Aufwand verbunden und bis
o
heute nicht vollkommen ausgereift. SSJS wurde von iPlanet/Netscape entwickelt und bettet
JavaScript-Fraktmente in HTML ein. SSJS l¨uft jedoch ausschließlich auf iPlanet/Netscape-
a
Servern.
Lediglich PHP, das sich stark an dem vielen CGI-Programmiern bekannte Perl anlehnt, l¨uft a
auf nahezu allen Servern. So verwundert es auch nicht, dass PHP die verbreitetste dieser
drei Sprachen ist. Der Nachteil, dass große Projekte schnell un¨bersichtlich werden, bleibt
u
allerdings auch hier bestehen.
ColdFusion Das Unternehmen Allaire entwickelte eine Alternative zur Erzeugung dynami-
scher Inhalte: ColdFusion. Bei diesem Ansatz werden HTML/XML-¨hnliche Elemente, ge-
a

14. 2.1 Java Servlets 9
nannt ColdFusion Markup Language (CFML), in die Web-Seite eingebettet. War der Funk-
tionsumfang von ColdFusion zu Beginn noch recht beschr¨nkt, bieten sich dem Entwickler
a
mittlerweile viele n¨tzliche Features, die jedoch in ihrer M¨chtigkeit der Java-API deutlich
u a
unterlegen sind.
Die neuste Version von ColdFusion er¨ffnet jedoch die M¨glichkeit, benutzerdefinierte Ele-
o o
mente zu entwickeln, die mit JavaServlets kommunizieren k¨nnen. ColdFusion bietet sich
o
somit als Erg¨nzung von Servlets an, wobei allerdings zu abzuw¨gen ist, ob die Verwendung
a a
von JavaServer Pages, die sp¨ter beschrieben werden, nicht die bessere Alternative ist.
a
Servlets Ein Java Servlet l¨uft ¨hnlich wie Server-Extensions im Web-Server und erweitert
a a
dessen Funktionalit¨t. Jedoch laufen Servlets als Java-Programme in einer Java Virtual Ma-
a
chine (JVM), so dass sie erstens sicher sind und zweitens, dank Byte-Code, leicht auf andere
Plattformen ubertragen werden k¨nnen. Servlet-Unterst¨tzungen sind bereits f¨r viele Web-
¨ o u u
Server erh¨ltlich.
a
Der große Vorteil von Servlets besteht darin, dass Client-Anfragen nicht zu einer Unmenge
von Prozessen f¨hren. Vielmehr ist es mit Servlets m¨glich, separate Threads zu erzeugen,
u o
die in ein und dem selben Prozess laufen. Abbildung 4 zeigt diese Vorgehensweise. Denkbar
Abbildung 4: Web-Server mit Servlet-Unterst¨tzung
u
w¨re auch die Verteilung von Threads auf mehrere Prozesse, die auf verschiedenen Rechnern
a
(sog. Backend Server) laufen.
Diese Technik erm¨glicht eine schnelle und resourcenschonende Verarbeitung von Anfragen.
o
Gleichzeitig ist es Servlets m¨glich, eng mit dem Web-Server zusammen zu arbeiten, da sie
o
direkt in diesen eingebettet werden. Eine solche Art der Kommunikation w¨re beispielsweise
a
mit CGI nicht m¨glich.
o
Dies alles f¨hrt zu den folgenden entscheidenden Vorteilen:
u

15. 2.1 Java Servlets 10
Effizienz Servlets laufen im Gegensatz zu CGI-Skripts nicht als schwergewichtiger
Betriebssystem-Prozess, sondern als resourcenschonender Thread. CGI-Progamme m¨ssten u
bei N parallelen Anfragen N mal in den Arbeitsspeicher geladen werden. Bei Servlets g¨be a
es zwar auch N Threads, aber lediglich ein Exemplar der Servlet-Klasse.
Servlets verweilen als einfache Instanz im Speicher. Im Gegensatz zu CGI, wo f¨r jede An-
u
frage der (Perl-)Interpreter erneut geladen werden muss, kann ein Servlet somit, wenn es erst
einmal geladen wurde, jede weiter Anfrage quasi unmittelbar ausf¨hren. Weiterhin ist es Serv-
u
lets m¨glich, einen Zustand uber mehrere Anfragen hinweg bei zu behalten. Daten k¨nnen
o ¨ o
als Klassenvariablen zwischengespeichert werden, vorangegangene Berechnungen k¨nnen ge-
o
cachet werden oder externe Resourcen, wie z.B. eine Datenbank-Verbindung, k¨nnen gehalten
o
werden, was sonst bei jeder Anfrage erneut einige Zeit in Anspruch nehmen w¨rde.
u
M¨chtigkeit Java Servlets k¨nnen den kompletten Java Sprachumfang nutzen.
a o
Datenbank-Verbindungen mit JDBC, Multithreading, Datenkomprimierung, Internationali-
sierung, Grafikerzeugung oder Serialisierung sind nur einige Beispiele f¨r die M¨glichkeiten,
u o
die sich Servlets bieten. Kommuniziert ein Servlet mit einem Applet, k¨nnte auf die M¨glich-
o o
keit von Remote Method Invokation (RMI) zur¨ckgegriffen werden. Zus¨tzlich zu den auf-
u a
gef¨hrten Gebieten decken Klassen von Drittanbietern fast jedes andere Einsatzgebiet ab.
u
Das Parsen von XML, die Verwendung von regul¨ren Ausdr¨cken oder das Erzeugen von
a u
Diagrammen seien als Beispiel genannt.
Alles in allem bietet die Java-API eine M¨chtigkeit, die kaum oder nur schwer von CGI-
a
Programmen oder Skriptsprachen erreicht werden kann.
Portierbarkeit Da Servlets in Java geschrieben sind, k¨nnen sie problemlos zwischen
o
verschiedenen Plattformen portiert werden. Der Quellcode wird dazu wie gewohnt kompiliert.
Der erzeugte Byte-Code in Form einer .class-Datei kann nun auf jeder JVM laufen. Servlets,
die unter dem IIS von Microsoft entwickelt wurden, k¨nnen somit ohne Ver¨nderungen auf
o a
einen Apache-Server ubertragen werden.
¨
Sicherheit Java Servlets sind sehr sicher. Da Java bereits beim Kompilieren eine Typ-
Pr¨fung vornimmt, k¨nnen klassische Sicherheitsl¨cken, wie beim typenlosen Perl gar nicht
u o u
erst entstehen.
Javas Garbage Collector und das Fehlen von Zeigern stellt sicher, dass Speicherprobleme wie
beispielsweise Memory Leaks, ung¨ltige oder gar b¨swillig ver¨nderte Pointer, nicht m¨glich
u o a o
sind. In C++ k¨nnte beispielsweise auf die 1000-te Position eines Arrays mit nur 200 Ein-
o
tr¨gen zugegriffen werden. Dies w¨rde dazu f¨hren, dass so in Bereiche des Arbeitsspeichers
a u u
geschrieben w¨rde, auf die sonst kein Zugriff best¨nde. Tats¨chlich ist dies eine oft benutzte
u u a
Hintert¨r f¨r Angriffe. Servlets bieten diese M¨glichkeit nicht, da automatsich Array-Grenzen
u u o
uberpr¨ft werden.
¨ u
Fehler zur Laufzeit, wie z.B. eine Division durch Null, die bei Server Extensions oft als Sicher-
heitsl¨cke f¨r Angriffe genutzt wurden um den Server lahmzulegen, werfen bei Java Servlets
u u
eine Exception, die entweder vom Servlet selbst oder aber vom Server abgefangen werden.
Ein Absturz des Servers ist nicht mehr m¨glich.
o
Zu guter Letzt werden bei Servlets keine externen Programme ausgef¨hrt, wie es bei CGI
u

16. 2.1 Java Servlets 11
der Fall ist. Oftmals ist es m¨glich einem CGI-Skript Daten zu ubergeben, um dadurch die
o ¨
Ausf¨hrung von anderen Programmen zu erzwingen. So werden bei Perl-Skripten oft Mails
u
verschickt, indem das Unix-Programm sendmail verwendet wird. Auf den ersten Blick ist
es ausreichend, die Adresse, die der Benutzer in ein Formular eingegeben hat, an sendmail
weiter zu reichen. Da jedoch auch mehrere Befehle in einer Unix-Shell mit einem Semikolon
getrennt werden k¨nnen, kann ein Angreifer als Adresse so etwas wie mmo@varial.de;rm
o
-rf / angeben. W¨rde dies ungepr¨ft an sendmail weitergegeben, erg¨be dies: sendmail
u u a
mmo@varial.de;rm -rf /. Resultat w¨re neben dem Senden einer Mail auch die Ausf¨hrung
a u
des rm-Befehls, der die Festplatte des Servers l¨schen w¨rde.
o u
Dies ist nur eines von vielen Beispielen, das zeigt, dass die Ausf¨hrung von externen Pro-
u
grammen ein erhebliches Sicherheitsrisiko darstellt. Servlets hingegen verwenden keine Shell,
selbst dann nicht, wenn ein Remote-Systemaufruf ausgef¨hrt wird.
u
Man sieht, dass Java Servlets uber einen umfangreichen Sicherheitsmechanismus verf¨gen.
¨ u
Serverintegration Dadurch, dass Servlets direkt in den Web-Server integriert werden,
k¨nnen sie eng mit ihm zusammenarbeiten. Sie k¨nnen direkt in Logfiles schreiben, relative
o o
URLs in absolute Pfadangaben ubersetzen oder auch Benutzerberechtigungen uberpr¨fen.
¨ ¨ u
CGI-Programme laufen hingegen getrennt vom eigentlichen Server, so dass eine solche Art
der Zusammenarbeit dort unm¨glich ist.
o
JavaServerPages JavaServer Pages oder kurz JSP verbinden die Vorteile von Servlets, Cold-
Fusion und eingebetteten Skript-Sprachen. JavaServer Pages ¨hneln vom Aufbau recht stark
a
dem ASP- oder PHP-Ansatz. In statischen HTML-Code 1 werden Elemente f¨ r dynamischen
u
Inhalt eingef¨gt. Seiten, die nur wenig dynamische Teile beinhalten, k¨nnen so ohne großen
u o
Aufwand erstellt werden.
Sollte der dynamische Inhalt einen gr¨ßeren Teil der Seite ausmachen, k¨nnen JSP-Seiten
o o
leicht mit Servlets zusammen arbeiten. Hierzu k¨nnen sog. Taglibs entwickelt werden. Dies
o
sind Bibliotheken mit benutzerdefinierten Elementen. Dem Entwickler wird es auf diese Weise
erm¨glicht, eigene Tags zu entwerfen. Die Funktion der Tags wird von einer Java-Klasse im-
o
plementiert. Der Vorteil dieser Vorgehensweise ist, dass Ausgabe (JSP) und Funktion (Java-
Klasse) klar voneinander getrennt sind. Die JSP-Seite unterscheidet sich vom Aufbau her
kaum von herk¨mmlichen HTML-Seiten, da alle Elemente der XML-Syntax folgen. So k¨nnen
o o
Web-Designer, die mit dem Umgang mit HTML-Seiten vertraut sind, fast ohne Einarbei-
tungszeit komplexe Seiten gestallten. Die Funktionalit¨t wird hingegen von Programmierern
a
ubernommen, die sich ihrerseits nicht mit dem Seitenlayout belasten m¨ssen. Beide Parteien
¨ u
erstellen so gemeinsam ein Projekt, arbeiten aber unabh¨ngig von einander.
a
Mit JSP und Taglibs kann so spielend einfach das Seitenlayout ge¨ndert werden, ohne dass
a
die Programmlogik angepasst werden muss und umgekehrt. Dies macht auch die Pflege eines
Projekts denkbar einfach.
Der JSP-Ansatz beinhaltet dar¨ber hinaus auch alle Vorteile von Servlets, da es sich bei JSP-
u
Seiten nur um eine andere Darstellung von Servlets handelt. JSP-Code wird bei erstmaliger
Ausf¨hrung2 in ein Java Servlet ubersetzt und kompiliert. Mit JSP erstellte Seiten werden
u ¨
1
JSP ist keinesfalls auf HTML beschr¨nkt, sondern kann theoretisch in jede Art von Text eingebettet
a
werden. Denkbar w¨ren ebenso XML- oder L TEX-Dokumente.
a A
2
JSP-Code kann auch vorkompiliert werden.

17. 2.2 CORBA 12
vom Server somit als Servlet betrachtet, sie sind also genauso effizient, m¨chtig, portierbar
a
und sicher wie Servlets.
2.1.3 Die Zukunft
Mit Java Servlets setzt die Programmiersprache Java ihren Siegeszug der letzen Jahre weiter
fort. Java besticht durch die M¨chtigkeit und Eleganz der Sprache, die eine saubere, objek-
a
torientierte, modulare und einfache Programmierung erm¨glicht. Mit Java Servlets k¨nnen
o o
diese Vorteile nun auch auf Web-Servern genutzt werden.
Immer mehr Hersteller bieten Servlet-Unterst¨tzung f¨r ihre Web-Server, so dass Java Serv-
u u
lets auf lange Sicht auf Grund ihrer Performance-Vorteile und Portierbarkeit den weitverbrei-
teten CGI-Ansatz abl¨sen werden.
o
2.2 CORBA
Die Common Object Request Broker Architecture oder kurz CORBA ist eine Spezifikation,
die von der Object Managment Group (OMG) entwickelt wurde. CORBA unterst¨tzt die u
Realisierung verteilter Objekte. So k¨nnen Objekte zusammen agieren ohne voneinander zu
o
wissen, wo sich das Gegen¨ber befindet, oder in welcher Sprache es implementiert wurde.
u
CORBA ist in der letzten Zeit immer mehr zu dem Standard f¨r die Entwicklung von Middle-
u
ware geworden. Die OMG umfasst mittlerweile mehr als 800 Firmen, die das ganze Spektrum
der Computerindustrie repr¨sentieren. Die einzige bemerkenswerte Ausnahme bildet Micro-
a
soft mit einem eigenen konkurierenden Objektbus namens Distributed Component Object
Model (DCOM).
2.2.1 Die OMG
OMG ist die Abk¨rzung f¨r Object Managment Group. Sie wurde im April 1989 gegr¨ndet
u u u
und bestand urspr¨nglich aus 11 Firmen, darunter u.a. 3Com Corporation, American Air-
u
lines, Canon Inc., Data General, Hewlett-Packard, Philips Telecommunications N.V., Sun
Microsystems und Unisys Corporation. Mittlerweile umfasst die OMG uber 800 Mitglieder.
¨
Auf der Basis eines Vorschlags, Request for Comment (RFC) genannt, wird zun¨chst disku-
a
tiert, was standardisiert werden soll. Dann k¨nnen zu einem festgelegten Anforderungsprofil,
o
als Request for Proposal (RFP) bezeichnet, Technologien zur Standardisierung vorgeschlagen
werden. Ziel der OMG ist es, herstellerunabh¨ngige, technisch ausgereifte und kommerziell
a
erfolgreiche Spezifikationen zu erarbeiten und zu standardisieren. Diese Spezifikationen sollen
es erm¨glichen, objektorientierte Modelle unter Abstraktion von der verwendeten Hardware
o
und des Betriebsystems zu gestalten.
2.2.2 Object Management Architecture
Die OMG ver¨ffentlichte im Herbst 1990 die Object Management Architecture (OMA) im
o
Rahmen des sog. OMA Guides, der im September 1992 nochmals uberarbeitet wurde. Drei
¨
Jahre sp¨ter wurde OMA dann schließlich ein weiteres Mal erweitert. Im Januar 1995 wurden
a
Einzelheiten der sog. Common Facilities hinzugef¨gt. Der endg¨ltige Stand der Spezifikation
u u
ist in Abbildung 5 dargestellt. Das Bild zeigt den Aufbau der OMA. Die Architektur gliedert

18. 2.2 CORBA 13
Abbildung 5: Aufbau der Object Management Architecture
sich in vier Teile:
Application Objects Die Application Objects (oft auch als Application Interfaces bezeich-
net) stellen die eigentliche Anwendung dar, die CORBA nutzt. Mit anderen Worten bezeich-
net der Begriff Application Objects die Objekte, die durch CORBA verteilt werden sollen.
Diese Objekte repr¨sentieren gem¨ß dem Grundsatz der objektorientierten Programmierung
a a
Dinge des realen Lebens. Wichtige Einzelheiten werden mit entsprechenden Attributen mo-
deliert, unwichtige Details wegabstrahiert. Im Folgendem werden diese Objekte, bzw. die
Java-Klassen, die diese implementieren, als Business-Objekte (BO) bezeichnet.
Die Business-Objekte werden speziell f¨r die jeweilige Anwendung programmiert. Folglich
u
werden diese von der OMG nicht n¨her spezifiziert. Die Business Object Task Force der
a
OMG definiert lediglich, dass ein BO eine Komponente der Applikationsebene ist, die sich
entsprechend des Prinzips der Wiederverwendbarkeit, vielseitig einsetzen l¨ßt.
a
Common Facilities Mit Common Facilities oder, wie sie von der OMG genannt werden,
CORBAfacilities stellt CORBA bereits einige n¨tzliche Dienste f¨r die Verwendung mit BOs
u u
zur Verf¨gung. Dazu z¨hlen beispielsweise grafische Benutzeroberfl¨chen, Drucker- und Da-
u a a
tenbankdienste, mobile Agenten oder auch Frameworks f¨r Internationalisierung. Das Reper-
u
toire an CORBAfacilities wird laufend weiterentwickelt und wird in Zukunft praktisch jeden
verteilten Dienst anbieten.
Common Object Services Die Common Object Services, die von der OMG als CORBA-
services bezeichnet werden, bieten das Fundament f¨r die CORBAfacilities. CORBAservices
u
sind Sammlungen von elementare Diensten auf Systemebene, die f¨r die Entwicklung von
u

19. 2.2 CORBA 14
verteilten Anwendungen ben¨tigt werden. Die OMG definiert insgesamt 15 CORBAservices:
o
• Lifecycle Service
¨
Ubernimmt das Erzeugen, Kopieren, Verschieben unf L¨schen von Objekten.
o
• Persistence Service
Einheitliche Schnittstelle f¨r das dauerhafte Speichern der Objekte auf unterschiedli-
u
chen physikalischen Datentr¨gern.
a
• Naming Service
Dienst f¨r das Auffinden von Objekten anhand ihres Namens.
u
• Event Service
Registriert und verwaltet Objekt-Ereignisse, so dass Objekte zusammenarbeiten
k¨nnen.
o
• Concurrency-Control Service
Verwaltet als Lock-Manager die Sperren f¨r Transaktionen und Threads.
u
• Transaction Service
Koordiniert ein Zwei-Phasen-Protokol zwischen wiederherstellbaren Komponenten.
• Relationship Service
Erm¨glicht das Verkn¨pfen von Objekten. Erm¨glicht weiterhin referentielle Integrit¨t.
o u o a
• Externalization Service
Importiert bzw. exportiert Daten uber eine Stream-Mechanismus in eine Komponente.
¨
• Query Service
Stellt Abfrageoperationen f¨r Objekte bereit.
u
• Licensing Service
Bietet Operationen um die Nutzungsdauer einer Komponente zu messen.
• Properties Service
Ordnet Objekten Schl¨ssel-Wert-Paare zu.
u
• Time Service
Synchronisiert Zeitangaben in verteilten Umgebungen.
• Security Service
Regelt die Sicherheit von verteilten Objekten. Unterst¨tzt Identifizierung, Zugriffskon-
u
trollen, Vertraulichkeit und Unwiderlegbarkeit der Daten.
• Trader Service
Verwaltet die Dienste, die Objekte bereitstellen in einem zentralen Verzeichnis.
• Collection Service
Erm¨glicht CORBA-Schnittstellen, allgemeine Collections zu erzeugen und zu manipu-
o
lieren.

20. 2.2 CORBA 15
Object Request Broker Die OMG definiert mit CORBA einen offenen Standard, liefert
selbst jedoch keine Implementierung. Software, die die CORBA-Spezifikation implementiert,
heißt Object Request Broker (ORB). Als Beispiele seien hier VisiBroker von Visigenic, Orbix
von Iona oder Suns Java IDL genannt.
Der ORB trennt die Anfrage eines Services (Client) von dessen Bereitstellung (Server). Der
ORB ist das Herzst¨ck der CORBA-Technologie. Alle Aufrufe von Objekten (ob lokal oder
u
entfernt) werden durch den ORB gemanagt (Abbildung 6). Genauer gesagt ist dies Aufgabe
Abbildung 6: Aufruf verteilter Objekte uber den ORB
¨
des Objektadapters. Er sorgt daf¨r, dass bei Anfragen das richtige Serverobjekt aktiviert
u
wird und leitet Auftr¨ge an diese Objekte weiter. Dies geschieht automatisch, ohne dass sich
a
der Entwickler Gedanken dar¨ber machen muss, wo und ob ein Serverobjekt zur Zeit aktiv
u
ist. Der Objektadapter sorgt daf¨r, dass aus Sicht des Clients alle Serverobjekte aktiv und
u
lokal zu sein scheinen.
CORBA legt fest, dass jeder ORB einen Standardadapter namens Basic Objekt Adapter
(BOA) unterst¨tzen muss. Da der BOA bei CORBA 1.1 noch nicht ausreichend spezifiziert
u
war, entwickelten sich viele herstellerabh¨ngige BOAs, die zwar alle den CORBA-Standard
a
erf¨llten, jedoch u.U. nicht richtig zusammen arbeiteten. Aus diesem Grunde wurde CORBA
u
2.0 um den Portable Object Adapter (POA) erweitert. Durch zus¨tzliche Spezifikationen der
a
OMG ist nun sichergestellt, dass POAs zueinander kompatibel sind, w¨hrend das bei BOAs
a
nicht unbedingt der Fall sein muss.
Da die ORB-Implementierungen an die Spezifikation der OMG gebunden sind, k¨nnen ORBs
o
verschiedener Hersteller problemlos ausgetauscht werden. Seit CORBA 2.0 und der Verab-
schiedung des Internet Inter-ORB-Protocols (IIOP) ist dar¨ber hinaus auch sicher gestellt,
u
dass ORBs verschiedener Hersteller miteinander kooperieren (Abbildung 7). Bei IIOP han-
delt es sich im Wesentlichen um TCP/IP, erg¨nzt um einige CORBA-spezifische Nachrichten,
a
die als gemeinsames Backbone-Protokoll dienen.
2.2.3 Interface Definition Language
CORBA ist ein selbstbeschreibendes System. Damit Objekte sprachenunabh¨ngig mitein-
a
ander agieren k¨nnen, wird klar zwischen Schnittstellenbeschreibung und Implementierung
o
unterschieden. Hierzu dient die Interface Definition Language (IDL). Mit dieser neutralen
Sprache, deren Syntax an C++ angelehnt ist, werden CORBA-Objekte mit ihren Attributen

21. 2.2 CORBA 16
Abbildung 7: ORB-Verbindung mit IIOP
¨
und Funktionen (inkl. Uber- und R¨ckgabe-Parameter und Fehlerbehandlungen) beschrieben.
u
Komponenten, die in IDL geschrieben sind, sollten zu anderen Sprachen, Betriebssystemen
und Netzwerken hin kompatibel sein (Abbildung 8). Hierzu generiert der Compiler aus der
Abbildung 8: Sprachunanh¨ngigkeit durch IDL
a
IDL-Beschreibung f¨r die jeweilige Programmiersprache passende Interfaces. Diese Interfa-
u
ces heißen serverseitig Skeletons, w¨hrend sie clientseitig als Stubs bezeichnet werden. Diese
a
Interfaces k¨nnen dann von Client und Server implentiert werden.
o
Auf diese Weise ist es z.B. m¨glich, dass ein in IDL beschriebenes Objekt als C-Client
o
und Java-Server implementiert und auf verschiedenen Rechnern platziert wird. Die IDL stellt
hierf¨r die programmiersprachenunabh¨ngige Verbindung her, der ORB sorgt f¨r die Loka-
u a u
lisierung der verteilten Objekte. F¨r den Programmierer gestaltet sich das Szenario dank
u
CORBA v¨llig transparent.
o
2.2.4 Alternative Ans¨tze
a
Sockets Sockets stellen die wohl primitivste Art der Netzwerkkommunikation dar. Ein
Socket ist ein Peer-to-Peer-Kommunikationsendpunkt uber TCP/IP. 1981 wurden Sockets
¨

22. 2.2 CORBA 17
im Rahmen von Unix BSD 4.2 als Interface f¨r interprocess communications“ (IPC) auf
u
”
Unix-Systemen vorgestellt. Mittlerweile sind Sockets auf nahezu allen Betriebssystemen im-
plementiert. Java selbst unterst¨tzt Socket durch einige Klassen in dem java.net-Packet.
u
Ein Socket besteht aus einem Namen und einer Netzwerkadresse und l¨ßt sich in eine von
a
drei Klassen einteilen.
• Datagram Sockets
a u ¨
UDP (User Datagram Protocol): unabh¨ngige Packet¨bertragung, keine Ubertragungs-
garantie.
• Stream Sockets
TCP/IP (Transmission Control Protocol / Internet Protocol), verbindungsorientiertes
Protokoll.
• Raw Sockets
ICMP (Internet Control Message Protocol), low-level Protokoll.
Durch ihren Low-Level-Charakter sind Sockets zwar sehr schnell, haben hingegen aber auch
einige Nachteile. So bieten Sockets weder Parameter Marshaling noch dynamische Service-
Bindung. Der Entwickler muss eigene Protokolle entwickeln, die die Methodenaufrufe des
Clients den Methoden des Servers zuordnen. Bedenkt man, dass große Systeme leicht einige
hundert Funktionen umfassen, k¨nnte dies zu einem gewaltigen Aufwand f¨hren. Die Pflege
o u
und Wartung der Software w¨rde schnell eine un¨berschaubare Aufgabe. Folglich stellen
u u
Sockets f¨r die Anforderung moderner Systeme keine ausreichende L¨sung dar.
u o
RMI Remote Method Invocation oder kurz RMI ist eine von der Firma Sun Microsystems
entwickelte Technik zur Realisierung verteilter Anwendungen mit Java. Genauer gesagt er-
laubt RMI einer Java-Applikation, Methoden anderer Java-Anwendungen, die in unterschied-
lichen JVMs und sogar auf anderen Systemen laufen k¨nnen, aufzurufen. Das Ziel bei der
o
Entwicklung von RMI war es, ein verteiltes Objektmodel in Java zu integrieren, ohne dabei
das bestehende Sprach- und Objektmodell zu zerreißen. RMI ist seit der Version 1.1 ein fe-
ster Bestandteil des JDKs (java.rmi-Packet) und erm¨glicht die einfache Entwicklung einer
o
Client-Server-Architektur, die sich f¨r den Entwickler fast vollkommen transparent gestaltet.
u
RMI baut auf Socketverbindungen auf, verbirgt aber alle Low-Level-Einzelheiten. Der Ent-
wickler muss keine Protokolle definieren oder sich uber Details der Verbindung Gedanken
¨
machen. Java-Klassen kommunizieren mit RMI uber ein wohldefiniertes und standardisiertes
¨
Protokoll. Die Entwicklung einer verteilten Anwendung gestaltet sich dadurch recht einfach.
Die Arbeitsweise von RMI l¨ßt sich folgendermaßen skizzieren:
a
• Erstellen eines Remote-Interfaces
Bei einem Remote-Interface handelt es sich um ein normales Java-Interface, das von
dem Interface java.rmi.Remote abgeleitet wurde. Dieses Interface muss immer als
public deklariert werden. Alle Funktionen, die ein verteiltes Objekt zur Verf¨gung stel-
u
len sollen, m¨ssen in diesem Interface angegeben werden. Hierbei ist zu beachten, dass
u
die Methoden die Ausnahme vom Typ java.rmi.RemoteException werfen m¨ssen. u
Verbindungsst¨rungen und Netzwerkprobleme w¨hrend eines Methodenaufrufs werden
o a
hiermit angezeigt.

23. 2.2 CORBA 18
• Entwurf einer Serverklasse, die das Remote-Interface implementiert
Eine Java-Klasse implementiert die Methoden des erstellten Remote-Interfaces und er-
zeugt eine oder mehrere Instanzen.
• Registrierung bei einem Name-Service
Nachdem mindestens eine Instanz der Server-Klasse erzeugt wurde (sog. Remote-
Objekte), muss diese bei einem Name-Service registriert werden. Das RMI-Packet
stellt hierzu bereits einen simplen Name-Service mit der Bezeichnung RMI-Registry
zur Verf¨gung.
u
• Aufruf entfernter Methoden
Clients verschaffen sich mittels des Name-Services Referenzen auf die Remote-Objekte.
Durch solche Remote-Referenzen lassen sich nun Methoden von entfernten Objekten
¨
aufrufen. Zu beachten ist hierbei, dass Ubergabeparamter serialisierbar sein m¨ssen,
u
indem sie das Interface Serializable implementieren. Der Grund daf¨r ist, dass RMI
u
Parameter-Objekte in irgendeiner Form uber das Netzwerk schicken muss. Hierzu stellt
¨
Java mit der Objekt-Serialisierung bereits die notwendige Technologie zur Verf¨gung,
u
auf die RMI zur¨ckgreift.
u
Genau wie bei CORBA kommunizieren Client- und Server-Klassen nur scheinbar direkt mit-
einander. Tats¨chlich dienen auch hier Stubs und Skeletons als Platzhalter, die die Kom-
a
munikation transparent erscheinen lassen. Der Client hat Zugriff auf eine Stub-Klasse, die
das Server-Interface implementiert. Methodenaufrufe des Stubs werden uber das Netzwerk
¨
ubertragen und von dem Gegenst¨ck auf der Serverseite, dem Skeleton, an das jeweilige
¨ u
Server-Objekt weitergeleitet (Abbildung 9).
Abbildung 9: Verteilte Anwendung mit RMI
Der RMI-Ansatz unterscheidet sich demnach nicht viel von der CORBA-Architektur.
Dementsprechend muss bei der Planung zun¨chst die Frage gestellt werden, welcher Ansatz
a
den Anforderungen besser gerecht wird. RMI stellt eine wesentlich einfachere Architektur als
CORBA zur Verf¨gung, was dazu f¨hrt, dass RMI besonders f¨r kleinere Projekte geeignet ist.
u u u
Dar¨ber hinaus ist es einfacher zu erlernen und direkt in neueren JDK-Versionen eingebettet.
u

24. 2.2 CORBA 19
Der Nachteil gegen¨ber CORBA ist allerdings, dass gerade große Projekte durch verschie-
u
dene CORBA-Features (CORBAservices und CORBAfacilities) besser mit die Technologie
der OMG umsetzbar sind. Außerdem k¨nnen mit RMI nur reine Java-Projekte implementiert
o
werden. Eine Kommunikation zwischen Objekte, die in unterscheidlichen Programmierspra-
chen geschrieben wurden, ist im Gegensatz zu CORBA nicht m¨glich. RMI stellt folglich bei
o
heterogenen Projekten keine Alternative dar.
DCOM Das Distributed Component Object Model (DCOM) ist Microsofts Antwort auf den
OMG-Standard. Mit DCOM stellt Microsoft eine weitere M¨glichkeit zur Realisierung verteil-
o
ter Anwendungen zur Verf¨gung. Dabei gehen die Wurzeln von DCOM weit in die Vergangen-
u
heit zur¨ck. Strenggenommen wurde 1987 mit Einf¨hrung der Zwischenablage in Windows
u u
der Grundstein f¨r DCOM gelegt (Abbildung 10). Mit der Zwischenablage war es erstmals
u
Abbildung 10: Entwicklung von DCOM aus COM und RPC
m¨glich, Texte aus einem Programm zu kopieren und in anderen Applikationen einzusetzen.
o
1992 wurde diese Technik erweitert und als OLE (Object Linking & Embedding) ver¨ffent-o
licht. Nun war es nicht nur m¨glich, Texte zwischen zwei Applikationen auszutauschen, son-
o
dern es wurde gar erm¨glicht, komplexere Objekte durch die Zwischenablage zu kopieren.
o
Ein oft zitiertes Beispiel ist das Einbinden einer Excel-Tabelle in einem Word-Dokument. Bei
Doppelklick des Benutzers auf die eingebettete Tabelle, startet die Excel-Applikation auto-
matisch im Hintergrund und ubernimmt die Kontrolle uber die grafische Oberfl¨che. Da beide
¨ ¨ a
Anwendungen jedoch unabh¨ngig von einander entwickelt werden, bedarf es einem standar-
a
disierten Verfahrens, das die Kommunikation zwischen den Windows-Applikationen regelt.
OLE bot mit DDE (Dynamic Data Exchange) die grundlegende Kommunikationsschicht f¨r u
den Datenaustausch. Da sich DDE jedoch schon schnell als zu langsam und unflexibel her-
ausstellte, konnte sich die Technologie nicht wie gew¨nscht durchsetzen.
u
Microsoft entwickelte daraufhin OLE 2. Die Fragestellung, wie zwei Windows-Programme
miteinander Daten austauschen k¨nnen, wurde jetzt ein wenig ausgeweitet. Als zentrales Ziel
o
wurde definiert, dass eine Applikation die Funktionalit¨t beliebiger bin¨rer Komponenten in
a a
einer objektorientierten Art und Weise nutzen solle. Dies unabh¨ngig von den verwendeten
a

25. 2.2 CORBA 20
Implementierungssprachen und ebenso vom Aufenthaltsort der beteiligten Akteure. Das Re-
¨
sultat der Uberlegung war 1993 OLE 2, eine Technologie, die schon bald die Grundlage f¨r u
COM bilden sollte.
COM ist die Kurzbezeichnung f¨r Component Object Model und definiert einen Standard f¨r
u u
die Entwicklung von Software-Komponenten. Eine Software-Komponente stellt in der COM-
¨
Uberlegung eine Art Black-Box dar, die ihre Funktionalit¨ten nach Außen durch beschriebene
a
Schnittstellen zur Verf¨gung stellt. Bei der Verwendung der Komponente ist es hierbei v¨llig
u o
egal, wie und in welcher Programmiersprache sie geschrieben ist. Mit Hilfe der Interfaces
kann die Komponente von anderen Anwendungen genutzt werden ohne den inneren Aufbau
zu kennen (Abbildung 11).
Schnell fand ein neues Zauberwort Einzug in die Windows-Welt: ActiveX. ActiveX beinhaltet
Abbildung 11: Software-Komponente nach COM: Aufbau und Zugriff
dabei lediglich COM. Der Grund f¨r die babylonische Sprachverwirrung, in der auch VBX,
u
das Software-Komponenten f¨r Visual-Basic-Steuerelemente beschreibt, und das allgemeinere
u
OCX, Platz finden, ist weniger in technischen Weiterentwicklungen, als in marketingtechni-
¨
schen Uberlegungen zu finden.
ActiveX war mit COM wesentlich schneller als DDE und dar¨ber hinaus viel flexibler als die
u
alte Technologie. Mit Windows NT und einer Version f¨r Windows 95 fand ActiveX schnell
u
erste Einsatzgebiete in der Windows-Welt. Fortan sollte das Component Object Model bzw.
ActiveX eine entscheidende S¨ule in der Entwicklung von Windows-Applikationen spielen.
a
W¨hrend COM lediglich das Zusammenspiel von Software-Komponenten auf dem selben
a
Rechner erlaubt, hebt DCOM als verteiltes COM diese Grenzen auf. DCOM erm¨glicht nun
o
auch die netzweite Kommunikation zwischen Komponenten und damit die Entwicklung ver-
teilter Systeme (Abbildung 12). DCOM-Objekte entsprechen hierbei weitgehend den gewohn-
ten COM-Komponenten. Die Kommunikation zwischen den Objekten regelt das DCE (Distri-
buted Computing Enviroment), das in Abbildung 13 dargestellt ist. Es basiert im Grunde auf
RPC. Clients rufen Server-Methoden auch hier uber die Stellvertreter, die Stubs, auf. Eine
¨
¨
weitere Ahnlichkeit zu CORBA ist, dass DCOM ebenfalls die Beschreibung von Diensten von
deren Implementierung trennt. Hierzu definiert DCOM eine eigene IDL, die allerdings keine
¨
Ahnlichkeit zu der CORBA-Systax hat.
Die neuste Entwicklung der COM bzw. DCOM Technik wurde unter der Bezeichnung COM+
ver¨ffentlicht. COM+ ist dabei nichts anderes als die Kombination von DCOM und dem
o
Microsoft Transaction Server (MTS). Der MTS, der die Entwicklung von Middleware verein-
fachen soll (Abbildung 14 und 15), wurde zuvor als optionales und eigenst¨ndiges Produkt
a
verkauft. COM+ bezeichnet somit keine wirkliche Neuentwicklung des Standards, sondern
nur ein neu zusammengestelltes Microsoft Produkt.

26. 2.2 CORBA 21
Abbildung 12: Verteilte Anwendung mit DCOM
Der propriet¨re DCOM-Standard stellt eine f¨r Windows-Produkte optimierte Technik f¨r
a u u
die Umsetzung verteilter Systeme dar. Dementsprechend einfach gestaltet sich die Entwick-
lung auf der Microsoft-Plattform. Auf der anderen Seite bietet DCOM keine oder kaum
Unterst¨tzung f¨r andere Betriebssysteme. Die Firma Software AG portierte ActiveX un-
u u
ter dem Namen EntireX zwar auf verschiedene Plattformen wie Linux, Sun Solaris, Digital
Unix, HP-UX oder OS/390, eine komplette Kompatibilit¨t wurde hingegen noch nicht er-
a
reicht. Außerdem ist DCOM ein Bin¨rstandard. Die Folge ist eine enge Bindung an die
a
x86-Prozessorarchitektur.
¨
Alle diese Uberlegungen zeigen, dass DCOM in einem reinen Windows-System sicherlich eine
gute L¨sung darstellt. F¨r die Verwendung in heterogenen Systemen stellt CORBA jedoch
o u
die bessere Wahl dar.
SOAP Das Simple Open Access Protocol oder kurz SOAP ist die neuste Entwicklung aus
dem Hause Mircrosoft und definiert ein Transportprotokoll, das die wesentlichen Merkmale
von XML und HTTP in sich vereinigt. SOAP stellt einen wichtigen Pfeiler in Microsofts
.NET-Strategie dar. Ziel der .NET-Architektur und damit auch von SOAP ist es, die direkte
Bindung von Anwendungen an Microsoft Windows und an die x86-Prozessorarchitektur auf-
zuheben und eine Kommunikation uber die Grenzen des Microsoft Betriebssystems hinaus
¨
zu erm¨glichen. SOAP dient als Grundlage f¨r diese plattformunabh¨ngige Kommunikation
o u a
in heterogenen Systemen.
SOAP beruht im Prinzip auf der Verwendung von sog. Remote Procedure Calls (RPC). Wie
der Name bereits andeutet, werden mit dieser Technik entfernte Funktionsaufrufe erm¨glicht.
o
Durch gestiegene Sicherheitsbed¨rfnisse in Netzwerken bzw. dem Internet werden aber immer
u
mehr Netzwerke durch Firewalls gesichert. Diese Firewalls sch¨tzen an das WWW angeschlos-
u
sene Netzwerke, indem sie Ports blockieren und Anfragen filtern. In der Regel werden nur
Anfragen auf den Ports der Standard-Protokolle wie HTTP (Port 80), FTP (Port 21) oder

27. 2.2 CORBA 22
Abbildung 13: Aufbau des DCE
Abbildung 14: Kommunikation von COM-Objekten ohne MTS
Abbildung 15: Kommunikation von COM-Objekten mit MTS

28. 2.2 CORBA 23
SMTP (Port 25) zugelassen. Die Folge ist, dass RPC-Aufrufe des Clients von der Firewall
blockiert werden. Zur L¨sung dieses Problems verwendet SOAP den offenen Port 80, indem
o
RPC-Aufrufe uber HTTP verschickt werden. Hierzu bedient sich SOAP der Datenaustausch-
¨
sprache XML. Methodenaufrufe werden mit XML verpackt und dann uber HTTP verschickt.
¨
Eine SOAP-Nachricht definiert hierzu einen sog. SOAP Envelope (Abbildung 16). Dieser un-
Abbildung 16: Aufbau der SOAP Envelope
terteilt sich wiederum in einen SOAP Header und einen SOAP Body. Der Header enth¨lt a
Informationen dar¨ber, was f¨r eine Art von Nachricht vorliegt, den Empf¨nger der Nach-
u u a
richt und welche Bestandteile der Nachricht optional bzw. obligatorisch sein m¨ssen, um
u
eine g¨ltige SOAP-Nachricht darzustellen. Der SOAP-Body enth¨lt den eigentlichen Inhalt
u a
der Nachricht. Außerdem kann eine SOAP-Nachricht noch einen Block mit der Bezeichnung
Fault beinhalten. Dieser kann Fehlermeldungen enthalten, die Transport-Knoten w¨hrend der
a
¨
Ubertragung erzeugt haben.
Der eigentliche RPC-Aufruf wird als Nachricht in den SOAP-Body integriert. Um eine ent-
fernte Methode mit SOAP aufzurufen, sind die folgenden Angaben notwendig:
• Die URL des Zielknotens
• Der Name der aufzurufenden Methode
¨
• Ubergabe-Parameter f¨r die Methode
u
• Evtl. weitere Header-Informationen
Mit diesen Angaben wird eine SOAP-Nachricht im XML-Format erstellt und uber das Netz-
¨
werk verschickt. Dies geschieht normalerweise uber HTTP. SOAP kann jedoch auf jedem
¨
anderen Netzwerkprotokoll aufsetzen, das den Austausch von XML-Dokumenten erlaubt.
Die Verwendung von XML als kleinster gemeinsamer Nenner erm¨glicht es einerseits, SOAP
o
auf prinzipiell jeder Plattform auszuf¨hren. Andererseits entstehen gerade bei komplexen
u
Anwendungen u.U. schnell sehr große Datenmengen, da XML-Dateien neben den reinen In-
formationen große Mengen von Formatierungs- bzw. Gliederungsanweisungen in Form von
Tags besitzen. Beachtet man weiterhin den Aufwand f¨r das Parsen des Dokuments, erfolgt
u
die Verarbeitung dementsprechend langsamer als bei CORBA oder DCOM. SOAP bietet

29. 2.2 CORBA 24
daf¨r jedoch eine einfachere Zusammenarbeit mit Firewalls. Zusammenfassend l¨ßt sich sa-
u a
gen, dass Microsoft bei der Entwicklung von SOAP eher die Verwendung im Internet im Auge
hatte, w¨hrend DCOM in kleineren, homogenen LANs St¨rken offenbart.
a a
Als Erg¨nzung sei an dieser Stelle ein ¨hnliches Verfahren genannt, dass unter der Bezeich-
a a
nung XML-RPC bekannt geworden ist. Auch hier werden RPC-Anweisungen in XML ver-
packt. Diese Technologie ist im Gegensatz zu SOAP jedoch nicht in diesem Mase ausgereift
und findet deshalb nur in kleineren Projekten Anwendung.
2.2.5 Vorteile von CORBA
Stellt man CORBA und andere Techniken f¨r die Entwicklung verteilter Anwendungen ge-
u
gen¨ber, zeigen sich schnell die St¨rken des OMG-Standards. Die reine Socket-Verbindung
u a
bietet zwar eine schnelle Kommunikation, allerdings auf einer denkbar niedrigen Abstrakti-
onsebene. So sind neben vielen Verbindungseigenschaften ein eigenes Protokoll zu definieren.
Sockets finden demzufolge nur Verwendung in sehr kleinen Systemen. Bereits bei der Umset-
zung mittelgroßer Software zeigt sich schnell, dass Socket eine viel zu niedrige Abstraktion
bieten.
RMI bietet bereits eine sehr hohe Abstraktionsebene. Die Kommunikation erfolgt in einem
standardisieren Protokoll und Verbindsdetails werden f¨r den Entwickler verborgen, so dass
u
dieser sich keine Gedanken uber Einzelheiten der Kommunikation machen muss. RMI ist Teil
¨
der Programmiersprache Java und l¨uft deshalb mit der passenden JVM auf sehr vielen Platt-
a
formen. Bei der Verteilung von Java-Applikationen stellt RMI sicherlich die beste L¨sung dar.
o
Allerdings erm¨glicht RMI nicht das Zusammenspiel zwischen verschiedenen Programmier-
o
sprachen.
Microsofts DCOM-Architekur erm¨glicht im Gegensatz zu RMI zwar eine Kommunikati-
o
on zwischen Software-Komponenten, die in verschiedenen Sprachen implementiert werden
k¨nnen. Zugleich wurde auch hier eine hohe Abstraktionsebene erreicht. Der Nachteil von
o
DCOM ist hingegen die enge Bindung an das Microsoft-Betriebssystem und die Prozessor-
Architektur. In einer reinen Windows-Applikation bietet DCOM somit eine gute Alternative
zu CORBA. In heterogenen Systemen offenbart DCOM aber seine Schw¨chen. a
SOAP als neuste Entwicklung von Microsoft hebt die Bindung von DCOM auf. Die Kommu-
nikation uber XML ist nicht nur plattformunabh¨ngig, sondern erlaubt auch die Verbindung
¨ a
uber Port 80 und somit die Zusammenarbeit mit Firewalls. Die Unabh¨ngigkeit von XML
¨ a
wird jedoch mit einem hohen Mass an Overhead f¨r Strukturierungsbefehle bezahlt. Dadurch,
u
dass die XML-Beschreibungen gerade in großen Projekten sehr groß werden, und dass diese
Dokumente vor der Verarbeitung entsprechend geparst werden m¨ssen, zeigen sich deutliche
u
Performance-Schw¨chen bei SOAP. Mit dem selben Problem ist auch XML-RPC behaftet.
a
Außerdem bietet sich hier ein geringerer Funktionsumfang.
Mit CORBA l¨ßt sich Middleware auf einer sehr hohen Abstraktionsebene realisieren.
a
Dar¨ber hinaus bietet CORBA ein Optimum an Unabh¨ngigkeit. Der Standard ist weder
u a
an Betriebssysteme, noch an Programmiersprachen gebunden. Außerdem stellt CORBA mit
den CORBAfacilities und den CORBAservices viele sehr n¨tzliche Dienste zur Verf¨gung.
u u
Die OMG vereinigt das Know-How vieler Experten und definiert einen offenen Standard.
Resultat ist ein st¨ndig weiterentwickelter und verbesserter CORBA-Standard.
a