Your SlideShare is downloading. ×
DiplomarbeitEntwicklung eines webbasierten CORBA-Clients mit       Java Servlets im Umfeld betrieblicher                 S...
INHALTSVERZEICHNIS                                                                                                        ...
INHALTSVERZEICHNIS                                                                                                        ...
INHALTSVERZEICHNIS                                                                                                        ...
INHALTSVERZEICHNIS                                                                                                        ...
INHALTSVERZEICHNIS                                                                             19   Zusammenfassung und Au...
VorwortDie vorliegende Diplomarbeit beschreibt die Entwicklung einer Internet-Schnittstelle f¨r                           ...
1 EinleitungDie Industrie befindet sich zur Zeit im Wandel. Die traditionelle Wirtschaft bewegt sichhin zur Digital Economy...
4umgesetzt.   Kapitel 8 widmet sich der Bedienung der Web-Ober߬che. Der Aufbau sowie die                                 ...
2 Technologie2.1 Java ServletsServlets sind Java-Programme, die auf einem Web-Server laufen.W¨hrend Java urspr¨nglich f¨r ...
2.1   Java Servlets                                                                       6Bei CGI nimmt der Web-Server wi...
2.1   Java Servlets                                                                            7Speziell f¨r Perl-Skripte ...
2.1   Java Servlets                                                                           8                      Abbil...
2.1   Java Servlets                                                                       9nannt ColdFusion Markup Languag...
2.1   Java Servlets                                                                           10    Effizienz Servlets laufe...
2.1   Java Servlets                                                                                 11der Fall ist. Oftmal...
2.2     CORBA                                                                             12vom Server somit als Servlet b...
2.2   CORBA                                                                            13                  Abbildung 5: Au...
2.2    CORBA                                                                               14verteilten Anwendungen ben¨ti...
2.2   CORBA                                                                              15Object Request Broker Die OMG d...
2.2     CORBA                                                                              16                          Abb...
2.2    CORBA                                                                                 17im Rahmen von Unix BSD 4.2 ...
2.2    CORBA                                                                             18      • Entwurf einer Serverkla...
2.2   CORBA                                                                              19Der Nachteil gegen¨ber CORBA is...
2.2   CORBA                                                                              20Implementierungssprachen und eb...
2.2   CORBA                                                                             21                     Abbildung 1...
2.2   CORBA                                                           22                           Abbildung 13: Aufbau de...
2.2    CORBA                                                                          23SMTP (Port 25) zugelassen. Die Fol...
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Diplomarbeit
Upcoming SlideShare
Loading in...5
×

Diplomarbeit

7,530

Published on

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.

