Lade Inhalt...
Titel: Analyse und Vergleich von Applikations-Servern und ihren zugrundeliegenden Technologien

Analyse und Vergleich von Applikations-Servern und ihren zugrundeliegenden Technologien

von Klaus Fellner (Autor:in)
©2000 Diplomarbeit 181 Seiten
Informatik - Software

Zusammenfassung

Inhaltsangabe:Einleitung:
Die Entwicklung und der Betrieb Server-basierter Softwaresysteme wird durch ständig steigende Anforderungen immer aufwendiger und komplizierter. Zusätzlich erfordert die starke Verbreitung des Internets und die damit verbundene ständig steigende Akzeptanz von E-Commerce eine möglichst einfache Entwicklung Web-basierter Anwendungen, die in die bestehende Infrastruktur eingebunden werden und diese nutzen können. Applikations-Server stellen die zur Bewältigung dieser Probleme nötige Infrastruktur samt Werkzeuge zur Verfügung. Ausgelöst durch den Motor E-Commerce, der hohe Zuwachsraten mit stark steigenden Umsätzen verspricht, gelang ihnen am Markt innerhalb der letzten zwei Jahre endgültig der Durchbruch. Die Heterogenität der zu integrierenden Infrastrukturen und der zu erstellenden Softwaresysteme bewirkte jedoch eine sehr starke Diversifikation von Applikations-Servern. Dies mündete letztendlich in einer zur Zeit beinahe unüberschaubaren Anzahl von Produkten.
Gang der Untersuchung:
Diese Diplomarbeit beschreibt im theoretischen Teil zuerst die Charakteristika und zugrundeliegenden Technologien von Applikations-Servern, um danach einen Kriterienkatalog zu ihrem Vergleich aufstellen zu können. Im Zuge dessen wird die Brückenfunktion von Applikations-Servern anhand der sechs Middleware Kategorien „RPC based Middleware, Message Oriented Middleware, Database Middleware, Distributed Transaction Coordinator, Object Request Broker und Component Oriented Middleware“ verdeutlicht. Darin enthalten ist ein Vergleich der zur Zeit populärsten serverseitigen Komponentenmodelle COM+ und EJB, die die zentrale Architektur der meisten Applikations-Server festlegen.
Im praktischen Teil dieser Diplomarbeit wird schließlich der Kriterienkatalog zur Beurteilung der Applikations-Server Allaire Cold Fusion 4.5.1 Enterprise, Inprise Application Server 4.0 und Microsoft Windows 2000 Advanced Server angewandt. Abschließend wird, um die praktische Anwendbarkeit der Applikations-Server von
Allaire und Inprise zu überprüfen, mit ihnen eine Beispielapplikation (Mini-Tourismus- Server) erstellt.

Inhaltsverzeichnis:Inhaltsverzeichnis:
1.Motivation für den Einsatz von Applikations-Servern1
1.1Allgemeines Schichtenmodell2
1.2Zwei-Schichten Architektur3
1.2.1Kombination von Präsentations- und Geschäftslogikschicht3
1.2.2Vorziehen eines Teils der Geschäftslogik in die Datenschicht5
1.3N-Schichten-Architektur6
1.4Sonderfall HTML […]

Leseprobe

Inhaltsverzeichnis


