II

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

  Inhaltsübersicht  

  ABKÜRZUNGSVERZEICHNIS  V

  ABBILDUNGSVERZEICHNIS.  VII

TABELLENVERZEICHNIS X   

1  EINLEITUNG.  1

2  ENTWURF VERTEILTER SOFTWARESYSTEME.  3

3  PORTALSYSTEME.  11

4  KOMPONENTENBASIERTE SOFTWAREENTWICKLUNG  27

5  MICROSOFT NET  47

6  PRAXISPROJEKT IWIPORTAL.  75

7  SCHLUSSBETRACHTUNG.  153

  ANHANG.  155

  LITERATURVERZEICHNIS  156

III

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

  Inhaltsverzeichnis  

  ABKÜRZUNGSVERZEICHNIS  V

  ABBILDUNGSVERZEICHNIS.  VII

TABELLENVERZEICHNIS X   

1  EINLEITUNG.  1

1.1  Problemstellung und Zielsetzung  1

1.2  Gang der Untersuchung  1

2  ENTWURF VERTEILTER SOFTWARESYSTEME.  3

2.1  Softwarearchitektur  3

2.2  Architektur- und Entwurfsprinzipien  5

2.3  Musterorientierte Softwarearchitektur  7

3  PORTALSYSTEME.  11

3.1  Definition und Klassifizierung.  11

3.2  Referenzarchitektur  16

4  KOMPONENTENBASIERTE SOFTWAREENTWICKLUNG  27

4.1  Schichtenbildung  27

4.2  Präsentationsschicht.  33

4.2.1  Benutzeroberflächenkomponenten  33

4.2.2  Benutzerprozesskomponenten  35

4.3  Anwendungsschicht  37

4.3.1  Geschäftsworkflows  37

4.3.2  Geschäftskomponenten.  39

4.3.3  Dienstschnittstellen.  40

4.3.4  Geschäftsentitäten.  41

4.4  Datenzugriffsschicht  44

4.4.1  Datenzugriffslogikkomponenten  44

4.4.2  Dienstagenten  45

5  MICROSOFT NET  47

5.1  NET Framework.  47

5.2  Komponentenmodell von NET  51

5.3  ASP.NET  55

5.3.1  Web Forms  55

5.3.2  ASP.NET-Serversteuerelemente  59

5.3.3  Zustandsverwaltung.  62

5  4 ADO NET  67

IV

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

5.4.1  Architektur.  67

5.4.2  Verbundene Objekte  69

5.4.3  Unverbundene Objekte  71

6  PRAXISPROJEKT IWIPORTAL.  75

6.1  Anforderungsanalyse.  75

6.2  Architektur.  78

6.3  Entwurf von Komponenten  81

6.3.1  Präsentationsschicht.  81

6.3.1.1  Seitenstruktur und -layout  81

6.3.1.2  Navigationsstruktur  83

6.3.1.3  Module und Modulsteuerelemente  90

6.3.1.4  Globalisierung  94

6.3.1.5  URL-Management  102

6.3.1.6  Integration von Komponenten der Drittanbieter.  104

6.3.2  Anwendungsschicht.  106

6.3.2.1  Geschäftentitäten  106

6.3.2.2  Geschäfstkomponenten.  108

6.3.2.3  Objektrelationale Abbildung  113

6.3.3  Datenzugriffsschicht  120

6.3.3.1  Generative Programmierung und gespeicherte Prozeduren  122

6.3.3.2  Datenzugriffslogikkomponenten  125

6.3.3.3  Caching-Komponente  135

6.4  Schichtenübergreifende Konzepte  136

6.4.1  Klickverfolgung.  136

6.4.2  Sicherheit  138

6.4.2.1  Authentifizierung, Autorisierung, sichere Kommunikation  138

6.4.2.2  Portaladministration.  146

6.5  Migration.  150

7  SCHLUSSBETRACHTUNG.  153

  ANHANG.  155

A  Namensgebung für Komponententypen.  155

  LITERATURVERZEICHNIS  156

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

