Inhaltsverzeichnis I

Inhaltsverzeichnis   

Abbildungsverzeichnis   IV

Tabellenverzeichnis   V

Abk  ürzungsverzeichnis.  VI

1  Einleitung  1

1.1  Motivation.  1

1.2  Zielsetzung und Aufbau der Arbeit  2

2  Portale  5

2.1  Definition.  5

2.1.1  Portal allgemein  5

2.1.1.1  Kriterium Fokus  6

2.1.1.2  Kriterium Nutzerkreis  7

2.1.2  Unternehmensportale  7

2.1.2.1  Kriterium Zielgruppen.  8

2.1.2.2  Kriterium Anwendungsschwerpunkte  9

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

Unternehmensportalen   10

2.2  Portlets  11

2.2.1  Definition  11

2.2.2  Abgrenzung zu Web Services und Webparts  13

2.3  Architekturmodelle und Referenzarchitekturen  14

2.3.1  Fachliches Architekturmodell.  14

2.3.2  Technische Referenzarchitektur  16

2.3.3  PADEM Referenzarchitektur für Portalsoftware  17

3  Serviceorientierte Architekturen.  19

3.1  Definition.  19

3.2  Elemente einer SOA  21

3.2.1  Services.  21

3.2.2  Anwendungs-Frontend  24

3.2.3  Service-Repository  24

3.2.4  (Enterprise) Service-Bus  25

3.3  Gründe für den Einsatz einer SOA  25

3.3.1  Die Unternehmensperspektive.  26

3.3.2  Die Personalperspektive  29

3.4  Die Rolle von Portalen innerhalb einer SOA  30

Inhaltsverzeichnis II

4  Web 2.0  31

4.1  Die Grundprinzipien des Web 2.0.  31

4.2  Die Entwicklung vom Web 1.0 zum Web 2.0  35

4.3  Ausgewählte Technologien und Anwendungen des Web 2.0  36

4.3.1  Weblogs  37

4.3.2  Wikis  38

4.3.3  AJAX  39

4.4  Etablierte Web 2.0-Anwendungen.  41

4.4.1  Wikipedia  41

4.4.2  YouTube  41

4.4.3  Xing  42

5  Mashups.  43

5.1  Definition.  43

5.2  Handlungsfelder von Mashups im Web 2.0  46

5.3  Beispiele von Mashup-APIs und Mashups  48

5.3.1  Mashup-APIs  49

5.3.2  Mashups  50

5.4  REST-Architektur  51

5.4.1  Grundlagen  51

5.4.2  Verwandte Konzepte und Anwendungsgebiete  55

5.5  Technische Perspektive von Mashups  57

5.5.1  Grundlagen der Erstellung von Mashups  58

5.5.2  Integration und Kombination von Diensten und Datenquellen zu  

einem  Mashup  59

5.5.2.1  Integration von Diensten durch Widgets.  59

5.5.2.2  Integration von Datenquellen durch Feeds.  61

5.5.2.3  Integration von Datenquellen und Diensten durch  

Mashup  -APIs  64

5.5.3  Kommunikation zwischen den Komponenten eines Mashups  67

5.5.4  Software zum Erstellen von Mashups im Web 2.0.  69

5.5.5  Technologien im Umfeld von Mashups  71

5.6  Vor- und Nachteile von Mashups  72

5.7  Abgrenzung von Mashups zu Composite Applications, Web Services und  

Portlets   75

5.7.1  Composite Apps, Situational Apps und SAP xApps  75

5.7.2  Web Services.  80

5.7.3  Portlets und Portale  81

5.8  „Software as a Service“ und ähnliche Paradigmen  82

5.8.1  Application Service Providing  83

Inhaltsverzeichnis III

5.8.2  „Software as a Service“  84

6  (Business) Mashups in Unternehmensportalen  88

6.1  Enterprise 2.0 - Web 2.0 in Unternehmen  88

6.1.1  Definition  88

6.1.2  Business Mashups  90

6.2  Handlungsfelder und Potenziale von Business Mashups.  91

