Ein Modell zur Nutzung von Business Mashups in Unternehmensportalen

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1 Einleitung
1.1 Motivation
1.2 Zielsetzung und Aufbau der Arbeit

2 Portale
2.1 Definition
2.1.1 Portal allgemein
2.1.1.1 Kriterium Fokus
2.1.1.2 Kriterium Nutzerkreis
2.1.2 Unternehmensportale
2.1.2.1 Kriterium Zielgruppen
2.1.2.2 Kriterium Anwendungsschwerpunkte
2.1.2.3 Gründe / Erfolgsfaktoren für den Einsatz von Unternehmensportalen
2.2 Portlets
2.2.1 Definition
2.2.2 Abgrenzung zu Web Services und Webparts
2.3 Architekturmodelle und Referenzarchitekturen
2.3.1 Fachliches Architekturmodell
2.3.2 Technische Referenzarchitektur
2.3.3 PADEM Referenzarchitektur für Portalsoftware

3 Serviceorientierte Architekturen
3.1 Definition
3.2 Elemente einer SOA
3.2.1 Services
3.2.2 Anwendungs-Frontend
3.2.3 Service-Repository
3.2.4 (Enterprise) Service-Bus
3.3 Gründe für den Einsatz einer SOA
3.3.1 Die Unternehmensperspektive
3.3.2 Die Personalperspektive
3.4 Die Rolle von Portalen innerhalb einer SOA

4 Web 2.0
4.1 Die Grundprinzipien des Web 2.0
4.2 Die Entwicklung vom Web 1.0 zum Web 2.0
4.3 Ausgewählte Technologien und Anwendungen des Web 2.0
4.3.1 Weblogs
4.3.2 Wikis
4.3.3 AJAX
4.4 Etablierte Web 2.0-Anwendungen
4.4.1 Wikipedia
4.4.2 YouTube
4.4.3 Xing

5 Mashups
5.1 Definition
5.2 Handlungsfelder von Mashups im Web 2.0
5.3 Beispiele von Mashup-APIs und Mashups
5.3.1 Mashup-APIs
5.3.2 Mashups
5.4 REST-Architektur
5.4.1 Grundlagen
5.4.2 Verwandte Konzepte und Anwendungsgebiete
5.5 Technische Perspektive von Mashups
5.5.1 Grundlagen der Erstellung von Mashups
5.5.2 Integration und Kombination von Diensten und Datenquellen zu einem Mashup
5.5.2.1 Integration von Diensten durch Widgets
5.5.2.2 Integration von Datenquellen durch Feeds
5.5.2.3 Integration von Datenquellen und Diensten durch Mashup-APIs
5.5.3 Kommunikation zwischen den Komponenten eines Mashups
5.5.4 Software zum Erstellen von Mashups im Web 2.0
5.5.5 Technologien im Umfeld von Mashups
5.6 Vor- und Nachteile von Mashups
5.7 Abgrenzung von Mashups zu Composite Applications, Web Services und Portlets
5.7.1 Composite Apps, Situational Apps und SAP xApps
5.7.2 Web Services
5.7.3 Portlets und Portale
5.8 „Software as a Service“ und ähnliche Paradigmen
5.8.1 Application Service Providing
5.8.2 „Software as a Service“

6 (Business) Mashups in Unternehmensportalen
6.1 Enterprise 2.0 – Web 2.0 in Unternehmen
6.1.1 Definition
6.1.2 Business Mashups
6.2 Handlungsfelder und Potenziale von Business Mashups
6.2.1 Anbieterperspektive
6.2.2 Nutzerperspektive
6.3 Determinanten für die Nutzung von Business Mashups
6.3.1 Weborientierte Architekturen
6.3.2 Business Mashups als Integrationswerkzeug
6.3.2.1 Integrationsmodell
6.3.2.2 Integration durch Mashups
6.3.3 Unternehmensportale als Trägersystem
6.3.3.1 Personelle Voraussetzungen
6.3.3.2 Allgemeine technische Vorraussetzungen
6.4 Modell zur Integration und Nutzung von Mashups in einem Unternehmensportal
6.4.1 Grundlagen
6.4.2 Mashups im Umfeld unterschiedlicher Portalmodelle
6.4.2.1 Fachliches Architekturmodell
6.4.2.2 Technische Referenzarchitektur
6.4.2.3 PADEM Referenzarchitektur für Portalsoftware
6.4.3 Aggregation der Portalmodelle und des Mashup Ecosystems
6.5 Marktübersicht von Business Mashup-Software
6.5.1 BEA Aqua Logic Ensemble und WebLogic Portal
6.5.2 Serena Business Mashup-Lösungen
6.5.3 IBM Mashup Starter Kit / Lotus Mashups
6.5.4 Microsoft Popfly und Microsoft SharePoint Server
6.5.5 SAP Netweaver-Plattform
6.6 Kritische Würdigung der Ergebnisse

7 Fazit, Prognose und Ausblick

Anhang A: Codebeispiel Kapitel 5.5.1.2

Literaturverzeichnis

Abbildungsverzeichnis

Abbildung 1: Erstellung einer Portalseite und ihren Portlets

Abbildung 2: fachliches Architekturmodell

Abbildung 3: technische Referenzarchitektur

Abbildung 4: PADEM Portalsoftware Referenzarchitektur 2.0

Abbildung 5: Das Prinzip der Serviceorientierung

Abbildung 6: Service Composition

Abbildung 7: Bestandteile eines Service

Abbildung 8: Klassisches Modell einer Web-Anwendung vs. AJAX-Modell einer Web-Anwendung

Abbildung 9: Der „Hype Cycle for Emerging Technologies 2006“

Abbildung 10: Zusammensetzung eines Mashups aus unterschiedlichen Diensten und Datenquellen

Abbildung 11: Die beliebtesten Mashup-APIs

Abbildung 12: Abruf einer Ressource auf SOAP-Basis

Abbildung 13: Abruf einer Ressource auf REST-Basis

Abbildung 14: Einbinden eines YouTube Widgets

Abbildung 15: Aufbau eines RSS 2.0 Dokuments

Abbildung 16: Zugriff auf den Google Maps-Dienst

Abbildung 17: Integration einer Google Map in einem HTML-Dokument

Abbildung 18: Zugriff auf einen Flickr-Feed

Abbildung 19: Kommunikation zwischen zwei Diensten in einem Mashup

Abbildung 20: Drei-Schichten-Architektur von Composite Apps

Abbildung 21: Handlungsfelder und Potenziale von Business Mashups

Abbildung 22: Kernkomponenten einer WOA und ihre Bestandteile

Abbildung 23: Sichten und Ebenen des Integrationsmodells

Abbildung 24: Das „assemble, wire, and share“-Modell

Abbildung 25: Beziehungen zwischen Portalen und Mashups

Abbildung 26: Das „Mashup Ecosystem“

Abbildung 27: Funktionen und Anforderungen von Mashups im fachlichen Architekturmodell

Abbildung 28: Anforderungen von Mashups in der technischen Referenzarchitektur

Abbildung 29: Schichten der PADEM Referenzarchitektur in denen Mashups Funktionen übernehmen können

Abbildung 30: Modell zur Nutzung von Business Mashups in Unternehmensportalen

Tabellenverzeichnis

Tabelle 1: Vorteile und Herausforderungen einer SOA aus der Personalperspektive

Tabelle 2: Die Grundprinzipien des Web 2.0

Tabelle 3: Verschiedene Anwendungstypen des Web 2.0 und ihre Funktionen

Tabelle 4: Kategorien von Internetdiensten und ihre Mashup-APIs

Tabelle 5: ausgewählte Technologien im Umfeld von Mashups

Tabelle 6: Vor- und Nachteile von Mashups

Tabelle 7: Vergleich der traditionellen Anwendungsentwicklung mit Composite Apps, Situational Apps und Mashups

Tabelle 8: Vor- und Nachteile von ASP

Tabelle 9: Integrationspotenziale von Mashups im Rahmen des Integrationsmodells

Tabelle 10: Auswahl an Informationen, die in einem Service Repository verfügbar sein können

Tabelle 11: Die Komponenten einer SOA und ihr Pendant in einer WOA

Tabelle 12: Chancen und Risiken durch Business Mashups

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

1.1 Motivation

In den letzten Jahren gewannen in der IT- und Kommunikationslandschaft einige Schlagwörter immens an Bedeutung: die Begriffe Web 2.0, (Unternehmens-) Portale und serviceorientierte Architekturen (SOA) stehen für Themen, die nicht nur Einzug in die IT-Systemlandschaften von Unternehmen hielten und in Fachkreisen großen Anklang fanden, sondern besonders im Fall des Web 2.0, jeden Internetnutzer weltweit betreffen. Der Ausdruck Web 2.0 steht für ein neues Verständnis respektive eine neue Auffassung des Internets (vgl. [KoHä2007, 1]), durch die ein Nutzer nicht mehr nur als Informationskonsument wahr genommen wird, sondern als partizipierendes Individuum. Das bedeutet, dass ein Internetnutzer die Gelegenheit geboten bekommt, Inhalte und Informationen selbst bereitzustellen und in Zusammenarbeit mit anderen Nutzern zusammen zu tragen (wie bspw. bei Blogs und Wikis, siehe Kapitel 4.3.1 und 4.3.2). Zudem eignen sich moderne soziale Netzwerke besonders gut für einen kommunikativen Austausch der Internetnutzer zu speziellen Themengebieten. Diese Alternativen spielen sich im Web 2.0 bislang primär auf einer privaten, auf den Konsumenten ausgerichteten Ebene ab: Ein Angler schreibt regelmäßig einen Blog über sein Hobby, es werden die privaten Urlaubsbilder bei Flickr^[1] ins Netz gestellt, private Videoaufnahmen der eigenen Tanzgruppe werden bei YouTube^[2] online bereitgestellt, der Lageplan des Kleingartenvereins wird mit Hilfe von Google Maps^[3] abgebildet oder es werden über soziale Netzwerke wie das StudiVZ^[4] Kontakte mit alten Schul- und Studienkollegen gepflegt. Es ist ein gestiegener Mehrwert für die Nutzung des Internets bzw. bestimmter Plattformen für den Endnutzer ersichtlich, da die meisten dieser neuen Dienste kostenfrei genutzt werden können.