ABKÜRZUNGSVERZEICHNIS

Association for Computing Machinery ACM ADO.NET ActiveX Data Objects .NET ALM Adjacency List Model

API Application Programming Interface ASP Active Server Pages ASP.NET Active Server Pages .NET B2B Business-to-Business B2C Business-to-Consumer Portale B2E Business-to-Employee

C# CSharp

Magazin für Computertechnik c’t CLR Common Language Runtime CLS Common Language Specification Component Object Model COM CORBA Common Object Request Broker Architecture CRM Customer Relationship Management CSS Cascading Style Sheets CTS Common Type System DAL Data Access Layer DBMS Datenbankmanagementsystem Distributed Component Object Model / COM+ DCOM DHTML Dynamic HTML DLL Dynamic Link Library DTS Data Transformation Services EAI Enterprise Application Integration ECC Electronic Commerce Care ECP Enterprise Collaborative Portals EEP Extended Enterprise Portals EIP Enterprise Information Portals EKP Enterprise Knowledge Portals EMP Extended Marketplace Portals

ER Entity Relationship FCL .NET Framework Class Library

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

GAC Global Assembly Cache GUI Graphical User Interface HMD Handbuch der maschinellen Datenverarbeitung HTML Hypertext Markup Language HTTP Hypertext Transfer Protocol IAO Institut für Arbeitswirtschaft und Organisation ISO International Organization for Standardization iX Magazin für professionelle Informationstechnik J2EE Java 2 Plattform, Enterprise Edition JDBC Java Database Connectivity JIT Just In Time MPTT Modified Preorder Tree Traversal MSIL Microsoft Intermediate Language RSS Rich Site Summary SOA Service Oriented Architecture SSL Secure Sockets Layer UI User Interface URL Uniform Resources Locator VB Visual Basic WISU Das Wirtschaftsstudium WYSIWYG What You See Is What You Get XML Extensible Markup Language XSLT Extensible Stylesheet Language Transformation

VII

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

  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  

VIII

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

  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  

IX

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

  Abb. 69: DTS-Pakete für Datenmigration  

  Abb. 70: DTS-Paket DeleteTableContents  

  Abb. 71: DTS-Paket TablesWithoutFK  

  Abb 72: DTS-Paket TablesWithFK  

X

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

  TABELLENVERZEICHNIS  

  Tab. 1: Workflow-Typen.  23

  Tab. 2: Mechanismen zur Zustandsverwaltung in ASP.NET  63

  Tab. 3: Elemente und Komponenten der Seitenvorlage.  82

  Tab. 4: Ressourcendateien für IWIPortal  97

  Tab. 5: Integration von Komponenten der Drittanbieter  105

  Tab. 6: Selbst erstellte gespeicherte Prozeduren in der Datenbank.  125

  Tab. 7: Berechtigungsarten.  139

  Tab. 8: Administrationsfunktionen.  149

  Tab 9: Namensgebung für Komponententypen  155

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

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 entwi- ckelnden Systeme skalieren, benötigt. So ist der Wandel zu beobachten von den frühen Modularisierungstechniken über objektorientierte Systeme hin zu Systemen, die mehr- schichtig und komponentenbasiert entwickelt sind. Durch den Einsatz von Komponen- ten 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

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

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 Basisdiens- te werden detailliert dargestellt.

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

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.

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. Ein Merkmal der Softwarearchitektur ist

aber die weitgehende Gestaltungsfreiheit. Eine weitgehend akzeptierte Definition stammt von Bass, Clemens und Kazman:

⁴ Eine Softwarearchitektur 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. 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. 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.

¹ Vgl. Siedersleben, J. (2004), S. 1.

² Vgl. Starke, G. (2005), S. 15.

³ Bass, L. et al. (2004), S. 21.

⁴ 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 Systemar- zählen die Architektur der verteilten Anwendungen (Softwarearchitektur) und die Architek- des verteilten Systems. Vgl. Hammerschall, U. (2005).

