Entwurf und Implementierung eines komponentenbasierten Portalsystems mit ASP.NET-Technologie

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

1 Einleitung
1.1 Problemstellung und Zielsetzung
1.2 Gang der Untersuchung

2 Entwurf verteilter Softwaresysteme
2.1 Softwarearchitektur
2.2 Architektur- und Entwurfsprinzipien
2.3 Musterorientierte Softwarearchitektur

3 Portalsysteme
3.1 Definition und Klassifizierung
3.2 Referenzarchitektur

4 Komponentenbasierte Softwareentwicklung
4.1 Schichtenbildung
4.2 Präsentationsschicht
4.2.1 Benutzeroberflächenkomponenten
4.2.2 Benutzerprozesskomponenten
4.3 Anwendungsschicht
4.3.1 Geschäftsworkflows
4.3.2 Geschäftskomponenten
4.3.3 Dienstschnittstellen
4.3.4 Geschäftsentitäten
4.4 Datenzugriffsschicht
4.4.1 Datenzugriffslogikkomponenten
4.4.2 Dienstagenten

5 Microsoft .NET
5.1 NET Framework
5.2 Komponentenmodell von .NET
5.3 ASP.NET
5.3.1 Web Forms
5.3.2 ASP.NET-Serversteuerelemente
5.3.3 Zustandsverwaltung
5.4 ADO.NET
5.4.1 Architektur
5.4.2 Verbundene Objekte
5.4.3 Unverbundene Objekte

6 Praxisprojekt IWIPortal
6.1 Anforderungsanalyse
6.2 Architektur
6.3 Entwurf von Komponenten
6.3.1 Präsentationsschicht
6.3.1.1 Seitenstruktur und -layout
6.3.1.2 Navigationsstruktur
6.3.1.3 Module und Modulsteuerelemente
6.3.1.4 Globalisierung
6.3.1.5 URL-Management
6.3.1.6 Integration von Komponenten der Drittanbieter
6.3.2 Anwendungsschicht
6.3.2.1 Geschäftentitäten
6.3.2.2 Geschäfstkomponenten
6.3.2.3 Objektrelationale Abbildung
6.3.3 Datenzugriffsschicht
6.3.3.1 Generative Programmierung und gespeicherte Prozeduren
6.3.3.2 Datenzugriffslogikkomponenten
6.3.3.3 Caching-Komponente
6.4 Schichtenübergreifende Konzepte
6.4.1 Klickverfolgung
6.4.2 Sicherheit
6.4.2.1 Authentifizierung, Autorisierung, sichere Kommunikation
6.4.2.2 Portaladministration
6.5 Migration

7 Schlussbetrachtung

Anhang

A Namensgebung für Komponententypen

Literaturverzeichnis

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abb. 1: Referenzarchitektur für Portalsysteme

Abb. 2: Contentorientierung

Abb. 3: Community-Dienste

Abb. 4: Aufgabenunterstützung durch Collaboration & Groupware-Komponenten

Abb. 5: Drei-Schichtenarchitektur

Abb. 6: Komponententypen

Abb. 7: Entwurf der Benutzeroberfläche

Abb. 8: Trennung der Benutzeroberfläche vom Benutzerprozess

Abb. 9: Entwurf von Benutzerprozesskomponenten

Abb. 10: Geschäftsworkflow

Abb. 11: Geschäftskomponenten

Abb. 12: Plattformunabhängiges Konzept im .NET Framework

Abb. 13: Sprachintegration

Abb. 14: Namensraumhierarchie

Abb. 15: Grundlegende Struktur einer Assembly

Abb. 16: .NET Komponenten: Komponente vs. Steuerelement

Abb. 17: .NET Komponenten: zwei Steuerelementarten

Abb. 18: Vererbung bei Web Forms (Code-Behind-Modell)

Abb. 19: Ereignisorientierte Programmierung in ASP.NET

Abb. 20: ASP.NET-Serversteuerelemente

Abb. 21: ADO.NET-Objektmodell

Abb. 22: Aufbau eines DataSet

Abb. 23: Anwendungsfalldiagramm

Abb. 24: Architektur des IWIPortals

Abb. 25: Seitenvorlage

Abb. 26: Klassendiagramm: Seitenvorlage

Abb. 27: ER-Diagramm: Definition der Portalseiten

Abb. 28: Seitennavigation mit Menü und Brotkrumen

Abb. 29: Hierarchische Daten und MPTT-Algorithmus

Abb. 30: Modulübergreifende Navigation

Abb. 31: Klassendiagramm: Modulaktionen

Abb. 32: Klassendiagramm: Ereignisverarbeitung für Modulaktionen

Abb. 33: ER-Diagramm: Modularar Aufbau

Abb. 34: Klassendiagramm: Module

Abb. 35: ER-Diagramm: Globalisierung

Abb. 36: Globalisierungsarchitektur

Abb. 37: Satellitenassembly

Abb. 38: Komponente CommonResourcesManager

Abb. 39: Komponente Globalization

Abb. 40: Vererbungskonzept bei Verwendung von Ressourcen

Abb. 41: Sequenzdiagramm: Spracheinstellung I

Abb. 42: Sequenzdiagramm: Spracheinstellung II

Abb. 43: URL-Management

Abb. 44: Klassendiagramm: Geschäftsentitäten für Portaleinstellungen

Abb. 45: Klassendiagramm: Geschäftsentitäten für Moduleinstellungen

Abb. 46: Geschäftskomponenten

Abb. 47: Anwendungsschicht: ComponentFactory

Abb. 48: Schnittstellenspezifikation der Geschäftskomponente PortalSettings

Abb. 49: Schnittstellenspezifikation der Geschäftskomponente ModuleSettings

Abb. 50: Klassendiagramm für Persistenzattribute

Abb. 51: Generierung der Geschäftsentität für eine Portalseite

Abb. 52: OR-Mapper: Paketdiagramm für Fassaden und Dienstagenten

Abb. 53: Klassendiagramm: OR-Mapper

Abb. 54: Komponenten der Datenzugriffsschicht

Abb. 55: Generative Programmierung

Abb. 56: Datenzugriffslogikkomponenten

Abb. 57: Dienste der Hilfskomponente DALManagerCore

Abb. 58: Entwurf von DALPortalNavigation und DALAnnouncements

Abb. 59: DataReader und Seitenauslagerung

Abb. 60: Optimistische Nebenläufigkeit

Abb. 61: Entwurf der Caching-Komponente

Abb. 62: Klickverfolgung: Prokollierung und Auswertung

Abb. 63: Sicherheit: Authentifizierung

Abb. 64: ER-Diagramm: Rollenbasierte Sicherheit

Abb. 65: Komponenten für Portalsicherheit

Abb. 66: Objektfabrik für die Portalsicherheit

Abb. 67: Schnittstellenspezifikation für Portalsicherheit

Abb. 68: Administrationsmodus des Portals

Abb. 69: DTS-Pakete für Datenmigration

Abb. 70: DTS-Paket DeleteTableContents

Abb. 71: DTS-Paket TablesWithoutFK

Abb. 72: DTS-Paket TablesWithFK

Tabellenverzeichnis

Tab. 1: Workflow-Typen

Tab. 2: Mechanismen zur Zustandsverwaltung in ASP.NET

Tab. 3: Elemente und Komponenten der Seitenvorlage

Tab. 4: Ressourcendateien für IWIPortal

Tab. 5: Integration von Komponenten der Drittanbieter

Tab. 6: Selbst erstellte gespeicherte Prozeduren in der Datenbank

Tab. 7: Berechtigungsarten

Tab. 8: Administrationsfunktionen

Tab. 9: Namensgebung für Komponententypen

1 Einleitung

1.1 Problemstellung und Zielsetzung

Die ersten Softwaresysteme waren monolithische Systeme. Sie entstanden aus dem Bedürfnis heraus, genau ein vorliegendes Problem zu lösen, ohne die Rücksicht auf die verteilte Architektur und Wartbarkeit des Gesamtsystems. Die steigende Komplexität, Dynamik und steigender Umfang von Anwendungen erfordern andere als klassische Softwareentwicklungsmethoden. Es ist der Trend zu beobachten, dass mehr und mehr Aufwand in die frühen Phasen der Softwareentwicklung investiert wird, um diesen gestiegenen Anforderungen gerecht zu werden. Hierzu zählen insbesondere das Anforderungsmanagement und die Softwarearchitektur.

Es werden neue Techniken zur Erstellung flexibler Bausteine, die sich leicht an sich ändernde Anforderungen anpassen lassen und die zugleich mit der Größe der zu entwickelnden Systeme skalieren, benötigt. So ist der Wandel zu beobachten von den frühen Modularisierungstechniken über objektorientierte Systeme hin zu Systemen, die mehrschichtig und komponentenbasiert entwickelt sind. Durch den Einsatz von Komponenten sollen bei der Softwareentwicklung Kosten gesenkt und die Entwicklungseffizienz gesteigert werden.

Die Lösung der vorgestellten Problemstellung erfordert eine genaue Untersuchung moderner Softwaresysteme und deren Bausteine zum Entwurf und zur Implementierung eines komponenten- und webbasierten Portalsystems.

1.2 Gang der Untersuchung