Published in: Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
7,530
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
10
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Transcript of "Diplomarbeit"

  1. 1. DiplomarbeitEntwicklung 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. 2. INHALTSVERZEICHNIS iInhaltsverzeichnis1 Einleitung 32 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 . . . . . . . . . . . . . . . . . . . 253 Varial World Edition 26 3.1 Leistungsumfang VWE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.2 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.3 Das Web-Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 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-Oberfl¨che . a . . . . . . . . . . . . . . . . . . . 475 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. 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 . . . . . . . . . . . . . . . . . . . . . 796 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. 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. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1607 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1958 Aufbau und Bedienung der Web-Oberfl¨che a 196
  6. 6. INHALTSVERZEICHNIS 19 Zusammenfassung und Ausblicke 197A Anhang 199 Tabellenverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 A.1 Abbildungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 A.2 Glossar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
  7. 7. VorwortDie vorliegende Diplomarbeit beschreibt die Entwicklung einer Internet-Schnittstelle f¨r udas 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 awar. Aus meinem Interesse sowohl an modernen Internet-Technologien als auch an der Java- ¨Programmierung und den strategischen Uberlegungen des Unternehmens Varial entstanddie Idee, eine Anbindung der World Edition f¨r das World Wide Web zu konstruieren. Der uGrundstein f¨r VWE-Web war gelegt. u Die Arbeit ist schließlich recht umfangreich ausgefallen, da sie neben den verwendetenTechnologien sowohl die Bedienung des Web-Interfaces als auch dessen Entwicklung be-schreibt. Durch die Dokumentation aller wichtigen Klassen und die beispielhafte Umsetzungeiner Anwendung, soll es dem Leser erm¨glicht werden, die entwickelte API selbstst¨ndig zu o averwenden 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 ubesonderer 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 einsehr 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 uKorrekturlesen der Arbeit opferte. Auch bei meinen Kommilitonen Maik, der neben derKorrektur f¨r viele interessante fachliche Diskussionen zur Stelle war, und Tobi f¨r seine u uErkl¨rungen zu DCOM, SOAP & Co m¨chte ich mich an dieser Stelle herzlich bedanken. a oIhr wart mir eine große Hilfe. Ebenfalls haben die vielen unz¨hligen User diverser Internet-Foren, wie vorzugweiße dem aSELFHTML-Forum, zum Gelingen dieser Arbeit beigetragen. Danke f¨r die vielen guten uRatschl¨ge, Meinungen und Kritiken. a Außerdem sei meinen Mitmenschen gedankt, die mich in den letzen Monaten unterst¨tzt, ugelobt, ertragen und getr¨stet haben und mit ihrem Verst¨ndnis den n¨tigen Freiraum f¨r o a o udie Erstellung der Arbeit gegeben haben und damit deren Realisierung erst erm¨glichten. Zu oguter Letzt gilt mein besonderer Dank nat¨rlich Julia, die mir nicht nur in Zeiten technischer uSchwierigkeiten 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 mancherTiefphase und f¨r die Fertigstellung der Arbeit lieferte. Danke! u
  8. 8. 1 EinleitungDie Industrie befindet sich zur Zeit im Wandel. Die traditionelle Wirtschaft bewegt sichhin 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 uInformations- und Kommunikationsmedium schlechthin. W¨hrend vor Jahren das Internet lediglich statische Inhalte zur Verf¨gung stellte, nimmt a umittlerweile mehr und mehr dynamischer Content das Netz ein. Das Potential reicht jedochweit uber die M¨glichkeiten eines einfachen eShops oder eines G¨stebuchs hinaus. So bieten ¨ o asich auch einem modernen ERP-System interessante M¨glichkeiten, das Internet f¨r eine o uunternehmens- und weltweite Abwicklung von Gesch¨ftsf¨llen zu nutzen. a a Diese Diplomarbeit beschreibt hierzu die Entwicklung eines Systems, mit dessen Hilfewebbasierte 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. DerServer wird in Java implementiert, w¨hrend clientseitig C++ zum Einsatz kommt. aIm Rahmen der Diplomarbeit wird die Software um die M¨glichkeit erweitert, auf aus- ogew¨hlte Datenbest¨nde mittels Web-Browser zugreifen zu k¨nnen. Auf diese Weise wird a a oes dem Benutzer erm¨glicht, VWE via Intra-, Extra- oder Internet von jedem beliebigen oArbeitsplatz zu nutzen. Hierbei kommen Java Servlets zum Einsatz. Die Arbeit gliedert sich in neun Abschnitte. Nach dieser Einf¨hrung werden im zweiten uKapitel zun¨chst die beiden Techniken CORBA und Java Servlets vorgestellt. Hierbei werden ainsbesondere Alternativen zu diesen Technologien aufgezeigt und diskutiert. Die Vorteile desverwendeten L¨sungsansatzes werden herausgestellt und die Entscheidung f¨r CORBA und o uJava Servlets begr¨ndet. u Kapitel 3 beschreibt das ERP-System VWE. Es wird ein Einblick in den Leistungsumfangund den Aufbau von VWE gegeben. Außerdem wird gezeigt, wie ein Web-Interface diebestehenden Funktionalit¨ten sinnvoll erweitern bzw. erg¨nzen kann. a a Das vierte Kapitel fasst anschließend alle Anforderungen, die an eine Browser-Oberfl¨che agestellt werden, zusammen. Kapitel 5 zeigt, wie diese Anforderungen umgesetzt wurden undwelche Fragestellungen und Probleme sich bei der Entwicklung ergaben. Kapitel 6 erl¨utert die Komponenten, die zur Realisierung entwickelt wurden. Zentrale aPackete werden aufgef¨hrt und die Funktionen der Klassen im Einzelnen erl¨utert. u a Im siebten Kapitel wird aufgezeigt, wie die entwickelten Komponenten zur Realisierungeines Use-Cases eingesetzt werden k¨nnen. Hier wird eine kleine Anwendung beispielhaft o
  9. 9. 4umgesetzt. Kapitel 8 widmet sich der Bedienung der Web-Oberfl¨che. Der Aufbau sowie die aHandhabung des Web-Interfaces werden erl¨utert. a Das abschließende neunte Kapitel fasst noch einmal alle gewonnenen Erkenntnissezusammen und bietet einen Ausblick auf zuk¨nftige Entwicklungen. u
  10. 10. 2 Technologie2.1 Java ServletsServlets 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 usp¨ter das Interesse an Java durch den Einsatz als Applets. Bei Applets handelt es sich um aJava-Code, der in einem Web-Umfeld clientseitig, also im Browser, ausgef¨hrt wird. Dank uJavas Plattformunabh¨ngigkeit ist der Byte-Code auf jedem Betriebssytem ausf¨hrbar. Dies a uf¨hrte zusammen mit der Tatsache, dass eine solche Funktionalit¨t im Browser bislang u aunbekannt 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 ukeinesfalls auf die Behandlung von HTTP-Anfragen beschr¨nkt. Denkbar w¨re auch, ein a aServlet in einen Mail- oder FTP-Server einzubetten, um dessen Funktionalit¨t zu erweitern. aIn der Praxis bilden solche Einsatzm¨glichkeiten jedoch eher die Ausnahme, so dass Servlets ouberwiegend f¨r HTTP-Anfragen verwendet werden.¨ u2.1.1 EntstehungsgeschichteUrspr¨nglich bestand die Aufgabe des Internets darin, Informationen in Form von statischen uSeiten zur Verf¨gung zu stellen. Der Web-Server konnte die Anfrage eines Clients durch u ¨die einfache Ubermittlung vorgefertigter Dokumente befriedigen. Mittlerweile hat sich dasInternet jedoch stark gewandelt, so dass die Bereitstellung statischer Seiten u.U. nicht mehrausreichend ist, sondern dass f¨r jede Anfrage eine andere Seite generiert werden muss. Es ugibt 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 anach dynamischen Web-Seiten entsprachen, gesucht.2.1.2 Alternative Ans¨tze aCommon Gateway Interface Das Common Gateway Interface (CGI) war die erste Techno-logie, die das Erzeugen von dynamischen Web-Seiten erm¨glichte. o 5
  11. 11. 2.1 Java Servlets 6Bei CGI nimmt der Web-Server wie gewohnt eine Client-Anfrage entgegen, startet dann aberein externes Programm und leitet die Bearbeitung an dieses Programm weiter. Das Programmgeneriert daraufhin die Antwortseite. Diese Seite kann nun vom Web-Server an den Clientgesendet werden.Mit CGI k¨nnen dynamsiche Seiten in fast jeder Programmiersprache erzeugt werden. CGI oruft lediglich ein Programm auf und erwartet eine R¨ckgabe, die an den Browser geschickt uwird. In welcher Sprache das Programm geschrieben ist spielt hierbei keine Rolle. Allerdingshat sich Perl als Programmiersprache durchgestetzt, da Perl m¨chtige Befehle zur Verar- abeitung von Texten bereitstellt (u.a. Regular Expressions), die sich im Umfeld von CGI alsgroße Hilfe herausstellen. Auf diese Weise war es erstmals m¨glich, dynamsiche Seiten zu oerzeugen. Schnell verbreitete sich CGI und immer mehr Web-Server stellten dieses Interfacezur Verf¨gung. uDer Nachteil von CGI ist jedoch, dass nicht gerade sparsam mit Serverresourcen umgegangenwird. F¨r jede Anfrage wird das verarbeitende Programm als eigener Prozess gestartet. Bei uhochfrequentierten 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 ubei CGI jedesmal der Perl-Interpreter gestartet werden. Abbildung 1 zeigt die Funktionsweisevon 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 obeispielsweise nicht in das Logfile des Servers schreiben. Außerdem k¨nnen CGI-Skripte nur orecht 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 aDie Firma Open Market entwickelte eine Alternative namens FastCGI, die im Gegensatz zuCGI ein Programm immer im selben Prozess laufen l¨sst. So wird nur noch ein Prozess pro aProgramm, und nicht mehr pro Anfrage gestartet. Dies f¨hrt zwar zu einer Performance- uVerbesserung, 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. 12. 2.1 Java Servlets 7Speziell f¨r Perl-Skripte auf dem Apache-Server wurde mod perl entwickelt. Bei mod perl u Abbildung 2: Web-Server mit FastCGIhandelt es sich um ein Modul f¨r den Apache-Server, das den Perl-Interpreter direkt in den uServer einbettet. Perl-Skripte laufen so wesentlich schneller als zuvor. Dieser Ansatz ist jedochausschließlich f¨r Perl-Skripte, die auf dem Apache-Server laufen, geeignet. uServer-Extension-API Einige Serverhersteller entwickelten sog. Extension-APIs f¨r ihre uWeb-Server. Auf diese Weise k¨nnen Server um weitere Funktionalit¨ten erweitert werden. o aBeispiele hierf¨r sind ISAPI f¨r Microsofts Internet Information Server (IIS) oder WAI (ur- u uspr¨nglich ver¨ffentlicht unter der Bezeichnung NSAPI) von iPlanet/Netscape f¨r deren Ser- u o uver. Abbildung 3 stellt die Funktionsweise der Server-Extensions dar. Diese Erweiterungen sind i.d.R. in C++ geschrieben, was eine hohe Performance zur Folgehat. Jedoch hat auch diese L¨sung einige Nachteile: Durch die enge Verbindung mit dem Web- oServer kann eine abgest¨rzte Server-Erweiterung den kompletten Server lahm legen. Außer- u ¨dem sind Erweiterungen immer auf einen bestimmten Servertyp festgelegt. Eine Ubertragungauf andere Server ist somit nicht m¨glich. oServer Side Includes Mit Hilfe von Server Side Includes (SSI) k¨nnen dynamische Infor- omation direkt innerhalb von HTML-Dateien eingebunden werden. Server Side Includes sindgenerell 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 uubertragbar. Jedoch ist der Funktionsumfang recht beschr¨nkt, so dass SSI nicht f¨r gr¨ßere¨ a u oProjekte geeignet ist.ASP, PHP, SSJS Eine weitere M¨glichkeit zum Erstellen dynamischer Web-Seiten bieten odie Technologien ASP (Active Server Pages), PHP (benannt nach einem Vor¨ngerprodukt anamens Personal Homepage) oder auch SSJS (Server Side JavaScript).Bei dieser Technik werden Code-Fragmente in HTML-Seiten eingebettet. Wird eine Seite
  13. 13. 2.1 Java Servlets 8 Abbildung 3: Web-Server mit Server-Extension-APIangefordert, wird der eingebettete Code zuerst vom Web-Server ausgef¨hrt, bevor er zum uClient geschickt wird.Diese Technik ist vor allem hilfreich bei Seiten, die nur sehr wenig dynamischen Inhalt bietenund uberwiegend aus statischen Teilen bestehen, da hier lediglich ein paar zus¨tzliche Zeilen ¨ ain den bestehenden HTML-Code eingef¨gt werden m¨ssen. Ein Beispiel ist ein Seite, die den u uBesucher namentlich begr¨ßt, sonst aber keine benutzerabh¨ngigen Informationen enth¨lt. u a aEin anderes Beispiel ist ein Besucherz¨hler auf einer sonst statischen Seite. aBesteht die Seite jedoch aus sehr vielen dymanischen Teilen, zeigen sich die Schw¨chen dieser aTechnologie. 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. ¨ oAußerdem sind ASP und SSJS serverabh¨ngig. So verwendet ASP in der Regel VBScript aoder JScript und l¨uft nur auf Microsofts IIS. Zwar gibt es bereits kommerzielle Software wie az.B. InstantASP von Halcyon Software oder OpenASP von ActiveScripting.org, die ASP auchauf anderen Servern m¨glich macht, jedoch ist dies mit großem Aufwand verbunden und bis oheute nicht vollkommen ausgereift. SSJS wurde von iPlanet/Netscape entwickelt und bettetJavaScript-Fraktmente in HTML ein. SSJS l¨uft jedoch ausschließlich auf iPlanet/Netscape- aServern.Lediglich PHP, das sich stark an dem vielen CGI-Programmiern bekannte Perl anlehnt, l¨uft aauf nahezu allen Servern. So verwundert es auch nicht, dass PHP die verbreitetste dieserdrei Sprachen ist. Der Nachteil, dass große Projekte schnell un¨bersichtlich werden, bleibt uallerdings 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. 14. 2.1 Java Servlets 9nannt 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 amittlerweile viele n¨tzliche Features, die jedoch in ihrer M¨chtigkeit der Java-API deutlich u aunterlegen sind.Die neuste Version von ColdFusion er¨ffnet jedoch die M¨glichkeit, benutzerdefinierte Ele- o omente zu entwickeln, die mit JavaServlets kommunizieren k¨nnen. ColdFusion bietet sich osomit als Erg¨nzung von Servlets an, wobei allerdings zu abzuw¨gen ist, ob die Verwendung a avon JavaServer Pages, die sp¨ter beschrieben werden, nicht die bessere Alternative ist. aServlets Ein Java Servlet l¨uft ¨hnlich wie Server-Extensions im Web-Server und erweitert a adessen Funktionalit¨t. Jedoch laufen Servlets als Java-Programme in einer Java Virtual Ma- achine (JVM), so dass sie erstens sicher sind und zweitens, dank Byte-Code, leicht auf anderePlattformen ubertragen werden k¨nnen. Servlet-Unterst¨tzungen sind bereits f¨r viele Web- ¨ o u uServer erh¨ltlich. aDer große Vorteil von Servlets besteht darin, dass Client-Anfragen nicht zu einer Unmengevon Prozessen f¨hren. Vielmehr ist es mit Servlets m¨glich, separate Threads zu erzeugen, u odie in ein und dem selben Prozess laufen. Abbildung 4 zeigt diese Vorgehensweise. Denkbar Abbildung 4: Web-Server mit Servlet-Unterst¨tzung uw¨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. oGleichzeitig ist es Servlets m¨glich, eng mit dem Web-Server zusammen zu arbeiten, da sie odirekt in diesen eingebettet werden. Eine solche Art der Kommunikation w¨re beispielsweise amit CGI nicht m¨glich. oDies alles f¨hrt zu den folgenden entscheidenden Vorteilen: u
  15. 15. 2.1 Java Servlets 10 Effizienz Servlets laufen im Gegensatz zu CGI-Skripts nicht als schwergewichtigerBetriebssystem-Prozess, sondern als resourcenschonender Thread. CGI-Progamme m¨ssten ubei N parallelen Anfragen N mal in den Arbeitsspeicher geladen werden. Bei Servlets g¨be aes 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- ufrage der (Perl-)Interpreter erneut geladen werden muss, kann ein Servlet somit, wenn es ersteinmal geladen wurde, jede weiter Anfrage quasi unmittelbar ausf¨hren. Weiterhin ist es Serv- ulets m¨glich, einen Zustand uber mehrere Anfragen hinweg bei zu behalten. Daten k¨nnen o ¨ oals Klassenvariablen zwischengespeichert werden, vorangegangene Berechnungen k¨nnen ge- ocachet werden oder externe Resourcen, wie z.B. eine Datenbank-Verbindung, k¨nnen gehalten owerden, 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 oDatenbank-Verbindungen mit JDBC, Multithreading, Datenkomprimierung, Internationali-sierung, Grafikerzeugung oder Serialisierung sind nur einige Beispiele f¨r die M¨glichkeiten, u odie sich Servlets bieten. Kommuniziert ein Servlet mit einem Applet, k¨nnte auf die M¨glich- o okeit von Remote Method Invokation (RMI) zur¨ckgegriffen werden. Zus¨tzlich zu den auf- u agef¨hrten Gebieten decken Klassen von Drittanbietern fast jedes andere Einsatzgebiet ab. uDas Parsen von XML, die Verwendung von regul¨ren Ausdr¨cken oder das Erzeugen von a uDiagrammen seien als Beispiel genannt.Alles in allem bietet die Java-API eine M¨chtigkeit, die kaum oder nur schwer von CGI- aProgrammen oder Skriptsprachen erreicht werden kann. Portierbarkeit Da Servlets in Java geschrieben sind, k¨nnen sie problemlos zwischen overschiedenen 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 aeinen 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 uerst entstehen.Javas Garbage Collector und das Fehlen von Zeigern stellt sicher, dass Speicherprobleme wiebeispielsweise Memory Leaks, ung¨ltige oder gar b¨swillig ver¨nderte Pointer, nicht m¨glich u o a osind. In C++ k¨nnte beispielsweise auf die 1000-te Position eines Arrays mit nur 200 Ein- otr¨gen zugegriffen werden. Dies w¨rde dazu f¨hren, dass so in Bereiche des Arbeitsspeichers a u ugeschrieben w¨rde, auf die sonst kein Zugriff best¨nde. Tats¨chlich ist dies eine oft benutzte u u aHintert¨r f¨r Angriffe. Servlets bieten diese M¨glichkeit nicht, da automatsich Array-Grenzen u u ouberpr¨ft werden.¨ uFehler 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 ueine Exception, die entweder vom Servlet selbst oder aber vom Server abgefangen werden.Ein Absturz des Servers ist nicht mehr m¨glich. oZu guter Letzt werden bei Servlets keine externen Programme ausgef¨hrt, wie es bei CGI u
  16. 16. 2.1 Java Servlets 11der 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 uverschickt, indem das Unix-Programm sendmail verwendet wird. Auf den ersten Blick istes ausreichend, die Adresse, die der Benutzer in ein Formular eingegeben hat, an sendmailweiter zu reichen. Da jedoch auch mehrere Befehle in einer Unix-Shell mit einem Semikolongetrennt 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 ammo@varial.de;rm -rf /. Resultat w¨re neben dem Senden einer Mail auch die Ausf¨hrung a udes rm-Befehls, der die Festplatte des Servers l¨schen w¨rde. o uDies ist nur eines von vielen Beispielen, das zeigt, dass die Ausf¨hrung von externen Pro- ugrammen ein erhebliches Sicherheitsrisiko darstellt. Servlets hingegen verwenden keine Shell,selbst dann nicht, wenn ein Remote-Systemaufruf ausgef¨hrt wird. uMan 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 oURLs in absolute Pfadangaben ubersetzen oder auch Benutzerberechtigungen uberpr¨fen. ¨ ¨ uCGI-Programme laufen hingegen getrennt vom eigentlichen Server, so dass eine solche Artder Zusammenarbeit dort unm¨glich ist. oJavaServerPages JavaServer Pages oder kurz JSP verbinden die Vorteile von Servlets, Cold-Fusion und eingebetteten Skript-Sprachen. JavaServer Pages ¨hneln vom Aufbau recht stark adem ASP- oder PHP-Ansatz. In statischen HTML-Code 1 werden Elemente f¨ r dynamischen uInhalt eingef¨gt. Seiten, die nur wenig dynamische Teile beinhalten, k¨nnen so ohne großen u oAufwand erstellt werden.Sollte der dynamische Inhalt einen gr¨ßeren Teil der Seite ausmachen, k¨nnen JSP-Seiten o oleicht mit Servlets zusammen arbeiten. Hierzu k¨nnen sog. Taglibs entwickelt werden. Dies osind Bibliotheken mit benutzerdefinierten Elementen. Dem Entwickler wird es auf diese Weiseerm¨glicht, eigene Tags zu entwerfen. Die Funktion der Tags wird von einer Java-Klasse im- oplementiert. Der Vorteil dieser Vorgehensweise ist, dass Ausgabe (JSP) und Funktion (Java-Klasse) klar voneinander getrennt sind. Die JSP-Seite unterscheidet sich vom Aufbau herkaum von herk¨mmlichen HTML-Seiten, da alle Elemente der XML-Syntax folgen. So k¨nnen o oWeb-Designer, die mit dem Umgang mit HTML-Seiten vertraut sind, fast ohne Einarbei-tungszeit komplexe Seiten gestallten. Die Funktionalit¨t wird hingegen von Programmierern aubernommen, die sich ihrerseits nicht mit dem Seitenlayout belasten m¨ssen. Beide Parteien¨ uerstellen so gemeinsam ein Projekt, arbeiten aber unabh¨ngig von einander. aMit JSP und Taglibs kann so spielend einfach das Seitenlayout ge¨ndert werden, ohne dass adie Programmlogik angepasst werden muss und umgekehrt. Dies macht auch die Pflege einesProjekts denkbar einfach.Der JSP-Ansatz beinhaltet dar¨ber hinaus auch alle Vorteile von Servlets, da es sich bei JSP- uSeiten nur um eine andere Darstellung von Servlets handelt. JSP-Code wird bei erstmaligerAusf¨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 awerden. Denkbar w¨ren ebenso XML- oder L TEX-Dokumente. a A 2 JSP-Code kann auch vorkompiliert werden.
  17. 17. 2.2 CORBA 12vom Server somit als Servlet betrachtet, sie sind also genauso effizient, m¨chtig, portierbar aund sicher wie Servlets.2.1.3 Die ZukunftMit Java Servlets setzt die Programmiersprache Java ihren Siegeszug der letzen Jahre weiterfort. Java besticht durch die M¨chtigkeit und Eleganz der Sprache, die eine saubere, objek- atorientierte, modulare und einfache Programmierung erm¨glicht. Mit Java Servlets k¨nnen o odiese 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 ulets auf lange Sicht auf Grund ihrer Performance-Vorteile und Portierbarkeit den weitverbrei-teten CGI-Ansatz abl¨sen werden. o2.2 CORBADie Common Object Request Broker Architecture oder kurz CORBA ist eine Spezifikation,die von der Object Managment Group (OMG) entwickelt wurde. CORBA unterst¨tzt die uRealisierung verteilter Objekte. So k¨nnen Objekte zusammen agieren ohne voneinander zu owissen, wo sich das Gegen¨ber befindet, oder in welcher Sprache es implementiert wurde. uCORBA ist in der letzten Zeit immer mehr zu dem Standard f¨r die Entwicklung von Middle- uware geworden. Die OMG umfasst mittlerweile mehr als 800 Firmen, die das ganze Spektrumder Computerindustrie repr¨sentieren. Die einzige bemerkenswerte Ausnahme bildet Micro- asoft mit einem eigenen konkurierenden Objektbus namens Distributed Component ObjectModel (DCOM).2.2.1 Die OMGOMG ist die Abk¨rzung f¨r Object Managment Group. Sie wurde im April 1989 gegr¨ndet u u uund bestand urspr¨nglich aus 11 Firmen, darunter u.a. 3Com Corporation, American Air- ulines, Canon Inc., Data General, Hewlett-Packard, Philips Telecommunications N.V., SunMicrosystems und Unisys Corporation. Mittlerweile umfasst die OMG uber 800 Mitglieder. ¨Auf der Basis eines Vorschlags, Request for Comment (RFC) genannt, wird zun¨chst disku- atiert, was standardisiert werden soll. Dann k¨nnen zu einem festgelegten Anforderungsprofil, oals Request for Proposal (RFP) bezeichnet, Technologien zur Standardisierung vorgeschlagenwerden. Ziel der OMG ist es, herstellerunabh¨ngige, technisch ausgereifte und kommerziell aerfolgreiche Spezifikationen zu erarbeiten und zu standardisieren. Diese Spezifikationen sollenes erm¨glichen, objektorientierte Modelle unter Abstraktion von der verwendeten Hardware ound des Betriebsystems zu gestalten.2.2.2 Object Management ArchitectureDie OMG ver¨ffentlichte im Herbst 1990 die Object Management Architecture (OMA) im oRahmen 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 aEinzelheiten der sog. Common Facilities hinzugef¨gt. Der endg¨ltige Stand der Spezifikation u uist in Abbildung 5 dargestellt. Das Bild zeigt den Aufbau der OMA. Die Architektur gliedert
  18. 18. 2.2 CORBA 13 Abbildung 5: Aufbau der Object Management Architecturesich 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 aDinge des realen Lebens. Wichtige Einzelheiten werden mit entsprechenden Attributen mo-deliert, unwichtige Details wegabstrahiert. Im Folgendem werden diese Objekte, bzw. dieJava-Klassen, die diese implementieren, als Business-Objekte (BO) bezeichnet.Die Business-Objekte werden speziell f¨r die jeweilige Anwendung programmiert. Folglich uwerden diese von der OMG nicht n¨her spezifiziert. Die Business Object Task Force der aOMG definiert lediglich, dass ein BO eine Komponente der Applikationsebene ist, die sichentsprechend des Prinzips der Wiederverwendbarkeit, vielseitig einsetzen l¨ßt. aCommon 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 uzur Verf¨gung. Dazu z¨hlen beispielsweise grafische Benutzeroberfl¨chen, Drucker- und Da- u a atenbankdienste, mobile Agenten oder auch Frameworks f¨r Internationalisierung. Das Reper- utoire an CORBAfacilities wird laufend weiterentwickelt und wird in Zukunft praktisch jedenverteilten 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 usind Sammlungen von elementare Diensten auf Systemebene, die f¨r die Entwicklung von u
  19. 19. 2.2 CORBA 14verteilten 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. 20. 2.2 CORBA 15Object Request Broker Die OMG definiert mit CORBA einen offenen Standard, liefertselbst jedoch keine Implementierung. Software, die die CORBA-Spezifikation implementiert,heißt Object Request Broker (ORB). Als Beispiele seien hier VisiBroker von Visigenic, Orbixvon Iona oder Suns Java IDL genannt.Der ORB trennt die Anfrage eines Services (Client) von dessen Bereitstellung (Server). DerORB ist das Herzst¨ck der CORBA-Technologie. Alle Aufrufe von Objekten (ob lokal oder uentfernt) 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 uwird und leitet Auftr¨ge an diese Objekte weiter. Dies geschieht automatisch, ohne dass sich ader Entwickler Gedanken dar¨ber machen muss, wo und ob ein Serverobjekt zur Zeit aktiv uist. Der Objektadapter sorgt daf¨r, dass aus Sicht des Clients alle Serverobjekte aktiv und ulokal 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 uwar, entwickelten sich viele herstellerabh¨ngige BOAs, die zwar alle den CORBA-Standard aerf¨llten, jedoch u.U. nicht richtig zusammen arbeiteten. Aus diesem Grunde wurde CORBA u2.0 um den Portable Object Adapter (POA) erweitert. Durch zus¨tzliche Spezifikationen der aOMG ist nun sichergestellt, dass POAs zueinander kompatibel sind, w¨hrend das bei BOAs anicht unbedingt der Fall sein muss.Da die ORB-Implementierungen an die Spezifikation der OMG gebunden sind, k¨nnen ORBs overschiedener 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, udass 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, adie als gemeinsames Backbone-Protokoll dienen.2.2.3 Interface Definition LanguageCORBA ist ein selbstbeschreibendes System. Damit Objekte sprachenunabh¨ngig mitein- aander agieren k¨nnen, wird klar zwischen Schnittstellenbeschreibung und Implementierung ounterschieden. Hierzu dient die Interface Definition Language (IDL). Mit dieser neutralenSprache, deren Syntax an C++ angelehnt ist, werden CORBA-Objekte mit ihren Attributen
  21. 21. 2.2 CORBA 16 Abbildung 7: ORB-Verbindung mit IIOP ¨und Funktionen (inkl. Uber- und R¨ckgabe-Parameter und Fehlerbehandlungen) beschrieben. uKomponenten, die in IDL geschrieben sind, sollten zu anderen Sprachen, Betriebssystemenund Netzwerken hin kompatibel sein (Abbildung 8). Hierzu generiert der Compiler aus der Abbildung 8: Sprachunanh¨ngigkeit durch IDL aIDL-Beschreibung f¨r die jeweilige Programmiersprache passende Interfaces. Diese Interfa- uces heißen serverseitig Skeletons, w¨hrend sie clientseitig als Stubs bezeichnet werden. Diese aInterfaces 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 ound Java-Server implementiert und auf verschiedenen Rechnern platziert wird. Die IDL stellthierf¨r die programmiersprachenunabh¨ngige Verbindung her, der ORB sorgt f¨r die Loka- u a ulisierung der verteilten Objekte. F¨r den Programmierer gestaltet sich das Szenario dank uCORBA v¨llig transparent. o2.2.4 Alternative Ans¨tze aSockets Sockets stellen die wohl primitivste Art der Netzwerkkommunikation dar. EinSocket ist ein Peer-to-Peer-Kommunikationsendpunkt uber TCP/IP. 1981 wurden Sockets ¨
  22. 22. 2.2 CORBA 17im 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. uEin Socket besteht aus einem Namen und einer Netzwerkadresse und l¨ßt sich in eine von adrei 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 aucheinige Nachteile. So bieten Sockets weder Parameter Marshaling noch dynamische Service-Bindung. Der Entwickler muss eigene Protokolle entwickeln, die die Methodenaufrufe desClients den Methoden des Servers zuordnen. Bedenkt man, dass große Systeme leicht einigehundert Funktionen umfassen, k¨nnte dies zu einem gewaltigen Aufwand f¨hren. Die Pflege o uund Wartung der Software w¨rde schnell eine un¨berschaubare Aufgabe. Folglich stellen u uSockets f¨r die Anforderung moderner Systeme keine ausreichende L¨sung dar. u oRMI Remote Method Invocation oder kurz RMI ist eine von der Firma Sun Microsystemsentwickelte 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 oEntwicklung von RMI war es, ein verteiltes Objektmodel in Java zu integrieren, ohne dabeidas 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 oClient-Server-Architektur, die sich f¨r den Entwickler fast vollkommen transparent gestaltet. uRMI 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. 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. uGenau 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- amunikation transparent erscheinen lassen. Der Client hat Zugriff auf eine Stub-Klasse, diedas Server-Interface implementiert. Methodenaufrufe des Stubs werden uber das Netzwerk ¨ubertragen und von dem Gegenst¨ck auf der Serverseite, dem Skeleton, an das jeweilige¨ uServer-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 aden Anforderungen besser gerecht wird. RMI stellt eine wesentlich einfachere Architektur alsCORBA zur Verf¨gung, was dazu f¨hrt, dass RMI besonders f¨r kleinere Projekte geeignet ist. u u uDar¨ber hinaus ist es einfacher zu erlernen und direkt in neueren JDK-Versionen eingebettet. u
  24. 24. 2.2 CORBA 19Der Nachteil gegen¨ber CORBA ist allerdings, dass gerade große Projekte durch verschie- udene CORBA-Features (CORBAservices und CORBAfacilities) besser mit die Technologieder OMG umsetzbar sind. Außerdem k¨nnen mit RMI nur reine Java-Projekte implementiert owerden. Eine Kommunikation zwischen Objekte, die in unterscheidlichen Programmierspra-chen geschrieben wurden, ist im Gegensatz zu CORBA nicht m¨glich. RMI stellt folglich bei oheterogenen Projekten keine Alternative dar.DCOM Das Distributed Component Object Model (DCOM) ist Microsofts Antwort auf denOMG-Standard. Mit DCOM stellt Microsoft eine weitere M¨glichkeit zur Realisierung verteil- oter Anwendungen zur Verf¨gung. Dabei gehen die Wurzeln von DCOM weit in die Vergangen- uheit zur¨ck. Strenggenommen wurde 1987 mit Einf¨hrung der Zwischenablage in Windows u uder Grundstein f¨r DCOM gelegt (Abbildung 10). Mit der Zwischenablage war es erstmals u Abbildung 10: Entwicklung von DCOM aus COM und RPCm¨glich, Texte aus einem Programm zu kopieren und in anderen Applikationen einzusetzen. o1992 wurde diese Technik erweitert und als OLE (Object Linking & Embedding) ver¨ffent-olicht. Nun war es nicht nur m¨glich, Texte zwischen zwei Applikationen auszutauschen, son- odern es wurde gar erm¨glicht, komplexere Objekte durch die Zwischenablage zu kopieren. oEin oft zitiertes Beispiel ist das Einbinden einer Excel-Tabelle in einem Word-Dokument. BeiDoppelklick 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 ¨ ¨ aAnwendungen jedoch unabh¨ngig von einander entwickelt werden, bedarf es einem standar- adisierten Verfahrens, das die Kommunikation zwischen den Windows-Applikationen regelt.OLE bot mit DDE (Dynamic Data Exchange) die grundlegende Kommunikationsschicht f¨r uden Datenaustausch. Da sich DDE jedoch schon schnell als zu langsam und unflexibel her-ausstellte, konnte sich die Technologie nicht wie gew¨nscht durchsetzen. uMicrosoft entwickelte daraufhin OLE 2. Die Fragestellung, wie zwei Windows-Programmemiteinander Daten austauschen k¨nnen, wurde jetzt ein wenig ausgeweitet. Als zentrales Ziel owurde definiert, dass eine Applikation die Funktionalit¨t beliebiger bin¨rer Komponenten in a aeiner objektorientierten Art und Weise nutzen solle. Dies unabh¨ngig von den verwendeten a
  25. 25. 2.2 CORBA 20Implementierungssprachen 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 uCOM bilden sollte.COM ist die Kurzbezeichnung f¨r Component Object Model und definiert einen Standard f¨r u udie 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 aSchnittstellen zur Verf¨gung stellt. Bei der Verwendung der Komponente ist es hierbei v¨llig u oegal, wie und in welcher Programmiersprache sie geschrieben ist. Mit Hilfe der Interfaceskann die Komponente von anderen Anwendungen genutzt werden ohne den inneren Aufbauzu kennen (Abbildung 11). Schnell fand ein neues Zauberwort Einzug in die Windows-Welt: ActiveX. ActiveX beinhaltet Abbildung 11: Software-Komponente nach COM: Aufbau und Zugriffdabei lediglich COM. Der Grund f¨r die babylonische Sprachverwirrung, in der auch VBX, udas Software-Komponenten f¨r Visual-Basic-Steuerelemente beschreibt, und das allgemeinere uOCX, 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 ualte Technologie. Mit Windows NT und einer Version f¨r Windows 95 fand ActiveX schnell uerste Einsatzgebiete in der Windows-Welt. Fortan sollte das Component Object Model bzw.ActiveX eine entscheidende S¨ule in der Entwicklung von Windows-Applikationen spielen. aW¨hrend COM lediglich das Zusammenspiel von Software-Komponenten auf dem selben aRechner erlaubt, hebt DCOM als verteiltes COM diese Grenzen auf. DCOM erm¨glicht nun oauch 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 aufRPC. 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 vonderen 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 oMicrosoft 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 averkauft. COM+ bezeichnet somit keine wirkliche Neuentwicklung des Standards, sondernnur ein neu zusammengestelltes Microsoft Produkt.
  26. 26. 2.2 CORBA 21 Abbildung 12: Verteilte Anwendung mit DCOMDer propriet¨re DCOM-Standard stellt eine f¨r Windows-Produkte optimierte Technik f¨r a u udie Umsetzung verteilter Systeme dar. Dementsprechend einfach gestaltet sich die Entwick-lung auf der Microsoft-Plattform. Auf der anderen Seite bietet DCOM keine oder kaumUnterst¨tzung f¨r andere Betriebssysteme. Die Firma Software AG portierte ActiveX un- u uter dem Namen EntireX zwar auf verschiedene Plattformen wie Linux, Sun Solaris, DigitalUnix, HP-UX oder OS/390, eine komplette Kompatibilit¨t wurde hingegen noch nicht er- areicht. Außerdem ist DCOM ein Bin¨rstandard. Die Folge ist eine enge Bindung an die ax86-Prozessorarchitektur. ¨Alle diese Uberlegungen zeigen, dass DCOM in einem reinen Windows-System sicherlich einegute L¨sung darstellt. F¨r die Verwendung in heterogenen Systemen stellt CORBA jedoch o udie bessere Wahl dar.SOAP Das Simple Open Access Protocol oder kurz SOAP ist die neuste Entwicklung ausdem Hause Mircrosoft und definiert ein Transportprotokoll, das die wesentlichen Merkmalevon 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 direkteBindung 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 ain heterogenen Systemen.SOAP beruht im Prinzip auf der Verwendung von sog. Remote Procedure Calls (RPC). Wieder Name bereits andeutet, werden mit dieser Technik entfernte Funktionsaufrufe erm¨glicht. oDurch gestiegene Sicherheitsbed¨rfnisse in Netzwerken bzw. dem Internet werden aber immer umehr Netzwerke durch Firewalls gesichert. Diese Firewalls sch¨tzen an das WWW angeschlos- usene Netzwerke, indem sie Ports blockieren und Anfragen filtern. In der Regel werden nurAnfragen auf den Ports der Standard-Protokolle wie HTTP (Port 80), FTP (Port 21) oder
  27. 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. 28. 2.2 CORBA 23SMTP (Port 25) zugelassen. Die Folge ist, dass RPC-Aufrufe des Clients von der Firewallblockiert werden. Zur L¨sung dieses Problems verwendet SOAP den offenen Port 80, indem oRPC-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 Envelopeterteilt sich wiederum in einen SOAP Header und einen SOAP Body. Der Header enth¨lt aInformationen dar¨ber, was f¨r eine Art von Nachricht vorliegt, den Empf¨nger der Nach- u u aricht und welche Bestandteile der Nachricht optional bzw. obligatorisch sein m¨ssen, um ueine g¨ltige SOAP-Nachricht darzustellen. Der SOAP-Body enth¨lt den eigentlichen Inhalt u ader Nachricht. Außerdem kann eine SOAP-Nachricht noch einen Block mit der BezeichnungFault 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-InformationenMit 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 oauf prinzipiell jeder Plattform auszuf¨hren. Andererseits entstehen gerade bei komplexen uAnwendungen u.U. schnell sehr große Datenmengen, da XML-Dateien neben den reinen In-formationen große Mengen von Formatierungs- bzw. Gliederungsanweisungen in Form vonTags besitzen. Beachtet man weiterhin den Aufwand f¨r das Parsen des Dokuments, erfolgt udie Verarbeitung dementsprechend langsamer als bei CORBA oder DCOM. SOAP bietet

×