⁵ Vgl. Dustdar, S. et al. (2003), S. 3.

⁶ Vgl. Bass, L. et al. (2004), S. 21 f; Posch, T. et al. (2004), S. 5, 8.

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

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 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 Abstraktions- ⁸ niveau. 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. 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 we- ¹⁰ gen der sonst zu detaillierten Sichtweise (Feinentwurf, Quellcode) auf die Software. Festhalten des Kernwissens

⁷ Beim iterativ inkrementellen Entwicklungsprozess wird die Software stufenweise und unter Berück- bereits gemachter Erfahrungen entwickelt, wobei die einzelnen Entwicklungsphasen mehr- durchlaufen werden. Vgl. Balzert, H. (2001), S. 58, 69.

⁸ Vgl. Posch, T. et al. (2004), S. 14.

⁹ Vgl. Sommerville, I. (2001), S. 226; Posch, T. et al. (2004), S. 15.

¹⁰ Vgl. Dustdar, S. et al. (2003), S. 7.

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

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.

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 Programmwiederverwen- ¹² dung durch Kopieren des Quellcodes.

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

¹¹ Vgl. Posch, T. et al. (2004), S. 16.

¹² Vgl. Parnas, D. L. (1972), S. 1056; Fink, A. (2002), S. 655; Aßmann, U.; Neumann, R. (2003), S. 20.

¹³ Vgl. Hammerschall, U. (2005), S. 69; Bass, L. et al. (2004), S. 21.

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

sich Systeme mit verändertem Verhalten. Objektorientierte Systeme bieten eine ideale ¹⁴ Basis für Komponentensysteme. 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 inter-

- “A

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

faces.” Diesen Definitionen folgend wird eine Komponente durch folgende Merkmale charakte- ¹⁸ risiert, wobei sie:

- eine oder mehrere Schnittstellen exportiert, die im Sinne eines Vertrags garantiert sind. Hierzu gehört insbesondere die genaue Semantik der Schnittstellen. Jede

¹⁴ Vgl. Aßmann, U.; Neumann, R. (2003), S. 19 ff.

¹⁵ Szyperski, C. (2002), S. 41.

¹⁶ D’Souza, D. F.; Wills, A.C. (1999).

¹⁷ OMG (2004).

¹⁸ Vgl. Siedersleben, J. (2004), S. 42 f.

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

Komponente, die eine Schnittstelle exportiert, ist eine Implementierung von dieser

- andere Schnittstellen importiert, wobei der Import einer Schnittstelle bedeutet,

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

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

Ein Muster beschreibt ein bestimmtes, in einem speziellen Entwurfskontext wiederkehrendes Entwurfsproblem und präsentiert eine erprobte, generische Lösung. Diese Lö- ¹⁹ Vgl. Brüssau, K. (2002), S. 1216.

²⁰ Vgl. Quibeldey-Cirkel, K. (1996), S. 326; Buschmann, F. et al. (2000), S. X.

²¹ 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).

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

sung spezifiziert die beteiligten Komponenten, ihre jeweiligen Zuständigkeiten, die Be- ²² ziehungen zwischen den Komponenten und die Art deren Zusammenarbeit. 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.

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. Des Weiteren

existieren Muster, die spezielle Aspekte des Entwurfs in einer Programmiersprache oder ^{25 26} einer Plattform (z.B. Sun J2EE oder Microsoft .NET ) 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.

²² Vgl. Buschmann, F. et al. (2000), S. 8.

²³ Vgl. Gamma et al. (2004), S. 1 f; Buschmann, F. et al. (2000), S. 5 ff.

²⁴ Vgl. Buschmann, F. et al. (2000), S. 11 f.

²⁵ Vgl. Alur, D. et al. (2002).

²⁶ Vgl. Trowbridge, D. (2003).

²⁷ Vgl. Buschmann, F. et al. (2000), S. 12, 27.

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