Im zweiten Kapitel werden die Konzepte des Entwurfs verteilter Softwaresysteme vorgestellt. Es wird die im Mittelpunkt stehende Softwarearchitektur definiert und beschrieben, welche Ziele sie verfolgt. Daraufhin werden Architektur- und Entwurfsprinzipien erläutert und die Komponente als der wichtigste Begriff der Softwarearchitektur definiert. Des Weiteren wird untersucht, wie musterorientierte Softwarearchitektur bei der Lösung von Entwurfsproblemen helfen kann.

Das dritte Kapitel untersucht, welche Ziele Portalsysteme verfolgen, wie sie definiert und klassifiziert werden können. Daraufhin wird die Referenzarchitektur für Portalsysteme vorgestellt, wobei der Aufbau und Funktionen eines Portals transparent dargestellt werden. Die Referenzarchitektur fasst portaltypische Gemeinsamkeiten zusammen.

Das vierte Kapitel zeigt die Techniken auf, wie ein größeres Softwaresystem zerlegt werden kann, um die Komplexität zu reduzieren. Es ist aufgeteilt in Hauptschichten, die durch Komponentypen verfeinert sind. Es werden Komponentypen und ihre Rollen im Entwurf beschrieben.

Im fünften Kapitel wird die Microsoft .NET Plattform vorgestellt und untersucht, wie dessen Technologien ASP.NET und ADO.NET die Entwicklung mehrschichtiger, komponentenbasierter Softwaresysteme unterstützen.

Die Umsetzung der theoretischen Ausarbeitung erfolgt im sechsten Kapitel. Auf Basis der Anforderungsanalyse wurde die Architektur des Portalsystems entworfen. Die auf den Hauptschichten entworfenen Komponenten und schichtenübergreifende Basisdienste werden detailliert dargestellt.

2 Entwurf verteilter Softwaresysteme

2.1 Softwarearchitektur

Die Softwarearchitektur ist ein entscheidender Erfolgsfaktor und Voraussetzung dafür, dass ein Softwaresystem im Ergebnis die gewünschte Qualität erreicht. Qualitätskriterien wie Flexibilität, Effizienz, Wiederverwendbarkeit, Wartbarkeit oder Leistungsfähigkeit setzen eine gute Softwarearchitektur voraus, um überhaupt wirksam werden zu können.^[1]

In der Literatur gibt es eine Reihe von Definitionen für Softwarearchitektur. Da sie die Strukturen eines Software- bzw. Anwendungssystems beschreibt, wird sie häufig mit der Architektur eines Gebäudes verglichen.^[2] Ein Merkmal der Softwarearchitektur ist aber die weitgehende Gestaltungsfreiheit. Eine weitgehend akzeptierte Definition stammt von Bass, Clemens und Kazman:

„The software architecture of a program or computing system is the structure or structures of a system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.”^[3]

Eine Softwarearchitektur^[4] beschreibt die Elemente eines Softwaresystems und ihre Beziehungen untereinander. Dies erfolgt auf den obersten Abstraktionsebenen, d.h. unter Verbergen von Elementdetails, die nicht die Art der Nutzung, Verantwortlichkeit oder die Interaktion miteinander betreffen.^[5] Die Elemente sind Softwarebausteine, z.B. Module, Komponenten und deren Schnittstellen, Pakete und Teilsysteme. Dabei bestehen Softwaresysteme nicht nur aus einer, sondern aus mehreren Strukturen (z.B. statische Struktur, Prozessstruktur), die durch unterschiedliche Sichten dargestellt werden.^[6]

Eine Softwarearchitektur ist in entscheidendem Maße dafür verantwortlich, dass das Anwendungssystem alle funktionalen Anforderungen, d.h. fachliche Dienste und insbesondere die oben erwähnten nichtfunktionalen Anforderungen, die auch als Qualitätsanforderungen bezeichnet werden, der zukünftigen Benutzer erfüllt.

Um die Fragen zu beantworten, was die Softwarearchitektur erreichen will und was sie leisten muss, lassen sich Ziele und Aufgaben der Softwarearchitektur formulieren. Die Softwarearchitektur verfolgt vier wesentliche Ziele:

- Effiziente Softwareentwicklung,
- Minimieren von Risiken,
- Schaffen des Verständnisses bei allen Systembeteiligten,
- Festhalten des Kernwissens über das System.

Effiziente Softwareentwicklung

Eine effiziente Softwareentwicklung wird hauptsächlich durch folgende Aspekte erzielt. Erstens ist die Softwarearchitektur das Grundgerüst eines jeden iterativ inkrementellen^[7] Entwicklungsprozesses, so dass neue Anforderungen leichter integriert werden können (Integrationsrahmen). Zweitens bildet Softwarearchitektur die Grundlage für Projektplanung und -management. Die Zuständigkeiten der Teams können z.B. anhand der Architekturbausteine leichter zugeordnet werden, was effektives, verteiltes Arbeiten ermöglicht (Rahmen für die Implementierung). Des Weiteren gibt die Architektur einem Projektmanager Einblick in die Entwicklung auf dem von ihm benötigten Abstraktionsniveau.^[8]

Minimieren von Risiken

Das Minimieren von Risiken erreicht die Softwarearchitektur, indem sie Einflussfaktoren, z.B. Qualitätsanforderungen wie Sicherheit, Portabilität oder Änderbarkeit bereits frühzeitig berücksichtigt und auf der Grundlage dieser Einflussfaktoren Entscheidungen trifft. So ist es möglich vorherzusagen, ob eine Softwarearchitektur in der Lage ist, den gestellten Anforderungen gerecht zu werden.^[9]

Schaffen des Verständnisses

Die Softwarearchitektur dient als Kommunikationsmedium und schafft das Verständnis bei allen am System beteiligten Personen wie Benutzer, Entwickler und Wartungsmitarbeiter. Sie fördert ein wechselseitiges Verstehen, hilft beim Festlegen von Entscheidungen und verhindert den Ausschluss bestimmter Personenkreise aus der Diskussion wegen der sonst zu detaillierten Sichtweise (Feinentwurf, Quellcode) auf die Software.^[10]

Festhalten des Kernwissens

Die Softwarearchitektur als ein übertragbares Modell kann für zukünftige, ähnliche Anforderungen aufweisende Systeme als Basisarchitektur dienen und somit teilweise oder vollständig wieder verwendet werden. Eine erfolgreiche Softwarearchitektur stellt somit ein hochwertiges geistiges Eigentum dar.^[11]

2.2 Architektur- und Entwurfsprinzipien

Modularisierung

Die in den frühen 70er Jahren vorgeschlagene und diskutierte Modularisierung galt als Mechanismus für die Erhöhung der Flexibilität und Verständlichkeit eines Softwaresystems, während sie gleichzeitig zur Verkürzung der Entwicklungszeit beiträgt.

Grundlage der modularen Systeme ist die auf Parnas zurückgehende Idee des Geheimnisprinzips (Information Hiding), welches fordert, dass ein Modul eine Schnittstelle braucht, hinter der es seine interne Realisierung (Implementierung) verbirgt. Dann kann die Implementierung ausgetauscht werden, ohne dass die Umgebung des Moduls davon Kenntnis nehmen muss. Der Aufrufer, der das Modul verwendet, muss nicht wissen, was sich innerhalb des Moduls befindet, er kann sich darauf verlassen, dass seine Schnittstelle genügend Auskunft über die Verwendung gibt. Die Idee der „Information Hiding Modules“ war ein großer Fortschritt gegenüber der Programmwiederverwendung durch Kopieren des Quellcodes.^[12]

Die von Parnas eingeführten „Information Hiding Modules“ sind die Vorläufer der heutigen Softwarekomponenten. Sie sind lediglich reine Entwurfselemente und spielen in Abgrenzung zu Komponenten zur Laufzeit keine entscheidende Rolle.^[13]

Objektorientierung

Die sich Ende der 80er Jahre durchgesetzten objektorientierten Technologien unterscheiden sich von den früheren modularen System dadurch, dass sie anstatt statischer Elemente dynamische Komponenten (Objekte) benutzen, die sich zur Laufzeit eines Systems gegen andere ausgetauscht werden können. Das Objektkonzept erlaubt es, dynamisch viele Instanzen des Moduls zu schaffen und deren Zustand einzukapseln.

Mit objektorientierten Systemen lassen sich dynamisch veränderliche Architekturen beschreiben. Je nachdem, welche tatsächlichen, zur Laufzeit ermittelten und aufgerufenen Objekte aus Vererbungshierarchien in ein Rahmenwerk eingehängt werden, ergeben sich Systeme mit verändertem Verhalten. Objektorientierte Systeme bieten eine ideale Basis für Komponentensysteme.^[14]

Komponentenorientierung

Seit Anfang der 90er Jahre rückt die Komponentenorientierung (z.B.CORBA) in den Mittelpunkt. Seit Mitte der 90er Jahre gewinnt in Erweiterung zu Modularisierung und Objektorientierung der Begriff der Komposition an Bedeutung. Dies bedeutet, dass eine Komponente während der Komposition mit anderen Komponenten verschmolzen und integriert werden kann. Sie kann somit an die jeweilige Einsatzumgebung angepasst werden. Die entsprechende Schnittstelle beschreibt, wie die Komponente mit den anderen zusammengesetzt werden kann. Auf Komponentensysteme wie CORBA oder (D)COM setzen weitergehende Architekturen auf wie .NET oder J2EE.

Definition einer Komponente