6.2.1  Anbieterperspektive.  91

6.2.2  Nutzerperspektive  93

6.3  Determinanten für die Nutzung von Business Mashups  96

6.3.1  Weborientierte Architekturen  96

6.3.2  Business Mashups als Integrationswerkzeug.  99

6.3.2.1  Integrationsmodell  99

6.3.2.2  Integration durch Mashups.  101

6.3.3  Unternehmensportale als Trägersystem.  104

6.3.3.1  Personelle Voraussetzungen  105

6.3.3.2  Allgemeine technische Vorraussetzungen  107

6.4  Modell zur Integration und Nutzung von Mashups in einem  

Unternehmensportal.   108

6.4.1  Grundlagen  109

6.4.2  Mashups im Umfeld unterschiedlicher Portalmodelle  111

6.4.2.1  Fachliches Architekturmodell  111

6.4.2.2  Technische Referenzarchitektur.  114

6.4.2.3  PADEM Referenzarchitektur für Portalsoftware.  117

6.4.3  Aggregation der Portalmodelle und des Mashup Ecosystems  120

6.5  Marktübersicht von Business Mashup-Software.  125

6.5.1  BEA Aqua Logic Ensemble und WebLogic Portal  126

6.5.2  Serena Business Mashup-Lösungen.  126

6.5.3  IBM Mashup Starter Kit / Lotus Mashups  127

6.5.4  Microsoft Popfly und Microsoft SharePoint Server  128

6.5.5  SAP Netweaver-Plattform  129

6.6  Kritische Würdigung der Ergebnisse  130

7  Fazit, Prognose und Ausblick  134

Anhang A:  Codebeispiel Kapitel 5.5.1.2.  137

Literaturverzeichnis   139

Abbildungsverzeichnis   

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 V

Tabellenverzeichnis

Tabelle 1: Vorteile und Herausforderungen einer SOA aus der

Personalperspektive ..................................................................30 Tabelle 2: Die Grundprinzipien des Web 2.0 ................................................34 Tabelle 3: Verschiedene Anwendungstypen des Web 2.0 und ihre Funktionen...37 Tabelle 4: Kategorien von Internetdiensten und ihre Mashup-APIs ..................50 Tabelle 5: ausgewählte Technologien im Umfeld von Mashups........................72 Tabelle 6: Vor- und Nachteile von Mashups .................................................74 Tabelle 7: Vergleich der traditionellen Anwendungsentwicklung mit Composite Apps, Situational Apps und Mashups............................................79 Tabelle 8: Vor- und Nachteile von ASP........................................................83 Tabelle 9: Integrationspotenziale von Mashups im Rahmen des

Integrationsmodells ................................................................ 104 Tabelle 10: Auswahl an Informationen, die in einem Service Repository verfügbar sein können ......................................................................... 122 Tabelle 11: Die Komponenten einer SOA und ihr Pendant in einer WOA ......... 125 Tabelle 12: Chancen und Risiken durch Business Mashups........................... 132

Abkürzungsverzeichnis VI

Abkürzungsverzeichnis

ADSL ....... Asymmetric Digital Subscriber Line AJAX ....... Asynchronous Java and XML API.......... Application Programming Interface ASP ......... Application Service Providing B2B ......... Business to Business B2C ......... Business to Consumer B2E ......... Business to Employee BI ........... Business Intelligence Blog ........ Weblog

BPEL........ Business Process Execution Language CEO......... Chief Executive Officer CIO ......... Chief Information Officer CMS ........ Content Management System CRM ........ Customer Relationship Management CSS......... Cascading Style Sheets DOM........ Document Object Model EAI.......... Enterprise Application Integration ERP ......... Enterprise Resource Planning GIF ......... Graphics Interchange Format GME ........ Google Mashup Editor GUI ......... Graphical User Interface HTML....... Hypertext Markup Language HTTP ....... Hypertext Transfer Protocol IAO ......... Institut Arbeitswirtschaft und Organisation IDL.......... Interface Definition Language IT ........... Informationstechnologie J2EE ........ Java Platform, Enterprise Edition JCP.......... Java Community Process JSON ....... JavaScript Object Notation JSR ......... Java Specification Request LPM ......... Lightweight Programming Models PADEM..... Portal Analyse und Design Methode PDF ......... Portable Document Format PHP ......... PHP: Hypertext Preprocessor REST ....... REprensentational State Transfer RIA ......... Rich Internet Application