Die Auswahl eines Architekturmusters stellt eine Grundsatzentscheidung dar, da sie ²⁸ systemweite Struktur festlegt und wird auch als Grobentwurf bezeichnet. . 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 Kernfunkti- ²⁹ onalität und den Daten der Anwendung (Model View Controller, MVC). 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.

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 (Fac- ^{31 32} tory) oder Singleton. Strukturmuster befassen sich mit der Zusammensetzung von ³³ Klassen und Objekten, z.B. Fassade (Facade) . Verhaltensmuster charakterisieren die

Art und Weise, in der Klassen und Objekte zusammenarbeiten und Zuständigkeiten auf- ³⁴ teilen, z.B. Beobachter (Observer) . 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 Mus- ²⁸ Vgl. Sommerville, I. (2001), S. 225.

²⁹ Vgl. Buschmann, F. et al. (2000), S. 32, 124; Gamma, E. (2004), S. 5.

³⁰ Vgl. Buschmann, F. et al. (2000), S 13.

³¹ Vgl. Gamma, E. (2004), S. 107 ff.

³² Vgl. Gamma, E. (2004), S. 157 ff.

³³ Vgl. Gamma, E. (2004), S. 212 ff.

³⁴ 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.

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

tern und sich herausbildenden Mustersystemen zu verstehen. Somit unterstützen sie die ³⁵ wirkungsvolle Verwendung von Mustern in der Softwareentwicklung. 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. 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.

³⁵ Vgl. Buschmann, F. et al. (2000), S. 357.

³⁶ Vgl. Dustdar, S. et al. (2003), S. 4.

³⁷ Vgl. Vlachakis, J. et al. (2005), S. 14.

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

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üh- ³⁸ rende Informationen - entsprechend seiner jeweiligen Interessen - lenkt.“ 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. 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 ver- ⁴⁰ arbeitet, erfasst, überträgt, transformiert, speichert und bereitstellt. Im weiteren Ver-

³⁸ Vgl. Fricke, M. (2001), S. 371.

³⁹ Vgl. Sandkuhl, K. (2005), S. 193; Kappel, G. et al. (2004), S. 8; Wege, C. (2002), S. 73.

⁴⁰ Vgl. Voß, S.; Gutenschwager, K. (2001), S. 86.

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

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. 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 Unter- ⁴² scheidung in Webportale und Unternehmensportale (Enterprise Portals). 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 Res- ⁴³ sourcen im gesamten Internet verweisen.

⁴¹ Vgl. Fricke, M. (2001), S. 372; Hansen, H. R. Neumann, G. (2005), S. 640.

⁴² Vgl. Amberg, M. et al. (2003), S. 1395; Stelzer, D. (2004), S. 11.

⁴³ Vgl. Schumacher, M.; Schwickert, A. C. (1999), S. 9; Gurzki, T. (2004), S. 28.

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

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. 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ät- ⁴⁵ ze). 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 priva- ⁴⁶ te Endverbraucher beim Aufbau von Handelsbeziehungen zu anderen Konsumenten. 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

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 Inhal- ⁴⁴ Vgl. Stelzer, D. (2004), S. 12.

⁴⁵ Vgl. Hansen, H. R. Neumann, G. (2005), S. 639, 735 f; Vgl. Stelzer, D. 12 f.

⁴⁶ Vgl. Schumacher, M.; Schwickert, A. C. (1999), S. 8; Stelzer, D. (2004), S. 13.

⁴⁷ Vgl. Amberg, M. et al. (2003), S. 1394

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