Es gibt keine allgemein akzeptierte Definition des Begriffs Komponente. Die Komponente ist einer der wichtigsten Begriffe der Softwarearchitektur und bedarf klarer Kriterien. Zahlreiche Autoren haben sich an der Definition von Komponenten versucht:

- „A software component is a unit of composition with contractually specified interfaces ans explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties.”^[15]
- “A software component is a coherent package of software implementations that
a) has explicit and well-specified interfaces for services it provides;
b) has explicit and well-specified interfaces for services it expects; and
c) can be composed with other components, perhaps customizing some of their
properties, without modifying the components themselves.”^[16]
- “The component is a modular unit with well defined interfaces that is replaceable within its environment. … It has one or more provided and required interfaces, and its internals are hidden an inaccessible other than as provided by its interfaces.”^[17]

Diesen Definitionen folgend wird eine Komponente durch folgende Merkmale charakterisiert, wobei sie:^[18]

- eine oder mehrere Schnittstellen exportiert, die im Sinne eines Vertrags garantiert sind. Hierzu gehört insbesondere die genaue Semantik der Schnittstellen. Jede Komponente, die eine Schnittstelle exportiert, ist eine Implementierung von dieser Schnittstelle,
- andere Schnittstellen importiert, wobei der Import einer Schnittstelle bedeutet, dass die Komponente die Methoden dieser Schnittstelle benutzt. Sie ist erst lauffähig, wenn alle importierten Schnittstellen zur Verfügung stehen,
- die Implementierung versteckt und kann daher durch eine andere Komponente ersetzt werden, die dieselbe Schnittstelle exportiert,
- als Einheit der Wiederverwendung geeignet ist, denn sie kennt nicht die Umgebung, in der sie läuft, sondern macht darüber nur minimale Annahmen,
- aus anderen Komponenten über beliebig viele Stufen zusammengesetzt (komponiert) werden kann.

Es muss nicht notwendigerweise gegeben sein kann, dass sich eine Komponente als Einheit der Auslieferung eignet. Vielmehr ist dies eine optionale Eigenschaft. In dieser Arbeit steht die Wiederverwendbarkeit von Komponenten im Vordergrund.

Komponentenbasierte Softwareentwicklung, d.h. der Einsatz von Komponenten, führt zur Steigerung der Entwicklungseffizienz und ermöglicht, Softwaresysteme besser als monolithische Systeme zu warten und zu skalieren, weil die Komponenten einzeln weiter entwicklet werden können.^[19]

2.3 Musterorientierte Softwarearchitektur

Die Idee, Entwurfswissen in kanonischer Form aufzuzeigen, geht auf Architekten und Städteplaner Christopher Alexander zurück. Er hat in den 70er Jahren als Erster Muster für die Gebäudearchitektur verwendet, indem er eine Architekturtheorie entwickelt hat, in der Planung und Bau auf der Konstruktion sowie der Verwendung von Mustern aufbauen.^[20] Basierend auf dieser Idee entstand die Erkenntnis, dass sich eine Mustersprache auch im Bereich der Softwareentwicklung hervorragend eignen würde. Mitte der 90er Jahre wurden die ersten Entwurfsmuster von Gamma, Helm, Johnson und Vlissides veröffentlicht und der Begriff des Softwaremusters einer breiten Leserschaft nahe gebracht.^[21]

Ein Muster beschreibt ein bestimmtes, in einem speziellen Entwurfskontext wiederkehrendes Entwurfsproblem und präsentiert eine erprobte, generische Lösung. Diese Lösung spezifiziert die beteiligten Komponenten, ihre jeweiligen Zuständigkeiten, die Beziehungen zwischen den Komponenten und die Art deren Zusammenarbeit.^[22]

Durch die Verwendung von Mustern können mehrere Ziele realisiert werden. Weil man auf dem gesammelten Wissen erfahrener Softwareingenieure aufbaut, lassen sich bewährte Lösungen wieder verwenden. Dieses hilft, Entwurfsprobleme wirksam und elegant zu lösen. Folglich kann der Entwurf schneller und effektiver erfolgen sowie die Qualität von Entwurfsentscheidungen verbessert werden. Außerdem entsteht ein gemeinsames Vokabular, das die Diskussion für die Entwickler durch die Anwendung ausdrucksstarker Musternamen erleichtert.^[23]

Existierende Musterbeschreibungen betreffen Software von verschiedener Größenordnung und weisen unterschiedliche Detailvariationen auf. Einige Muster betonen den strategischen Aspekt der Strukturierung in Teilsysteme, andere die Verfeinerung von Teilsystemen und Komponenten oder die Beziehungen zwischen ihnen.^[24] Des Weiteren existieren Muster, die spezielle Aspekte des Entwurfs in einer Programmiersprache oder einer Plattform (z.B. Sun J2EE^[25] oder Microsoft .NET^[26]) ausdrücken. Obwohl z.B. J2EE-Muster im Kontext der spezifischen Plattform beschrieben werden, lassen sich die meisten auch in anderen Umgebungen sinnvoll anwenden. .NET-Muster für Enterprise-Lösungen erweitern beispielsweise bereits beschriebene Muster um weitere Qualitätseigenschaften. Schließlich können Muster vollständig unabhängig vom Anwendungsgebiet sein oder für bestimmte Anwendungsgebiete typisch sein.

In Abhängigkeit vom Umfang eines Softwaresystems und der Abstraktionsebene werden zwei wichtige Musterkategorien identifiziert:

- Architekturmuster und
- Entwurfsmuster.

Architekturmuster

Architekturmuster liegen auf einem hohen Abstraktionsniveau vor. Ein Architekturmuster spiegelt ein grundsätzliches Strukturierungsprinzip zur Organisation eines Softwaresystems wieder. Es beschreibt eine Menge vordefinierter Teilsysteme, spezifiziert deren jeweiligen Verantwortungsbereich und beinhaltet Richtlinien zur Regelung der Beziehungen zwischen den Teilsystemen.^[27]

Die Auswahl eines Architekturmusters stellt eine Grundsatzentscheidung dar, da sie systemweite Struktur festlegt und wird auch als Grobentwurf bezeichnet.^[28]. Die sich anschließenden Entwicklungstätigkeiten, z.B. Feinentwurf der Teilsysteme, Kommunikation und die Zusammenarbeit zwischen Systemteilen oder spätere Erweiterungen werden dadurch beeinflusst. Bekannte Architekturmuster sind die Verwendung von Schichten (Layers) oder die Entkopplung der Benutzerschnittstelle von der Kernfunktionalität und den Daten der Anwendung (Model View Controller, MVC).^[29]

Entwurfsmuster

Entwurfsmuster liegen auf einem niedrigeren Abstraktionsniveau und sind daher für den Architekturentwurf zu feingranular. Ein Entwurfsmuster stellt die Verfeinerung von Teilsystemen oder Komponenten eines Softwaresystems oder Beziehungen zwischen ihnen dar. Es beschreibt eine wiederkehrende Struktur von miteinander kooperierenden Komponenten, die ein allgemeines Entwurfsproblem in einem bestimmten Kontext löst.^[30]

Für die objektorientierte Softwareentwicklung beschreiben Gamma, Helm, Johnson und Vlissides in ihren Entwurfsmustern zusammenarbeitende Objekte und Klassen. Die Entwurfsmuster werden dabei in Erzeugungs-, Struktur- und Verhaltensmuster unterteilt. Erzeugungsmuster betreffen den Prozess der Objekterzeugung, z.B. Fabrik (Factory)^[31] oder Singleton.^[32] Strukturmuster befassen sich mit der Zusammensetzung von Klassen und Objekten, z.B. Fassade (Facade)^[33]. Verhaltensmuster charakterisieren die Art und Weise, in der Klassen und Objekte zusammenarbeiten und Zuständigkeiten aufteilen, z.B. Beobachter (Observer)^[34].

Mustersysteme

Einzelne Muster stehen nicht für sich allein. Es gibt stattdessen eine Reihe von Beziehungen zwischen ihnen. Daher stellen die Muster in ihrer Gesamtheit nicht mehr nur Musterkataloge dar, bei denen sie isoliert und nacheinander beschrieben werden. Vielmehr entstehen die Organisierungen der Muster in Mustersysteme. Ein Mustersystem verbindet seine Muster miteinander und beschreibt, wie sie voneinander abhängen und sich gegenseitig ergänzen. Die Mustersysteme helfen, das richtige Muster für eine bestimmte Situation herauszufinden und ermöglichen die Beziehungen zwischen den Mustern und sich herausbildenden Mustersystemen zu verstehen. Somit unterstützen sie die wirkungsvolle Verwendung von Mustern in der Softwareentwicklung.^[35]

Referenzarchitekturen

Auf dem höchsten Abstraktionsniveau der Muster stehen Referenzarchitekturen, auch Musterarchitekturen genannt. Referenzarchitekturen beschreiben nicht so sehr Entwurfslösungen für Teilprobleme einer Softwarearchitektur, sondern konzentrieren sich auf den Entwurf vollständiger Anwendungen.

Eine Referenzarchitektur fasst Gemeinsamkeiten mehrerer ähnlicher Systemfamilien zusammen und beschreibt diese in einer allgemeinen Softwarearchitektur.^[36] Allgemeine Lösungskonzepte für ähnliche Entwurfsprobleme können dann wieder verwendet werden. Ein Beispiel ist Referenzarchitektur für Portalsysteme (s. Abschnitt 3.2.), von der sich ein spezifisches Portal ableiten kann, um seine portalspezifische Einzelarchitektur zu bilden.^[37]

