Diplomarbeit
Konzeption und praktische Evaluierung einer J2EE-basierten Systemarchitektur
für kollaborative Serverdienste
- am Beispiel der Referenzumgebung IBM Workplace Collaboration Services 2.6 -
Prof. Dr. Ludwig Nastansky
2006
Betreuer:
Dipl.-Wirt.-Inf. Ingo Erdmann
vorgelegt von:
Tobias Altemeier
Greitelerweg 79
33102 Paderborn
Wirtschaftsinformatik
Matrikel Nr. 6018617
Einleitung
3
Inhaltsverzeichnis
1 EINLEITUNG ................................................................................................................................... 1
1.1 ZIELDEFINITION .............................................................................................................................. 3
1.2 AUFBAU DER ARBEIT ...................................................................................................................... 4
2 EINFÜHRUNG KOLLABORATIVE SERVERDIENSTE .......................................................... 6
2.1 GLOBALE BEGRIFFSDEFINITION UND -ABGRENZUNG ...................................................................... 6
2.1.1 Systemelemente versus Systemarchitektur ............................................................................ 6
2.1.2 Computer Supported Cooperative Work und Groupware .................................................... 8
2.1.3 Kollaboration und Serverdienste .......................................................................................... 8
2.2 GRUNDSÄTZLICHE MERKMALE VON KOLLABORATIVEN SERVERDIENSTEN .................................. 10
2.2.1 Systemelemente und deren Bedeutung für kollaborative Dienste ....................................... 10 2.2.1.1 Applikationsserver ........................................................................................................................ 11 2.2.1.2 Webserver ..................................................................................................................................... 15 2.2.1.3 Portalserver ................................................................................................................................... 16 2.2.1.4 Verzeichnisdienste ........................................................................................................................ 20 2.2.1.5 Datenbanksysteme und DBMS ..................................................................................................... 28
2.2.2 System-Architekturmerkmale und deren Bedeutung für kollaborative Dienste .................. 29 2.2.2.1 Single Node Architektur / Single Tier Architektur ....................................................................... 31 2.2.2.2 Application Offload / eSSL ........................................................................................................... 32 2.2.2.3 Horizontales – und vertikales Clustering ...................................................................................... 32 2.2.2.4 Multi Node Architektur / Multi Tier Architektur .......................................................................... 35 2.2.2.5 Network Deployment .................................................................................................................... 37
3 KONZEPTION EINER J2EE SYSTEMARCHITEKTUR ........................................................ 38
3.1 ZIELDEFINITION DER ZU ENTWERFENDEN SYSTEMARCHITEKTUR ................................................. 39
3.1.1 Rahmenbedingungen und Budget ....................................................................................... 39
3.1.2 Anforderungen an die Systemarchitektur ........................................................................... 40
3.2 DISKUSSION MÖGLICHER SYSTEMARCHITEKTUREN ...................................................................... 42
3.2.1 Single Server Installation ................................................................................................... 43
3.2.2 Application Offload ............................................................................................................ 46
3.2.3 Network Deployment .......................................................................................................... 48
3.2.4 Horizontales und vertikales Clustering .............................................................................. 51
3.3 ENTWURF EINER SYSTEMARCHITEKTUR AUS KONZEPTIONELLER SICHT ....................................... 53
3.3.1 Modellierung einer eSSL Systemarchitektur ...................................................................... 54 3.3.1.1 Ist-Analyse der bestehenden Infrastruktur ..................................................................................... 55
3.3.2 Identifikation, Spezifikation und Distribution der benötigten Systemelemente .................. 56 3.3.2.1 Applikationsserver und Portalserver ............................................................................................. 57 3.3.2.2 Webserver ..................................................................................................................................... 57 3.3.2.3 Verzeichnisdienste ........................................................................................................................ 58 3.3.2.4 Datenbanksysteme ........................................................................................................................ 59
3.4 J2EE-BASIERTE ESSL SYSTEMARCHITEKTUR FÜR KOLLABORATIVE SERVERDIENSTE ................. 61
Einleitung
4
4 REALISATION & PRAKTISCHE EVALUIERUNG AM BEISPIEL DER
REFERENZUMGEBUNG ...................................................................................................................... 64
4.1 IBM WORKPLACE COLLABORATION SERVICES 2.5 / 2.6 .............................................................. 64
4.1.1 IBM Workplace Produktfamilie .......................................................................................... 67
4.1.2 Workplace Collaboration Komponenten ............................................................................ 68
4.1.3 IBM WCS Systemelemente, Funktion und Positionierung .................................................. 72 4.1.3.1 IBM WebSphere Application- und Portal-Server ......................................................................... 73 4.1.3.2 IBM Workplace Server 2 .............................................................................................................. 74 4.1.3.3 IBM Cloudscape und DB2 UDB ................................................................................................... 76 4.1.3.4 IBM Tivoli Directory / IBM Lotus Domino LDAP ...................................................................... 77 4.1.3.5 IBM HTTP Server ......................................................................................................................... 79
4.2 SYSTEMAUFBAU UND REALKONZEPT ........................................................................................... 80
4.2.1 Szenario .............................................................................................................................. 80
4.2.2 Realisation .......................................................................................................................... 82 4.2.2.1 Application Offload ...................................................................................................................... 84 4.2.2.2 WebSphere Application und Portal Kernsystem ........................................................................... 88 4.2.2.3 IBM Workplace Managed Client .................................................................................................. 90
4.3 ERFAHRUNGEN UND EVALUIERUNG DER SYSTEMARCHITEKTUR .................................................. 91
4.3.1 Stabilität und Verfügbarkeit für Produktivbetrieb .............................................................. 91
4.3.2 Datensicherung und – wiederherstellung ........................................................................... 92
4.3.3 Integrationsfähigkeit in bestehenden Systemkontext .......................................................... 92
4.3.4 Administrierbarkeit und Wartungsaufwand ....................................................................... 92
4.3.5 Kostenaufwand ................................................................................................................... 93
4.3.6 Installationsaufwand .......................................................................................................... 94
5 ZUSAMMENFASSUNG UND FAZIT ......................................................................................... 95
6 AUSBLICK ..................................................................................................................................... 97
7 LITERATURVERZEICHNIS ....................................................................................................... 98
EIDESSTATTLICHE ERKLÄRUNG ................................................................................................. 109
ANHANG ................................................................................................................................................ 110
Einleitung
5
Abkürzungsverzeichnis
AS Autonomous System
BGP Border Gateway Protocol
CSCW Computer Supported Cooperative Work
DFN Deutsches Forschungs-Netz
DB2 UDB DB2 Universal Database
DBMS Database Management System
DM Deployment Manager
DS Directory Service
EJB Enterprise Java Bean
eSSL Erweiterte Singe Server Lösung
HTML Hypertext Markup Language
HTTP Hypetext Transfer Protocol
J2EE Java 2 Enterprise Edition / Java Plattform Enterprise Edition
JAVA EE Java Plattform Enterprise Edition, ehemals J2EE
JAR Java ARchive file
JSP JavaServer Pages
LDAP Lightweight Directory Access Protocol
LTPA Lightweight Third-Party Authentication
LWP Lotus Workplace
LWWCM Lotus Workplace Web Content Management
NAB Name and Adressbook / The IBM Domino Directory
ND Network Deployment
PAC Portal Access Control
PDM Portal Document Manager
PME Programming Model Extension
RDBMS Relational Database Management System
SIP Session Initiation Protocol
SQL Structured Query Language
Einleitung
6
SSI Single Server Installation
SSL Secure Socket Layer
SSO Single Sign-on
UI User Interface
URL Uniform Resource Locator
WAS WebSphere Application Server
WAS EE WebSphere Application Server Enterprise Edition
WAS ND WebSphere Application Server Network Deployment
WCS Workplace Collaboration Services
WMC IBM Workplace Managed Client
WMM WebSphere Member Manager
WPCP WebSphere Portal Content Publishing
WPCP WebSphere Portal Content Publisher
WPMC Workplace Managed Client
WSRP Web Services for Remote Portlets
XSS Cross Site Scripting
Einleitung
7
Abbildungsverzeichnis / Tabellen
Abbildung 1-1 IBM Marken (2006) .................................................................................. 9
Abbildung 1-1 Aufbau der Arbeit ..................................................................................... 5
Abbildung 2-1 J2EE Application Server Components .................................................. 12
Abbildung 2-2 Referenzarchitektur für Portalsoftware .................................................. 17
Abbildung 2-3 LDAP SSO / Identity Management ........................................................ 22
Abbildung 2-4 X.500 und LDAP Middleware ................................................................ 24
Abbildung 2-5 Directory Datenstruktur .......................................................................... 26
Abbildung 2-6 Beispiel Three Tier Architektur ............................................................. 30
Abbildung 2-7 Horizontale Cluster Architektur ............................................................. 34
Abbildung 2-8 Vertikale Cluster Architektur ................................................................. 34
Abbildung 2-9 Beispiel Multi Node Architektur IBM WebSphere Cluster ................... 36
Abbildung 2-10 Network Deployment ........................................................................... 37
Abbildung 3-1 SSI .......................................................................................................... 43
Abbildung 3-2 Application Offload ................................................................................ 46
Abbildung 3-3 Beispielsystems AO Directory und DBMS ............................................ 59
Abbildung 3-4 J2EE-basierte kollaborative Systemarchitektur (eSSL) ......................... 61
Abbildung 4-1 IBM Workplace Solutions ..................................................................... 65
Abbildung 4-2 Workplace Produktintegration ............................................................... 66
Abbildung 4-3: Workplace Collaboration Services Komponentenstruktur ................... 69
Abbildung 4-4 IBM Workplace Managed Client............................................................ 71
Abbildung 4-5 Conceptual Lotus Workplace architecture ............................................. 74
Abbildung 4-6 Workplace Server ................................................................................... 75
Abbildung 4-7 IBM HTTP Server & IBM WebSphere .................................................. 80
Abbildung 4-8 Realszenario DNS ................................................................................... 82
Abbildung 4-9 eSSL Installation Roadmap .................................................................... 83
Abbildung 4-10 LDAP Schema Lotus Domino .............................................................. 87
Einleitung
8
Abbildung 4-11 Prototyp eSSL Architektur ................................................................... 89
Abbildung 4-12 WMC Connections ............................................................................... 90
Abbildung 4-13 Hardwareanforderungen eSSL.............................................................. 94
Einleitung
9
Anmerkungen
Die folgenden Begriffe sind Warenzeichen / Marken der International Business
Maschines Corporation (IBM) USA oder anderer Länder.
Abbildung 1-1 IBM Marken (2006)
Die folgenden Begriffe und Bezeichnungen sind Warenzeichen und Marken anderer
Hersteller:
Intel, Intel Inside (logos) und Pentium sind Warenzeichen / Marken der Intel
Corporation Microsoft, Windows, und die Windows Logos sind Warenzeichen / Marken
der Microsoft Corporation.
Java und alle Java-basierenden Auszeichnungen und Logos sind Marken /
Warenzeichen der Sun Microsystems Inc.
Andere Firmen-, Produkt-, und Servicenamen können Warenzeichen / Marken anderer
Hersteller sein.
1 Einleitung
„Wer will, dass ihm die anderen sagen, was sie wissen, der muss ihnen sagen, was er selbst
weiß. Das beste Mittel, Informationen zu erhalten, ist, Informationen zu geben“
Niccoló Macchiavelli (1469-1527)
Nachdem die Unternehmen in den letzten Jahren durch die Verbreitung von
Informationen via E-Mail unter der s.g. Informationsüberflutung litten, besinnen sich
heutige Ansätze wieder auf das Konzept von Ray Ozzie, dem Gründer von Lotus Notes.
Ray Ozzie ging es damals schon um ein „Information Sharing“ – dem Leitgedanken
hinter jeder Groupware-Idee. Im Gegensatz zu E-Mail handelt es sich dabei um einen
Ansatz von oben nach unten (Top-Down) – es werden Informationen verteilt bzw.
einem entsprechenden Benutzerkreis zentral zur Verfügung gestellt. Zudem bietet dieses
Konzept die Möglichkeit, neben dem reinen Informationsaustausch auch Anwendungen
und Verarbeitungslogiken zur Verfügung zu stellen. Hieraus entwickelten sich die
kollaborativen Portaltechnologien, die sich zum Arbeitsplatz der Zukunft 1 entfalten
können, indem sie den Desktop als klassische Arbeitsoberfläche ablösen. Diese
Entwicklung zeigt sich besonders bei betriebswissenschaftlichen Applikationen wie
dem Customer Relationship Management (CRM), Lösungen für Business Intelligence,
und Content- oder Projektmanagement; praktisch alle namhaften Hersteller bieten ein
integriertes Webfrontend für ihre Programme an. Browseranwendungen bieten zwar
(noch) weit weniger Benutzerkomfort als traditionelle PC-Software, bieten aber im
Idealfall z.B. eine vollständig plattformunabhängige Implementierungsmöglichkeit.
Java basierte kollaborative Systemarchitekturen bilden damit ein zukunftsweisendes
Konstrukt des „neuen“ digitalen Arbeitsplatzes und sind Kern der Bemühungen vieler
namhafter Softwarehäuser wie z.B. IBM.
Bei der Konzeption solcher Systeme bieten sich verschiedene Systemarchitekturen für
die Umsetzung kollaborativer Anwendungssysteme, die sich trotz ihres grundsätzlich
gleichen Anliegens z.B. im Bezug auf ihre Leistungsfähigkeit, Skalierbarkeit und
Integrationsfähigkeit in bestehende Strukturen unterscheiden. Die Konzeption einer
1 Vgl. Ebel (2005) S. 17 f.
Einleitung
2
solchen Systemarchitektur, bezogen auf definierte Anforderungen, stellt die zentrale
Aufgabe dieser Arbeit.
IBM entwickelt in diesem Kontext das Java-basierte kollaborative Produktportfolio
„IBM Workplace“. Die IBM Workplace Collaboration Services 2.5 / 2.6 bieten damit
eine Referenzumgebung für kollaborative Serverdienste, die für den praktischen Teil
dieser Arbeit zur Evaluierung einer möglichen Systemarchitektur dienen.
Im Rahmen der Seminararbeit „Konzeption eines Best Practice Guide zur
Administration einer IBM Workplace Infrastruktur“ 2 wurde ausschließlich die s.g.
Single-Server Variante einer IBM Workplace Systemarchitektur bearbeitet und in Form
eines Best Practice Guides erörtert.
Diese Diplomarbeit erweitert das bestehende Konzept um die Integrationsmöglichkeiten
bestehender Systemkontexte und betrachtet insbesondere die möglichen
Systemarchitekturen der IBM Workplace Collaboration Services.
Die Umsetzung des erarbeiteten Konzeptes erfolgt hierbei auf gestellter Hardware der
Firma VegaSystems Paderborn, die in diesem Rahmen die anfallenden einmaligen- und
laufenden Kosten übernimmt. Dieses erarbeitete und erprobte Konzept wird der
Universität Paderborn mit der vorliegenden Diplomarbeit zur Verfügung gestellt, um
zukünftige kollaborative Systemarchitekturen, auf Basis dieser empirischen Studie,
entwickeln und nutzen zu können.
2 Vgl. Altemeier, Tobias (2005): Konzeption eines Best Practice Guide zur Administration einer IBM
Workplace Infrastruktur
Einleitung
3
1.1 Zieldefinition
Ziel dieser Arbeit ist die Konzeption und praktische Evaluierung einer J2EE-basierten
Systemarchitektur für kollaborative Serverdienste am Beispiel der Referenzumgebung
IBM Workplace Collaboration Services 2.5 / 2.6.
Ziel ist die Konzeption einer Systemarchitektur, die neben den in der verfügbaren
Literatur genannten, konkrete Lösungsmöglichkeiten für die geforderten
Rahmenbedingungen erarbeitet. Hierbei wird insbesondere auf das Multi-Tier-Konzept
zur Auslagerung und Einbindung einzelner Teilkomponenten eingegangen. um eine
spätere Integration in die Infrastruktur der Universität Paderborn zu ermöglichen.
Mit Hilfe der Konzeption und praktischen Umsetzung einer IBM Workplace
Collaboration Services Architektur soll, anhand dieser Referenzumgebung, eine Lösung
entwickelt werden, die es ermöglicht, vorhandene Systemressourcen und –
Komponenten zu nutzen, um einer Gruppe von mindestens 25 Usern eine
Entwicklungs- und Testumgebung zu bieten.
Hierbei ist eine besondere Berücksichtigung der limitierten Hardwareressourcen der
Universität Paderborn und der Firma VegaSystems notwendig, trotzdem soll eine
Arbeitsumgebung geschaffen werden, die eine operative und performante Nutzung des
Gesamtsystems ermöglicht. Als weitere Anforderung soll die Wiederverwertbarkeit des
Konzeptes und Anwendbarkeit auf zukünftige Umgebungen gegeben sein, insbesondere
soll eine Architektur geschaffen werden die von anderen Administratoren auf den
eigenen Systemkontext übertragen werden kann. Maßgeblich sind somit die Nutzung
der vorhandenen Hard- und Softwareressourcen und eine besondere Berücksichtigung
der vorhandenen Infrastruktur.
Einleitung
4
1.2 Aufbau der Arbeit
In dem Einführungsteil werden die grundsätzlichen Merkmale von kollaborativen
Serverdiensten erläutert und abgegrenzt und bilden damit die Basis für das weitere
Verständnis. In der darauf folgenden Konzeptionsphase werden auf Basis der
Anforderungsdefinition verschiedene Systemarchitekturen diskutiert und bewertet.
Daraus resultierend wird eine konkrete Systemarchitektur entwickelt und in seinen
Details vorgestellt.
Im darauf folgenden Kapitel wird die erarbeitete Systemarchitektur in einer realen
Serverlandschaft umgesetzt und anhand definierter Merkmale evaluiert.
Insbesondere wird hierbei die Referenzumgebung IBM Workplace Collaboration
Services in den Gesamtkontext eingeordnet und anhand definierter Begriffe
kategorisiert und erörtert.
Die hierbei gewonnenen Erfahrungen und Kenntnisse bilden die Grundlage für den
Ergebnisteil dieser Arbeit.
Abschließend werden die gesammelten Ergebnisse in Form einer kurzen
Zusammenfassung erörtert und mögliche Konsequenzen für zukünftige Architekturen in
einem Ausblick aufgezeigt. 3
3 Siehe Abbildung 1-1 Aufbau der Diplomarbeit
Einführung Kollaborative Serverdienste
6
2 Einführung Kollaborative Serverdienste
In diesem Kapitel folgt ein Überblick über die für diese Arbeit notwendigen Grundlagen
und Merkmale kollaborativer Serverdienste. Zunächst werden die Fachbegriffe aus dem
Bereich des Computer Supported Cooperative Work erklärt und in den Gesamtkontext
kollaborativer Serverdienste eingeordnet. Im darauf Folgenden werden die
grundlegenden Konzepte Kollaborativer Serverdienste erläutert und definiert.
2.1 Globale Begriffsdefinition und -abgrenzung
Für das Verständnis dieser Arbeit ist eine klare Abgrenzung der verwendeten Begriffe
notwendig. Verschiedene Forschungsgruppen, Softwarehersteller und Publizisten
verwenden oft ein und denselben Begriff im gleichen Zusammenhang mit grundliegend
unterschiedlicher Definition. Begriffe werden gleichgesetzt (Synonym) die
kontextbezogen jedoch eine unterschiedliche Bedeutung haben.
Ein zentrales Unterscheidungskriterium in dieser Arbeit ist die Abgrenzung von
Systemelementen zu der Systemarchitektur.
2.1.1 Systemelemente versus Systemarchitektur
Systemelemente
Der Begriff System (v. griech.: σύστημα systema = das Gebilde, Zusammengestellte,
Verbundene; Pl. Systeme) bezeichnet ein Gebilde, dessen wesentliche Elemente (Teile)
so aufeinander bezogen sind und in einer Weise wechselwirken, dass sie (aus einer
übergeordneten Sicht heraus) als aufgaben-, sinn- bzw. zweckgebundene Einheit (d.h.
als Ganzes) angesehen werden (können) und sich in dieser Hinsicht gegenüber der sie
umgebenden Umwelt auch abgrenzen.4
Im Rahmen dieser Diplomarbeit beschreibt der Begriff „Systemelemente“ die
Teilkomponenten eines Gesamtsystems auf Funktionsebene. Relevant ist die Einordung
von Elementen nach ihrer Aufgabe (Funktion) und nicht nach ihrer strukturellen oder
strategischen Anordnung.
4 Vgl. Brockhaus Enzyklopädie 20. Auflage
Einführung Kollaborative Serverdienste
7
Am Beispiel eines KFZ sind typische Systemelemente z.B. der Motor, Tank und
Lenkrad. Für die Nennung und Beschreibung dieser Elemente ist die Anordnung nach
gewissen Gesichtspunkten zunächst unerheblich.
Systemarchitektur
Die Systemarchitektur ist ein Teilgebiet der technischen Informatik, welche sich mit
dem Design von Systemen und speziell mit deren Organisation sowie deren externen
und internen Aufbau beschäftigt.
Eine Architektur (vοn griech. αρχή = Anfang, Ursprung und lat. tectum = Haus, Dach) 5
behandelt in der Informatik im Allgemeinen das Zusammenspiel der Komponenten
eines komplexen Systems und beschreibt die Anordnung und Interaktion von
Systemelementen. Der Architekturbegriff findet dabei im wesentlichen in drei
unterschiedlichen Bereichen Anwendung: Einmal als Informationsarchitektur, die im
Rahmen der Wirtschaftsinformatik die Komponenten eines Informationssystems und
deren Beziehungen zueinander umfasst, des Weiteren als Softwarearchitektur, die im
Rahmen der Softwareentwicklung diese Beziehungen innerhalb eines Softwaresystems
aufstellt sowie schließlich der Rechnerarchitektur, die sich auf die Operationsprinzipien
und die Hardwarestruktur von Computern bezieht.6
Im Rahmen dieser Diplomarbeit beschreibt der Begriff „Systemarchitektur“ die
Anordnung von Systemelementen nach strukturellen und strategischen Merkmalen.
Hierbei steht weniger die Funktion im Vordergrund, vielmehr die sinnvolle Plazierung
in einem Gesamtsystem.
Am Beispiel des KFZ beschreibt eine mögliche Systemarchitektur z.B. die
Positionierung des Systemelementes „Lenkrad“ im Agitationsraum des Fahrers aus
strategischen Gesichtspunkten.
5 Vgl. Brockhaus Enzyklopädie 20. Auflage
6 Vgl. Hennessy, Patterson: (1994) S. 16 f.
Einführung Kollaborative Serverdienste
8
2.1.2 Computer Supported Cooperative Work und Groupware
„Computer Supported Cooperative Work (CSCW) stellt ein interdisziplinäres
Forschungsgebiet dar, das sich mit der Computerunterstützung kooperativen Arbeitens
befasst.“7. CSCW wird sowohl in der Literatur als auch in den verschiedenen
beteiligten Forschungsgebieten nahezu durchgängig als wissenschaftlicher Rahmen
beschrieben, „der das gesamte Forschungsgebiet des kooperativen Arbeitens umfasst“8.
Ziel dieses Forschungsgebietes ist es, die Zusammenarbeit von Menschen durch den
Einsatz von Informations- und Kommunikationstechniken zu verbessern.9
Groupware
Der Begriff Groupware wird in diesem Zusammenhang verwendet, wenn es um die
Umsetzung von Konzepten der CSCW-Forschung geht. Er meint somit im Besonderen
Softwarekomponenten und Anwendungssysteme, die die Zusammenarbeit von Personen
oder Arbeitsgruppen ermöglichen und explizit unterstützen. 10 Heute hat der Begriff an
Bedeutung verloren und wird in der Regel durch „Collaboration Software“ ersetzt.
2.1.3 Kollaboration und Serverdienste
Der Begriff Kollaboration (engl. collaboration) wird in der Literatur aufgrund der
negativ geprägten Bedeutung im deutschsprachigen Raum oft durch das deutsche Wort
Kooperation ersetzt11. Im Kontext dieser Arbeit wird der Begriff Kollaboration dennoch
zur Verwendung kommen und nach dem Verständnis von Levitt, Mahowald
interpretiert werden.
Die Definition besagt, “Collaboration involves people working together by sharing
information and processes”.12
7 Nastansky et al. (2000), S. 238
8 Nastansky et al. (2000), S. 239
9 Vgl. Hasenkamp, Kirn, Syring (1994), S. 15
10 Vgl. Barent et al. (1994), S. 1-4
11 Vgl. Nastansky et al. (2000), S. 241
12 Levitt, Mahowald (2002), S. 1
Einführung Kollaborative Serverdienste
9
Demnach kann Kollaboration als die Vereinigung verschiedener Dienste verstanden
werden, die alle elementaren Unterstützungsfunktionalitäten zur Zusammenarbeit von
Personen umfasst.
Unter Collaborative Software versteht man somit eine Auswahl an Software, die den
Zielen der CSCW- Forschung entspricht und im Allgemeinen auch als „Groupware“
bezeichnet werden kann. Groupwaresysteme wie z.B. IBM Lotus Notes gehören zur
Gattung der „Collaborativen Software“.13
Serverdienste
Im Englischen werden Dienste auch allgemein als „Services“ bezeichnet und
beschreiben Softwarekomponenten die, mittels definierter Schnittstellen,
Funktionalitäten oder Daten bereitstellen. Ein Dienst kann somit sowohl die Fähigkeit
der Verarbeitung von Informationen als auch das reine Bereitstellen dieser umfassen.
Serverdienste bilden eine Auswahl aus der Gesamtheit aller Dienste und grenzen sich
durch ihren Ausführungsort, der zentralen Server-Infrastruktur, ab.
Kollaborative Serverdienste definieren sich somit über das Ziel und den nativen
Ausführort Ihrer Funktionalitäten. Die Gesamtheit der zur Verfügung gestellten
Funktionen und Werkzeuge dienen zur Unterstützung kooperativer Arbeit und werden
serverseitig ausgeführt.
Somit sind Serverdienste Teil eines Client-Server-Systems, bei der die Ressourcen von
einem zentralen Server angeboten werden, auf die von den Arbeitsstationen (Clients)
aus zugegriffen werden kann. Der Server stellt die Dienste zur Verfügung, der Client
bietet die Benutzeroberfläche oder die Benutzerschnittstelle der Anwendung(en) an.
13 Nastansky et al. (2000), S. 239
Einführung Kollaborative Serverdienste
10
2.2 Grundsätzliche Merkmale von kollaborativen
Serverdiensten
Im Folgenden werden die den „kollaborativen Serverdiensten“ zugrunde liegenden,
Basis-Technologien erörtert, voneinander abgegrenzt und in den Gesamtkontext
eingeordnet.
Kollaborative Serverdienste dienen „der Zusammenarbeit von Menschen durch den
Einsatz von Informations- und Kommunikationstechniken“14 und basieren in der Regel
auf einer sinnvollen Kombination an verfügbarer Server- und Client-Software. Es ist in
diesem Kontext unerheblich, ob es sich bei einem kollaborativen System um ein
vollständiges „Produkt“ (z.B. IBM Workplace Collaboration Services) oder um
Teilimplementierungen (z.B. Webbasierte Dokumenten- oder Content-Management-
Systeme) handelt; die integrierten Technologien (im Folgenden Systemelemente
genannt) wie z.B. Webserver und Datenbankserver sind in jeder Systemarchitektur
vorhanden und notwendig. In der Vergangenheit hat sich das Konzept der Addition
durchgesetzt, d.h. es wurde keine vollständig neue Kollaborative-Software entwickelt
sondern vorhandene Technologien genutzt, um aus deren Synergie neue Lösungen zu
schaffen. 15
Das folgende Kapitel 2.2 ist somit allgemeingültig, nicht auf die IBM Workplace
Collaboration Services beschränkt, und gilt generell für alle verfügbaren kollaborativen
Systeme.
2.2.1 Systemelemente und deren Bedeutung für kollaborative Dienste
Im nächsten Schritt werden die einzelnen für ein kollaboratives Gesamtsystem
erforderlichen Systemelemente genannt und erläutert. Zunächst wird die Frage nach
dem „was“ (Begriffsdefinition) geklärt, gefolgt von dem „warum“ (individuelle
Bedeutung für kollaborative Dienste) und letztendlich das „wie“ (Funktionsweise). Die
folgenden Definitionen sind von essentieller Bedeutung für das Gesamtverständnis von
14 Vgl. Hasenkamp, Kirn, Syring (1994), S. 15
15 Vgl. Monson et al. (2005)
Einführung Kollaborative Serverdienste
11
kollaborativen Systemarchitekturen und werden daher in entsprechendem Umfang
behandelt.
2.2.1.1 Applikationsserver
Der Begriff „Application Server“ (APS) ist mehr eine Marketingbezeichnung als ein
einheitliches technisches Konzept.16 In der Regel ist ein Applikationsserver ein Server
auf dem spezielle Software-Applikationen in einer geeigneten Laufzeitumgebung
ausgeführt werden. Die Forrester Research Gruppe beschreibt beispielsweise einen
Application-Server einfach als ein „Softwareprodukt, das schlanke Clients mit einer
integrierten Suite verteilter Betriebsmöglichkeiten verbindet“ 17. Folglich müssen sie
Client-Sitzungen unterstützen und Verbindungen zu Ressourcen im Backend managen
(z.B. Datenbanken, Inhalte oder Transaktionen). Wird diese Definition noch um eine
Entwicklungsumgebung ergänzt, trifft man in etwa den Leistungsumfang heutiger
verfügbarer Produkte. Daher ist es schwierig, eine genaue Grenze zwischen Application
Server und Webentwicklungsumgebung zu ziehen.
In der Literatur werden diverse Definitionen für den Begriff „Anwendungsserver“
gegeben, die sich teilweise unmittelbar wiedersprechen. Einig wird die Unterstützung
komplexer Transaktionssysteme gefordert, selten die Komponentenfähigkeit eines
Application-Servers genannt. Die „Webfähigkeit“ wiederum wird von allen angeführt,
jedoch mit unterschiedlichen Prioritätensetzungen. Gleichzeitig lässt sich im Alltag
beobachten, dass der Begriff „Application-Server“ durchaus nicht einheitlich verwendet
wird. Transaktionsmonitore werden als Application-Server bezeichnet, Message
Oriented Middleware (MOM) Server ebenso wie Objekt Request Broker. Am
häufigsten fällt jedoch der Begriff immer noch im Zusammenhang mit Enterprise
JavaBeans und dem Internet.
Als Essenz kann ein Application-Server heute als Zusammenwachsen von
Nischentechnologien angesehen werden und vereinigt Middleware-Technologien
miteinander.
16 Love (2005) S. 16 ff.
17 Forrester Research ist eine unabhängige Firma die Technolgie- und Marktanalysen durchführt. Seit 22
Jahren ist Forrester nach eigenen Angaben eines der führendsten Unternehmen „helping global clients
lead in their markets through its research, consulting, events, and peer-to-peer executive programs”
Einführung Kollaborative Serverdienste
12
Ein Applikationsserver definiert sich somit über folgende Kernkompetenzen:
• Webserver
• Transaktionsmonitore
• Objekt Request Broker
• Sicherheitslösungen
• Datenbankzugriffslösungen
Abbildung 2-1 J2EE Application Server Components 18
Applikationsserver und deren Bedeutung für kollaborative Anwendungen
Heutige kollaborative Anwendungen werden in der Regel durch Applikationsserver
verwaltet und auf diesen ausgeführt. Dabei kann es sich um proprietäre Lösungen wie
z.B. IBM Lotus Domino / Notes oder Microsoft Groove handeln, die, wenn auch
erweiterbar, ein in sich geschlossenes Groupware-Konzept darstellen. J2EE oder Java
18 In Anlehnung an „A sample WebSphere Application Server single server installation” IBM 2005
Einführung Kollaborative Serverdienste
13
EE -basierte Applikationsserver zeigen jedoch gerade bei der Interoperabilität deutliche
Vorteile gegenüber proprietären Lösungen. Durch die Plattformunabhängigkeit schaffen
sie die Möglichkeit, kollaborative Anwendungen von Betriebssystemen unabhängig zu
gestalten und dem Entwickler die freie Wahl der Entwicklungsumgebung zu
ermöglichen. Durch die allgemein weite Definition des Begriffs „Applikationsserver“
basieren faktisch alle derzeitig verfügbaren kollaborativen Anwendungen auf einem
Applikationsserver-Konzept und sind von diesem nicht trennbar. Applikationsserver
sind somit fester Bestandteil der Implementierung von CSCW-Konzepten19.
Java
Java ist eine plattformunabhängige, objektorientierte Programmiersprache, die im
Frühjahr 1991 bis Sommer 1992 unter dem Projektnamen „The Green Project“ von
Patrick Naughton, Mike Sheridan und James Gosling sowie zehn weiteren Entwicklern
im Auftrag von Sun Microsystems entwickelt wurde.20 Das ursprüngliche Ziel der
Entwickler war jedoch nicht die Neuerschaffung einer weiteren Programmiersprache
sondern die Entwicklung einer vollständigen Betriebssystemumgebung, inklusive
virtueller CPUs, für variable Einsatzzwecke. Im März 1995 wurde die erste Alpha-
Version (1.0a2) des Java-Quellcodes freigegeben, und wenig später wurde Java das
erste Mal der Öffentlichkeit vorgestellt. Der endgültige Durchbruch für Java kam mit
der Integration in den Browser Netscape.
Der Entwurf der Sprache verfolgt vier Hauptziele:21
• Objektorientierung
• Plattformunabhängigkeit
• Vernetzbarkeit
• Sichere Ausführung auf fernen Computern
Derzeit gibt es eine Vielzahl an Entwicklungsumgebungen für Java, sowohl
kommerzielle als auch freie (Open Source). In der Regel wurden die meisten
19 Vgl. 2.1.3 Definition “Computer Supported Cooperative Work”
20 Vgl. Middendorf, Singer, Heid (2002) S. 11 ff.
21 Heuer, Saake (2000) S. 475 u. 490
Einführung Kollaborative Serverdienste
14
Entwicklungsumgebungen für Java selbst ebenfalls in Java geschrieben. Inzwischen
finden sich auch eigenständige Entwicklungsframeworks, die verschiedene Konzepte
von Java unabhängig weiterentwickeln. Die verbreitetsten Open-Source-Umgebungen
sind Eclipse, jEdit und NetBeans. Unter den kommerziellen Umgebungen sind vor
allem das auf NetBeans basierende Sun ONE Studio, JBuilder von Borland und IntelliJ
IDEA von JetBrains zu nennen. Darüber hinaus gibt es noch eine um Plug-Ins
erweiterte Version von Eclipse, die von IBM unter dem Branding „WebSphere Studio
Application Developer“ (WSAD) vertrieben wird.
J2EE / Java Platform, Enterprise Edition (Java EE) oder .NET
Java 2 Platform, Enterprise Edition, abgekürzt J2EE, ist die Spezifikation eines
Standards für eine Vielzahl von Softwarekomponenten, die primär in der
Programmiersprache Java erstellt werden. Die Spezifikation dient dazu, einen
allgemeinen akzeptierten Rahmen zu schaffen, um mit modularen Komponenten
verteilte mehrschichtige Anwendungen zu entwickeln. Klar definierte Schnittstellen
zwischen den Komponenten und Schichten sorgen dafür, dass Softwarekomponenten
unterschiedlicher Herkunft interoperabel sind.
Die meisten verfügbaren Application Server basieren heute auf der Java 2 Enterprise
Edition (J2EE). Es gibt jedoch einzelne Systeme, die nicht auf Java basieren und keine
bzw. nur in einigen Schnittstellen eine Java-Unterstützung leisten. Als Alternative bietet
sich derzeit neben Java z.B. noch die von Microsoft propagierte und entwickelte .NET
(Gesprochen: dot net) Technologie. Java und .Net haben viele Gemeinsamkeiten. Beide
bieten objektorientierte Programmierung, umfangreiche Klassenbibliotheken, diverse
Komponentenmodelle und Frameworks, Funktionen zur dezentralen Verarbeitung,
Webservices sowie eine verwaltete Ausführungsumgebung. Java Programme können im
Prinzip mit allen Java-Applikationsservern und allen Betriebssystemen eingesetzt
werden. Bei der Entscheidung für Java bleiben Wahlfreiheiten zwischen verschiedenen
Softwareherstellern, Microsoft hingegen unterstützt mit .Net zwar mehr als 25
verfügbare Programmiersprachen jedoch nur die eigene Windows
Betriebssystemumgebung. Es kommt daher zu einer allgemeinen Bevorzugung von Java
bzw. J2EE basierten Applikationsservern, weil die hier maßgebliche Java 2 Enterprise
Edition standardisiert und hierdurch die Interoperabilität gewährleistet ist. Für
(Windows-) Desktop zentrierte Anwendungen mit komplexen Benutzerschnittstellen
Einführung Kollaborative Serverdienste
15
wird hingegen oft .Net favorisiert, da die Nähe zu betriebssystem-verwandten Methoden
gegeben ist.
Neben umfassender Java-2-Unterstützung sind auch abgespeckte Applikationsserver
verfügbar, die nur einen Teil der J2EE-Spezifikationen implementieren und dafür
jedoch teilweise erheblich kostengünstiger zu erwerben sind. Solche s.g. Middelware
wie beispielsweise Tomcat22 oder Jetty23 enthält einen Webcontainer für das Hosting
von Servlets und JSPs (Java Servlet Pages), unterstützt jedoch EJBs (Enterprise Java
Beans), CORBA (Common Object Request Broker Architecture) und JMS (Java
Message Service) in der Regel nicht. Diese „schmalen“ Applikationsserver werden auch
allgemein als Servlet Engines bezeichnet.
2.2.1.2 Webserver
Ein Webserver ist im engeren Sinne ein Server-Dienst (Software), der Informationen
über das HyperText Transfer Protocol (HTTP) zur Verfügung stellt. Im weiteren Sinne
wird der Begriff Webserver – wie bei Server – auch für den Host verwendet (dann Web-
Host genannt), auf dem der Server-Dienst ausgeführt wird. Ein Web- oder HTTP-Server
dient grundsätzlich dem Rendern und Parsen 24 von HTML Quellcode. Erweiterte
Webserver (z.B. Lotus Domino HTTP-Task) erlauben zusätzlich das nahezu echtzeitige
„Übersetzen“ von Ansichten, Masken und Applikationen in eine HTML-Code-Struktur,
das (Volltext-) Suchen innerhalb von Webseiten und bieten Schnittstellen zu
Datenbank- oder Verzeichnisdiensten.
Webserver bilden die Grundfunktion für z.B. Portalserver und liegen somit auch in
Applikationsservern als Integrationsprodukt vor.
22 Apache Tomcat stellt eine Umgebung zur Ausführung von Java-Code auf Webservern bereit, die im
Rahmen des Jakarta-Projekts der Apache Software Foundation entwickelt wird.
23 Jetty ist ein Java-basierter Servlet/JSP-Container und Webserver. Er ist als Open-Source-Software unter
der Apache-Lizenz veröffentlicht, ist jedoch im Gegensatz zu Tomcat kein Projekt der Apache Software
Foundation. Vgl. http://www.mortbay.org/jetty/ (21.06.2006)
24 Vgl. Smith et. al. (2002)
Einführung Kollaborative Serverdienste
16
Webserver und deren Bedeutung für kollaborative Anwendungen
Webserver (HTTP-Dienste) stellen den zentralen Dienst für die Schnittstelle zwischen
User (Client) und Server. Bei einem Großteil der ThinClient-Konzepte wird die
Benutzeroberfläche in Form einer Webseite oder eines Web-Portals bereitgestellt. Aber
auch in RichClient-Varianten werden Teilbereiche durch die Integration von
Webinhalten realisiert, um Informationen in möglichst allen Clientvarianten verfügbar
zu machen. Der Webserver-Dienst (Task) gehört somit unabdingbar zum Konzept
kollaborativer Anwendungen und ist in allen verfügbaren System-Architekturen
kollaborativer Dienste integriert oder ihnen angeschlossen.
Der HTTP-Dienst ist darüber hinaus, neben den Datenbanksystemen und integrierten
Anwendungen, maßgeblich an der „spürbaren“ Performance eines Systems beteiligt und
einer der kritischen Komponenten für die Akzeptanz des Users.
Dynamische- und statische Webserver
Im Umfeld einer typischen Website liefert ein Webserver vorwiegend statische Daten
wie HTML (Web) -Seiten, Stylesheets (z.B. CSS) oder Grafiken (PNG, JPG, GIF,
BMP) zurück. Neben statischen Daten werden heute zunehmend (mehrfach)
dynamische d. h. beim Abruf erzeugte Daten ausgeliefert. Dieses wird in der Regel
durch den Einsatz von Skripten (PHP, JSP, ASP), Server-Containern (Servlets, J2EE,
ASP.NET) und Webservices (SOAP, XML-RPC) realisiert. Durch die Verwendung
dynamischer Seiten wird u. a. z.B. interaktive Benutzerführung oder eine individuelle
Gestaltung der Benutzeroberfläche ermöglicht. Beispiele für dynamische Seiten sind
Foren, Portale und kollaborative Serverdienste.
2.2.1.3 Portalserver
Portale
Der Begriff „Portal“ erfährt ähnlich wie der Begriff „Applikationsserver“
unterschiedliche Interpretationen und ist oft Gegenstand marketingtechnischer
Bemühungen und wird so fälschlicherweise missbraucht.25 Im Sinne einer kleinsten
Gemeinsamkeit könnte definiert werden, dass „ein Portal unterschiedliche
Informationsarten in einer gemeinsamen Oberfläche zusammenfasst, wobei (…) diese
25 Rütschlin (2001) S. 691-696.
Einführung Kollaborative Serverdienste
17
Eigenschaft Aggregation genannt wird“.26 Nach dieser Definition wäre bereits jede
etwas komplexere Webseite mit oder ohne Content-Management-System (CMS) bereits
ein Portal. Der Portalbegriff stützt sich somit nicht allein auf die Aggregation, sondern
muss mit Hilfe etablierter Standards präzisiert werden.
Ein Portal kann viel mehr als ein serverbasiertes (Web-) Oberflächensystem verstanden
werden, das verschiedene unabhängige Informationsquellen und Anwendungen vereint
(aggregiert) und in integrierter Weise benutzbar macht. Portaltechnologien umfassen in
der Regel weitere Features wie z.B. Integrationsstandards, Personalisierung, Single-
Sign-On, CMS-Funktionen und die Möglichkeit, sowohl dynamischen Content
(Anwendungen) als auch statischen Content (z.B. Dokumente) einzubinden.
Abbildung 2-2 Referenzarchitektur für Portalsoftware 27
26 Zitat: Ebel (2005) S. 465
27 Aus Gurzki, Hinderer, H. (2003) S. 158
Einführung Kollaborative Serverdienste
18
Portalserver
Portalserver stellen im Allgemeinen die oben genannten Technologien dem User über
definierte Schnittstellen, in der Regel über das http-Protokoll, bereit. In den meisten
Fällen stellt ein Portalserver eine Erweiterung oder zweckgebundene Nutzung des
Applikationsservers dar. Somit liegt den Portalservern ein Applikationsserver-Modell
zugrunde, das die Grundfunktionen wie Datenbankanbindung, Verarbeitung-Logik und
Präsentation leistet. 28
Portalserver und deren Bedeutung für kollaborative Anwendungen
Kollaborative Systeme bieten dem User eine Interaktion mit dem System oft über so
genannte ThinClients (z.B. Webbrowser) oder RichClients.
Der Rich-Client ist ein "neuer" Ableger des s.g. FatClients, meist handelt es sich um ein
Framework, das durch Module und Plugins erweiterbar ist. Beispiele hierfür sind der
IBM Workplace Managed Client aber auch der IBM Lotus Notes Client für IBM Lotus
Domino.
Bei den meisten ThinClients, insbesondere den Webbrowser-Varianten, wird der
Arbeitsbereich (Workspace) bei einer kollaborativen Anwendung durch ein
webbasiertes Portal bereitgestellt. Der Benutzer arbeitet auf einer, den eigenen
Bedürfnissen anpassbaren, Weboberfläche und nutzt diese zur Interaktion mit den
einzelnen Systemkomponenten.29
Portalserver stellen somit eine wichtige Basistechnologie für kollaborative Systeme dar
und sind eine wichtige Komponente bei der Anbindung von (Ultra30) ThinClients. 31
Horizontale- und Vertikale Portale
Zusätzlich spielt in der Praxis eine Unterscheidung zwischen horizontalen und
vertikalen Plattformen eine wichtige Rolle. Diese Kategorisierung hilft vor allem bei der
28 Vgl. Abbildung 2-1 Referenzarchitektur für Portalsoftware
29 Vgl. IBM Redbook (2003): IBM WebSphere Portal V4.1 Handbook Volume 1
30 Ein Ultra Thin Client bezeichnet in der elektronischen Datenverarbeitung eine Anwendung oder einen
Computer als Endgerät eines Netzwerkes, deren Funktion ausschließlich die Anzeige von Daten ist.
31 Vgl. Ebel (2005) S. 473
Einführung Kollaborative Serverdienste
19
Unterscheidung von Informations- und Integrationstiefe und ist notwendig bei der
Klassifikation von Portalen und elektronischen Marktplätzen.
Horizontale Portale versuchen den Benutzer durch eine redigierte Struktur zum
gesuchten Angebot zu leiten und sind häufig auf den privaten Gebrauch ausgerichtet.
Vertikale Portale fokussieren auf eine spezielle Thematik oder Zielgruppe (z.B.
Branche) und versuchen Angebote für eine Zielgruppe zusammenzufassen.
Daraus ergeben sich zusammengefasst vier Grundformen von Portalen:
• Consumer-Portal
o Horizontale Portale als Einstiegspunkt in Webangebote. Sie bieten in der
Regel einen Katalog mit thematisch sortierten und zumeist ausgewählten
Verweisen
• Business-Portal 32
o Vertikale Portale als zentrale Anlaufstelle für Kunden eines
Unternehmens oder für Interessensgruppen. Sie beschränken sich nicht
allein auf eine reine Informationsvermittlung sondern bieten produkt-
oder unternehmensbezogene Dienste wie Shop-Funktionen und After-
Sales-Support. Die Besucher dieser Portale bilden „Business-
Communities“, die sich durch die themenzentriete Bündelung von
Wissen und Informationen auszeichnen. Das Informationsangebot ist oft
individuell auf die Bedürfnisse des Benutzers anpassbar.
• Corporate- oder Enterprise-Portal 33
o Mitarbeiterbezogenes Portal auf dem mit entsprechenden Rollen und
Rechten sowohl Informationen gelesen als auch geschrieben werden
können. Es ist als Unternehmensportal eine Firmenanwendung für
Mitarbeiter und bildet den Kern eines Intranets. Es wird zwischen
Eterprise Information Portals (EIP), Enterprise Applikation Portals
(EAP) und Enterprise Knowledge Portals (EKP) unterschieden.
32 Vgl. Gurzki, Hinderer (2003) S. 157-160
33 Vgl. Bauer (2001) S. 3 ff.
Einführung Kollaborative Serverdienste
20
2.2.1.4 Verzeichnisdienste
Verzeichnisse
Im Internet und unternehmensinternen Intranet werden Verzeichnisse in der Regel dazu
verwendet, Benutzerdaten zentral zu sammeln und Applikationen zur Verfügung zu
stellen. Diesen Datensammlungen liegt meist eine Datenbank zugrunde, in der die
Daten aufgenommen werden. Um mit diesem Dienst in Kontakt zu treten werden
sogenannte Netzwerkprotokolle verwendet, um Daten aus dem Verzeichnis abzufragen
oder zu aktualisieren. In den meisten Fällen kommt dabei ein sogenanntes Directory
Access Protocol (DAP) zum Einsatz, Standard-Implementierungen dieses Protokolls
sind DAP aus der X.500-Architektur sowie LDAP einer „leichtgewichtigen„
(lightweight) Form von DAP.34
Ein Verzeichnisdienst (englisch: Directory Service (DS)) ist somit eine im Netzwerk
verteilte hierarchische Datenbank, die auf dem Client-Server Prinzip basiert. In dieser
Datenbank können beliebige Informationen gespeichert werden. Die Einträge in der
Datenbank können verglichen, gesucht, erstellt, modifiziert und gelöscht werden.
Meistens wird lesend auf die Daten eines Verzeichnisdienstes zugegriffen.
Veränderungen an den Einträgen dieser Datenbank sind eher selten. Aus diesem Grund
bieten Verzeichnisdienste lesend eine wesentlich geringere Zugriffszeit als andere
Datenbanken.
Verzeichnisdienste (VD) können in verschiedenen Formen auftreten, ihnen sind aber
folgende Eigenschaften gemeinsam:
• Optimiert für Lesezugriffe: Auf ein Verzeichnis wird fast ausschließlich lesend
und selten schreibend zugegriffen. Dieses ist der signifikanteste Unterschied zu
Datenbanken.
• Informationsablage: Ein VD dient nicht nur der Speicherung von Informationen,
er implementiert ein verteiltes Modell zur Informationsablage.
• Baumstruktur: Die Informationen werden in meinem Verzeichnisbaum
organisiert. Es können mehrere Personen für die Administration von
34 Vgl. Chater (2003) S. 4 ff.
Einführung Kollaborative Serverdienste
21
Teilbereichen des Verzeichnisbaums zuständig sein. Durch die Baumstruktur ist
eine effiziente Suche möglich (Suche in Teilbäumen)
• Replikation: Verzeichnisdienste bieten die Replikation zwischen
unterschiedlichen Verzeichnisservern zum Datenabgleich an.
• Asynchron: Bei mehreren Anfragen über das Protokoll müssen die Antworten
nicht in der gleichen Reihenfolge erfolgen wie die Anfragen
Verzeichnisdienste und deren Bedeutung für kollaborative Anwendungen
Kollaborative Anwendungen und Dienste stellen dem Benutzer eine Reihe an
umfangreichen Funktionen zur Verfügung, die auf verschiedenen, teilweise getrennt
laufenden, Softwareapplikationen beruhen. Groupware ist heute kein einzelnes
„Softwareprodukt“ mehr sondern eine bewußte Kombination aus Kommunikations-,
Kollaborations- und Koordinationssoftware. Instant Messaging, E-Mail, Dokumenten-
Management und Aktivitäten-Management werden heute dem User zwar über ein
Userinterface vereint zur Nutzung angeboten (vgl. IBM Workplace Collaboration
Services), greifen im Backend jedoch auf einzelne, getrennte Softwarekomponenten wie
z.B. IBM Lotus Sametime, IBM Lotus Notes / Domino, IBM WebSphere zurück. 35
Um hier eine nahtlose Integration zu schaffen sind Verzeichnisdienste von essentieller
Bedeutung.
Die Benutzer- und Diensteverteilung für unterschiedliche Systeme auf der Grundlage
von einzelnen dezentralen Datenspeichern würde hier zu vielfachen Registrations- und
Anmeldeprozessen führen und inkonsistente Datenbestände fördern.
Zentrale Verzeichnisdienste sind die Grundvoraussetzung für die Realisierung von
Single Sign-On (SSO)36, der einmaligen, netzweiten Anmeldung von Benutzern
unterschiedlicher Dienste.
Im Rahmen kollaborativer Anwendungen spielt das Identity Management 37 eine weitere
wichtige Rolle. Ob Activity Management, Dokumenten- mit Versionsmanagement oder
35 Ebel (2005) S. 551 ff.
36 Siehe Abbildung 2-2 LDAP SSO / Identity Management
37 Siehe Abbildung 2-2 LDAP SSO / Identity Management
Einführung Kollaborative Serverdienste
22
direkte one-to-one Kommunikation (z.B. E-Mail oder Instant Messaging), bei allen
Vorgängen und Dokumenten existieren Referenzen zu den jeweiligen Autoren oder
Zuständigen. Ein Aktivitäten-Management ohne Bezug zu den jeweiligen Autoren oder
Editoren würde sich selbst wiedersprechen. Alle Vorgänge innerhalb z.B. einer
Groupwareplattform werden z.B. aus Sicherheitsgründen,
Nachverfolgungsmöglichkeiten und dem Personenbezug immer mit eingebetteten
Userdaten abgespeichert. Arbeitsabläufe (Workflows) sind ohne Identitäts-Management
nicht möglich. Als Speicherort aller Informationen über die gemanagten Identitäten
dient heute in der Regel ein zentrales LDAP kompatibles Verzeichnis.
Abbildung 2-3 LDAP SSO / Identity Management
Einführung Kollaborative Serverdienste
23
LDAP und X500
Mit dem Lightweight Directory Access Protocol (LDAP) und X.500 Standards haben
sich zwei Gattungen von Spezifikationen für Verzeichnisdienste etabliert, die in einer
engen Beziehung zu einander stehen. Dies hat historische Gründe und geht auf das frühe
PC- und Client/Server Zeitalter zurück.
In der Zeit bis zum Jahr 1985 existierten in den typischen Firmennetzen diverse
historisch gewachsene Systemarchitekturen nebeneinander. Der Datenaustausch
zwischen verschiedenen Systemen gestaltete sich äußerst komplex, da es entweder
keine oder nur sehr unzulängliche Schnittstellen zwischen den verschiedenen Systemen
gab. Mit der fortschreitenden Computerisierung der Arbeitsplätze verstärkte sich das
Bedürfnis, Daten auch zwischen verschiedenen Systemen austauschen zu können.
Typischerweise wollte man am Arbeitsplatz auf einen Unix-Server oder Mainframe
zurückgreifen. Bei der Entwicklung von Interfaces, die ad hoc zwei Architekturen
miteinander verbanden, zeigten sich deutliche Schwächen. Dieser Ansatz hat einen
entscheidenden Nachteil:
Um eine Anzahl von n verschiedenen Systemen zu verbinden, braucht man auf diese
Weise (1 /2) n (n-1) individuelle Schnittstellen.38
Der Aufwand wächst somit quadratisch mit der Anzahl der zu verbindenden Systeme.
Die langfristig weniger aufwendige Alternative zum oben beschriebenen
Interfacemodell stellt das Schichtenmodell dar. Dabei wird ein zentrales
Kommunikationsprotokoll definiert, über das alle angeschlossenen Systeme mittels
definierter Schnittstellen kommunizieren.39
Der Aufgabe eines Neuentwurfes widmete sich das Comitè sonsultatif international
télégraphique et téléphinique, kurz CCITT, eine Unterorganisation der Vereinten
Nationen mit Sitz in Genf, die später zur International Telekommunication Union (ITU)
wuchs. Die ITU verabschiedete im Lauf der Jahre zahlreiche Standards, die als X-Series
bekannt wurden.
Für die Verzeichnisdienste existieren eine Reihe von X-Standards: die X.500 Series
genannt. Diese Standards definieren wie Verzeichnisdaten zur Verfügung gestellt und
38 Vgl. Klünter, Laser (2003) S. 9
39 Vgl. Fischer et al. (2000) S. 126 ff.
Einführung Kollaborative Serverdienste
24
abgerufen werden sollen, wie Verschlüsselung, Authentifizierung, Replikation und
Verwaltung der Daten gehandhabt werden und liefern vor allem Modelle und Begriffe
auch für abgewandelte Verzeichnisdienste, die nicht mehr vollkommen auf dem X.500
Standard beruhen, wie LDAP. 40
Die X.500 Spezifikation definiert zwei Subprotokolle namens Directory System
Protocol (DSP) und Directory Access Protocol DAP. Während das DSP die
Kommunikation der Server untereinander sicherstellt, dient das DAP zur Interaktion
zwischen Benutzerprozess und Serverprozess. Durch die Umstellung vieler Protokolle
auf das Internet-Protokoll (TCP/IP) Mitte der 90er Jahre wurde der Einsatz des DAP
Protokolls erschwert: DAP setzt auf der Transportschicht des ISO-Protrokollstacks und
nicht auf dem nun verbreiteten Transmission Control Protocol (TCP) auf. Als Reaktion
auf die Einführung des TCP/IP Protokolls wurde im Juli 1993 im „Request for
comments“ 41(RFC) Nr. 1487 das Lightweight Directory Access Protocol spezifiziert,
was man leger aber suggestiv mit „abgespecktes DAP“ übersetzen kann.
Die ursprüngliche Idee hinter LDAP war, dass dieses Protokoll serverseitig durch eine
Middleware implementiert werden sollte, die per LDAP mit den Clients und über die
X.500-Protokolle mit einem oder mehreren X-500-DSP(s) kommuniziert. 42
Abbildung 2-4 X.500 und LDAP Middleware
40 Vgl. Klünter, Laser (2003) S. 9 ff.
41 Siehe hierzu: http://www.ietf.org/rfc/rfc1487.txt
42 Siehe Abbildung 2-3 X.500 und LDAP Middelware
Einführung Kollaborative Serverdienste
25
Für den wachsenden Erfolg von LDAP ist aber auch der Paradigmenwechsel
mitverantwortlich, durch den sich die Einsatzgebiete dieses Protokolls verlagern, weg
von einer Middleware die zwischen TCP/IP und X.500 vermittelt, hin zu einer
Serversoftware die LDAP-fähigen Clients den Zugriff auf eine fast beliebige Datenbasis
vermittelt. 43
Das Lightweight Directory Access Protocol
Das LDAP ist zwar durch internationale RFCs definiert jedoch bis heute noch kein
offizieller Standard. Dennoch wird allgemein von einem De-facto-Standard gesprochen.
Das LDAP vermittelt die Kommunikation zwischen dem LDAP-Client (zum Beispiel
einem Mailserver, einem Mailclient oder einem digitalen Adressbuch) und dem
Verzeichnis (Directory Server), aus dem benutzerrelevante Daten ausgelesen werden.
Im administrativen Sprachgebrauch spricht man von einem LDAP-Server, dabei meint
man einen Directory-Server, dessen Daten-Struktur der LDAP-Spezifikation entspricht,
und der über das Netzwerkprotokoll LDAPv3, ohne Middleware, Daten mit Client-
Systemen austauschen kann.
Da LDAP als Zugriffsprotokoll auf X.500-Verzeichnisse entworfen worden ist, beruht
es auf der Nomenklatur der X.500 Struktur. Die Einträge sind als Objekte verpackt, sie
bestehen aus Attributen mit Typen und Werten und sind in einem hierarchischen Baum
strukturiert. 44
Dieser in einer objektorientierten Baumstruktur abgelegte Baum kann über mehrere
Server verteilt sein. Jedes Element in diesem Baum ist ein Objekt. Jedes dieser Objekte
hält verschiedene Attribute. Sowohl die Objekte als auch die Attribute unterliegen
festen Definitionen: dem LDAP Schema. In diesem Schema wird definiert, welche
Objekte welche Attribute besitzen können, als auch welche Attribute vorhanden sein
können und welche vorhanden sein müssen. Durch Erweiterungen der Schemata lassen
sich weitere Strukturen und Definitionen für additive Attribute hinzufügen.
43 Vgl. Charter (2003) S. 6 ff
44 Siehe Abbildung 2-4 Directory Datenstrukutr
Einführung Kollaborative Serverdienste
26
Abbildung 2-5 Directory Datenstruktur
Jedes Schema-Element (Attributtypen, Objektklassen, Regeln (Syntax), Mathcing Rules
usw.) besitzt eine weltweit eindeutige Nummer, mit der es identifiziert werden kann –
die Object ID (OID45). Dies ist, neben einem sprechenden Namen, die zweite
Möglichkeit, ein in einem Schema definiertes Objekt zu referenzieren.
Eine Objektkennung (OID) ist eine Zahl, die eine Objektklasse oder ein Attribut in
einem Verzeichnisdienst eindeutig kennzeichnet. OIDs werden von
Herrausgabeinstanzen (z.B. Verisign) ausgestellt und bilden eine Hierarchie. Eine OID
wird als Zeichenfolge in punktierter Dezimalschreibweise (beispielsweise 2.16.840.1)
dargestellt. Organisationen (und Einzelpersonen) können von einer Herausgabeinstanz
eine Stamm-OID erhalten und unter Verwendung dieser Stamm-OID weitere OIDs
reservieren. Sind eigene Objekte für LDAP notwendig, wird ein eigener Object
45 OIDs sind weltweit eindeutige Kennzeichnungen für Objekte und sind in ISO/IEC 9834/1 normiert.
Objekte sind persistente, wohldefinierte Informationen, Definitionen oder Spezifikationen und werden als
Identifikationen (IDs) und Kodierungen wiedergegeben.
Einführung Kollaborative Serverdienste
27
Identifier notwendig. Die Vergabe läuft über die IANA46 (Internet Assigned Numbers
Authority)
LDAP-Schema
Verschiedene Dienste (z.B. IBM Lotus Domino) sind heute in der Lage, zentrale
LDAP-Dienste für Clients bereitzustellen. Durch die s.g. LDAP-Schemas werden die
vorhandenen, oder benötigten, Objektstrukturen auf die LDAP Spezifikationen
übersetzt. LDAP-Objekte sind standardisiert, um die Zusammenarbeit mit anderen
Verzeichnisdienst-Servern zu gewährleisten. Ein LDAP-Schema definiert die Liste
möglicher Typen von Einträgen (Objektklassen) zusammen mit den mit ihnen
verknüpften Attributen. Ein Schema stellt also eine Sammlung von Strukturdefinitionen
(Metadaten) dar.
• Definition der zu verwendenden Attributklassen
• Definitionen der zu verwendenden Objektklassen
• Filter/Matching-Regeln bei Vergleichsoperationen
• Rechte zum Anlegen und Modifizieren von Datensätzen 47
Dazu gehören die Beschreibungen der Klassen und der verwendeten Typen. Es gibt
verschiedene Schemata, und es ist möglich, eigene zu definieren (oder bestehende
anzupassen oder zu erweitern).48
Jeder LDAP-Server besitzt ein oder mehrere bekannte Standard-Schemata, auf die man
zurückgreifen kann. Jeder Anwendungsentwickler kann sich somit darauf verlassen,
dass ein LDAP kompatibler Server auf bestimmten Standard-Objektklassen und
Attributen beruht.
Zur praktischen Untersuchung von Standard-LDAP-Schema-Objekten sind
verschiedene LDAP-Schema-Viewer verfügbar, die eine praktische Schnittstelle zu
LDAP Servern bieten. 49
46 Siehe auch: http://www.iana.org/
47 In Anlehnung an: Ebel (2005) S. 252
48 Vgl. Carter (2003) S.14 ff.
49 Siehe hierzu z.B.: http://ldap.akbkhome.com/index.php oder http://www.ldapbrowsers.com/
Einführung Kollaborative Serverdienste
28
2.2.1.5 Datenbanksysteme und DBMS
Ein Datenbanksystem (DBS) ist per Definition ein System zur elektronischen
Verwaltung von Daten, dass sowohl große Datenmengen speichern können und diese
Daten einem beliebigen Prozess durch Abfrageoptionen wieder zur Verfügung stellen
muss.50 51 Das Gesamtsystem besteht dabei aus dem eigentlichen Datenspeicher, der
Datenbank und der Verwaltungssoftware, dem Datenbank Management Systems
(DBMS), bei relationalen Datenbanken auch RDBMS genannt.
Deine Datenbank muss folgende Kriterien berücksichtigen:52
• Strukturierung und Integrität der gespeicherten Daten
o Vermeidung von Datenredundanz
• Sprachunterstützung wie
o Datenabfrage und -manipulation (DML)
o Verwaltung der Datenbank (DDL)
o Berechtigungssteuerung (DCL)
• Mehrbenutzerfähigkeit
• Betriebssicherung
o Verwaltung von Metadaten
o Backup und Recovery
o Daten-Import und –Export
o Geschwindigkeitsgarantie auch bei großen Datenbeständen
Diese Gruppe von Anforderungen zeichnet Datenbanksysteme im engeren Sinne
gegenüber funktional erweiterten Dateisystemen aus.
50 Vgl. Olle (1978) S. 13 ff.
51 Vgl. Codd (1979) S. 377-387
52 Vgl. Heuer (2000) S. 2 ff.
Einführung Kollaborative Serverdienste
29
Datenbanksysteme und deren Bedeutung für kollaborative Anwendungen
Softwaresysteme wie Dateiverwaltungssysteme, Tabellenkalkulation und auch
Programmiersprachen können große Datenmengen nicht „effizient“53 verarbeiten und
ermöglichen keinen parallelen Zugriff mehrerer Benutzer oder Anwender auf den
gleichen Datenbestand. In der Anwendungsentwicklung führt der fehlende Einsatz einer
zentralen Datenbank zu Problemen, da Anwendungen ohne die Kenntnis über die
interne Darstellung der Daten sowie Speichermedien oder Rechner (bei verteilten
Systemen) nicht programmiert werden können. Diese Problematik bezeichnet man als
fehlende Datenunabhängigkeit. Auch ist die Sicherstellung der Zugriffskontrolle und
der Datensicherheit ohne zentrale Datenbanksysteme nicht gewährleistet.
Im Rahmen kollaborativer Anwendungen sind jedoch z.B. der parallele Datenzugriff
(Kollaboration), das Rapid Application Development und die definierte
Zugriffskontrolle wichtige Voraussetzungen für die (online) Zusammenarbeit. Somit
sind zukunftsorientierte kollaborative Anwendungen und –Systeme nicht ohne
Datenbank- (DBS) und Datenbank-Management-Systeme (DBMS) zu realisieren.
2.2.2 System-Architekturmerkmale und deren Bedeutung für
kollaborative Dienste
Kollaborative Systeme werden in der Regel als s.g. mehrschichtige (multi-tier
architecture) Systeme implementiert und bestehen im Wesentlichen aus einer
Präsentationsschicht (presentation tier), der Logigschicht (logic tier oder application-
server tier) und der Datenschicht (data tier oder data-server tier). 54
Die Präsentationsschicht übernimmt dabei die Repräsentation der Daten und ist
verantwortlich für die Interaktion mit dem Benutzer; sie wird häufig als Front-End
bezeichnet und mit Hilfe von Webbrowsern und ThinClients gesteuert.
In der Logigschicht werden Informationen (Daten) verarbeitet (Geschäftslogig) und an
die angrenzenden Schichten bidirektional weitergeleitet. Diese so genannte
53 Vgl. Heuer, Saake (2000) S. 3 ff.
54 Vgl. Abbildung 2-6 Beispiel Multi Tier Archtektur
Einführung Kollaborative Serverdienste
30
„Programmintelligenz“55 wird durch Applikationsserver-Modelle realisiert und ist die
Kernkomponente aller kollaborativen Serverarchitekturen.
Die Services der dritten Schicht (Datenschicht) umfassen eine eigenständige Sammlung
von Datenbanken, Ressourcenmanagern und Mainframe-Anwendungen. Die Interaktion
mit der Datenschicht muss über die Prozesse der zweiten Schicht erfolgen, ein direkter
Zugriff auf Ressourcen des data-tier ist nicht möglich.
Abbildung 2-6 Beispiel Three Tier Architektur 56
Bei diesen Schichten handelt es sich um logische Schichten; sie werden unter
Umständen nicht auf demselben physischen Server ausgeführt. Offene
Standardprotokolle und Schnittstellen zur Anwendungsentwicklung (API’s application
programming interface) gewährleisten die Kommunikation zwischen verteilten
Systemelementen und erlauben die freie Wahl der Programmiersprache für die
Entwicklung der Client-Komponenten.
Bei dem J2EE-tier Modell, einer Variante der mehrschichtigen Architektur, wird das
drei-schichtige-Modell um die s.g. client-tier erweitert und beschreibt zusätzlich die
55 Ebel (2005) S. 372
56 Ohne Autor (http://en.wikipedia.org/wiki/Image:Overview_of_a_three-tier_application.png)
06.07.2006
Einführung Kollaborative Serverdienste
31
Funktionalitäten der Thin- und Richclients.57 Die Präsentationsschicht wird dadurch auf
einen reinen „logischen Unterbau“58 der Benutzerschnittstelle reduziert.
Die verschiedenen Schichtenmodelle beschreiben lediglich die logische Anordnung
einzelner Systemelemente und machen keine Aussage über die physikalische Verteilung
auf mehrere mögliche Systeme. Die Auslagerung von Anwendungen (application
offload 59) wird durch die modulare Konzeption der Systemelemente jedoch erst
ermöglicht.
Um verschiedenen kausalen Grundsätzen kollaborativer Systemarchitekturen gerecht zu
werden, bieten sich die im Folgenden genannten Basis-Systemarchitekturen, die in der
Praxis häufig als Kombinat auftreten:
2.2.2.1 Single Node Architektur / Single Tier Architektur
Unter einer single node oder single tier Architektur wird die Implementierung des
Schichten-Modells auf einer Hardwareressource (z.B. einem Server) verstanden. Alle
Systemelemente teilen sich die vorhandenen Systemressourcen und kommunizieren
durch definierte Schnittstellen miteinander. Softwareentwickler bezeichnen in ihren
Produkten diese Installationsvariante auch als s.g. „Single Server Installation“ oder
„Single Server Variante“.
IBM nennt diese Architektur bei komplexeren Systemen auch warnend „demo
deployment“ oder „express-Konfiguration“ und rät damit von der Installation eines
Produktivsystems auf nur einem node (Server) wegen mangelnder Performance ab. Bei
heutigen Softwarearchitekturen zeigt sich, durch das Konzept der Addition60
vollständiger Softwareprodukte, eine steigende Anforderung an die Leistung der
einzelnen Serversysteme. Die einzelnen Schichten werden durch den Einsatz
vollständige Softwareprodukte realisiert und bieten dadurch einen großen
Funktionsumfang. Die vorhandenen Hardwareressourcen werden hierbei jedoch häufig
57 Ebel (2005) S. 373 ff.
58 Ebel (2005) S. 373
59 Ebel (2005) S.379
60 Vgl. Kapitel 2.2
Einführung Kollaborative Serverdienste
32
durch nicht benötigte Funktionalitäten blockiert, was zu einer Reduzierung der
Arbeitsgeschwindigkeit des Systems führt. Zur Diagnose dieser Schwächen liefern
Softwareanbieter s.g. PMI-Dienste (Performance Monitoring Infrastructure), die Daten
zur Laufzeit und zu Anwendungen zusammenstellen. Diese Dienste sammeln
Leistungsdaten von verschiedenen Systemelementen und erlauben die Einschätzung der
Performance einzelner Systemelemente in verschiedenen Systemarchitekturen.
2.2.2.2 Application Offload / eSSL
Unter Application Offload (offload = abladen, abstoßen) versteht man die gezielte
Auslagerung von Diensten auf separate Hardwareressourcen in einem
Netzwerkverbund. Die essentiellsten Dienste verbleiben bei diesem Konzept auf einer
Hauptmaschine und nutzen die Dienste anderer, verteilter Systeme. In diesem Kontext
spricht man daher auch von der s.g. Erweiterten Single Server Lösung (eSSL).
Dienste der ersten und letzten Schicht einer Multi-Tier-Architektur eignen sich durch
ihre Beschaffenheit eher für eine Ausgliederung als zusammenhängende
Geschäftsprozesse der Logigschicht. Für z.B. Webserver und Datenbankserver bestehen
vereinheitlichte und offene Schnittstellen, die eine sicherere und verlässliche
Kommunikation auch über Systemgrenzen hinweg sicherstellen.
2.2.2.3 Horizontales – und vertikales Clustering
Der Begriff Cluster (von engl. cluster – Schwarm, Gruppe, Haufen) beschreibt eine
Menge an vernetzten (auch virtuellen) Rechnersystemen, die in Ihrer Gesamtheit ein
einzelnes System darstellen. Es handelt sich dabei in der Regel um vollständige Kopien
eines Systems die im Verbund agieren. Ein „cluster-member“ oder „Knoten“ ist ein
Anwendungsserver in einem Cluster. Mehrere Cluster-Member mit derselben Aufgabe
bilden zusammen eine s.g. Zelle.
Gründe für das Erstellen von Cluster-Architekturen sind:
- Skalierbarkeit (Steigerung der Verarbeitungsleistung durch Hinzufügen
mehrerer Maschinen für eine größere Anzahl zu versorgender Clients)
Einführung Kollaborative Serverdienste
33
- Leistung / High Performance Computing (HPC) Cluster (Maximierung der
Leistung um Antwortzeiten für Transaktionen kurz zu halten)
- Durchsatz ( Erhöhung der Anzahl gleichzeitig ablaufender Transaktionen)
- Verfügbarkeit und Failover / Hochverfügbarkeitscluster (HA) (Vermeidung von
Single Points of Failure durch Redundanz)
- Wartungsfreundlichkeit (Möglichkeit Maschinen vom Netz zu nehmen, ohne
den Betrieb des Gesamtsystems zu gefährden)
Generell wird zwischen den Architekturen „shared nothing“ und „shared all“
unterschieden.
Typischer Vertreter eines Clusters mit „shared nothing“ Architektur ist DB2 mit EEE
Erweiterung. Hier beherbergt jeder Clusterknoten eine eigene Datenpartition. Ein
Performancegewinn wird durch die Partitionierung der Daten und die damit
einhergehende verteilte Verarbeitung erzielt. Ausfallsicherheit wird hiermit nicht
gewährleistet.
Anders ist dies beim „shared all"-Cluster; diese Architektur gewährleistet durch einen
konkurrierenden Zugriff auf „Shared Storage“, dass alle Clusterknoten auf den
gesamten Datenbestand zugreifen können. Neben Skalierung und
Performancesteigerung wird durch diese Architektur eine zusätzliche Ausfallsicherheit
erreicht. Fällt ein Knoten aus, übernehmen die anderen Knoten seine Aufgaben. Ein
typischer Vertreter der shared all-Architektur ist der Oracle Real Application Cluster
(RAC).
Horizontales Clustering
Ein horizontales Clustering (horizontale Skalierung / hCluster) liegt vor, wenn
Mitglieder eines Clusters auf mehrere physische Maschinen verteilt werden.61 Hierbei
werden alle kausalen Ansätze von 2.2.2.3 erfüllt. Die Wartungsfreundlichkeit wird
durch die Möglichkeit des offline-Betriebes erhöht, durch die multiplen (Hardware-)
Systeme und den damit verbundenen Mehraufwand der Hardwarepflege wieder
verringert.
61 Vgl. Abbildung 2-7 Horizontale Cluster Achritektur
Einführung Kollaborative Serverdienste
34
Abbildung 2-7 Horizontale Cluster Architektur
Vertikales Clustering
Beim vertikalen Clustering (vCluster) wird die Instanz einer Anwendung oder eines
Anwendungsservers (Cluster Member) auf einer physischen Maschine, teilweise durch
Virtualisierungstechniken, mehrfach konfiguriert und betrieben. 62
Abbildung 2-8 Vertikale Cluster Architektur
Das vertikale Clustering erfüllt, ohne eine Kombination mit dem horizontalen
Clustering, nicht alle kausalen Grundsätze aus Abschnitt 2.2.2.3.63 Es bietet jedoch bei
62 Vgl. Abbildung 2-7 Horizontale Cluster Architektur
63 Vgl. Roehm et al. (2004) S. 144 ff.
Einführung Kollaborative Serverdienste
35
kollaborativen JVM-Prozessen, die z.B. durch die Restriktionen beim gemeinsamen
Zugriff nur seriell abgearbeitet werden können, eine größere Effizienz 64 bei der
Ausnutzung der Verarbeitungsleistung einer einzelnen Maschine.
Architekturen mit vertikaler Skalierung auf nur einer Maschine ermöglichen ein
Failover bei Prozessen, stellen jedoch durch die (alleinige) Host-Maschine einen
zusätzlicher Single Point of Failure dar.
In der Praxis vereint oft eine kombinierte Architektur aus vCluster und hCluster die
Vorteile beider Konzepte.
2.2.2.4 Multi Node Architektur / Multi Tier Architektur
Die Grenze zwischen einer eSSL- und Multi Node Architektur ist nicht klar definiert
und in vielen Systemen fließend. Eine Multi Node Architektur zeichnet sich schlicht
durch das Vorhandensein mehrerer Nodes (virtuelle und reale Maschinen) aus und
macht keine Vorgaben bezüglich eventueller Cluster-Technologien. Somit wäre ein
Application Offload einer (kleinen) Multi Node Architektur zuzuordnen.
Im Kontext dieser Arbeit definieren wir, zwecks klarer Abgrenzung, eine Multi Node
Architektur durch das Vorhandensein von mindestens zwei oder mehr physikalischen
(hCluster) 65 oder virtuellen (vCluster) (Applikations-) Servern.
64 Vgl. Ebel (2005) S. 406 ff.
65 Vgl. Abbildung 2-9: Beispiel Multi Node Architektur IBM WebSphere Cluster
Einführung Kollaborative Serverdienste
36
Abbildung 2-9 Beispiel Multi Node Architektur IBM WebSphere Cluster66
Eine Multi Tier Architektur hingegen wird in der Literatur bewußt ohne zwingende
Cluster-Technologien beschrieben und grenzt sich dadurch von der Multi Node
Architektur ab, womit die erweiterte Single Server Lösung zu den Multi Tier
Architekturen gehört.
In der Praxis werden, durch die Vermischung und Kombination beider Konzepte, die
Grenzen aufgeweicht, was oft zu einer synonymen Verwendung beider Begriffe führt.
Produktive kollaborative Systeme arbeiten überwiegend sowohl mit einer Multi Node-
als auch der Multi Tier Architektur. Die Abbildung 2-9 zeigt eine solche Kombination
(Database- und LDAP-Server sind Teil einer Multi Tier- und die zwei Workplace Nodes
Teil der Multi Node Architektur).
66 Aus: Roehm et al. (2004)
Einführung Kollaborative Serverdienste
37
2.2.2.5 Network Deployment
Der Begriff Network Deployment wurde im Zusammenhang mit der Einführung des
IBM Application Servers bekannt, beschreibt jedoch ein allgemein gültiges Prinzip der
(teilweise automatischen) Verteilung und Steuerung von Diensten innerhalb einer Multi
Node Architektur (nicht Multi Tier), zur zentralen Verwaltungsübersicht (Deployment
Manager)67 und Lastverteilung über alle Knoten. Ein Network Deployment bietet
meist die Möglichkeit der Kombination von horizontalen- und vertikalen
Clustertechnologien. 68 Eine Installation von Network Deployment kann ein Netz von
Hardwaresystemen unterstützen, die für die Ausführung von miteinander arbeitenden
Instanzen einer Single Server Installation (SSI) konfiguriert sind. 69 Jeder Computer mit
einer Single Server Installation wird als Knoten bezeichnet (node). Im Network
Deployment besitzt jeder Knoten einen s.g. Node-Agent, der als Vermittler zwischen
den Anwendungsservern auf dem Knoten und dem Deployment Manager agiert, der die
gesamte Struktur (Zelle) überwacht.
67 Vgl. Abbildung 2-9: Beispiel Multi Node Architektur IBM WebSphere Cluster
68 Vgl. Monson et al. (2005) S. 169 ff.
69 Vgl. Abbildung 2-10 Network Deployment
Abbildung 2-10 Network Deployment
Konzeption einer J2EE Systemarchitektur
38
3 Konzeption einer J2EE Systemarchitektur
Eine Konzeption (aus dem Lateinischen concipere: auffassen, erfassen, begreifen,
empfangen, sich vorstellen) ist eine Zusammenstellung von Information und
Begründungszusammenhängen für ein Vorhaben oder „umfangreiche Planungen“.70
Auftrag
Ziel dieser Arbeit ist, neben der prototypischen Evaluation, die Konzeption einer
Systemarchitektur die definierte Anforderungen erfüllt und auf zukünftige Kontexte
übertragen werden kann.
Planungshorizont
Das hier entwickelte Konzept einer Systemarchitektur soll maßgeblich der Evaluierung
und Nutzung durch Studierende dienen und ist somit in seiner Laufzeit auf das Jahr
2006 beschränkt.
Quellen
Die Analyse der möglichen Systemarchitekturen basiert auf den Grundlagen aus Kapitel
1 dieser Arbeit, der Seminararbeit „Konzeption eines Best Practice Guide zur
Administration einer IBM Workplace Infrastruktur“71, der im Literaturverzeichnis
genannten Quellen und der Erfahrung im täglichen Umgang mit der Referenzumgebung
IBM Workplace Collaboration Services 2.6.
70 Vgl. Brockhaus Enzyklopädie 20. Auflage
71 Vgl. Altemeier (2005): Konzeption eines Best Practice Guide zur Administration einer IBM Workplace
Infrastruktur
Konzeption einer J2EE Systemarchitektur
39
3.1 Zieldefinition der zu entwerfenden Systemarchitektur
Heute verfügbare Software, zur Lösung kollaborativer Konzepte, lassen sich nach
verschiedenen Anforderungen durch entsprechende Systemarchitekturen
implementieren. In diesem Kapitel steht die Auswahl aus verschiedenen
Lösungsansätzen im zentralen Mittelpunkt.
Ausgangsituation
Alle verfügbaren kollaborativen Systeme folgen demselben kausalen Grundsatz und
sind in ihren möglichen Systemarchitekturen vergleichbar. Daher ist ein möglichst
allgemeingültiger Lösungsansatz gefragt, der sich auf verschiedene Systeme übertragen
lässt.
Das zu erarbeitende Konzept soll definierten Anforderungen genügen, die im Folgenden
kategorisiert definiert werden. Die Auswahl möglicher Konzepte wird durch die
vorhandenen Ressourcen, wie Hardware und Budget, begrenzt.
3.1.1 Rahmenbedingungen und Budget
Universität Paderborn
Die Universität stellt für diese Arbeit einen Server auf Athlon-Basis (Single CPU) mit
4 GB Arbeitsspeicher zur Verfügung. Weitere Server für mögliche Clustervarianten
sind nicht vorgesehen. Das verfügbare Budget beschränkt sich auf die vorhandenen
Hardwareressourcen.
Die Integration von vorhandenen Ressourcen der Universität Paderborn, im Speziellen
des Groupware Competence Center (GCC), ist nicht möglich, da ein Zugriff aus
Datenschutzgründen nicht realisierbar ist.
VegaSystems Paderborn
Die Firma VegaSystems stellt einen IBM eServer x345 auf Dual-Xeon Basis mit 4 GB
Arbeitsspeicher und Hardware-Raid 1 System, sowie einen IBM Netfinity Server mit
2,8 GHz Prozessor, 4 GB RAM und Hardware-Raid 1 System zur Verfügung.
Zusätzlich wird das Hosting der erforderlichen Systeme übernommen. Ein weiteres
monetäres Budget zur Anschaffung weiterer Hardware wird nicht gestellt.
Zur Integration und Auslagerung von Diensten (Application Offload) stehen LDAP-
kompatible Verzeichnisse und Datenbanksysteme verschiedener Hersteller zur
Konzeption einer J2EE Systemarchitektur
40
Verfügung. Ein temporäres Schreibrecht kann gewährt werden, kundenspezifische
Daten gelten als sensitiv und sind daher auszuschließen.
Die Nutzung von vorhandener Software ist im Rahmen der Lizenzrechte der Hersteller
möglich.
3.1.2 Anforderungen an die Systemarchitektur
Die zu entwickelnde Systemarchitektur soll im Rahmen des CCW Kolloquiums
definierten Kriterien gerecht werden und anderen Benutzern die Arbeit mit dem System
erlauben.
Stabilität und Verfügbarkeit für Produktivbetrieb
Studenten und Mitarbeiter der Universität Paderborn bzw. des Groupware Competence
Centers sollen die kollaborative Systemarchitektur als Gesamtsystem zu Forschungs-
und Evaluierungszwecken nutzen können. Hierbei stehen die Anwendungsentwicklung,
Software-Evaluierung und Präsentation des Gesamtsystems im Vordergrund. Da
andere wissenschaftliche Arbeiten diese Systemarchitektur als Ausgangssystem nutzen
sollen, ist eine hohe Verfügbarkeit und Stabilität erforderlich. Das System soll 24
Stunden / 7 Tage die Woche zur Verfügung stehen.
Performance bei entsprechender Benutzerzahl
Eine weitere Anforderung ist die s.g. Performance. Der Begriff wird unterschiedlich
genutzt und beschreibt sowohl die Geschwindigkeit mit der ein oder mehrere Aufträge
von einem System verarbeitet werden als auch die vom User „spürbare“ Antwortzeit auf
Interaktionen mit dem System. Bei beiden Ansätzen werden jedoch ähnliche
Meßgrößen verwendet:72
- Durchsatz: Zahl der pro Zeiteinheit bearbeiteten Aufträge
- Antwortzeit: Zeit, die ein Auftrag vom Zeitpunkt des Eintreffens bis zum
Ausgang nach erfolgter Bearbeitung im Datenverarbeitungssystem verbringt
- Verfügbarkeit73: Wahrscheinlichkeit, eine Anlage zu einem gegebenen Zeit-
punkt in einem funktionsfähigen Zustand anzutreffen.
72 Vgl. Claus (1993) S. 371 f.
73 Vgl. Kapitel 3.1.2 Abschnitt „Stabilität und Verfügbarkeit“
Konzeption einer J2EE Systemarchitektur
41
Zum Vergleich der Leistung unterschiedlicher Systemarchitekturen werden s.g.
Bewertungsprogramme (Performance Monitoring Infrastructures)74 genutzt, die eine
objektivierte Messung obiger Größen ermöglichen.75 Im Rahmen dieser Arbeit werden
Performance-Messungen nur stichprobenartig zur Validierung der Herstellerangaben76
durchgeführt und beschränken sich im Umfang auf die implementierten
Systemarchitekturen.
Im konkreten Umfeld soll die Systemarchitektur mind. 25 Usern eine performante
Arbeitsumgebung bieten und den gleichzeitigen Zugriff aller Benutzer ermöglichen. Zur
Realisierung sollen die, von den Herstellern genannten, Bedingungen für die jeweilige
Nutzeranzahl verwendet werden. Eine eigene, detaillierte Performance-Messung in
Relation zu der Useranzahl ist im Rahmen dieser Arbeit weder möglich noch gefordert.
Die Bewertungen innerhalb der nächsten Kapitel basieren darüber hinaus auf den
eigenen Erfahrungen im Umgang mit J2EE-basierten Systemarchitekturen.77
Ausfallsicherheit
Der Begriff der „Ausfallsicherheit“ beschränkt sich im Gegensatz zur „Verfügbarkeit“
auf die grundsätzliche Sicherstellung der Dienstbereitschaft ohne Berücksichtigung der
Performance. Neben der Verfügbarkeit soll die Systemarchitektur möglichst
ausfallsicher konzipiert werden, jedoch nur im Rahmen der allgemeinen Bedingungen
und des zur Verfügung stehenden Budgets.
Datensicherung und –wiederherstellung
J2EE-basierte Systemarchitekturen erschweren durch ihren komplexen Aufbau und dem
Prinzip der Addition78 oft die effiziente und vollständige Datensicherung. Die zu
entwerfende Systemarchitektur soll Möglichkeiten zur Datensicherung (backup) und zur
Wiederherstellung (restore) schaffen.
74 Vgl. Kapitel 2.2.2.1 Single Node Architektur / Single Tier Architektur
75 Siehe hierzu: Kuppinger (2003) S. 795 ff.
76 Angaben der Softwarehersteller zu den jeweiligen J2EE basierten Systemarchitekturen für
kollaborative Anwendungen.
77 Vgl. Altemeier, Tobias (2005): Konzeption eines Best Practice Guide zur Administration einer IBM
Workplace Infrastruktur
78 Vgl. Kapitel 2.2: Grundsätzliche Merkmale von kollaborativen Serverdiensten
Konzeption einer J2EE Systemarchitektur
42
Integrationsfähigkeit
Die Systemarchitektur soll unter besonderer Berücksichtigung der Integrationsfähigkeit
entworfen werden. Vorhandene Dienste, Anwendungen und Ressourcen müssen in das
Gesamtkonzept eingegliedert sowie mitbenutzt werden können. Ziel ist der Entwurf
einer skalierbaren Architektur unter Beachtung der vorhandenen Hard- und
Softwareressourcen und der (zu integrierenden) Infrastruktur.
Administrierbarkeit
Gesucht ist eine Systemarchitektur, die ohne große Einarbeitungszeit von Studenten und
wissenschaftlichen Mitarbeitern des Groupware Competence Centers der Universität
Paderborn verwaltet werden kann. Hierbei kann von fundierten Kenntnissen der
Microsoft Windows Betriebssysteme, der IBM Lotus Domino Architektur und
Grundkenntnissen weiterer IBM Produkte wie z.B. DB2 und WebSphere ausgegangen
werden. Linux- Kenntnisse sind nur begrenzt vorhanden. Alle Beteiligten sind mit der
Programmiersprache Java vertraut.
3.2 Diskussion möglicher Systemarchitekturen
Wie in Kapitel 2.2.2 „System-Architekturmerkmale und deren Bedeutung für
kollaborative Dienste“ beschrieben, bieten sich anforderungsorientiert verschiedene
Systemarchitekturen zur Umsetzung an. Die in der Realität vorkommenden Architekur-
Implementierungen stellen in der Regel eine Kombination aus möglichen Konzepten
dar und versuchen die Vorteile der einzelnen Lösungen sinnvoll zu kombinieren. So
kann jede Systemarchitektur, z.B. durch horizontales Clustern zur Verbesserung von
z.B. Performance und Ausfallsicherheit, erweitert werden.79 Daraus resultiert eine
Vielzahl an Lösungsmöglichkeiten, die durch die gegebenen Anforderungen und
Rahmenbedingungen begrenzt werden. Ziel dieses Kapitels ist Eruierung und
Bewertung möglicher Basiskonzepte. Eine generelle, von den Rahmenbedingungen
unabhängige Bewertung, erfolgt hier nicht und ist in diesem Kontext auch nicht
sinnvoll.80
79 Vgl. Kapitel 2.2.2.3 Horizontales – und vertikales Clustering
80 Für die allgemeine Bewertung siehe Altemeier (2005)
Konzeption einer J2EE Systemarchitektur
43
3.2.1 Single Server Installation Die Single Server Installation (SSI) ist die am wenigsten
komplexe Systemarchitektur. Grundsätzlich ist es möglich, alle
benötigten Dienste und Anwendungen auf einer einzelnen
Hardwaremaschine zu installieren und zu betreiben. Hierbei
teilen sich einzelne Applikationen die vorhandenen
Systemressourcen und müssen gegenseitig auf die Freigabe
warten. Die Mindesthardwareanforderungen an ein Single-Server-
Konzept sind entsprechend hoch, die Leistung und Skalierbarkeit vergleichsweise
gering.
Bewertung der Stabilität , Verfügbarkeit und Ausfallsicherheit
Da sich die SSI auf ein Hardwaresystem stützt, ist die Verfügbarkeit und Stabilität
unmittelbar abhängig von der verwendeten Hardwareplattform und dem Betriebssystem.
Die Hardware bietet keinerlei echte Redundanz, Points-of-failure wie Prozessoren,
Speicher und Festplatten sind nur einfach vorhanden oder können im Fall eines
Defektes nicht automatisch entkoppelt oder ersetzt werden. Ein Hardwaredefekt führt in
der Regel immer zu einem Totalausfall der Architektur und damit des Gesamtsystems.
Bei der Wahl der Hardwarekomponenten sollte daher im Idealfall auf spezielle Server-
Hardware mit redundanter Auslegung der Kernkomponenten (Speicher, Prozessoren,
Netzteile, Festplatten) geachtet werden.
Unter den gegebenen Rahmenbedingungen ist eine Wahl geeigneter Hardware jedoch
nicht möglich, es muss auf die vorhandenen Systeme zurückgegriffen werden. Ein
Budget zur Anschaffung redundanter Komponenten oder neuer Systeme existiert nicht.
Die Stabilität, Verfügbarkeit und Ausfallsicherheit ist somit maßgeblich abhängig von
den zur Verfügung stehenden Hardwaresystemen. Da nur die Systeme der Firma
VegaSystems über redundante Komponenten verfügen, ist eine reine SSI nur auf diesen
Systemen zu empfehlen.
Performance
Die Performance des Systems ist abhängig von der verwendeten Serverhardware, dem
Betriebssystem und der verwendeten Dienstsoftware (J2EE-basiertes kollaboratives
System). Die SSI basiert nur auf einer Serverhardware, so dass die Leistungsfähigkeit
dieser, gegenüber Multi-Tier Konzepten, eingeschränkt ist.
Abbildung 3-1 SSI
Konzeption einer J2EE Systemarchitektur
44
Die zur Verfügung stehenden Serversysteme können in ihrer Leistung als Mid-Range-
Systeme81 eingestuft werden und erfüllen damit die Mindestvoraussetzung für SSI -
J2EE-basierte Systeme mit maximal 20 gleichzeitigen Benutzern.82 Das verfügbare
Dual-Xeon System erreicht als einzige Hardwaremaschine die geforderte Grenze von
mind. 25 Usern. Durch selektives Abschalten einiger Dienste könnte die Performance
der anderen Systeme erhöht werden, welches jedoch der Anforderung der vollständigen
Abbildung aller Leistungspotentiale zu Präsentationszwecken widerspricht. Somit kann
die SSI den Anforderungen bezüglich der Performance, bei den vorhandenen
Rahmenbedingungen, nicht gerecht werden.
Datensicherung und – wiederherstellung
Durch die Integration aller Systemelemente auf einer Hardwaremaschine - und damit
auch auf einem Betriebssystem - ist die Datensicherung, im Vergleich zu anderen
Systemarchitekturen, einfach zu realisieren. Es bedarf hierbei oft nur einer
Datensicherungssoftware die, mit entsprechenden s.g. Plugins oder Agents
(Schnittstellen zu den einzelnen Systemelementen), alle vorhandenen Daten
(Verzeichnisse, Datenbanken, File-Partitionen etc.) ohne Überschreitungen von
Systemgrenzen sichern kann. Portierungen für verschiedene Betriebssysteme sind nicht
notwendig, Remoute-Agents für die Sicherung entfernter Daten überflüssig. Die
Datensicherung ist in ihrer Integrität jedoch von der vorhandenen (einfachen83)
Hardware abhängig.
Die im Rahmen dieser Arbeit zur Verfügung stehenden Systeme besitzen keine
Bandlaufwerke oder optischen Laufwerke zur Sicherung. Es ist daher nur eine
Sicherung auf File-Ebene (Festplatte) über s.g. Dump-Images (Momentaufnahmen des
Systems zu einem Zeitpunkt X) möglich. Bei einem Festplattendefekt wäre die
Datensicherheit somit nicht gewährleistet. Eine partielle Wiederherstellung ist wegen
der Art der Sicherungsmechanismen ebenfalls nicht möglich.
81 Vgl. IBM (2005) S. 5 ff.
82 Monson et al. (2005) S. 30 ff.
83 Hier: Anzahl (1)
Konzeption einer J2EE Systemarchitektur
45
Bewertung der Integrationsfähigkeit
Die Single Server Installation sieht in ihrer reinen Form weder die Möglichkeit des
Application-Offload vor noch die Einbindung von vorhandenen Diensten. Alle
benötigten Systemelemente befinden sich auf derselben Hardwaremaschine und
benötigen keine externen Dienstanbieter. Die Integrationsfähigkeiten der SSI sind somit
stark begrenzt, es wird häufig nur der einmalige Import von Stammdaten ermöglicht wie
z.B. der Userdaten. In der Regel lässt sich die reine SSI jedoch zu der erweiterten
Single Server Lösung ausbauen.84
Es wird jedoch explizit eine mögliche Integration in bestehende Systemkonzepte
gefordert, daher ist die reine SSI für diesen Kontext nicht Anforderungskonform.
Bewertung der Administrierbarkeit
Für alle J2EE-basierenden kollaborativen Systemarchitekturen sind fundierte
Kenntnisse der einzelnen Systemelemente, der verwendeten Betriebssysteme und der
Programmiersprache Java erforderlich.85 Da die Single Server Installation
architekturbedingt nur eine Hardwareplattform benötigt, beschränkt sich der
Verwaltungsaufwand auf diese und das verwendete Betriebssystem. Geht man von
einem erhöhten Administrationsaufwand bei verteilten Systemen, und dadurch
verteilten Systemelementen, aus, bietet die reine SSI den geringsten Zeitaufwand für die
Einarbeitung, Installation und Wartung. 86 87
84 Vgl. Kapitel 2.2.2.2 Application Offload / eSSL
85 Vgl. IBM (2005) Kapitel 1
86 Siehe auch: Monson (2005 b) Kapitel 1 und Kapitel 2 S. 30 ff.
87 Vgl. Altemeier (2005): Konzeption eines Best Practice Guide zur Administration einer IBM Workplace
Infrastruktur
Konzeption einer J2EE Systemarchitektur
46
3.2.2 Application Offload Das Application Offload (AO) stellt, wie in
Kapitel 2.2.2.2 erläutert, eine Erweiterung der
SSI dar und wird daher auch architektonisch als
eSSL Variante bezeichnet. Dieses Konzept erfüllt
erstmals, durch die mögliche Einbindung
vorhandener Dienste, die Anforderung der
Integrations-fähigkeit. Architekturen mit Application Offload sind grundsätzlich Multi
Tier Architekturen.
Bewertung der Stabilität , Verfügbarkeit und Ausfallsicherheit
Das Konzept der Auslagerung von Diensten baut weiterhin auf einer einzelnen
Hardwaremaschine, als zentrale Verwaltungseinheit, auf. Sicherheitsrelevante-,
speicher- und prozessorintensive Prozesse können jedoch auf externe Server
ausgegliedert (A -> B) oder von vorhandenen Dienstanbietern bezogen (B -> A)
werden. Bezüglich der Ausfallsicherheit gilt weiterhin das Prinzip des Single-Point-of-
Failure, fällt eine der genannten Komponenten aus, gilt das Gesamtsystem als
gefährdet. Je größer die Anzahl der verwendeten Hardwarekomponenten ist desto
größer ist auch die Wahrscheinlichkeit eines Defektes. Da das reine AO keine
Redundanzen (Cluster-Technologien) vorsieht, existieren keine Mechanismen zum
automatisierten Failover. Die Verfügbarkeit des Gesamtsystems ist somit stark abhängig
von den einzelnen (ausgegliederten) Diensten. Ohne Betrachtung der Performance ist
das AO in einer eSSL Architektur bezüglich Stabilität, Verfügbarkeit und
Ausfallsicherheit, ohne Kombination mit Cluster-Technologien, nur bedingt
empfehlenswert und führt eher zu einer Verringerung der Verfügbarkeit.88
Performance
Da Java-Code von einer Runtime-Umgebung interpretiert und nicht wie native,
betriebssystemnahe Applikationen ausgeführt wird, gelten J2EE Anwendungen als
vergleichsweise „speicherhungrig“ und prozessorbelastend.89
88 Vgl. Monson et al. (2005 b) S. 215 ff.
89 Vgl. Ebel (2005) S. 353 - 359
Abbildung 3-2 Application Offload
Konzeption einer J2EE Systemarchitektur
47
Durch die Auslagerung von Diensten verbleiben dem Kernsystem mehr
Systemressourcen zur Verarbeitung der eigenen Aufgaben (tasks), was zu einer s.g.
Lastverteilung über alle Systeme führt. Das AO von Datenbank- und Webserverdiensten
ist im Bezug auf die Performancesteigerung anderen Diensten vorzuziehen, da diese ein
Hardwaresystem am relevantesten belasten.90
In einer eSSL Architektur bietet das AO somit ein Konzept zur Performancesteigerung
durch Verteilung der Aufgaben auf verschiedene Hardwaresysteme. Voraussetzung
hierfür ist jedoch eine qualitativ hochwertige (geringe Latenzzeiten) und schnelle (100
MBit oder schneller) Vernetzung zwischen den einzelnen Hardwaresystemen (tier) der
eSSL Architektur, da die Kommunikation zwischen den Einheiten über die
Netzwerkschnittstelle geführt wird.
Konkret stehen in der Summe 3 Hardwaresysteme zur Verfügung, die zur Nutzung des
AO und die dadurch resultierende Performancesteigerung genutzt werden könnten.
Durch die räumliche Trennung der Systeme (VegaSystems und Universität Paderborn)
ist eine Vernetzung in der geforderten Qualität (Geschwindigkeit und Latenz) nicht
möglich. Eine Steigerung der Performance des Gesamtsystems wäre daher nur durch die
Einbindung schon vorhandener Systeme und Systemelemente (VegaSystems)
erreichbar.
Datensicherung und – wiederherstellung
Die Datensicherung wird mit der größeren Anzahl an verwendeten Hardwaremaschinen
zunehmend komplexer. Durch den Einsatz von verschiedenen Betriebssystemen (z.B.
Microsoft Windows Verzeichnisdienste, AIX für Datenbankserver und Linux für
Webserver) wird eine Portierung der Datensicherungssoftware notwendig und eine
sichere Verbindung zwischen den verteilten Systemen und der
Datensicherungskomponente erforderlich. Sind Dienste im Netzwerk bereits vorhanden,
können diese weiterhin wie gewohnt gesichert werden, der zentrale J2EE-basierte
Applikationsserver wird hinzukommend, als SSI betrachtet, gesichert.
Bewertung der Integrationsfähigkeit
Wie eingangs beschrieben ermöglicht das AO in einer eSSL Architektur erstmals die
Integration in bestehende Systemkontexte durch Einbindung von vorhandenen
90 Vgl. Roehm et al. (2004) Kapitel 7
Konzeption einer J2EE Systemarchitektur
48
Dienstanbietern bzw. kompatiblen Systemelementen. Das J2EE-basierte kollaborative
System wird nicht mehr eigenständig und losgelöst betrieben sondern fügt sich in die
Infrastruktur ein und kann vorhandene Datenbestände mitbenutzen.
Somit wird die eSSL Architektur den gestellten Anforderungen bezüglich der
Integrationsfähigkeit gerecht und ist durch die Möglichkeit der Mitbenutzung von
vorhandenen Systemelementen der Firma VegaSystems realisierbar.
Bewertung der Administrierbarkeit
Mit jedem zusätzlich verwendeten Tier (Hardwaresystem) steigt der Aufwand für die
Wartung der Hardware und die verschiedenen Betriebssysteme. Geht man beim
Application Offload von einer vollständigen Integration bestehender Dienste aus,
erschwert sich die Administration nur unwesentlich durch die Pflege der Schnittstellen
zwischen den Systemelementen. Wird eine AO-Architektur zur Performancesteigerung
geplant, ohne vorhandene Dienstanbieter, muss die gesonderte Administration aller
verwendeten Produkte berücksichtigt werden. Bei der SSI sind viele Systemelemente
fest integriert und bedürfen keiner besonderen Verwaltung und Pflege. Bei dem AO
hingegen müssen alle ausgelagerten Teile separat konfiguriert und überwacht werden.
3.2.3 Network Deployment
Das Network Deployment (ND) definiert sich über das mehrfache Vorhandensein des
Applikationsservers91 und die (einfache92) zentrale Steuerungseinheit, dem Deployment
Manager. Es sind somit mindestens drei Hardwaresysteme (Deployment Manager,
Node A, Node B) zur Realisierung erforderlich. Das Application Offload ist separat
realisierbar und gilt pro Zelle.93
Bewertung der Stabilität , Verfügbarkeit und Ausfallsicherheit
Das ND ist eine Erweiterung der SSI oder eSSL Architektur und eliminiert den
zentralen Applikationsserver als Single-Point-of-Failure durch eine clusterähnliche
Vervielfachung (mind. 2) des Haupt-Nodes.94
91 Vgl. Kapitel 2.2.2.5 Network Deployment und Abbildung 2-10.
92 Hier: Anzahl (1)
93 Vgl. Abbildung 2-10 Network Deployment
94 Vgl. Ebel (2005) S. 381 - 382
Konzeption einer J2EE Systemarchitektur
49
Der Deployment Manager ist in der Regel nur einfach vorhanden, wodurch die
Ausfallsicherheit und Verfügbarkeit von diesem abhängt, da ein Failover zwischen den
einzelnen Knoten zentral gesteuert wird. Global gesehen wird die Verfügbarkeit durch
das Erhöhen der Knotenanzahl linear gesteigert95, die Kosten und der Aufwand für
Verwaltung und Pflege gleichermaßen. Je nach Hardwareausstattung und
Softwareprodukt lassen sich im Durchschnitt 25 gleichzeitige User pro Knoten bei einer
eSSL & Network Deployment Kombination bedienen.96 Dieser Wert ist stark abhängig
von dem eingesetzten Softwareprodukt, den verwendeten Systemkomponenten und
Systemelementen, so dass dieser als Richtwert anzusehen ist.
Für die gestellten Anforderungen und Rahmenbedingungen erscheint das ND zur
Steigerung der Verfügbarkeit und Ausfallsicherheit sinnvoll, erschwert jedoch durch
den komplexen Aufbau die Administrierbarkeit und bedarf eines erhöhten
Wartungsaufwandes. Da in diesem Fall nur die Sicherstellung der Versorgung von
maximal 25 Usern gefordert ist, steht der hohe Aufwand einer ND – Implementierung
der geringen Verfügbarkeitsverbesserung entgegen.
Performance
Es handelt sich beim Network Deployment um keine echte Clustertechnologie. Der
Deployment Manager verteilt und steuert einzelne Aufgaben auf den jeweiligen
Systemen kann Tasks jedoch nicht systemübergreifend abarbeiten lassen. Die
Performance steigt mit jedem weiteren Knoten (node) allerdings nicht mit dem
effizienten Faktor eines echten horizontalen Clusters. Im Mittelpunkt steht eher eine
Maximierung der User-Anzahl als die schnellere Abarbeitung einer Aufgabe in einem
gegebenen Zeitraum X.
Eine hohe Performance für mehr als 25 User ist nach der Aufgabenstellung kein
Kriterium für den Entwurf der hier benötigten Systemarchitektur. Daher ist der Einsatz
des ND aus Performancegründen unnötig.
Datensicherung und – wiederherstellung
Das Network Deployment sieht mindestens 2 Knoten vor, die ohne Application Offload
zu jedem Zeitpunkt X den fast gleichen Datenbestand aufweisen. Ausgenommen
95 Vgl. Ebel (2005) S. 404
96 Vgl. Roehm et al. (2004) S. 5-9
Konzeption einer J2EE Systemarchitektur
50
hiervon sind Logdateien und die Status zu den jeweils aktuell laufenden Prozessen. Da
diese Daten für eine Wiederherstellung des Systems unerheblich sind, ist die Sicherung
eines Knotens ausreichend. Bei einem Spontanausfall97 können aktuell laufende
Transaktionen allerdings oft weder revidiert noch, nach Wiederaufnahme des Betriebes,
abgeschlossen werden. Wird diese Tatsache bei der Datensicherungsstrategie
berücksichtigt, ist die Sicherung einer ND – Architektur vergleichbar mit der einer
erweiterten Single Server Lösung, da der Deployment Manager als separat zu sichernde
Instanz anzusehen ist.
Bewertung der Integrationsfähigkeit
Die Integrationsfähigkeit des ND hängt von der Erweiterung um das AO ab. Das
Network Deployment macht in der eigentlichen Form keine Aussagen über die
Einbindung von vorhandenen Diensten oder separate Auslagerung dieser. Genauer stellt
es eine Erweiterung der einfachen Single Server – und erweiterten Single Server Lösung
dar. Die Integrationsfähigkeiten beruhen somit nicht auf der Architektur des ND an sich
sondern auf dem Konzept des Applikation Offload.
Da der aktuelle Rahmen nicht genügend Hardwareressourcen und
Netzwerkperformance für ND und AO bietet, wäre eine Realisation nur unter Wegfall
sämtlicher Integrationsfähigkeiten möglich.
Bewertung der Administrierbarkeit
Werden die einzelnen Elemente eines Network Deployments betrachtet, zeigen sich
separate Administrationsaufwände für a) den Deployment Manager b) alle Nodes und c)
den verteilten Diensten durch das Application Offload. Es ergibt sich somit, im
Vergleich zu der Single Server Installation, ein Mehraufwand für den Deployment
Manger und jeden einzelnen Knoten. Die verteilten Applikationsserver werden zentral
gesteuert und bedürfen daher, ohne Berücksichtigung der Betriebssysteme, keiner
besonderen Beachtung. Die Erfahrung mit verteilten Systemen hat jedoch gezeigt, dass
der Zeitbedarf für die Verwaltung linear mit der Anzahl der Knoten steigt. Die
Bewertung des Application Offload bleibt an dieser Stelle mit dem Verweis auf Kapitel
3.2.2 aus.
97 Unvorhersehbarer Ausfall während laufender Transaktionen
Konzeption einer J2EE Systemarchitektur
51
3.2.4 Horizontales und vertikales Clustering
Das Network Deployment wird von einigen Softwareherstellern auch als
Clustertechnologie bezeichnet (z.B. IBM WebSphere Cluster) und beschreibt die erste
Stufe des horizontalen Clustering allerdings ohne die Möglichkeit der Verteilung einer
(ein und derselben) Aufgabe auf mehrere Knoten zur Lastverteilung von
rechenintensiven Prozessen und unterscheidet sich damit von dem allgemeinen
Verständnis eines Clusters (z.B. Linux-Cluster) nur minimal. Zur Vereinfachung und
zum besseren Verständnis wird im Folgenden das Network Deployment zu den Cluster-
Architekturen und -Technologien gezählt.
Bewertung der Stabilität , Verfügbarkeit und Ausfallsicherheit
Da sämtliche Cluster-Technologien zur Steigerung der Verfügbarkeit und
Ausfallsicherheit entwickelt worden sind, bieten diese die ideale Plattform für
Hochverfügbarkeits-Anwendungen.98 Für das horizontale Clustering (HC) sind
mindestens 2 Knoten notwendig, für das Vertikale (VC) reicht eine Hardwaremaschine
aus, somit erreicht nur das HC eine zusätzliche Ausfallsicherheit bei einem
Hardwaredefekt.
Durch die limitierte Anzahl an verfügbaren Hardwaremaschinen ist eine mögliche
Steigerung der Verfügbarkeit und Ausfallsicherheit durch Cluster-Technologien nicht
möglich.
Performance
Durch die mögliche parallele Verarbeitung von (Einzel-) Aufgaben steigt die
Arbeitsgeschwindigkeit des Gesamtsystems analog zu der Anzahl der verwendeten
Rechnersysteme abzüglich der Rechenleistung die zur Koordination der
Aufgabenverteilung und der Lastverteilung (Load-Balanceing) benötigt wird.99 Die
verschiedenen Anbieter von J2EE-basierten kollaborativen Diensten halten hierfür
individuelle Tabellen100 zur Anzahl benötigter Knoten bei einer definierten Anzahl von
Usern bereit, die eine performante Versorgung der Benutzer sicherstellen sollen. Der
Begriff „performante Versorgung“ wird allerdings in diesem Zusammenhang von
98 Vgl. Ebel (2005) S. 377 ff.
99 Vgl. Kuppinger (2003) S. 13
100 Vgl. IBM (2005 b) S. 6 ff.
Konzeption einer J2EE Systemarchitektur
52
keinem Softwarehersteller näher definiert und eher als subjektive Empfindung der
schnellen Reaktion auf Benutzereingaben beschrieben. Somit ist eine endgültige
Bewertung der Performance nur anhand der diskutierbaren Angaben der Hersteller
möglich.
Analog zum Network Deployment ist ein Clustering zur Steigerung der Performance bei
gegebenen 25 Usern nicht notwendig und erneut durch die Anzahl vorhandener Server
unrealisierbar.
Datensicherung und – wiederherstellung
Der Aufwand und die Komplexität der Datensicherung sind abhängig von der endgültig
verwendeten Cluster-Technologie und der Art der Datenspeicherung. Verfügen alle
Knoten zu jedem möglichen Zeitpunkt über dieselben (redundanten) Daten, ist die
Sicherung eines Knotens ausreichend. Wird ein Cluster in Verbindung mit dem
Application Offload betrieben, ist die Sicherung analog der eSSL Variante
vorzunehmen und vergleichbar komplex und aufwendig.
Da die Anforderungsdefinition lediglich die „Wiederherstellbarkeit“ des Systems
fordert, sind die Cluster-Technologien für diesen Kontext irrelevant.
Bewertung der Integrationsfähigkeit
Entsprechend zum Network Deployment ist die reine Cluster-Technologie, unerheblich
ob vertikal oder horizontal, unbedeutend für die Integrationsfähigkeit eines Systems in
bestehende Systemstrukturen.
Bewertung der Administrierbarkeit
Cluster, egal ob horizontale oder vertikale, sind grundsätzlich nur mit einem erhöhten
Aufwand zu administrieren.101 Erschwerend kommen notwendige Kenntnisse über
Clusterverfahren und deren Produkte hinzu. Einige Softwareanbieter vereinfachen das
Erstellen von neuen Cluster-Nodes durch automatisierte Vorgänge 102 bestätigen jedoch
den steigenden Zeitbedarf für die Systempflege in ihrer Produktliteratur. Architekturen
mit Clustertechnologien erkaufen sich den Vorteil an Performance und Ausfallsicherheit
durch einen überproportional steigenden Administrationsaufwand.
101 Vgl. IBM (2005 b) S. 37 ff.
102 Vgl. Roehm et al. (2004) S. 391
Konzeption einer J2EE Systemarchitektur
53
3.3 Entwurf einer Systemarchitektur aus konzeptioneller
Sicht
Ein Ziel dieser Arbeit ist der Entwurf einer geeigneten Systemarchitektur für
kollaborative Anwendungen.
Aus der erarbeiteten Architekturbewertung gilt es nun, die geeigneten Architekturen
und zugehörigen Elemente für eine kollaborative Systemarchitektur zu identifizieren
und zu beschreiben. Dabei wird der Top-Down-Ansatz verfolgt, bei dem zuerst der
grobe Architekturaufbau modelliert wird und dann bis zur Beschreibung der einzelnen
Systemelemente und deren Funktion verfeinert wird.
Die Konzeption betrachtet die möglichen Architekturen nach deren Konformität, d.h. es
wird untersucht, wie die Systemarchitektur aufgebaut sein muss, damit alle ersuchten
Anforderungen103 und gegebenen Rahmenbedingungen104 erfüllt werden. Eine
Betrachtung von Lösungswegen die Forderungen verletzten ist in diesem
Zusammenhang ungeeignet, da explizit nach einer Architektur gesucht wird, die real
umgesetzt werden soll. 105
Entscheidung
“Planning is crucial. The decisions you make when initially installing (…) Services
might be difficult, or impossible, to change after the system is in use.”106. Die
Entscheidung für oder gegen eine spezifische Systemarchitektur ist oft nur zu Beginn
der Installation eines J2EE-basierenden kollaborativen Systems möglich. Eine
nachträgliche Änderung ist in der Regel undurchführbar oder auf die reine Erweiterung
einzelner Systemelemente begrenzt.
Aufgrund der für diese Arbeit definierten Rahmenbedingungen ergibt sich nach der
Bewertung der einzelnen Systemarchitekturen nur die Auswahl aus der reinen Single
Server Installation und der erweiterten Single Server Installation (eSSL). Alle
103 Vgl. Kapitel 3.1.2
104 Vgl. Kapitel 3.1.1
105 Siehe auch: Lockemann (o.J.) S. 1
106 Vgl. IBM (2005 b) S. 1
Konzeption einer J2EE Systemarchitektur
54
Clustervariationen und das Network Deployment sind wegen mangelnder
Hardwareressourcen nicht implementierbar. Die Hardware der Universität Paderborn
und die der Firma VegaSystems gekoppelt als Cluster oder Network Deployment zu
nutzen ist durch die unperformante Vernetzung über öffentliche Internetrouten nicht
möglich. Das gewährte Budget sieht darüber hinaus keinerlei Neuanschaffungen vor.
Da explizit eine Versorgung von mindestens 25 Benutzern107 gefordert wird, ist die
reine SSI hierfür nicht ausreichend.108 Die IBM Workplace Collaboration Services 2.6
als Referenzumgebung betrachtet, erlauben in der reinen Single Server Installation laut
Literatur und eigener Evaluierung eine Versorgung von maximal 20 gleichzeitigen
Anfragen (Clients). Einziger Ausweg aus diesem Dilemma ist die hardwaretechnische
Aufrüstung: „Note that for a single-server (…) deployment, you need a minimum of 6
GB RAM and a quad processor server“. 109
Heute wird in der Fachpresse und Fachliteratur die Migration auf s.g. Unix-Kernel-
basierte Systeme zur Steigerung der Performance (…) diskutiert. In der Tat konnten
auch die vorliegenden Untersuchungen eine geringe Erhöhung der maximalen
Useranzahl auf Unix (Linux) basierenden Systemen im Vergleich zu der äquivalenten
Windowsinstallation aufzeigen. Eine Installation von J2EE basierten Diensten auf
einem Linuxsystem bietet somit nachweislich höhere Performance, ist wegen
mangelnden Linux-Kenntnissen der Zielgruppe für diese Konzeption jedoch
unerwünscht.
Somit ergibt sich für die hier gestellten Bedingungen die erweiterte Single Server
Installation (eSSL) auf Basis von Microsoft Windows als einzige mögliche
Systemarchitektur für J2EE-basierte kollaborative Serverdienste.
3.3.1 Modellierung einer eSSL Systemarchitektur
Der erste Schritt bei dem Entwurf einer Systemarchitektur umfasst zumeist auch eine
Anforderungsanalyse. Anforderungen und Rahmenbedingungen bieten dem
107 Vgl. Kapitel 3.1.2
108 Vgl. Altemeier (2005) S. 25
109 Vgl. Bai et al. (2004) S. 47 ff.
Konzeption einer J2EE Systemarchitektur
55
Entwicklungsteam eine erste aufgabennahe Vorstellung des Gesamtsystems und bilden
die Grundlage für eine gemeinsame zielorientierte Kommunikation.110 Durch die
festgesetzten Rahmenbedingungen und Anforderungen aus Kapitel 3.1.1 und 3.1.2 ist
eine besondere Analyse hier nicht notwendig.
Neben den Hardwarebegrenzungen werden an die zu entwickelnde Systemarchitektur
jedoch definierte Anforderungen gestellt. Ein besonders wichtiger Aspekt ist hierbei die
Integrationsfähigkeit, die sicherstellen soll, dass das zu entwickelnde Konzept auf
zukünftige Systemlandschaften übertragbar ist. Daher ist die Betrachtung der
vorhandenen Infrastruktur von essentieller Bedeutung, da sie maßgeblich für die
Effizienz111 der kollaborativen Systemarchitektur verantwortlich ist.
Das Groupware Competence Center (GCC) und die Firma VegaSystems betreiben
ähnliche Systemlandschaften die sich zwar hinsichtlich der Anzahl an Servern und der
verwendeten Software unterscheiden, jedoch bezüglich der Systemelemente (Hersteller
losgelöst) nahezu identisch sind. Somit kann die gesonderte und separate Betrachtung
einer vorhandenen Systemlandschaft ausbleiben, und eine gemeinsame, auf beide
Kontexte verallgemeinerte, Bestandsaufnahme erstellt werden.
3.3.1.1 Ist-Analyse der bestehenden Infrastruktur
Beide genannten Institutionen betreiben eine komplexe Systemlandschaft zur
Verteilung und Speicherung sowie Verarbeitung von Informationen, die sowohl über
die Webschnittstelle (http) als auch über proprietäre Protokolle (z.B. IBM Lotus Notes)
einer Vielzahl von Usern zur Verfügung gestellt werden. Die vorhandenen
Systemarchitekturen umfassen dabei alle in Kapitel 2.2.1 erläuterten Systemelemente
und sind daher direkt vergleichbar.
Das Konzept der erweiterten Single Server Lösung für kollaborative Systeme erlaubt in
der Regel (herstellerabhängig) die Einbindung bzw. Auslagerung von
- HTTP Server
- Verzeichnissdiensten
110 Vgl. Tabeling (2006) S. 414 f.
111 Claus (1993): „Effizienz (v. lat.: efficere „bewirken“) ist das Verhältnis eines in definierter Qualität
vorgegebenen Ziels zu dem Aufwand, der zur Erreichung dieses Ziels nötig ist.“
Konzeption einer J2EE Systemarchitektur
56
- Datenbank (Management) Servern.
Der Applikationsserver ist bei allen Herstellern (z.B. Sun, Microsoft, IBM) fester
Bestandteil des kollaborativen Systems und kann daher nicht ausgelagert und nur über
Cluster Technologien (Network Deployment) erweitert werden.
Systemelemente, die über standardisierte Schnittstellen verfügen (z.B. LDAP
kompatible Verzeichnisserver), können herstellerunabhängig eingesetzt werden, andere
Dienstanbieter wie z.B. ausgelagerte Webserver müssen in der Regel den
Spezifikationen des kollaborativen Systems entsprechen und zu diesem kompatibel
sein.112
Das GCC und die Firma VegaSystems verfügen über diverse Systemelemente, die sich
für die Einbindung in ein kollaboratives System eignen. Es sind verschiedene HTTP-
Service-Anbieter wie IBM Lotus Domino, Microsoft IIs, IBM HTTP Server (100%
kompatibel zum Apache Webserver) und IBM WebSphere Application Server
vorhanden, wie auch Verzeichnisdienste, die über das LDAP Protokoll gesteuert werden
können (Microsoft Active Directory, IBM Lotus Domino, FreeRADIUS). Als DBMS
sind IBM DB2, Informix, Microsoft SQL, Sybase und MySQL - Systeme vorhanden.
Es zeigt sich somit ein großes Potential an integrationsfähigen Elementen.
3.3.2 Identifikation, Spezifikation und Distribution der benötigten
Systemelemente
Die Identifikation der in Frage kommenden Systemelemente bezüglich ihrer realen
Produktausprägung hängt von der Bedeutung dieser in der realen Systemumgebung ab.
Die Frage, ob z.B. das Active Direktory einer Microsoft Domaine als Quelle aller
Userdaten oder das IBM Lotus Domino Directory (Name- and Adressbook NAB)
genutzt werden soll, hängt von der Zielgruppe des kollaborativen Systems ab und von
der Tatsache welches der genannten Verzeichnisse die relevanten Userdaten enthält.
Im Folgenden werden die einzelnen Systemelemente identifiziert und bezüglich Ihrer
Eignung klassifiziert.
112 Vgl. IBM (2005) S. 52 f.
Konzeption einer J2EE Systemarchitektur
57
3.3.2.1 Applikationsserver und Portalserver
Wie in Kapitel 2.2.1.1 beschrieben stellt der Applikationsserver zwar ein separates
Systemelement dar, ist in der Regel allerdings systembedingt nicht für die Auslagerung
geeignet. Da bei allen untersuchten kollaborativen Systemarchitekturen der
Applikationsserver fest mit dem Portalserver gekoppelt ist, ist eine separate
Auslagerung der Portalktechnologien ebenfalls nicht möglich. Somit stellt der
Applikationsserver im Verbund mit dem Portalserver die zentrale Einheit für eine
kollaborative Architektur dar und ist immer separat auf mindestens einer
Hardwaremaschine zu installieren. 113 Dieser Teil wird daher in der Literatur auch als
„Kernprodukt“ bezeichnet, erhält in der Regel den Namen der gesamten Architektur
(Vgl. „IBM Workplace Collaboration Services“) und beschreibt somit sowohl die
Systemelemente als auch die Zieldefinition des Produktes.
3.3.2.2 Webserver
Die Auslagerung von Webserverdiensten eignet sich bevorzugt zur Steigerung der
Performance eines Gesamtsystems und wird daher von allen Anbietern (J2EE-basierter)
kollaborativer Systemarchitekturen ermöglicht. Relevant für die Auswahl eines
Webserverproduktes ist die Kompatibilität mit dem Kernprodukt und ist in der
Herstellerliteratur definiert. Die meisten J2EE-basierten Systeme sind aufgrund ihrer
offenen Java-Architektur mit frei verfügbarer (OpenSource) Software verträglich (z.B.
Apache HTTP Server). Es können oft auch andere, als vom Hersteller des
kollaborativen Systems vorgeschlagene, Webserver genutzt werden, was jedoch häufig
zu speziellen Anpassungen führt.114
Die Auswahl des geeigneten Webservers richtet sich in der Realität jedoch häufig nach
dem Vorhandensein von Softwareprodukten, deren Leistungsfähigkeit und dem nötigen
Installationsaufwand.
VegaSystems und das GCC nutzen als IBM Business Partner die Vorteile des Value
Package of Software und haben daher die Möglichkeit, auf alle verfügbaren IBM
Produkte zurückzugreifen. Daher eignen sich im Kontext dieser Arbeit vor allem der
IBM HTTP Server V6 und der IBM Lotus Domino HTTP Task für die Auslagerung.
113 Vgl. IBM (2005) S. 65 ff.
114 Vgl. IBM (2005) S. 220 ff.
Konzeption einer J2EE Systemarchitektur
58
Alternativ steht der Microsoft IIS zur Verfügung, der bei fast allen Microsoft
Betriebssystemen integriert ist. Da jedoch eine spätere Portierung des Gesamtsystems
auf die Linux Plattform nicht ausgeschlossen ist, ist der IBM HTTP Server nicht zuletzt
aufgrund seiner Nähe zum (Linux-) Apache HTTP Server bezüglich
Installationsaufwand und Performance das geeignetste Systemelement.115
Die Distribution bzw. Ausgliederung (Application Offload) des HTTP Servers richtet
sich nach den herstellerindividuellen Angaben bezüglich ihres Kernproduktes und den
in der Produktliteratur erläuterten Vorgehensweisen zur Installation
3.3.2.3 Verzeichnisdienste
Bei Verzeichnisdiensten wird im Gegensatz zum HTTP-Server eine definierte
Schnittstelle zur Kommunikation mit dem kollaborativen (Kern-) System genutzt, was
die Einbindung quasi aller verfügbaren Verzeichnisdienste erlaubt. Unterstützt ein
Directory selbst kein LDAP, sind oft Applikationen von Drittanbietern verfügbar, die
diese Aufgabe übernehmen. Wie in Kapitel 2.2.1.4 erläutert, benötigt jeder
Verzeichnisserver ein s.g. LDAP-Schema, welches das Field-Mapping zwischen den
eigenen Userinformationen und den Anfragen des Kernsystems übernimmt. Mögliche
Softwareprodukte mit bzw. für Verzeichnisdiente(n) sind z.B.
- IBM Lotus Domino (ab Version R5)
- IBM Tivoly Directory Server
- Microsoft Active Directory (ab Version 4.0)
- Sun Java System Directory Server
- Novell eDirectory
In allen genannten Produkten ist das LDA-Protokoll bereits implementiert und die
individuelle Spezifikation von LDAP-Schemata vorgesehen. Die Auswahl eines
Produktes ist auch hier abhängig von den Fähigkeiten des Systemverwalters bezüglich
Installation und Wartung und die eventuell schon vorhandene Quelle der user-
relevanten Daten.
115 Mehr hierzu: Vgl. IBM (2005) S. 52 ff.
Konzeption einer J2EE Systemarchitektur
59
Für den Kontext dieser Arbeit empfiehlt sich besonders der Einsatz des IBM Lotus
Domino Directorys, da sowohl am GCC als auch bei VegaSystems alle relevanten
Userinformationen der Zielgruppe in Domino Adressbüchern gespeichert sind und der
IBM Lotus Domino Server als bestehendes Systemelement integriert bzw. mitbenutzt
werden kann.
Die Eingliederung bzw. das Application Offload des Verzeichnisservers geschieht nach
Anleitung der Softwarehersteller und definiert sich über die Angabe des LDAP-
kompatiblen Verzeichnisses auf der Seite des Kernproduktes und über die
Implementierung eines LDAP-Schemas im Directory Server. 116
Abbildung 3-3 Beispielsystems AO Directory und DBMS
3.3.2.4 Datenbanksysteme
Es liegt nahe, eine Nutzung von IBM Lotus Domino Datenbanken als Data-
Repository117 für kollaborative Anwendungen in Betracht zu ziehen. Aufgrund ihrer
Struktur eigenen sich dokumentenbasierte Datenbanken (z.B. „Notes storage facility“
116 Vgl. Abbildung 3-3 Beispielsystems AO Directory und DBMS
117 Claus (1993): Repository (engl. für deutsch: Lager, Depot), ist eine Verzeichnisstruktur oder
Datenbank, die Datenobjekte und deren Methoden zur Datentransformation enthält.
Konzeption einer J2EE Systemarchitektur
60
NSF) nicht für die Nutzung als Speicherobjekt für relationale Anwendungen. 118 Auch
wenn eine spätere Unterstützung von Domino Datenbanken vorgesehen ist,119
unterstützen alle derzeit verfügbaren J2EE-basierenden kollaborativen Systeme
ausschließlich relationale Datenbanksysteme als Backend-Speichersystem.120
Als Schnittmenge aller unterstützten DBM-Systeme ergeben sich folgende
Wahlmöglichkeiten: 121
- IBM DB2 Universal Database
- Oracle Enterprise Edition
- Microsoft SQL Server Enterprise Edition
Freie DBMS wie z.B. MySql werden nur von wenigen Anbietern unterstützt und
werden hier daher nicht weiter berücksichtigt. Eine weitere Betrachtung von DBMS-
Nischenanbietern ist zwar möglich, jedoch bei der endgültigen Implementierung sehr
aufwändig und daher nicht ratsam. 122 Eine Untersuchung dieser entfällt somit.
IBM erlaubt allen Nutzern des Value Package of Software die Nutzung der IBM DB2
Universal Database. Da dieses Datenbanksystem bereits sowohl vom GCC als auch
VegaSystems eingesetzt wird, liegt eine (Mit-) Nutzung der vorhandenen Ressourcen
nahe. Insofern vom kollaborativen System unterstützt, empfiehlt sich daher die Nutzung
der vorhandenen DBM-Systeme.
In der verfügbaren Literatur zu J2EE-basierenden kollaborativen Systemarchitekturen
finden sich ausführliche, wenn auch nicht immer korrekte und stimmige,
Installationsanleitungen für die Einbindung von vorhandenen DBMS. Die Distribution
erfolgt hierbei immer über einen s.g. Datenbank-Client, der die Kommunikation mit
dem Datenbanksystem ermöglicht. Hier sind grundsätzlich komplexe Anpassungen
118 Vgl. und mehr hierzu: Donskoj, Knäpper, Perc (2004), S. 171 ff.
119 Vgl. Ebel (2005) S. 616
120 Siehe auch: IBM (2005) S. 43 ff.
121 Vgl. Abbildung 3-3 Beispielsystems AO Directory und DBMS
122 Vgl. IBM (2005 b) S. 41, 42, 43
Konzeption einer J2EE Systemarchitektur
61
notwendig, die einen hohen Kenntnisstand des Systemverwalters über
Datenbanksysteme erfordern. 123
3.4 J2EE-basierte eSSL Systemarchitektur für kollaborative
Serverdienste
Aus der Konzeptionsphase ergibt sich somit ein klareres Bild der Zielarchitektur, die
sowohl den gestellten Anforderungen als auch den gegebenen Rahmenbedingungen
gerecht wird. Ziel war die vollständige Abbildung aller Produktmerkmale eines J2EE
basierten kollaborativen Systems, das durch die Wahl einer geeigneten Architektur über
die benötigten Leistungspotentiale, Stabilität und Integrationsfähigkeiten verfügt.
Für die erweiterte Single Server Lösung werden 4 einzelne Nodes
(Hardwaremaschinen) benötigt, die zum Teil bereits vorhandene Systeme der
Infrastruktur darstellen. 124
Abbildung 3-4 J2EE-basierte kollaborative Systemarchitektur (eSSL)
123 Vgl. IBM (2005) S. 49 ff.
124 Vgl. Abbildung 3-4 J2EE-basierte kollaborative Systemarchitektur (eSSL)
Konzeption einer J2EE Systemarchitektur
62
Für das J2EE basierende kollaborative Kernsystem wird ein freier, ungenutzter Rechner
beansprucht, der die Dienste „Webserver“, „Verzeichnisserver“ und „Datenbankserver“
von ausgelagerten Rechnersystemen bezieht und somit ausschließlich die zentralen
Dienste des Applikations- und Portalservers verwaltet.
Da Webclients ausschließlich über den ausgelagerten Webserver mit dem
kollaborativen System kommunizieren, erfolgt hier der vergleichsweise größte
Lastenausgleich auf ein separates Rechnersystem, was die Versorgung von 25
gleichzeitigen Usern erleichtert.
Durch die Verwendung eines externen LDAP kompatiblen Verzeichnisdienstes wird die
Mitbenutzung bestehender Systemelemente besonders zur zentralen Verwaltung von
(bestehenden) Benutzerdaten und Authentifizierung ermöglicht, was wiederum zu einer
zusätzlichen Entlastung des Kernsystems führt.
Neben dem Applikationsserver stellt ein Datenbanksystem in diesem Zusammenhang
die höchsten Anforderungen an die verfügbare Hardware. 125 Alle Anbieter von Java-
basierter kollaborativer Software raten zur Auslagerung der Datenbankanwendungen
auf externe Rechnerressourcen, was in der vorliegen Systemarchitektur berücksichtigt
wird. Da in allen vorhandenen Systemlandschaften bereits relationale Datenbankserver
vorhanden sind, können diese für das Application Offload mitbenutzt werden. 126
Zusammenfassend wird für die modellierte Architektur ein zusätzlicher Bedarf von zwei
Rechnersystemen (Kernsystem und Webserver) zum Erreichen der gesteckten Ziele
erforderlich. Die Firma VegaSystems verfügt in ihrem festgelegten Budget über
genügend Ressourcen zur Realisierung dieses Konzeptes. Um das Konzept auf die
gestellte Hardware der Universität Paderborn (nur ein freier Server) zu übertragen, ist
die separate Installation des HTTP Servers auf derselben Maschine notwendig.
Evaluierungen der reinen Single Server Installation haben ergeben, dass von dieser
Installationsvariante zwar abzuraten ist, durch die Auslagerung des Verzeichnis- sowie
Datenbankservers jedoch genügend Kapazitäten frei werden, um auch mit einem
zusätzlichen Rechnersystem 25 User versorgen zu können. 127
125 Vgl. Chen et al. (2004) S. 31 ff.
126 Vgl. Kapitel 3.3.2.4
127 Vgl. Altemeier (2005) S.
Konzeption einer J2EE Systemarchitektur
63
Je nach Art des J2EE-basierenden kollaborativen Softwareproduktes ist die
Auslagerung einzelner Dienste nicht nur optional sondern zwingend erforderlich. Die
meisten Hersteller bieten jedoch die reine SSI als Installationsoption raten dennoch
grundsätzlich wegen mangelnder Performance und Stabilität davon ab. 128
Die modellierte erweiterte Single Server Lösung stellt somit für die gegebene
Aufgabenstellung die vergleichsweise bestmöglichste Systemarchitekturvariante dar.
Im folgenden Kapitel 4 wird die entwickelte Architektur aus der Konzeptionsphase
anhand der Referenzumgebung IBM Workplace Collaboration Services 2.5 / 2.6
umgesetzt und praktisch evaluiert.
128 Vgl. IBM (2005) S. 24
Realisation & praktische Evaluierung am Beispiel der Referenzumgebung
64
4 Realisation & praktische Evaluierung am Beispiel der
Referenzumgebung
Die prototypische Implementierung der entwickelten eSSL Architektur für kollaborative
Serverdienste beschreibt exemplarisch die Umsetzung der Ergebnisse der
Konzeptionsphase anhand der Referenzumgebung IBM Workplace Collaboration
Services (WCS). Zunächst werden die WCS Komponenten vorgestellt, erläutert und in
die Workplace Strategie eingeordnet.
Darauf folgt die Betrachtung der einzelnen Systemelemente mit deren Funktion und
Position innerhalb der erweiterten Single Server Architektur. Anschließend wird die
konzeptionelle Umsetzung vorgestellt und in einem Gesamtkonzept für die
prototypische Realisation festgehalten.
Basierend auf diesem Entwurf wird dann die eigene Implementierung aufgebaut. Es
folgt eine Beschreibung der in der Realisation umgesetzten Architekturmerkmale und
enthaltenen Funktionalitäten. Abgeschlossen wird das Kapitel mit der Darstellung der
Struktur der entwickelten und umgesetzten Lösung.
4.1 IBM Workplace Collaboration Services 2.5 / 2.6
IBM Workplace ist ein vielseitig einsetzbares, auf Standards basierendes, Produkt, das
sich aus einer Kombination verschiedener Lösungen aus dem IBM-Softwareportfolio
zusammensetzt. In dieser Vereinigung konzentrieren sich alle Faktoren, die die
Benutzer benötigen – Geschäftsprozesse, Collaboration, Communication, Informations-
Management, Dokumenten-Management und Produktivitätstools. 129 Diese werden über
eine einheitliche Workplace-Benutzeroberfläche (Web / Richclient (Managed Client) /
Thinclient) dem Anwender bereitgestellt. 130
129 Vgl. Abbildung 4-1 IBM Workplace Solutions
130 Vgl. Ebel (2005) S. 551 ff.
Realisation & praktische Evaluierung am Beispiel der Referenzumgebung
65
Abbildung 4-1 IBM Workplace Solutions 131
Bei IBM Workplace handelt es sich nicht um ein Softwareprodukt sondern vielmehr um
das Konzept eines digitalen Arbeitsplatzes132. Der Name „IBM Workplace“ steht hierbei
für die Front-End-Seite der Datenverarbeitung – also die mitarbeiterbezogene Online-
Umgebung, in der Benutzer arbeiten und miteinander kommunizieren können.
Die IBM Workplace Collaboration Services stellen ein Integrationsprodukt der
einzelnen IBM Workplace Produkte dar. Es handelt sich dabei um eine Produktfamilie,
auf der J2EE Plattform basierend, für messaging und instant messaging, calendaring
und scheduling, team collaboration, collaborative learning, Web content management
und document management.
IBM möchte mit diesem neuen Paradigma zum einen die Interaktion und die
Zusammenarbeit verbessern, indem Informationen und Geschäftsprozesse in einer
einzigen Umgebung zur Verfügung gestellt werden. Zum anderen bietet dieses Portal-
131 Quelle: IBM Press 2005, ohne Angabe des Autors
132 Siehe Abbildung 2-4 Workplace Collaboration Services Elementenstruktur
Realisation & praktische Evaluierung am Beispiel der Referenzumgebung
66
Framework die Möglichkeit, Schlüsselanwendungen und Funktionen für den jeweiligen
Anwender zusammenzulegen und ihm zudem weitere situationsabhängige
Informationen anzubieten (Activity Awareness). Mittels eines Single Point of Entry
können die Benutzer innerhalb ihrer personalisierten Portalumgebung auf z.B. E-Mail
Dienste, Webkonferenzen, Messaging Tools oder auf Anwendungen für virtuelle
Schulungen zugreifen, ohne sich jedes Mal neu und mit Passwort anmelden zu müssen
(Single Sign On / SSO).
Die neue Workplace-Strategie steht an sich für Anwendungen auf der Basis des
WebSphere Applikation- und Portalservers. Es handelt sich dabei um eine
übergreifende Integration 133 von bestehenden IBM Produkten mit Anwendungen von
Drittanbietern und spezifischen, neuen Eigenentwicklungen.
Die Workplace Umgebung greift dabei auf bestehende Konzepte der
Infrastrukturelemente von Lotus Workplace Version 2.01, Lotus Notes Domino Version
6.5.1, IBM WebSphere Application Server, WebSphere Portal Server und DB2 zurück.
Ziel dieser Vorgehensweise ist die s.g. Komponentisierung aufgrund ihrer Einordung,
Aufteilung und Funktion, so dass sie auf neue Art und Weise zum Nutzen der User und
deren Aufgaben effektiv kombiniert werden können.
Abbildung 4-2 Workplace Produktintegration 134
133 Vgl. Kapitel 2.2
134 In Anlehnung an Ebel (2005)
Realisation & praktische Evaluierung am Beispiel der Referenzumgebung
67
Begrifflichkeiten
Bei Durchsicht der verfügbaren Produktliteratur wird schnell ersichtlich, dass IBM sehr
verwirrend mit den einzelnen Produktbezeichnungen umgeht. Zusätzlich werden in
regelmäßigen Abstände ganze Produktgruppen umbenannt und damit Teil neuer
Marketingkampagnen. So nennt sich das umfassende, übergeordnete System und die
Strategie „IBM Workplace“, für eine der Komponenten wurde aber der Name „Lotus
Workplace“ vergeben. Auch IBM Lotus Domino wird mittlerweile unter dem Begriff
„IBM Workplace Technologies“ subsummiert, obwohl dies mit der aktuell vorgestellten
portierbaren Workplace-J2EE Technologie (noch) nichts zu tun hat. IBM wird in der
Zukunft nach eigener Aussage die Markennamen der einzelnen Produkte immer weiter
in den Hintergrund treten lassen, der Kunde erwirbt nur noch IBM Workplace und kann
darin Funktionen aktivieren und lizensieren, die benötigt werden, als ein Teil der IBM
Business-On-Demand Strategie.135
Abgrenzung
Das einzelne Produkt Lotus Notes Domino repräsentiert das bekannte Groupware-
System als Anwendungsplattform, das sich als Marktführer im Mail- und
Kollaborations-Bereich etabliert hat. IBM Workplace repräsentiert dabei eine neue
Strategie mit einem anderen technologischen Ansatz: WebSphere Application- und
Portal Server und damit die Java-Plattform bzw. J2EE. Die unterschiedlichen
Anwendungen werden nicht mehr separat sondern als WebSphere-Applications
ausgeführt.
4.1.1 IBM Workplace Produktfamilie
Die vielseitige Workplace Infrastruktur beinhaltet vier einzelne Produktfamilien der
IBM Bemühungen bezüglich kollaborativen Arbeitens, aggregiert auf einer
einheitlichen Technologie und Plattform. Diese neue Plattform beinhaltet zusätzlich die
neue „Managed Client“ Technologie.
135 Vgl. Devlin (2005) S. 1 bis 4.
Realisation & praktische Evaluierung am Beispiel der Referenzumgebung
68
IBM Lotus Notes and Domino
Messaging, Application Development und Collaboration Produkte, die in
Unternehmensumfelder integriert werden können.
IBM WebSphere Portal
Die vereinheitlichte Arbeitsumgebung, die personalisierten Zugriff auf Informationen,
Anwendungen und Geschäftsprozesse bietet.
IBM Workplace Collaboration Services (Lotus Workplace)
Die auf Standards basierende Integrationslösung mit einem vereinheitlichten Interface
für den Zugriff auf kollaborative Anwendungen
IBM Workplace Services Express
Die, im Funktionsumfang reduzierte, Workplace Collaboration Lösung mit der
Zielgruppe „Small Business”
-IBM WebSphere Everyplace
Lösungen für die Anbindung von ThinClients wie PDAs und Mobiltelefone
IBM Workplace Managed Client
Die neue, verwaltete Client-Technologie, basiert auf einer RichClient Architektur
4.1.2 Workplace Collaboration Komponenten
„Die starke Nachfrage nach einer integrierten Software fördert das Zusammenwachsen
von Marktsegmenten wie Collaboration, Portale und Content Management. Laut IDC
wird das Marktvolumen für integrierte Software im Jahr 2007 13 Milliarden Dollar
betragen. Mit der IBM Workplace-Produktfamilie kann sich IBM als Marktführer in
diesem Segment positionieren“
Larry Bowden, Vize Präsident von Lotus Workplace Products, IBM
IBM Workplace soll eine Reihe von Funktionen integrieren und als übergreifendes Ziel
die Interaktion zwischen Menschen und den Zugriff auf Informationen und Prozesse
ermöglichen, um damit langfristig zu einer Steigerung des Unternehmenserfolges
Realisation & praktische Evaluierung am Beispiel der Referenzumgebung
69
beizutragen.136 Die einzelnen Komponenten lassen sich mittels Lizenzkey einzeln
aktivieren und deaktivieren und ermöglichen somit den bedarfsorientierten Einsatz.
Abbildung 4-3: Workplace Collaboration Services Komponentenstruktur 137
Das zusammengefasste Produktportfolio wird als „IBM Workplace Collaboration
Services“ bezeichnet und umfasst im Wesentlichen folgende Komponenten:
• IBM Workplace Documents (WD)
Diese Komponente umfasst ein standardisiertes Dokumentenmanagement mit
der Möglichkeit, den kompletten Lebenszyklus eines Dokumentes von der
Erstellung bis zur Archivierung zu verfolgen. Dieses Modul wird vollständig in
den Microsoft Windows Desktop und vorhandene Microsoft Office
Anwendungen integriert.
• IBM Workplace Web Content Management (WWCM)
Das WWCM Konzept umfasst die Erstellung, Veröffentlichung und
Archivierung webbasierter Informationen für die Bereiche Internet, Extranet und
Intranet.
136 Vgl. Abbildung 4-3: Workplace Collaboration Services Komponentenstruktur
137 Quelle: IBM Press 2005 ohne Author
Realisation & praktische Evaluierung am Beispiel der Referenzumgebung
70
• IBM Workplace Messaging (WM)
IBM WM beschreibt die zentrale Messaging-Lösung, die neben der normalen E-
Mail Funktionalität, ähnlich zu IBM Lotus Domino, auch die Verwaltung von
Kontakten und Kalenderfunktionen zur Verfügung stellt. Wahlweise kann auch
eine bestehende Messaging Umgebung integriert werden (z.B. IBM Lotus
Domino / Microsoft Outlook)
• IBM Workplace Team Collaboration (WTC)
Dieses Modul händelt sowohl die statischen als auch die dynamischen
Teamarbeitsbereiche und schafft Lösungen für Echtzeitkommunikation,
Anwesenheitserkennung und die Durchführung von Webkonferenzen.
• IBM Workplace Collaborative Learning (WCL)
Diese Anwendung dient der effizienten Verwaltung von Trainingsprogrammen,
Ressourcen und Kursen als Schulungsangebot für verteilte User.
• IBM Workplace Solutions (WS)
Dieses Modul beschreibt eine Reihe optionaler branchenspezifischer
Anwendungen, zugeschnitten auf spezielle Arbeitsrollen innerhalb eines
Unternehmens.
Clienttechnologien
Die IBM Workplace Collaboration Services unterstützen dabei verschiedene Client-
Technologien als Schnittstelle zum Benutzer. Die WCS Express Variante stellt die
Leistungen ausschließlich über das integrierte Webportal zur Verfügung und bietet
keine Unterstützung für weitere Clienttechnologien.
Das Hauptprodukt „Collaboration Services 2.6“ erweitert die Zugriffsmöglichkeiten um
die Integration von ThinClients wie PDA’s und Mobiltelefone sowie um die
Unterstützung von s.g. RichClients von IBM „Managed Client“ genannt. Bei diesem
RichClient handelt es sich um eine Java-Applikation, die alle erforderlichen
Softwarepakete vom Workplace-Server im Pull-Verfahren bezieht, neue Daten und
Änderungen im Push-Verfahren zurückgibt. Es handelt sich somit um eine vollständig
verwaltete (eng. „managed“) Lösung, deren Konfiguration, Wartung und Erweiterung
zentral von der Workplace Infrastruktur gesteuert wird. Neue Applikationen, die s.g.
Realisation & praktische Evaluierung am Beispiel der Referenzumgebung
71
PlugIns, werden über den Provisioning Server, eine Erweiterung des Portalservers, an
die Managed Clients verteilt. 138
Abbildung 4-4 IBM Workplace Managed Client139
IBM bemüht sich derzeit verstärkt um die Entwicklung des RichClients und plant die
Verschmelzung des Lotus Notes Clients mit dem Workplace Managed Client. Auch hier
ist das Ziel eine (ver-) einheitlichte Architektur „Workplace“, in der letztendlich auch
das Lotus Domino / Notes Konzept mit aufgehen soll.
138 Vgl. Abbildung 4-4 IBM Workplace Managed Client
139 Aus: Bai et al. (2005) S. 9
Realisation & praktische Evaluierung am Beispiel der Referenzumgebung
72
4.1.3 IBM WCS Systemelemente, Funktion und Positionierung
Bei dem Produkt „IBM Workplace Collaboration Services 2.6“ handelt es sich um eine
Integrationslösung (Konzept der Addition) folgender IBM Produkte:
- IBM Websphere Portal Server
- IBM Websphere Application Server
- IBM (Lotus) Workplace Server 2
- IBM Cloudscape RDBMS / IBM DB2 UDB (alternativ)
- IBM Tivoly Directory Server
- IBM HTTP Server (optional, für Managed Client erforderlich)
Bei der rudimentären Installationsvariante (SSI) werden die oben aufgeführten
Bestandteile automatisch, mit den erforderlichen Integrationskomponenten, installiert
und stellen als Gesamtsystem die Benutzerschnittstelle „Workplace“ zur Verfügung.
Die Installation greift hierbei auf eine „Cloundscape / Informix “ Datenbank als Basis
zurück. Die Installation einer DB2 Datenbank als alternatives Respository ist optional.
Soll der User über weitere Client-Technologien verfügen können (z.B. Richclients oder
Thinclients), ist eine zusätzliche manuelle Installation eines IBM HTTP Servers (oder
vergleichbar) und, des Client-Typs entsprechenden, Provisioning Servers nötig. Dieser
stellt die erforderlichen Programminstanzen, Plugins und Extensions (Funktionalitäts-
erweiterungen) für die jeweiligen Clients zur Verfügung und versorgt (engl.
provisioning) diese mit entsprechenden Updates und Upgrades.
Im Folgenden werden die einzelnen Systemelemente kurz erläutert und innerhalb der
Workplace Collaboration Services positioniert. Die Funktionsvorstellung erfolgt analog
zu der Einführung in die Systemelemente aus Kapitel 2. Eine erneute Vorstellung aller
Funktionen ist im Rahmen dieser Arbeit nicht möglich; die folgenden Abschnitte
beschränken sich somit auf die kurze Einführung in die einzelnen IBM Produkte und
deren Bedeutung für das kollaborative Gesamtkonstrukt IBM Workplace.
Realisation & praktische Evaluierung am Beispiel der Referenzumgebung
73
4.1.3.1 IBM WebSphere Application- und Portal-Server
IBM WebSphere Application Server
Der Applikationsserver von IBM basiert auf einer Servlet Engine, ist voll kompatibel
zum J2EE-Standard Version 1.2.1 und wurde um einige Features der Java-Version 1.3
erweitert. Der WebSphere Application Server Advanced Edition bietet eine
Unterstützung für alle gängigen Dienste wie Servlets, Java Servlet Pages (JSP),
Enterprise Java Beans (EJB) und die Standard-Schnittstellen wie CORBA und JMS.
Der integrierte Webserver basiert hierbei auf der Apache-Technologie und unterstützt
somit Webservices wie das SOAP Protokoll (Simple Object Access Protocol), UDDI
(Universal Description, Discovery and Integration) als auch die WSDL-Sprache
(Webservices Description Language).140
IBM WebSphere Portal Server
Auf Basis des Eclipse-Framework und offenen Standards, wie Java und J2EE, bietet der
Portal Server von IBM die technische Grundlage für die prozessorientierte
Zusammenführung von Inhalten, Informationen und Daten aus heterogenen Systemen.
Das System bietet die freie Wahl unterschiedlicher Betriebssysteme (Windows, Linux,
AIX, Solarias), Aggregation der Benutzeroberfläche auf ein Frondend sowie globaler
Mehrsprachigkeit, Single Sign On (SSO) und umfangreicher Personalisierungs-
funktionen. Der Portalserver nutzt die Technologien des Applikationsservers, kann
jedoch auch einzeln, ohne eine vollständige Installation des IBM WebSphere
Application Server, installiert und betrieben werden.
Workplace Integration
Der IBM WebSphere Applikationsserver (WAS) ist fester Bestandteil der Workplace-
Technologie und bildet die Basis für alle Funktionalitäten der Collaboration Services.141
Der WAS kann nicht ausgelagert werden, bestehende (externe) Applikationsserver nicht
integriert werden. Durch die feste Aggregation mit dem Portal Server stellt diese
Kombination die zentrale Einheit dar, in dem der Kern-Portalcode läuft, ebenso wie
einige Workplace-spezifische Programmlogik. Der User agiert somit über das Frontend
140 Vgl. Sadtler et al. (2005 b) S. 1 ff.
141 Vgl. Abbildung 4-5 Conceptual Lotus Workplace architecture
Realisation & praktische Evaluierung am Beispiel der Referenzumgebung
74
des WebSphere Application- und Portalservers mit dem Workplace Server und niemals
direkt.
Abbildung 4-5 Conceptual Lotus Workplace architecture142
“Overall, the (…) Workplace architecture is based on the concept of Workplace
application components, leveraging Workplace services, that themselves run on top of
WebSphere Portal services. These all share a common base infrastructure of IBM
WebSphere Application Server, WebSphere Portal (…)”143
4.1.3.2 IBM Workplace Server 2
Der Workplace Server, auch teilweise noch „Lotus Workplace Server“ genannt, stellt
das Herzstück des IBM Workplace Konzeptes dar. Der Großteil aller Workplace-
Dienste (Services) läuft innerhalb dieses WebSphere Applikationsserver Java Prozesses.
142 In Anlehnung an: Bravo et al. (2005) S. 28
143 Vgl. Bravo et al. (2005) S.8
Realisation & praktische Evaluierung am Beispiel der Referenzumgebung
75
Die Kommunikation zwischen den einzelnen Services läuft üblicherweise über s.g.
Requests innerhalb des WebSphere Portal Servers. 144
Eine Ausnahme hierzu stellen die Zugriffe über POP3- und IMAP-Clients dar; diese
führen einen direkten Dialog mit dem Workplace Server.
Eine klare Abgrenzung zwischen IBM WebSphere Application / Portal Server und dem
Workplace Server ist nicht bei allen Komponenten möglich. Vielmehr stellt der
Workplace Server eine eigenständige Applikation dar, die innerhalb des WebSphere
Application Server Frameworks ausgeführt wird und auf dem Softwareprodukt „Lotus
Workplace 2.01“ basiert. Alle Komponenten, wie z.B. Workplace Documents der IBM
Workplace Struktur, sind Teil des Workplace Servers und werden als „Workplace
Produkte“ bezeichnet.145 Somit können alle Funktionen der Workplace Collaboration
Services dem Workplace Server zugeordnet werden, der wiederum selbst auf dem IBM
WebSphere Application- und Portal-Server aufbaut. 146
Abbildung 4-6 Workplace Server
144 Vgl. Abbildung 4-5 Conceptual Lotus Workplace architecture
145 Vgl. Ebel (2005) S. 812
146 Vgl. Abbildung 4-6 Workplace Server
Realisation & praktische Evaluierung am Beispiel der Referenzumgebung
76
4.1.3.3 IBM Cloudscape und DB2 UDB
IBM Cloudscape
IBM Cloudscape ist ein auf Java basiertes objekt-relationales Datenbank Management
System. Cloudscape wurde speziell für verteilte Systeme und Java Anwendungen, die
eine integrierte Datenbank benötigen, entwickelt. Mit Cloudscape können Java-basierte
Anwendungen erstellt und verteilt werden, die z.B. als Teil eines
Unternehmensnetzwerks arbeiten. IBM Cloudscape kann auch als Client zum DB2
Everyplace Synchronization Server (ab DB2 Everyplace V8.1.4) eingesetzt werden, um
bidirektional Daten mit anderen Unternehmensservern zu synchronisieren, wie z.B.
IBM DB2 Datenbank Management Systeme.
Mittlerweile wurde der Quellcode von Cloudscape an die Apache Software Foundation
zur Nutzung als OpenSource Software übergeben. IBM will nach eigener Aussage
damit die Entwicklung neuer Java-Applikationen vorantreiben und so auch das
Spektrum an Java-Anwendungen vergrößern. Besonders Nutzer von Embedded-Geräten
und kleine Unternehmen sollen von dem Open Source Projekt mit Codenamen Derby
profitieren.
Trotzdem ist das Cloudscape Datenbanksystem immer noch Bestandteil vieler IBM
Anwendungen und Systeme. Die Single Server Variante der IBM Workplace
Collaboration Services 2.5 und 2.6 basieren in ihrer rudimentären Installation auf einer
IBM Cloudscape-Instanz als Datenrepository. Wie bereits erläutert, empfiehlt IBM
jedoch die Installation eines externen DBMS wie z.B. IBM DB2 zur Steigerung der
Performance des Gesamtsystems, so dass nicht weiter auf IBM Cloudscape eingegangen
werden muss. 147
IBM DB2 Universal Database
Basis des IBM Information Management Produktportfolios ist DB2 Universal Database
(UDB), IBMs multimediales, internetfähiges, relationales Datenbank-Management-
System. DB2 eignet sich dabei für alle Arten von Anwendungen, von der
Transaktionsverarbeitung mit ERP- (Enterprise Resource Planning), CRM- (Customer
Relationship Management), SCM- (Supply Chain Management) und E-Commerce-
Anwendungen über die Verwaltung multimedialer Inhalte im Rahmen von Enterprise
147 Vgl. Kapitel 2.2.1.5 Datenbanksysteme und DBMS
Realisation & praktische Evaluierung am Beispiel der Referenzumgebung
77
Content Management bis hin zu Data Warehousing und kollaborativen Anwendungen.
Dabei ist die IBM DB2 im Vergleich zu anderen DBMS sehr „leistungsfähig und
wirtschaftlich“.148
Workplace Integration
Es ist nicht vorgesehen die DB2 UDB auf demselben Node des WAS Kernsystems zu
installieren. Auch wenn dieses technisch möglich ist, sehen alle
Installationsanweisungen von IBM nur die separate Installation auf externen Systemen
vor. Ein Datenbanksystem wie die DB2 UDB stellt somit den wichtigsten Teil für die
Datenverarbeitung und -speicherung der IBM WCS dar.
4.1.3.4 IBM Tivoli Directory / IBM Lotus Domino LDAP
Sowohl der IBM Tivoli Directory Server (TDS) als auch der IBM Lotus Domino
(Directory) Server können Benutzerkonten und deren Attribute verwalten. Der IBM
TDS ist ein reiner Verzeichnisserver und verfügt, im Gegensatz zu IBM Lotus Domino,
über keine weiteren Fähigkeiten und ist ausschließlich auf die Verwaltung von
Benutzerdaten, Benutzerauthentifizierung und -validierung ausgerichtet. Der Lotus
Domino Server stellt die Eignungen des eigenen Names and Adressbook (NAB) über
das Lightweight Directory Access Protokoll (LDAP) bereit und erlaubt somit, wie der
reinrassige Tivoli Directory Server, die Nutzung des eigenen Verzeichnisses durch
externe Dienste.
Somit bieten beide Dienste eine leistungsfähige LDAP-Identitätsinfrastruktur als
Implementierungsbasis für Anwendungen zum Identitätsmanagement und
fortschrittliche Softwarearchitekturen wie die IBM Workplace Collaboration Services.
Sowohl der IBM Tivoli als auch der Lotus Domino Server bieten:
• Kompatibilität mit LDAP-basierten Anwendungen des Industriestandards durch
Unterstützung von LDAP Version 3.
• Skalierbarkeit von Einträgen sowie Mitgliedern
148 Siehe Brown (2002) : IBM DB2 Universal Database vs. Oracle 9i: Total Cost of Ownership
Realisation & praktische Evaluierung am Beispiel der Referenzumgebung
78
• Plattformunterstützung: AIX, Solaris, Microsoft Windows 2000 und HP-UX
sowie Linux-Varianten für Intel und IBM eServer iSeries-, pSeries- und zSeries-
Plattformen.
• Replikationsfunktionalität für Master/Subordinate-Replikation, kaskadierende
Gateway-Replikation und Peer-to-Peer-Replikation mit Master-Servern.
• Vereinfachtes Management und erhöhte Benutzerfreundlichkeit durch eine
grafische Webadministrationsschnittstelle (GUI) und Funktionen wie
dynamische und verschachtelte Gruppen sowie sortierte und seitenweise
abrufbare Suchergebnisse.
• Integration mit IBM Betriebssystemen, WebSphere-Middleware und Tivoli-
Produkten für Identitätsmanagement und Sicherheit.
Nach der Standardinstallation der WCS Version 2.6 übernimmt ein integrierter Tivoli
Directory Server die Aufgaben des Benutzermanagements und der Authentifizierung
(auch SSO).149 Dieser eingebettete Dienst stellt nur einen Teil der Funktionen des
vollständigen TDS bereit und dient mehr der exemplarischen Funktionsdarstellung als
einem Produktivbetrieb.150 Analog zur Auslagerung des DBMS sieht IBM für die
erweiterte Single Server Lösung auch das Application Offload des Verzeichnisdienstes
vor.
In letzter Konsequenz ist es unerheblich welcher Verzeichnisdienst (mit)genutzt wird;
die Entscheidung beruht eher auf den Ausprägungen der eigenen Infrastruktur und den
damit schon vorhandenen Diensten und Daten(quellen).
149 Vgl. Kapitel 2.2.1.4 Verzeichnisdienste
150 Vgl. IBM (2006) S. 107
Realisation & praktische Evaluierung am Beispiel der Referenzumgebung
79
4.1.3.5 IBM HTTP Server
Der IBM HTTP Server ist sowohl fester Bestandteil des WebSphere Application
Servers als auch eigenständiges Produkt. Er wurde von der Apache Software
Foundation entwickelt und basiert auf den Technologien des Apache Webservers 2.0
und der Apache Portable Runtime (APR). IBM selbst ergänzt die bestehenden Releases
des Apache 2.x um IBM-spezifische Erweiterungen, um Kompatibilität zu anderen IBM
Produkten zu gewährleisten.151
Neben dem Ursprungssystem Unix unterstützt Apache auch Linux, Windows, NetWare,
Mac OS sowie eine Vielzahl weiterer Betriebssysteme. Die Bibliothek Apache Portable
Runtime (APR) stellt eine Aggregation wichtiger Systemaufrufe und – funktionen zur
Verfügung, so dass die individuellen Stärken des jeweiligen Betriebssystems ausgenutzt
werden können. Hinzu kommen verschiedene Multiprocessing-Module (MPM), die je
nach OS-Plattform unterschiedliche Lösungen für die gleichzeitige Bedienung mehrerer
Client-Anfragen anbieten. Daher eignet sich der Apache bzw. IBM HTTP Server
besonders für das Application Offload zur Performancesteigerung.152
Durch den modularen Aufbau des Apache Webservers ist es IBM möglich, Workplace-
spezifische Schnittstellen zu entwickeln, die nahtlose Integration garantieren. 153 154
Neben dem IBM bzw. Apache Webserver unterstützen die Workplace Collaboration
Services weitere Webserverdienste, wie z.B. den Microsoft Internet Information Server
(IIS), Sun ONE Webserver als auch den HTTP Task des IBM Lotus Domino Servers.
Aufgrund der Schlankheit der Apache-Derivaten empfiehlt IBM jedoch explizit den
Einsatz des IBM HTTP Servers für die IBM WCS. 155
Weitere Gründe für die Präferenz sind sowohl die schon vorhandenen
Integrationskomponenten des IBM HTTP Servers als auch die daraus resultierenden
Administrations-Erleichterungen.
151 Vgl. Abbildung 4-7 IBM HTTP Server & IBM WebSphere
152 Vgl. 3.3.2.2 Webserver
153 Vgl. IBM (2004) S. 9 ff.
154 Vgl. Abbildung 4-7 IBM HTTP Server & IBM WebSphere
155 Vgl. IBM (2006) S. 219 ff.
Realisation & praktische Evaluierung am Beispiel der Referenzumgebung
80
Abbildung 4-7 IBM HTTP Server & IBM WebSphere
4.2 Systemaufbau und Realkonzept
Die entwickelte eSSL Systemarchitektur für J2EE-basierte kollaborative Serverdienste
soll anhand der Referenzumgebung IBM Workplace Collaboration Services 2.6
umgesetzt werden. Ziel ist die Validierung der Konzeption anhand einer realen
Installation.
4.2.1 Szenario
Für die Realisation stehen zwei Server der Firma VegaSystems und ein System der
Universität Paderborn zur Verfügung. Für die Integration bestehender Dienste bieten
sich darüber hinaus das IBM Lotus Domino Verzeichnis und der DB2 UDB Server der
Firma VegaSystems an, da die Mitbenutzung vorhandener Systeme der Universität aus
Datenschutzgründen nicht vorgesehen ist.156 Der externe IBM HTTP Server kann auf
dem verbleibenden freien System umgesetzt werden.
Durch die räumliche und netzwerktechnische Trennung der Universitäts – und
VegaSystems-Systeme ist eine Nutzung beider Systeminfrastrukturen
ausgeschlossen.157 Da zu Installationszwecken extrem große Datenmengen 158 über das
156 Siehe auch: 3.1.1 Rahmenbedingungen und Budget
157 Vgl. Kapitel 3.2.2 Application Offload und 3.2.3 Network Deployment
158 Datenvolumen der WCS 2.6 Installation: ca. 4,86 GigaByte
Realisation & praktische Evaluierung am Beispiel der Referenzumgebung
81
Netzwerk transferiert werden müssen, bietet sich die ausschließliche Nutzung der
VegaSystems Systeme an, da eine Installation des Universitätsservers über optische
Speichermedien (z.B. DVD) wegen der räumlichen Unzugänglichkeit undurchführbar
ist. Um den Aufwand für die Installation, Wartung und Administration so gering wie
möglich zu halten, wird daher auf eine Einbeziehung des einzelnen Servers der
Universität verzichtet. 159
Zur Realisation der eSSL Architektur stehen somit zur Verfügung:
- Freies Hardwaresystem für das IBM Workplace 2.6 Kernsystem
- Freies Hardwaresystem für den IBM HTTP Server V6
- Vorhandener Verzeichnisserver IBM Lotus Domino 7 über LDAP
- Vorhandener DB2 UDB Server zur Mitbenutzung
Für die einfachere Zuordnung der einzelnen Knoten wird für den folgenden Teil dieser
Arbeit die explizite DNS-Bezeichnung (Domain Name Service) verwendet. Die Angabe
von einzelnen IP-Adressen bleibt, insbesondere wegen ihres dynamischen Charakters,
aus und ist darüber hinaus im Rahmen dieser Arbeit auch nicht notwendig.
Die Konfiguration von Reverse- und Forward DNS Zonen ist dagegen für die
Installation der IBM WCS 2.6 zwingend erforderlich.160
Folgende Aufstellung beschreibt das Knoten-Szenario anhand der DNS-Namen:
DNS URL und Serverhardware WCS Elemente
ibmwp1.vegasystems.org IBM eServer x345
Dual XEON, 4 GB, Raid 1/5 HDD
IBM Workplace Server
IBM WebSphere Application Server
IBM WebSphere Portal Server
gate1.vegasystems.de IBM eServer x345
Dual Xeon, 4 GB RAM, Raid 5 HDD
IBM Lotus Domino V7 als Verzeichnisserver über LDAP (Mitbenutzung und Integration)
159 Siehe auch: 3.1.1 Rahmenbedingungen und Budget
160 IBM (2006 b) S. 7
Realisation & praktische Evaluierung am Beispiel der Referenzumgebung
82
gate2.vegasystems.de IBM eServer x346
Single Xeon, 2 GB RAM, Raid 1 HDD
IBM HTTP Server V6
primus.vegasystems.de IBM eServer x306m (Cluster)
IBM DB2 Datenbankserver
(Mitbenutzung und Integration) Abbildung 4-8 Realszenario DNS
4.2.2 Realisation
Die Installation der einzelnen Systemelemente erfolgt analog zu den Beschreibungen
der IBM Dokumentation für das IBM Workplace Collaboration Cluster Deployment 161
und mit Hilfe der vorangegangenen Seminararbeit „Konzeption eines Best Practice
Guide zur Administration einer IBM Workplace Infrastruktur“. 162
Durch die partiell fehlerhafte Beschreibung der Installationsprozeduren in der IBM
Dokumentation weichen die tatsächlichen Implementierungswege von den IBM-
Anweisungen teilweise erheblich ab. Da der Rahmen dieser Arbeit eine vollständige
Abbildung aller Besonderheiten nicht zuläßt und erfordert, beschränken sich die
Anmerkungen der Besonderheiten auf die folgenden Kapitel und die „Erfahrungen mit
der Systemarchitektur“ in Kapitel 4.3.
Installation Roadmap
Die Realisation der eSSL Systemarchitektur erfolgt in 4 Schritten, die nacheinander
abgearbeitet werden müssen.
161 Vgl. IBM (2006 b)
162 Vgl. Altemeier (2005)
Realisation & praktische Evaluierung am Beispiel der Referenzumgebung
83
Abbildung 4-9 eSSL Installation Roadmap
Zum Zeitpunkt der Installation der WCS Kernkomponenten müssen die ausgelagerten
Komponenten des Verzeichnisdienstes und der Datenbankanwendung bereits bestehen,
da ansonsten eine Installation des eSSL WCS 2.6 Systems nicht möglich ist. Eine
spätere Erweiterung der reinen Single Server Installation auf die eSSL Architektur ist
nicht möglich. Die Entscheidung für eine Architektur zu Beginn der Installation ist von
essentieller Bedeutung und im Nachhinein nicht mehr, oder nur sehr schwer, zu
revidieren.163
Das vorliegende Szenario beinhaltet bereits vorhandene Verzeichnisdienste und DBM-
Systeme, die jedoch speziell an die Bedürfnisse des WCS-Systems angepasst werden
müssen. Daher wird im Folgenden zuerst das Application Offload erläutert und definiert
und danach die Installation des Kernsystems.
163 Vgl. IBM (2006) S. 1
Realisation & praktische Evaluierung am Beispiel der Referenzumgebung
84
4.2.2.1 Application Offload
IBM DB2
Da eines der Hauptziele dieser Arbeit die Integrationsfähigkeit in bestehende
Systemlandschaften darstellt, wird an dieser Stelle nicht auf die Grundinstallation eines
IBM DB2 Datenbank Systems eingegangen, sondern vielmehr auf die Anpassungen, die
für die Nutzung des DBMS durch die Workplace Collaboration Services notwendig
sind. Es wird im Folgenden somit von einer bestehenden IBM DB2 Installation
ausgegangen.164 Bestehen auf dem DB2 Server bereits andere Datenbankanwendungen,
muss zwingend ein eigener Datenbankcontainer angelegt werden.165
Damit die IBM WCS 2.5/2.6 mit der DB2 Instanz kommunizieren können, ist ein s.g.
DBMS-Client notwendig, der die Erstellung und den späteren Zugriff der relevanten
Datenbanken regelt. Die Installation des DBMS-Clients wird ausführlich in der
Produktliteratur beschrieben.166
Anmerkungen
Der DB2-Client muss immer denselben Verbindungsport wie der DB2-Server
verwenden, da die WCS ansonsten später nicht mit der DB2 Instanz arbeiten kann. Der
DB2-Server verwendet standardmäßig Port 50000 für Verbindungen und Port 50001 für
Interrupts.167 Unter z.B. SuSE Linux ist Port 50000 möglicherweise bereits für einen
anderen Zweck reserviert; wenn dies der Fall ist, erhöht DB2 die Portnummern
automatisch um +1. Dieses muss bei der Konfiguration berücksichtigt werden.
Einrichtung der Datenbanken
Standardmäßig wird IBM Workplace Collaboration Services zusammen mit einigen
vordefinierten Daten installiert, die im Datenbankverwaltungssystem IBM Cloudscape,
das sich direkt auf dem Workplace Collaboration Services Server befindet, gespeichert
sind. Die Daten für IBM WebSphere Portal Server (zusammen mit Workplace
Collaboration Services installiert) werden standardmäßig ebenfalls in Cloudscape
164 Zur Installation der IBM DB2 UDB: Vgl.: Chen et al. (2003)
165 Vgl. Chen et al. (2003)
166 Vgl. IBM (2005) S. 171
167 Mehr hierzu: Chen et al. (2004)
Realisation & praktische Evaluierung am Beispiel der Referenzumgebung
85
gespeichert. Zum Application Offload des DBMS ist nun ein s.g. Transfer der
Datenbanken auf den ausgelagerten DB2 Server notwendig.
Die Übertragung der Datenbanken gliedert sich in folgende Schritte:
1. DB2-Datenbank konfigurieren - Damit werden die Schemata und
Tabellenbereiche erstellt, die für Workplace Collaboration Services erforderlich
sind.
2. WebSphere Portal Server-Daten an DB2 Universal Database übertragen - Damit
werden WebSphere Portal Server-Standarddaten an die DB2-Datenbank
übertragen.
3. Workplace Collaboration Services Daten an DB2 Universal Database übertragen
- Damit werden Workplace Collaboration Services-Standarddaten an die DB2-
Datenbank übertragen.
4. DB2 Universal Database-Einstellungen aktualisieren - Damit werden einige
abschließende Konfigurationstasks für die Datenbank ausgeführt, bevor Sie das
Produkt nutzen können.
Die Prozedur zur Anbindung an externe Datenbanken ist zum Teil sehr komplex und
fehleranfällig. IBM stellt bis zur WCS Version 2.6 keine automatisierten
Installationsmechanismen bereit, so dass fundierte Kenntnisse über DB2 und JDBC
notwendig sind. 168 Da die WCS immer noch 169 über keine geeigneten Fehlerdiagnose-
Einrichtungen verfügen, werden Komplikationen bei der Anbindung oft nicht bemerkt
und erst später bei der Benutzung des Gesamtsystems sichtbar. Fehler in der
Datenbankanbindung sind irreversibel und gehen immer mit einer vollständigen
Neuinstallation des Systems einher.
168 Vgl. IBM (2005) S. 177 ff.
169 Vgl. Altemeier (1995) „Fazit“
Realisation & praktische Evaluierung am Beispiel der Referenzumgebung
86
IBM Lotus Domino LDAP
Bei der Integration von IBM Lotus Domino als Verzeichnisdienst ist der jeweilige
Versionsstand der Domino-Installation relevant. Das vorliegende Szenario beinhaltet
ausschließlich Lotus Domino Server der Version 7.x. Für die Anbindung von Domino
Infrastrukturen mit der Version 6.5.x sind spezielle Anpassungen im Domino Directory
notwendig.170
Die Vorbereitung des Domino Servers für LDAP gliedert sich wie folgt:
1. Verwaltungskonten für Domino Directory erstellen.
2. E-Mail-Adressen für Domino Directory-Gruppen konfigurieren.
3. Schreibzugriff für das Domino Directory konfigurieren
4. Verzeichnisverwaltung und Schemata konfigurieren (Directory Assistance)
5. Volltextindex im Domino Directory erstellen.
6. Helper-File für Domino Directory bearbeiten.
7. LDAP-Sicherheit für Domino Directory aktivieren.
8. (Optional: Lesezugriff für Domino Directory konfigurieren)
Die Erstellung von Verwaltungskonten mit Schreibzugriffen ist für die Anbindung an
die WCS 2.6 zwingend erforderlich. Ein „nur lesender“ Zugriff reicht nicht aus und
verhindert das Starten der Workplace Collaboration Services. Nach erfolgreicher
Einrichtung kann nachträglich (siehe Schritt 8) der schreibende Zugriff wieder entfernt
werden.
Analog zur Anbindung eines DB2 DBMS stehen auch bei der Einrichtung von Domino
LDAP Diensten keine Installationsagenten zur Verfügung; alle erforderlichen
Konfigurationen müssen manuell vorgenommen werden.
Die Konfiguration der benötigten LDAP Schemata erfolgt über den Lotus Domino
Administrator Client und ist vergleichsweise unkompliziert.171
170 Vgl. IBM (2005) S. 119
171 Vgl. IBM (2005) S. 123 ff. und Abbildung 4-10 LDAP Schema Lotus Domino
Realisation & praktische Evaluierung am Beispiel der Referenzumgebung
87
Abbildung 4-10 LDAP Schema Lotus Domino
Die weiteren Installationsschritte beinhalten im Wesentlichen das Editieren einzelner
Textzeilen in verschiedenen Konfigurationsfiles. Auch hier muss auf die exakte Syntax
geachtet werden, da die WCS keine Diagnose falscher Einträge ermöglichen.
IBM HTTP Server
Die Anbindung eines externen HTTP Servers kann auch nach der Installation des WCS
Kernsystems erfolgen. Der WCS-integrierte Webserver verwendet für die
Kommunikation den TCP/IP Port 9081 und bleibt nach der Installation eines
ausgelagerten HTTP-Servers weiterhin aktiv. Wie bereits beschrieben, ist die
Auslagerung des HTTP Tasks nicht nur wegen der Performance, sondern auch für die
Anbindung der IBM Workplace Managed Client Technologie notwendig. Im Gegensatz
zu den anderen Application Offload Diensten wird die Installationsprozedur hierbei
weitestgehend durch automatisierte Abläufe unterstützt. Der IBM HTTP Server V6.x ist
bereits für die Integration in IBM WebSphere, und damit auch in die Collaboration
Services, vorbereitet. Während der Konfigurationsprozedur werden die erforderlichen
Einstellungen direkt aus dem WebSphere Verzeichnis eingelesen und automatisch
übernommen. Unregelmäßig kommt es hierbei zu Abbrüchen und Abstürzen, deren
Ursachen jedoch unbekannt bleiben.
Nach der Installation und Anbindung an die IBM WCS 2.5/2.6 muss der IBM HTTP
Server V6.0 auf die entsprechend neueren Versionen 6.0.2 und 6.0.2.1 angehoben
werden. Nach erfolgreicher Installation des externen IBM HTTP Servers und des WCS
Realisation & praktische Evaluierung am Beispiel der Referenzumgebung
88
Kernsystems erfolgt der Zugriff auf die Systemdienste der Collaboration Services nur
noch über den externen HTTP Server mittels des konfigurierten TCP/IP Ports 80.172
4.2.2.2 WebSphere Application und Portal Kernsystem
Die Installation des Kernsystems erfolgt auf dem Knoten ibmwp1.vegasystems.org auf
Basis des Betriebssystems Microsoft Windows 2003 Server.173 Die einzelnen
Installationsdateien müssen nicht mehr, wie bei der Vorgängerversion 2.5, einzeln
umbenannt und extrahiert werden. Danach erfolgt die Installation mit Hilfe von
textbasierten oder grafischen Konfigurationsassistenten.174 Eine Onlinehilfe ist für
keinen Schritt implementiert.
Der Name des WCS Kernsystems muss exakt dem DNS Namen des Rechners (und
damit der IP-Adresse) entsprechen. Eine Installation ohne Nameservice, und damit
zumindest virtueller „Internet-Anbindung“, ist nicht möglich. 175
Das System wird zuerst automatisch mit der eingebetteten IBM Cloudscape
Datenbankumgebung konfiguriert; die Anbindung eines (vorkonfigurierten) LDAP
Verzeichnisses und externen Webservers wird hingegen bereits während der
Erstinstallation angeboten. Die Auslagerung der relevanten Datenbanken wird zu einem
späteren Zeitpunkt durch einen Transfer von IBM Cloudscape auf die externe DB2
Instanz vollzogen.176
Bei jedem Schritt der Installation muss der Konfigurationsassistent schreibenden
Zugriff auf alle erforderlichen Systemelemente, wie den LDAP Server, das DB2 DBMS
und alle darunter liegende Dateisysteme, erhalten.
Bei jeder Ausführung des Konfigurationsassistenten werden Protokolldateien
("configwizard.log" und "configwizardlog.txt") im Verzeichnis "Portal_Server-
172 Vgl. Abbildung 4-11 Prototyp eSSL Architektur
173 Vgl. Kapitel 3.1.2 Anforderungen an die Systemarchitektur
174 Vgl. IBM (2005) S. 69 ff.
175 Vgl. Abbildung 4-11 Prototyp eSSL Architektur
176 Vgl. Kapitel 4.2.2.1 IBM DB2
Realisation & praktische Evaluierung am Beispiel der Referenzumgebung
89
Stammverzeichnis\log" erstellt. Diese enthalten jedoch oft nur JAVA-relevante Fehler,
die kaum Rückschlüsse auf die wirkliche Fehlerquelle erlauben.
Nach der erfolgreichen Installation lassen sich die Workplace Collaboration Prozesse
durch Batchdateien aufrufen, die nacheinander die Cloudscape Datenbank, den IBM
WebSphere Server, den integrierten Mailserver, die Portal Extensions und zuletzt die
Workplace Komponenten starten. Für jeden Start- und Stopvorgang werden
Protokolldateien angelegt, die umfangreich mit Java-Fehlermeldungen gefüllt werden.
Für Konfigurationsänderungen lassen sich die einzelnen Systemelemente auch separat
neu laden, um einen vollständigen Neustart des WCS System zu verhindern, da dieser
immer mit einem Zeitaufwand von mindestens 20 Minuten verbunden ist.177
Allerdings verlief der Neustart einzelner Dienste nicht immer reibungslos, da dieser oft
zu einer Entkoppelung der Elemente führte.
Abbildung 4-11 Prototyp eSSL Architektur
177 Zeitaufwand gemessen auf der angegebenen Hardware
Realisation & praktische Evaluierung am Beispiel der Referenzumgebung
90
4.2.2.3 IBM Workplace Managed Client
Für die Verwendung des Workplace Managed Clients (WMC) ist der vollständige
Abschluss aller vorherigen Schritte, insbesondere der Einrichtung des externen HTTP-
Servers, notwendig. Die Verteilung des Clients und aller relevanten Updates bzw.
Upgrades erfolgt durch den s.g. Provisioning Server. Dieser nutzt sowohl Teile des
WebSphere Portal Servers als auch des IBM HTTP Servers. Die Installationsdatei des
WMC wird in einem Unterpfad des .htdoc Verzeichnisses abgelegt, so dass der User
über die Weboberfläche „IBM Workplace“ direkten Zugriff auf diese erhält. Ebenso
werden Plugins und Extensions dort zum Download via HTTP bereitgestellt. Die
Steuerung aller Zugriffe, Sicherheitsmechanismen und Bereitstellungsprozesse
übernimmt jedoch der IBM WebSphere Portal Server. 178
Abbildung 4-12 WMC Connections
Die Authentifizierung aller Zugriffe wird durch den eingebundenen IBM Domino
Directory (Server) über das LDAP Protokoll verifiziert. Fällt der Zugriff auf das NAB
aus, ist keine Anmeldung, weder über das Webfrontend (Portal) noch über den WMC,
möglich. Alle Systemelemente arbeiten im Verbund und beinhalten keine gutartige
Redundanz an betriebsnotwenigen Daten.
178 Vgl. Abbildung 4-12 WMC Connections
Realisation & praktische Evaluierung am Beispiel der Referenzumgebung
91
Zum Abschluss der WMC-Integration müssen einige Systemvariablen, sowohl im
WebSphere Application- als auch Portalserver, editiert werden. Die Verwaltung aller
Managed Client Variablen und -Policies übernimmt die webbasierte WebSphere
Administrative Console über den TCP/IP Port 9091. Die Administrationsoberfläche des
Workplace Portal Frontends dient nur der Verwaltung der URL-Links zum Download
des WMC.179
4.3 Erfahrungen und Evaluierung der Systemarchitektur
Ziel dieser Arbeit ist die Konzeption und praktische Evaluierung einer J2EE-basierten
Systemarchitektur für kollaborative Serverdienste am Beispiel der Referenzumgebung
IBM Workplace Collaboration Services 2.6. In den voran gegangenen Kapiteln wurden
die möglichen Systemarchitekturen erörtert und voneinander abgegrenzt. Anschließend
wurde eine anforderungs- und rahmenbedingungskonforme Systemarchitektur
entwickelt und anhand der IBM Workplace Collaboration Services 2.6 umgesetzt.
Die folgenden Kapitel fassen die Erfahrungen mit der implementierten eSSL
Architektur kategorisiert zusammen und evaluieren die Umsetzung anhand des
Anforderungskataloges aus Kapitel 3.1.2 bzw. der Rahmenbedingungen aus Kapitel
3.1.1. Darüber hinaus wird der Kostenaufwand und der Installationsaufwand der
Umsetzung erörtert, da diese von essentieller Bedeutung für die abschließende
Evaluierung einer Systemarchitektur sind.
4.3.1 Stabilität und Verfügbarkeit für Produktivbetrieb
Die Stabilität des Gesamtsystems ist maßgeblich von der Verfügbarkeit der einzelnen
Systemelemente abhängig. Die eSSL Architektur der IBM Workplace Collaboration
Services konnte zwar der geforderten Mindestanzahl von parallelen Benutzern gerecht
werden, jedoch nicht der geforderten Stabilität und Verfügbarkeit. Dieses ist jedoch
nicht unmittelbar auf die Architektur selbst zurückzuführen, sondern vielmehr auf die
mangelhafte Implementierung der Schnittstellen zu den ausgelagerten Diensten.
179 Vgl. IBM (2005) S. 144, 262 ff.
Realisation & praktische Evaluierung am Beispiel der Referenzumgebung
92
4.3.2 Datensicherung und – wiederherstellung
Die Sicherung und Wiederherstellung der ausgelagerten Systemelemente stellt wegen
Ihrer Beschaffenheit, gerade in bestehenden (und gesicherten) Infrastrukturen, keine
Besonderheit dar. Es zeigte sich jedoch, dass eine reine Sicherung der
Datenbankanwendungen des DB2 Servers nicht ausreicht, da einige notwendige
Konfigurationen und Datenbestände innerhalb der IBM Cloudscape verbleiben. Somit
wird die Datensicherung des WCS Kernsystems komplexer. Es gelang zu keinem
Zeitpunkt eine komplette Wiederherstellung der IBM WCS aus den erstellten
Sicherungen; eine Neuinstallation (wenn auch mit Integration der gesicherten Daten)
war grundsätzlich notwendig. Diese Problematik beruht ebenfalls auf der nur teilweisen,
und damit inkonsequenten, Auslagerung der Datenbankelemente, was Rückschlüsse auf
eine eventuell unausgereifte Umsetzung innerhalb der WCS zulässt.
4.3.3 Integrationsfähigkeit in bestehenden Systemkontext
Die eSSL Architektur stellt die einzige Möglichkeit der Integration in bestehende
Systemarchitekturen dar. Mit der vorliegenden Umsetzung gelang die Mitbenutzung des
Domino Verzeichnisses zur Authentifikation und die Verwendung der bestehenden IBM
DB2 UDB Installation als DBM-System für die WCS. Der Systemverwalter verfügt
jedoch noch über zu wenige Mechanismen zur Kontrolle und Fehlerdiagnose zur
effektiven Anbindung von bestehenden Diensten. Eine Integration ist möglich, jedoch
bei der vorliegenden WCS Version 2.6 nur mit extrem hohem Aufwand und unter
vorauszusetzenden, fundierten Kenntnissen des Administrators.
„It is helpful if someone with advanced knowledge of (…) concepts and administration
who is familiar with your (…) environment is responsible for connecting to external
servers.”180
4.3.4 Administrierbarkeit und Wartungsaufwand
Die Verwaltung der zentralen IBM WCS Komponenten entspricht im Aufwand und in
der Komplexität der Administration der Single Server Lösung. Durch die Auslagerung
der DBMS-, Verzeichnis- und HTTP-Dienste wird das Überwachen aller Elemente
zunehmend unübersichtlicher und komplexer. Da IBM keine zentrale
180 Vgl. IBM (2005) S. 26
Realisation & praktische Evaluierung am Beispiel der Referenzumgebung
93
Verwaltungsschnittstelle oder Administrationsoberfläche für alle Elemente bereitstellt,
ist der Zeitbedarf für die Kontrolle und Erweiterung um ein Vielfaches höher als in der
reinen Single Server Lösung.
Da in keinem Fall eine zentrale Speicherung von Fehlermeldungen erfolgt, und die Art
der gegebenen Warnmeldungen keine Interpretation über Fehlerquellen ermöglicht, ist
eine angemessene Reaktion der Administration auf mögliche Probleme ausgeschlossen.
Da kaum Verwaltungsautomatismen zur Verfügung stehen müssen viele Einstellungen
in Konfigurationsdateien der einzelnen Systemelemente vorgenommen werden, was
durch den strikten Syntax-Zwang als teilweise unzumutbar eingestuft werden kann.
4.3.5 Kostenaufwand
Die Kosten für eine eSSL-Architektur sind stark abhängig von der vorhandenen
Infrastruktur und den damit vorhandenen Systemelementen.
Existiert keine Infrastruktur, müssen für jeden ausgegliederten Dienst neue Hardware-
Ressourcen bereitgestellt werden. Je nach Anzahl der (synchron) zu versorgenden
Clients ergeben sich verschiedene Hardwareanforderungen. Bei der vorliegenden eSSL
Implementation werden die erforderlichen Dienste auf vier (4) unterschiedliche Server
ausgelagert; die DBMS-, HTTP-, und Verzeichnisdienste erhalten jeweils eine eigene
Serverhardware.181
Sind bereits andere Dienstanbieter im Netzwerk vorhanden (wie vorliegend IBM Lotus
Domino für LDAP, DB2 als DBMS), können diese mitbenutzt werden, was die
Installationskosten für Hardwareanschaffungen reduziert.
Die Anschaffungskosten für Server-Hardware vervielfachen sich durch die Mehrzahl
(3) an Servern um den Faktor 3. Da die weitere Hardware nicht die gleich hohen
Anforderungen wie die der IBM WCS erfüllen muss, kann dort auf Standard Server
zurückgegriffen werden. Die Verteilung der Dienste entlastet den Kern-WCS Server
jedoch nur geringfügig, so dass die Hardwareanforderungen des WCS-Kernsystems
durch das ESSL Konzept kaum sinken. 182
181 Vgl. Abbildung 4-11 Prototyp eSSL Architektur
182 Vgl. Abbildung 4-13 Hardwareanforderungen eSSL
Realisation & praktische Evaluierung am Beispiel der Referenzumgebung
94
Abbildung 4-13 Hardwareanforderungen eSSL
4.3.6 Installationsaufwand
Die Installationsroutinen der IBM WCS 2.6 sehen eine automatische Verteilung der
Dienste auf mehrere Server weiterhin nicht vor. Das Verteilen der Software und die
Verknüpfen dieser Komponenten müssen manuell vorgenommen werden. Die IBM
Workplace Collaboration Services bieten keine vollständigen Routinen zum Einbinden
der vorhandenen Ressourcen; es werden lediglich spärliche Hilfestellungen und
Verweise auf die Dokumentation gegeben. Die eigentliche Einbindung von
vorhandenen Ressourcen erfolgt, wie beschrieben, manuell durch Einrichten von
Schnittstellen und durch die Anpassung von zentralen und ausgelagerten Diensten (z.B.
LDAP Field Mapping in Lotus Domino und WebSphere Application Server).
Die Installation stellt hohe Anforderungen an den Kenntnisstand des Administrators und
verlangt interdisziplinäres Wissen. Ist dieses nur unzureichend vorhanden, muss viel
„geraten und gehofft“ werden, da die Produktdokumentation nur wenig Hilfe leistet.
Zusammenfassung und Fazit
95
5 Zusammenfassung und Fazit
Die IBM Workplace Collaboration Services 2.6 zeigen neue Möglichkeiten der
Produktgestaltung durch Konjunktion bestehender Softwarekomponenten. IBM hat mit
den WCS eine neue Lösung geschaffen, ohne bestehende Kompetenzen (IBM
WebSphere, IBM WebSphere Portal) auszugrenzen und durch neue Entwicklungen zu
ersetzen. Dieses Konzept greift jedoch nur zum Teil, da die hohe Integration der
einzelnen Komponenten weiterhin noch nicht vollständig gelingt.183
Die IBM WCS 2.6 hinterlassen, insbesondere beim Systemverwalter, den Eindruck
eines unfertigen Produktes. Die Version 2.6 ist derzeit weder fehlerfrei zu installieren
noch zu betreiben. Da das Produkt fast ausschließlich in der Programmiersprache JAVA
entwickelt worden ist, leidet dieses, in dem vorliegenden Programmcode, deutlich unter
Performanceeinbußen und benötigt durch die Vollintegration von WebSphere- , Portal-
und Workplace-Server Hardwarevoraussetzungen, die über heutige „Standard-Server“
weit hinaus gehen. Weiterhin wird keine Möglichkeit der effizienten Fehlerdiagnose
geboten. Installationsassistenten zur Konfliktmeidung fehlen.
Durch die vorliegende prototypische Installation konnten die Erwartungen an die
erweiterte Single Server Lösung nur zum Teil bestätigt werden. IBM wird dem
Integrationswunsch zwar gerecht, verwendet derzeit aber den
Hauptentwicklungsaufwand auf die sichtbaren Module des Systems. Die Frontend-
Funktionalitäten und Portalkomponenten sind grafisch ansprechend gelungen, dem
System fehlt es jedoch massiv an Backendintegrität. Das Application Offload gelingt
somit nur mit Mühe und ist als instabil einzustufen.
Die implementierte eSSL-Architektur konnte den Anforderungen bei gegebenen
Rahmenbedingungen zwar gerecht werden und den Mitarbeitern und Studenten der
Universität Paderborn eine Plattform zur Evaluierung zukünftiger Technologien bieten,
die Erwartungen bezüglich Performance und Stabilität jedoch nur unzureichend
erfüllen.
Die erweiterte Single Server Lösung wird jedoch dem Grundgedanken kollaborativer
Systemarchitekturen gerecht und ist, produktunabhängig gesehen, durch die
Integrationsfähigkeit und Lastverteilung auf mehrere Systeme die einzig sinnvolle
183 Siehe auch: Altemeier(2005)
Zusammenfassung und Fazit
96
Lösung für zukünftige J2EE-basierte Serverdiensten. Java-Anwendungen benötigen
vergleichsweise viele Systemressourcen, die durch die Auslagerung von Diensten
(zumindest teilweise) wieder zur Verfügung stehen. Ein weiter Ausweg aus der
Ressourcenknappheit ist, neben der Anschaffung immer leistungsfähigerer Hardware,
die Erweiterung der eSSL um das Network Deployment.
Die IBM Workplace Collaboration Services gehen hierbei den richtigen Weg und
erlauben einen Ausblick auf zukünftige Realisationswege. Viele Möglichkeiten der
Skalierung werden berücksichtigt und die Wahl der geeigneten Systemarchitektur
bedacht.
Viele der genannten Problematiken mit der Realisierung der eSSL-Architektur sind auf
die unausgereifte Umsetzung des „Additions-Konzeptes“ der WCS-Einzelelemente
zurückzuführen und sind kein Grundproblem der entwickelten Systemarchitektur. Die
IBM WCS 2.6 bestehen aus einer aufwändigen Symbiose komplexer Teilkomponenten,
die auch in der aktuellen Version wieder keine Vollendung gefunden haben.
Ziel dieser Arbeit war die die Konzeption und praktische Evaluierung einer J2EE-
basierten Systemarchitektur für kollaborative Serverdienste am Beispiel der
Referenzumgebung IBM Workplace Collaboration Services 2.6. Zu den Ergebnissen
der Konzeption zählen die Erörterung geeigneter Systemarchitekturen, das Modell zum
Architekturaufbau, die Auswahl geeigneter Grundkonzepte und die Modellierung der
geeigneten eSSL Architektur. Auf diesen Grundlagen wurde die entwickelte
Systemarchitektur anhand einer praktischen Evaluierung mit der Referenzumgebung
IBM Workplace Collaboration Services verifiziert.
Ausblick
97
6 Ausblick
Die erarbeiteten Lösungen bieten eine Grundlage für zukünftige Studien, die es zum
Ziel haben, offen gebliebene Fragestellungen zu bearbeiten und spezifische Aufgaben-
bereiche zu erweitern. So existiert weiterer Forschungsbedarf in der zusätzlichen
Performancesteigerung durch Clustertechnologien, die aufgrund zu geringer
Serveranzahl in dieser Arbeit nicht betrachtet werden konnte. Diese Arbeit spiegelt vor
allem die Erfahrungen mit der erweiterten Single Server Lösung (eSSL) wider und geht
nur konzeptionell auf das Network Deployment ein. Ein zukünftiger
Forschungsgegenstand kann somit die Kombination der eSSL mit den Vorteilen des
Networkdeployment darstellen. Sind in Zukunft geeignete Hardwareressourcen
vorhanden, wird das Networkdeployment dazu beitragen können, J2EE-basierte
kollaborative Dienste einer Vielzahl an Benutzern performant und stabil zur Verfügung
zu stehen um somit die tägliche kollaborative Arbeit einfacher und produktiver zu
gestalten.
Literaturverzeichnis
98
7 Literaturverzeichnis
Referenz-Indizes: Dokument im PDF Format (im Anhang) Buch, Zeitschrift, sonstige Printmedien
Original IBM Dokumente (Whitepapers, Drafts, Readme) IBM Redbooks / IBM Redpapers
Altemeier (2005)
Altemeier, Tobias: Konzeption eines Best Practice Guide zur Administration einer IBM
Workplace Infrastruktur, Paderborn, 2005
Alur et al. (2003)
Alur, Nagaj; Falos, Amy; Lau, Ada; Lindquist, Svante; Varghese, Monzy: DB2
UDB/WebSpere Performance Tuning Guide, IBM Press, 2003
Alur et al. (2004)
Alur, Nagraj; Farrel, Peter; Gunning, Philip; Mohseni, Saeid; Rajagopalan,
Swaminaathan: DB2 UDB ESE V8 non-DPF Performance Guide for High Performance
OLTP and BI, IBM Press 2004
Bai et al. (2004)
Bai, Jiong Xin; Davis, Kit; Gereci, Mario; Richerzhagen, Michael; Seshasai, Satwiksai;
Tworek, William: Lotus Workplace release 2.0.1 products and Lotus Domino 6.5.x
Together Integration Handbook, 2004
Baklarz et al. (2003)
Baklarz, George / Melnyk, Roman / deRoos, Dirk / Zi, Paul: DB2® Version 8, The
Official Guide , 2003
Literaturverzeichnis
99
Barent et al. (1994)
Barent, Volker; Gräslund, Karin; Schwabe, Gerhard: Datenbankunterstützung für
Groupware. In: Datenbank-Management: Aktuelles Nachschlagewerk der
systemunabhängigen Datenbankpraxis, WEKA Fachverlag für EDV, Augsburg 1994
Barry (2005)
Devin, Barry: Te evolution of office work- part 1 – IBM Workplace stategy (2005)
Bauer (2001)
Bauer, H. (2001): Unternehmensportale – Geschäftsmodelle, Design, Technologien.
Galileo Business Verlag, Bonn.
Boering et al. (2006)
Boering, Ingo; Chenthamarakshan, Vijjl; Johnston, Trevor; Kilmon, Shane: IBM
Workplace Managed Client 2.6 on Linux, IBM, 2006
Bravo et al. (2005)
Bravo, Alberto; Chadbourne, Greg R.; Luz, Carlos; Monson, Philip; Mueller, Heiko;
Savov, Tatjana, Slone, Jeffrey: Lotus Workplace 2.01 Products: Deployment Guide,
IBM Press, 2005
Brown (2002)
Brown, D.H: IBM DB2 Universal Database vs. Oracle 9i: Total Cost of Ownership,
Jan. 2002
Literaturverzeichnis
100
Carter (2003)
Carter, Gerald: LDAP System Administration, O'Reilly Media, Sebastopol 2003
Chadwick (1996)
Chadwick, David W.: Understanding X.500 – The Directory (out of print)
http://sec.cs.kent.ac.uk/x500book/ , 1996 (17.06.2006)
Chamberlin (1999)
Chamberlin, Don: DB 2 Universal Database - Der unentbehrliche Begleiter, 1999
Chen et al. (2003)
Chen, Whei-Jen; Beaton, Angus; Kline, David; Johnson, Glen: DB2 UDB Evaluation
Guide for Linux and Windows, IBM Press, 2003
Chen et al. (2004)
Chen, Whei-Jen; Mungale, Ajit; Raymundo, Carlos; Thuering, Andreas: DB2 UDB
V8.2 on the Windows Environment, IBM Press, 2004
Claus, Schwill (1993)
Claus, Voker; Schwill, Andreas: Duden Informatik, B.I-Wissenschaftsverlag, 1993
Codd (1970)
Codd, E.F.: A relational model of data for large shared data banks. In: Communications
of the ACM. 1970.
Literaturverzeichnis
101
Dahn et al. (2005)
Dahm, Frederic; Ryan, Paul; Schwartz, Richard; Smith, Amy; Stalder, Dieter: Security
Considerations in Notes and Domino 7, IBM, 2005
Devlin (2005)
Devlin, Barry: The evolution of office work Part 1—IBM® Workplace™ strategy, 2005
Donskoj, Knäpper, Perc (2004)
Donskoj, Markus; Knäpper, Matthias; Perc, Primoz: Anwendungsentwicklung unter
Lotus Notes Domino 6.5, Addison-Wesley, München 2004
Ebel (2005)
Ebel, Nadin: WebSphere / Domino Workplace Administration, Addison-Wesley,
München 2005
Fischer et al. (2000)
Fischer, Joachim; Herold, Werner; Dangelmaier, Wilhelm; Nastansky, Ludwig; Suhl,
Leena: Bausteine der Wirtschaftsinformatik, 2. Aufl., Berlin 2000
Gurzki, Hinderer (2003)
Gurzki, T., Hinderer, H.: Eine Referenzarchitektur für Software zur Realisierung von
Unternehmensportalen. Tagungsband WM 2003: Professionelles Wissensmanagement –
Erfahrungen und Visionen. Ulrich Reimer, Andreas Abecker, Steffen Staab, Gerd
Stumme (Hrsg.), GI-Edition - Lecture Notes in Informatics (LNI). Bonner Köllen
Verlag, Bonn 2003
Literaturverzeichnis
102
Hasenkamp et. al (1994)
Hasenkamp, Ulrich; Kirn, Stefan; Syring, Michael: CSCW – Computer Supported
Cooperative Work. 1. Auflage, Addison Wesley GmbH, Bonn 1994
Hennessy et al. (1994)
Hennessy, John L.; Patterson, David A.: Rechnerarchitektur: Analyse, Entwurf,
Implementierung, Bewertung. Vieweg, Braunschweig 1994
Herold (2004)
Herold, Helmut: Linux/Unix-Grundlagenreferenz - Die wichtigsten Kommandos und
typische Anwendungsfälle, München 2004
Heuer, Saake (2000)
Heuer, Andreas; Saake, Gunter: Datenbanken: Konzepte und Sprachen, 2., aktualisierte
und erweiterte Auflage, Bonn, 2000
Holmquist, Falk, Wigström (o.J)
Homquist, Lars Erik; Falk, Jennica; Wigström, Joakim: Supporting Group
Collaboration with Inter-Personal Awareness Devices
IBM (2004)
IBM o.V: IBM HTTP Server V2 Manual, IBM Press, 2004
IBM (2005)
IBM o.V.: Workplace Collaboration Services 2.6 - Single-Server Deployment Guide,
IBM Press, 2005
Literaturverzeichnis
103
IBM (2005 b)
IBM o.V.: Workplace Collaboration Services 2.6 - Cluster-Server Deployment Guide,
IBM Press, 2005
IBM (2006)
IBM o.V.: Workplace Collaboration Services 2.6 –Release Notes, IBM Press, 2006
IBM (2006 b)
IBM o.V.: Workplace Collaboration Services 2.6 – Browser Client User Guide, IBM
Press, 2006
IBM (2006 c)
IBM o.V.: Workplace Managed Client 2.6 – User Guide, IBM Press, 2006
IBM (2006 d)
IBM o.V.: IBM Workplace Collaboration Services 2.6 Information Center; Build:
February 15, 2006
Künter, Laser (2003)
Klünter, Dieter; Laser, Jochen: LDAP verstehen, OpenLDAP einsetzen. Grundlagen,
Praxiseinsatz, Single-sign-on-Systeme, Dpunkt Verlag Heidelberg 2003
Kuppinger (2003)
Kuppinger, Martin: Windows Server 2003 – Das Handbuch, Microsoft Press
Deutschland, 2003
Literaturverzeichnis
104
Landon et al. (2005)
Landon, Deb; Bloom, Jenniver; Burston, Neil; Byrd, David; Donato, Tony; Guidera,
Mac; Guirigay, Luis; MecCauley, Martin; Milstein, Steve; Piza, Jazmin; Stamp, Colin;
Tallackson, Trevor: Deploying IBM Workplace Collaboration Services on the IBM
iSeries Server, IBM, 2005
Levitt, Mahowald (2002)
Levitt, Mark; Mahowald; Robert P.: There Should be More to Collaboration than Email
(2002). Aus: http://www.groove.net/pdf/idc-collaboration.pdf am 23.06.2006
Lockemann (o.J.)
Lockemann, C. Peter: Information System Architectures: Form Art to Science;
Universität Karlsruhe, Falkultät für Informatik
Lotus (1995)
Lotus o.V.: Groupware - Communication, Collaboration, Coordination (1995). Aus:
http://gcc.upb.de/www/WI/WI2/wi2_lit.nsf/0/5098c20fcf549d15412564ca00333bc2/$F
ILE/Groupwar.pdf am 02.06.2006
Love (2005)
Love, Robert: Linux-Kernel-Handbuch - Leitfaden zu Design und Implementierung von
Kernel 2.6 , 2005
Middendorf et al. (2002)
Middendorf, Stefan; Singer, Reiner; Heid, Jörg (2002): Java – Programmierhandbuch
und Referenz für die Java – 2 – Plattform, http://www.dpunkt.de/java/index.html,
dpunkt.Verlag 2002 (Webreferenz 21.06.2006)
Literaturverzeichnis
105
Monson et al. (2005)
Monson, Philip; Savov, Tatjana; Dussourd, Edward; Rousseaux, Miachel; Koch,
Barbara: IBm Workplace Collaboration Services: Release 2.5 Deployment Guide, 2005
Monson et al. (2005 b)
Monson, Philip; Bry, Robert; Scouller, David; Marchetti, Gianluigi; Kantor, Katinka;
O’Connel, Margaret; Opot, Evans: IBM Workplace Services Express, 2005
Monson et al. (2005 c)
Monson, Philip; Clark, Jane; Mikkolainen, Kalle; Shalabi, Sami: Building a Component
for IBM Workplace, IBM, 2005
Monson et al. (2005 d)
Monson, Philip; Ott, Lori; Shah, Nishant; O´Sullivan, Shane: IBM Workplace Managed
Client - ISV Integration Guide, IBM, 2005
Nastansky et al. (2000)
Nastansky, Ludwig; Bruse, Thomas; Haberstock, Philip; Huth, Carsten; Smolnik, Ste-
fan: Büroinformations- und Kommunikationssysteme: Groupware, Workflow Manage-
ment, Organisationsmodellierung und Messaging-Systeme. In: Bausteine der Wirt-
schaftsinformatik. Hrsg.: Fischer, Joachim; Herold, Werner; Dangelmaier, Wihlhelm;
Nastansky, Ludwig; Suhl, Leena, 2. Auflage, Erich Schmidt Verlag GmbH & Co., Ber-
lin 2000, S. 235-322
Olle (1978)
Olle, T. William: The Codasyl Approach to Data Base Management. Wiley, 1978,
Literaturverzeichnis
106
Policht, Shapiro (2004)
Policht, Marcin / Shapiro, Jeffrey: Building High Availability Windows Server 2003
Solutions, 2004
Rahul et al. (2000)
Sharma, Rahul; Stearns, Beth; Ng, Toni: J2EE Connector Architecture and Enterprise
Application Integration. Addison Wesley 1. Dezember 2000
Radtke (2002)
Radtke, Stefan: System Authentication for AIX and Linux using the IBM Directory
Server, IBM Server Group, 2002
Roehm et al. (2004)
Roehm, Birgit; Cseprgi-Horvath; Gao, Pingze; Hikade, Thomas; Holecy, Moroslav:
IBM WebSpere V5.1 Performance, Scalability, and High Availability, 2004
Rütschlin (2001)
Rütschlin, J. (2001): Informatik 2001: Wirtschaft und Wissenschaft in der Network
Economy – Visionen und Wirklichkeit. Tagungsband der GI/OCG-Jahrestagung, 25.-
28. September 2001, Universität Wien,
Sadtler et al. (2005)
Sadtler, Carla; Laursen, Lars Bek; Philips, martin; Sjostrand, Henrik; Smithson, Martin;
Wan, Kwan-Ming: WebSphere Application Server V6 – System Management and
Configuration Handbook, IBM Press, 2005
Literaturverzeichnis
107
Sadtler et al. (2005 b)
Sadtler, Carla; Griffith, Kevin; Hu, Daniel, Marhas, Dildar: WebSphere product
overview, IBM Press, 2005
Shannon (2000)
Shannon, Bill; Hapner, Mark; Matena, Vlada: Java 2 Platform, Enterprise Edition.
Addison Wesley 2000
Slone, Jeffrey (2004)
Slone, Jeffrey; Tworek, William: Lotus Workplace Messaging Administration Guide
(2004)
Smith et. al. (2002)
Smith, Brian R.; Banchelli, Gaia; Echeverry, Monika Maria; Lachmann, Axel: A
Feature Based Comparison between HTTP Server (original) and HTTP Server (powered
by Apache), 2002
Tabeling (2006)
Tabeling, Peter: Softwaresysteme und ihre Modellierung, 1.Auflage, Heidelberg 2006
Tanenbaum, van Steen (2003)
Tanenbaum, Andrew; van Steen, Marten: Verteilte Systeme - Grundlagen und Paradig-
men. 1. Auflage, Pearson Studium, München 2003
Theisen (1992)
Theisen, Manuel R.: Wissenschaftliches Arbeiten: Technik - Methodik - Form, 6.,
überarbeitete und aktualisierte Auflage, Paderborn, 1992
Literaturverzeichnis
108
Tierling (2005)
Tierling, Eric: Windows Server 2003 - Einrichtung, Verwaltung, Referenz, 2005
Wilczek, Krcmar (2001)
Wilczek, Stephan; Krcmar, Helmut: Betriebliche Groupwareplattformen. In: CSCW -
Kompendium. Hrsg.: Schwabe, G.; Streitz, N.; Unland, R., Springer, Berlin 2001
Xin Bai et al. (2004)
Xin Bai, Jiong; Davis, Kit; Gereci, Mario; Richerzhagen, Michael; Seshasai, Satwiksai;
Tworekt, William: Lotus Workplace release 2.01 products and Lotus Domino 6.5.x
Together – Integration Handbook (2004)
Eidesstattliche Erklärung
109
Eidesstattliche Erklärung
Ich erkläre hiermit an Eides Statt, dass ich die vorliegende Arbeit selbständig und nur
unter Verwendung der angegebenen Hilfsmittel angefertigt habe, die aus fremden
Quellen direkt oder indirekt übernommenen Gedanken sind als solche kenntlich
gemacht.
Die Arbeit wurde bisher keiner anderen Prüfungsbehörde vorgelegt und auch noch nicht
veröffentlicht.
Paderborn, den . . . . . . . . . . . . . . . . . . . . . . . . . . .
(Datum) (Unterschrift)
Anhang
110
Anhang
Auf der beiliegenden CD befindet sich folgende Literatur im PDF Format:
Alur et al. (2003)
Alur et al. (2004)
Bai et al. (2004)
Barry (2005)
Boering et al. (2006)
Bravo et al. (2005)
Brown (2002)
Chadwick (1996)
Chen et al. (2003)
Chen et al. (2004)
Dahn et al. (2005)
Devlin (2005)
Holmquist, Falk, Wigström (o.J)
IBM (2004)
IBM (2005)
IBM (2005 b)
IBM (2006)
IBM (2006 b)
IBM (2006 c)
IBM (2006 d)
Landon et al. (2005)
Levitt, Mahowald (2002)
Lockemann (o.J.)
Lotus (1995)
Monson et al. (2005)
Monson et al. (2005 b)
Monson et al. (2005 c)