ten (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

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

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.

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

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. Die Referenzarchitektur fasst portaltypische Gemeinsamkeiten zusammen, so dass eine portalspezifische Einzelarchitektur mit einigen fehlenden oder zusätzlichen Komponenten von ihr abgeleitet sein kann.

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.

⁴⁸ Vgl. Vlachakis, J. et al. (2005), S. 14.

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

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.

Der Webserver in ein Teil der Bereitstellungsdienste in der Verarbeitungsebene. Ein ⁵⁰ weiterer Dienst kann z.B. WebDAV 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 ^{51 52} im softwaretechnischen Sinne eine Framework-Funktion zur Realisierung von An- ⁵³ wendungen. Im Folgenden werden ausgewählte Portalbasisdienste genauer untersucht.

⁴⁹ Vgl. Kappel, G. et al. (2003), S. 127; Hammerschall, U. (2002), S. 7.

⁵⁰ 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.

⁵¹ Sotwaretechnik betont mit ihren charakteristischen Eigenschaften eine arbeitsteilige, ingenieurmäßige

Entwicklung umfangreicher Softwaresysteme, wobei zielorientierte (d.h. unter Berücksichtigung von

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

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.

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.

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 wer- ⁵⁶ den können. 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 Kontex- ⁵⁷ ten, Kombinationen, Medien und Formaten (z.B. Webbrowser) ermöglicht wird. Die

Informationen können dann direkt auch von Autoren ohne HTML-Wissen in das Sys- Kosten,Zeit, Qualität) Bereitstellung und systematische Verwendung von Prinzipien, Methoden und

Werkzeugen erfolgt. Vgl. Balzert, H. (2001), S. 36.

⁵² Ein Framework (Rahmenwerk) enthält eine Menge zusammenarbeitender Klassen, die einen wieder

verwendbaren Entwurf für einen bestimmten Anwendungsbereich implementieren. Es umfasst kon- und insbesondere abstrakte Klassen und Schnittstellen, welche die Verwendung und das Anpas- des Frameworks erlauben. Vgl. Zwintscher, O. (2005), S. 125; Balzert, H. (2005), S 533.

⁵³ Vgl. Vlachakis, J. et al. (2005), S. 16; Gurzki, T. (2004), S. 31.

⁵⁴ Vgl. Vlachakis, J. et al. (2005), S. 31; Gurzki, T. (2004), S. 32; Gurzki, T.; Hinderer, H. (2003), S.

159.

⁵⁵ Vgl. Vlachakis, J. et al. (2005), S. 30; Gurzki, T. (2004), S. 32 f.

⁵⁶ Vgl. Bullinger, H.-J. (2002), S. 24.

⁵⁷ Vgl. Hartmann, P. (2001), S. 121; Bullinger, H.-J. (2000), S. 7.

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

tem eingebunden werden. Alternativ können HTML- oder Textinhalte über integrierte ⁵⁸ Werkzeuge wie WYSIWYG-Editoren intuitiv gepflegt werden.

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. 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 me- ⁶⁰ dienneutral in standardisierten Formaten (RSS, XML) transferiert werden. 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 wer- ⁶¹ den auch zu autorisierende Informationsobjekte und Berechtigungen verknüpft. 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

⁵⁸ WYSIWYG: What You See Is What You Get.

⁵⁹ Vgl. Krcmar, H. (2005), S. 498; Bullinger, H.-J. (2002), S. 24.

⁶⁰ Vgl. Wege, C. (2002), S. 73; Bullinger, H.-J. (2002), S. 25; Hess, T. (2001), S. 122.

⁶¹ Vgl. Stelzer, D. (2004), S. 24; Wege, C. (2002), 74.

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

⁶² vielen unterschiedlichen Anwendungen, da sie schwierig administrierbar sind. 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 rol- ⁶³ len-, interessen- oder fachspezifisch sind. 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. 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 (Strukturdefiniti- ⁶⁵ on). 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 Datenbankbe- ⁶⁶ stände) und Semantik aufweisen.

Die Klassifikation der Suchdienste erfolgt nach unterschiedlichen Sucharten (z.B. Kategorien, Synonym, Suchbaum, Volltext). Volltext-Suchdienste ziehen bei ihrer Analyse

⁶² Vgl. Graf, L. et al. (2005), S. 140.

⁶³ Vgl. Stelzer, D. (2004), S. 24.

⁶⁴ Vgl. Jacobsen, C. (2002), S. 7, 14, 69; Hansen, H. R.; Neumann, G. (2005a), S. 652 f.