3 Portalsysteme

Die zunehmende Komplexität und Diversifizierung der Geschäftstätigkeit vieler Organisationen führt einerseits zu einem steigenden Informationsbedarf der Mitarbeiter, andererseits aber auch zu der Schwierigkeit, die richtigen Informationen zur richtigen Zeit mit einem angemessenen Aufwand erreichen zu können. Portale sollen die Lösung dieses Problems unterstützen. Daher wird Portalen eine besondere Bedeutung zugemessen, die als zentrale Zugangsstelle zu internen und potentiell externen Informationen und anderen Ressourcen wie Anwendungen einen Beitrag zur bedarfsgerechten Informationsversorgung leisten sollen. Durch eine einheitliche Benutzeroberfäche, einfache und leicht verständliche Bedienung sowie übersichtliche Strukturierung soll die Orientierung und Navigation erleichtert und die Komplexität reduziert werden.

3.1 Definition und Klassifizierung

Definition

Fricke definiert ein Portal als „einen zentralen Einstiegs- und Navigationspunkt, der dem Anwender Zugang zu einem virtuellen Angebotsraum bietet und ihn auf weiterführende Informationen – entsprechend seiner jeweiligen Interessen – lenkt.“^[38]

Diese eher allgemeine, primär durch Informationsorientierung gekennzeichnete Definition sagt wenig darüber aus, aus welchen Quellen die Informationen stammen, so dass sie um die Einbeziehung verschiedener Datenbestände und Anwendungen erweitert werden muss.

Demnach ist ein Portal ein zentraler Einstiegs- und Navigationspunkt, der den Zugang zu konsistent integrierten Informationen, Diensten und Anwendungen aus potentiell verteilten, heterogenen Quellen erlaubt.^[39] In der Literatur werden Begriffe Internetportal und Webportal häufig synonym verwendet und stehen für im Internet verfügbare bzw. auf Grundlage von Internet- und World Wide Web-Technologie realisierte Portale.

Ein Portalsystem ist ein Informationssystem, durch das ein Portal realisiert wird. Es kann als ein System bezeichnet werden, da es im weiteren Sinne die Informationen verarbeitet, erfasst, überträgt, transformiert, speichert und bereitstellt.^[40] Im weiteren Verlauf dieser Arbeit werden beide Bezeichnungen synonym verwendet.

Klassifizierung

Portale werden im Internet in unterschiedlichen Kontexten und mit verschiedenen Schwerpunkten gestaltet. Demnach gibt es unterschiedliche Arten von Portalen, die nach im Folgenden beschriebenen Kriterien klassifiziert werden können.

In Abhängigkeit vom Umfang der fokussierten Themengebiete wird in horizontalen und vertikalen Portalen unterschieden. Horizontale Portale bieten ein weit gefächertes Angebot an Informationen und Funktionen und sind nicht auf bestimmte Interessengruppen, Themen, Branchen oder Produktgruppen ausgerichtet. Große horizontale Portale sind z.B. Yahoo, AOL oder Lycos. Vertikale Portale konzentrieren sich auf spezifische Themenbereiche und fokussieren auf bestimmte Interessengruppen, Branchen oder Produkte(n). Sie bieten einen Zugang zu (auf) darauf spezialisierten Informationen und Funktionen. Beispiele hierfür sind ZDNet und Heise.de für Informationstechnik.^[41]

Nach dem Nutzerkreis kann in offene oder geschlossene Portale klassifiziert werden. Offene Portale sind nicht auf bestimmte Nutzergruppen ausgerichtet und sind für jede Person zugänglich. Geschlossene Portale sind auf bestimmte Zielgruppen beschränkt. In beiden Typen von Portalen kann eine Registrierung erforderlich sein, wobei bei geschlossenen Portalen typischerweise eine Zugangskontrolle eingesetzt wird, um unberechtigte Benutzer auszuschließen. Eine Spezialform ist in diesem Bereich die Unterscheidung in Webportale und Unternehmensportale (Enterprise Portals).^[42]

Portale können auch in Typen nach dem mit Hilfe des Portals zugänglichen Teil des Internets – Intranet, Extranet oder Internet – klassifiziert werden. Ein Intranetportal ermöglicht den Mitarbeitern eines Unternehmens oder einer Organisation Zugang zu verschiedenen Informationsbeständen, Anwendungen oder anderen Ressourcen. Ein Extranetportal erfüllt im Wesentlichen die gleichen Funktionen, erweitern den Berechtigtenkreis aber um enge aktuelle oder potentielle Kooperationspartner, z.B. Kunden oder Lieferanten. D.h. Teile des Intranets werden für diese spezielle Zielgruppe freigegeben. Ein Internetportal eröffnet Zugang zu dem gesamten World Wide Web und nicht nur zu einem Informations- und Funktionsbereich, der durch die Interessen eines Unternehmens oder einer Organisation abgegrenzt ist. Dieses Kriterium kann auch zur Abgrenzung des Teils des Internets, aus dem heraus das Portal zugänglich ist, verwendet werden, z.B. ist ein Intranetportal aus dem Intranet erreichbar und kann auf Ressourcen im gesamten Internet verweisen.^[43]

Nach dem Personalisierungsgrad können Portale in standardisierte und personalisierte Portale unterscheiden werden. Während Portale i.e.S. standardisiert und für alle Benutzer gleiche Einstiegspunkte ins Web sind, können Portale i.w.S. personalisiert, d.h. benutzerspezifischen Präferenzen entsprechend angepasst werden. Der Benutzer hat Einfluss auf die gemäß seinen Anforderungen dynamisch generierten Inhalte. Heute ist Personalisierung ein charakteristisches Merkmal grundsätzlich aller Portale.^[44]

Portale können nach ihrem jeweiligen Funktionsschwerpunkt klassifiziert werden, die entsprechend durch eine Informations- oder Funktionsorientierung gekennzeichnet sind. Informationsorientierte Portale entstanden aus klassischen Such- und Verzeichnisdiensten. Sie verstanden sich als verschiedene Inhalte strukturiert zusammenfassende Aggregatoren, die die Suche und Navigation im Web erleichterten. Durch die schrittweise Erweiterung des Informations- und Funktionsangebotes entwickelten sie sich zu Portalen. Funktionsorientierte Portale legen ihren Schwerpunkt weniger auf die Recherche nach Informationen, sondern in erster Linie auf das Zurverfügungstellen von Funktionen, die Kommunikation und Kooperation zwischen den Benutzern ermöglichen. Ein Funktionsschwerpunkt kann hier auch im zwischenbetrieblichen Handel oder im Handel mit privaten Endverbrauchern liegen (Portale für elektronische Marktplätze).^[45] Im Bereich der Unternehmensportale haben sich viele Klassen von Portalen herausgebildet, die ihren Schwerpunkt jeweils auf Information, Zusammenarbeit oder Wissensmanagement legen.

Als letztes Kriterium kann die durch das Portal miteinander verbundenen Nutzergruppen verwendet und entsprechend in Portale Business-to-Consumer, Business-to-Business, Business-to-Employee oder auch Consumer-to-Consumer unterschieden werden. Während auf die ersten drei im Rahmen der Unternehmensportale näher eingegangen wird, stellen die letzten einen elektronischen Marktplatz dar und unterstützen private Endverbraucher beim Aufbau von Handelsbeziehungen zu anderen Konsumenten.^[46]

Anschließend lässt sich anmerken, dass die Grenzen bei vielen Konzepten fließend verlaufen und ein Portal viele der genannten Merkmale kombinieren kann.

Unternehmensportale^[47]

Unternehmensportale (Enterprise Portals) integrieren Anwendungen, Dienste und Inhalte aus unterschiedlichen Informationsquellen zentral am Arbeitsplatz der Mitarbeiter, Kunden oder Geschäftspartner. Sie bieten Grundfunktionen zum Verwalten von Inhalten (z.B. Content Management und Dokumentenmanagement), zur Struktur (z.B. Strukturierung, Suche, Präsentation), zur Zusammenarbeit (z.B. Kommunikation, Koordination, Prozessunterstützung) und für die Administration des Portals selbst (z.B. Benutzerverwaltung, Personalisierung, Anpassung). Durch das Kombinieren dieser Merkmale grenzen sie sich von Web-Content-Management-Systemen oder Zugangsseiten zu anderen Webseiten ab.

Unternehmensportale unterschieden sich nach dem zu Grunde liegenden Geschäftsmodell bzw. der Zielgruppe. Danach gibt es Business-to-Employee, Business-to-Business und Business-to-Consumer Portale.

Business-to-Employee Portale (B2E) dienen zur innerbetrieblichen Geschäftsabwicklung und bieten einen personenbezogenen Zugang zu betriebsinternem und -externem Wissen. Sie sind gekennzeichnet durch eine benutzerfreundliche webbasierte Oberfläche sowie durch einen einheitlichen Zugang zu Wissens- und Informationsquellen. Ein B2E Portal geht über ein nicht personalisiertes Intranet hinaus und führt durch die Individualisierung zu Effizienz- und Effektivitätssteigerungen. Durch die Aufbereitung der unternehmensinternen Informationsbasis werden die entscheidenden Informationen zusammengeführt, gefiltert, verdichtet und in eine dem jeweiligen Geschäftsprozess entsprechende Form gebracht.

