Aussenpräsentation und Anwendungsintegration

Transcription

IBM WebSphere Software, Hochschulen Nordrhein-Westfalen
Aussenpräsentation und Anwendungsintegration
Der IBM WebSphere Portal Server als integrierte Hochschulplattform
Grobkonzept, Vorgehensweise, Aufwand
Version 1.00
Dr. Volker Klingspor, Software Architekt
[email protected]
SerCon GmbH Dortmund
Michael Stupp, WebSphere Sales Specialist
[email protected]
IBM Deutschland GmbH
Thomas Ehlert, WebSphere Sales Specialist
[email protected]
IBM Deutschland GmbH
Inhaltsverzeichnis
1
Management Summary
3
2
Zielsetzung und Umfang des Konzeptes
6
3
Einleitung
7
4
Anforderungen an eine ganzheitliche Portallösung im Hochschulumfeld
10
4.1
Personalisierung
10
4.2
Anwendungsintegration
12
4.3
Kollaboration und Kommunikation
16
4.4
Inhalt und Suche
20
4.5
Weitere Funktionalitäten
24
5
Markt- und Technologiebetrachtung
26
5.1
Marktbetrachtung
26
5.2
Technologiebetrachtung
28
6
Investitionen für die Realisierung
35
6.1
Projektvorgehen
35
6.2
Potentielle Rollen innerhalb eines Hochschulportals
37
6.3
Detallierte Use Cases
38
6.4
Allgemeine Hardwarebetrachtung
49
6.5
Enthaltene Softwarekomponenten
51
7
Zusammenfassung
52
8
Abbildungsverzeichnis
53
Stand:26.09.03
IBM / Hochschulen NRW confidential
2 von 53
1 Management Summary
An den Hochschulen wurde erkannt, dass die Verbesserung der Services für die Benutzergruppe der Studierenden eine unabdingbare Komponente zur Sicherung des
Bildungsstandortes darstellt.
Die Themen Aussenpräsentation und Anwendungsintegration wurden in verschiedenen
Gesprächen und Workshops mit den Hochschulen als übergreifende Use Cases zur Erfüllung dieser Forderung vor dem Hintergrund folgender Überlegungen identifiziert:
Die Hochschule möchte talentierte Neustudierende gewinnen, diese zu einem hochqualifizierten Abschluss führen und auch nach der Studienzeit z.B. durch spezielle Alumniprogramme an sich binden, um dadurch die Grundlage für steigende Reputation und institutionelle Förderung zu schaffen.
Auf dem Weg vom Talent über den guten Studierenden bis hin zum erfolgreichen Absolventen stellt eine zielgruppengerechte Informationsversorgung eine immense Entlastung
dar. Mit Hinblick auf die Themen Anwendungsintegration und Aussenpräsentation befreit
eine zentralisierte Hochschulplattform im Sinne eines „One face to the Student“ den Lernenden von lästigen und zeitraubenden Routinearbeiten und gibt ihm somit mehr Zeit für
seine Kerntätigkeit - das Studieren.
Abbildung 1: Exemplarische Darstellung eines Portals als Hochschulplattform
Stand:26.09.03
3 von 53
Im Alltag der Hochschulen finden wir jedoch - wie auch durchaus in der Industrie - fragmentierte Infrastrukturen vor, die sich zwar moderner Techniken bedienen, aber anstelle
einer einheitlichen, hochschulübergreifenden Webplattform eher eine unübersichtliche
Menge fachbereichsspezifischer Einzelauftritte darstellen. Durch das historisch bedingte
Wachstum sind Informationssilos entstanden, die es den Mitarbeitern und Studierenden
erschweren, die für sie relevanten Daten schnell zu finden. Diese Problematik wird durch
die ständig zunehmende Informationsflut zusätzlich verstärkt.
Damit die ursprünglichen Erwartungen an das Internet, die Informationsflüsse zu verbessern, dennoch erfüllt werden können, müssen die Hochschulen entsprechende Lösungen entwickeln, die die vorhandenen Inhalte aggregieren und konsolidieren sowie einen
plattformübergreifenden Zugriff verbunden mit einer plattformübergreifenden Suche
ermöglichen.
Ebenso wie das historische Wachstum vieler Fachbereichsinternetauftritte haben sich
auch die Anwendungen im Laufe der Zeit vermehrt und somit zu einer heterogenen ITLandschaft in den Hochschulen geführt. Die Erweiterung, Aktualisierung und Pflege
einer Vielzahl unterschiedlicher Software-Produkte verstärkt den Druck auf immer knapper werdende IT- und Fachbereichsbudgets durch den erhöhten Administrationsaufwand
zwangsläufig und steht damit gleichzeitig den erhofften Einsparungseffekten einer ITInvestition entgegen.
Um diesen Missständen Abhilfe zu verschaffen, hat sich in jüngster Zeit unter Verwendung von „state of the art“-Technologien eine Anwendungsform entwickelt, die unter dem
Begriff „Portal“ geführt wird. Oft wurde dieser Begriff nur für Teilaspekte dessen benutzt,
was ein Portal ausmacht. Um jedoch dem oben skizzierten umfassenden Anspruch gerecht zu werden, muss ein Portal folgender Definition genügen:
Ein Portal ist eine auf Web-Technologien basierende Applikation, die einer bestimmten
Zielgruppe (Studierende, Lehrende, Verwaltungsangestellte, Ehemalige, Gäste, Partner,
Lieferanten) einen zentralen und personalisierten Zugang zu Informationen, Anwendungen und Prozessen ermöglicht und die Kommunikation aller Beteiligten forciert.
Als neue Integrationsform fasst ein Portal die existierenden unterschiedlichen Informationsquellen und Applikationen der Hochschule zusammen und stellt diese dem Endbenutzer kanalisiert zur Verfügung. Hierbei werden sowohl die bereits getätigten Investitionen gesichert als auch die gewünschte Flexibilität hinsichtlich zukünftiger Anforderungen
erreicht. Unter Beachtung bestimmter IT-technischer Rahmenbedingungen können sämtliche Hochschulservices über das Portal integriert werden. Das Portal kann als modularer
Baukasten verstanden werden.
Im Gesamtzusammenhang der Software Generallizenz für die Hochschulen in NRW
bedeutet dies, dass basierend auf einem einheitlichen User Management (Tivoli Identity
Management) bestehende Anwendungen, aber auch neue Anwendungen wie Dokumenten Management Systeme (IBM Content Manager) und e-Learning Systeme (Lotus
Learning Management System) in den Gesamtkontext des Portals integriert werden kön-
Stand:26.09.03
4 von 53
nen und somit zum Gesamterfolg des Portals als Hochschulplattform beitragen: Der Studierende braucht sich nur einmal an dieser Plattform anzumelden und bekommt
sämtliche Informationen, Applikationen und Services zur Verfügung gestellt, die er zur
Bewältigung seiner täglichen Aufgaben als Studierender benötigt.
In den Diskussionen und Workshops mit den beteiligten Hochschulen wurden rund 30
Hochschulservices und -funktionalitäten herausgearbeitet, die sich unter den Use Cases
„Aussenpräsentation und Anwendungsintegration“ subsumieren lassen.
Hierbei haben wir anhand der Nennungen bzw. anhand der Vielzahl der nachgeordneten
Unterfunktionen folgende Schwerpunkte herausgearbeitet:
•
Personalisierung (Individuell zugeschnittene Dienste: Prüfungsinformationen,
Bibliotheksprofil, Vorlesungsverzeichnis)
•
Kollaboration / Kommunikation (Teamräume, Diskussionsforen, e-Mail, Terminmanagement: Vereinheitlichung unterschiedlichster Terminquellen wie z.B. Asta-,
Fachbereichs- und Hochschulkalender mit Übernahmemöglichkeit in den persönlichen Terminkalender; Notifikation bei Ausfall/Verlegungen; webbasierte Terminabsprache bei Sprechstunden)
•
Inhaltsmanagement / Web Content Management (Konsolidierung unterschiedlicher Datenquellen unter Erhaltung der Fachbereichsautorität) und hochschulweite Metasuche
•
Anwendungsintegration (Formen der Einbindung hochschulinterner und -externer
Services, wie z.B. HIS, e-Learning, Newsticker, Wetter, ÖPNV, JobBörse,
Amazon.com)
Eine genauere Betrachtung dieser Services und die jeweilige Unterstützung durch den
IBM WebSphere Portal Server (WPS) ist Inhalt des nachfolgenden Konzepts.
Stand:26.09.03
5 von 53
2 Zielsetzung und Umfang des Konzeptes
Zielsetzung dieses Konzepts ist es, für die in den Gesprächen mit den Hochschulen
herausgearbeiteten Prozesse „Aussendarstellung und Anwendungsintegration“, IT-gestützte Umsetzungsmöglichkeiten zu beschreiben.
Das Konzept stellt zunächst die hierfür in Frage kommenden Technologien vor und
bringt sie anschliessend - unter Berücksichtigung der spezifischen Befindlichkeiten - in
den hochschuleigenen Kontext.
Ein Mapping auf die in dem marktführenden Produkt IBM WebSphere Portal Server gegebenen Funktionen und Erweiterungsmöglichkeiten ermöglicht abschliessend eine Abschätzung der zu erwartenden Aufwendungen.
Es wurde ein höchstmögliches Augenmerk auf Allgemeingültigkeit und Modularität bzw.
Austauschbarkeit der Module gelegt, um den Spezifika der einzelnen Hochschulen
Rechnung tragen zu können. Einerseits besteht die Möglichkeit, bereits bestehende
Systeme im Sinne einer Investitionssicherung unter Beachtung bestimmter ITtechnischer Rahmenbedingungen in das Portalframework zu integrieren, andrerseits
können bei Bedarf diese Systeme aber auch durch neue, in der Software Generallizenz
enthaltene „state of the art“ - Produkte, abgelöst werden.
Aufgrund der Vielzahl der Hochschulen in NRW konnten zeizbedingt nicht alle Hochschulen in NRW besucht werden - jedoch sollte mit der getroffenen Wahl ein repräsentativer Querschnitt erreicht worden sein. Zur Verifizierung der durch die IBM identifizierten Prozesse wurden weitere Gespräche geführt, so dass trotz des teilweise etwas
groben Rasters alle wesentlichen und wichtigen Prozesse und Aspekte für die „Aussendarstellung und Anwendungsintegration“ an Hochschulen betrachtet wurden.
Stand:26.09.03
6 von 53
3 Einleitung
„Ein Portal ist eine auf Web-Technologien basierende Applikation, die einer bestimmten
Zielgruppe (Studierende, Lehrende, Verwaltungsangestellte, Ehemalige, Gäste, Partner,
Lieferanten) einen zentralen und personalisierten Zugang zu Informationen, Anwendungen und Prozessen ermöglicht und die Kommunikation aller Beteiligten forciert.“
Ausgehend von dieser im Kapitel 1 aufgestellten Definition wird in diesem Kapitel der Anwendungstyp „Portal“ näher betrachtet und es werden anhand einer einfachen Architektur die grundlegenden funktionalen Anforderungen an ein Portal dargestellt.
Im allgemeinen Sprachgebrauch stellen Portale Internetauftritte dar, die eine Vielzahl
unterschiedlicher Dienstleistungen unter einem Dach anbieten. Beispiele für solche Portale sind insbesondere die Auftritte der Internetprovider wie z.B. yahoo, web.de oder
gmx.
Abbildung 2: Überblick funktionale Portalarchitektur
Eine Zusammenfassung der von Hochschulen angeboten Dienstleistungen ergibt für den
Anwender zunächst den Vorteil, dass er auf diese Dienste von jedem Ort der Welt aus
eine einheitliche Sicht hat. Werden z.B. Dienste wie eMail oder Kalender mit in das
Portal aufgenommen, hat ein Studierender oder ein Mitarbeiter auch von zu Hause oder
Stand:26.09.03
7 von 53
von einer Dienstreise aus Zugriff auf diese Funktionalitäten. Üblicherweise erfordern die
Zugriffe auf die Dienstleistungen eine Anmeldung mit Benutzerkennung und Passwort.
Die Zusammenfassung verschiedener Dienste unter dem Dach des Portals bietet den
Vorteil, dass eine einmalige Anmeldung ausreichend ist, um auf alle angebotenen
Dienstleistungen zugreifen zu können.
Obwohl bereits die einfache Zusammenstellung von Diensten als Portal bezeichnet wird,
leisten moderne Portale weitaus mehr. Abbildung 2 skizziert die in Kapitel 4 ff. ausführlich beschriebenen Funktionen des WebSphere Portal Servers.
Die Grobarchitektur des WebSphere Portal Servers lässt sich in drei Ebenen (von unten
nach oben) unterteilen: Quellensysteme - Verarbeitungsebene - Präsentation.
Quellensysteme können sowohl Anwendungen als auch Datenverwaltungssysteme sein,
hierzu zählen hauptsächlich:
- strukturierte Daten (Datenbanken),
- unstrukturierte Daten (Filesysteme, Textsysteme, etc.),
- Anwendungen (Verwaltungsanwendungen, Dokumentenmanagement, Individualentwicklungen etc.),
- externe Inhaltsdienste (Content Provider: Financial Times, Hoovers, etc.)
Die in der Verarbeitungsebene dargestellten Funktionen Anwendungsintegration, Inhaltsmanagement, Suche, Kommunikation & Kollaboration und Personalisierung werden als
Kernkomponenten eines Portal Servers in Kapitel 4 anhand hochschulspezifischer Anforderungen behandelt.
Als Präsentationsoberfläche dient dem Portalbenutzer meist ein Web-Browser, der über
HTML oder Java mit dem Portal interagiert. Die Portaloberfläche selbst setzt sich aus
mehreren sogenannten Portlets zusammen, die die Kernfunktionalität einer jeden Portallösung darstellen (siehe Abbildung 3).
Abbildung 3: Vergrösserung Portlet
Stand:26.09.03
8 von 53
Portlets sind voneinander unabhängige modulare Standardbausteine und werden - ähnlich wie ein Fenster auf dem PC-Desktop - als Teilfenster des Portals sichtbar. Sie erlauben neben der flexiblen Einbindung von Inhalten auch das Abbilden von Teilfunktionalitäten unterschiedlichster Programme und dienen somit als Bindeglied zwischen den
in einer Hochschule verwendeten Anwendungen und ihrer Darstellung im Portal.
Stand:26.09.03
9 von 53
4 Anforderungen an eine ganzheitliche Portallösung im
Hochschulumfeld
Um die in Kapitel 3 aufgestellte Portaldefinition transparenter zu machen, werden nachfolgend die einzelnen Funktionalitäten und der Aufbau eines Hochschulportals erläutert.
Die Vielfalt der Portalfunktionen lässt die mögliche Spannweite einer umfassenden
Portallösung erahnen.
4.1 Personalisierung
Neben der Anzeige von generellem Portalinhalt und Diensten ermöglicht es die Anmeldung des Benutzers, die Inhalte des Portals auf den Anwender individuell anzupassen,
indem nur die für den Anwender relevanten Dienste dargestellt werden. Personalisierung
kann auf verschiedenen Ebenen stattfinden.
4.1.1 Benutzerrollen und Organisationseinheiten
Zunächst können die Anwender in Benutzerrollen wie Studierende, Lehrende, Verwaltungsangestellte, Alumni oder Gäste eingeordnet werden. Während für Studierende insbesondere der Veranstaltungskalender und der Speiseplan der Mensa von Interesse ist,
beinhaltet das Portal für einen Verwaltungsangestellten die Dienste für die Bearbeitung
von Verwaltungsvorgängen.
Neben der Rolle, die ein Benutzer einnimmt, kann die Zuordnung zu der Organisationseinheit, in der er sich befindet, Einfluss auf die Portalinhalte nehmen. Studierende des
Fachbereichs „Wirtschaft“ sehen die Veranstaltungen des Fachbereichs „Wirtschaft“ mit
Priorität und haben die Homepage des Fachbereichs in ihrem personalisierten Bereich
des Portals. Das Portal von Mitarbeitern der Abteilung für Beschaffungen beinhaltet nur
die Verwaltungsvorgänge für Beschaffungen, nicht aber die für die Abwicklung von
Dienstreisen. Im Rahmen dieser persönlichen Gestaltung können auch individuelle Bookmarks angelegt werden, die dem Benutzer von überall in der Welt Zugriff auf seine wichtigsten Seiten ermöglicht.
Wichtig bei der Gestaltung des Portals ist dabei, dass Gäste, also nicht angemeldete
Benutzer, eine eigene Benutzergruppe sind, deren Portalinhalt ebenso gestaltet werden
sollte. Benutzer mit multiplen Rollen, zum Beispiel wissenschaftliche Angestellte, die
auch als Promotionsstudierende immatrikuliert sind, besitzen die Rechte für die Dienste
beider Rollen, es stehen ihnen somit auch die definierten Seiten und Dienstleistungen
beider Rollen zur Verfügung.
Zusätzlich zu der vordefinierten Konfiguration des Portalinhalts anhand der Rolle und der
Organisationseinheit des Benutzers kann jeder dazu berechtigte einzelne Benutzer seinen Portalinhalt individuell zusammenstellen. Dazu kann er aus einem Katalog von
seiner Rolle zugeordneten Dienstleistungen diejenigen auswählen, die er in sein Portal
aufgenommen wissen will, beziehungsweise standardmäßig zugeordnete Dienste, die er
Stand:26.09.03
10 von 53
nicht benötigt, aus seinem Portal entfernen. So können Studierende oder Angestellte,
die ohnehin nie in der Mensa essen gehen, den Speiseplan aus ihrem Portal entfernen.
Eine weitere Möglichkeit, Personalisierung im Portal vorzunehmen, bietet der in dem
WebSphere Portal Server integrierte Personalisierungsserver, mit dem bestimmte Inhalte
über Regeln und Kampagnen zielgruppenspezifisch angezeigt werden können. So wäre
es beispielsweise möglich, alle Erstsemester in den ersten 4 Wochen ihres Studiums
verstärkt mit speziellen Informationen zum Studienanfang zu versorgen.
Die Benutzer, deren Rechte, Rollen und Zuordnungen zu Organisationseinheiten können
bei der Verwendung eines zentralen Identity Management Systems (siehe Konzept
„Identity Management und Zentraler Verzeichnisdienst“) der zentralen Rechteverwaltung
entnommen werden. Im Kontext des Portals erleichtert dies die Verwaltung der
Portalbenutzer unter anderem dadurch, dass im Portal automatisch neue Benutzer mit
den Berechtigungen im Portal existierender Benutzergruppen angelegt werden können.
Der Freigabeprozess für den personalisierten Zugriff auf das Portal über User ID und
Passwort kann erheblich unterstützt werden: Insbesondere für die Vielzahl der
gleichzeitig zu berechtigenden Erstsemester kann dadurch ein schneller Portalzugang
realisiert werden, da die Studierenden automatisch berechtigt werden können, sobald die
entsprechenden Informationen im Hochschulinformationssystem erfasst sind.
4.1.2 Individuelle Dienste
Personalisierung bezieht sich aber nicht nur auf die Frage, welche Dienste überhaupt in
Anspruch genommen werden, sondern insbesondere auch auf die Inhalte dieser
Dienste. Für die Zielgruppe der Studierenden kann man sich verschiedene Dienste
vorstellen, die diesen einen echten Mehrwert bieten würden:
Ein personalisiertes Vorlesungsverzeichnis, in dem Veranstaltungen hervorgehoben werden, die entsprechend dem bisherigen Studienverlauf und dem Studienverlaufsplan als
nächste belegt werden sollten, erleichtert den Studierenden die Auswahl der zukünftig zu
belegenden Veranstaltungen. Ein persönlicher Kalender, in dem automatisch die
belegten Veranstaltungen eingetragen werden, hilft bei der Erstellung des
Semesterstundenplans. Verknüpft man dies mit dem automatischen Terminvermerk der
Anmeldefrist für die Prüfung der belegten Veranstaltung, kann eine weitere wertvolle
Unterstützung erreicht werden. Im Abschnitt Kollaboration und Kommunikation werden
weitere Beispiele für den Einsatz von Kalenderfunktionalität dargestellt.
Sowohl die Zuordnung zu Organisationseinheiten als auch die elektronische Belegung
von Veranstaltungen ermöglichen einen personalisierten Newsticker, in dem alle
aktuellen Informationen des Fachbereichs, des Lehrstuhls, oder der einzelnen
Veranstaltungen angezeigt werden. Auf diese Weise könnte auch kurzfristig über
zeitliche oder räumliche Verlegung oder Ausfall der Veranstaltung informiert werden.
Den Studierenden können auch Informationen über persönliche Daten, wie zum Beispiel
Adressdaten, belegte Übungen, abgelegte Leistungsnachweise oder Prüfungsnoten angezeigt werden, die die Hochschule in verschiedenen Systemen über sie erfasst hat.
Wie der Zugriff auf diese Daten vom Portal aus realisiert werden kann, wird in Kapitel 4.2
Stand:26.09.03
11 von 53
Anwendungsintegration dargestellt. Inwiefern hierbei durch Datenschutzaspekte Integrationsgrenzen (z.B. personalisierte Notenprofile) entstehen, muss hochschulintern geprüft
werden. Die Sicherstellung, dass auch nur die Informationen nach außen dringen, die die
Hochschule verantworten kann, wird über das Rollenmanagement im Portal geregelt.
Erläuterungen zur Sicherheit im Portal befinden sich in Kapitel 5.2.4 Sicherheit.
Bei Umsetzung der Personalisierung muss beachtet werden, dass einige der Funktionalitäten Bestandteil des Portal Servers sind, wohingegen andere individuell programmiert
werden müssen. Immer dann, wenn nicht die Dienstleistung als solche auf Grund der
Rollenzugehörigkeit ausgewählt wird, sondern der Inhalt individuell für eine Rolle oder
einen Benutzer konfiguriert werden soll, muss dies auch individuell entwickelt werden.
Beinhaltet der Standardbaustein für das Vorlesungsverzeichnis zum Beispiel immer alle
Veranstaltungen, so ist eine Personalisierung basierend auf dem Studienverlauf durch
die Hochschule zu erstellen.
4.2 Anwendungsintegration
Bereits die im Vorherigen beschriebenen Dienste eines Portals erfordern die Einbindung
anderer Anwendungen. Das Portal bietet zwar zentrale Dienstleistungen für die Darstellung von Inhalten, die Inhalte selbst müssen jedoch von zentralen Anwendungen kommen. Dies können allgemein übliche Anwendungen wie eMail- und Kalenderdienste sein,
es können aber auch sehr spezielle Dienste wie beispielsweise aus der Hochschulverwaltung sein. In dem nachfolgenden Abschnitt wird beschrieben, wie Anwendungen
angebunden und vor allem zu einem gesamten System integriert werden können.
4.2.1 Einbindung einzelner Anwendungen
Anwendungen, deren Inhalte in einem Portal angezeigt werden sollen, können auf verschiedene Arten eingebunden werden.
Am einfachsten ist die Einbindung bestehender Webseiten durch sogenannte iFramePortlets. Hierdurch können unter geringem Aufwand komplette Webseiten direkt in das
Portal eingefügt werden. Besitzt zum Beispiel die Bibliothek einen eigenen
Internetauftritt, so kann dieser Auftritt in einem eigenen Fenster des Portals angezeigt
werden. Für den Fall, dass die Bibliothek nur einen authentifizierten Zugriff zulässt,
können die hierfür benötigten benutzerspezifischen Anmeldedaten im Portalframework
hinterlegt werden, so dass der Zugriff auf die geschützten Bibliotheksseite automatisch
durch die einmalige Anmeldung am Portal gewährleistet wird.
Der WebSphere Portal Server bietet zudem die Möglichkeit, einen Teil einer Seite auszuschneiden und nur diesen Ausschnitt im Portal anzuzeigen. Diese Funktionalität wird als
Web-Clipping bezeichnet. Durch Web-Clipping können Teilinformationen aus bestehenden Webauftritten extrahiert und in das Hochschulportal mit dem gewünschten Look &
Feel integriert werden. Diese Art der Anbindung bietet sich zum Beispiel an, wenn aus
dem Wochen-Speiseplan der Mensa nur der jeweils aktuelle Tag in einem Fenster des
Portals angezeigt werden soll.
Stand:26.09.03
12 von 53
Beide genannten Arten der Einbindung sind in wenigen Stunden umzusetzen.
Aufwendiger ist die Einbindung von Anwendungen, die nicht unmittelbar über Webseiten
bedient werden können. Besitzen diese Anwendungen moderne Schnittstellen basierend
auf dem Standard der Java 2 Enterprise Edition (J2EE) wie zum Beispiel XML, so
können für diese Anwendungen auch ohne Programmierkenntnisse Portalseiten relativ
einfach neu gestaltet werden.
Die Integration von Anwendungen ins Portal, die weder web-enabled sind noch über eine
moderne Schnittstelle verfügen, ist entsprechend komplexer. Die Java-Technologie, mit
der die Portalbausteine implementiert werden, bietet zwar eine Reihe von Zugriffsmöglichkeiten auf entfernte Systeme und Daten, dies erfordert jedoch entsprechende Programmierkenntnisse. Die Anbindung solcher Anwendungen ans Portal wird durch die im
Lieferumfang des WebSphere Portal Servers enthaltene Entwicklungsumgebung unterstützt (siehe Kapitel 5.2.2 Entwicklungsumgebung).
4.2.2 Integration von Portalanwendungen untereinander
Im vorherigen Abschnitt wurde beschrieben, wie einzelne Anwendungen in das Portal
eingebunden werden können. Die Zusammenstellung aller für eine Rolle relevanten
Informationen bietet bereits einen echten Mehrwert für den Benutzer. Das Zusammenspiel verschiedener Anwendungen durch die Integration der Anwendungen
untereinander kann diesen Mehrwert noch einmal deutlich steigern. In diesem
Zusammenhang kann man sich insbesondere die Integration von Informationsdiensten
mit dem persönlichen Kalender vorstellen.
Neben den klassischen Integrationsformen wie Workflow- und Message Brokern bietet
der Portal Server eine gänzlich neue Form der Kommunikation. Die einzelnen Bausteine
einer Portalseite können miteinander über die sogenannte Click to Action (C2A) Technologie kommunizieren. Auf diese Weise kann der Benutzer in einem Baustein einen Datensatz auswählen und diesen an einen anderen Baustein senden, wo dann eine Aktion
auf diesem Datensatz ausgeführt wird. So kann beispielsweise bei Auswahl einer Veranstaltung aus der Übersicht des Vorlesungsverzeichnisses diese an einen Baustein
gesendet werden, der die Details der Veranstaltung anzeigt. Ebenso kann die Veranstaltung an einen Kalender gesendet werden, der die Veranstaltungstermine aufnimmt. Um
diese oder vergleichbare Funktionen zu nutzen, ist eine Erstellung solcher Bausteine
bzw. eine Adaption der Portlets erforderlich.
Diese Form der Anwendungsintegration bietet vielfältige Möglichkeiten. So können bei
Auswahl einer Matrikelnummer in einem anderen Baustein die persönlichen Daten des
Studierenden angezeigt werden. Ein Datensatz mit persönlichen Daten kann an den
Baustein für Urlaubsanträge gesendet werden. Allerdings ist in der Regel individuelle
Programmierung erforderlich, da die Schnittstellen der verschiedenen Anwendungen aufeinander abgestimmt werden müssen.
Stand:26.09.03
13 von 53
4.2.3 Portletkatalog
Die bereits in dem Kapitel Personalisierung beschriebene Möglichkeit der individuellen
Einbindung von Dienstleistungen wird in Form von einzelnen Bausteinen (Portlets)
realisiert, die durch den Administrator des Portals bereitgestellt werden. Dabei wird auch
definiert, Anwender welcher Rollen den jeweiligen Baustein verwenden dürfen.
Woher aber bekommt die jeweilige Hochschule diese Portlets, um Anwendungen in das
Portal integrieren zu können? Prinzipiell gibt es folgende Möglichkeiten:
Die Nutzung bereits vorgefertigter Standardportlets. Hierzu stellt die IBM in ihrem
Portletkatalog im Internet unter www.software.ibm.com/wsdd/zones/portal/catalog eine
ständig wachsende Anzahl von vorgefertigten Portlets zur Anbindung unterschiedlichster
Anwendungen „Out of the Box“ zur Verfügung. Dies umfasst unter anderem Standardportlets zum Zugriff auf eMail- und Kalenderdienste, Bausteine für Newsticker, für Teamräume und für eine Vielzahl weiterer Standardanwendungen. Der Portletkatalog enthält
sowohl Portlets, die durch die IBM entwickelt wurden, als auch Portlets von Drittanbietern: Viele Anbieter von Backendsystemen bieten inzwischen zum Zugriff auf ihre
Anwendungen eigene Portlets an. Nicht zuletzt aufgrund der Marktführerschaft des WebSphere Portal Servers (siehe Kapitel 5.1 Marktbetrachtung) wird bei den Herstellern eine
hohe Motivation erzeugt, eine Integration mit dem IBM Produkt über die entsprechenden
Portlets anzubieten. Während die von der IBM entwickelten Portlets kostenlos zur Verfügung gestellt werden, sind Portlets von Drittanbietern zum Teil getrennt zu lizensieren.
Neben vorgefertigten Portlets können durch die im Portal Server enthaltene
Programmierschnittstelle auch neue Portlets entwickelt und in das Portal integriert
werden. Als Programmierunterstützung dienen hierbei einerseits sogenannte Portlet
Builder, die es ermöglichen, relativ einfach ohne Java Programmierkenntnisse Portlets
zu entwickeln, und andrerseits das Portal Toolkit, welches auf der mitgelieferten
Entwicklungsumgebung des Portals aufsetzt und das Erstellen, Testen und
Implementieren von Portlets erleichtert (siehe Kapitel 5.2.2 Entwicklungsumgebung).
Da der Nutzen eines Portals steigt, je spezifischer es auf die individuellen Bedürfnisse
der Endbenutzer angepasst ist, ist es empfehlenswert, neben der Einbindung von
Standardapplikationen durch vorgefertigte Portlets auch hochschulspezifische
Applikationen und Informationen durch eigenentwickelte Portlets zu integrieren und zu
personalisieren. Da die Hochschulen häufig dieselben Anwendungen verwenden,
empfehlen wir den Aufbau eines internen Netzwerks zum Austausch und koordinierten
Entwickeln von Bausteinen, so dass Mehrfachentwicklungen vermieden werden.
Als Vorbildfunktion eines solchen internen Wissensnetzwerkes kann hier die Entwicklergemeinschaft des MyCoRe-Projektes angeführt werden. Bei dieser Gemeinschaftsinitiative, die von der Universität Essen im Jahre 1997 initiiert wurde, sind heute die Rechenzentren, Bibliotheken, Medienzentren oder bestimmte Fachbereiche der Universitäten
Bonn, Essen, Freiburg, Göttingen, Halle, Hamburg, Jena, Leipzig, Münster, Rostock und
Uppsala an der Weiterentwicklung beteiligt. In dieser Gemeinschaft werden mit Unterstützung des IBM Labors auf der Basis des IBM Content Managers Open Source Module
für den Einsatz in digitalen Bibliotheken im Hochschulumfeld entwickelt und umgesetzt.
Stand:26.09.03
14 von 53
Insbesondere Portlets zum Zugriff auf die Verfahren des HIS sind zunächst natürlich
hochschulspezifisch und müssen daher individuell implementiert werden, könnten dann
aber von allen Hochschulen des Landes verwendet werden. Bei einer hochschulweit
einheitlichen Portalplattform liessen sich durch ein solches Netzwerk Zeitaufwände und
Kosten sparen.
4.2.4 e-Learning
Eine wesentliche Komponente innerhalb eines Hochschulportals stellt sicher ein
integriertes e-Learning System dar, durch das dem Lernenden unterstützende Hilfsmittel
bereitgestellt werden sollen. Es bietet sich an, bestimmte Lehrinhalte oder -veranstaltungen derart aufzubereiten, dass diese zu einem vom Lernenden festgelegten Zeitpunkt
belegt oder auch wiederholt werden können. Weitere wichtige Komponenten stellen
Veranstaltungspläne dar, Hilfsmittel zum Einschreiben in Seminare, Vorlesungen,
Praktika und Prüfungen sowie vorbereitende Tests und Online-Prüfungen mit sofortiger
Auswertung.
Für solche Funktionen bietet IBM eine separate Lösung an, das IBM Lotus Learning
Management System. Die ausführliche Beschreibung seiner Funktionsweise und vorgeschlagener Komponenten finden Sie in dem Konzept „e-Learning“.
Die Einbindung des e-Learning Systems von IBM in ein universelles Hochschulportal, ist
durch die Nutzung der WebSphere-Technologie im Learning Management System (LMS)
wesentlich vereinfacht worden. So werden seitens des LMS spezielle, vorgefertigte
Portlets bereitgestellt, die direkt in ein hochschulweites Portal integriert werden können.
Des Weiteren ist es möglich, durch Nutzung von Web Services die Portlets des LMS in
das Hochschulportal zu integrieren. Die einfachste Form der Integration kann auch hier
über die in 4.2.1 erwähnte iFrame-Technologie realisiert werden - die komplette
Oberfläche des Learning Management Systems lässt sich so unter geringem Aufwand
als Web Applikation innerhalb eines speziellen Portlets im Portal darstellen.
Die Rollen der Nutzer, also die der Lehrenden und der Lernenden, werden durch die
Infrastruktur des Portals in Verbindung mit dem universellen Identity Management und
dem zentralen Verzeichnisdienst bereitgestellt.
4.2.5 HIS
Obwohl die Softwarelandschaft der Hochschulen aufgrund ihrer Autonomie sehr heterogen ist und daher hier wenige Empfehlungen für die Anbindung spezieller Produkte gegeben werden können, gehen wir auf die Produkte der Hochschul-Informations-System
GmbH (HIS) detaillierter ein. Die Produkte der HIS sind in den Hochschulen der Landes
Nordrhein-Westfalen weit verbreitet. Sie umfassen Module zur Studentenverwaltung
(SOS), Prüfungsverwaltung (POS), Zulassungsverwaltung (ZUL), Finanz- und Sachmittelverwaltung (FSV), Gebäude- und Flächenmanagement (BAU), Kosten- und Leistungsrechnung (COB), Personal- und Stellenverwaltung (SVA) sowie Lehre, Studium, Forschung (LSF).
Eine Besonderheit ist das Modul QIS, durch das eine Internet-Schnittstelle zu den Funktionen verschiedener HIS-Module bereitgestellt wird. Die Funktionalität von QIS umfasst
insbesondere die Bereitstellung von Studentendaten, Durchführen von Rückmeldungen,
Ändern von Adressdaten, Erzeugen von Bescheinigungen für Studierende, Anmeldung
Stand:26.09.03
15 von 53
zu und Rücktritt von Prüfungen, Erstellen von Notenstatistiken, Noteneingabe und ansicht.
Das Modul LSF, mit dem Lehrveranstaltungen und die damit verbundenen Ressourcen
erfasst werden, ist aufgrund der moderneren Technologie, mit der es entwickelt wurde,
unmittelbar internetfähig.
4.2.5.1 Darstellungsmöglichkeiten im Portal
Die Funktionalitäten aus QIS und LSF können direkt in das Portal integriert werden.
Damit stehen den Studierenden eine Vielzahl von Verwaltungsfunktionalitäten sowie der
Zugang zum Vorlesungsverzeichnis zur Verfügung.
Für den Zugriff auf die weiteren HIS-Module müssen eigene Dienstleistungsbausteine
entwickelt werden, die direkt auf die Schnittstellen dieser Module, unter Umständen auch
direkt auf die Datenbank zugreifen. Durch die relativ große Verbreitung der HIS-Software
können diese Bausteine, wenn sie einmal entwickelt wurden, landesweit eingesetzt
werden.
4.2.5.2 Integration mit anderen Funktionalitäten
Bei der Integration mit anderen Funktionalitäten des Portals sehen wir insbesondere den
Mehrwert, den die Integration mit dem Terminmanagement, also dem persönlichen Kalender bietet. So können zum Beispiel Veranstaltungen aus dem Vorlesungsverzeichnis
in den persönlichen Kalender übertragen werden. Diese Funktionalitäten müssen
individuell implementiert werden.
4.2.6 Externe Anbieter
Neben den internen Dienstleistungen, die die Hochschule selbst den Anwendern
anbieten will, können auch externe Anbieter z.B. über Web Services Technologie relativ
einfach in das Hochschulportal eingebunden werden. Eine solche Einbindung sollte
aufgrund des zu erwartenden Werbeeffekts für den Partner in der Regel mit Rabatten
oder sonstigen Dienstleistungen für die Hochschule einhergehen. So könnten
beispielsweise Dienste eines Buchversandhandels eingebunden werden, in dem
fachbereich- bzw. lehrstuhlrelevante Literatur angeboten wird.
Weitere Ansätze für die Nutzung des Hochschulportals als Partnering Plattform können
die Einbindung von Praktika- und Job-Börsen sowie die Integration von
Wohnungsbörsen als Ergänzung der Angebote der Studentenwohnheime sein. Aktuelle
Informationen über das jeweilige Stadtleben, der aktuelle Fahrplan des ÖPNV oder
lokale Wetternachrichten steigern im Kontext des Portals die Attraktivität der zentralen
Hochschulplattform und tragen zu seiner intensiven Nutzung bei.
4.3 Kollaboration und Kommunikation
Unter Kollaboration und Kommunikation fallen alle Anwendungen, die der Zusammenarbeit verschiedener Anwender dienen. Dies umfasst einerseits Anwender innerhalb der
Hochschule, wie zum Beispiel Studierende untereinander und mit dem Lehrenden sowie
die Kommunikation mit der Verwaltung. Während die Zusammenarbeit im Rahmen der
Lehre bereits innerhalb des Konzepts e-Learning behandelt wird und dort auch integraler
Stand:26.09.03
16 von 53
Bestandteil ist, sehen wir auch die bessere Unterstützung der Zusammenarbeit des
wissenschaftlichen Personals mit andere Hochschulen als Zielsetzung. Die Software
Generallizenz beinhaltet sowohl Portalbausteine als auch serverseitige Anwendungen,
die die Zusammenarbeit unterstützen.
Eine logische Zusammenfassung von Kommunikationsdiensten im Portal ist das sogenannte Collaboration Center. Durch die Darstellung von Instant Messaging Funktionen,
Teamräumen, Calendering und gelben Seiten (People Finder) in einem Kontext (siehe
Abbildung 4) wird die Zusammenarbeit der Benutzer forciert und ihre Produktivität gesteigert.
Abbildung 4: Collaboration Center des Portal Servers
Im Hochschulumfeld können so Studierende und Forschende vor allem bei Projektarbeiten optimal unterstützt werden, aber auch die Verwaltungsangestellten der Hochschule
profitieren vom Collaboration Center: Möchte man einen anderen Mitarbeiter
kontaktieren, so kann man diesen im People Finder Portlet ausfindig machen, sieht zu
welcher Organisation dieser gehört und ob der gewünschte Kollege gerade erreichbar ist
(siehe Kapitel 4.3.6 Awareness).
Unter der Adresse http://media.lotus.com/collaboration/CollabCtr_04_30_03.html ist beispielhaft dargestellt, wie die Kollaborationswerkzeuge eingesetzt werden können.
Die Erläuterungen zu den Teilfunktionen finden sich in den nachfolgenden Abschnitten.
Stand:26.09.03
17 von 53
4.3.1 eMail
Der Portlet-Katalog der IBM beinhaltet Bausteine zur Integration von eMail-Bausteinen
für allgemeine POP3-Server, für Microsoft Exchange sowie für Lotus Notes. Die
Bausteine bieten Zugriff auf bestehende eMail-Funktionalität, und ermöglichen den
Anwendern die Bearbeitung ihrer eMail von jedem Ort der Welt aus. Der Lotusteil der
Software Generallizenz umfasst dabei auch die serverseitige Unterstützung von eMail,
so dass die Integration bereits vorhandener eMail-Server möglich, nicht aber notwendig,
ist.
4.3.2 Kalender / Terminmanagement
Auch Standardkalenderfunktionalitäten von Microsoft Exchange und Lotus Notes können
über vorgefertigte Portlets im Portal zur Verfügung gestellt werden.
So ermöglichen vorgefertigte Notes Portlets aus dem Portal heraus beispielsweise die
Pflege eigener Termine und die Pflege von Terminen, zu denen eine Delegationsberechtigung besteht. Insbesondere ermöglicht dies die Pflege der Kalender der Professoren
durch die Sekretariate. Auch die Einsicht in Kalender anderer ist - abhängig von den
definierten Berechtigungen - möglich, so könnten zum Beispiel alle Mitglieder eines Lehrstuhls ihre Termine untereinander sehen. Eine weitere mögliche Funktion der Kalender
ist die Planung von Besprechungen und Sitzungen. Hierzu können andere Personen
eingeladen werden. Die Verfügbarkeit von Ressourcen, wie zum Beispiel des
lehrstuhleigenen Beamers, kann mittels der Kalenderfunktionalität geprüft werden, auch
kann eine Ressource reserviert werden.
Ein Mehrwert des Kalenders ergibt sich insbesondere durch die Möglichkeit,
verschiedene Terminquellen zu bündeln. So können die Termine des Referats für
Öffentlichkeitsarbeit, des Allgemeinen Hochschulsport, der Fachbereiche, des AStA, der
Bibliothek, des Studentenwerk getrennt voneinander eingetragen werden. Die jeweiligen
Kalender können einzeln durch einen Anwender abonniert werden, sie können aber
auch automatisch zu einem gemeinsamen Kalender zusammengefasst werden, der
dann alle Termine enthält. Für die beiden zuletzt genannten Möglichkeiten sind je nach
Umfang Anpassungen notwendig.
Neben der Verwaltung allgemeiner Termine steht die personalisierte Verwaltung von Terminen. Rückmeldefristen sind für bereits rückgemeldete Studierende nicht mehr relevant.
Die Termine des Promotionsausschusses sind nur für bestimmte wissenschaftliche Mitarbeiter und Promotionsstudierende relevant. Termine für die Belegung von Übungsgruppen und für die Anmeldung zu Klausuren sind nur für diejenigen Studierende
wichtig, die die entsprechende Vorlesung besucht haben.
Sofern keine automatische Zuweisung von wichtigen Terminen zu den Anwendern
umgesetzt wird, hilft die clientseitige Anwendungsintegration bei der Übernahme von
Terminen aus allen genannten Quellen in den persönlichen Kalender. Diese
Personalisierung ist allerdings nicht Standardfunktionalität und muss individuell
umgesetzt werden.
Stand:26.09.03
18 von 53
4.3.3 Diskussionsforen
Diskussionsforen stellen eine Plattform bereit, mit deren Hilfe die Anwender zu selbst
definierten Themen miteinander diskutieren können. Je nach Berechtigungsprofil kann
der Anwender innerhalb eines Forums neue Themen eröffnen oder Beiträge anderer
beantworten. Für die clientseitige Anbindung von Newsgroups in das Portal existieren
vorgefertigte Portlets. Der Newsgroup Server ist nicht im Lieferumfang des Portals
enthalten.
Neben der Bereitstellung eigener Diskussionsforen im Kontext der virtuellen Teamräume
durch die Quickplace Technologie (siehe Kapitel 4.3.4) bietet das Portal auch die Möglichkeit, externe Diskussionsforen durch den Zugriff auf externe Newsserver anderer
Hochschulen oder Forschungseinrichtungen einzubinden. Dadurch wird das nationale
und internationale Forschungsnetzwerk unterstützt.
4.3.4 Virtuelle Teamräume
Teamräume stellen eine Erweiterung der Idee der Diskussionforen dar. Neben Diskussionsbeiträgen können Dokumente aller Art klassifiziert abgelegt werden. Weiterhin ermöglichen Teamräume die Verwaltung der teambezogenen Termine.
Teamräume sind für Forschungsprojekte und Übungsgruppen von Interesse. Hier
können Übungsaufgaben, Musterlösungen, Fragen und Termine abgelegt werden. Bei
Forschungsprojekten können die Forschungsergebnisse (Deliverables), Statusberichte,
gemeinsame Datensätze, Veröffentlichungen, Literaturverzeichnisse und ähnliches für
jeden Projektbeteiligten einfach zugänglich abgelegt werden. Es können die Termine
erfasst werden, zu denen Forschungsergebnisse erstellt werden müssen oder
Begutachtungen stattfinden. Insbesondere für externe Anwender, die nicht im
hochschuleninternen Verzeichnisdienst geführt werden, können vereinfachte
Zugriffsverfahren ermöglicht werden, so dass die Teamräume tatsächlich flexibel genutzt
werden können.
Ein besondere Vorteil des hier eingesetzten Produktes ist die einfache Einrichtung eines
virtuellen Teamraumes, die durch berechtige Benutzer mit wenigen Clicks durchgeführt
werden kann. So können Teamräume flexibel immer dann eingerichtet werden, wenn sie
konkret benötigt werden.
Die serverseitig erforderlichen Komponenten wie IBM Lotus Domino und Quickplace sind
Bestandteil des IBM WebSphere Portal Servers. Die Offline-Funktionalität der Teamräume ist nicht Bestandteil des WebSphere Portal Servers, wird aber durch den Lotusteil
der Software Generallizenz abgedeckt.
4.3.5 Sametime
Im Gegensatz zu Diskussionsforen und Teamräumen, die asynchron genutzt werden,
also keine unmittelbare Kommunikation zwischen den verschiedenen Benutzern besteht,
ermöglicht die Sametime-Technologie eine unmittelbare synchrone Kommunikation
(Instant Messaging) zwischen gleichzeitig im Portal befindlichen Benutzern.
Stand:26.09.03
19 von 53
Bearbeiten beispielsweise mehrere Studierende gleichzeitig einen Übungszettel, können
sie mittels Chat unmittelbar Fragen stellen und deren Beantwortung diskutieren. Eine
weitere Funktion von Sametime besteht darin, dass die Nutzer die Möglichkeit bekommen, virtuelle Meetings, so genannte Webkonferenzen, aufzusetzen und automatisch an
die gewünschten Teilnehmer eine Einladung versenden zu lassen. Damit lassen sich
gemeinsam Übungen durchführen, ohne dass die Teilnehmer sich dazu in einen Raum
begeben müssen. Solche Webkonferenzen können unter Leitung eines Seminarverantwortlichen aber auch von Studierenden selbständig abgehalten werden.
Die serverseitig erforderlichen Komponenten wie IBM Lotus Domino und Sametime sind
Bestandteil des WebSphere Portal Servers. Die Webkonferenzfunktionalität ist nicht
Bestandteil des WebSphere Portal Servers, wird aber durch den Lotusteil der Software
Generallizenz abgedeckt.
4.3.6 Awareness
Dem Besucher einer Seite im Portal kann angezeigt werden, wer sich ausser ihm selbst
noch auf dieser Webseite befindet. Verständnisfragen und Diskussionen können so unmittelbar zielgerichtet initiiert werden, indem genau die Personen kontaktiert werden, die
sich gerade mit dem selben Thema beschäftigen. Dieses Merkmal wird als „Awareness“
bezeichnet. „Awareness“ ist eine Funktionalität des Portal Servers unter Verwendung
von Sametime. Beim Erstellen von Portalbausteinen kann die Unterstützung dieser
Eigenschaft dem Baustein zugeordnet werden, ohne dass speziell programmiert werden
muss. Eine Vielzahl von Standardportlets der IBM unterstützt dieses Merkmal.
Bei der Bereitstellung eines Dienstes im Portal kann im Rahmen der Konfiguration des
entsprechenden Portlets individuell festgelegt werden, ob die Funktionalität „Awareness“
im Portal bereitgestellt werden soll oder nicht.
4.4 Inhalt und Suche
Die bisher beschriebenen dynamischen Aspekte des Portals stellen sicherlich die Highlights einer solchen Lösung dar. Der Großteil eines Portals umfasst jedoch statische
Inhalte - Informationen, die in ganz normalen Internetseiten dargestellt werden. In jeder
größeren Organisation stellt die Pflege und Verwaltungen dieser Informationen eine
eigene Herausforderung dar.
4.4.1 Syndicated Content
Unter Content Syndication versteht man den Austausch und den Handel mit Inhalten für
das elektronische Publizieren auf Webseiten. Dabei werden Inhalte von Fremdanbietern
vermarktet und je nach Servicegrad direkt im richtigen Format zur Verfügung gestellt.
Gewöhnlich besteht dieser Inhalt aus Nachrichten, Finanzdaten und Unterhaltung.
WebSphere Portal hat Partnerschaften mit populären Inhaltsprovidern wie Moreover,
YellowBrix, Hoovers, Factiva, NewsEdge, MediaApps, DataMonitor, Screaming Media,
Financial Times und anderen. Die meist vorgefertigten Portlets der News Provider sind
dabei so aufgebaut, dass sich die Endbenutzer die gewünschten Inhalte bequem zusam-
Stand:26.09.03
20 von 53
menclicken können. Studierende des Fachbereichs Wirtschaft könnten so im Kontext
ihres Portals zum Beispiel mit tagesaktuellen Finanznachrichten der Financial Times
versorgt werden.
4.4.2 Web Content Management Systeme
Web Content Management Systeme (WCMS) stellen eine Umgebung bereit, die die
koordinierte Pflege von Internetseiten ermöglicht. Die zentrale Ablage der Internetseiten
und eine zentrale technische Infrastruktur für den Zugriff auf die Seiten (die Webserver)
sollten Ziel einer jeder Hochschule sein. Erst damit wird der Verwaltungsaufwand für
viele einzelne Server verringert, und nur eine zentrale Verwaltung ermöglicht eine hohe
Sicherheit des Gesamtsystems gegenüber Einbrüchen.
Für eine Hochschule muss sichergestellt sein, dass jede Organisationseinheit die Hoheit
über ihre eigenen Seiten besitzt. Die Fachbereiche stellen ihre Inhalte selbst dar, die einzelnen Lehrstühle wiederum ihre jeweiligen Inhalte, und letztendlich besitzen viele einzelne Mitarbeiter eigene Seiten, in denen sie ihre Forschungsinhalte darstellen. Das WCMS
sieht für jede dieser Gruppen Bereiche vor, die nur durch speziell berechtigte Benutzer
editiert werden dürfen. Erst die Gesamtheit aller dieser Seiten ergibt den Internetauftritt
einer Hochschule. Zusätzlich ermöglichen die Redaktionssysteme von WCM-Systemen
die Definition von Arbeitsabläufen zur Freigabe von Inhalten, so können die Rollen Ersteller und Verantwortlicher einer Seite voneinander getrennt sein.
Auf Grund der Besonderheit, dass den Fachbereichen und Lehrstühlen die Verwendung
des zentralen WCMS und der Portalserverfunktionalität freisteht, muss das Portal die
Möglichkeit besitzen, bestehende Auftritte der Fachbereiche und Lehrstühle, die autark
arbeiten möchten, in das Gesamtportal aufzunehmen. So können kaskadierend Subportale integriert werden, wobei die Autonomie der Lehrstühle nicht angegriffen wird.
Sowohl die zu veröffentlichenden Inhalte als auch das Look & Feel bleiben - falls
gewünscht - in der Autorität der Fachbereiche.
Die Software Generallizenz umfasst mit dem Produkt Lotus Workplace Web Content
Management (LWWCM, ehemals Aptrix) ein vollständiges WCMS, das sowohl Standalone als auch über entsprechende Portlets zusammen mit dem WebSphere Portal
Server als integrierte Lösung eingesetzt werden kann.
Stand:26.09.03
21 von 53
Abbildung 5: Integrierte Gesamtlösung
Wie in Abbildung 5 verdeutlicht, macht jedoch nicht nur eine Integration mit dem WebSphere Portal Server Sinn, sondern auch eine Integration mit dem IBM Content
Manager. Wird der in der Software Generallizenz enthaltene IBM Content Manager als
zentrales Datenrepository genutzt, entstehen durch die Anbindung an das WCMS
weitere Synergieeffekte. Die Inhalte des WCMS werden personalisiert im Portal
angezeigt, im IBM Content Manager abgelegt und letztendlich über den Tivoli Storage
Manager gesichert. Da durch eine Integration neben ursprünglichen Dokumenten dann
auch Web-Inhalte im Repository des Dokumenten Management Systems vorgehalten
werden, wird eine einheitliche Suche entsprechend vereinfacht.
4.4.3 Suche
Auch ein in der Struktur noch so gutes Portal kommt ohne Suchfunktion nicht aus. Im
Lieferumfang des WebSphere Portal Servers sind deswegen eine integrierte
Portalsuchmaschine „Portal Search Engine“ und eine Meta-Suchmaschine „IBM Lotus
Extended Search“ enthalten.
4.4.3.1 Portal Search Engine
Die Portal Search Engine unterstützt mehr als 200 unterschiedliche Formate. Diese können anhand internetähnlicher Suchmöglichkeiten wie z.B. +/- (plus/minus), "" (bestimmte
Phrasen) und * (Platzhalter) durchsucht werden. Suchindizes über eine oder mehrere
Webseiten und Http-Server können über Crawling-Technologien erstellt werden. Dieser
Erstellungsprozess wird durch Filterregeln unterstützt und durch die Möglichkeiten,
Crawls periodisch von der Engine wiederholen zu lassen sowie manuell Indizes zu bearbeiten und zu aktualisieren. Die automatische Kategorisierung (Search Taxonomy) von
gefundenen Dokumenten und eine Kurzzusammenfassung der Suchergebnisse sind
weitere Funktionalitäten.
4.4.3.2 IBM Lotus Extended Search
Während die Portal Search Engine für die Suche in mittelgroßen Dokumentensammlungen optimiert ist, bietet sich die Nutzung von Extended Search insbesondere bei der
Stand:26.09.03
22 von 53
Suche in großen Dokumentensammlungen an, die auf unterschiedlichen Datenquellen
verteilt sein können.
Extended Search bietet hierfür eine verteilte, heterogene Suche über verschiedene
Datenquellen und das Internet, ohne dass Benutzer die Details dieser verschiedenen
Systeme kennen müssen. Extended Search wandelt jede Abfrage in die Abfragesprache
des jeweiligen Zielsystems um und verwendet dessen native Such- und Abfragemechanismen. Extended Search unterstützt standardmäßig die Suche in vielen verschiedenen
Datenquellen. Dies umfasst insbesondere die IBM- und Microsoft-Produkte, sowie Produkte die die Standard ODBC und LDAP unterstützen. Weiterhin können Internet Suchmaschinen (u.a. Google, Excite, Altavista, Lycos) und Nachrichtenseiten kommerzieller
Inhaltsanbieter in die Suche eingebunden werden.
Da durch diese Technologie auch existierende Suchindizes anderer Hochschulen im
Sinne einer hochschulübergreifenden Metasuche eingebunden werden können, wird die
Wahrscheinlichkeit für Studierende und Lehrende, relevante Inhalte zu finden, durch die
Erweiterung der zu durchsuchenden Dokumentenmenge erheblich erhöht.
Extended Search beinhaltet die Möglichkeit zur automatischen Erstellung von Taxonomien, Kategorien und Indizes. Die Suchergebnisse können wahlweise nach Relevanz
über mehrere Datenspeicher eingestuft werden, werden dann konsolidiert und dem Benutzer im Portal präsentiert. Um einen schnellen Überblick über die Inhalte eines Dokuments zu erhalten und das aufwendige Lesen irrelevanter Dokumente zu vermeiden,
werden - wie auch bei der Portal Search Engine - die Schlüsselphrasen der Dokumente
extrahiert und in einer Kurzzusammenfassung dargestellt.
4.4.4 Dokumentenablage
Neben den Inhalten, die in Form von HTML-Seiten angeboten werden, werden enorm
viele Informationen (laut Merrill Lynch Research 85% aller Informationen) in unstrukturierten Dateisystemen gespeichert. Der Websphere Portal Server bietet mit dem Portal
Document Manager die Möglichkeit, für jeden Benutzer einen Bereich zu schaffen, in
dem er seine Dokumente ablegen kann. Er kann bestimmten anderen Benutzern Zugriff
auf diese Dokumente verschaffen, oder sie als privat kennzeichnen, wodurch kein
anderer Benutzer Zugriff auf diese Dokumente hat. Das Portal stellt somit ein zentrales
Dateisystem zur Verfügung, auf das von überall in der Welt zugegriffen werden kann.
Der Vorteil gegenüber zentralen Dateisystemen von externen Portalprovidern wie gmx,
yahoo oder freenet ist die Gewährleistung der Sicherheit der Dokumente - der Benutzer
kennt den Betreiber der Server, auf dem die Dokumente abgelegt sind.
Office-Dokumente, die über den Portal Document Manager abgelegt sind, können auf
dreierlei Arten geöffnet werden.
1. Zur Ansicht.
2. Durch Starten des entsprechenden Office-Produkts.
3. Zum direkten Editieren im Portal.
Insbesondere mit der letzten Funktionalität können zum Beispiel Formulare für Verwaltungsvorgänge zur Verfügung gestellt werden, die überall ohne weitere Software bear-
Stand:26.09.03
23 von 53
beitet werden können. Dies ist insbesondere in heterogenen Computerlandschaften
nützlich - gerade Benutzer von UNIX-Workstations, die das Microsoft Office Paket nicht
besitzen, werden diese Funktionalität schätzen.
Neben der Dokumentablage im Rahmen der Portalfunktionalität, die mehr auf die kurzzeitige Ablage und der Änderbarkeit und Löschbarkeit der Dokumente abzielt, wird im
Rahmen der Software Generallizenz auch der IBM Content Manager als Dokumenten
Management System angeboten. Hiermit können digitale Dokumente, Bilddateien und
auch Videoelemente dauerhaft und unveränderlich abgespeichert werden. Für die Integration des IBM Content Managers in das Portal stellt der in Kapitel 4.2.3 erwähnte Portletkatalog der IBM entsprechende Portlets bereit.
Weitere Einzelheiten zu den Funktionalitäten des IBM Content Managers werden in dem
Konzept „Dokumentenverwaltung & Wissensmanagement für Hochschulen“ behandelt.
4.5 Weitere Funktionalitäten
Die folgenden Abschnitte beschreiben weitere Funktionalitäten, die sich nicht in den
Kontext der bisherigen Abschnitte einordnen liessen.
4.5.1 Barrierefreiheit
Unter Barrierefreiheit wird die Zugänglichkeit des Portals für behinderte Menschen bezeichnet. Barrierefreie Auftritte ermöglichen es insbesondere sehbehinderten Benutzern,
die Dienste über Brailleschriftleser oder durch Vorlesen der Inhalte zu nutzen.
Durch die Möglichkeit, im Rahmen der Personalisierung die Farbgestaltung und die
Schriftgrößen des Auftritts zu variieren, können Benutzer mit Sehschwächen, insbesondere auch Farbblindheit, ihr Portal so konfigurieren, dass sie es trotz der Behinderung
möglichst gut nutzen können. So können sie sich mithilfe der Bildschirmsprachausgabe
und eines digitalen Sprachsynthesizers vorlesen lassen, was auf dem Bildschirm angezeigt wird. Des Weiteren lassen sich die meisten Funktionen auch mit der Tastatur
anstelle der Maus ausführen.
Der Portal Server unterstützt die Barrierefreiheit weiterhin, indem für bestimmte
Benutzergruppen eine andere Ausgabeform für die Inhalte gewählt werden kann.
Dadurch kann die Informationsmenge einer Seite reduziert und weiter untergliedert
werden, so dass auch eine zeilenweise Ausgabe für Brailleschriftleser möglich ist.
Zusätzlich ist der Portal Server für die IBM Voice Server Technik vorbereitet, die Seiten
können also bei Verwendung dieses Produkts auch vorgelesen werden, zudem ist eine
Steuerung über Spracheingabe möglich.
4.5.2 Mobile Endgeräte
Ein besonderes Merkmal des Portals ist der Zugang zu allen Dienstleistungen und Informationen von überall in der Welt aus. Durch die vermehrte Verwendung von mobilen
Endgeräten ist auch für ein Hochschulportal eine entsprechende Zugriffsmöglichkeit von
Stand:26.09.03
24 von 53
einem mobilen Endgerät aus durchaus sinnvoll.
Dienstleistungsbausteine können so erstellt werden, dass sie die verschiedenen Datenformate für die unterschiedlichen Endgeräte unterstützen. Auf diese Weise können für
normale Arbeitsplatzcomputer, Mobiltelefone und Personal Digital Assistants (PDA)
unterschiedliche Darstellungen erzeugt werden. Bei Eintritt in das Portal erkennt der
Portal Server, mit welcher Art von Endgerät auf das Portal zugegriffen wird, und wählt
die entsprechende Darstellungsform automatisch aus.
Das persönliche Portal kann durch unterschiedliche Konfiguration für die unterschiedlichen Endgeräte so gestaltet werden, dass bei Zugriff über ein Mobiltelefon beispielsweise nur Kalender und eMail angezeigt werden, wohingegen dem PDA-Besitzer
vielleicht auch der Veranstaltungskatalog und die Dateien des Portal Document
Managers dargestellt werden.
Einige Portlets können für alle unterstützten Geräte verfügbar sein, während andere gegebenenfalls nur auf einem einzelnen Gerätetyp zur Verfügung stehen. Die Auslegung
der Oberfläche der einzelnen Portlets unterscheidet sich auch von Gerätetyp zu Gerätetyp, so dass die Darstellung für den Endbenutzer auf jeder Geräteart optimiert werden
kann. Die Homepage und Portlets des Endbenutzers können auf einem Mobiltelefon
ganz anders aussehen als auf einem Desktopbrowser.
4.5.3 Mehrsprachigkeit
Mehrsprachigkeit wird durch den Portal Server in unterschiedlicher Weise unterstützt.
Zum einen wird die anhand der im Webbrowser definierten Sprache die Sprache für die
Bedienung des Portals gewählt. Diese Sprache kann aber auch individuell durch den
Benutzer eingestellt werden.
Für ausländische Benutzer des Portals, seien es Gäste, Studierende oder Mitarbeiter,
bietet der WebSphere Translation Server die Möglichkeit der Übersetzung von
deutschen Inhalten in die englische Sprache, sowie die Übersetzung von englischen
Inhalten nach Französisch, Spanisch, Italienisch, Chinesisch, Japanisch und Koreanisch.
Der Translation Server kann auch in die Kollaborationswerkzeuge eingebunden werden,
so dass Teamräume und Chaträume mehrsprachig verwendet werden können, wobei die
Übersetzung in Echtzeit stattfindet.
Der Translation Server wurde für den Einsatz auf mehreren Plattformen konzipiert und
kann auf einem dedizierten Server laufen, der mittels dem RMI- und Java-Protokoll mit
WebSphere Application Server kommunizieren kann. Er besteht aus:
- MÜ-Engines (MÜ = Maschinenübersetzung) für die Übersetzung von Texten von einer
Sprache in eine andere (z. B. vom Deutschen ins Spanische)
- User Dictionary Manager-Tools, mit denen bestimmte Wörter einer Domäne hinzugefügt werden können (z. B. Anpassung für eine bestimmte Anwendung oder
Hinzufügen von Slang oder domänenspezifischen Sätzen und Ausdrücken)
- Unterstützung für WebSphere Application Server- und HTTP-Server von Microsoft,
Netscape, Apache und IBM
Stand:26.09.03
25 von 53
5 Markt- und Technologiebetrachtung
5.1 Marktbetrachtung
5.1.1 Produktentwicklung
Obwohl noch ein recht junger Anwendungstyp - erstmalig taucht der Begriff "Portal" im
IT-Umfeld 1997 auf - hat diese Technologie bis heute bereits mehrere Evolutionsstufen
durchlaufen.
Vorstufen von Portalen waren Webauftritte, die sich aus statischem Inhalt, kombiniert mit
einfachen Suchfunktionen und Hyperlinks, zusammensetzten.
Die erste Portalgeneration war überwiegend inhaltsorientiert und zeichnete sich vor allem
durch Content Management Funktionen, Kategorisierung, erweiterte Suchfunktionen
sowie Personalisierungsmöglichkeiten aus.
In der zweiten Generation standen vor allem die Bereitstellung robuster Frameworks zur
Integration von Daten und Applikationen, umfangreiche Kollaborationsmöglichkeiten und
alternative Zugriffsmöglichkeiten, wie z.B. über PDA's und Mobiltelefonen im Mittelpunkt.
Portale der dritten Generation nehmen die Automatisierung und Abbildung von Geschäftsprozessen über das Portal in Angriff. Technologisch sind die Verwendung von
Webservices und das Einbeziehen von Abstraktionsschichten zentrales Thema in den
Jahren 2003 und 2004. Neben der Prozessintegration sind unter anderem die
Erweiterung um Knowledge Management Funktionen, Bereitstellung von Offline
Funktionen sowie die Unterstützung von Mainframes als Portalplattform zur Steigerung
der Ausfallsicherheit Kern dieser Portalphase.
Kommende Portalgenerationen werden die Interoperabilität zwischen verschiedenen
Portallösungen unterschiedlicher Hersteller zum zentralen Thema haben. Zentrale Metaportale sollen dem Wildwuchs von Portalen entgegenwirken, bzw. die Konsolidierung
von konkurrierenden Portalen ermöglichen. In diesem Zusammenhang müssen
insbesondere Probleme bei der Standardisierung und dem Austausch von Personalisierungs- und Sicherheitsinformationen (Benutzerrollen) gelöst werden.
5.1.2 Marktentwicklung
Noch im Jahr 2001 waren auf dem Portalanbietermarkt sechzig bis siebzig unterschiedliche Anbieter bekannt.
Nach neueren Marktforschungsuntersuchungen hat sich diese Zahl jedoch in 2002 auf
ca. zwanzig bis dreißig bekannte Anbieter verringert.
Das unabhängige Marktforschungsinstitut Gartner Group hat einen Großteil der bekannten Portalanbieter analysiert und hinsichtlich bestimmter Kriterien bewertet.
Stand:26.09.03
26 von 53
Der sogenannte „Magic Quadrant" (siehe Abbildung 6) der Gartner Group setzt die bewerteten Unternehmen hinsichtlich ihrer Leistungsfähigkeit („ability to execute“) und ihrer
Produktstrategie („completeness of vision“) zueinander in Beziehung und ordnet sie den
Segmenten Leader, Visionaries, Challengers und Niche Players zu.
Abbildung 6: Matrix Portalmarkt nach Gartner Group
Da die Gartner Group den „Magic Quadrant" in regelmäßigen Abständen erstellt, können
die Entwicklungen der Anbieter genau verfolgt werden:
Anbieter bewegen sich auf der 'Completeness of Vision' Achse nach rechts, wenn sie
Innovationen präsentieren, und sie bewegen sich auf der 'Ability to Execute' Achse nach
oben, wenn sie Marktanteile gewinnen.
Im Leader Quadranten werden demnach diejenigen Unternehmen aufgenommen, die
gegenwärtig gut auf dem Markt etabliert sind, über eine klare Marktstrategie verfügen
und aktiv daran arbeiten, ihre Führungsposition am Markt aufrechtzuerhalten und weiter
auszubauen.
IBM wird mit dem WebSphere Portal Server in dieser Darstellungsform als das marktführende Produkthaus betrachtet.
Wie bereits erwähnt, hat sich der Portalmarkt in den Jahren 2001-2002 bereits stark konsolidiert. Vor allem die großen Softwareunternehmen gewinnen, im Vergleich zu den
"Portal Only" - Anbietern, zunehmend an Marktanteil. Diese Einschätzung wird durch die
aktuelle, fortschreitende Konsolidierung am Portalmarkt bestätigt. Vor allem
Stand:26.09.03
27 von 53
Unternehmen der "Portal Only" - Kategorie werden entweder aufgekauft, ziehen ihr
Portalprodukt aufgrund des steigenden Konkurrenzdruckes zurück, versuchen sich als
Nischenanbieter zu etablieren oder müssen Insolvenz anmelden.
Trotz dieses auf den ersten Blick düsteren Szenarios bietet der Portalmarkt immense
Chancen für die "Leader"; die Schätzungen für das durchschnittliche jährliche Wachstum
des weltweiten Marktvolumens für Portalsoftware sind mit 23 bis 46% - je nach Marktforschungsinstitut - durchgehend positiv und liegen damit weit über dem Wachstum der Gesamtausgaben für Unternehmenssoftware.
Aus dem vorab Gesagten lassen sich vor dem Hintergrund der Forderung nach
Zukunftssicherheit und Investitionsschutz folgende Anforderungen an den Portalanbieter
ableiten:
er muss Visionen haben, neue Technologien zu entwickeln und voranzutreiben und
sich an offenen Standards zu beteiligen,
er muss die Finanzkraft haben, den eingangs erwähnten Generationenwechsel
vollziehen zu können und mit dem enormen Evolutionstempo Schritt halten zu können.
IBM ist einer der wenigen Portalanbieter, der beide Anforderungen erfüllen kann und
wird aufgrund dessen von einer Vielzahl von Marktforschungsunternehmen mit dem
Produkt WebSphere Portal Server als marktführendes Unternehmen positioniert.
5.2 Technologiebetrachtung
Der WebSphere Portal Server beruht auf der Basistechnologie WebSphere. WebSphere
ist eine Softwareinfrastruktur für dynamisches e-Business und hat sich von einem Applikationsserver hin zu einer Vielfalt von Produkten und Lösungen mit einer gemeinsamen
Basis entwickelt. Auf offenen Standards basierend, stellt WebSphere die derzeit umfassendste und am schnellsten wachsende e-Business Plattform auf dem Markt dar.
5.2.1 Das Portalframework WebSphere Portal Server
5.2.1.1 Architektur
WebSphere Portal besteht aus Middleware, Anwendungen und Entwicklungstools zur
Erstellung und Verwaltung sicherer Portale. Aus technischer Sicht ist der WebSphere
Portal Server eine J2EE(TM)-Anwendung, die unter dem WebSphere Application Server
ausgeführt wird. Seine Hauptfunktion besteht darin, den WebSphere Portal Funktionsumfang für die Desktopcomputer und Mobilgeräte der Portalbenutzer zur Verfügung zu
stellen. Hierzu erstellt er eine entsprechende Umgebung, in der die erforderlichen Services für Konnektivität, Verwaltung und Darstellung bereitgestellt werden.
Stand:26.09.03
28 von 53
Abbildung 7: Architektur des WebSphere Portal Servers
Wie in der Grafik verdeutlicht, kann auf das Portal mit unterschiedlichen Endgeräten
zugegriffen werden. Alle Endgeräte nutzen den Authentifizierungsservice des
WebSphere Application Servers. Die Präsentationsservices (Page Aggregation) des
Portal Servers erlauben dem User, nur auf die seinem Berechtigungsprofil
entsprechenden Seiten und Portlets zuzugreifen. Die Portalansicht hängt einerseits von
seiner Gruppenzugehörigkeit (z.B. Gruppe Studierende) und der durch ihn selbst
personalisierten Portaloberfläche ab. Neben den Inhalten kann der User auch das Look
& Feel seiner Seiten über Schemata (Themes) und Oberflächen (Skins) verändern.
Durch die Eigenschaften des Portlet Containers und durch die Portal-Services bekommt
der Portalentwickler alle Funktionen zur Verfügung gestellt, um beliebige Applikationen
an das Portal anzubinden und es mit Inhalten zu füllen. Das Portal Framework baut auf
der Basis des J2EE WebSphere Application Servers auf und nutzt dessen Services, wie
z.B. die Java Connector Architecture (JCA), Java Message Service (JMS), Web Service
und Enterprise Java Beans (EJB).
5.2.1.2 Skalierbarkeit
Der WebSphere Application Server stellt weiterhin die Basistechnologie für die Skalierbarkeit des Portals bereit. Da die Benutzerakzeptanz des Hochschulportals stark von
seiner Fähigkeit abhängt, Benutzeranfragen schnell beantworten zu können, muss ein
Portal entsprechende Mechanismen zur Performanceoptimierung und Hochverfügbarkeit
enthalten.
Für die sogenannte horizontale Skalierung stellt die WebSphere Application Server
Technologie Clustering und Loadbalancing zur Verfügung. Über die Module Workloadmanagement und Network Dispatcher wird das Loadbalancing realisiert. Beim
Loadbalancing wird die Last, die durch die Anfragen mehrerer Benutzer am
Hochschulportal entsteht, auf zwei oder mehrere identische Systeme mittels festgelegter
Stand:26.09.03
29 von 53
Algorithmen verteilt und so eine Minimierung der Antwortzeiten erreicht. Durch ein
Clustering auf mehreren Maschinen kann gleichzeitig ein „failover“ für eine höhere
Verfügbarkeit erreicht werden. Hierbei teilen sich zwei oder mehr Systeme einen
gemeinsamen Speicher und können untereinander Informationen über ihren Zustand
austauschen. Fällt das System während der Bearbeitung eines Prozesses aus, kann ein
anderes System unter Zuhilfenahme der Informationen aus dem gemeinsamen Speicher
an eben der Stelle des Bearbeitungsprozesses anknüpfen und ihn ohne Datenverlust zu
Ende führen. Für die Gesamtverfügbarkeit müssen außer dem Portal Server auch die
anderen beteiligten Systeme (Backendapplikationen, LDAP, Web Server, DB) mit
betrachtet werden.
Die sogenannte vertikale Skalierung wird dadurch erreicht, dass zum einen die WebSphere Applikationserver Middleware mit mehreren Prozessoren arbeiten kann, und zum
anderen auch auf den verschiedenen Prozessortechnologien verfügbar ist - unterstützt
werden zur Zeit Windows, AIX, Solaris, Linux Intel, Linux zSeries.
5.2.1.3 Offene Standards
IBM hat erkannt, dass technologisches Wachstum nur unter Verständigung auf gemeinsame Standards nachhaltig geschehen kann. Um die Integrationsfähigkeit zu anderen
Softwarekomponenten sicherzustellen, arbeitet IBM aktiv bei der Definition und Weiterentwicklung diverser Standards mit. Offene Standards wie Linux, XML, J2EE und Web
Services werden offiziell unterstützt und vorangetrieben. Die Portaltechnologie des WebSphere Portal Servers basiert vollständig auf Web- und J2EE-Standards.
Standardisierungsinitiativen speziell im Portalumfeld sind der Java Specification Request
(JSR) 168 und Web Services for Remote Portlets (WSRP), die im Nachfolgenden erläutert werden.
Mit der Standardisierungsinitiative JSR 168 soll die Portlet Schnittstelle (Application
Programming Interface, API) vereinheitlicht werden, um Interoperabilität zwischen
Portlets und Portalen beliebiger Hersteller zu schaffen. Die Portlet-API definiert eine
gemeinsame Basisklasse und Schnittstellen für Portlets, um die Portlets sauber von der
Infrastruktur von WebSphere Portal zu trennen. In vielerlei Hinsicht ist die Portlet-API
eine Erweiterung der Servlet-API, ausser dass sie bestimmte Funktionen auf eine
Teilgruppe beschränkt, die für Portlets, die im Zusammenhang eines Portals aktiv sind,
sinnvoll ist. IBM treibt gemeinsam mit SUN die Standardisierung einer gemeinsamen
Java Portlet-API voran. Das Release der Spezifikation ist für den Anfang des vierten
Quartals
2003
vorgesehen.
Details
zum
JSR
168
können
unter
http://jcp.org/jsr/detail/168.jsp abgerufen werden.
Unter der Führung von IBM haben sich unter anderem Firmen wie Oracle, SAP, BEA und
Plumtree zusammengeschlossen und das OASIS WRSP Technical Commitee
gegründet, um Web Services for Remote Portlets zu standardisieren. Die WSRP
Initiative hat das Ziel, einen Standard für benutzerorientierte und interaktive Web
Services zu definieren, die sich leicht in unterschiedliche Portale integrieren lassen.
WSRP ermöglichen es somit, Portalelemente einer Site in andere Portale einzubinden,
und zwar auf der Grundlage von Web-Services-Standards wie Simple Object Access
Stand:26.09.03
30 von 53
Protocol (Soap) und Web Services Description Language (WSDL), unabhängig davon,
ob diese nun in einer J2EE- oder Microsofts .NET-Umgebung laufen.
Services wie zum Beispiel das Einsehen einer Telefonrechnung im Portal eines
Mobilfunkbetreibers können - unter Einhaltung des WSRP Standards - einfach in das
Hochschulportal integriert werden, ohne dass die Hochschule Portlets entwickeln oder
sich über die Implementierung des Mobilfunkportals Gedanken machen müsste.
Die Version 1.0 von WSRP wurde Anfang September 2003 als OASIS Standard veröffentlicht. Details zu WSRP können unter http://www.oasis-open.org/ abgerufen werden.
5.2.2 Entwicklungsumgebung
Wie in Kapitel 4.2.3 Anwendungsintegration erläutert, können neben vorgefertigten Portlets durch die im Portal Server enthaltene Programmierschnittstelle auch neue Portlets
entwickelt und in das Portal integriert werden. Hierzu stehen dem Entwickler grundsätzlich zwei Tools zur Verfügung: Die im Lieferumfang des Portal Servers enthaltene Entwicklungsumgebung WebSphere Studio Site Developer mit dem Plug In Portal Toolkit
und das Portletentwicklungsprogramm WebSphere Portal Application Integrator.
IBM WebSphere Studio Site Developer (WSSD) ist eine integrierte Entwicklungsumgebung (IDE) zum Erstellen, Testen und Implementieren von J2EE-Anwendungen. WSSD
basiert auf der Eclipse Technolgie und bietet integrierte Entwicklungsunterstützung zum
Erstellen von J2EE-Anwendungen mit HTML-Seiten, Servlets, Java Server-Seiten (JSPs)
und EJBs. Es erstellt Webserviceanwendungen mit offenen Standards, erzeugt XMLDokumente aus Document Type Definitions (DTD) und ermöglicht eine bereichsübergreifende Teamentwicklungsumgebung. Es ermöglicht lokales und fernes End-to-EndTesten und erstellt Anwendungen mit hoher Qualität unter Verwendung von Assistenten,
Codegeneratoren und Best Practices.
Das Portal Toolkit stellt Funktionen zum Anpassen und Verwalten des Unternehmensportals und zum Erstellen, Testen, Debugging und Implementieren einzelner Portlets und
Webinhalte zur Verfügung. Mit Hilfe von Schablonen und Wizards können Entwickler
schnell und einfach eigene Portlets erstellen. Debug- und Implementierungstools verkürzen die Entwicklungszeit. Darüber hinaus werden Beispielportlets zur Veranschaulichung
optimaler Programmiermethoden bereitgestellt.
Das Portletentwicklungsprogramm WebSphere Portal Application Integrator (WPAI) ermöglicht Benutzern, Portlets zu erstellen, die auf Daten in einer Unternehmensanwendung zugreifen und sie verändern können, ohne dass Programmierkenntnisse vom
System erforderlich sind. Durch Auswählen von Business-Objects der Unternehmensanwendung können Benutzer festlegen, welche Datenfelder in Ihrem Portlet angezeigt
werden sollten.
Der Application Portlet Builder unterstützt folgende Anwendungen:
- Oracle und DB2 über JDBC-Verbindung
- Domino Server 5.11, V6
- SAP R/3
- Peoplesoft 7.5, 8
- Siebel 7, 7.5
Stand:26.09.03
31 von 53
5.2.3 Administration
Die gesamte Administrationsoberfläche des Portal Servers ist über Portlets realisiert.
Dies gibt dem Administrator die Möglichkeit, sehr flexibel verschiedene administrative
Tätigkeiten an unterschiedliche Benutzer oder Gruppen (Subadministratoren) zu
delegieren. Abhängig von den weitergegebenen Zugriffsrechten auf die
Administrationsportlets können diese Benutzer die Administration weiter delegieren.
Aufgrund dieser Delegationsmöglichkeit können jedem Fachbereichsadministrator
entsprechende Administrationsrechte zugeteilt werden, womit die Fachbereichsautorität
im Portal problemlos umgesetzt werden kann.
Es existieren Portlets zur Verwaltung von Benutzern, Gruppen und Portlets, das Veröffentlichen und Suchen von Portlets als Web Services, das Verwalten von
Zugriffsrechten, portalweiten Einstellungen und der Protokollerstellung, zur Auswahl von
Darstellungsvarianten, für Sicherheitseinstellungen, zur Verwaltung von Seiten und
Seitengruppierungen, für das Einrichten neuer Endgeräteklassen und dazugehöriger
Markup-Sprachen.
Der gesamten Administration ist ein hierarchisches Rollenkonzept hinterlegt. Das hierarchische Rollenkonzept des Portal Servers ist in Abbildung 8 skizziert.
Abbildung 8: Hierarchisches Rollenkonzept des Portal Servers
Die Rollen werden entsprechend der Hierarchie vererbt. Das bedeutet, dass die
Manager-Rolle auch die Funktionalitäten der Editor- und User-Rolle hat, aber nicht die
Rechte des Privileged-User. Damit gibt es eine Rolle, in der ein User eigene Managerund Editor-Rechte haben kann. Die Vererbung und Weitergabe kann an jeder beliebigen
Stelle unterbrochen werden.
Um die Benutzerakzeptanz des Hochschulportals messen zu können, sollte die Administrationsoberfläche des Portal entsprechende Tools zur Auswertung des Benutzerverhaltens enthalten.
Stand:26.09.03
32 von 53
Um Informationen über die Relevanz der angebotenen Informationen und Dienste zu erhalten, ist im Lieferumfang des WebSphere Portal Servers der Tivoli Site Analyzer enthalten. Das Produkt verwendet die vom Portal Server aufgezeichneten Zugriffe und
Zugriffspfade, um daraus vielfältige Analysen zu erstellen. Diese umfassen zum einen
statische Aspekte wie beispielsweise Häufigkeit der Treffer auf Seiten, Verweildauer auf
Seiten, Häufigkeit der Anmeldung von Benutzern und regionale Herkunft der Benutzer.
Zusätzlich kann aber auch die Folge der betrachteten Seiten analysiert werden sowie
nach fehlerhaften Links im Auftritt gesucht werden. Die Ergebnisse dieser Analysen
ermöglichen eine Restrukturierung der Seiten durch die Seitenautoren basierend auf
dem tatsächlichen Verhalten der Benutzer.
Für die Analyse können vordefinierte Berichtselemente genutzt werden - es besteht aber
auch die Möglichkeit, eigene angepasste Berichtselemente zu erstellen.
Der Tivoli Web Site Analyzer enthält eine integrierte Unterstützung für WebSphere
Portal. Diese Unterstützung beinhaltet spezielle Berichtselemente, die es ermöglichen,
Nutzungsdaten über das Portal zu analysieren, wie zum Beispiel eine Rangordnung der
von den Besuchern angezeigten Portalseiten und Portalanmeldetrends. Bei der
Verwendung dieser Integration wird das Portal so konfiguriert, dass es Anwendungsstufenprotokolle generiert, diese Protokolle in den Tivoli Web Site Analyzer exportiert und
entsprechende Berichte erstellt.
5.2.4 Sicherheit
Bedingt durch das modulare Framework, kann der Portal Server in die verschiedensten
Sicherheitskonzepte eingebunden werden. Die Securitykomponenten für ein Web-Technologie-basierendes Portal wirken immer auf mehreren Ebenen (Netzwerkebene, Zugangsprotokoll, Authentisierung, Autorisierung, etc.). WebSphere Portal Server kann
Security-Dienste des verwendeten HTTP-Servers und des zugrunde liegenden J2EEbasierenden Application Servers (IBM WebSphere Application Server V5) nutzen. Darüber hinaus bietet der WebSphere Portal Server eigene Security Dienste wie z.B. Credential Vault für die Realisierung einer unternehmensweiten Single Sign On (SSO)
Implementierung. Hierbei werden die sogenannten "Credentials", also zum Beispiel
Benutzername und Passwort in einem sicheren Schliessfach abgelegt und bei Bedarf für
den im Portal authentisierten Benutzer transparent und sicher an das Hintergrundsystem
weitergereicht. Unter Verwendung des Single Sign On braucht sich ein Benutzer nur
noch einmal authentifizieren (Anmeldung am Portal) und seine Identität wird an die
Hintergrundanwendungen übergeben, ohne dass erneut eine Identitätsüberprüfung
erforderlich ist.
Wie in Abbildung 9 skizziert, wird der SSO gegenüber den Backend Applikationen aus
Portalsicht über den portalinternen Credential Vault Service, in dem die Benutzercredentials abgelegt werden, realisiert (Portal-Backend SSO). Werden neben dem Portal Server
noch weitere Webapplikationen betrieben, so werden diese gemeinsam über einen
Authentication Proxy zum Client-Web SSO zusammengefasst.
Stand:26.09.03
33 von 53
Beim Client-Web SSO wird zur Authentisierung ein LTPA Token (Lightweight Third Party
Authentication) verwendet. Wenn ein Benutzer authentifiziert wurde, wird ein „LTPA
single sign on Cookie“ mit den authentifizierten Benutzer Credentials ausgestellt. Dieses
verschlüsselte Cookie wird von allen in der WebSphere Domain befindlichen Applikationen akzeptiert.
Beim Portal-Backend SSO holt sich das Portlet für den Zugriff auf die geschützte
Applikation aus dem Credential Vault Service, die Credentials, um sich an der Backend
Applikation zu authentifizieren. Die Authentifizierungscredentials werden entweder in der
lokalen, portalservereigenen Datenbank oder im externen IBM Tivoli Access Manager
gespeichert.
Portal-Back End
SSO
Client-Web App
SSO
Web
Application
Client
Client
Authentication
Proxy
Portal
Server
Client
Client
Back End
Application
Portlet
Portlet
Portlet
Web
Application
Back End
Application
Back End
Application
Abbildung 9: Single Sign On im WebSphere Portal Server
Um ein unternehmensweites Single Sign On zu erhalten, müssen die zwei Bereiche
Client Web SSO und Portal Backend SSO zusammengefasst werden. Die Zusammenführung kann durch den Tivoli Access Manager, der im Tivoli Konzept beschrieben wird,
realisiert werden.
Um die Vertraulichkeit der Daten zu gewährleisten, kann die Kommunikation zwischen
LDAP-Server, WebSphere Portal und WebSphere Application Server sowie die Kommunikation der Portlets mit der Backend-Anwendung über die Verwendung des Secure
Socket Layer-Protokolls (SSL) verschlüsselt und somit gesichert werden.
Stand:26.09.03
34 von 53
6 Investitionen für die Realisierung
6.1
Projektvorgehen
Die Einführung eines Portals erfordert neben der eigentlichen Installation der Software
und dem Einspielen der Inhalte vor allem konzeptionelle Phasen, die diesen Schritten
vorausgehen. In dem hier vorgestellten Vorgehensplan gehen wir davon aus, dass die
prinzipielle Entscheidung für die Einführung des Portals bereits stattgefunden hat, und
dass das Projektteam, insbesondere der Verantwortliche für die Umsetzung der Portaleinführung, benannt ist.
Bei der Einführung sollte die Konzeption die Gesamtzielsetzung im Auge behalten, in
einer ersten Phase sollten allerdings nur schnell und einfach zu realisierende Bausteine
eingebunden werden, damit die Komplexität der Einführung nicht zu groß wird. Ein
Portalprojekt ist immer ein iteratives Projekt, da das Portal lebt - es werden im Laufe
seiner Existenz immer wieder neue Anwendungen und Funktionalitäten hinzufügt.
Die nachfolgend geschätzten Aufwende sind Gesamtaufwendungen, die durch die Hochschule und/oder externe Dienstleister erbracht werden können. Sie unterliegen großen
Varianzen, da sie stark von den vorhandenen Skills und den lokalen Gegebenheiten der
jeweiligen Hochschule abhängen. Sie können daher nur ein Gefühl dafür geben, mit welchen realen Aufwenden gerechnet werden muss. Bei der letztendlichen Planung muss
auch die Komplexität der vorhandenen Infrastruktur, die Komplexität der Zielinfrastruktur,
und damit auch die Größe der jeweiligen Hochschule beachtet werden. Andrerseits
können Synergieeffekte genutzt werden, da potentiell alle Hochschulen des Landes
NRW die hier vorgeschlagene Portallösung einführen können.
Die IBM und die Servicetöchter der IBM können die Einführung des Portals vielfältig
unterstützen. Die Dienstleistungen umfassen den gesamten Projektrahmen, von der
Analyse und Konzeption bis hin zur Installation oder Implementierung von Portlets. Je
nach Zielsetzung kann durch die jeweilige Projektphase auch durch Coaching unterstützt
werden.
Die nachfolgenden Punkte 6.1.1 bis 6.1.5 skizzieren das Vorgehen bei der Einführung
eines Hochschulportals.
6.1.1 Konzeption
Geschätzter Aufwand: 30 Personentage
• Grundsätzlichen Design des Portals
o Layout des Portals
o Einbindung der Fachbereiche, Lehrstühle, Verwaltung, etc.
Das Layout kann auf dem bisherigen Design des Internetauftritts basieren.
• Auswahl der Anwendungen mit hoher Priorität, die ab Einführung bereits
enthalten sein sollen
Stand:26.09.03
35 von 53
•
•
•
Benutzerkonzept und Rollen
Insbesondere auch administrative Rollen für die Wartung des Portals und die
Bearbeitung der Inhalte
Technisches Konzept
o Auswahl der verwendeten Rechner.
o Einbindung in die sonstige technische Infrastruktur (z.B. Anbindung an
das Identity Management)
o Anbindung zentraler bestehender Anwendungen (eMail/Kalender, HIS, eLearning)
Dokumentation der Prozesse
o Prozesse zur Wartung des Systems (Starten, Stoppen, Sichern)
o Prozesse zur Bearbeitung der Inhalte
6.1.2 Installation und Konfiguration
Geschätzter Aufwand: 10-25 Personentage (abhängig von der lokalen Infrastruktur) plus
Aufwand für die einzubindenden Anwendungen
• Installation des Portal Servers
• Installation oder Anbindung des Web Content Management Systems (WCMS)
• Konfiguration von Portal Server und WCMS
• Integration der priorisierten Anwendungen
6.1.3 Test
Geschätzter Aufwand: 5 Personentage
• Test des Redaktionssystems des WCMS
• Test des Portals unter Betrachtung aller unterschiedlichen Rollen
• Test der Personalisierung des Portals
• Test jeder einzelnen Anwendung des Portals und aller
Interaktionsmöglichkeiten
umgesetzten
6.1.4 Go-Live
6.1.5 Einbindung weiterer Inhalte
Dies ist ein iterativer Prozess, der Aufwand ist abhängig von der jeweiligen Anwendung.
Beispiele für die Aufwände stehen im Kapitel 6.3 „Detaillierte Use Cases“.
Für jede einzelne Anwendung werden folgende Schritte durchgeführt.
• Auswahl weiterer Anwendungen
• Konzeption der Umsetzung
• Realisierung
• Test
• Einführung
Stand:26.09.03
36 von 53
6.2 Potentielle Rollen innerhalb eines Hochschulportals
Die nachfolgend aufgeführten Rollen stellen potentielle Rollen eines Hochschulportals
dar. Sie beinhalten Personen und Gruppen von Personen, welche in einer spezifischen
Ausprägung einen Zugriff auf das Portal haben sollten.
•
Die Allgemeinheit
Diese Gruppe stellt die allgemeinste Benutzergruppe dar, sie ist geprägt von
einem allgemeinen Zugriff auf ein Portal und hat keinen spezifischen Zugriff auf
Anwendungen. Diese Gruppe stellt den nicht-authentifizierten User des Portals
dar. Für diese Gruppe sollte der Zugriff auf allgemeine Informationen der Hochschule sichergestellt werden.
•
Studierende
Diese Gruppe benötigt einen spezifischen Zugriff auf alle Informationen und
Tools (Anwendungen), die allgemein für Studierende an einer Hochschule zur
Verfügung gestellt werden. Die Steuerung dieses Zugriffes sollte über den
Immatrikulationseintrag und zusätzlich über den Nachweis der Semestergebühr
erfolgen. Des Weiteren lässt sich diese Gruppe in Untergruppen nach Fakultäten
unterteilen, da es wenig Sinn macht, allen Studierenden den Zugriff auf die
Informationen aller Fakultäten zu ermöglichen.
•
Mitarbeiter
Mitarbeiter benötigen Zugriffe auf alle Informationen und Tools, die für ihre spezifische Arbeit erforderlich sind. Wir müssen zwei Untergruppen unterscheiden,
wissenschaftliche Mitarbeiter und Mitarbeiter der Verwaltung.
Während der wissenschaftliche Mitarbeiter Zugriffe auf verschiedenste Anwendungen und Informationen benötigt, macht es beim Verwaltungsmitarbeiter sicher
wenig Sinn, Zugriffe auf fachspezifische Informationen oder Anwendungen zu
erlauben.
•
Professoren
Professoren sind vom Zugriffsprofil analog dem wissenschaftlichen Mitarbeiter
einzustufen. Teilweise haben diese noch Zugriffe auf bestimmte Bereiche, die
seitens des Professorenkollegiums notwendig sind.
•
Ausschüsse und andere Gruppen
Ausschüsse stellen eine Gruppe dar, die einerseits zeitlich unbefristet,
andrerseits aber auch zeitlich befristet agieren kann. Hierzu gehören ausgewählte
Nutzer, welche Studierende, Mitarbeiter, Professoren etc. sein können. Wird ein
Nutzer in einen Ausschuss gewählt, muss sein Nutzerprofil so angepasst werden,
dass dieser automatisch Zugriff auf Informationen dieses Ausschusses hat .
•
Studentische Mitarbeiter
Studentische Mitarbeiter sind einerseits Studierende, andrerseits aber auch Mitarbeiter meist innerhalb eines Institutes (der eigenen Fakultät oder einer
anderen). In diesem Falle benötigen diese Studierende einen Zugriff auf die
Stand:26.09.03
37 von 53
Ressourcen des jeweiligen Institutes.
6.3 Detallierte Use Cases
In diesem Abschnitt werden die zuvor beschriebenen Anforderungen als detaillierte Use
Cases dargestellt, die Umsetzung skizziert und eine grobe Aufwandsschätzung
gegeben. Bei der Aufwandsschätzung muss beachtet werden, dass diese ohne
Kenntnisse der konkreten Infrastruktur, Datenquellen und Backend-Verfahren der
jeweiligen Hochschule erfolgt. Daher kann sie nur als Richtlinie angesehen werden, die
bei einer konkreten Realisierung unter Kenntnis der Rahmenbedingungen verifiziert
werden muss.
Titel
6.3.1 HIS Integration – Modul QIS
Beschreibung
Das Modul QIS stellt seinerseits eine Internet-Schnittstelle zu den Funktionen verschiedener anderer HIS-Module bereit. Die Funktionalität von QIS umfasst insbesondere die Bereitstellung von Studierendendaten, Durchführen von Rückmeldungen,
Ändern von Adressdaten, Erzeugen von Bescheinigungen für Studierende, Anmeldung zu und Rücktritt von Prüfungen, Erstellen von Notenstatistiken, Noteneingabe
und -ansicht.
Umsetzung
Durch die Internetschnittstelle des Moduls QIS ist die Integration in das Portal mit
Standardfunktionen in relativ kurzer Zeit möglich. Zum Einsatz kann ein iFramePortlet kommen, welches den Inhalt einer bestehenden Webapplikation unverändert
in einem Portlet darstellen kann und damit in das Portal übernimmt. Zugangsdaten
zum Modul QIS und damit zum HIS lassen sich benutzerbezogen dem Portlet
zuordnen und werden durch das Portlet beim Aufruf aktiviert, damit das Portlet die
Authentifizierung beim HIS durchführt. Ist Single Sign On mit dem Indentity
Management System implementiert und ein LTPA Token auch beim QIS nutzbar,
kann die Hinterlegung der Zugangsdaten entfallen.
Aufwand
max. 1 Personentag, bei Adaption für verschiedene User auch mehr
Titel
6.3.2 HIS Integration – Modul LSF
Beschreibung
Das Modul LSF basiert schon komplett auf Internet-Technologien. Die Funktionalität
von LSF umfasst die Verwaltung von Lehrveranstaltungen und den damit
verbundenen Ressourcen.
Stand:26.09.03
38 von 53
Umsetzung
Durch die Internetschnittstelle des Moduls LSF ist die Integration in das Portal mit
Standardfunktionen in relativ kurzer Zeit möglich. Zum Einsatz kann wie bei QIS ein
iFrame-Portlet kommen.
Aufwand
max. 1 Personentag, bei Adaption für verschiedene User auch mehr
Titel
6.3.3 HIS Integration – sonstige Module
Beschreibung
Hierunter fallen alle Module, für die noch keine webbasierende Schnittstelle existiert.
Umsetzung
Alle nicht webbasierenden Module lassen sich nur durch Programmierung entsprechender Portlets in das Portal einbinden. Dazu ist es notwendig, die Schnittstellen der
Module zu untersuchen und zu prüfen, inwieweit von aussen auf diese zugegriffen
werden kann. Existiert ein solches API (Application Programming Interface), lassen
sich sehr komfortable Portlets für die entsprechende Anwendung erstellen.
Aufwand
Derzeit nicht abschätzbar.
Titel
6.3.4 eMail mit Hochschulaccount
Beschreibung
Jeder Studierende bekommt mit der Immatrikulation einen Mailaccount auf dem
hochschuleigenen Mailsystem eingerichtet. Der Zugriff auf diesen Mailaccount wird
über ein entsprechendes Mailportlet geregelt. Je nach verwendetem Mailserver
stehen POP3-, MS-Exchange- und IBM Lotus Notes- Mail Portlets zur Verfügung. Die
Accounts selbst können im Identity Management System verwaltet werden.
Umsetzung
Hier ist nur etwas Anpassungsaufwand notwendig. Diese Funktion gehört zum Basisumfang des IBM WebSphere Portal Servers.
Aufwand
etwa 1 Personentag
Stand:26.09.03
39 von 53
Titel
6.3.5 e-Learning
Beschreibung
Aus dem Hochschulportal erfolgt ein direkter Zugriff auf das e-Learning System. Mit
dem Learning Management System der IBM werden eine ganze Reihe von
Funktionen für die Studierenden abgebildet. Eine genaue Beschreibung befindet sich
in dem entsprechenden Konzept „e-Learning“.
Umsetzung
Einerseits profitiert diese Lösung von der Konsistenz der Plattform - das e-Learning
System der IBM basiert auf der IBM WebSphere Technologie. Andrerseits werden im
e-Learning System Portlets für eine persönliche Kursübersicht (My Courses), Kurskatalog und -suche (Catalog/search), sowie persönliche Aktivitäten (My Activities) bereitgestellt, die in den WebSphere Portal Server eingebunden werden können. Des
Weiteren lässt sich das e-Learning System unter Zuhilfenahme der iFrame-Technologie in das Hochschulportal einbinden.
Die Nutzung von Single Sign On ist selbstverständlich, die Übernahme der Rollen aus
dem Identity Management System ebenso. Damit ist die Einbindung mit Basisfunktionen des Portal Servers sichergestellt.
Voraussetzung ist ein lauffähiges und fertig konfiguriertes IBM Lotus Learning
Management System. Der dort notwendige Aufwand zur Implementierung wird hier
nicht betrachtet.
Aufwand
Je nach Komplexität (Umfang) etwa 3 Tage.
Titel
6.3.6 Projektgruppen/Virtuelle Teams
Beschreibung
Die Zusammenarbeit von Projektgruppen, der Austausch von Dokumenten etc. wird
innerhalb des Portals gesteuert (Teamworkplace). Damit ist das Dokumentensharing
sichergestellt. Des Weiteren sind in diesen Projektgruppen Tools für virtuelle
Meetings (Webkonferenz), Terminplanung, direkter Chat mit Teammitgliedern und
Diskussionsforen sowie Dokumentenablage enthalten. Die virtuellen Teams sind nicht
nur auf Studierende und Professoren und Mitarbeiter beschränkt, ebenso können
externe Teilnehmer eingebunden werden und damit auch Unternehmen in einer Forschungspartnerschaft.
Umsetzung
Hierfür stehen eine Reihe von Standardportlets zur Verfügung, der Anpassungsaufwand ist gering. Zusätzlich gibt es ein so genanntes Collaboration Center, welches
die wesentlichen Komponenten auf einer Portalseite zusammenfasst. Die Steuerung
des Zugriffes erfolgt über Rollen und kann aus dem Identity Management System
übernommen werden.
Stand:26.09.03
40 von 53
Aufwand
etwa 1 Personentag
Titel
6.3.7 Dokumentenablage
Beschreibung
Das Portal stellt ein integriertes Dokumentenmanagement für den Portalbenutzer dar.
Das bedeutet, dass der Nutzer unter Verwendung der Produktivitätstools oder einer
lokalen Applikation Dokumente erstellen oder bearbeiten kann und diese im internen
Dokumentenmanagement des Portals ablegt.
Der Portal Document Manager umfasst die Möglichkeit einer internen Suche und die
Bearbeitung vieler Dokumenttypen über die Produktivitätswerkzeuge im Portal ohne
Client Office Anwendungen.
Umsetzung
Wird mit dem Portal Server installiert.
Aufwand
nach Installation verfügbar
Titel
6.3.8 Integration von Termindatenquellen und Kalender
Beschreibung
Es ist dem Benutzer möglich, Termine anderen Portlets in den Kalender zu übernehmen.
Umsetzung
Es wird eine allgemeine Schnittstelle für den Kalender implementiert, die das Hinzufügen eines Termins durchführt.
Das Portlet, aus dem der Termin übernommen werden soll, wird um die Fähigkeit
erweitert, alle für den Kalender relevanten Daten an das Kalenderportlet zu übertragen.
Aufwand
10-20 Personentage für eine allgemeine Schnittstelle des Kalenders (einmalig)
1-10 Personentage jeweils für die Erweiterung des Quellportlets .
Titel
6.3.9 Semesterstudienplan
Beschreibung
Basierend auf bisherigen Kursen und Prüfungen kann dem Studierenden eine perso-
Stand:26.09.03
41 von 53
nalisierte Information über einen möglichen Semesterstudienplan geliefert werden.
Eine vereinfachte Variante wäre die nicht so stark personalisierte Variante auf Fakultätsebene.
Umsetzung
Ist abhängig von der Umsetzung des allgemeinen Vorlesungsverzeichnis.
Aufwand
Ohne konkrete Analyse nicht schätzbar.
Titel
6.3.10 Laborverfügbarkeit / Raumzuteilung / Raumreservierung
Beschreibung
Bestehende webfähige Raumplanungssysteme können über die üblichen Techniken
eingebunden werden.
Existieren keine Raumplanungssysteme, sehen wir das Thema als zu komplex an, als
dass es als reines Integrationsthema angesehen werden kann.
Umsetzung
Einbindung eines bestehenden webfähigen Verfahrens
Aufwand
1 Personentag
Titel
6.3.11 Einschreibung zu Prüfungen und Seminaren
Beschreibung
Es ist den Studierenden möglich, sich direkt im Portal zu Seminaren bzw. Prüfungen
einzuschreiben. Dazu werden diesen entsprechend ihrem Profil die passenden Seminare und dazugehörige Prüfungen angezeigt. Bei der Einschreibung ist zu prüfen, ob
der entsprechende Platz noch frei ist, dann erfolgt die Einschreibung, andernfalls erfolgt Ablehnung.
Es sind 2 Rollen dazu erforderlich: Die erste Rolle stellt der Studierende dar, der sich
einschreiben will, die anderen Rolle ist mindestens ein wissenschaftlicher Mitarbeiter,
der das Seminar bzw. die Prüfung anlegt.
Umsetzung
Wenn davon ausgegangen wird, dass im ersten Schritt keine Anbindung an ein Vorlesungsverzeichnis durchgeführt wird, dann werden Portlets zur Eingabe und Änderung
von Veranstaltungen sowie Portlets zur Anmeldung bei Veranstaltungen benötigt. In
diesem Fall ist der Prozess genauer zu analysieren.
Stand:26.09.03
42 von 53
Aufwand
20-30 Personentage für eine einfache Lösung
Titel
6.3.12 Generell: Erfassung von Daten und Speicherung in einer
Datenbank
Beschreibung
Es ist dem Benutzer möglich, spezielle Daten in einem Eingabedialog zu erfassen
und diese in einer Datenbank zu speichern. Es wird dabei keine weitere Bearbeitung
angestossen. Die Daten können in Übersichtslisten angezeigt werden, über Click-toAction können die Details zu einem Datensatz aus der Übersichtsliste angezeigt
werden.
Beispiele für diesen Anwendungsfall sind zum Beispiel die Erfassung von Störungsmeldungen, von Veröffentlichungen, von Inventar, etc.
Umsetzung
Das Portlet wird mit Hilfe der Entwicklungsumgebung ohne spezielle Java-Kenntnisse
zusammengestellt. Der Zugriff auf die Datenbank erfolgt über JDBC durch das
Portlet.
Aufwand
ca. 1-3 Personentage
Titel
6.3.13 Externe Diskussionsforen
Beschreibung
Externe Diskussionsforen sind leicht einzubinden, wenn diese über eine Webschnittstelle verfügen, dazu steht wieder das iFrame oder das Clipping Portlet zur
Verfügung.
Andernfalls ist zu prüfen, ob eine Anbindung über Webservices möglich ist oder ob
eine Neuerstellung eines entsprechenden Portlets sinnvoll ist.
Umsetzung
Bei iFrame oder Clipping ist nur Customizing notwendig, im Falle von Webservices
oder Neuprogrammierung wird der Aufwand etwas umfangreicher. Ausserdem stehen
im Portletkatalog vergleichbare Portlets zur Verfügung .
Aufwand
Im ersten Fall weniger als 1 Personentag, andernfalls ca. 3 Personentage
Stand:26.09.03
43 von 53
Titel
6.3.14 Allgemeine Informationen zum Studienort
Beschreibung
Hierzu zählen beispielsweise Verkehrspläne, Stadtpläne, Stadtinformationen. Es
sollte nach Rücksprache mit dem jeweiligen Anbieter problemlos möglich sein, diesen
Content in Form eines Portlets in das Portal mit einzubinden. Für den Anbieter führt
dies in jedem Fall zu einer Steigerung der Zugriffszahl durch die erzielte
Werbewirkung.
Umsetzung
Da diese Informationen normalerweise schon webbasierend zur Verfügung stehen, ist
es problemlos mit einem iFrame Portlet möglich, den Content des Anbieters als
eigenständiges Portlet einzubeziehen. Alternativ bietet sich auch das Web-Clipping
Portlet an, wenn neben der eigentlichen Information noch weitere nicht relevante
Daten Bestandteil einer solchen Site (Bannerwerbung etc.) sind.
Sind die Voraussetzungen (Freigabe des Inhaltsanbieters) gegeben, ist die Umsetzung mit einfachen Mitteln sehr schnell möglich.
Aufwand
etwa 1 Personentag
Titel
6.3.15 Hochschulnewsticker
Beschreibung
Laufende Darstellung von aktuellen Informationen in einem Portlet
Umsetzung
Wird ein vorhandener Newsticker der Hochschule verwendet, sollte dieser in der Lage
sein, den Content in Form eines RSS-Formates zu liefern. Dann ist der Einsatz eines
RSS-Portlets angebracht.
Andernfalls erfolgt die Bereitstellung der Informationen über das WCMS.
Aufwand
Im ersten Fall weniger als 1 Personentag, im zweiten Fall unter 3 Personentagen
Titel
6.3.16 Bibliotheksrecherche / Reservierung
Beschreibung
Es wird davon ausgegangen, dass die Bibliothek derzeit schon über ein Webfrontend
verfügt. Damit ist eine sehr schnelle Einbindung in das Portal möglich und es stehen
sofort alle Funktionen dieses Frontends zur Verfügung. Sollen weitere Funktionen darüber hinaus als Portlet verfügbar gemacht werden, muss dies entsprechend
programmiert werden.
Stand:26.09.03
44 von 53
Umsetzung
Die Einbindung einer Standardweboberfläche erfolgt wie bisher mit dem iFrame
Portlet oder Clipping Portlet. Single Sign On ist möglich, alternativ kann für jeden User
der Account dem Portlet mitgegeben werden, damit die Anmeldung durch das Portlet
erfolgt.
Aufwand
Bei Nutzung von iFrame oder Clipping: max. 1 Personentag, evtl. Adaption
notwendig, dann entsprechend höherer Aufwand
Titel
6.3.17 Informationen von Studentenklubs
Beschreibung
Über das Content Management System gibt es die Möglichkeit, dass Studentenklubs
ihre Informationen in Form von Portlets anbieten und verfügbar machen. Diese Informationen können z.B. Newsletter und Veranstaltungskalender sein. Dazu ist es erforderlich, entsprechende Rollen zu definieren und diese auch im WCMS zu hinterlegen
(Verwendung des Identitiy Management Systems), damit die Studentenklubs jeweils
ihren eigenen Content pflegen können.
Hat der Studentenklub seinerseits schon eine Internetpräsenz aufgebaut und pflegt
diese über ein eigenes System, so lässt sich diese wieder mittels iFrame oder
Clipping Portlet problemlos in das Portal mit einbinden.
Umsetzung
Im ersten Fall ist für den Klub eine Rolle zu definieren und ein entsprechender
Account notwendig, damit dieser Zugriff auf das CMS bekommt, um seinen Content
zu pflegen und die entsprechenden Portlets zu generieren.
Im zweiten Fall werden einfach die entsprechenden Portlets generiert.
Aufwand
Mit Nutzung des CMS: etwa 3-5 Personentage
Bei Nutzung von iFrame+Clipping: etwa 1 Personentag
Titel
6.3.18 Studentenwerk
Beschreibung
Das Studentenwerk ist verantwortlich für eine Reihe von Services rund um das Studium. Darunter fallen die Verwaltung von Wohnheimplätzen, Verwaltung der Mensen
(Bereitstellung von Informationen, Essenspläne etc.). Eine Bereitstellung dieser Informationen darf als notwendig angesehen werden.
Über das Content Management System gibt es die Möglichkeit, dass das Studentenwerk seine Informationen in Form von Portlets anbieten und verfügbar machen kann.
Dazu ist es erforderlich, entsprechende Rollen zu definieren und diese auch im CMS
Stand:26.09.03
45 von 53
zu hinterlegen (Verwendung des Identitiy Management Systems), damit das Studentenwerk jeweils seinen eigenen Content pflegen kann.
Hat das Studentenwerk seinerseits schon eine Internetpräsenz aufgebaut und pflegt
diese über ein eigenes System, so lässt sich diese wieder mittels iFrame oder
Clipping Portlet problemlos in das Portal einbinden.
Umsetzung
Im ersten Fall ist für den Klub eine Rolle zu definieren und ein entsprechender
Account notwendig, damit dieser Zugriff auf das CMS bekommt, um seinen Content
zu pflegen und die entsprechenden Portlets zu generieren.
Im zweiten Fall werden einfach die entsprechenden Portlets generiert.
Aufwand
Mit Nutzung des CMS: etwa 3-5 Personentage
Bei Nutzung von iFrame+Clipping: max. 1 Personentag
Titel
6.3.19 Externe Newsticker und Wetter einbinden
Beschreibung
Hierzu werden vom Portal Server bereits einige Portlets bereitgestellt. So lassen sich
Wetter und andere Newsticker z.B. über die Pinnacor Portlets einbinden. Alternativ
kann ein Wetterportlet mittels iFrame oder Clipping generiert werden und ein
Newsletterportlet über das RSS-Portlet.
Umsetzung
Portlets sind im Lieferumfang enthalten. Bei Nutzung von iFrame-, Clipping und RSSPortlet sind diese zu generieren
Aufwand
Max. 1 Personentag
Titel
6.3.20 Externe Dienste
Beschreibung
Es bietet sich an, unter Verwendung von WebServices oder iFrame die Dienste von
externen Partnern wie z.B. „amazon.com“ oder Jobbörsen mit einzubinden.
Umsetzung
Stellt der Partner seinerseits Portlets zur Verfügung, können diese auf die Verwendbarkeit geprüft werden. Evtl. kann auf die Applikation des Partners über WebServices
zugegriffen werden, z.B. in der Form von Remote Portlets. Unter Umständen ist die
Einbindung in Form des iFrames möglich.
Stand:26.09.03
46 von 53
Aufwand
etwa 3 Personentage
Titel
6.3.21 Standard Suchmaschine
Beschreibung
Im Rahmen des Portals wird eine Suchfunktion für Volltextsuche zur Verfügung
gestellt. Diese Suche bezieht sich auf Standarddateiformate.
Suchfunktionen
• Crawl über eine oder mehrere Webseiten zur Erstellung von Indizes
• Internetähnliche Suchmöglichkeiten wie z.B. +/- (plus/minus), "" (bestimmte
Phrasen) und * (Platzhalter)
• Zusammengefasste Ergebnisseiten
• Konfigurationsmöglichkeiten für Indizes, multiple Webseiten in einen Index;
Filterregeln für den Crawler; regelmäßige crawls per Webseite; manueller Start
und Stops von crawls; erweiterte Sprachunterstützung
Umsetzung
Einbindung des Standardsuchportlets mit Konfiguration, Konfiguration des Summarizers für die Ergebnisdarstellung und Konfiguration/Anpassung der Portlets zur Verwaltung der Kategorien innerhalb der Suchtaxonomy
Aufwand
ca. 3-5 Personentage
Titel
6.3.22 IBM Lotus Extended Search
Beschreibung
IBM Lotus Extended Search gehört zum Lieferumfang des WebSphere Portal
Servers. Mit Extended Search ist es nicht notwendig einen neuen, zentralen Index zu
erstellen oder zu verwalten. Extended Search wandelt jede Abfrage in die
Abfragesprache des jeweiligen Zielsystems um und verwendet dessen native Suchund Abfragemechanismen. Dadurch wird der Benutzer von den Komplexitäten im
Umgang mit dem Zielsystem geschützt und eine parallele Suche über mehrere
unterschiedliche Datenquellen ermöglicht.
IBM Lotus Extended Search unterstützt standardmäßig die Suche auf folgende
Datenquellen:
• Lotus Notes 4.x und 5.x, Domino.doc, Lotus Connectors, sowie Domino R5
Domain Index
• ODBC-konforme relationale Datenbanken wie DB2, Oracle, Sybase und MS
SQL-Server
• IBM Enterprise Information Portal (EIP) Datenbanken
Stand:26.09.03
47 von 53
•
•
•
•
Microsoft Site Server Kataloge
Microsoft Index Server Index
Microsoft Exchange Server Mail Datenbanken
LDAP-konforme Verzeichnisse (z.B. MS Active Directory, Domino)
•
Viele gebräuchliche Internet Suchmaschinen (u.a. Google, Excite, Altavista,
Lycos) und Nachrichtenseiten kommerzielle Inhaltsanbieter
Umsetzung
Kategorie 1:
Datenquellen, die nicht über Web Technologie erreicht werden sollen, z.B. dBase
oder eigene Datenbank Systeme, die nicht ODBC fähig sind.
Hierfür ist die Erstellung von neuen Links und Grammar notwendig. Eine Link Library
beinhaltet Programmlogik, die für den Zugriff auf die Datenquelle und die Ausführung
von Abfragen, verwendet wird. Ein Grammar beinhaltet Programmlogik, womit die
Abfrage von der generischen Generalized Query Language (GQL) des Extended
Search in die native Abfragesprache des Zielsystems umgewandelt wird (z.B. von
GQL zu SQL).
Links und Grammar können durch Verwendung der mitgelieferten Programmiertools
des IBM Lotus Extended Search erstellt werden. Ein erfahrener LotusScript Programmierer benötigt zwischen 3 - 6 Tagen (inkl. Dokumentation) zur Realisierung. Voraussetzung ist, dass die neue Datenquelle überhaupt eine Schnittstelle nach aussen hat,
über die sie dann erreichbar wäre.
In diese Kategorie würde z.B. die Anbindung des Produkts mindaccess von insiders
GmbH fallen, da mindaccess eine Java Schnittstelle anbietet, um auf deren
Datenbestände zugreifen zu können.
Kategorie 2:
Datenquellen, die über Web Technologie erreicht werden können.
Hierfür ist die Erstellung einer oder mehrerer Web Source Definiton Files (.SBB) notwendig. In diesen Dateien wird beschrieben, wie die Suchanfrage an eine Suchmaschine zu übergeben ist (in welchen Feldern, welche Inhalte mit welcher Syntax) und
in welcher Form die Suchergebnisse zurückgegeben werden, um diese dann in die
gemeinsame Ergebnisliste des Extended Search übergeben zu können.
Aufwand
Je nach Umfang zwischen 5 und 10 Personentagen
Stand:26.09.03
48 von 53
6.4 Allgemeine Hardwarebetrachtung
Auf der Basis von Benchmarks und aus Erfahrungen in Kundenprojekten hat IBM Methoden zur Bestimmung der Grössenordnung der für eine Webanwendung benötigten Hardware entwickelt. Diese Methoden werden als Sizing bezeichnet.
Als Eingangsparameter dienen üblicherweise bei einem Sizing:
- Plattform (Betriebssystem, Hardware)
- Architektur (1-, 2- oder 3-tier Architektur)
- Anwendungsmuster (hier Portal)
- Geforderte Antwortzeit
- Anzahl der Neuanmeldungen (je Sekunde)
- Anzahl der aufgerufenen Webseiten
- Durchschnittliche Verweildauer je Webseite
- Anzahl der Pageviews, die am Portal ankommen
- Maximal zulässige Hardwareauslastung
Da sich neben diesen Parametern noch weitere Einflussfaktoren aus den individuellen
Kundensituationen ergeben, wie z.B. die Netzwerklast, das letztendliche Anwendungsdesign und Anforderungen an die Verfügbarkeit, kann ein Sizing mithin nur eine
Abschätzung sein, um einen ersten Eindruck für die benötigten Hardwareressourcen zu
gewinnen.
Als Ergebnis des Sizings werden Vorschläge zu
- Anzahl und Typ der Systeme,
- Anzahl, Typ und Leistungsmerkmalen der Prozessoren und
- Hauptspeicherbedarf des jeweiligen Systems
gegeben, wobei die später im Realbetrieb gemachten Erfahrungen durchaus von den
Sizingergebnissen abweichen können. Darüber hinaus werden Empfehlungen bezüglich
Hochverfügbarkeit und Lastverteilung gegeben und auch Angaben zu der zu
erwartenden Systemlast gemacht.
Da die WebSphere-Technologie sehr gut skaliert, kann mit einer kleinen Startkonfiguration und ausgewählten Einsatzszenarien begonnen werden und von diesen relativ leicht
auf grössere Szenarien extrapoliert werden.
Abbildung 10 zeigt eine beispielhafte Startkonfiguration, die im Nachfolgenden erläutert
wird.
Bei webbasierten Anwendungen ist es gängige Praxis, die Produktionsumgebung von
den produktionsvorbereitenden Systemen zu trennen, um eine Beeinflussung des Livebetriebs weitestgehend zu vermeiden.
Das Entwicklungs- und Testsystem dient sowohl der Applikations- als auch Templateentwicklung und der Erprobung dieser erstellten Anwendungen und Vorlagen.
Das Redaktions- und Stagingsystem dient dem Einpflegen neuen Contents und der
Überprüfung, wie sich dieser Content darstellt.
Stand:26.09.03
49 von 53
Abbildung 10: Beispielhafte Startkonfiguration
Die Produktionsumgebung, auf der die Portal- und Web-Content-Management-Anwendungen letztendlich im Wirkbetrieb ausgeführt werden, ist in diesem Beispiel als 3-tier
Architektur gewählt, dass heisst Datenbank, logische Verarbeitung und Präsentation sind
voneinander getrennt.
Es sind jedoch auch 2-tier oder 1-tier Architekturen möglich, d.h. die genannten 3
Ebenen werden dann auf einem Rechner betrieben.
Eine 3-tier Architektur hat jedoch den Vorteil, dass die einzelnen Ebenen für sich betrachtet natürlich geringere Systemanforderungen haben und nur dem tatsächlichen
Bedarf entsprechend ausgestattet sein müssen. So können im Sinne einer Investitionssicherung existierende Systeme wiederverwendet werden, die nicht mehr der letzten
Rechnergeneration entsprechen, da z.B. der Präsentationsserver (Webserver) relativ
geringe Anforderungen an die Hardware stellt.
Zur Erhöhung der Verfügbarkeit, sollte man, neben der Auslegung als 3-tier Architektur,
eine redundante Auslegung der 3 Ebenen in Betracht ziehen und die Clustermöglichkeiten der WebSphere-Technologie ausnutzen.
Die Darstellung mag auf den ersten Blick den Eindruck erwecken, dass die Beispielarchitektur zu einer erhöhten Komplexität führt. Andrerseits muss jedoch auch in Betracht
gezogen werden, über wieviele Systeme mit ähnlicher Funktion heute die Web-Präsentationen der Fachbereich betrieben werden, die durch ein Portal als Hochschulplattform
konsolidiert werden können. Bei dem dargestellten System handelt es sich um ein zentralisiertes System, welches die Fachbereiche von den Routinetätigkeiten der Infrastrukturbetreuung befreit, ihnen andrerseits jedoch weiterhin völlige Freiheit bei der inhaltlichen und gestalterischen Ausführung der Aussenpräsentation gibt.
Stand:26.09.03
50 von 53
6.5 Enthaltene Softwarekomponenten
Die im WebSphere-Teil der Software Generallizenz enthaltenen Softwarekomponenten
sind der IBM WebSphere Portal Server Extend V5 und IBM Lotus Workplace Web
Content Management.
Die nachfolgend aufgelisteten Module sind in dem Paket WebSphere Portal Server
Extend Version 5 enthalten:
•
•
•
•
•
•
•
•
•
•
•
•
•
WebSphere Portal
IBM WebSphere Application Server, Enterprise Version 5.0
DB2 Enterprise Edition, Enterprise Server Edition Version 8.1
IBM Lotus Domino Enterprise Server 5.0.12
IBM Lotus Extended Search 4.0
Instant messaging and online awareness, based on Lotus Sametime 3.0 technology
Virtual teamrooms based on Lotus QuickPlace 3.0.1 technology
Lotus Collaboration Center Version 5.0
IBM Tivoli Web Site Analyzer Version 4.5
WebSphere Translation Server Version 5.0
IBM WebSphere Studio Site Developer Version 5.0.1
Portal Toolkit
IBM Directory Server Version 5.1
Teilweise sind die oben genannten Module ausschließlich für die Nutzung im Portalkontext lizensiert. Weitere ausführliche Informationen zu den einzelnen Modulen des WPS
Extend V5 finden sich unter http://publib.boulder.ibm.com/pvc/wp/500/ent/en/InfoCenter/
index.html.
IBM Lotus Workplace Web Content Management kann sowohl in Verbindung mit dem
WebSphere Portal Server eingesetzt werden als auch als Standalone Lösung betrieben
werden. Auch die Nutzungsrechte für die Vollversion des IBM Lotus Workplace Web
Content Management sind in der Software Generallizenz für die Hochschulen in NRW
enthalten.
Stand:26.09.03
51 von 53
7 Zusammenfassung
Mit der sich seit 1998 entwickelnden Portaltechnologie hat sich ein Segment im
Softwaremarkt etabliert, welches einerseits durch ein enormes Wachstum und
andrerseits durch eine enorme Innovationsgeschwindigkeit geprägt ist.
Portale bieten ein enormes Nutzenpotential, wie zum Beispiel die beschriebene Unterstützung der Studierenden und die Zusammenführung verteilter Ressourcen. Darüber
hinaus stellen Portale aber auch eine führende Technologie dar, welche die EDV-Landschaft gegenwärtig entscheidend mitprägt. Hochschulen in ihrer Funktion als Technologiepioniere werden von der IBM als prädestinierte Partner angesehen, den Einsatz
dieser Schlüsseltechnologie voranzutreiben.
IBM bietet mit dem WebSphere Portal Server ein marktführendes Produkt an, welches
auf der jahrelang erprobten Infrastruktursoftware WebSphere Application Server basiert.
Dieses technologische Fundament und die Innovations- und Finanzkraft der IBM bieten
unter den Rahmenbedingungen der Generallizenz - wie z.B. der mindestens fünfjährigen
Laufzeit, welche Support und den Zugriff auf die jeweils aktuelle Produktversion enthält ein Höchstmass an Planungssicherheit und Investitionsschutz.
Die Generallizenz ermöglicht den Hochschulen den Zugriff auf dieses umfangreiche
Technologieset zu Rahmenbedingungen, in denen Aufwand und Leistung in einem sehr
attraktiven Verhältnis stehen.
Stand:26.09.03
52 von 53
8 Abbildungsverzeichnis
Abbildung 1:
Abbildung 2:
Abbildung 3:
Abbildung 4:
Abbildung 5:
Abbildung 6:
Abbildung 7:
Abbildung 8:
Abbildung 9:
Abbildung 10:
Stand:26.09.03
Exemplarische Darstellung eines Portal als Hochschulplattform…….. 3
Überblick funktionale Portalarchitektur………………………………….. 7
Vergrösserung Portlet……………………………………………………... 8
Collaboration Center des Portal Servers……………………………..... 17
Integrierte Gesamtlösung………………………………………………... 21
Matrix Portalmarkt nach Gartner Group………………………………... 27
Architektur des WebSphere Portal Servers…………………………….29
Hierarchisches Rollenkonzept des Portal Servers……………………. 32
Single Sign On im WebSphere Portal Server…………………………. 34
Beispielhafte Startkonfiguration………………..……………………….. 50
53 von 53

Aussenpräsentation und Anwendungsintegration

Transcription

Documents pareils

Die Fakten zu Ramco Systems

Intercom Gruppe

IT-Systemadministrator (m/w) – Schwerpunkt Virtualisierung / Storage

Internetadressen

Allgemeine Hotel- und Gastronomie-Zeitung (AHGZ)

mySAP Human Resources (HR)

eine hochverfÜgbare unD ausfallsichere systemumgebung auf

Business Process Outsourcing

WWS-Neuprogrammierung mit ILE RPG und WOPIXX

Musterbrief Genehmigung zur Tierhaltung