⁶⁵ Vgl. Leßweng, H.-P. et al. (2004), S. 223 f.

⁶⁶ Vgl. Vlachakis, J. et al. (2005), S. 31; Gurzki, T.; Hinderer, H. (2003), S. 160.

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

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 An- ⁶⁷ bieter (z.B. Google) gelieferten Suchergebnisse integrieren. 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 Prozessschnitt- ⁶⁸ stelle können die organisationsspezifischen internen Prozesse abstrahiert werden. 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, 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. 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.

⁶⁷ Vgl. Hansen, H. R.; Neumann, G. (2005a), S. 645 ff.

⁶⁸ Vgl. Kirchhof, A. et al. (2004), S. 7.

⁶⁹ Vgl. Lorenz, P. A. (2004), S. 613.

⁷⁰ Vgl. Guzki, T. (2004), S. 28, 36; Bohlmann, S.; Stock, H. (2004), S. 73; Wege, C. (2002), S. 73 f.

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

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. 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 Ge- ⁷² schäftsprozesse zu modellieren, zu analysieren oder zu steuern. 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. 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.

⁷¹ Vgl. Bullinger, H.-J. et al. (2002), S. 23; Krcmar, H. (2005), S. 497.

⁷² Vgl. Deppisch, M.; Oppitz, M. (2004), S. 886.

⁷³ Vgl. Bullinger, H.-J. (2002), S. 22.

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

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. ⁷⁵ Eine Virtuelle Community 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 Zu- ⁷⁶ sammenarbeit, Vertrauensaufbau sowie Knüpfung von Kontakten ermöglicht. 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 Informatio- ⁷⁷ nen auf der Grundlage der Beziehungsdaten.

⁷⁴ Vgl. Burghardt, M. et al. (2003), S. 61.

⁷⁵ Synonym werden in der Literatur auch Begriffe wie virtuelle Gemeinschaft, Communities, Virtual

Communities und Online Communities verwendet.

⁷⁶ Vgl. Krcmar, H.; Leimeister, J. M. (2003), S. 659 f.

⁷⁷ Vgl. Krcmar, H. (2005), S. 500.

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

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 Wissensge- ⁷⁸ nerierung beitragen kann. 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. Der Bereich Collaboration & Groupware bezeichnet diejenigen Module, die eine e- ⁸⁰ lektronische Kooperation, Koordination und Kommunikation von zusammenarbeitenden Benutzergruppen unterstützen, wobei unterschiedliche Ausprägungen der Dimensionen Zeit, Ort und Strukturierung der Prozesse zu berücksichtigen sind.

⁷⁸ Vgl. Prestipino, M.; Schwabe, G. (2003), S. 672 f.

⁷⁹ Vgl. Krcmar, H.; Leimeister, J. M. (2003), S. 661; Prestipino, M.; Schwabe, G. (2003), S. 673.

⁸⁰ 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 glei- Objekte) bedeutet Koordination. Kommunikation betrifft den Austausch von Informationen un-

ter Vorraussetzung eines gemeinsamen Verständnisses. Vgl. Becker, W. et al. (1999), S. 423 f.

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

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. Während im

Workflow Management strukturierte Prozessabläufe automatisiert werden, eignet sich ⁸² Groupware zur Unterstützung eher unstrukturierter und Ad-hoc-Workflows. 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 wer- ⁸³ den.

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. 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 Group- ⁸⁵ ware herausgelöst und unter dem Begriff Collaboration eingeordnet.

⁸¹ Vgl. Krause, D.; Bager, J. (2003), S. 123.

⁸² Vgl. Krause, D.; Bager, J. (2003), S. 125.

⁸³ Vgl. Vlachakis, J. et al. (2005), S. 32; Hansen, H. R.; Neumann, G. (2005), S. 444.

⁸⁴ Vgl. Hansen, H. R.; Neumann, G. (2005), S. 441 ff.

⁸⁵ Vgl. Vlachakis, J. et al. (2005), S. 32.