In B2E-Portalen kommen eine Vielzahl unterschiedlicher Technologien zum Einsatz. Typische Beispiele sind Enterprise Information Portals, Enterprise Colaborative Portals, Enterprise Expertise Portals sowie Enterprise Knowledge Portals.

Enterprise Information Portals (EIP) stellt die einfachste Form der Unternehmensportale dar. Sie bieten einen zentralen Einstiegspunkt in die Informationsbestände des Unternehmens, wobei die Informationen mit dem jeweiligen Mitarbeiter verknüpft werden.

Enterprise Collaborative Portals (ECP) stellen Funktionen für die Zusammenarbeit in Teams zur Verfügung. Mitarbeitern wird die Möglichkeit gegeben, Informationen mit Hilfe unterschiedlicher Medien auszutauschen und so in virtuellen Teams gemeinsam abteilungsübergreifend, zeitzonenunabhängig und aufgabenorientiert Projekte zu lösen.

Enterprise Expertise Portals (EEP) verbinden Mitarbeiter mit ähnlichen Aufgaben, Spezialgebieten und Erfahrungshintergründen durch eine Kommunikationsplattform. Damit kann ein ausgewählter Nutzerkreis gezielt über den Eingang neuer Meldungen z.B. aus Expertendatenbanken oder Diskussionsforen informiert werden.

Enterprise Knowledge Portals (EKP) beinhalten alle vorherigen Stufen und darüber hinaus werden personalisierte Inhalte und Hinweise auf Personen, die wichtig für die Arbeit des Mitarbeiters sind, durch Push-Mechanismen und intelligente Agenten proaktiv und in Echtzeit zum Arbeitsplatz geleitet. Der Mitarbeiter kann dadurch aktiv bei seiner Aufgabenbearbeitung unterstützt werden.

Business-to-Business Portale (B2B) dienen zur zwischenbetrieblichen Geschäftsabwicklung innerhalb von Geschäftsbeziehungen. Sie haben die Aufgabe, die Systeme, Daten und Prozesse der beteiligten Unternehmen möglichst weitreichend miteinander zu integrieren. Die Digitalisierung der ausgetauschten Nachrichten ermöglicht eine Prozessautomatisierung, wodurch Informationen schneller und in höherer Qualität ausgetauscht werden können. B2B-Portale können sich auf die gesamte Lieferkette oder nur auf Teile daraus beziehen. Anhand ihrer Funktionen können B2B-Portale unterschieden werden in Extended Enterprise Portals, Extended Marketplace Portals.

Bei Extended Enterprise Portals (EEP) handelt es sich um Portale, die Supply-Chain-Management und Beschaffungsprozesse mit den daran beteiligten Kunden, Lieferanten und Geschäftspartnern unterstützen. Im Mittelpunkt steht dabei die Kombination von Produktkatalogen mit aktuellen Lagerinformationen einer großen Zahl von Lieferanten.

Ein Extended Marketplace Portal (EMP) bildet die zentrale Schaltstelle des Handels zwischen Anbietern und Nachfragern als virtueller Marktplatz. Jedes Unternehmensportal, das Inhalte mit dem Verkauf verknüpft kann damit als EMP bezeichnet werden.

Business-to-Consumer Portale (B2C) dienen zur kundenprozessbezogenen Geschäftsabwicklung. Sie verfolgen das Ziel, aus Interessenten Kunden zu formen, diese Kundenbeziehungen zu festigen und auszubauen. Durch die Personalisierungsmöglichkeiten können dem Kunden unterschiedliche Angebote zur Verfügung gestellt werden. Das reicht von der individuellen Ansprache und Angebotsgestaltung, Produktempfehlungen aufgrund bereits betrachteter oder vorgemerkter Produkte bis zur Speicherung der bevorzugten Zahlungs- und Lieferungsmodalitäten sowie der Verfolgung der Ware und des Auftragstatus. Betriebswirtschaftliche Konzepte wie Customer Relationship Management oder über Electronic Customer Care lassen sich über Portale realisieren.

Customer Relationship Management (CRM) Portale beinhalten Funktionen zur Gewinnung neuer Kunden und zur Pflege dauerhafter und gewinnbringender Kundenbeziehungen. Dafür werden CRM-Systeme um Portalfunktionen erweitert.

Electronic Commerce Care (ECC) Portale schaffen internetbasierte Geschäftsbeziehungen zwischen dem Unternehmen und dem Kunden mit dem Ziel, Waren und Dienstleistungen über das Web zu handeln. Dabei spielt das Konzept, individuelle Leistungen aufgrund von Kundenprofilen anzubieten sowie das Portal als Vertriebsinstrument zu nutzen, eine zentrale Rolle.

3.2 Referenzarchitektur

Die Aufgaben und Dienste eines Portalsystems können je nach Anforderungen einen unterschiedlich ausgeprägten Funktionsumfang aufweisen. Um den Aufbau und die generelle Funktionalität transparent darzustellen, wird im Folgenden eine Referenzarchitektur für Portalsysteme vorgestellt, anhand welcher verschiedene Funktionen schrittweise beschrieben werden (s. Abb. 1). Die funktionalen Komponenten im Modell sind unabhängig von einer bestimmten Technologie und können im konkreten Portalsystem je nach Scherpunktsetzung unterschiedlich stark ausgeprägt sein.^[48] Die Referenzarchitektur fasst portaltypische Gemeinsamkeiten zusammen, so dass eine portalspezifische Einzelarchitektur mit einigen fehlenden oder zusätzlichen Komponenten von ihr abgeleitet sein kann.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1: Referenzarchitektur für Portalsysteme

Quelle: Vgl. Vlachakis, J. et al. (2005), S. 14.

Grundlegender Aufbau

Die grundlegende Struktur eines Portals umfasst drei Ebenen: Ebene der Benutzeroberfläche, Verarbeitungsebene und Datenebene.

Die Ebene der Benutzeroberfläche besteht aus Endgeräten der Benutzer (Clients), z.B. Webbrowser, die zur clientspezifischen Darstellung der Portalinhalte verwendet werden.

Die Verarbeitungsebene enthält die Kernfunktionalität des Portals. Aufgrund einer hohen Komplexität und eventuellen Skalierbarkeitsproblemen durch die permanent wachsende Anzahl von Benutzern ist die Basis einer Portallösung häufig nicht mehr ein Webserver, sondern ein Anwendungsserver (z.B. Technologien J2EE, .NET). Während auf dem letzteren die Verarbeitungslogik gespeichert und ausgeführt wird, ist der Webserver eher für das Weiterreichen der Clientanfragen an Anwendungsserver sowie für den Transfer des vom Anwendungsserver gelieferten Ergebnisses (z.B. Portalseiten in HTML) an den Client zuständig.^[49]

Der Webserver in ein Teil der Bereitstellungsdienste in der Verarbeitungsebene. Ein weiterer Dienst kann z.B. WebDAV^[50] sein, der den Zugriff auf Dokumente gestattet.

Die Portalanwendungsvisualisierung betrifft die Ausgabe bzw. Darstellung von Portalanwendungen auf Portalseiten und übernimmt die Kommunikation mit einem Benutzer. Die Visualisierung erfolgt typischerweise in virtuellen, in HTML nachgebildeten Fenstern (sog. Portlets, IViews, Module). Über eine Programmierschnittstelle, Portal-API (Application Programming Interface) können Portalanwendungen aufgerufen sowie Basisdienste genutzt werden.

Die Datenebene umfasst Informationssysteme für persistente Datenspeicherung wie Datenbankmanagementsystem, Dateisystem oder auch externe Datenquellen. Der Datenzugriff erfolgt über Integrationsdienste wie Datenbankschnittstellen (z.B. JDBC, ADO.NET), Web Services oder auch umfangreiche EAI-Funktionen (Enterprise Application Integration). Integrierte Transaktionsdienste gewährleisten die Transaktionssicherheit über die verschiedenen angebundenen Anwendungen hinweg.

Portalbasisdienste

Zur Realisierung des Portals bietet die Portalsoftware Basisdienste an, die von den verschiedenen Portalanwendungen genutzt werden können. Sie umfassen grundlegende Funktionen für die Erstellung und des Betriebes des Portals. Das Portal besitzt hiermit im softwaretechnischen Sinne^[51] eine Framework-Funktion^[52] zur Realisierung von Anwendungen.^[53] Im Folgenden werden ausgewählte Portalbasisdienste genauer untersucht.

Das Strukturmanagement definiert den strukturellen Aufbau und die Navigierbarkeit des Portals, wie es dem Benutzer personalisiert präsentiert werden soll. In der Struktur werden die Anordnung der Portalseiten im Navigationsbaum und die Verlinkung der Seiten untereinander beschrieben. Die Portalseiten sind wesentliches Element des Strukturmanagements. Auf ihnen werden Elemente des Portals platziert, die dynamisch zur Laufzeit von der Portalsoftware erzeugt werden. Das Strukturmanagement umfasst insbesondere die Definition, an welcher Stelle der Portalstruktur Anwendungen platziert sind. Des Weiteren wird die Navigationsstruktur, z.B. gruppenspezifisch konfiguriert. Die Darstellung des Portalmenüs kann als Baumstruktur, hierarchische Struktur oder Reiter erfolgen.^[54]