ID 5172
Fellner, Klaus: Analyse und Vergleich von Applikations-Servern und ihren zugrundeliegenden
Technologien / Klaus Fellner - Hamburg: Diplomica GmbH, 2002
Zugl.: Linz, Universität, Diplom, 2000
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die
der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen,
der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der
Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung,
vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im
Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der
Bundesrepublik Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem
Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche
Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten
wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können Fehler nicht
vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die Autoren oder
Übersetzer übernehmen keine juristische Verantwortung oder irgendeine Haftung für evtl.
verbliebene fehlerhafte Angaben und deren Folgen.
Diplomica GmbH
http://www.diplom.de, Hamburg 2002
Printed in Germany
Inhaltsverzeichnis
I
Inhaltsverzeichnis
1
Motivation für den Einsatz von Applikations-Servern... 1
1.1
Allgemeines Schichtenmodell ... 2
1.2
Zwei-Schichten Architektur ... 3
1.2.1
Kombination von Präsentations- und Geschäftslogikschicht ... 3
1.2.2
Vorziehen eines Teils der Geschäftslogik in die Datenschicht ... 5
1.3
N-Schichten-Architektur ... 6
1.4
Sonderfall HTML Applikation... 10
1.5
Weitere Vorgehensweise ... 11
2
Einführung in Applikations-Server ... 13
2.1
Definition... 13
2.2
Aufgaben ... 13
2.2.1 Explizite
Aufgaben... 13
2.2.1.1 Horizontale
Aufgabengebiete... 14
2.2.1.2 Vertikale
Aufgabengebiete... 16
2.2.1.3 Werkzeugunterstützung... 18
2.2.1.4 Unterstützung
von
Industriestandards ... 18
2.2.1.5 Aufgabenerfüllung... 18
2.2.2
Implizite Aufgaben und Nebeneffekte ... 18
2.2.2.1 Rollenteilung ... 18
2.2.2.2 Brückenfunktion von Applikations-Servern ... 19
2.2.2.3 Produktivitätssteigerung
der
Softwareentwicklung... 20
2.2.2.4 Unabhängigkeit gegenüber den Herstellern ... 22
2.3
Arten von Applikations-Servern ... 22
2.3.1
Einsatzgebiete von Applikations-Servern ... 22
2.3.2
Aufgabenbereiche von Applikations-Servern ... 23
2.3.3
Aufwand zur Beherrschung von Applikations-Servern ... 24
2.4
Hersteller von Applikations-Server ... 25
2.4.1
Klassifizierung der Hersteller... 25
2.4.2
Stärken und Schwächen der einzelnen Herstellerklassen... 26
3
Middleware ­ Applikations-Server als Brücke... 28
3.1
RPC based Middleware ... 29
Inhaltsverzeichnis
II
3.2
Message Oriented Middleware... 31
3.2.1 Message
Passing... 31
3.2.2 Message
Queuing ... 32
3.2.3
Publish & Subscribe ... 32
3.3
Database Middleware... 33
3.3.1
Open Database Connectivity (ODBC) ... 33
3.3.2 OLE
DB... 34
3.3.3
Java Database Connectivity (JDBC) ... 34
3.4
Distributed Transaction Coordinators... 35
3.4.1
Standards für verteilte Transaktionsverarbeitung... 36
3.4.2
Klassische Transaction Processing Monitors ... 38
3.5
Object Request Broker ... 39
3.5.1
Common Object Request Broker Architecture... 41
3.5.1.1 ORB Funktionalität von CORBA... 41
3.5.1.2 CORBA
Services... 42
3.5.2
Java Remote Method Invocation... 44
3.5.2.1 ORB Funktionalität von Java RMI... 44
3.5.2.2 Java 2 Platform, Enterprise Editon (J2EE)... 46
3.5.3
Distributed Component Object Model ... 47
3.5.3.1 ORB Funktionalität von DCOM ... 48
3.5.3.2 Windows Distributed interNet Architecture (DNA) ... 48
3.5.4
Bewertung der ORB-Modelle... 49
3.6
Component Oriented Middleware ... 50
3.6.1 Komponenten ... 50
3.6.1.1 Definition... 51
3.6.1.2 Auswirkungen ... 53
3.6.2
Architektur von Component Oriented Middleware... 54
3.6.3
Vorteile von Component Oriented Middleware ... 55
3.6.4
Produkte eines Komponenten-Servers ... 56
3.7
Beispiele serverseitiger Komponentenmodelle ... 57
3.7.1
Enterprise JavaBeans (EJB) ... 58
3.7.1.1 Allgemeines zu EJB ... 58
3.7.1.2 EJB
Modell... 59
3.7.1.3 Implizite Dienste von EJB... 60
3.7.1.4 Komponententypen
von
EJB... 61
3.7.2
Component Object Model+ (COM+) ... 63
Inhaltsverzeichnis
III
3.7.2.1 Allgemeines zu COM+... 63
3.7.2.2 COM+
Modell ... 64
3.7.2.3 Implizite Dienste von COM+ ... 65
3.7.2.4 Komponententypen
von
COM+ ... 65
3.7.3
Corba Component Model (CCM)... 66
3.7.4
Vergleich und Bewertung der serverseitigen Komponentenmodelle 66
3.7.4.1 Unterschiede zwischen EJB und COM+ ... 68
3.7.4.2 Zusammenfassung der Unterschiede... 71
4
Kriterienkatalog zur Bewertung von Applikations-Servern ... 73
4.1
Kategorie ... 73
4.2
Verfügbare Plattformen... 74
4.3
Client Unterstützung... 74
4.3.1 Web-Client ... 74
4.3.1.1 HTML
Applikationen... 74
4.3.1.2 Java
Applets ... 75
4.3.2 Arbeitsplatzapplikationen... 75
4.3.2.1 Java
Applikationen ... 75
4.3.2.2 Native
Applikationen ... 76
4.4
Mutli-threading ... 76
4.5
Middleware ... 78
4.5.1
Object Request Broker ... 79
4.5.2
Component Oriented Middleware ... 79
4.5.3
Enterprise JavaBeans spezifische Eigenschaften ... 80
4.5.3.1 EJB
Version... 80
4.5.3.2 Unterstützung von Entity Beans... 80
4.5.3.3 Persistenzmechanismen bei Entity Beans ... 80
4.5.3.4 CORBA- oder RMI-basiertes EJB-Produkt ... 81
4.5.3.5 Verwendung der RMI-IIOP API ... 82
4.5.3.6 Eingesetztes
Kommunikationsprotokoll... 83
4.5.3.7 Zugriff auf JTA über JNDI... 84
4.5.3.8 Integration von professionellen Bean-Herstellern... 84
4.5.4
Message Oriented Middleware... 84
4.5.5 Distributed
Transaction
Coordinator... 85
4.5.5.1 Transaktionsverwaltung durch den Ressource Manager... 85
4.5.5.2 Transaktionsverwaltung durch den eigenen DTC ... 85
Inhaltsverzeichnis
IV
4.6
Web Dienste ... 87
4.6.1 Web-Server
eingebaut ... 87
4.6.2 HTML
Generator... 88
4.6.2.1 Web-Server
Module ... 88
4.6.2.2 CGI
Programme ... 89
4.6.2.3 Java-Servlets... 89
4.6.2.4 Schablonensysteme ... 89
4.6.3
Automatisches Status- und Sitzungsmanagement ... 90
4.7
Kombination mehrerer Schichten ... 92
4.7.1
Art der Kombination ... 93
4.7.1.1 Web-Präsentationsschicht mit Geschäftslogikschicht... 93
4.7.1.2 Geschäftslogikschicht mit Datenschicht ... 93
4.7.2 Logische
Trennung... 93
4.8
Betrieb ... 94
4.8.1 Clustering ... 94
4.8.1.1 Clusteraufbau... 95
4.8.1.2 Lastverteilung
(Load
Balancing)... 96
4.8.1.3 Fehlertoleranz
(Failover) ... 98
4.8.2 Ressourcen
Pooling ... 99
4.8.3
Zwischenspeicherung von Daten der Datenschicht (Caching)... 100
4.8.3.1 Caching von dynamisch erzeugten HTML Seiten ... 100
4.8.3.2 Caching von Transaktionen... 100
4.8.3.3 Caching
von
Datenbankabfragen ... 101
4.8.3.4 In-Memory Database (IMDB) Cache... 101
4.8.4 Stabilität... 101
4.9
Integration externer Systeme ... 101
4.9.1
Integration von Datenbeständen... 101
4.9.1.1 Database
Middleware ... 102
4.9.1.2 Native
Treiber... 102
4.9.1.3 Datenbestände in bestehenden Informationssystemen ... 102
4.9.1.4 Entkoppelung vom Datenbankschema ... 102
4.9.2
Integration entfernter Server-Objekte ... 102
4.9.2.1 CORBA
Objekte... 103
4.9.2.2 COM Objekte bzw. Komponenten... 103
4.9.2.3 EJB
Komponenten... 103
4.9.3
Integration externer Web-Server ... 103
4.9.3.1 Indirekte
Integration ... 103
Inhaltsverzeichnis
V
4.9.3.2 Direkte
Integration ... 104
4.10 Sicherheit... 107
4.10.1 Verschlüsselung... 107
4.10.2 Client
Authentifizierung... 108
4.10.2.1 Einfache
Authentifizierung ... 108
4.10.2.2
SSL Client Authentifizierung (Zertifikat-basiert) ... 108
4.10.2.3 Digest-Authentifierung... 109
4.10.3 SSL
Server
Authentifizierung ... 110
4.10.4 Benutzerverzeichnisse ... 110
4.10.5 Autorisierung
(Rollenkonzept)... 111
4.10.6
Firewall Proxy - HTTP Tunneling ... 112
4.11 Integration zusätzlicher Internet Technologien ... 112
4.11.1 E-Mail... 112
4.11.2 Volltextsuchmaschine ... 113
4.11.3 XML
Integration... 113
4.11.3.1
Verarbeitung von XML ... 114
4.11.3.2
Abbildung von XML (XML Mapping) ... 115
4.11.3.3
Transformation von XML Dokumenten (XSL Prozessor)... 115
4.12 Zusätzliche Dienste (Besonderheiten)... 115
4.12.1
Sauberes Herunterfahren (Clean Shutdown)... 115
4.12.2 Getriggerte
Aktionen... 115
4.13 Administration... 116
4.13.1
Installation der Applikationslogik ... 116
4.13.2 Konfiguration ... 116
4.13.3 Protokollierung... 117
4.13.4 Überwachung... 117
4.14 Integration von Entwicklungswerkzeugen... 118
4.14.1
Entwicklungswerkzeuge vom Hersteller des Applikations-Servers 118
4.14.1.1 Geschäftslogik ... 119
4.14.1.2 Präsentationslogik ... 119
4.14.1.3 Debugger ... 120
4.14.1.4 Eingabekontrollen ... 120
4.14.1.5
Quellcode Überwachung (Source Code Control)... 120
4.14.2 Entwicklungswerkzeuge
von
Drittherstellern ... 121
5
Bewertung von Applikations-Servern... 122
Inhaltsverzeichnis
VI
5.1
Erhältliche Applikations-Server ... 122
5.2
Allaire Cold Fusion 4.5.1 Enterprise ... 123
5.2.1 Kategorie ... 123
5.2.2 Verfügbare
Plattformen ... 124
5.2.3 Client
Unterstützung... 124
5.2.4 Server
Architektur ... 124
5.2.4.1 Allgemeines... 124
5.2.4.2 Middleware... 126
5.2.5 Web
Dienste ... 126
5.2.6 Betrieb ... 126
5.2.6.1 Clustering ... 126
5.2.6.2 Ressourcen
Pooling ... 127
5.2.6.3 Zwischenspeichern von Daten der Datenschicht... 127
5.2.7
Integration externer Systeme... 127
5.2.7.1 Integration von Datenbeständen... 127
5.2.7.2 Integration entfernter Server-Objekte ... 128
5.2.7.3 Integration externer Web-Server ... 128
5.2.8 Sicherheit... 129
5.2.9 Benutzerverzeichnisse ... 129
5.2.10
Integration von Internet Technologien ... 129
5.2.10.1 E-Mail... 129
5.2.10.2 Volltextsuchmaschine ... 130
5.2.10.3 XML
Integration... 130
5.2.11 Administration... 130
5.2.12
Integration von Entwicklungswerkzeugen ... 131
5.2.13 Zusammenfassung ... 131
5.3
Inprise Application Server 4.0 ... 131
5.3.1 Kategorie ... 132
5.3.2 Verfügbare
Plattformen ... 132
5.3.3 Client
Unterstützung... 133
5.3.4
Server Architektur - Middleware... 133
5.3.4.1 Allgemeines... 133
5.3.4.2 EJB
Container... 136
5.3.4.3 Message Oriented Middleware... 137
5.3.4.4 Distributed
Transaction
Coordinator... 137
5.3.5 Web
Dienste ... 138
5.3.6 Betrieb ... 139
Inhaltsverzeichnis VII
5.3.6.1 Clustering ... 139
5.3.6.2 Ressourcen
Pooling ... 139
5.3.6.3 Zwischenspeichern von Daten der Datenschicht (Caching)... 140
5.3.7
Integration externer Systeme... 140
5.3.7.1 Integration von Datenbeständen... 140
5.3.7.2 Integration entfernter Server-Objekte ... 140
5.3.7.3 Integration externer Web-Server ... 141
5.3.8 Sicherheit... 141
5.3.8.1 Web-Server... 141
5.3.8.2 Benutzerverzeichnisse ... 141
5.3.8.3 Zusätzliche
Sicherheitseigenschaften... 142
5.3.9
Integration von Internet Technologien ... 142
5.3.10 Administration... 142
5.3.11
Integration von Entwicklungswerkzeugen ... 142
5.3.12 Sonstiges... 143
5.3.13 Zusammenfassung ... 143
5.4
Übersicht über die getesteten Applikations-Server... 143
5.4.1 Kategorie ... 144
5.4.2 Verfügbare
Plattformen ... 144
5.4.3 Client
Unterstützung... 144
5.4.4 Multi-threading... 144
5.4.5 Middleware... 145
5.4.6 Web
Dienste ... 145
5.4.7
Kombination mehrerer Schichten... 146
5.4.8 Betrieb ... 146
5.4.9
Integration externer Systeme... 147
5.4.10 Sicherheit... 148
5.4.11
Integration von zusätzlichen Internet Technologien ... 148
5.4.12 Zusätzliche
Dienste ... 148
5.4.13 Administration... 149
5.4.14
Integration von Entwicklungswerkzeugen ... 149
6
Beispielapplikation ... 150
6.1
Aufgabenstellung ... 150
6.2
Ablaufdiagramm und Benutzerschnittstelle ... 150
6.3
Architektur der Beispielapplikation... 152
6.3.1
Architektur der Allaire Cold Fusion Applikation... 153
Inhaltsverzeichnis VIII
6.3.2
Architektur der Inprise Application Server Applikation... 153
6.4
Präsentationslogik ... 154
6.4.1
Präsentationslogik von Cold Fusion 4.5.1... 154
6.4.2
Präsentationslogik von Inprise Application Server 4.0 ... 155
6.5
Geschäftslogik... 157
6.5.1
Geschäftslogik von Cold Fusion 4.5.1 ... 157
6.5.2
Geschäftslogik von Inprise Application Server 4.0... 157
6.6
Schlußfolgerung aus dem Vergleich der Applikationen ... 158
7
Ausblick... 159
Abbildungsverzeichnis IX
Abbildungsverzeichnis
Abbildung 1.1 - Zwei Schichten Architektur (Fat Client) ... 4
Abbildung 1.2 - Zwei Schichten Architektur (Stored Procedures)... 6
Abbildung 1.3 - Drei Schichten Architektur ... 7
Abbildung 1.4 ­ Sicherheitsgründe verlangen oft eine Drei-Schichten Architektur... 8
Abbildung 1.5 - Sitzungsmanagement bei einer Zwei- und Drei-Schichten Architektur
... 9
Abbildung 1.6 ­ Zweieinhalb-Schichten Architektur... 11
Abbildung 2.1 Aufgaben von Applikations-Servern ... 14
Abbildung 2.2 ­ Merkmale von Applikations-Servern ... 22
Abbildung 3.1 - Remote Procedure Call ... 29
Abbildung 3.2 - Stubs und Skeletons ... 30
Abbildung 3.3 ­Message Queuing... 32
Abbildung 3.4 - Publish & Subscribe... 33
Abbildung 3.5 ­ Transaktion ... 35
Abbildung 3.6 - Referenzmodell für Transaktionsverarbeitungssysteme von X/Open
... 37
Abbildung 3.7 - Transaction Processing Monitor... 39
Abbildung 3.8 - Object Request Broker... 40
Abbildung 3.9 - Merkmale von Komponenten... 51
Abbildung 3.10 ­ Serverseitige Komponentenarchitektur ... 54
Abbildung 3.11 - EJB Modell ... 59
Abbildung 3.12 ­ COM+ Modell ... 64
Abbildung 4.1 - Multi Threading... 78
Abbildung 4.2 - CORBA basierender EJB-Server... 81
Abbildung 4.3 - Proprietärer EJB-Server ... 82
Abbildung 4.4 ­ Im Applikations-Server eingebauter Web-Server ... 88
Abbildung 4.5 ­ Clustering mit einem IP-Lastverteiler und Network Address
Translation (NAT) ... 95
Abbildung 4.6 ­ Indirekte Integration eines Web-Servers ... 104
Abbildung 4.7 ­ Direkte Integration eines Web-Server ... 105
Abbildung 4.8 - Paßwort-basierte Authentifizierung ... 108
Abbildung 4.9 - Zertifikat-basierte Authentifizierung ... 109
Abbildung 4.10 - Firewall Proxy... 112
Abbildung 4.11 - Erweiterter XML-Parser ... 115
Abbildung 5.1 - Kategorie von Cold Fusion 4.5.1 ... 123
Abbildung 5.2 - Cold Fusion Server 4.5.1 Enterprise... 125
Abbildungsverzeichnis X
Abbildung 5.3 - Kategorie von Inprise Application Server 4.0... 132
Abbildung 5.4 - Inprise Application Server 4.0... 134
Abbildung 6.1 - Ablaufdiagramm von miniTIS... 150
Abbildung 6.2 - miniTIS Startseite ... 151
Abbildung 6.3 - miniTIS Formular Hotelsuche... 151
Abbildung 6.4 - miniTIS Suchergebnis... 151
Abbildung 6.5 - miniTIS Authentifizierung... 152
Abbildung 6.6 - miniTIS Administrator Menü... 152
Abbildung 6.7 - miniTIS Formular Hotel einfügen ... 152
Abbildung 6.8 - miniTIS Hotel auflisten... 152
Abbildung 6.9 - Architektur der Allaire Cold Fusion Applikation... 153
Abbildung 6.10 - Architektur der Inprise Application Server Applikation ... 154
Motivation für den Einsatz von Applikations-Servern 1
1 Motivation für den
Einsatz von
Applikations-Servern
Server-basierte Softwaresysteme verfolgen das Ziel, ihren Benutzern einen
gleichzeitigen, sicheren, verläßlichen und effizienten Zugriff auf ihre Dienste zu
ermöglichen.
Einige Anwendungsfälle für Server-basierter Softwaresysteme sind:
· Versicherungsunternehmen, die ihre dezentral agierenden Agenten über
einen zentralen Server mit Information versorgen
· Banken, die ihre lokalen Institute mit einem zentralen Server verbinden
· Support-Center, die über Terminals ihre Techniker mit Kundendaten
versorgen
· Zeitungen, die aktuelle Daten auf ihren Web-Sites einer große Anzahl von
Benutzern zur Verfügung stellen
Es ist jedoch bei weitem nicht einfach, solche Systeme zu entwickeln. Aspekte der
Skalierbarkeit, Wartung, Sicherheit, Verläßlichkeit etc. sind zu beachten. Gerade bei
komplexen Systemen, die regelmäßig von einer großen Anzahl von Benutzern in
Anspruch genommen werden, ist ein fehlerfreier Betrieb ohne Ausfälle,
Leistungseinbrüche und Sicherheitslücken sehr wichtig. Gleichzeitig ist dies jedoch
durch die Komplexität dieser Informationssysteme ungemein schwierig zu
bewerkstelligen. Das allgemeine Schichtenmodell soll diese Komplexität verringern.
Motivation für den Einsatz von Applikations-Servern 2
1.1 Allgemeines
Schichtenmodell
Die Applikationslogik Server-basierter Softwaresysteme läßt sich theoretisch in drei
verschiedene logische Schichten mit jeweils speziellen Aufgabengebieten einteilen.
Dies sind:
· Präsentationsschicht
· Geschäftslogikschicht
· Datenschicht
Die Logik der Präsentationsschicht erzeugt die Benutzerschnittstelle und steuert
den Arbeitsablauf (eng.: Workflow) einer Anwendung. Zur Codierung der
Präsentationsschicht werden meist Programmiersprachen gewählt, die eine einfache
Erstellung von grafischen Benutzerschnittstellen ermöglichen (z.B. HTML, Java,
Visual Basic).
Die Geschäftslogikschicht löst die eigentlichen Geschäftsprobleme einer
Anwendung. Sie stellt daher das Kernstück der meisten Applikationen dar und dient
als Verbindungsstück zwischen der Präsentations- und Datenschicht. Software dieser
Schicht wird in der Regel mit typsicheren Programmiersprachen wie C++ oder Java
geschrieben.
Die Datenschicht wird von der Geschäftslogikschicht zur persistenten Speicherung
von Zuständen (Daten) verwendet. Zur Speicherung der Daten werden meist mehrere
verschiedene Datenbank Management Systeme (DBMS), Legacy Systeme (SAP,
Großrechner) oder gewöhnliche Dateien verwendet.
Diese logische Partitionierung der Applikations-Logik soll zu einer weitgehenden
Isolierung der einzelnen Aufgabengebiete führen. Eine Änderung der
Benutzerschnittstelle soll daher kaum Auswirkungen auf die Geschäftslogik bzw.
Datenlogik besitzen. Dies soll analog bei Änderungen in den anderen beiden
Schichten gelten.
Die logische Partitionierung eines Systems alleine hat noch keine Auswirkungen auf
seine physische Aufteilung. Logisch getrennte Programmteile können daher im
gleichen Prozeß einer Maschine unter Nutzung des gleichen Adreßraums ablaufen.
Physisch getrennte Programmteile benutzen jedoch unterschiedliche Prozesse auf
unterschiedlichen Maschinen und besitzen daher unterschiedliche Adreßräume.
Deshalb kann nur ein sogenannter entfernter Zugriff (z.B. ein Remote Procedure Call
­ RPC) auf ein physisch getrenntes Programmteil erfolgen. Dieser benötigt jedoch
Motivation für den Einsatz von Applikations-Servern 3
mehr Zeit als ein lokaler Zugriff, wodurch die maximale Systemgeschwindigkeit
reduziert wird. Diesem Nachteil steht der Vorteil der unabhängigen Skalierung der
physisch getrennten Programmteile gegenüber. Dies bedeutet, daß die den
Programmteilen zugeordneten Serverressourcen voneinander unabhängig sind.
Informationssysteme können nun auf eine unterschiedliche Anzahl von physischen
Schichten aufgeteilt werden. Während traditionelle Client/Server Systeme auf zwei
physische Schichten aufgeteilt sind, verwenden Applikations-Server meist drei oder
mehr Schichten.
1.2 Zwei-Schichten
Architektur
Aufgrund ihrer Anwendung bei traditionellen Client/Server Systemen werden Zwei-
Schichten-Architekturen am häufigsten eingesetzt. Die mittlere Schicht der
Geschäftslogik wird mit den beiden anderen Schichten so kombiniert, daß nur zwei
physikalische Schichten übrigbleiben.
Die verbreitetsten Kombinationen sind:
· Kombination von Präsentations- und Geschäftslogikschicht
· Vorziehen eines Teils der Geschäftslogik in die Datenschicht
1.2.1 Kombination von Präsentations- und Geschäftslogikschicht
Wird die Präsentationsschicht mit der Geschäftslogikschicht in einer physikalischen
Schicht gekoppelt, so entsteht, wie in Abbildung 1.1 dargestellt, eine physikalische
Schichtgrenze zwischen Geschäftslogikschicht und Datenschicht. Betrachtet man die
Präsentations- bzw. Geschäftslogikschicht als Client und die Datenschicht als Server,
so wird der Client ,,fat" und der Server ,,thin".
Motivation für den Einsatz von Applikations-Servern 4
Schichtgrenze
Präsentations
Logik
Datenbank
Treiber
Geschäftslogik
Einheit
Datenbank
Präsentations- bzw.
Geschäftslogik-
schicht
Datenschicht
Geschäftslogik
Einheit
Geschäftslogik
Einheit
Server
Client
Abbildung 1.1 - Zwei Schichten Architektur (Fat Client) [Roma99, Fig. 1.6]
Die Client-Applikation kommuniziert mit dem Datenbankserver über eine
Programmierschnittstelle (API ­ Application Programming Interface), die vom
Datenbanktreiber zur Verfügung gestellt wird. Unterstützt der Treiber einen offenen
Standard wie Java Database Connectivity (JDBC) oder Open Database Connectivity
(ODBC), ist die Datenschicht vom Rest weitgehend entkoppelt (abgesehen von
Datenbank-spezifischen SQL-Kommandos).
Diese Architektur besitzt folgende Eigenschaften [Roma99, S. 15,16]:
Hohe Verteilungskosten. Datenbanktreiber müssen auf jeder Client-Maschine
installiert und konfiguriert werden. Die Anzahl der Clients kann leicht mehrere
hundert oder tausend betragen.
Hohe Kosten bei Wechsel der Datenbanktreiber. Das Auswechseln eines
Datenbanktreibers erfordert eine Reinstallation und Rekonfiguration aller
betroffenen Clientmaschinen. Der Wartungsaufwand hierfür ist bei einer
großen Anzahl an Clients dementsprechend hoch, vor allem wenn sie dezentral
verteilt sind.
Hohe Kosten bei Wechsel des Datenbankschemas. Da die Clients die Datenbank
über den Treiber direkt ansprechen können, greifen sie auch direkt auf das
darunterliegende Datenbankschema zu. Wird dieses Schema derart verändert
Motivation für den Einsatz von Applikations-Servern 5
(z.B. um ein neues Problem zu lösen), so daß die bisher verwendete
Datenzugriffslogik nicht mehr anwendbar ist, müssen sämtliche Client-
Programme neu verteilt werden.
Hohe Kosten bei Wechsel des Datenbanktyps. Fat-Clients sind an eine bestimmte
Datenbankschnittstelle wie eine relationale Datenbank API oder eine
objektorientierte Datenbank API gebunden. Wird zwischen diesen beiden
Typen gewechselt, müssen nicht nur alle Client-Programme neu verteilt,
sondern auch ihr Code massiv verändert werden.
Hohe Geschäftslogik-Migrationskosten. Eine Änderung der Geschäftslogik
erzwingt ein erneutes Übersetzen und anschließendes Verteilen des Client-
Programms.
Hohe Datenbank-Verbindungskosten. Jeder Client benötigt seine eigene
Verbindung zur Datenbank. Eine Datenbankverbindung ist jedoch eine
begrenzte Ressource und relativ teuer zu erstellen. Offene
Datenbankverbindungen inaktiver Clients können nicht an andere weiter
gegeben werden.
Hohe Netzwerkbelastung. Jede Datenbankverbindung überquert die physikalische
Grenze zwischen Client und Server. Dies kann zu einer Verstopfung des
Netzwerkes führen, was die Zeit zur Durchführung einer Datenbankoperation
drastisch erhöht.
1.2.2 Vorziehen eines Teils der Geschäftslogik in die Datenschicht
Ein Teil der Geschäftslogik (v.a. Datenzugriffslogik) wird, wie in Abbildung 1.2
dargestellt, vom Client in die Datenbank gezogen. In sogenannten ,,Stored
Procedures" können mehrere Datenzugriffe lokal durchführt werden, da sie
innerhalb des Adreßraums der Datenbank erfolgen. Dies reduziert die Netzbelastung
sowie die Zeit zur Durchführung einer Datenbankoperation enorm und führt daher zu
einer verbesserten Skalierbarkeit und Performanz des gesamten Systems. Alle
anderen Probleme der Zwei-Schichten Architektur bleiben jedoch bestehen. Die
Portabilität wird hingegen negativ beeinflußt, da die Sprachen zur Implementierung
von Stored Procedures meist proprietär sind. Vorteile von offenen
Datenbankschnittstellen wie JDBC oder ODBC kommen daher nicht zur Geltung.
Sind Stored Procedures jedoch in Java geschrieben, erhöht sich ihre Portabilität
beträchtlich, wenn auch Leistungseinbußen in Kauf genommen werden müssen.
[Roma99, S. 16,17]
Motivation für den Einsatz von Applikations-Servern 6
Datenbank
Geschäftslogik- bzw. Datenschicht
Schichtgrenze
Präsentations
Logik
Präsentations- bzw.
Geschäftslogik-
schicht
Stored
Procedures
Geschäftslogik
Einheit
Geschäftslogik
Einheit
Geschäftslogik
Einheit
Server
Client
Abbildung 1.2 - Zwei Schichten Architektur (Stored Procedures) [Roma99, Fig. 1.7]
1.3 N-Schichten-Architektur
Bei der N-Schichten-Architektur ist die Präsentations-, Geschäftslogik- und
Datenschicht auch in entsprechende physische Schichten aufgeteilt. Mehr als drei
Schichten erhält man, indem eine oder mehrere dieser Schichten in weitere Teile
aufgeteilt werden. Dies ermöglicht eine unabhängige Skalierung aller logischen
Schichten. Wird eine Schicht lediglich über mehrere Server repliziert, spricht man
nicht von einer neuen Schicht, sondern von einem Cluster (siehe 4.8.1).
Eine Drei-Schichten Architektur ist in Abbildung 1.3 dargestellt und besteht aus
folgenden Komponenten:
Die Präsentationsschicht läuft bei einer Web-Anwendung innerhalb des
Adreßraums eines oder mehrerer Web-Server. Bei Nicht-Web-Anwendungen
müssen die Clientprogramme, welche die Präsentationsschicht enthalten, an
alle Benutzer verteilt werden.
Die Geschäftslogikschicht läuft innerhalb des Adreßraums eines oder mehrerer
Applikations-Server. Diese sind somit Dreh- und Angelpunkt des gesamten
Serversystems und müssen die nötige Infrastruktur für einen stabilen und
Motivation für den Einsatz von Applikations-Servern 7
effizienten Betrieb bereitstellen. Applikations-Server sind jener Teil der Drei-
Schichten Architektur, auf die in dieser Diplomarbeit ab Kapitel 2 näher
eingegangen wird.
Die Datenschicht enthält eine oder mehrere Datenquellen, die neben den
eigentlichen Daten auch Datenzugriffslogik in der Form von Stored Proceduers
enthalten können.
DB-MiddleWare
Schichtgrenze
Geschäftslogikschicht
Schichtgrenze
Präsentations
Logik
Datenbank
Treiber
Geschäftslogik
Einheit
Datenbank
Präsentationsschicht
Datenschicht
Geschäftslogik
Einheit
Geschäftslogik
Einheit
Client
Applikations-
Server
DB-Server
Abbildung 1.3 - Drei Schichten Architektur [Roma99, Fig. 1.8]
Die N-Schichten Architektur besitzt folgende Eigenschaften [Roma99, S. 18ff.]:
Niedrige Verteilungskosten. Datenbanktreiber werden zentral am Server installiert
und konfiguriert. Dies ist weit günstiger als die Installation und Konfiguration
auf dezentral verteilten Clients, deren Anzahl leicht in die hundert oder tausend
gehen kann.
Niedrige Kosten bei Wechsel der Datenbank. Clients müssen nicht direkt über
eine spezifische Datenbank API auf die Datenbank zugreifen. Verwenden sie
für den Datenzugriff eine Database Middleware (siehe 3.3), die sie ausreichend
von der Datenbank abkoppelt, können Datenbank-Schemata migriert, neue
Motivation für den Einsatz von Applikations-Servern 8
Datenbanktreiber installiert oder sogar der Datenbanktyp gewechselt werden
ohne den Clientcode neu übersetzen oder verteilen zu müssen.
Niedrige Geschäftslogik-Migrationskosten. Eine Änderung der Geschäftslogik
erzwingt nicht unbedingt ein erneutes Übersetzen und anschließendes
Verteilen der Präsentationsschicht.
Differenzierte Sicherheitszonen für die einzelnen Schichten. In vielen Bereichen
ist die Frage der Sicherheit sehr sensitiv. Während Daten vor unberechtigten
Zugriffen geschützt werden müssen, darf gleichzeitig der Betrieb des Systems
nicht behindert werden. Trennt man zum Beispiel Präsentations- und
Geschäftslogikschicht durch eine Firewall, schützt man sowohl die
Geschäftslogik- als auch die Datenschicht vor Angriffen, während man
gleichzeitig weiterhin ungestört auf das System zugreifen kann.
Unsichere Zone
Web-Server
Applikations-Server
Datenbank Server
S
chic
ht
gr
enz
e
F
ire
wa
ll +
S
chic
ht
gr
enz
e
Präsentations
Schicht
Geschäftslogik
Schicht
Datenschicht
Sichere Zone
Abbildung 1.4 ­ Sicherheitsgründe verlangen oft eine Drei-Schichten Architektur [Roma99, Fig. 1.9]
Ressourcen können effizient verwaltet und wiederverwendet werden. Bei einer
reinen Client/Server Architektur sinkt die Systemleistung ab einem bestimmten
Punkt drastisch ab. Server der mittleren Schicht können dies durch Wiederver-
wendung von Ressourcen (siehe 4.8.2) vermeiden.
Leistungseinbrüche betreffen nur eine logische bzw. physikalische Schicht. Ist
eine Schicht überlastet funktionieren die anderen trotzdem einwandfrei.
Motivation für den Einsatz von Applikations-Servern 9
Fehler betreffen nur eine logische bzw. physikalische Schicht. Fällt eine Schicht
aus, können die anderen Schichten eine entsprechende Fehlermeldung
ausgeben.
Reduzierung der Anzahl an Sitzungen. Bei traditionellen Client Server Systemen
ist jeder Client mit jedem Server verbunden. In einer Drei-Schichten-
Architektur sind jedoch nur Verbindungen zwischen jedem Client und jedem
Applikations-Server und zwischen jedem Applikations-Server und jedem
Datenbankserver zu verwalten. Besteht ein Anwendungssystem zum Beispiel
aus 10.000 Clients (c), 100 Datenbank-Servern (s) und 10 Applikations-
Servern (m), müssen bei einer reinen Client/Server Architektur eine Anzahl
von c*s = 100.000*100 = 10.000.000 separaten Sitzungen verwaltet werden.
Bei einer Drei-Schichten Architektur schrumpft diese Zahl auf m*(c+s) =
10*(100.000+100) = 101.000. Die Anzahl der zu verwalteten Sitzungen
reduziert sich also von c*s auf etwa c*m.
Drei-Schichten Architektur
Zwei-Schichten Architektur
Applikations-
Server
Clients
Datenbank-
Server
Clients
Datenbank-
Server
Abbildung 1.5 - Sitzungsmanagement bei einer Zwei- und Drei-Schichten Architektur [Lam98]
Hohe Netzwerkbelastung. Da alle drei Schichten physisch voneinander getrennt
sind, müssen sie über ein Netzwerk miteinander kommunizieren. Dies führt zu
einem beträchtlich höheren Kommunikationsaufwand. Dem kann nur durch ein
sauberes System-Design entgegengewirkt werden. Dies bedeutet jedoch, daß
Motivation für den Einsatz von Applikations-Servern 10
man sich der Schichtgrenzen bewußt ist, was zu Lasten der Ortstransparenz
1
geht.
Einfacheres Transaktionsmanagement. Transaktionen können auf der Ebene der
Geschäftslogik kontrolliert werden. Sie müssen nicht mehr als SQL-
Kommando kodiert werden und können somit mehrere verschiedene
Datenquellen beinhalten.
Besserer technischer Support. Eine einfache Standardinstallation auf dem
Arbeitsplatz des Benutzers (z.B. Web-Browser) erlaubt gegenüber speziellen
Clients, welche die Präsentations- und Geschäftslogik für jede einzelne
Aufgabe enthalten (Fat-Client), einen verbesserten und zentralisierten
technischen Support. Dies führt zu einem qualitativ höherwertigen Service für
Kunden.
Hohe Administrationskosten. Es müssen drei oder mehr physikalisch getrennte
Schichten gewartet werden. Installations-, Aktualisierungs- und
Administrationsosten der Software steigen daher signifikant an.
Vergleicht man diese Eigenschaften mit jenen der Zwei-Schichten Architektur, kann
man die Vorteile der N-Schichten Architektur schnell erkennen. Besonders große,
komplexe Applikationen, die von einer Vielzahl an Benutzern verwendet werden
und eine hohe Skalierbarkeit besitzen müssen, können von ihr im hohen Maße
profitieren. Voraussetzung ist aber ein sauberer Design der Anwendungsarchitektur,
um die negativen Effekte der N-Schichten Architektur zu mindern.
1.4 Sonderfall HTML Applikation
Datenbank-getriebene HTML Applikationen lassen sich jedoch nur schwer in eines
dieser Schichtenmodelle einordnen. Sie sind zwar physisch auf drei Schichten
aufgeteilt, logisch gesehen bestehen sie aber aus nur zwei Schichten, da sowohl ihre
Präsentations- als auch ihre Geschäftslogik gekoppelt von einem zentralen Web-
Server verwaltet werden. Die dezentralen Web-Clients zeigen zwar die
Benutzerschnittstelle in ihren Web-Browsern an, müssen jedoch die
Präsentationslogik zuerst vom Web-Server herunterladen. Deshalb bezeichnet man
die in Abbildung 1.6 dargestellte Architektur auch als Zweieinhalb-Schichten
Architektur. Durch die zentrale Verwaltung der Präsentations- und Geschäftslogik
am Web-Server fallen die meisten Probleme der Zwei-Schichten Architektur weg.
1
Ortstransparenz erlaubt es, auf Informationsobjekte zuzugreifen, ohne ihren tatsächlichen Ort zu
kennen [Star97]
Motivation für den Einsatz von Applikations-Servern 11
Lediglich eine unabhängige Skalierung von Präsentations- und Geschäftslogik-
schicht ist nicht möglich.
Schichtgrenze
Präsentations- bzw.
Geschäftslogik-
schicht
Schichtgrenze
Präsentations
Logik
Datenbank
Treiber
Geschäftslogik
Einheit
Datenbank
Datenschicht
Geschäftslogik
Einheit
Geschäftslogik
Einheit
Web-Server od.
Web-Appliaktions-
Server
DB-Server
Browser
Web-Client
Abbildung 1.6 ­ Zweieinhalb-Schichten Architektur
Wird der Web-Server durch einen Web-Applikations-Server ersetzt, ändert sich
nichts am Schichtenmodell der HTML-Applikation. Es stellt sich daher die Frage,
welche Vorteile sich mit dem Einsatz eines Web-Applikations-Servers erzielen
lassen. Wie die von Applikations-Servern wahrgenommenen unter 2.2 beschriebenen
Aufgaben zeigen, besitzen Web-Applikations-Server jedoch eine Vielzahl anderer
Eigenschaften, welche sie besonders für Datenbank-getriebene HTML
Applikationen nützlich erscheinen lassen.
1.5 Weitere
Vorgehensweise
Der weitere Verlauf dieser Diplomarbeit läßt sich grob in zwei Abschnitte einteilen.
Der erste Abschnitt erläutert die Charakteristika von Applikations-Servern, erklärt
ihre technologischen Grundlagen und stellt einen Kriterienkatalog zu ihrer
Bewertung auf. Der zweite Abschnitt wendet den Kriterienkatalog auf konkrete
Applikations-Server Produkte an und überprüft ihre praktische Anwendbarkeit
anhand einer Beispielapplikation.
Motivation für den Einsatz von Applikations-Servern 12
Der erste Abschnitt besteht konkret aus folgenden Kapiteln:
Im nächsten Kapitel werden sowohl die expliziten Aufgaben eines Applikations-
Servers, die direkt durch seine Dienste wahrgenommen werden, als auch die
impliziten Aufgaben, die durch seinen Einsatz erfüllt werden und als Nebeneffekte
betrachtet werden können, erläutert. Danach werden die verschiedenen Arten von
Applikations-Servern kategorisiert und ihre Hersteller vorgestellt und klassifiziert.
Im 3. Kapitel wird die Brückenfunktion von Applikations-Servern innerhalb der
Drei-Schichten Architektur hervorgehoben. Um die Funktion ausüben zu können,
integrieren die meisten Applikations-Server Dienste, die unter dem Begriff
,,Middleware" zusammengefaßt werden. Ihre zentrale Bedeutung wird anhand der
sechs Kategorien ,,RPC based Middleware, Message Oriented Middleware, Database
Middleware, Distributed Transaction Coordinator, Object Request Broker und
Component Oriented Middleware" erklärt. Darin enthalten ist ein Vergleich der zur
Zeit populärsten serverseitigen Komponentenmodelle COM+ und EJB, die die
zentrale Architektur der meisten Applikations-Server festlegen.
In Kapitel 4 wird schließlich ein Kriterienkatalog aufgestellt, anhand dem sich
Applikations-Server beurteilen lassen. Hierfür wird auf die Erkenntnisse der
vorangegangen Kapitel zurückgegriffen. Noch nicht behandelte Technologien
werden in diesem Kapitel erklärt.
Der zweite Abschnitt besteht aus folgenden Kapiteln:
Im 5. Kapitel wird der zuvor aufgestellte Kriterienkatalog zur Beurteilung der
Applikations-Server Allaire Cold Fusion 4.5.1 Enterprise, Inprise Application Server
4.0 und Microsoft Windows 2000 Advanced Server angewandt. Die Applikations-
Server von Allaire und Inprise werden hierfür einer sehr detaillierten Analyse und
Bewertung unterzogen. Microsoft's Windows 2000 Advanced Server wird wegen
seiner erwarteten großen Verbreitung zwecks besserem Vergleich in die
Überblicksbewertung mit aufgenommen.
Abschließend wird, um die praktische Anwendbarkeit der Applikations-Server von
Allaire und Inprise zu überprüfen, mit ihnen eine Beispielapplikation erstellt. Die
Beispielapplikation ist als Mini-Tourismus-Informationssystem für das Web
konzipiert, das die Abfrage und die Wartung von Hoteldaten ermöglicht. Aus der
Beispielapplikation läßt sich zudem der Aufwand, der zur Erstellung eines
Anwendungssystems notwendig ist, ablesen.
Einführung in Applikations-Server 13
2 Einführung in
Applikations-Server
2.1 Definition
Eine allgemein anerkannte, klar abgegrenzte Definition für Applikations-Server gibt
es nicht. Es wird jedoch allgemein anerkannt, daß Applikations-Server eine
optimierte Laufzeitumgebung für serverseitige Anwendungskomponenten zur
Verfügung stellen. Außerdem erlauben sie die Entwicklung, das Testen und die
Verwaltung von verteilten Anwendungen.
2.2 Aufgaben
Bei den Aufgaben die Applikations-Server erfüllen sollen, kann man zwischen
expliziten und impliziten Aufgaben unterscheiden. Explizite Aufgaben werden im
Unterschied zu impliziten Aufgaben vom Applikations-Server selbst durchgeführt.
Implizite Aufgaben werden hingegen vom Einsatz eines Applikations-Server
erwartet oder als Nebeneffekte betrachtet.
2.2.1 Explizite
Aufgaben
Da das Gebiet der Applikations-Server noch relativ jung und noch nicht ausgereift
ist, herrscht noch keine Einigkeit darüber, welche Eigenschaften und Aufgaben sie
im einzelnen erfüllen und übernehmen sollen. Es gibt einfach zu viele
Möglichkeiten, um die gleiche Problemstellung zu lösen.
Einführung in Applikations-Server 14
Die Aufgaben von Applikations-Servern lassen sich jedoch grundsätzlich in die in
Abbildung 2.1 dargestellten Bereiche unterteilen:
Applikations-Server
Präsentation
Ausführen
von
Geschäfts-
logik
Transaktions
Management
Betrieb
Integration externer Systeme
Installation Administration
Werkzeug-
unterstützung
Abbildung 2.1 Aufgaben von Applikations-Servern
Horizontal dargestellten Aufgaben sind grundlegender Natur. Sie durchdringen alle
Arten von Anwendungen. Im Gegensatz dazu repräsentieren vertikal dargestellte
Aufgaben ein bestimmtes Aufgabengebiet.
2.2.1.1 Horizontale
Aufgabengebiete
Integration externer Systeme
Applikations-Server werden oft in bereits bestehende Infrastrukturen eingegliedert
und müssen daher mit bereits bestehenden externen Systemen zusammenarbeiten
können.
Integration von Datenbeständen
Einer der ersten Gründe für den Einsatz von Applikations-Servern war den Zugriff
auf möglichst viele Datenquellen an einem zentralen Punkt zu integrieren und zu
verwalten [King99]. Im Zeitalter von E-Commerce ist unter anderem der Zugriff auf
Datenbestände in Großrechnern, SAP Systemen etc. (Legacy-Daten) - etwa zur
Auftragsverwaltung - besonders wünschenswert. Bei komplexen Anwendungen, die
einen Zugriff auf viele unterschiedliche Datenquellen erfordern, erleichtert ein
zentraler, vereinfachter Datenzugriff die Integration dieser Datenbestände enorm.
Integration der Geschäftslogik anderer Server
Die Integration der Geschäftslogik anderer Server ermöglicht die
Einführung in Applikations-Server 15
Wiederverwendung bereits existierender Programme. Doppelentwicklungen können
somit vermieden werden.
Integration externer Web-Server
Durch die Integration externer Web-Server können Applikations-Servern ihre
Anwendungen in die bereits bestehende Web-Infrastruktur integrieren.
Betrieb
Applikations-Server müssen einen reibungslosen Betrieb ihrer Anwendung
gewährleisten. Um dies zu erreichen, muß ein Applikations-Server eine ausreichende
Skalierbarkeit und Verläßlichkeit besitzen.
Skalierbarkeit
Informationssysteme werden in der Regel von mehreren Benutzern gleichzeitig
benutzt. Steigt deren Anzahl über ein vorgesehenes Maß hinaus an, soll der
Applikations-Server dieser höheren Last ohne Redesign der Software standhalten
können. Lediglich die Vergrößerung des Server-Clusters zwecks Erhöhung der
Rechenleistung ist erlaubt (siehe 4.8.1). Das ist auch preislich wesentlich günstiger,
vergleicht man die Kosten der zusätzlich benötigten Hardware mit der Arbeitszeit,
die Softwareentwickler für ein Redesign benötigen würden.
Besonders bei frei zugänglichen Web-Applikationen kann sich die Last drastisch
erhöhen, da man die Anzahl der Benutzer nicht genau vorhersehen kann. Daher ist
die Wiederverwendung von Serverressourcen bei diesen Anwendungen besonders
wichtig.
Unglücklicherweise ist die Skalierbarkeit eines Applikations-Server eines der am
schwersten meßbaren Eigenschaften. Einerseits ist es sehr teuer, die zur Messung
notwendigen Tests durchzuführen, andererseits sind die Meßergebnisse schwer zu
vergleichen, da die einzelnen Applikations-Server aufgrund ihrer jeweils
einzigartigen Architektur in den einzelnen Anwendungsgebieten unterschiedlich gut
skalieren [King99].
Verläßlichkeit
Fällt ein Server aus (z.B. aufgrund eines Absturzes), bemerkt das System dies von
selbst und ergreift sofort Gegenmaßnahmen, so daß der Benutzer von dieser
Fehlfunktion nichts merkt. [Wrig99]
Installation Administration
Verteilte Applikationen, insbesondere große Web-Anwendungen, sind in der Regel
sehr komplex. Es behauptet zwar jeder Hersteller von Applikations-Servern, sein
Einführung in Applikations-Server 16
Server sei einfach zu bedienen, doch dies kommt ganz auf den jeweiligen
Standpunkt an. Für die einen heißt einfache Bedienung einfache Entwicklung, für die
anderen einfache Wartung. Im Endeffekt ist entscheidend, inwieweit Entwickler und
Systemadministratoren Hilfe benötigen, um mit der komplexen mehrschichtigen
Architektur klarzukommen.
Installation der Geschäftslogikeinheiten
Jeder Applikations-Server muß die Installation von Applikationslogik (das Laden
des Programmcodes in den Server) unterstützen.
Einfache Administration der mehrschichtigen Architektur
Um große Systeme vernünftig konfigurieren und warten zu können, muß der
Systemadministrator auch die Architektur des Applikations-Servers verstehen. Das
System darf keine Black-Box sein, sondern muß seine Konfiguration und
Überwachung ermöglichen. [King99]
Sicherheitsmanagement
Sicherheit besteht immer aus folgenden 2 Teilen:
· Übertragungssicherheit der Daten
· Sicherheit der Serverressourcen
Die Übertragungssicherheit der Daten wird durch Verschlüsselungsverfahren wie
SSL gewährleistet. Sicherheit von Serverressourcen wird durch Authentifizierung
von Clients erreicht. Beide Mechanismen werden zentral vom Server zur Verfügung
gestellt und müssen nicht extra implementiert werden.
2.2.1.2 Vertikale
Aufgabengebiete
Präsentation
Anbieten von Web-Präsentationslogik
Die Präsentationslogik wird bei Web-Anwendungen nicht dezentral an die
Endbenutzer verteilt, sondern zentral am Server verwaltet. Applikations-Server
können deshalb nicht nur als Server für Geschäftslogik, sondern auch als Server für
Web-Präsentationslogik verwendet werden.
Dynamisches erzeugen von HTML Code
Applikations-Server für Web-Anwendungen müssen HTML Code dynamisch selbst
erzeugen (z.B. aus einer Datenbank auslesen).
Einführung in Applikations-Server 17
Status- und Sitzungs-Management
Eines der größten Probleme von Web-Applikationen ist die Zustandslosigkeit des
im Web zur Kommunikation zwischen Client und Server eingesetzten HyperText
Transfer Protocols (HTTP). Da eine Kommunikationsverbindung zwischen Web-
Browser und Web-Server nur für die Dauer einer HTTP-Anfragebearbeitung besteht,
muß bei jeder weiteren Anfrage erneut eine Verbindung zum Web-Server erstellt
werden. Zustände von Sitzungen, die sich über mehrere HTTP-Anfragen erstrecken,
müssen daher programmatisch mittels Cookies, versteckten Formularfeldern oder in
der URL gespeichert werden [Loes98, S. 202ff]. Applikations-Server können
Entwickler von dieser Aufgabe entlasten, indem sie diese Aufgabe automatisiert
durchführen.
Ausführen von Geschäftslogik
Das Ausführen von Geschäftslogik im Auftrag von Clients ist die zentrale Aufgabe
eines Applikations-Servers. Geschäftslogikeinheiten müssen daher im laufenden
Betrieb möglichst vielen Clients zur Verfügung gestellt werden.
Bereitstellen von Geschäftslogikeinheiten im laufenden Betrieb
Geschäftslogik kann in wiederverwendbare Module gespeichert werden, so daß
Programmteile, die immer wieder benötigt werden (z.B. Überprüfung einer
Kreditkartennummer), nicht jedesmal neu geschrieben werden müssen. Dies führt
neben einer höheren Produktivität und Verläßlichkeit auch zur Unterstützung eines
Prototyping-orientierten Software-Entwicklungsprozeß, da Prototypen aus diesen
Moduln schnell und billig erzeugt werden können.
Zugriff auf Geschäftslogikeinheiten
Applikations-Server müssen Clients Zugriff auf ihre Geschäftslogikeinheiten
ermöglichen. Jedoch können nicht alle Clients die Geschäftslogikeinheiten eines
Applikations-Servers direkt aufrufen, da sie ein anderes Kommunikationsprotokoll
als der Applikations-Server verwenden. Speziell für Web-Clients wird eine spezielle
Server-Komponente (Web-Engine) benötigt, die HTTP-Anfragen decodiert, die
gewünschte Komponente ausführt und den erzeugten HTML-Code dem Client via
HTTP zurückschickt (z.B. Java-Servlets).
Transaktionsmanagement
Da der Applikations-Server sämtliche Zugriffe auf externe Datenquellen durchführt,
kann die Transaktionsverwaltung von den einzelnen Datenquellen zum
Applikations-Server verlagert werden. Dies hat den Vorteil, daß mehrere
unterschiedliche Datenquellen an einer einzigen Transaktion teilnehmen können.
Einführung in Applikations-Server 18
Zu diesem Zweck können Applikations-Server mit einem eigenen
Transaktionsmanager ausgestattet sein oder externe Transaktionsmanager
integrieren. Gerade bei E-Commerce Applikationen, die in der Regel viele
geschäftliche Transaktionen beinhalten, ist die Behandlung von Transaktionen und
die Erhaltung der Datenintegrität eine der wichtigsten Aufgaben.
2.2.1.3 Werkzeugunterstützung
Applikations-Server müssen Werkzeuge zu ihrer Administration sowie zur
Erstellung von Anwendungslogik besitzen. Ist der Applikations-Server nicht bereits
mit solchen Werkzeugen ausgestattet, muß er eine offene Schnittstelle zu ihrer
Integration anbieten.
2.2.1.4 Unterstützung von Industriestandards
Die Industriestandards des Internets entwickeln sich rapide. Deshalb ist es wichtig,
daß Applikations-Server die heute gängigen Standards unterstützen (z.B. HTTP,
IIOP, CORBA, EJB, MTS, COM/COM+, JDBC, ODBC, SMTP, LDAP, etc. ­
werden im Laufe der Arbeit noch erklärt) und eine saubere Architektur besitzen, um
zukünftige Standards einfach verwenden zu können. Dies betrifft sowohl die
Umsetzung der horizontalen als auch die der vertikalen Aufgaben.
2.2.1.5 Aufgabenerfüllung
Bis auf die Einfachheit der Administration und Wartung werden so gut wie alle
Aufgaben von allen Produkten, die sich als Applikations-Server bezeichnen,
umgesetzt. Der Unterschied liegt in der Art und im Grad der Umsetzung. Hier
unterscheiden sich die einzelnen Produkte teilweise beträchtlich.
2.2.2 Implizite Aufgaben und Nebeneffekte
2.2.2.1 Rollenteilung
Applikations-Server unterstützen die Rollenteilung beim Erstellen eines
Anwendungssystems.
Grundsätzlich kann man zwischen 2 verschiedene Rollen unterscheiden:
· Anwendungsentwickler
· Systemadministrator
Der Anwendungsentwickler übernimmt das Design und die Implementierung der
Applikation. Der Systemadministrator ist sowohl für die Konfiguration,
Einführung in Applikations-Server 19
Überwachung und Wartung des Systems als auch für die Fragen des
Kapazitätsmanagement zuständig. Zusätzlich könnte man noch die Rolle eines
Testers einführen, jedoch kann diese Aufgabe auch vom Administrator oder von
anderen Entwicklern übernommen werden.
Verwendet man eine Component Oriented Middleware (siehe 3.6), kann man die
Aufgaben des Anwendungsentwicklers noch in folgende Rollen aufspalten:
· Komponenten-Entwickler
· Systemarchitekt
· Komponenten-Installateur
Der Komponenten-Entwickler ist für das Design und die Implementierung der
einzelnen Komponenten zuständig.
Der Systemarchitekt entwickelt die Architektur der gesamten Anwendung durch
Spezifizieren der einzelnen Komponenten. Er versteht wie die einzelnen
Komponenten zusammenpassen und ist für den Zusammenbau der Komponenten zu
einer vollständigen Applikation zuständig.
Der Komponenten-Installateur installiert die vorgefertigten Komponenten in einen
oder mehreren Applikations-Servern, und fügt sie so in das Anwendungssystem ein.
2.2.2.2 Brückenfunktion von Applikations-Servern
Applikations-Server besitzen einen weiteren maßgeblichen positiven Nebeneffekt.
Sie bringen jene zwei Parteien der Web-Entwicklung zusammen, die bis jetzt
getrennt waren. Dies sind einerseits Web-Entwickler und andererseits IT-Entwickler
(Entwickler in traditionellen EDV-Abteilungen) [Benf99].
Web-Entwickler arbeiten mit CGIs, Scripts, Servlets etc. Da sie auf keine
bestimmten Entwicklungswerkzeuge angewiesen sind, können sie zwischen den am
Markt angebotenen Produkten frei wählen. Solange sie sich an die Standards des
Internets halten arbeitet alles zusammen. Web-Entwickler verwenden daher meist
mehrere Werkzeuge zum Erstellen einer Anwendung. Sie betrachten oft nur kleinere
Teile an Code, die wiederum andere Teile verwenden, um so eine ganze Anwendung
zu erstellen.
Für IT Entwickler und traditionelle Software Ingenieure ist dies allerdings ein
ziemlich sonderbarer Weg Systeme zu erstellen, der zudem für komplexe
Anwendungen kaum mehr geeignet ist. Sie verwenden zur Entwicklung von
Einführung in Applikations-Server 20
Client/Server Systemen in der Regel hochwertige Entwicklungswerkzeuge mit
Sprachen der 4. Generation (4 GL). Sie sind an einfachen Datenzugriff, garantierten
Transaktionen und Sicherheit gewöhnt. Client/Server hat sich in der Vergangenheit
als Standardarchitektur unternehmensinterner Informationssysteme weitgehend
durchgesetzt. Werkzeuge wie Visual Basic, Delphi oder Powerbuilder dominieren
den Markt. Zum Erstellen von vollständigen Anwendungen wird eines dieser
Werkzeuge verwendet.
Applikations-Server sind nun fähig, eine Brücke zwischen diesen beiden Welten zu
schlagen. Web-Entwickler wünschen sich skalierbare transaktionsorientierte
Systeme mit einem einfachen Zugriff auf möglichst viele Datenquellen. IT-
Entwickler möchten nicht fünf oder sechs verschiedene Werkzeuge benutzen, nur
um eine Web-Anwendung erstellen zu können. Zusätzlich wäre eine
Wiederverwendung der Geschäftslogik von Altanwendungen wünschenswert
[Benf99]. Nur Applikations-Server sind in der Lage, diese Anforderungen auf breiter
Basis zu erfüllen.
2.2.2.3 Produktivitätssteigerung der Softwareentwicklung
Die Komplexität vieler Informationssysteme ist bereits so groß, daß Fragen der
Bereiche Organisation, Koordination und Sicherheit wichtiger werden als die
eigentliche Entwicklungsarbeit. Umfassende Projekte müssen sich zudem unter
zeitkritischen Gesichtspunkten durch Skalierbarkeit, Zuverlässigkeit, Stabilität und
Sicherheit auszeichnen - gerade im Zeitalter von Electronic Commerce.
Applikations-Server können zur Lösung dieser Probleme mit einer
Produktivitätsverbesserung beitragen, indem sie die Produktivität der
Softwareentwicklung erhöhen.
Verwendung der Server-Dienste
Informationssysteme müssen Eigenschaften besitzen, die über ihre eigentlichen
Aufgaben ­ die zu lösenden Geschäftsprobleme - weit hinausgehen. Dies sind z. B.:
· effiziente Verwaltung der einzelnen Sitzungen
· Verhindern von Streitigkeiten um Serverressourcen
· effizientes Verwalten von Serverressourcen (Lastverteilung)
· effizienter Datenzugriff
· Verwaltung von Transaktionen
· Stabilität
· Wiederanlauf und Fehlerbehandlung bei Absturz eines Servers
· Performanz
Einführung in Applikations-Server 21
· Sicherheit
· ...
Viele Unternehmen haben sich aufgrund der Ermangelung von Alternativen hierfür
bis jetzt selbstgestrickte Lösungen gebastelt. Die Entwicklung dieser Lösungen raubt
den Entwicklern jedoch viel Zeit und Energie, die ihnen dann bei der Lösung von
Geschäftsproblemen fehlt. Da sie meist über kein Expertenwissen in diesen Gebiete
verfügen, sind die fertigen Informationssysteme meist komplex, ineffizient und
schwer zu warten.
Applikations-Server befreien den Anwendungsentwickler von diesen Problemen, da
sie bereits Dienste zu dessen Lösung besitzen. Unternehmen können diese Dienste
daher zukaufen, anstatt sie selbst zu entwickeln.
Wiederverwendung
Web-basierte Anwendungen stellen Dienste zur Verfügung, die nicht nur über das
Internet, sondern auch über das Intranet oder Extranet zugänglich sein sollen. Die
Anforderungen der einzelnen Benutzergruppen sind aber sehr unterschiedlich.
Internetanwender sind meist Endkunden, die nur über eine niedrige Bandbreite
verfügen. Zugangssoftware ist praktisch immer ein Web-Browser. Intranetanwender
sind in der Regel Angestellte des eigenen Unternehmens, die aufgrund der direkten
Verbindung über eine relativ hohe Bandbreite verfügen. Informationssysteme des
Intranets verwenden traditionell die Client/Server Architektur. Extranetanwender
sind Vertragspartner des Unternehmens, die über einen vertraglich genau definierten
Zugang zu bestimmten Diensten verfügen. Extranetanwendungen werden auch als
Business-to-Business E-Commerce Anwendungen bezeichnet. Ihr Zugriff erfolgt oft
automatisiert.
Ohne Applikations-Server müssen für alle drei Benutzergruppen eigenständige
Anwendungssysteme geschaffen werden. Gleichartige Geschäftslogikeinheiten
müssen daher mehrmals entwickelt werden, was sowohl Entwicklungszeit
verschwendet als auch die Wartbarkeit des gesamten Systems sehr verschlechtert.
Applikations-Server können hingegen alle drei Anwendungssysteme in ein einziges
Anwendungssystem fusionieren, indem sie verschiede Schnittstellen zu ihren Server-
Diensten anbieten. Somit müssen nicht verschieden Anwendungssysteme entworfen
werden, die alle die gleiche Geschäftslogik implementieren.
Werkzeuge
Ausgereifte Entwicklungswerkzeuge, können ebenfalls zur Produktivitätssteigerung
beitragen. Daher sollen Applikations-Server zusätzlich zu ausgewogenen
Managementwerkzeugen Entwicklungswerkzeuge integrieren, die die Entwicklung
Einführung in Applikations-Server 22
von fortschrittlichen Informationssystemen bestmöglichst unterstützen. Je mehr
Programmierarbeit zum Erstellen der Applikation benötigt wird, desto wichtiger
wird diese Aufgabe. [King99]
2.2.2.4 Unabhängigkeit gegenüber den Herstellern
Je einfacher eine Applikation von einem Applikations-Server zu einem anderen
portiert werden kann, desto geringer ist die Gefahr einer Abhängigkeit vom
Hersteller eines bestimmten Applikations-Servers (engl. Vendor Lock-In). Dies
hängt auch eng mit der Unterstützung von Industriestandards zusammen. [King99]
2.3 Arten von Applikations-Servern
Applikations-Server lassen sich aufgrund folgender dreier Merkmale in mehrere
unterschiedliche Kategorien einordnen:
Aufwand
E
insatz
ge
bie
t
Augabenbereich
Abbildung 2.2 ­ Merkmale von Applikations-Servern
2.3.1 Einsatzgebiete von Applikations-Servern
Applikations-Server können aufgrund ihres Einsatzgebietes grob in folgende zwei
Gruppen unterteilen werden [Reib99]:
· Web-Applikations-Server
· Legacy-Applikations-Server
Web-Applikations-Server sind Systeme, die auf die Entwicklung von Web-basierten
Anwendungen spezialisiert sind. Sie integrieren entweder direkt einen Web-Server
oder werden neben einem herkömmlichen Web Server betrieben (siehe 4.6.1). Sie
ermöglichen im Vergleich zur reinen Web-Server Applikationen eine relativ
Einführung in Applikations-Server 23
einfache Entwicklung von Internetanwendungen, können jedoch oft nur sehr schwer
mit bereits existierenden Informationssystemen zusammenarbeiten.
Legacy-Applikations-Server stellen für geschäftskritische Intranetanwendungen
Infrastruktur zum Transaktions- und Sicherheitsmanagement, zum automatischen
Wiederanlauf im Fehlerfall und zur Integration von Daten bereits existierender
Informationssysteme wie TP-Monitore (siehe 3.4.2) zur Verfügung. Jedoch ist ihre
Unterstützung für Web-basierte Systeme sehr begrenzt.
Die Verschmelzung aus Web- und Legacy-Applikations-Server ergibt eine neue
Kategorie, die Enterprise-Applikations-Server genannt wird. Diese auch als
vollwertig bezeichneten Applikations-Server, können bestehende
Informationssysteme sehr gut integrieren und gleichzeitig alle Vorteile einer
modernen Web-orientierten mehrschichtigen Architektur nutzen.
Wie bereits erwähnt, gibt es aber keine klar abgegrenzte Definition von
Applikations-Servern. Bei manchen Produkten ist der Server ein einfacher Zusatz
zur ausgereiften Entwicklungsumgebung. Diese Produkte lassen sich natürlich nur
sehr schwer mit Applikations-Servern der Enterprise Klasse vergleichen.
Allen gemeinsam ist jedoch, daß der Applikations-Server selbst ein separates klar
identifizierbares Modul innerhalb des gesamten Pakets sein soll.
2.3.2 Aufgabenbereiche von Applikations-Servern
Selbst Applikations-Server des gleichen Einsatzgebietes können als Server für
unterschiedliche Aufgabenbereiche dienen. Wie in den vertikalen Säulen der
Abbildung 2.1 angedeutet, gibt es folgende drei Möglichkeiten:
· Präsentations-Server
· Geschäftslogik-Server
· Transaktionsmanager
Präsentations-Server stellen ihren Clients Präsentationslogik in Form von HTML,
Java-Script und Java-Applets zur Verfügung. Teile dieser Logik können vom
Präsentations-Server auch dynamisch erzeugt werden. Ihr Anwendungsgebiet ist zur
Zeit ausschließlich das World Wide Web, da die dort als Clients verwendeten Web-
Browser keine Präsentationslogik besitzen. Diese auch als Thin-Clients bezeichneten
Programme sind somit sehr flexibel und können für unterschiedliche Anwendungen
eingesetzt werden.
Einführung in Applikations-Server 24
Geschäftslogik-Server stellen ihren Clients ausschließlich Geschäftslogik zur
Verfügung. Die Kommunikation erfolgt entweder synchron mittels Remote
Procedure Calls (siehe 3.1) oder asynchron mittels einer Message Queue. (siehe
3.2.2). Die Geschäftslogik selbst wird meist als Objekt bzw. Komponente verpackt.
Transaktionsmanager können Transaktionen über mehrere Datenquellen
durchführen und koordinieren (siehe 3.4).
Diese Unterteilung ist jedoch nicht exklusiv. Applikations-Server können alle drei
Server integrieren. Vermischen Applikations-Server Präsentationslogik mit
Geschäftslogik, so werden sie zu den Präsentations-Servern gezählt.
Web-Applikations-Server haben ihren Ursprung in der Präsentation. Je größer und
komplexer Web-Anwendungen werden, desto wichtiger werden jedoch auch andere
Bereiche ­ gerade im Zeitalter von Electronic Commerce.
2.3.3 Aufwand zur Beherrschung von Applikations-Servern
Der Aufwand der zur Beherrschung von Applikations-Server nötig ist, kann sich von
Server zu Server sehr stark unterscheiden.
Applikations-Server, die nur einen vergleichsweise geringen Aufwand zur
Anwendungsentwicklung und Administration benötigen, sind bereits von einer
Einzelperson oder einem kleinen Team beherrschbar. Sie eignen sich hervorragend
für eine schnelle Anwendungsentwicklung (engl.: Rapid Application Development -
RAD) und sind meist auch relativ günstig in der Anschaffung mit Preisen um die
5.000 US$ pro Serverlizenz. Beispiele hierfür sind Allaire's Cold Fusion oder
EveryWare Development's Tango.
Applikations-Server, die für den sinnvollen Einsatz bereits mehrere Personen
benötigen (z.B. mind. 2-3 Entwickler, 1 Systemdesigner, 1 Administrator und
Installateur) gehören zur hohen Aufwandsklasse. Sie sind wesentlich teurer in der
Anschaffung mit Preisen um bis zu 35.000 US$ pro CPU. Die Abrechnung auf CPU
Basis macht die Anschaffung noch teurer, da solche Systeme zur optimalen
Ressourcenauslastung meist auf Mehrprozessormaschinen laufen. Sie eignen sich am
besten für High-End Applikationen, die einen Systemausfall unbedingt vermeiden
und hoher Last standhalten müssen. Beispiele hierfür sind BEA Weblogic, Inprise
Application Server, IBM WebSphere, Oracle Application Server, SUN
Netdynamics, etc.
Einführung in Applikations-Server 25
2.4 Hersteller von Applikations-Server
2.4.1 Klassifizierung der Hersteller
Network Computing [Netw99] listet im aktuellen Buyers Guide für Web-
MiddleWare (Stand: 17.11.1999) 63 Produkte von 51 Herstellern auf. Da dieser
Bereich als eine der zukünftigen ,,Cash-Cows" angesehen wird, drängten und
drängen immer mehr Hersteller ­ neue und etablierte ­ auf den Markt. Durch den
Eintritt der großen Infrastrukturhersteller wie IBM, Sun und Microsoft ist aber
bereits eine Konsolidierung des Marktes im Gange [Karp98]. Bis jetzt waren so gut
wie alle Firmenübernahmen friedlicher Natur und die Produkte der übernommen
Hersteller werden weiter unterstützt bzw. weiterentwickelt [Wrig99-2]. Eine
Garantie, daß das so bleibt, gibt es aber nicht. Denn laut Forrester Resarch Inc. wird
die Zahl der am Markt vertretenen Hersteller stark schrumpfen. Forrester Resarch
hat in einer Analyse des Appliktions-Server Marktes eine Konsolidierung des
Marktes auf fünf ,,Key-Player" und ihre strategischen Partner vorhergesagt. Laut Ted
Schadler, Co-Autor dieser Studie, werden dies Microsoft, IBM, Oracle, Sun und
Netscape sein [Grus98]. Mittlerweile sind jedoch auch SUN und Netscape eine
Partnerschaft eingegangen, um ihre Applikations-Server in einem Produkt zu
verschmelzen [Fitz99].
Im Grunde kann man zwischen folgenden drei Herstellern unterscheiden [Desa99]:
· Unabhängige Hersteller
· Große etablierte Software und Infrastruktur Hersteller
· Hersteller von klassischen, netzwerkfähigen Softwareinfrastrukturen
Die unabhängigen Hersteller waren die ersten in diesem neuen und von ihnen
definierten Markt. Seit ca. 5 Jahren bieten Firmen wie Allaire und Bluestone
Software Produkte an, die ein schnelles Entwickeln Web-basierter Anwendungen
ermöglichen. Diese Produkte sind von Anfang bis Ende für das Web konzipiert und
haben sich zu vollwertigen, ausgereiften Web-Applikations-Servern entwickelt. In
den letzten Jahren sind Hersteller wie Silverstream, Pervasive oder Vision Software
hinzugekommen. All diese Firmen sind keine kleinen in Garagen gegründeten
Newcomer, sondern Firmen mit einem starken Management und einem guten
Fundament.
Vor ca. 2 Jahren stiegen die großen etablierten Infrastruktur und Software Hersteller
wie IBM, Sun, Oracle und Microsoft in den Markt ein. Die meisten mit
Einführung in Applikations-Server 26
Eigenentwicklungen, nur Sun kaufte NetDynamics und ging mittlerweile auch mit
Netscape eine mehrjährige Partnerschaft ein. Microsoft wiederum besitzt mit
Windows 2000 Advanced Server ein Produkt, das zwar nicht ausschließlich als
Applikations-Server vermarktet wird, jedoch alle Eigenschaften eines Applikations-
Servers besitzt.
Diese großen Anbieter betrachten Applikations-Server nicht bloß als ein Produkt,
sondern als integraler Bestandteil ihrer Produktlinie. Applikations-Server dieser
Kategorie lassen sich daher oft nahtlos in die Infrastruktur ihrer Hersteller
integrieren. Deswegen macht ihr Einsatz vor allem Sinn, wenn man bereits Produkte
dieses Herstellers in Verwendung hat.
Zuletzt stieg noch eine dritte Gruppe in den Markt ein: Hersteller von klassischen
netzwerkfähigen Softwareinfrastrukturen (vor allem von ORB- und TPM-Systemen -
siehe 3.5.1 und 3.4.2). Sie komplementieren mit ihrem Markteinstieg lediglich ihre
Produktpalette, da sie bereites Produkte anbieten, die für verteilte, komplexe, hoch
skalierbare, transaktionale Systeme konstruiert sind. Sie zeichnen sich durch
Stabilität und Verfügbarkeit aus. Dies ist besonders wichtig, wenn ein Ausfall
sowohl einen monetären Verlust als auch einen Kundenverlust bedeutet. Beispiele
dieser Gruppe sind IBM, BEA Systems und Sybase.
2.4.2 Stärken und Schwächen der einzelnen Herstellerklassen
Laut [Desa99] besitzen die einzelnen Herstellerklassen folgende Vor- und Nachteile:
Die unabhängigen Hersteller bieten in erster Linie vielversprechende, offene
Technologien mit einen Fokus auf verschiedene vertikale Märkte an. Die
Langzeitstabilität einzelner Firmen ist jedoch sicher mehr als fraglich.
Die großen Infrastruktur Hersteller sind vor allem dann eine attraktive Alternative,
wenn man sich bereits auf einen dieser Hersteller standardisiert hat oder dessen
Technologie einsetzt. Jedoch benutzen diese Firmen ihre Applikations-Server, um
ihre gesamte Produktpalette zu unterstützen. Der Nachteil von Applikations-Server
dieser Gruppe ist, daß man sich sehr an den Hersteller bindet. Die Gefahr eines
Vendor Lock-In ist hier am größten.
Hersteller von klassischen netzwerkfähigen Softwareinfrastrukturen haben im
Bereich der verteilten Systeme ihre Vorteile, da genau hier ihre Kernkompetenzen
liegen. Sie ermöglichen zudem oft eine einfache Integration von Altanwendungen.

Details

Seiten
Erscheinungsform
Originalausgabe
Erscheinungsjahr
2000
ISBN (eBook)
9783832451721
ISBN (Paperback)
9783838651729
DOI
10.3239/9783832451721
Dateigröße
1.2 MB
Sprache
Deutsch
Institution / Hochschule
Johannes Kepler Universität Linz – Wirtschaftsinformatik
Erscheinungsdatum
2002 (März)
Note
1,0
Schlagworte
com+ kriterienkatalog applikationsserver middleware
Produktsicherheit
Diplom.de

Autor

Zurück

Titel: Analyse und Vergleich von Applikations-Servern und ihren zugrundeliegenden Technologien
Cookie-Einstellungen