Nun stellt sich jedoch auch zwangsläufig die Frage, welchen Nutzen und Mehrwert Unternehmen aus den verschiedenen neuen Konzepten des Web 2.0 ziehen können. An dieser Stelle treten dann wiederum auch die eingangs bereits erwähnten Begriffe „Portal“ und „SOA“ in Erscheinung, die wiederum im Zusammenhang mit dem Web 2.0 einige Fragen aufwerfen. Wenn das Web 2.0 das Verständnis des Internets grundlegend verändert hat, wie kann es Einzug in Unternehmen, im Speziellen in Unternehmensportale, halten? Können aktuelle Web 2.0 Dienste, Technologien und Paradigmen 1:1 in Unternehmensportalen umgesetzt werden? Wird ein solcher Einsatz die Unternehmenskultur verändern oder den Unternehmen einen Mehrwert liefern? Das Angebot von unterschiedlichen, kostenfreien Diensten, wie Flickr oder YouTube, spiegelt eine serviceorientierte Ausrichtung des Web 2.0 wieder. Hier stellt sich die Frage, wie dieser Aspekt auch in Unternehmen genutzt werden kann und es treten in diesem Kontext serviceorientierte Architekturen in Erscheinung. Bei dieser Form der Softwarearchitekturen bestehen Anwendungen ebenfalls jeweils nur aus einzelnen, unterschiedlichen Diensten. Kann das Konzept einer SOA demzufolge um Web 2.0 Komponenten erweitert werden? Ein geeignetes Mittel scheinen Mashups zu sein. Des Öfteren lassen sich in themenverwandten Medien und Fachliteratur Artikel zu Business Mashups finden, die darauf schließen lassen, dass diese momentan ein sehr aktuelles und umfassend diskutiertes Thema sind. Als Indiz dafür kann auch die Eingabe der Begriffe „Business Mashups“ oder „Enterprise Mashups“ bei Google gesehen werden, deren Suche eine Zahl von ca. 40.000 bzw. ca. 122.000 Ergebnissen liefert. Mashups basieren ebenfalls auf einem Konzept, das es ermöglicht, unterschiedliche Dienste zu einer neuen Anwendung zu kombinieren. Die technischen Voraussetzungen, sowie die Möglichkeiten die sich durch den Einsatz von Business Mashups in einem Unternehmen ergeben, gilt es im Laufe dieser Arbeit zu analysieren.

1.2 Zielsetzung und Aufbau der Arbeit

Das Hauptaugenmerk dieser Diplomarbeit liegt darauf, Mashups im Hinblick auf ihre Anwendbarkeit in Unternehmen, im Speziellen die Nutzung auf Basis des Trägersystems Unternehmensportal, zu untersuchen. Dabei wird zunächst das Grundkonzept von Mashups vorgestellt und es wird gezeigt, wie Mashups im heutigen Web 2.0 Verwendung finden. Ziel wird es sein, heutige durch Endverbraucher genutzte Technologien und Anwendungen für Unternehmen zugänglich zu machen und einen unternehmerischen Nutzen daraus zu ziehen. Es werden die technischen Gesichtspunkte von Mashups beleuchtet, dazu zählen die Funktionsweise, Implementierungsmöglichkeiten, Arten von Mashups, eingesetzte Technologien sowie eine Abgrenzung zu ähnlichen Technologiekonzepten. Bezüglich der potentiellen Nutzung im Unternehmensumfeld wird gezeigt, welche Rolle Mashups in einer SOA spielen. Die Zielsetzung dieser Arbeit sieht vor, ein Modell zu entwickeln, welches die Implementierungsmöglichkeiten von Mashups in einem Unternehmen, im Speziellen in einem Unternehmensportal beschreibt und als Hilfestellung bei der Einführung von Business Mashups in die IT-Architektur von Unternehmen dient.

Die folgende Arbeit ist grob in zwei Abschnitte unterteilt: Der erste Teil ist der Grundlagenteil, welcher in die Themengebiete (Unternehmens-)Portale, serviceorientierte Architekturen und Web 2.0 einführt. Im zweiten Teil, dem Hauptteil, werden die Begriffe „Mashup“ und „Business Mashup“ vorgestellt und tiefer gehend analysiert.

Zu Beginn des Grundlagenteils wird in Kapitel 2 das Thema Portale vorgestellt. Zunächst werden dort Portale im Allgemeinen definiert und mögliche Ausprägungsformen vorgestellt. Anhand dieser Ausprägungsformen werden dann Unternehmensportale klassifiziert und determiniert. Es folgt eine Definition von Portlets, den Bestandteilen von Portalen und deren Abgrenzung von ähnlichen Konzepten wie Webparts und Web Services. Abgeschlossen wird das zweite Kapitel durch eine Einführung in verschiedene Architekturmodelle und Referenzarchitekturen, die im Zusammenhang mit Unternehmensportalen und Portalsoftware Verwendung finden.

In Kapitel 3 werden serviceorientierte Architekturen eingeführt. Zu diesen wird zunächst eine Begriffsbestimmung gegeben, woraufhin die unterschiedlichen Elemente einer SOA vorgestellt werden. Darauf folgen Gründe für die Einführung einer SOA aus einer Unternehmens- sowie Personalperspektive und welchen Zweck Unternehmensportale innerhalb einer SOA erfüllen können.

Das Web 2.0 steht im Mittelpunkt des folgenden Kapitels. Anfangs werden die Grundprinzipien des Web 2.0 erklärt und anhand derer die Bedeutung des Be-griffs charakterisiert. Danach wird beschrieben, wie sich das Internet im Laufe der Zeit vom sog. Web 1.0 zum Web 2.0 entwickelt hat. Darauf folgt die Vorstellung von diversen, prägendenden Technologien und Konzepten des Web 2.0, zu denen u.a. Weblogs, Wikis, und AJAX gehören. Zum Ende hin werden aktuelle, typische Web 2.0 Anwendungen und Plattformen, wie Wikipedia oder YouTube, vorgestellt und an deren Umsetzung die Grundprinzipien des Web 2.0 aufgezeigt.

Mit Kapitel 5 beginnt der Hauptteil dieser Arbeit. Zunächst wird der Begriff „Mashup“ definiert und aufgezeigt, welche Rolle Mashups in der heutigen Zeit im Web 2.0 spielen. Im Rahmen dessen werden einige Mashups und Mashup-APIs vorgestellt, die sich aktuell großer Beliebtheit bei privaten Endanwendern erfreuen. Darauf folgt eine technischere Betrachtung von Mashups. Zuerst wird die REST-Architektur vorgestellt, um dann im nächsten Schritt die technischen Aspekte von Mashups zu beleuchten. Dabei wird auf die Entwicklung eines Mashups eingegangen und es werden im Mashup-Umfeld genutzte Technologien betrachtet. Im weiteren Verlauf des Kapitels folgt eine Diskussion der Vor- und Nachteile von Mashups. Zum Abschluss werden Mashups zu ähnlichen Konzepten wie Composite Applications, Web Services und Portale abgegrenzt und es wird gezeigt, in welchem Zusammenhang sie mit dem „Software as a Service“-Paradigma stehen.

In Kapitel 6 werden Mashups auf die Unternehmenswelt abgebildet. Dazu werden zuerst die Begriffe „Enterprise 2.0“ und „Business Mashup“ konkretisiert, sowie die Ziele und Vorteile von Business Mashups – jeweils aus einer Anbieter- und Nutzerperspektive erläutert. Die Voraussetzungen für den Einsatz von Business Mashups stehen im Mittelpunkt des nächsten Abschnitts. Dabei werden Mashups aus der Perspektive von weborientierten Architekturen, als Integrationswerkzeug sowie eines Unternehmensportals betrachtet. Daraufhin folgt das Kernstück dieser Arbeit: die Entwicklung eines Modells zur Nutzung von Business Mashups in einem Unternehmensportal. Abgerundet wird dieses Thema durch eine kurze Marktübersicht von Softwarelösungen, die die Möglichkeit des Einsatzes von Mashups in einem Unternehmen bieten. Am Ende dieses Kapitel folgt eine kri-tische Würdigung der Ergebnisse.

Abgeschlossen wird die gesamte Arbeit in Kapitel 7 mit einem Fazit sowie einer Prognose über die möglichen Entwicklungstendenzen von Business Mashups.

2 Portale

Musikportal, Nachrichtenportal, Sportportal – nahezu jeder Name einer neuen Webseite im Internet trägt mittlerweile den Begriff „Portal“ in seiner Beschreibung, häufig in Verbindung mit dem thematischen Bezug der Webseite (z.B. „Sport1.de – Deutschlands größtes Sportportal“^[5], eine Webseite zum Thema Sport). Das folgende Kapitel beschäftigt sich mit dem Begriff Portal und seiner Bedeutung. Zunächst wird dieser definiert und verschiedene Arten von Portalen werden vorgestellt, um dann den Begriff Unternehmensportal klassifizieren und definieren zu können. Daraufhin werden im technischen Bereich Portlets vorgestellt, kleine Anwendungen, welche im Rahmen von Portalsoftware für Portale Verwendung finden. Zum Abschluss dieses Kapitels werden unterschiedliche Architekturmodelle und Referenzarchitekturen, die auf unterschiedlichen Anforderungen an Portalen und Portalsoftware basieren, beschrieben.

2.1 Definition

2.1.1 Portal allgemein

So wie sich das Internet in den letzten Jahren verändert hat, änderte sich auch die Bedeutung des Begriffs „Portal“ aus informationstechnischer Sicht. Wurden Portale früher mehr als Linksammlungen gesehen, bestehend „aus einer meist exklusiv gehaltenen großen Anzahl von Links, wobei selbst wenig Content aufbereitet wird“ [Koll2004, 88] oder auch als „eine Webseite, die nach zielgruppenspezifischen Inhalten strukturiert ist und einen schnellen Zugang zu anderen Webseiten ermöglicht“ [StHa2002, 115], werden sie heute eher als „ein zentraler und persönlicher Einstieg (Single Point of Access) in die Informationswelt des Internet oder Intranet, von dem aus Verbindungen zu den relevanten Informationen und Diensten hergestellt werden können“ definiert [GrKo2005, 28]. Dabei zeigt sich eine Weiterentwicklung der Portale von einfachen Linksammlungen und Einstiegsseiten von Internet-Suchmaschinen, hin zu komplexen Webseiten, mit einem umfassenden Informationsangebot oder einer mit Inhalten, Diensten und Funktionen integrierten Unternehmens-Webanwendung. Durch die gestiegene Menge an Daten und Informationen, erwies es sich als nötig, zusätzlich zu den Elementen zur Unterstützung der Informationsnavigation, weitere Funkti-onen zu implementieren. Dazu zählt auch die Möglichkeit Portale zu personalisieren, um z.B. nur Inhalte zu Themen angeboten zu bekommen, die die eigenen Interessen widerspiegeln (vgl. [KGHV2004, 3; ScWi2002, 9; AbHe2003, 13 und GrKo2005, 28]).

Portale lassen sich zudem anhand unterschiedlichster Kriterien einordnen. Im Hinblick auf die Definition von Unternehmensportalen werden im Folgenden die Kriterien „Fokus“ und „Nutzerkreis“ vorgestellt, mit deren Hilfe sich Unternehmensportale hinreichend definieren und kategorisieren lassen. Unternehmensportale selbst werden im weiteren Verlauf noch differenziert, nach ihrem Anwendungsbereich und ihrer Zielgruppe, betrachtet (vgl. [GrKo2005, 29]).

2.1.1.1 Kriterium Fokus