Die Aufgabe des Layoutmanagement umfasst die Zusammenstellung der vom Nutzer angefragten Portalseiten aus den einzelnen Anwendungen und die Erzeugung der clientspezifischen Ausgabe. Beim Webbrowser ist das Ziel die Erstellung einer HTML-Seite, die alle Module und die damit verbundenen Inhalte sowie Navigations- und Designelemente enthält. Der Erstellungsprozess wird Rendering genannt. Dabei werden strukturelle Vorgaben, Berechtigungen und vom Benutzer eingestellte Layoutvorgaben (z.B. Platzierung, Reihenfolge, Variation der Visualisierungskomponenten) sowie Grafiken berücksichtigt.^[55]

Das Content Management verwaltet Inhalte und Grafiken des Portals. Web Content Management wird nötig, wenn größere Informationsmengen sich schnell und dynamisch verändern und damit nicht mehr über einen Webmaster manuell eingepflegt werden können.^[56] Content Management unterstützt die Erzeugung und Verwaltung von Inhalten, wobei Darstellungsunabhängigkeit eine wichtige Rolle spielt. Die Darstellung (Formatierung), Inhalte und Struktur (Metainformationen, z.B. Titel) werden voneinander getrennt (s. Abb. 2), damit die Präsentation der Inhalte in unterschiedlichen Kontexten, Kombinationen, Medien und Formaten (z.B. Webbrowser) ermöglicht wird.^[57] Die Informationen können dann direkt auch von Autoren ohne HTML-Wissen in das System eingebunden werden. Alternativ können HTML- oder Textinhalte über integrierte Werkzeuge wie WYSIWYG-Editoren^[58] intuitiv gepflegt werden.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2: Contentorientierung

Quelle: Vgl. Bullinger, H.-J. (2000), S. 8.

Content Management unterstützt das redaktionelle Management von Inhalten, bei dem sich Abläufe von der Erstellung, Prüfung, Freigabe bis zur Publikation, Überarbeitung und Archivierung über den ganzen Inhaltlebenszyklusprozess (Content Lifecycle) erstrecken können.^[59] Ein Inhaltsaustausch, sog. Content Syndication, ist eine weitere Funktion, die Mehrfachverwendung einmal erstellter Inhalte erlaubt, wobei Inhalte aus externen Quellen bezogen bzw. extern bereitgestellt werden können. Beispiel hierfür sind News im Portal, die nach dem Abbonieren individuell darstellbar sind, da sie medienneutral in standardisierten Formaten (RSS, XML) transferiert werden.^[60] Im Rahmen des Linkmanagement wird ein automatisches Generieren der Links in der Metaebene mit konfigurierbarem Inhalt aus den Strukturdaten der Informationen bereitgestellt. Die Linkeingabe wird z.B. durch die Auswahl- oder Suchfunktion unterstützt und eine Möglichkeit der Zielangabe angeboten.

Die Benutzer- und Berechtigungsverwaltung kann sowohl intern im Portal als auch extern erfolgen. Ein wesentliches Kriterium dieses Dienstes stellt die Art der Berechtigungsvergabe dar. In den meisten Fällen definieren die Administratoren verschiedene Aufgabenspektren zusammenfassende Sicherheitsrollen für Benutzergruppen und teilen daraufhin eine oder mehrere Rollen jedem Benutzer zu. Mit den einzelnen Rollen werden auch zu autorisierende Informationsobjekte und Berechtigungen verknüpft.^[61] Herkömmliche Autorisierungsverfahren, die jedem Benutzer einzelne Rechte zuordnen, stellen zwar eine Alternative dar, eignen sich aber eher nicht für größere Lösungen mit vielen unterschiedlichen Anwendungen, da sie schwierig administrierbar sind.^[62] Die Benutzer- und Berechtigungsverwaltung erfordert eine ausgereifte Portaladministration; eine typische Anforderung an ein Portalsystem.

Personalisierung bedeutet, dass sich die Portalseiten für Portalbenutzer individuell darstellen. Die Portalanwendungen präsentieren Inhalte und bieten Funktionen an, die rollen-, interessen- oder fachspezifisch sind.^[63] Die Vorraussetzung für Personalisierung ist somit die Authentifizierung und Autorisierung bzw. Zugriffskontrolle.

Zwei wesentliche Funktionen zur Personalisierung stellen Benutzerprofile und Customizing dar. In Benutzerprofilen können personenbezogene Stammdaten (z.B. Adresse, Werdegang), individuelle Einstellungen oder Benachrichtigungspräferenzen gepflegt werden.^[64] Beim Customizing oder Adaption kann das System an die organisations- und benutzerspezifischen Anforderungen angepasst werden. Das Customizing kann durch Parametrisierung erfolgen, bei der das Verhalten und Funktionsangebot (z.B. in der Navigation) des Portalsystems und einzelner Anwendungen durch Setzen von Parametern angepasst werden (z.B. Spracheinstellung, Rollen- und Berechtigungserteilung). Die Adaption kann durch Modularisierung (oder auch Konfiguration) erreicht werden, die eine individuelle Auswahl und Zusammenstellung der Portalseiten aus verschiedenen, im Bestand enthaltenen Portalanwendungen bzw. Modulen bedeutet (Strukturdefinition).^[65] Auch eine möglichst leichte Integration neuer Module kann zu diesem Funktionsumfang zählen. Die Personalisierung ist somit eng mit dem Strukturmanagement verbunden.

Suche repräsentiert im Portalsystem eher einen integrierten Hilfs- bzw. Zusatzdienst für Benutzer. Da Portale Zugang zu einer großen Informationsmenge bieten, ist häufig neben dem Zugang über definierte Ablagestrukturen eine Suchfunktion notwendig, um diese Informationen nutzbar zu machen. Die Aufgabe des Suchdienstes ist, das gesamte Portal für den Benutzer suchbar zu machen. Der Suchdienst hat eventuell die Herausforderung mit verschiedenen, heterogenen Datenquellen umgehen zu müssen, die unterschiedliche Strukturierungsgrade (Dokumentenbestand oder strukturierte Datenbankbestände) und Semantik aufweisen.^[66]

Die Klassifikation der Suchdienste erfolgt nach unterschiedlichen Sucharten (z.B. Kategorien, Synonym, Suchbaum, Volltext). Volltext-Suchdienste ziehen bei ihrer Analyse das gesamte Dokument heran. Andere Dienste beschränken sich auf explizit ausgewiesene Metadaten (z.B. Titel, Erstellungsdatum), auf deren Basis die Dokumente zum schnellen Finden indexiert werden. Die Ermittlung der Reihenfolge der gefundenen Einträge kann anhand verschiedenen Heuristiken ermittelt werden, z.B. anhand der Häufigkeit der vorkommenden Suchbegriffe oder zusätzlich anhand der auf ein Dokument zeigenden Hyperlinks (Verweise). Ein Portal muss nicht notwendigerweise eine eigene Technologie zur Websuche besitzen, sondern kann die von einem anderen Anbieter (z.B. Google) gelieferten Suchergebnisse integrieren.^[67]

Neben der Informationsverarbeitung ist ein wesentliches Merkmal eines Portalsystems die Prozessorientierung. Der Basisdienst Prozesssteuerung bietet eine softwaretechnische Unterstützung von Prozessen. Neben der internen Prozesssteuerung können optional die Prozessabwicklung und der Datenaustausch zwischen verschiedenen heterogenen Anwendungen über die Portalplattform notwendig sein. In diesem Fall kommt der Bildung einer Prozessschnittstelle von externen hin zu organisationsinternen Prozessen eine besondere Bedeutung zu, da hier die Prozesse der Benutzer direkt ankoppeln (Prozessintegration). Durch die an die Bedürfnisse der Benutzer angepasste Prozessschnittstelle können die organisationsspezifischen internen Prozesse abstrahiert werden.^[68]

Der Dienst Single Sign On authentifiziert die Portalbenutzer automatisiert an allen in das Portal integrierten Anwendungen. Die Benutzer identifizieren sich einmalig mit dem Benutzernamen und Passwort, auch Credentials genannt,^[69] und greifen auf benutzerspezifische Informationen in allen Systemen der Datenebene (die evtl. eine externe Benutzerverwaltung in Form eines organisationsweiten Verzeichnisdienstes enthält) zu. Durch das Vermeiden des vielfachen Anmeldens an Einzelanwendungen können die Benutzer entlastet (z.B. das Merken vieler Passwörter entfällt) werden sowie die Anzahl der über das Portal zu erreichbaren, eigene Authentifizierung erfordernden Systeme (z.B. in Form verweisender Links) kann abnehmen.^[70]

Portalanwendungsmodule

Die Portalanwendungsmodule repräsentieren vorgefertigte, im Portalsystem integrierte Portalanwendungen. In ihnen sind portalspezifische Funktionen umgesetzt. Die Modultypen sind einmal definiert und werden aus einer allgemeinen Portalanwendungsklasse instanziiert. Im Folgenden werden ausgewählte Module detailliert beschrieben.