Abkürzungsverzeichnis VII

RPC ......... Remote Procedure Call

RSS......... Really Simple Syndication oder Rich Site Summary oder RDF Site Summary

SA........... Situational Applications SaaS ....... Software as a Service SLA ......... Service Level Agreement SOA ........ serviceorientierte Architektur SOAP ....... Simple Object Access Protocol SQL ......... Structured Query Language SSL ......... Secure Socket Layer SSO ........ Single Sign On TCO......... Total Cost of Ownership UDDI ....... Universal Description, Discovery and Integration UML......... Unified Modeling Language URI ......... Uniform Resource Identifier URL ......... Uniform Resource Locator W3C ........ World Wide Web Consortium WFMS ...... Workflow Management System WOA........ weborientierte Architektur WSDL ...... Web Services Description Language WSRP ...... Web Services for Remote Portles WWW ...... World Wide Web XHTML ..... Extensible Hypertext Markup Language XML......... Extensible Markup Language XML-RPC .. Extensible Markup Language Remote Procedure Call

Einleitung 1

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 ¹ ins Netz gestellt, private Videoaufnahmen der eigenen Tanzgruppe werden bei YouTube ² online bereitgestellt, der Lageplan des Kleingartenvereins wird mit Hilfe von Google Maps ³ abgebildet oder es werden über soziale Netzwerke wie das StudiVZ ⁴ 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

¹ Siehe: http://www.flickr.com/ - Abruf am 2008-05-23

² Siehe: http://www.youtube.com/ - Abruf am 2008-05-23

³ Siehe: http://maps.google.de/ - Abruf am 2008-05-23

⁴ Siehe: http://www.studivz.net/ - Abruf am 2008-05-23

Einleitung 2

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

Einleitung 3

Die folgende Arbeit ist grob in zwei Abschnitte unterteilt: Der erste Teil ist der Grundlagenteil, welcher in die Themengebiete (Unternehmens-)Portale, service-orientierte 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 Un-ternehmensportale 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 Begriffs 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

Einleitung 4

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

Portale 5

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

⁵ Siehe: http://www.sport1.de - Abruf am 2008-05-23

Portale 6

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 Unterneh-mensportale hinreichend definieren und kategorisieren lassen. Unternehmens-portale 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ächlicher Form präsentiert. Als horizontale Portale gelten u.a. Bild.de ⁶ , T-Online.de ⁷ oder Web.de ⁸ (vgl. [GrKo2005, 29; TKLM2003, 215 ff.]).

VERTIKALE PORTALE hingegen bieten ein tiefes Informationsangebot für spezielle 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 ⁹ , 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

⁶ Siehe: http://www.bild.de/ - Abruf am 2008-05-23

⁷ Siehe: http://www.t-online.de/ - Abruf am 2008-05-23

⁸ Siehe: http://www.web.de/ - Abruf am 2008-05-23

⁹ Siehe: http://www.bundesliga.de/ - Abruf am 2008-05-23

Portale 7

das Portal von Sport1.de ¹⁰ 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

¹⁰ Siehe: http://www.sport1.de/ - Abruf am 2008-05-23

Portale 8

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 letzteren Definition, die Prozessorientierung von Unternehmensportalen hervorgehoben wurde. Der prozessorientierte Ansatz von Unternehmensportalen unterscheidet eben diese von den bislang existierenden Unternehmenswebseiten und der Intranetanwendungen 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 Potenziale 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 ins-

Portale 9