Wird sich auf den inhaltlichen Fokus eines Portals als Unterscheidungskriterium bezogen, muss zwischen horizontalen und vertikalen Portalen unterschieden werden. Horizontale Portale bieten ein in der Breite sehr vielfältiges Informationsangebot. Dabei wird keine spezielle Zielgruppe angesprochen und stattdessen werden unterschiedliche Themen und Kategorien in grober, oberfläch-licher Form präsentiert. Als horizontale Portale gelten u.a. Bild.de^[6], T-Online.de^[7] oder Web.de^[8] (vgl. [GrKo2005, 29; TKLM2003, 215 ff.]).

Vertikale Portale hingegen bieten ein tiefes Informationsangebot für spezi-elle Themenbereiche. Es werden bestimmte Zielgruppen oder Themengebiete angesprochen. Letztere werden dabei ausführlich und detailliert präsentiert. Als vertikale Portale gelten in Unternehmen auch Kollaborationsplattformen, z.B. für die Zusammenarbeit bei einzelnen Projekten. Ein Beispiel für ein vertikales Portal wäre Bundesliga.de^[9], wo eine große Informationsvielfalt rund um das Thema Fußball-Bundesliga vorgefunden werden kann (vgl. [GrKo2005, 29 ff; TKLM2003, 215 ff.].

Jedoch sind die beiden Begriffe nicht wirklich trennscharf. Werden demzufolge einige Portale in Relation zu anderen gesehen, dann fällt auf, dass ein Portal aus einer bestimmten Perspektive horizontal, aus einer anderen wiederum vertikal ausgerichtet sein kann. Als Beispiel wird zunächst Web.de herangezogen, welches ein klassisches Beispiel für ein horizontales Portal mit einem breiten Themenangebot, wie z.B. Autos, Finanzen, Reisen und Sport dargestellt. Wird nun das Portal von Sport1.de^[10] herangezogen, stellt sich dieses im Bezug zu Web.de als vertikales Portal rund um das Thema Sport heraus, da es sich nur auf dieses Thema spezialisiert und ausführlich darüber berichtet. Wird das Ganze jedoch aus der Sport-Perspektive gesehen, so erweist sich Sport1.de als horizontales Portal, mit einem breiten Themenangebot zu verschiedenen Sportarten. Ein Fußball-Fan würde bei Interesse zu einem anderen vertikalen Portal greifen, wie Bundesliga.de, um dort sein Informationsbedürfnis zu diesem speziellen Thema zu stillen.

2.1.1.2 Kriterium Nutzerkreis

Ein weiteres Unterscheidungskriterium für Portale ist der vorgesehene Nutzerkreis. Hier wird zwischen offenen und geschlossenen Portalen unterschieden. Offene Portale können im Allgemeinen von jedem Benutzer genutzt werden. Dies kann aber unter Umständen trotzdem bedeuten, dass sich die Benutzer dieser Portale zuvor registrieren müssen, um die Funktionen des Portals nutzen zu können. Die Offenheit bezieht sich in diesem Fall darauf, dass jeder Benutzer die Möglichkeit hat, sich für ein solches Portal registrieren zu können und diese Registrierung nicht nur auf bestimmte Personengruppen beschränkt ist. Durch diese Registrierungsmöglichkeit und einer folgenden Authentifizierung beim Einloggen, ist eine Personalisierung der jeweiligen Portalfunktionen und -inhalte möglich (vgl. [GrKo2005, 30]).

Im Gegensatz dazu stehen geschlossene Portale nur einer zuvor ausgewählten Personengruppe zur Verfügung. Ein Beispiel dafür wäre das Intranetportal eines Unternehmens. Dieses Portal steht nur den Mitarbeitern des Unternehmens zur Verfügung (möglicherweise zusätzlich noch Lieferanten oder Partnerunternehmen). Die Registrierung der Benutzer wird dabei durch eine zentrale Instanz durchgeführt, die einsehen kann, ob eine Person befugt ist, Zugang zum Portal zu erhalten. So wird der Zugang nur für autorisierte Personengruppen gewährleistet (vgl. [GrKo2005, 30]).

2.1.2 Unternehmensportale

Für den Begriff Unternehmensportal (im Englischen auch Enterprise Portal genannt) existieren in der Literatur mehrere ähnliche Definitionen (vgl. [ScWi2002, 7 ff.; Baue2001, 34; GrKo2005, 32 ff.; TKLM2003, 218 ff. und VlKG2005, 11 ff.]). Im Rahmen dieser Diplomarbeit wird ein Unternehmensportal wie folgt definiert: „Ein Unternehmensportal ist ein geschlossenes Portal, das den Anwendern einen individuellen, personalisierbaren Zugang zu allen relevanten Inhalten bietet, um alle Aufgaben bequem und schnell erledigen zu können. Dieser Zugang muss jederzeit und überall auf sicherem Weg erreichbar sein“ [GrKo2005, 32]. Diese Definition wird noch wie folgt erweitert:

„Ein Unternehmensportal ist definiert als eine Applikation, welche basierend auf Webtechnologien einen zentralen Zugriff auf personalisierte Inhalte sowie bedarfsgerecht auf Prozesse bereitstellt. Unternehmensportale bieten so die Möglichkeit, Prozesse und Zusammenarbeit innerhalb heterogener Gruppen zu unterstützen. Charakterisierend für Portale ist die Verknüpfung und der Datenaustausch zwischen heterogenen Anwendungen über eine zentrale Plattform mit einer einheitlichen Benutzeroberfläche. Eine manuelle Anmeldung an den einzelnen in der Plattform integrierten Anwendungen ist durch Single Sign On nicht mehr notwendig.“ [VlKG2005, 11]

Entscheidend für die Wahl dieser beiden Definitionen war zum Einen, dass sich ein Unternehmensportal mit Hilfe der zuvor eingeführten Klassifikationskriterien definieren ließ (vgl. Kapitel 2.1.1) und zum Anderen, dass gerade in der letzter-en Definition, die Prozessorientierung von Unternehmensportalen hervorgehoben wurde. Der prozessorientierte Ansatz von Unternehmensportalen unterscheidet eben diese von den bislang existierenden Unternehmenswebseiten und der Intra-netanwendungen in Unternehmen. Letztere dienten vor allem nur der internen (Intranet) und externen (Unternehmenswebsites) Informationsverbreitung von Unternehmen (vgl. [VlKG2005, 11 ff.]). Unternehmensportale stellen somit eine Weiterentwicklung von Unternehmenswebseiten und Intranets dar.

Unternehmensportale lassen sich ebenfalls weiter klassifizieren. Dies geschieht mit Hilfe der Kriterien „Zielgruppen“ (Wer soll mit dem Portal angesprochen werden?) und „Anwendungsschwerpunkte“ (Wie wird ein Portal genutzt?). Nachfolgend werden unterschiedliche Typen von Unternehmensportalen auf Basis dieser Kriterien vorgestellt. Zum Ende hin werden schließlich Gründe für den Einsatz eines Unternehmensportals genannt sowie Vor- und Nachteile wie auch Potenzi-ale vorgestellt.

2.1.2.1 Kriterium Zielgruppen

Unternehmensportale lassen sich nach ihrer Zielgruppenausrichtung klassifizieren. Zu unterscheiden wären hier Mitarbeiterportale (Employee Portals, B2E), Geschäftskundenportale (Business Portals, B2B), Lieferantenportale (Supplier Portals, B2B) und Endkundenportale (Consumer Portals, B2C). Mitarbeiterportale stellen die Schnittstelle zwischen Mitarbeitern und den Prozessen und Systemen eines Unternehmens dar. Geschäftskundenportale integrieren im Speziellen Marketing-, Vertriebs- und Serviceprozesse. Lieferantenportale hingegen bilden insbesondere Beschaffungsprozesse ab. Endkundenportale integrieren wiederum Marketing-, Vertriebs- und Serviceprozesse im Hinblick auf Endkunden^[11]. Auf dieser Basis kann ein zielgruppenspezifischer Zugriff auf Informationen, Daten, Prozesse und Funktionen eines Unternehmensportals erfolgen (vgl. [VlKG2005, 12; ScWi2002, 9; Baue2001, 36 ff.]).

2.1.2.2 Kriterium Anwendungsschwerpunkte

Ein weiteres Kriterium zur Klassifizierung von Unternehmensportalen stellt der jeweilige Anwendungsschwerpunkt dar. Hierbei lassen sich hauptsächlich vier grundlegende Ausprägungen unterscheiden: Publishing Portals, Collaborative Portals, Operational Portals und Decision Portals. In der Praxis werden jedoch nur selten Unternehmensportale vorgefunden, welche nur eine dieser Portalformen abdecken. Wahrscheinlicher ist es, auf Mischformen zu treffen, die mehrere Portaltypen repräsentieren und ihren Schwerpunkt jedoch auf einen der ge-nannten Anwendungsschwerpunkte legen [GrKo2005, 34].

Publishing Portals, oder auch (Enterprise) Information Portals, haben die Funktion, Informationen bedarfsgerecht bereitzustellen. Dabei werden nur die situations- und aufgabenrelevanten Daten, sowie interne und externe Informationen publiziert, die der Benutzer auch befugt ist einzusehen und nutzen zu dürfen (vgl. [GrKo2005, 35; Fire2003, 4]). Der Nutzer erhält somit einen personalisierten Zugriff auf das Portal und seine Inhalte. Firestone definiert die Enterprise Information Portals als „an amalgamation of software applications that consolidate, manage, analyze and distribute information across and outside of an enterprise“ (vgl. [Fire2003, 4]).

Im Gegensatz dazu dienen Collaborative Portals (Enterprise Collaboration Portals) der Miteinanderarbeit und Kollaboration. Diese Portale stellen Mitarbeitern Kommunikationsmöglichkeiten und Kollaborationsfunktionen, auch über räumliche und zeitliche Grenzen hinweg, bereit. Zu diesen Funktionen gehören u.a. synchrone und asynchrone Kommunikationsmittel, Termin- und Adressverwaltung, Datensynchronisierung in verteilten Systemen sowie „virtuelle
(Projekt-)räume mit Möglichkeiten der Dateiablage, projektbezogener Rollen- und Rechtevergabe und Projektplanungs-Funktionen“ (vgl. [GrKo2005, 35]).

Operational Portals (oder auch (Enterprise) Application Portals) integrieren unternehmensinterne Anwendungen innerhalb eines Portals. Für die Benutzer bieten diese Portale den Vorteil, über einen Single Sign-On-Mechanismus (SSO)^[12], sich einmalig, einheitlich und zentral für alle relevanten Anwendungen anzumelden (vgl. [GrKo2005, 35 ff. und VlKG2005, 11]). Der Benutzer erhält darüber hinaus eine transparente Sicht auf alle für ihn relevanten Daten.

Die auch (Enterprise) Knowledge Portals genannten Decision Portals greifen die Eigenschaften und Funktionen der zuvor genannten Anwendungsschwer-punkte auf und kombinieren sie, um Wissen zu extrahieren und Informationen aufzubereiten (vgl. [Coll2003, 30 ff.]). So stellen sie ein Prognose- und Analysewerkzeug für die strategische Entscheidungsfindung dar, das auf Data Ware-houses^[13] oder Statistikprogramme zurückgreift (vgl. [GrKo2005, 36]).

Wird im weiteren Verlauf dieser Arbeit von Unternehmensportalen gesprochen, so ist damit eine Kombination aus den oben genannten Portaltypen gemeint. Der Schwerpunkt liegt dabei jedoch im Bereich der Operational und Decision Portals, mit der entsprechenden Zielgruppe der Mitarbeiter eines Unternehmens (B2E).

2.1.2.3 Gründe / Erfolgsfaktoren für den Einsatz von Unternehmensportalen

Der Einsatz von Unternehmensportalen resultiert aus unterschiedlichen Gründen, die sich aus bereits zuvor genannten Aspekten ableiten lassen. Zunächst schaffen Portale einen zentralen und plattformunabhängigen Zugang zu Informationen und Diensten eines Unternehmens. Zudem helfen sie bei der stetig wachsenden Informationsflut relevante Daten zu filtern und zu sortieren, damit sich benötigte Informationen schneller und leichter finden lassen. Portale eröffnen, unabhängig von verschiedenen Informationssystemen, einen transparenten Blick auf Unternehmensdaten. Das hat den Vorteil, dass Anwender keine speziellen Schulungen für die Nutzung von Backendsystemen auf sich nehmen müssen, da der Zugriff über eine grafische Benutzeroberfläche, innerhalb des Web Browsers, geschieht. Portale bieten für Mitarbeiter ebenfalls den Zugriff auf alle relevanten Funkti-onen, die für die jeweilige Aufgabenbearbeitung in Frage kommen. Außerdem erlauben Unternehmensportale die Kollaboration von räumlich getrennten Mitarbeitern und Geschäftspartnern durch unterstützende Kommunikationsfunktionen auf der Grundlage von Internettechnologien (vgl. [GrKo2005, 37; ScWi2002, 10 ff.]). Hinter diesen Gründen stehen aber auch allgemeine Unternehmensziele, dazu zählen Produktivitätssteigerung, Automatisierung, Optimierung von Geschäftsprozessen, Qualitätsverbesserung und die Steigerung der Mitarbeitermotivation [GrKo2005, 37].

Jedoch muss beachtet werden, dass der Einsatz eines Unternehmensportals nicht automatisch Erfolg verspricht. Die Implementierung und der Aufbau eines Portals können sehr komplexe Züge annehmen. Gerade im Hinblick auf die Integration von Anwendungen und Backendsystemen wird eine genaue Planung erforderlich (vgl. [GrKo2005, 37; ScWi2002, 11]).

2.2 Portlets

Es wurde bereits beschrieben, dass Portale Anwendungen beinhalten, die sog. Portlets. Der folgende Abschnitt erklärt, was unter dem Begriff Portlets zu verstehen ist, auf welcher technologischen Grundlage sie beruhen und wie sie im Umfeld von Portalsoftware eingesetzt werden. Des Weiteren werden die Unterschiede zwischen Portlets, Web Services und den proprietären Webparts von Microsoft erläutert.

2.2.1 Definition

Die Funktionsweise und die technischen Grundlagen von Portlets sind in der Java Portlet Specification Java Specification Request 168 (JSR) (vgl. [AbHe2003]) festgelegt. Im Folgenden werden nur die wichtigsten Aspekte im Rahmen einer Definition von Portlets vorgestellt. Genauere Informationen bzgl. der technischen Funktionsweise von Portlets lassen sich in der Portlet Specification (siehe [AbHe2003]) nachlesen. Sie werden ebenfalls im weiteren Verlauf dieser Arbeit im Kontext von Mashups noch einmal näher vorgestellt und von diesen abgegrenzt (siehe Kapitel 5.7.3).

Portlets basieren auf Javatechnologie. Sie stellen Webkomponenten im Rahmen eines Portals dar, die durch einen Portlet Container gesteuert werden. Dieser verarbeitet die Anfragen eines Clients (engl. Requests), üblicherweise ein Web Browser und erstellt die dynamischen Inhalte der Portlets in Form von Antworten (engl. Responses). Im Portal selbst dienen die Portlets als Benutzerschnittstelle und bilden die Präsentationsschicht im Informationssystem ab (vgl. [AbHe2003, 13]). Die von einem Portlet generierten Inhalte werden Fragmente genannt und bestehen aus Komponenten von sog. Markup Languages, wie HTML oder XHTML. Der Portlet Container stellt eine Laufzeitumgebung für Portlets dar, in der
mehrere Portlets zur selben Zeit existieren können. Er steuert den Lebenszyklus der Portlets. Im Zusammenhang mit Portalen stellt der Portlet Container die Schnittstelle zwischen Portal und Portlet dar, indem er die Requests vom Portal an die Portlets weiterleitet [AbHe2003, 13]. Abbildung 1 zeigt die Erstellung einer Portalseite. Die generierten Portlets werden von einem Portlet Container verarbeitet und über den Portalserver an den Client weitergegeben. Dieser kann die Portalseite dann über einen Web Browser abrufen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Erstellung einer Portalseite und ihren Portlets

Quelle: [AbHe2003, 20]

Portlets besitzen einige Gemeinsamkeiten mit Servlets^[14]. So stellt der Portlet Container u.a. eine Erweiterung eines Servlet Containers dar und implementiert somit die gleiche Funktionalität wie dieser (für weitere Gemeinsamkeiten und Unterschiede siehe [AbHe2003, 15]).

Erstellt werden können Portlets auf Basis des JSR 168 mit Hilfe der freiverfüg-baren Portlet API 1.0^[15] des Java Community Process (JCP). Ist ein Portlet mit dieser API erstellt worden, so kann es innerhalb jeder Portalsoftware, die den JSR 168 unterstützt, genutzt werden. Portalsoftware, die diese API unterstützen sind bspw. das JBoss Portal^[16] oder das Jetspeed^[17] Portal, beides frei verfügbare Open-Source Produkte. Zusätzlich zur freien Portlet API 1.0 gibt es mittlerweile proprietäre Portlet APIs, wie die WebSphere Portal V5.0 Portlet API^[18] von IBM. Diese findet speziell Anwendung im Umfeld der WebSphere Portal Software von IBM. Momentan ist zudem auch die Portlet Specification 2.0 in der Entwicklung welche unter dem JSR 286^[19] zu finden ist.

2.2.2 Abgrenzung zu Web Services und Webparts

Es wurde bereits angedeutet, dass proprietäre Ausprägungen der Portlet API 1.0 auf dem Markt vorzufinden sind, die meistens nur von einem Hersteller explizit für seine eigene Portalsoftware entwickelt wurden. Infolgedessen bleibt noch zu erwähnen, dass auch Microsoft eine eigene proprietäre Lösung entwickelt hat. Im Rahmen des Microsoft Office SharePoint Portal Server (aktuelle Version: SharePoint Portal Server 2007^[20] ) kommen sog. Webparts zum Einsatz. Webparts sind funktionell äquivalent zu Portlets [LaMV2006, 357; Bodd2005, 325 ff.]. Im Rahmen des SharePoint Portals wird keine Unterstützung von JSR 168 angeboten, was bedeutet, dass Portlets, die nach JSR 168 entwickelt wurden, nicht in diesem Portal genutzt werden können. Andererseits sind Webparts auch nicht mit anderer Portalsoftware kompatibel. Sie werden nicht auf Grundlage des Java-basierten JSR 168 entwickelt, sondern basieren auf ASP.Net und dem .NET-Framework (vgl. [Webb2006, 233]).

Weiterhin muss zusätzlich auch zwischen Portlets und Web Services differenziert werden, da beide als Art Webapplikation angesehen werden können. Für den Begriff Web Service gibt es bisher keine einheitliche Definition. Die unterschiedlichen Unternehmen und Institutionen, wie Microsoft, Sun, IBM oder das World Wide Web Consortium (W3C), nutzen jeweils ihre eigenen Definitionen zu diesem Thema (vgl. [GSBD2002, 8 ff.; DJMZ2005, 26; W3C2004]). Eine allgemeine Definition stellt dabei die des W3C dar:

“A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.” [W3C2004]

Gemeinsam haben die oben genannten Definitionen, dass es sich bei Web
Services um Dienste / Anwendungen handelt, die über ein Netzwerk (Internet oder Intranet o.ä.) abrufbar sind. Sie werden mit Hilfe von WSDL (Web Service Description Language, siehe [DJMZ2005, 77 ff.; GSBD2002, 321 ff.; ZiTP2003, 104 ff.]), einer XML-basierten Beschreibungssprache artikuliert, die den Web Service sowie seine Schnittstellen beschreibt (vgl. [ACKM2004, 166]) und sind plattformunabhängig einsetzbar. Web Services können in Portlets genutzt werden, dabei findet der „Web Services for Remote Portlets“-Standard (WSRP) von Oasis Verwendung (siehe [KrLT2003]). Dieser Standard beschreibt eine Schnittstelle für Web Services, die eine Interaktion mit präsentationsorientierten
Diensten ermöglicht. In diesem Zusammenhang stellen Portlets die Präsentationsschicht im Portalumfeld dar. Der Web Service hingegen stellt die Anwendung bereit, die im Rahmen des Portlets, aufgrund der WSRP-Unterstützung, visualisiert wird.

2.3 Architekturmodelle und Referenzarchitekturen

Zum Abschluss dieses Themas werden Architekturmodelle und Referenzarchitekturen für Portale und Portalsoftware vorgestellt. Anfangs wird zunächst ein fachliches Architekturmodell vorgestellt, das auf den Anforderungen der jeweiligen Fachabteilungen beruht. Im Anschluss daran wird eine Referenzarchitektur für Portale präsentiert, die wiederum auf den technischen Anforderungen eines Portals beruht. Abgeschlossen wird dieses Kapitel mit der PADEM Referenzarchitektur für Portalsoftware des Fraunhofer Instituts. Diese Referenzarchitektur stellt eine Bewertungsgrundlage des Funktionsumfangs von Portalsoftware dar. Es sei zu beachten, dass nachfolgend die jeweiligen Modelle, Architekturen und Anforderungen nur kurz vorgestellt werden. Für genauere Erklärungen der einzelnen Komponenten wird an den entsprechenden Stellen auf weiterführende Literatur verwiesen.

2.3.1 Fachliches Architekturmodell

Die fachlichen Anforderungen an ein Unternehmensportal resultieren aus den Anforderungen der jeweiligen Fachabteilungen an eben jenes. Ein Unternehmensportal hat die Aufgabe, Geschäftsprozesse abbilden und steuern zu können (siehe [GrKo2005, 79 ff.]). Dies erfordert durchgängige Prozesse, eine Steigerung der Produktivität oder die Reduzierung der Prozesskosten (vgl. [GrKo2005, 86]). Zudem muss ein Portal für die Mitarbeiter eine einheitlich integrierte Sicht auf Daten bieten (siehe [GrKo2005, 87 ff.]). Hierbei werden u.a. eine höhere Informationsqualität oder eine hohe Aktualität von Kennzahlen gefordert (vgl. [GrKo2005, 93]). Eine weitere Anforderung stellt die Personalisierbarkeit des Portals dar (siehe [GrKo2005, 94 ff.]). Dabei stehen u.a. eine hohe Benutzerfreundlichkeit oder eine Beschränkung auf relevante Informationen im Mittelpunkt (vgl. [GrKo2005. 98]). Es wird zudem ein SSO Mechanismus gefordert (siehe [GrKo2005, 98 ff.]), der u.a. eine zentrale Schnittstelle zu Unternehmensdaten darstellt und eine einfache Administration ermöglicht (vgl. [GrKo2005, 102]). Folgerichtig ist auch ein hoher Grad an Sicherheit gefordert (siehe [GrKo2005, 102 ff.]), der den Schutz sensibler Daten, eine sichere Kommunikation oder Datenschutz im Allgemeinen garantiert (vgl. [GrKo2005, 105]). Zwingend erforderlich ist auch ein funktionierendes Benutzer- und Rollen-management, das u.a. zielgruppengenaue Angebote und einen rechtebasierten Portalzugriff ermöglicht (vgl. [GrKo2005, 105 ff.]). Das Portal sollte ebenfalls eine ergonomische Benutzerschnittstelle bereitstellen (siehe [GrKo2005, 108 ff.]). Weitere Anforderungen wären noch ein möglicher multimodaler Zugriff, wodurch das Portal über unterschiedliche Kommunikationskanäle abrufbar wird (siehe [GrKo2005, 110 ff.]), sowie eine zukunftssichere Architektur des Portals, die Erweiterungen und Änderungen des Portals ohne größere (wirtschaftlichen) Kosten ermöglicht, wobei die verwendete Technologie auch zukünftig einsetzbar sein muss (siehe [GrKo2005, 112 ff.]).

Nach dieser kurzen Vorstellung der fachlichen Anforderungen, lässt sich daraus ein fachliches Architekturmodell ableiten. Dieses Modell besteht aus einer Integrationskomponente, einer Prozesskomponente, Portalapplikationen, einer Präsentationskomponente, der Business Intelligence, dem Knowledge Management, der Benutzerverwaltung, den Sicherheitsmechanismen sowie einer Programmierschnittstelle und –werkzeugen (siehe Abbildung 2). Weitere Erklärungen zu den Komponenten finden sich in der Literatur (siehe [GrKo2005, 157 ff.]). In Verbindung mit Business Mashups werden einzelnen Komponenten des Architekturmodells, an einer anderen Stelle in dieser Arbeit näher vorgestellt (siehe Kapitel 6.4.2.1).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: fachliches Architekturmodell

Quelle: [GrKo2005, 157]

2.3.2 Technische Referenzarchitektur

Um die fachlichen Anforderungen an ein Portal umsetzen zu können sind auch einige technische Voraussetzungen zu erfüllen. Diese beziehen sich jedoch nicht primär auf das Unternehmensportal selbst, sondern betreffen die gesamte IT-Architektur eines Unternehmens. Wie im vorangegangenen Abschnitt, werden die Anforderungen hier ebenfalls nur kurz genannt, für nähere, genauere Beschreibungen wird jeweils auf die entsprechende Literatur verwiesen. Zunächst wäre die Integration der technischen Systeme zu erwähnen (siehe [GrKo2005, 115 ff.]). Hierzu zählen die Systemintegration (vgl. [GrKo2005, 116 ff.]), die Prozessintegration (vgl. [GrKo2005, 119 ff.]) sowie die Frontend- und Backend-Integration (vgl. [GrKo2005, 120 ff.]). Hinzu kommt, dass die Integration von heterogenen Daten und Datenstrukturen gewährleistet werden muss. Abhängig sind die Formen der Integrationsmöglichkeiten davon, ob auf strukturierte oder unstrukturierte Daten zugegriffen wird (siehe [GrKo2005, 125 ff.]). Als nächstes sind die Metadatenmodelle zu erwähnen, die dazu dienen, die vorhandenen Daten einer besseren Beschreibung unterziehen zu können (siehe [GrKo2005, 129 ff.]). Weitere Anforderungen betreffen die Kategorien Datensicherheit, Verfügbarkeit, IT-Sicherheit, Skalierbarkeit, Verteilbarkeit und Performanz (siehe [GrKo2005, 132 ff.]). Wichtig ist auch die Nutzung von standardisierten Technologien und offenen Schnittstellen (siehe [GrKo2005, 147 ff.]).

Auf Basis dieser Anforderungen und den technischen Systemkomponenten eines Portals beruht die technische Referenzarchitektur (siehe Abbildung 3). Zu ihren Komponenten gehören eine Middleware samt EAI (siehe [GrKo2005, 173]), ein Transaktionsmanager (siehe [GrKo2005, 174]), ein Metadatenserver (siehe [GrKo2005, 175]), ein Portalserver und Portlet-Container (siehe[GrKo2005, 176]), ein Web-Applikationsserver (siehe [GrKo2005, 176 ff.]), eine Firewall (siehe [GrKo2005, 179], Web Services sowie eine Portaladministration und
–überwachung (siehe [GrKo2005, 180 ff.]). Eine genauere Beschreibung der einzelnen Komponenten und deren Bedeutung im Umfeld von Business Mashups erfolgt in einem späteren Abschnitt dieser Arbeit (siehe Kapitel 6.4.2.2).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: technische Referenzarchitektur

Quelle: [GrKo2005, 171]

2.3.3 PADEM Referenzarchitektur für Portalsoftware

Eine weitere Referenzarchitektur, speziell für Portalsoftware, wurde von dem Fraunhofer Institut für Arbeitswirtschaft und Organisation (IAO) entwickelt. In der PADEM Portalsoftware Referenzarchitektur 2.0 werden die Anforderungen von Portalsoftware festgehalten, die beschreiben, welchen Funktionsumfang eine Portalsoftware haben sollte. Wie in der Abbildung 4 auffällt, sind besonders im Bezug zur technischen Referenzarchitektur Parallelen zu entdecken.

Die PADEM Referenzarchitektur besteht aus den drei Schichten Präsentation, Anwendungslogik und Backend. Die Präsentationsschicht beschreibt die verschiedenen Möglichkeiten zur Darstellung des Portals auf unterschiedlichen Endgeräten, wie Web- oder WAP-Browser. Die Anwendungslogikschicht besteht aus den Hauptkomponenten Bereitstellungsdienste, Portalsoftware, Transaktionsdienste sowie als Schnittstelle zum Backend, die Integrationsdienste. Die Portalsoftware ist dabei noch in die Komponenenten Portalanwendungsvisualisierung, individuelle Portalanwendungen, Portalanwendungsmodule und Portalbasisdienste unterteilt, die über die Portal-API miteinander kommunizieren. Die dritte Schicht ist die Backendschicht, in der unterschiedliche Anbindungsformen von Datenhaltungssystemen beschrieben werden (für eine detaillierte Beschreibung der Referenzarchitektur und ihrer Komponenten wird an dieser Stelle auf [VlKG2005, 14 ff.] und Kapitel 6.4.2.3 verwiesen).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: PADEM Portalsoftware Referenzarchitektur 2.0

Quelle: [VlKG2005, 15]

3 Serviceorientierte Architekturen

Einer der größten Trends, die die IT-Welt in den letzten Jahren geprägt haben, sind die sog. serviceorientierten Architekturen (SOA, vgl. [Alex2007]). Im folgenden Kapitel wird diese Form von Softwarearchitekturen vorgestellt und definiert. Es wird gezeigt, welche Elemente zu den grundlegenden Bestandteilen dieses Architekturtyps gehören und aus welchen Gründen Unternehmen eine SOA einführen und darüber hinaus nutzen sollten. Zum Abschluss dieses Kapitels wird erklärt, welche Rolle Portale hierbei spielen. Das Ziel dieses Kapitel ist eine grundlegende Einführung in die Welt der SOAs, bei der die wichtigsten Konzepte und Fragestellungen zu diesem Thema vorgestellt werden.

3.1 Definition

Für den Begriff SOA gibt es keine einheitliche, standardisierte Definition, jedoch ähneln sich die unterschiedlichen Begriffsbestimmungen inhaltlich sehr (vgl. [Heut2007, 21 ff.]), wie folgende Beispiele zeigen:

“Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains.” [MLMB2006, 8]

“A service-oriented architecture is a framework for integrating business processes and supporting IT infrastructure as secure, standardized components – services – that can be reused and combined to address changing business priorities.” [BBFJ2006, 5]

“A set of components which can be invoked, and whose interface descriptions can be published and discovered.” [W3C2004]

Die verschiedenen Definitionen haben gemeinsam, dass eine SOA eine Softwarearchitektur ist, „die Teile von Applikationen für eine vereinfachte Prozessintegration als geschäftsorientierte Services kapselt“ [Heut2007, 22]. Als Elemente dieser Softwarearchitektur lassen sich dabei das Anwendungs-Frontend, die Services, das Service-Repository und der (Enterprise) Service-Bus identifizieren (vgl. [KrBS2007, 76 ff.]). Im Groben lässt sich das Grundkonzept der Service-orientierung wie folgt erklären: Ein Service Anbieter (Service Provider) veröffentlicht einen Service und bietet diesen zur Nutzung an. Dieser wird in einem zen-tralen Service-Verzeichnis (Service Registry) verwaltet und kann hierüber gefunden werden. Ein Service-Nutzer (Service Requestor) findet diesen Service samt seiner Quelle im Verzeichnis und kann diesen verwenden. Die Nutzung beruht auf einem direkten Datenaustausch zwischen Service-Nutzer und Service-Anbieter (vgl. auch [MSJL2006, xxi ff.; Erl2006, 74 ff.; Kaye2003, 95 ff.]). Abbildung 5 verdeutlicht dieses Grundprinzip der Serviceorientierung anhand der Beziehungen von Service-Nutzer, Service-Anbieter und Service-Verzeichnis untereinander.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Das Prinzip der Serviceorientierung

Quelle: in Anlehnung an [MSJL2006, xxii; Erl2006, 75; Kaye2003, 96]

Das Konzept der Serviceorientierung ermöglicht es, dass die einzelnen Services gekoppelt und wieder verwendet werden können. Das Prinzip der Kopplung von verschiedenen, voneinander unabhängigen Services zu einer Anwendung wird auch Loose Coupling (lose Kopplung) genannt (siehe [Kaye2003; Erl2006, 315]). Dabei werden die einzelnen Services, die in ihrer Kombination eine funktionierende Anwendung ergeben, zur Laufzeit dieser zusammengefügt und verwendet. Im Vergleich zur traditionellen Anwendungsarchitektur ergibt sich dabei ein Vorteil hinsichtlich der Entwicklungszeit von Anwendungen sowie einer geringeren Komplexität der Entwicklung. Es müssen eventuell nur noch kleine, nicht sehr umfangreiche Komponenten einer Anwendung neuentwickelt werden, während andere, als Service vorliegende Komponenten erneut verwendet werden können (vgl. [Kaye2003, 92 ff.]).

Aufbauend auf den offenen Schnittstellen der Services (siehe Kapitel 3.2.1), wird die Interoperabilität zwischen unterschiedlichen Systemen ermöglicht (vgl. [BBFJ2006, 4 ff.]). Die meisten Definitionen sehen Web Services als die typische Implementierungsform von Services innerhalb einer SOA. Daraus folgt, dass eine SOA eine Architektur beschreibt, die auf den grundlegenden Web Service-Technologien (wie SOAP, WSDL und UDDI) basiert (vgl. [BBFJ2006, 5]). Es ist jedoch bei dieser Form von Softwarearchitekturen nicht zwingend vorgeschrieben, die Services auf der Grundlage von Web Services umzusetzen. In den meisten Fällen werden Web Services aber als die Basistechnologie betrachtet (vgl. [Cart2007, 76 ff.]).

3.2 Elemente einer SOA

Für eine genauere Beschreibung einer SOA, werden im folgenden Abschnitt die Kernelemente Services, Anwendungs-Frontend, Service-Repository und Service Bus detaillierter beschrieben. Dabei wird vor allem die Bedeutung der Services in den Vordergrund gestellt. Diese Kernelemente bilden das Schlüsselkonzept im Rahmen einer SOA.

3.2.1 Services

Die Kernkomponente einer SOA sind, wie bereits angedeutet wurde, die sog. Services. Dieses sind Softwarekomponenten mit speziellen Funktionen, die sich wie folgt definieren lassen:

„Ein Service stellt ein abstraktes Software-Element bzw. eine Schnittstelle dar, die anderen Applikationen über ein Netzwerk einen standardisierten Zugriff auf Anwendungsfunktionen anbietet.“ [Heut2007, 22]

Der Service stellt sozusagen einen Dienst für andere Services oder Softwarekomponenten bereit. Der Vorteil bei der Verwendung von Services ist, dass Geschäftsprozesse viel einfacher an unternehmerische Anforderungen angepasst werden können, da sie miteinander gekoppelt und wieder verwendet werden können. Dies geschieht durch die Möglichkeit, dass unterschiedliche Services zu neuen Anwendungen kombiniert werden können. Dabei greifen die einzelnen Komponenten auf Funktionen der anderen Komponenten zu. In Abbildung 6 greift Service B auf die Funktionen von Service A zu. Die Anwendung ABCD ergibt sich daraufhin aus einer Kombination der Services B, C und D. Insgesamt sind dabei die vier Services A, B, C und D mit ihren Funktionen an der Anwendung ABCD beteiligt, die nun wiederum selbst einen nutzbaren Service darstellt. Die Aggregation oder besser gesagt die Kopplung wird auch als „Service Composition“ bezeichnet (vgl. [Erl2008, 39; WoMa2006, 142]). Dahinter verbirgt sich wiederum, das bereits oben vorgestellte Prinzip der losen Kopplung, welches vorsieht, dass Services untereinander keine Abhängigkeiten vorweisen und dementsprechend unabhängig voneinander genutzt und gekoppelt werden können. Das bedeutet, dass kein Service die Funktionen eines anderen voraussetzt (vgl. [Kaye2003, 131 ff.; Erl2006, 315]). Die SOA wird dadurch sehr flexibel hinsichtlich der Nutzung ihrer Komponenten (vgl. [BBFJ2006, 4 ff.]), da die unterschiedlichen Services für weitere Anwendungen wiederverwendet werden können (vgl. [Erl2006, 292 ff.]). Die Bestandteile eines Services sind der Service-Vertrag, Schnittstellen, die Implementierung sowie Geschäftslogik und Daten (vgl. [KrBS2007, 78 ff.] sowie Abbildung 7), welche im Folgenden näher vorgestellt werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Service Composition

Der Service-Vertrag beschreibt informell den Zweck, die Funktionalität, die Beschränkungen und die Nutzung des Services. Dazu kann ebenfalls eine for-male Schnittstellendefinition auf Basis von IDL oder WSDL vorhanden sein (dies ist aber nicht zwingend erforderlich). Der Vertrag liefert demzufolge Informationen über einen Service und stellt keine formale Spezifikation dar (vgl. [KrBS2007, 79; Erl2006, 313 ff.]). Der Service-Vertrag beschreibt zudem sämt-liche Ein- und Ausgabeoperationen, sowie deren Ein- und Rückgabewerte, des jeweiligen Services (vgl. [Erl2006, 295]). Anders gesagt: er beinhaltet sämtliche Metadaten eines Services hinsichtlich der Regeln und Bedingungen die erfüllt werden müssen, wenn mit dem Service interagiert wird (vgl. [Erl2006, 313 ff.]).

Die einzelnen Funktionen eines Services werden dem Client^[21] über Schnittstellen bereitgestellt. Zwar werden die Schnittstellen im zuvor genannten Service-Vertrag beschrieben, jedoch werden sie als Service-Stubs^[22] implementiert, die von Clients des Services und einem Dispatcher verwendet werden (vgl. [KrBS2007, 79]).

Die Implementierung stellt die technische Umsetzung des Service-Vertrages dar, bestehend aus verschiedenen Elementen, wie Programmen oder Daten-banken und enthält zudem die Geschäftslogik und die entsprechenden Daten (vgl. [KrBS2007, 79]).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Bestandteile eines Service

Quelle: in Anlehnung an [KrBS2007, 78]

Abschließend bleibt zu erwähnen, dass ein Service eine Einheit mit einer spezi-ellen funktionalen Bedeutung darstellt. Clients haben somit einen transparenten Blick auf die Funktion eines Services und haben zwar Kenntnis darüber, welchen Zweck ein Service erfüllt, aber nicht wie. Es wird demnach von der technischen Funktionsweise abstrahiert. Der Service stellt somit eine geschlossene Blackbox dar, die einen speziellen Dienst anbietet (vgl. [KrBS2007, 79]). Häufig werden auch Web Services als funktionales Äquivalent zu Services gesehen (vgl. [Cart2007, 76 ff.]).

Als grundlegende Eigenschaften von Services im Umfeld einer SOA lassen sich durch die vorigen Ausführungen folgende identifizieren (in Anlehnung an [Erl2006, 312 ff.]):

- Lose Kopplung
- Wiederverwendbarkeit
- Service-Komposition
- Service-Verträge
- Service-Unabhängigkeit
- Abstraktion
- Verwaltbarkeit

3.2.2 Anwendungs-Frontend

Zum Anwendungs-Frontend zählt zum Einen die klassische grafische Benutzeroberfläche (GUI), worüber die Endanwender mit den Anwendungen und Komponenten einer SOA interagieren und zum Anderen Batch-Programme und langlebige Prozesse, die kontinuierlich, bestimmte Funktionen aufrufen (vgl. [KrBS2007, 78]). Anwendungs-Frontends initiieren Geschäftsprozesse und erhalten die Ergebnisse zurück. Sie stellen Clients dar, die Services aufrufen und deren Funktionen nutzen. Dabei kann es vorkommen, dass ein Geschäftsprozess auf einen oder mehrere Services aufgeteilt wird. Im Vergleich mit den Services haben die Anwendungs-Frontends kürzere Lebenszyklen, d.h. sie sind häufiger Änderungen unterzogen. Daraus lässt sich zusätzlich die zentrale Bedeutung der Services in einer SOA erkennen (vgl. [KrBS2007, 77]).

3.2.3 Service-Repository

Sind in einer SOA eine größere Menge an Services vorhanden, empfiehlt sich die Einführung eines Service-Repository (auch Service Inventory genannt, vgl. [Erl2008, 40]). Es dient dem Zweck der Auffindbarkeit von, in einer SOA vorhandenen, Services und verwaltet diese (vgl. [Cart2007, 81 ff.]). Es stellt somit eine Art Verzeichnis dar. Neben den im Service-Vertrag bereitgestellten Informationen und Metadaten, kann ein Service-Repository zusätzlich noch weitere Informationen über einen Service anbieten, wie seinen Anbieter, physischer Standort, Zugriffsrechte, Leistung und Skalierbarkeit des Service oder Sicherheits-aspekte. Es muss zudem zwischen unternehmensübergreifenden und unternehmensinternen Repositories unterschieden werden, die jeweils unterschiedlichen Anforderungen unterliegen (u.a. Rechtsfragen, Präsentation, Sicherheit, Verwaltungsfragen). Für die technische Umsetzung eines Repositories gibt es keine Vorgaben: theoretisch ist es möglich, die Services auf Basis von gedruckten Dokumenten zu verwalten; praktisch werden die Services meistens in Datenbanken innerhalb des Unternehmens verwaltet (vgl. [KrBS2007, 80; WoMa2006, 191 ff.]). Zum Verwalten eines solchen Verzeichnisses innerhalb eines Unternehmens ist es erforderlich, eine zentrale Instanz für die Wartung, Überwachung und Koordination einzuführen.

3.2.4 (Enterprise) Service-Bus

Der Service-Bus stellt das Kommunikationsmedium in einer SOA dar (vgl. [Cart2007, 85]). Er ist das verbindende Glied zwischen Services und Anwendungs-Frontends. Der Service-Bus muss verschiedene Eigenschaften besitzen. Als erstes wäre die Konnektivität zu nennen, die es ermöglicht, dass alle Teilnehmer einer SOA (Anwendungs-Frontends und Services) miteinander verbunden sind und Services aufrufen können. Zudem muss die Heterogenität der Technologie gewährleistet sein. Der Service-Bus muss in der Lage sein, Teilnehmer, die auf unterschiedlichen Technologien basieren (wie verschiedene Programmiersprachen, Betriebssysteme oder Laufzeitumgebungen, aber auch Middleware und Kommunikationsprotokolle), miteinander verbinden zu können. Analog dazu verhält es sich mit der Heterogenität von Kommunikationskonzepten. Auch hier müssen unterschiedliche Konzepte vereint und deren Kompatibilität untereinander gewährleistet werden. Als Beispiel wären hier unterschiedliche Einrichtungen für synchrone oder asynchrone Kommunikation zu nennen. Als letzte Eigenschaft sind sog. technische Services zu erwähnen. Zusätzlich zur Kommunikation ist der Service-Bus noch für die Bereitstellung von technischen Diensten und Wartungsdiensten zuständig. Hierzu zählen u.a. Protokollierung, Auditing und Sicherheit (vgl. [KrBS2007, 83 ff.]). Für eine detailliertere Beschreibung sei an dieser Stelle noch einmal auf weiterführende Literatur verwiesen, da eine genauere Betrachtung den Rahmen dieses Kapitels übersteigen würde (siehe z.B. [KrBS2007, 173 ff.; BBFJ2006, 43 ff.]).

3.3 Gründe für den Einsatz einer SOA

Die Gründe für die Einführung und Nutzung einer SOA lassen sich aus ihren Vorteilen ableiten. Für eine Sicht auf die Vorteile eignen sich zwei Perspektiven: die Unternehmensperspektive und die Personalperspektive.

3.3.1 Die Unternehmensperspektive

Ein Ziel aus unternehmerischer Sicht ist es, ein agiles Unternehmen aufzubauen, basierend auf einer technisch und organisatorisch flexiblen Infrastruktur. SOAs dienen dem Zweck, diese Flexibilität zu erreichen und somit eine Agilitätssteigerung zu erzielen. Um jedoch eine Agilitätssteigerung erzielen zu können, muss die Komplexität unterschiedlicher Elemente reduziert werden. Zu diesen gehören die Technologie, Geschäftsprozesse, Geschäftsfunktionalität, Integration und Wartung (vgl. [KrBS2007, 253]).

Hinsichtlich der Technologie resultiert die Komplexität aus heterogenen technischen Lösungen, die unter Umständen inkompatibel zueinander sind bzw. Insellösungen darstellen oder sogar technisch veraltet sind. Weniger offensichtlich stellen sich komplexe Geschäftsprozesse dar. Sie sind häufig nicht direkt ersichtlich und so kann ihre Komplexität häufig erst bei einer Implementierung erkannt werden. Gleiches gilt in ähnlicher Weise für die Geschäftsfunktionalität. Einzelne Teilelemente erscheinen nicht komplex, werden diese jedoch zusammengeführt, lassen sich komplexe Strukturen entwickeln. Zu Problemen kann es auch bei der Integration von Anwendungen kommen, die zwar an sich funktionell ihren Dienst leisten, jedoch in einem neuen Kontext zu Problemen führen können. Bei der Wartung können ebenfalls Probleme auftreten. So kann eine Aktualisierung einer Komponente die Aktualisierung weiterer Komponenten des Systems nach sich ziehen (vgl. [KrBS2007, 253; BBFJ2006, 17 ff.]).

SOAs helfen die Komplexität der zuvor genannten Elemente zu reduzieren. Dazu nutzen sie unterschiedliche Mittel. Zunächst zerlegen sie große, komplexe Systeme in die bereits vorgestellten Anwendungs-Frontends und Services. Eine geeignete Granularität der Services ist notwendig, um die Anwender nicht zu sehr mit Details zu überlasten, z.B. dadurch, dass Services zu kleine Funktionseinheiten darstellen (vgl. [KrBS2007, 254; Erl2006, 556 ff.]). SOAs bieten außerdem einen technologisch transparenten Blick auf das Gesamtsystem. Die Funktionsweise einer solchen Softwarearchitektur und ihrer Komponenten kann folglich auch verstanden werden, ohne dass sich das involvierte Personal mit der Technologie auskennen muss. Ein weiteres Mittel ist die Wiederverwendbarkeit der einzelnen Services. Dies ermöglicht eine zielorientiertere Arbeit und es werden Redundanzen vermieden, sowie doppelte Arbeit bei der Erstellung von immer gleich bleibenden Grundfunktionen. Als letztes sei noch die Dokumentation der einzelnen Services durch die Service-Verträge zu nennen, die wiederum die Verständlichkeit der SOAs und ihrer Komponenten erhöht (vgl. [KrBS2007, 254; BBFJ2006, 17 ff.]).

SOAs bieten zudem Möglichkeiten für Kosteneinsparungen. Diese können einerseits auf Geschäftsebene (indirekte Einsparungen), aber auch im Bereich der IT-Kosten (direkte Einsparungen) auftreten. Auf Seiten der Geschäftsebene helfen SOAs bei der Lösung verschiedener Probleme im Rahmen der Auswahl der preiswertesten Lieferanten, aber auch bei der Zielorientierung der Geschäftsprozesse und bei einem verbesserten Reporting. Im Bezug zu den IT-Kosten helfen SOAs bei der Reduzierung der Projektkosten durch eine effizientere Implementierung von Anwendungen und der Weitergabe von Services. Sie reduzieren zudem die Wartungskosten aufgrund einer weniger komplexen Anwendungsarchitektur. Außerdem ermöglichen sie den Einsatz von zukunftssicheren Lösungen, bspw. durch die Abstraktion von der Technologie (vgl. [KrBS2007, 254 ff.]), was sich positiv auf die Weiterentwicklung einer IT-Architektur auswirkt.

Die Wiederverwendbarkeit von Services stellt den nächsten Vorteil von SOAs dar. Services können nicht nur für die Projekte genutzt werden, für die sie ursprünglich entwickelt wurden, sondern stehen anderen, zukünftigen Projekten weiterhin zur Verfügung. Sie sind zudem auch nicht an spezielle technische Infrastrukturen gebunden (vgl. [KrBS2007, 256]). Dieser Aspekt erweist sich als äußerst vorteilhaft im Hinblick auf die klassische Anwendungsentwicklung. Hierbei wurde immer eine spezielle Softwarelösung für ein bestimmtes Problem entwickelt, die jedoch nicht für andere Zwecke genutzt werden konnte. Die Wiederverwendbarkeit ermöglicht die Nutzung von einzelnen entwickelten Services in neuen, zukünftigen Anwendungen. Dies bringt eine Zeit- und Kostenersparnis mit sich (vgl. [Erl2008, 76]). Die Wiederverwendung von Services wirkt auch der Redundanz von Anwendungsfunktionalitäten entgegen. Gab es zuvor unterschiedliche, eigenständig entwickelte Anwendungen, die zu einem bestimmten Teil auf ein und derselben Funktionalität beruhten, so wurde diese Funktionalität für jede Anwendung wieder neu entwickelt. In einer SOA genügt es, diese Funktion einmal zu entwickeln und bereitzustellen, um sie dann in Form eines Services für jede weitere, denkbare Anwendung zu nutzen (vgl. [Erl2008, 78 ff.]).

SOAs und im Speziellen auch ihre Services bieten einen transparenten Blick auf die wesentliche Funktionalität und abstrahieren dadurch stark von technischen Aspekten. Dies hat eine Technologieunabhängigkeit zur Folge, die es ermöglicht, sich nicht mehr mit der Frage nach der richtigen Technologie zu beschäftigen, sondern mehr Zeit in die Entwicklung und Funktionalität der einzelnen Services zu investieren. Anwendungslandschaften mit heterogenen Technologien (wie J2EE und .NET) werden so agiler und effizienter gestaltet. Jedoch muss bedacht werden, dass eine SOA niemals eine absolute Technologieunabhängigkeit bietet, da sie auch eine gewisse homogene, technische Infrastruktur als Grundlage benötigt (vgl. [KrBS2007, 257]).

SOAs bieten weiterhin eine flexible Geschäftsinfrastruktur. Sie bieten die Gelegenheit, sich an die ständig wechselnden Geschäftsbedingungen und –prozesse flexibel anzupassen. So werden Technologie, Prozesse, Geschäftsregeln und Daten zu flexiblen Bausteinen entkoppelt, die im Einzelnen trotzdem noch im Betrieb bleiben können, falls eine Komponente mal veraltet sein sollte (vgl. [KrBS2007, 258]). In diesem Fall können veraltete Komponenten durch neue, aktuelle ersetzt werden.

Die Reduzierung der Komplexität des Entwicklungsprozesses ist ein weiterer Vorteil. Werden für ein Projekt innerhalb eines Unternehmens Services entwickelt, so sind diese nicht zwingend mit eben diesem Projekt verknüpft, sondern können auch noch für weitere Projekte genutzt werden (siehe oben). Die einzelnen Komponenten einen Projekts können als Services auf mehrere Teams aufgeteilt werden. Zu beachten wäre hierbei eine genaue Schnittstellenbeschreibung. Dies ermöglicht es, Projekte auf mehrere kleine Teams zu verteilen, die einzelne Services entwickeln und reduziert so die Probleme, die bei großen komplexen Teams auftreten können (vgl. [KrBS2007, 258 ff.]).

Die Möglichkeit, dass SOAs die Unternehmensentwicklung unterstützen ist ebenfalls vorteilhaft. Probleme bei der technischen Unternehmensevolution stellen das Ausfallrisiko, die Änderungskapazität, die Einbeziehung von Interessensgruppen sowie die Machbarkeit dar. Durch die Kapselung in Komponenten mit einzelnen Funktionen, können in einer SOA selbst größere, riskantere Projekte, die durch eine Unternehmensevolution bedingt sind, in kleine Teilprojekte aufgeteilt werden. So stellt sogar das mögliche Scheitern eines Teilprojektes keine große Gefahr für das Gesamtunternehmen dar (vgl. [KrBS2007, 259 ff.]).

Durch die technische Abstraktion und die Konzentration auf die wesentlichen Funktionen ist es auch möglich geworden, dass selbst Mitarbeiter ohne oder mit geringen technischen Kenntnissen (z.B. Vertreter von Fachabteilungen), sich bei der Konzeption von architektonischen Veränderungen mit einbringen können. So kann in laufenden Projekten, ein Feedback auf unterschiedlichen Ebenen, wie den betroffenen Fachabteilungen, eingeholt werden(vgl. [KrBS2007, 260]).

Ein letzter Vorteil einer SOA ist die Risikoabschwächung. Werden die Hauptgründe für Probleme bei IT-Projekten herangezogen (siehe [KrBS2007, 261]), so kann sie teilweise dazu beitragen, diese Probleme zu lösen. Eine Service-Dokumentation kann u.a. dabei helfen, die jeweiligen Projektziele zu verdeutlichen. Serviceorientierung unterstützt außerdem die Einbeziehung von Fachabteilungen und hilft bei der Planung und dem Abschätzen von Ressourcen. Serviceorientierung kann zudem auf Projektmanagementebene eingesetzt werden. Dieses Architekturkonzept stellt eine gute Basis für die Integration von neuen Funktionen dar und bleibt dabei technologieunabhängig. Zudem kann durch eine SOA der Bedarf an erfahrenen Führungskräften reduziert werden (siehe auch [KrBS2007, 261 ff.]). Selbst fehlgeschlagene Projekte innerhalb einer solchen Softwarearchitektur können für das Unternehmen einen Vorteil darstellen, da die dazugehörigen, entwickelten Services weiterhin auch für zukünftige Projekte genutzt werden können (siehe oben).

3.3.2 Die Personalperspektive

Es muss beachtet werden, dass die Einführung einer SOA nicht nur dem Unternehmen im Ganzen Vorteile bringt, sondern auch das beteiligte Personal Vorteile aus dieser Architektur ziehen kann. Dabei sind die Vorteile die ein Mitarbeiter daraus ziehen kann, abhängig von der Position die er im Unternehmen bekleidet. Die betroffenen Personen können dabei aus dem oberen Management (CEO, CIO) oder aus den jeweiligen Fachabteilungen (Projektmanager, Entwickler) kommen. Die nachfolgende Tabelle 1 beschreibt die Vorteile und Herausforderungen einer SOA anhand unterschiedlicher Rollen, die in einem Unternehmen vorzufinden sind (vgl. [KrBS2007, 262 ff.]). Diese ausgewählten Rollen sind der Hauptgeschäftsführer (CEO), als Beispiel für ein Mitglied der oberen Managements, die Fachabteilungen sowie Architekten und Entwickler, als Beispiele für Personen die für die Softwareentwicklung zuständig bzw. davon betroffen sind.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Vorteile und Herausforderungen einer SOA aus der Personalperspektive

Quelle: in Anlehnung an [KrBS2007, 263 ff.]

3.4 Die Rolle von Portalen innerhalb einer SOA

Portale, insbesondere prozessorientierte Unternehmensportale, haben dieselbe zielgerichtete Ausrichtung wie eine SOA. Sie werden dazu genutzt, Anwen-dungen, Informationen und Dienste verschiedener Unternehmensbereiche und Geschäftspartner (wie Kunden, Lieferanten) innerhalb eines Prozesses zu kombinieren und zu integrieren (vgl. [GrKo2005, 341]). Die grundlegende Idee einer SOA, verschiedene Komponenten in Form von Services kombinieren zu können, spiegelt sich bei Portalen dabei in der Möglichkeit wieder, unterschiedliche Portalkomponenten (Portlets, Webparts, Web Services) miteinander zu verknüpfen (vgl. [GrKo2005, 341]) oder aber unterschiedliche Services innerhalb einer Portalkomponente zu koppeln. Portale können somit als Anwendungs-Frontends innerhalb einer SOA gesehen werden, die von den technischen Grundlagen abstrahieren und die Vorteile dieser Architektur ausschöpfen.

4 Web 2.0

Kein Begriff prägte das Internet in den letzten Jahren so sehr, wie der des Web 2.0. Immer wieder wurden neue Unternehmen oder Geschäftskonzepte im Internet mit dem Begriff Web 2.0 in Verbindung gebracht. Doch warum manche Plattformen plötzlich „Web 2.0 waren“ und was sich genau hinter diesem Begriff verbirgt, konnte kaum jemand näher spezifizieren.

Das folgende Kapitel wird zunächst den Begriff Web 2.0 anhand seiner Grundprinzipien definieren und erklären. Daraufhin folgt die Beschreibung der Entwicklung vom Web 1.0 zum Web 2.0. Im weiteren Verlauf werden allgemeine Technologien und Anwendungen des Web 2.0 vorgestellt, die dann zum Ende des Kapitels, wiederum an Praxisbeispielen Anwendung finden.

Das Ziel dieses Kapitel ist eine Einführung in das Thema Web 2.0. Dabei steht vor allem das Verständnis der veränderten Vorstellung vom Internet, auf Basis der Grundprinzipien des Web 2.0, im Vordergrund. Web 2.0 wird auch als Oberbegriff für unterschiedliche, neue Konzepte und Technologien angesehen (vgl. [Frie2008, 19 ff.]). Von zentraler Bedeutung ist daher auch das Verständnis der im Web 2.0 eingesetzten Technologien und Anwendungstypen.

4.1 Die Grundprinzipien des Web 2.0

Web 2.0 steht nicht für eine bestimmte Technologie, sondern vielmehr für ein neues Verständnis des Internets nach dem Platzen der Dotcom-Blase^[23] 2001 (vgl. [Frie2008, 25]). Prägend für die Bedeutung des Ausdrucks Web 2.0 war ein Artikel von Tim O’Reilly im Jahr 2005 [Orei2005]. Darin werden sieben Grundprinzipien beschrieben, die stellvertretend für das neue Netzverständnis stehen: Das Web als Plattform, Kollektive Intelligenz, datengetriebene Plattformen, Perpetual Beta, Lightweight Programming Models, Geräteunabhängigkeit sowie Rich User Experiences (vgl. [Orei2005; KoHä2007, 6 ff.; Alby2007, 15 ff.]). Diese Prinzipien beschreiben das Internet in der Form, wie es heute genutzt wird.

Das Prinzip, das Web als Plattform zu nutzen, war längst in Zeiten des Web 1.0 eine Vision, die umgesetzt werden sollte (vgl. [Alby2007, 125]). Diese Umsetzung fand jedoch erst im Web 2.0 statt. Das Internet dient mittlerweile als Plattform für unterschiedliche Dienste, die jeder Nutzer weltweit abrufen kann. Das heißt, es lässt sich eine Abkehr von reinen Desktopapplikationen hin zu Anwendungen, die auf dem Internet beruhen, erkennen. Dabei spielt vor allem die steigende Anzahl von Nutzern des Internets und der jeweiligen Dienste eine herausragende Rolle, da dadurch Informationen im großen Umfang gesammelt und ausgetauscht werden können (vgl. [Orei2005; KoHä2007, 6 ff.; Alby2007, 125 ff.]).

Eine weitere Besonderheit stellt die Nutzung einer kollektiven Intelligenz dar. Die Inhalte des Internets werden nicht mehr nur durch ein paar spezialisierte Redakteure erstellt. Vielmehr zielen Unternehmen, genauer gesagt die Betreiber von Onlinediensten und Webseiten, direkt auf die Partizipationsmöglichkeiten jedes einzelnen Internetnutzers. Auf der einen Seite sind hier die erfolgreichen Unternehmen der Dotcom-Ära, wie Amazon^[24] oder eBay^[25] zu nennen. Diese grenzen sich einerseits dadurch von anderen weniger erfolgreichen Marktteilnehmern ab, indem sie den Kunden die Möglichkeit geben, erworbene Produkte zu bewerten und folglich die Suche nach Produkten von der Beliebtheit bei den Kunden abhängig machen (siehe Amazon, vgl. [Orei2005]). Andererseits nutzt eBay bspw. die Verflechtung der einzelnen Internetnutzer untereinander aus, um diesen geschäftliche Transaktionen untereinander zu ermöglichen, anstatt, wie es früher der Fall war, einigen großen Firmen den Vertrieb von Waren zu überlassen. Auf der anderen Seite entstanden Webseiten wie Flickr oder Wikipedia, die direkt auf die Partizipation der einzelnen Internetnutzer zielen. Hierbei haben die Nutzer die Pflicht, die jeweiligen Inhalte einzustellen und diese anderen Anwendern zur Verfügung zu stellen (User-generated Content, vgl. [KoHä2007, 7]). Ebenfalls in das Umfeld der kollektiven Intelligenz fällt das sog. „Tagging“. Beim Tagging werden unterschiedliche Informationen, aber auch Medien, wie bei den Multi-Media-Portalen Flickr oder YouTube, mit „Tags“ versehen. Ein „Tag“ (engl. Für Etikett) ist ein Schlagwort, mit dem sich Objekte, zur besseren Beschreibung, versehen lassen. Dadurch lassen sich Objekte besser auffinden und nach Themen sortieren (vgl. [Frie2008, 38]). Ein Bild der Freiheitsstatue in New York könnte bei Flickr bspw. mit folgenden Tags versehen sein: New York, USA, Freiheitsstatue, Miss Liberty, Manhattan, Statue of Liberty usw..

Datengetriebene Plattformen stellen eine Sammlung von systematisierten Informationen dar, die nur unter großen finanziellen Aufwand zusammen zu tragen sind. Dies können bspw. geographische, bibliographische, Kunden- oder Produktdaten sein (siehe Google Maps als Anbieter von Kartenmaterial). Das beim Sammeln dieser Daten auch immer größere Barrieren des Datenschutzes und der Privatsphäre fallen, zeigt sich an Beispielen von sog. sozialen Netzwerken (siehe Xing oder StudiVZ^[26] ), bei denen die Nutzer freiwillig große Mengen an personenbezogenen Daten freigeben. Der Grundgedanke der datengetriebenen Platt-formen sieht vor, die gesammelten Daten anderen Marktteilnehmern als Leistung zur Verfügung zu stellen (vgl. [KoHä2007, 7; Orei2005]).

[...]

---

^[1] Siehe: http://www.flickr.com/ - Abruf am 2008-05-23

^[2] Siehe: http://www.youtube.com/ - Abruf am 2008-05-23

^[3] Siehe: http://maps.google.de/ - Abruf am 2008-05-23

^[4] Siehe: http://www.studivz.net/ - Abruf am 2008-05-23

^[5] Siehe: http://www.sport1.de – Abruf am 2008-05-23

^[6] Siehe: http://www.bild.de/ - Abruf am 2008-05-23

^[7] Siehe: http://www.t-online.de/ - Abruf am 2008-05-23

^[8] Siehe: http://www.web.de/ - Abruf am 2008-05-23

^[9] Siehe: http://www.bundesliga.de/ - Abruf am 2008-05-23

^[10] Siehe: http://www.sport1.de/ - Abruf am 2008-05-23

^[11] Für genauere Definitionen der unterschiedlichen Portaltypen siehe [VlKG2005, 13]

^[12] SSO beschreibt einen Mechanismus, der nur eine einmalige Benutzeranmeldung an einem System erfordert und danach den Zugriff auf sämtliche Anwendungen ermöglicht, für die ohne SSO jeweils eine separate Anmeldung nötig gewesen wäre [VlKG2005, 31].

^[13] Data Warehouses sind auf die Verwaltung, Analyse und Darstellung von komplexen Daten ausgerichtete Datenbanken, bei der die Beziehungen der beinhalteten Daten im Gegensatz zu einer operativen Daten nicht explizit vorgegeben sind [StHa2002, 402; oV2000, 671 ff.].

^[14] Als Servlets werden serverseitige Java-Anwendungen bezeichnet. Weitere Informationen unter: http://java.sun.com/products/servlet/index.jsp - Abruf am 2008-05-23

^[15] Die API steht unter http://jcp.org/aboutJava/communityprocess/final/jsr168/ zum freien Down-load bereit

^[16] Siehe: http://labs.jboss.com/jbossportal/download/index.html - Abruf am 2008-05-23

^[17] Siehe: http://portals.apache.org/jetspeed-2/ und [TKLM2003, 225 ff.] – Abruf am 2008-05-23

^[18] Einen Vergleich der Portlet API 1.0 und der WebSphere Portal V5.0 Portlet API findet sich unter: http://www.ibm.com/developerworks/websphere/library/techarticles/0312_hepper/hepper.html - Abruf am 2008-05-23

^[19] Siehe: http://www.jcp.org/en/jsr/detail?id=286 – Abruf am 2008-05-23

^[20] Siehe: http://office.microsoft.com/de-de/sharepointserver/HA101656531031.aspx - Abruf am 2008-05-23

^[21] Als Clients werden, im SOA-Umfeld, die Nutzer eines Services bezeichnet. Dies können wiederum andere Services oder Anwendungs-Frontends sein (vgl. [KrBS2007, 30, 79]).

^[22] Ein Stub ist ein lokales Objekt, welches die von der Kommunikation mit anderen Komponenten abstrahiert (vgl. [Röwe2002, 134 ff.]).

^[23] Als Dotcom-Blase wird die finanzielle Übersättigung des Marktes der Dotcom-Unternehmen bezeichnet, die aufgrund von nicht konkurrenzfähigen Geschäftsmodellen, zu einer Krise der Internetwirtschaft führten (vgl. [Frie2008, 25]).

^[24] Siehe: http://www.amazon.de/ - Abruf am 2008-05-23

^[25] Siehe: http://www.ebay.de/ - Abruf am 2008-05-23

^[26] Siehe: http://www.spiegel.de/netzwelt/web/0,1518,523906,00.html, http://www.spiegel.de/netzwelt/web/0,1518,448340,00.html und http://www.welt.de/webwelt/article1464027/StudiVZ_lenkt_nach_WELT-ONLINE-Bericht_ein.html - Abruf am 2008-05-23