Diplomarbeit Tobias Altemeier V1 3 Word2007 - gcc.upb.degcc.upb.de/www/WI/WI2/wi2_lit.nsf/7544f3043ee53927c12573e70058bbb6/8e3... · Diplomarbeit Konzeption und praktische Evaluierung

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

2

In Liebe und Dankbarkeit

meiner Frau Kerstin

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

Einleitung

5

Abbildung 1-1 Aufbau der Arbeit

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


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.


6 Vgl. Hennessy, Patterson: (1994) S. 16 f.


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


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


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.



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)


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”


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


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


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


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)


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.


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


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


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.


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.


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


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


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.


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


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


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.


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/


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.


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


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


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


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)


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


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.


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


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)


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.


71 Vgl. Altemeier (2005): Konzeption eines Best Practice Guide zur Administration einer IBM Workplace

Infrastruktur


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


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“


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


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)


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


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)


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


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.


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


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.


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.


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


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.


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


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


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.


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


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.


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.


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


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.


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.


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.


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.


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.


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


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


105 Siehe auch: Lockemann (o.J.) S. 1

106 Vgl. IBM (2005 b) S. 1


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


108 Vgl. Altemeier (2005) S. 25

109 Vgl. Bai et al. (2004) S. 47 ff.


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.“


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.


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.


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.


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.


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


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)


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.


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.


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


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)


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.


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


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


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.


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


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.


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


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


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


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


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


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


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.


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


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


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)


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


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)


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“


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


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


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.


176 Vgl. Kapitel 4.2.2.1 IBM DB2


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


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


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.


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


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


182 Vgl. Abbildung 4-13 Hardwareanforderungen eSSL


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


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


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.


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


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


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


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)


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,


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


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


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)

Anhang

111

Monson et al. (2005 d)

Radtke (2002)

Roehm et al. (2004)

Sadtler et al. (2005)

Sadtler et al. (2005 b)

Slone, Jeffrey (2004)

Smith et. al. (2002)

Xin Bai et al. (2004)