besondere Beschaffungsprozesse ab. Endkundenportale integrieren wiederum Marketing-, Vertriebs- und Serviceprozesse im Hinblick auf Endkunden ¹¹ . 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 genannten 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

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

Portale 10

bieten diese Portale den Vorteil, über einen Single Sign-On-Mechanismus (SSO) ¹² , 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 Anwendungsschwerpunkte 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 Warehouses ¹³ 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

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

¹² 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 je-

weils eine separate Anmeldung nötig gewesen wäre [VlKG2005, 31].

¹³ Data Warehouses sind auf die Verwaltung, Analyse und Darstellung von komplexen Daten ausge-

richtete Datenbanken, bei der die Beziehungen der beinhalteten Daten im Gegensatz zu einer o-perativen Daten nicht explizit vorgegeben sind [StHa2002, 402; oV2000, 671 ff.].

Portale 11

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. [Ab-He2003]) 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

Portale 12

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 1: Erstellung einer Portalseite und ihren Portlets Quelle: [AbHe2003, 20]

Portlets besitzen einige Gemeinsamkeiten mit Servlets ¹⁴ . 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ügbaren Portlet API 1.0 ¹⁵ 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 ¹⁶ oder das Jetspeed ¹⁷ Portal, beides frei verfügbare Open-Source Produkte. Zusätzlich zur freien Portlet API 1.0 gibt es mittlerweile

¹⁴ Als Servlets werden serverseitige Java-Anwendungen bezeichnet. Weitere Informationen unter:

http://java.sun.com/products/servlet/index.jsp - Abruf am 2008-05-23

¹⁵ Die API steht unter http://jcp.org/aboutJava/communityprocess/final/jsr168/ zum freien Down-

load bereit

¹⁶ Siehe: http://labs.jboss.com/jbossportal/download/index.html - Abruf am 2008-05-23

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

Portale 13

proprietäre Portlet APIs, wie die WebSphere Portal V5.0 Portlet API ¹⁸ 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 ¹⁹ 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: Share-Point Portal Server 2007 ²⁰ ) 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 Javabasierten 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-tomachine interaction over a network. It has an interface described in a machineprocessable 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]

¹⁸ 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

¹⁹ Siehe: http://www.jcp.org/en/jsr/detail?id=286 - Abruf am 2008-05-23

²⁰ Siehe: http://office.microsoft.com/de-de/sharepointserver/HA101656531031.aspx - Abruf am

2008-05-23

Portale 14

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

Portale 15

[GrKo2005, 93]). Eine weitere Anforderung stellt die Personalisierbarkeit des Portals dar (siehe [GrKo2005, 94 ff.]). Dabei stehen u.a. eine hohe Benutzer-freundlichkeit 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 Rollenmanagement, 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).

Portale 16

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

Portale 17

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

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

Portale 18

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 Anbindungs-formen 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 4: PADEM Portalsoftware Referenzarchitektur 2.0

Serviceorientierte Architekturen 19

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

Serviceorientierte Architekturen 20

Beziehungen von Service-Nutzer, Service-Anbieter und Service-Verzeichnis un-tereinander.

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

Serviceorientierte Architekturen 21

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

Serviceorientierte Architekturen 22

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

Der SERVICE-VERTRAG beschreibt informell den Zweck, die Funktionalität, die Beschränkungen und die Nutzung des Services. Dazu kann ebenfalls eine formale 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ämtliche 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 ²¹ über SCHNITT-STELLEN bereitgestellt. Zwar werden die Schnittstellen im zuvor genannten

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

Serviceorientierte Architekturen 23

Service-Vertrag beschrieben, jedoch werden sie als Service-Stubs ²² 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 Datenbanken und enthält zudem die GESCHÄFTSLOGIK und die entsprechenden DA-TEN (vgl. [KrBS2007, 79]).

Abschließend bleibt zu erwähnen, dass ein Service eine Einheit mit einer speziellen 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.]).

²² Ein Stub ist ein lokales Objekt, welches die von der Kommunikation mit anderen Komponenten

abstrahiert (vgl. [Röwe2002, 134 ff.]).