Das Dokumentenmanagement unterstützt die Verwaltung umfangreicher, elektronischer Dokumente in verschiedenen Formaten. Es umfasst alle Phasen des Dokumentlebenszyklus von der Erstellung bzw. Empfang eines Dokumentes bis hin zu Versionierung (Kenntlichmachung von Veränderungen), Archivierung (Sicherung älterer Versionen zum späteren Nachvollziehen) und Löschung. Die Erstellung eines Dokuments schließt neben dem Einstellen auch dessen Attributierung ein. Mithilfe der Attribute wird das Dokument beschrieben und mit ergänzenden Informationen angereichert. Die zur Verfügung gestellte Suchfunktionalität erlaubt das Wiederfinden gespeicherter Dokumente und der darin enthaltenen Informationen. Ebenso kann ein Download-Bereich, z.B. für Unterlagen oder Mitteilungen realisiert werden, wobei die Möglichkeit besteht, Dokumentensammlungen nach einer inhaltlichen Struktur zu organisieren.^[71] Das Dokumentenmanagement wird auch als Bestandteil des Content Management im weiteren Sinne betrachtet.

Ein Workflow ist ein vollständig oder teilweise automatisierbarer Geschäftsprozess. Er beschreibt den zeitlichen und logischen Ablauf einzelner Aktivitäten und stellt Informationen über Daten und Ressourcen zur Verfügung, die bei der Abarbeitung des Geschäftsprozesses notwendig sind. Workflow Management hat die Aufgabe, die Geschäftsprozesse zu modellieren, zu analysieren oder zu steuern.^[72] Die Dokumente, Informationen und Aufgaben werden gemäß definierter Regeln (Zuordnung einzelner Aktivitäten entsprechend der Rollen der Anweder) von einem Teilnehmer zu einem anderen zur Bearbeitung gereicht. Ein Systemmerkmal ist die Art der Erstellung (z.B. grafische Prozessdefinition) von neuen Geschäftsprozessen und deren Veränderung. Insbesondere strukturierbare, sich wiederholende Prozessabläufe lassen sich in einer Software gut abbilden. In einem Portalsystem sind i.d.R. zumindest einfache Workflow-Systeme enthalten, die der Steuerung der Inhaltserstellung und/oder -bearbeitung dienen.^[73] Je nach Aufgabenstellung können sie jedoch deutlich komplexer ausfallen. In Abhängigkeit von der Strukturierbarkeit der Prozesse und der Häufigkeit der Durchführung unterscheidet man zwischen mehreren Workflow-Typen, deren Aufgaben in der Tab. 1 zusammengefasst sind.

Abbildung in dieser Leseprobe nicht enthalten

Tab. 1: Workflow-Typen

Quelle: Bullinger, H.-J. (2002), S. 23.

Die Verfügbarkeit von Web Services mit bekannten Schnittstellen eröffnet bei komplexen Prozessen, bei denen eine Inanspruchnahme externer Dienste nötig ist, die Möglichkeit zur Abwicklung einzelner Vorgänge durch diese Technologie. Alle Vorgänge zusammen ergeben dann einen Workflow bzw. den sog. Super Service.^[74]

Eine Virtuelle Community^[75] ist ein Zusammenschluss elektronisch kommunizierender Personen. Zur Intensivierung der Beziehungen wird die Formung von Gemeinschaften mit starker Bindung angestrebt. Ein verbindendes Element ist ein gemeinsames Interesse, Problem oder eine gemeinsame Aufgabe der Mitglieder. Die mit gewisser Regelmäßigkeit stattfindende Interaktion zwischen den Mitgliedern wird durch eine technische Plattform vermittelt und unterstützt. Dabei wird eine effizientere Gestaltung der Zusammenarbeit, Vertrauensaufbau sowie Knüpfung von Kontakten ermöglicht.^[76]

Zur Informationsverteilung und Interaktion bietet ein Community-Modul verschiedene Dienste an. Dementsprechend kann zwischen Informations- und Interaktionsdiensten unterschieden werden, die sich zum Teil verschiedener Technologien zur Realisierung bedienen (s. Abb. 3). Die Kommunikationsdienste können dabei synchron oder asynchron, d.h. unter Berücksichtigung der zeitlichen Verteilung funktionieren. Matchmaking-Dienste dienen zum Aufdecken von Beziehungen und zum Filtern von Informationen auf der Grundlage der Beziehungsdaten.^[77]

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3: Community-Dienste

Quelle: Vgl. Krcmar, H.; Leimeister, J. M. (2003), S. 661.

Die Dienste können für das Finden und Verstehen von Informationen oder für die Wissensschaffung im Rahmen des Wissensmanagements eingesetzt werden. Ein Beispiel wäre ein elektronisches Diskussionsforum für asynchrone Gruppenkommunikation, bei dem Diskussionen strukturiert, interaktiv (Argumente-Gegenargumente) abgebildet und gespeichert werden. Das Ziel bei der Nutzung von Foren besteht in der Lösung individueller Fragen. Indem verschiedene Teilnehmer diskutieren und vorangegangene Beiträge berücksichtigen, entsteht ein iterativer, kollaborativer Prozess, der zur Wissensgenerierung beitragen kann.^[78] Als Nachteil wird aufgeführt, dass außer dem jeweiligen Diskussionsthema und der umfassenden Kategorie jedoch wenig Hinweise auf das enthaltene Wissen vorhanden sind. Die Titel sind z.B. nicht immer aufschlussreich und im Zeitverlauf können mehrere Diskussionen zu ähnlichen Themen entstehen, die ohne transparente inhaltliche Beziehung nebeneinander existieren. Diesen Nachteilen kann z.B. durch eine dem Inhalt entsprechende Verschlagwortung und eine entsprechende Kategorisierung bzw. Strukturierung entgegengewirkt werden.^[79]

Der Bereich Collaboration & Groupware bezeichnet diejenigen Module, die eine elektronische Kooperation, Koordination und Kommunikation^[80] von zusammenarbeitenden Benutzergruppen unterstützen, wobei unterschiedliche Ausprägungen der Dimensionen Zeit, Ort und Strukturierung der Prozesse zu berücksichtigen sind.

Dementsprechend hat sich das interdisziplinäre Forschungsgebiet Computer Supported Cooperative Work (CSCW) herausgebildet, das auf die computergestützte Gruppenarbeit zielt. Hier steht vor allem die Entwicklung und Definition von theoretischen und methodologischen Grundlagen der Zusammenarbeit unter Einsatz von Informations- und Kommunikationstechnologien sowie deren Umsetzung in neuen Arbeitsmethoden und Werkzeugen im Vordergrund. Die resultierenden Werkzeuge zur Realisierung und Unterstützung der Gruppenarbeit werden als Groupware bezeichnet.^[81] Während im Workflow Management strukturierte Prozessabläufe automatisiert werden, eignet sich Groupware zur Unterstützung eher unstrukturierter und Ad-hoc-Workflows.^[82]

Die Integration der Dienste in ein Portal zielt auf Erleichterung der Zusammenarbeit durch die rechnergestützte Verwaltung der gemeinsam bearbeiteten Dokumente bzw. Materialien, Verbesserung der Kommunikation, Erbringung besserer Ergebnisse, Bildung von Gruppen mit gemeinsamen Interessen oder Kombination persönlicher Fähigkeiten und dadurch Nutzung von Synergieeffekten ab. Durch die Ausrichtung der Groupware am spezifischen Kontext (Wissenserzeugung, Wissenswiederverwendung) können Potentiale im Wissensmanagement unter den Anwendern ausgeschöpft werden.^[83]

Die Abb. 4 zeigt typische Komponenten solcher gemeinschaftlichen Software, eingeteilt in Abhängigkeit von zeitlichen und räumlichen Unterscheidungsmerkmalen der primär unterstützten Gruppenarbeit. Viele Tätigkeiten der synchronen und lokalen Ausprägung lassen sich durchaus auch asynchron und/oder verteilt durchführen.^[84] In anderen Bereichen sind auch andere Einordnungen denkbar, z.B. synchrone Dokumentenbearbeitung.

Die Unterstützung der synchronen Kommunikation sowie Zusammenarbeit von entfernt/verteilt agierender Nutzergruppen wird in der Literatur manchmal aus der Groupware herausgelöst und unter dem Begriff Collaboration eingeordnet.^[85]

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4: Aufgabenunterstützung durch Collaboration & Groupware-Komponenten

Quelle: Vgl. Hansen, H. R.; Neumann, G. (2005), S. 442.

Der Einsatz diverser Technologien und Werkzeuge, die sich in unterschiedlichen Anwendungen einordnen lassen, führt in der Literatur zu vielfältigen, sich überlappenden Begriffsbildungen und entsprechend individueller Anforderungen ausgeprägten Zuständigkeiten.

[...]

---

^[1] Vgl. Siedersleben, J. (2004), S. 1.

^[2] Vgl. Starke, G. (2005), S. 15.

^[3] Bass, L. et al. (2004), S. 21.

^[4] Im Ggs. dazu befasst sich eine Systemarchitektur mit Hard- und Softwareeinheiten des vollständigen Systems und betrachtet demnach nicht nur die Architektur einer Softwareanwendung. Zur Systemarchitektur zählen die Architektur der verteilten Anwendungen (Softwarearchitektur) und die Architektur des verteilten Systems. Vgl. Hammerschall, U. (2005).

^[5] Vgl. Dustdar, S. et al. (2003), S. 3.

^[6] Vgl. Bass, L. et al. (2004), S. 21 f; Posch, T. et al. (2004), S. 5, 8.

^[7] Beim iterativ inkrementellen Entwicklungsprozess wird die Software stufenweise und unter Berücksichtigung bereits gemachter Erfahrungen entwickelt, wobei die einzelnen Entwicklungsphasen mehrfach durchlaufen werden. Vgl. Balzert, H. (2001), S. 58, 69.

^[8] Vgl. Posch, T. et al. (2004), S. 14.

^[9] Vgl. Sommerville, I. (2001), S. 226; Posch, T. et al. (2004), S. 15.

^[10] Vgl. Dustdar, S. et al. (2003), S. 7.

^[11] Vgl. Posch, T. et al. (2004), S. 16.

^[12] Vgl. Parnas, D. L. (1972), S. 1056; Fink, A. (2002), S. 655; Aßmann, U.; Neumann, R. (2003), S. 20.

^[13] Vgl. Hammerschall, U. (2005), S. 69; Bass, L. et al. (2004), S. 21.

^[14] Vgl. Aßmann, U.; Neumann, R. (2003), S. 19 ff.

^[15] Szyperski, C. (2002), S. 41.

^[16] D’Souza, D. F.; Wills, A.C. (1999).

^[17] OMG (2004).

^[18] Vgl. Siedersleben, J. (2004), S. 42 f.

^[19] Vgl. Brüssau, K. (2002), S. 1216.

^[20] Vgl. Quibeldey-Cirkel, K. (1996), S. 326; Buschmann, F. et al. (2000), S. X.

^[21] Vgl. Sommerville, I. (2001), S. 332, 335; Quibeldey-Cirkel, K. (1996), S. 326;
Im Literaturverzeichnis ist die deutsche Übersetzung der im Jahre 1995 erschienenen Originalquelle Design Patterns: Elements of Reusable Object-oriented Software aufgeführt: Gamma, E. et al. (2004).

^[22] Vgl. Buschmann, F. et al. (2000), S. 8.

^[23] Vgl. Gamma et al. (2004), S. 1 f; Buschmann, F. et al. (2000), S. 5 ff.

^[24] Vgl. Buschmann, F. et al. (2000), S. 11 f.

^[25] Vgl. Alur, D. et al. (2002).

^[26] Vgl. Trowbridge, D. (2003).

^[27] Vgl. Buschmann, F. et al. (2000), S. 12, 27.

^[28] Vgl. Sommerville, I. (2001), S. 225.

^[29] Vgl. Buschmann, F. et al. (2000), S. 32, 124; Gamma, E. (2004), S. 5.

^[30] Vgl. Buschmann, F. et al. (2000), S 13.

^[31] Vgl. Gamma, E. (2004), S. 107 ff.

^[32] Vgl. Gamma, E. (2004), S. 157 ff.

^[33] Vgl. Gamma, E. (2004), S. 212 ff.

^[34] Vgl. Gamma, E. (2004), S. 287 ff, Das Muster Observer wird auch unter dem Namen Publisher-Subscriber beschrieben. Vgl. Buschmann, F. et al. (2000), S. 338.

^[35] Vgl. Buschmann, F. et al. (2000), S. 357.

^[36] Vgl. Dustdar, S. et al. (2003), S. 4.

^[37] Vgl. Vlachakis, J. et al. (2005), S. 14.

^[38] Vgl. Fricke, M. (2001), S. 371.

^[39] Vgl. Sandkuhl, K. (2005), S. 193; Kappel, G. et al. (2004), S. 8; Wege, C. (2002), S. 73.

^[40] Vgl. Voß, S.; Gutenschwager, K. (2001), S. 86.

^[41] Vgl. Fricke, M. (2001), S. 372; Hansen, H. R. Neumann, G. (2005), S. 640.

^[42] Vgl. Amberg, M. et al. (2003), S. 1395; Stelzer, D. (2004), S. 11.

^[43] Vgl. Schumacher, M.; Schwickert, A. C. (1999), S. 9; Gurzki, T. (2004), S. 28.

^[44] Vgl. Stelzer, D. (2004), S. 12.

^[45] Vgl. Hansen, H. R. Neumann, G. (2005), S. 639, 735 f; Vgl. Stelzer, D. 12 f.

^[46] Vgl. Schumacher, M.; Schwickert, A. C. (1999), S. 8; Stelzer, D. (2004), S. 13.

^[47] Vgl. Amberg, M. et al. (2003), S. 1394

^[48] Vgl. Vlachakis, J. et al. (2005), S. 14.

^[49] Vgl. Kappel, G. et al. (2003), S. 127; Hammerschall, U. (2002), S. 7.

^[50] Distributed Authoring and Versioning (WebDAV) ist eine Erweiterung des WWW-Protokolls HTTP und ermöglicht das verteilte Erstellen und Ändern beliebiger Medientypen auf einem Webserver. Vgl. Prestipino, M.; Schwabe, G. (2003), S. 673 f.

^[51] Sotwaretechnik betont mit ihren charakteristischen Eigenschaften eine arbeitsteilige, ingenieurmäßige Entwicklung umfangreicher Softwaresysteme, wobei zielorientierte (d.h. unter Berücksichtigung von Kosten, Zeit, Qualität) Bereitstellung und systematische Verwendung von Prinzipien, Methoden und Werkzeugen erfolgt. Vgl. Balzert, H. (2001), S. 36.

^[52] Ein Framework (Rahmenwerk) enthält eine Menge zusammenarbeitender Klassen, die einen wieder verwendbaren Entwurf für einen bestimmten Anwendungsbereich implementieren. Es umfasst konkrete und insbesondere abstrakte Klassen und Schnittstellen, welche die Verwendung und das Anpassen des Frameworks erlauben. Vgl. Zwintscher, O. (2005), S. 125; Balzert, H. (2005), S 533.

^[53] Vgl. Vlachakis, J. et al. (2005), S. 16; Gurzki, T. (2004), S. 31.

^[54] Vgl. Vlachakis, J. et al. (2005), S. 31; Gurzki, T. (2004), S. 32; Gurzki, T.; Hinderer, H. (2003), S. 159.

^[55] Vgl. Vlachakis, J. et al. (2005), S. 30; Gurzki, T. (2004), S. 32 f.

^[56] Vgl. Bullinger, H.-J. (2002), S. 24.

^[57] Vgl. Hartmann, P. (2001), S. 121; Bullinger, H.-J. (2000), S. 7.

^[58] WYSIWYG: What You See Is What You Get.

^[59] Vgl. Krcmar, H. (2005), S. 498; Bullinger, H.-J. (2002), S. 24.

^[60] Vgl. Wege, C. (2002), S. 73; Bullinger, H.-J. (2002), S. 25; Hess, T. (2001), S. 122.

^[61] Vgl. Stelzer, D. (2004), S. 24; Wege, C. (2002), 74.

^[62] Vgl. Graf, L. et al. (2005), S. 140.

^[63] Vgl. Stelzer, D. (2004), S. 24.

^[64] Vgl. Jacobsen, C. (2002), S. 7, 14, 69; Hansen, H. R.; Neumann, G. (2005a), S. 652 f.

^[65] Vgl. Leßweng, H.-P. et al. (2004), S. 223 f.

^[66] Vgl. Vlachakis, J. et al. (2005), S. 31; Gurzki, T.; Hinderer, H. (2003), S. 160.

^[67] Vgl. Hansen, H. R.; Neumann, G. (2005a), S. 645 ff.

^[68] Vgl. Kirchhof, A. et al. (2004), S. 7.

^[69] Vgl. Lorenz, P. A. (2004), S. 613.

^[70] Vgl. Guzki, T. (2004), S. 28, 36; Bohlmann, S.; Stock, H. (2004), S. 73; Wege, C. (2002), S. 73 f.

^[71] Vgl. Bullinger, H.-J. et al. (2002), S. 23; Krcmar, H. (2005), S. 497.

^[72] Vgl. Deppisch, M.; Oppitz, M. (2004), S. 886.

^[73] Vgl. Bullinger, H.-J. (2002), S. 22.

^[74] Vgl. Burghardt, M. et al. (2003), S. 61.

^[75] Synonym werden in der Literatur auch Begriffe wie virtuelle Gemeinschaft, Communities, Virtual Communities und Online Communities verwendet.

^[76] Vgl. Krcmar, H.; Leimeister, J. M. (2003), S. 659 f.

^[77] Vgl. Krcmar, H. (2005), S. 500.

^[78] Vgl. Prestipino, M.; Schwabe, G. (2003), S. 672 f.

^[79] Vgl. Krcmar, H.; Leimeister, J. M. (2003), S. 661; Prestipino, M.; Schwabe, G. (2003), S. 673.

^[80] Kooperation kennzeichnet sich durch ein gemeinsames Ziel, das alle Beteiligten anstreben (z.B. ein gemeinsames Erstellen eines Dokumentes). Zur Erreichung der Ziele werden Aktionen auf Objekten ausgeführt. Die Behandlung von Abhängigkeiten zwischen den Aktionen (z.B. Zugriff auf die gleichen Objekte) bedeutet Koordination. Kommunikation betrifft den Austausch von Informationen unter Vorraussetzung eines gemeinsamen Verständnisses. Vgl. Becker, W. et al. (1999), S. 423 f.

^[81] Vgl. Krause, D.; Bager, J. (2003), S. 123.

^[82] Vgl. Krause, D.; Bager, J. (2003), S. 125.

^[83] Vgl. Vlachakis, J. et al. (2005), S. 32; Hansen, H. R.; Neumann, G. (2005), S. 444.

^[84] Vgl. Hansen, H. R.; Neumann, G. (2005), S. 441 ff.

^[85] Vgl. Vlachakis, J. et al. (2005), S. 32.