Portal (Informatik)

aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von Enterprise Portal)

Der Ausdruck Portal (lateinisch porta „Pforte“) bezeichnet in der Informatik ein Anwendungssystem, das sich durch die Integration von Anwendungen, Prozessen und Diensten auszeichnet. Ein Portal stellt seinem Benutzer verschiedene Funktionen zur Verfügung, wie beispielsweise Personalisierung, Navigation und Benutzerverwaltung. Außerdem koordiniert es die Suche und die Präsentation von Informationen und soll die Sicherheit gewährleisten.

Im allgemeinen Sprachgebrauch wird darunter der Spezialfall Webportal verstanden, der die Web-Anwendungen beschreibt, welche die Internetdienstanbieter, Webverzeichnisse, Webbrowser-Hersteller und Suchmaschinenbetreiber in den späten 1990er Jahren als Einstiegsseiten für die Benutzer des World Wide Webs anboten (z. B. Yahoo, AOL, Lycos).

Definition

Unternehmensportale im betrieblichen Umfeld nach Thorsten Riemke-Gurzki

„Ein Portal ist […] eine Applikation, die […] einen zentralen Zugriff auf personalisierte Inhalte sowie bedarfsgerecht auf Prozesse bereitstellt. Charakterisierend für Portale ist die Verknüpfung und der Datenaustausch zwischen heterogenen Anwendungen über eine Portalplattform. Eine manuelle Anmeldung an den in das Portal integrierten Anwendungen ist durch Single-Sign-On nicht mehr notwendig, es gibt einen zentralen Zugriff über eine homogene Benutzungsoberfläche. Portale bieten die Möglichkeit, Prozesse und Zusammenarbeit innerhalb heterogener Gruppen zu unterstützen.“

– Anja Kirchhof, Thorsten Gurzki, Henning Hinderer, Joannis Vlachakis: „Was ist ein Portal?“ – Definition und Einsatz von Unternehmensportalen[1]

Kurz: „Das ideale Portal eröffnet einen gemeinsamen, personalisierten Zugang zu Daten, Expertisen und Anwendungen“ (Dataquest).

Prozessportale sind als höherentwickelte, d. h. zweite Generation von Portalen zu verstehen. Sie können:

„als web-basierte, personalisierbare und integrierte Zugangssysteme zu internen und externen Applikationen definiert [werden], die der Unterstützung von Kunden-, Lieferanten und Mitarbeiterprozessen dienen und welche die grafische bzw. audiovisuelle Frontend-Integration (auch über verschiedene Portale hinweg) umsetzen. Dadurch verschaffen sie internen und externen Benutzern einen rollen-basierten, prozessorientierten Zugang zu einem umfassenden Set an aufeinander abgestimmten Mehrwertdiensten. Sie ermöglichen dies durch die Bereitstellung übergreifender Dienste wie Sicherheit, Personalisierung etc. Der Nutzen für den Portalbenutzer ist die Backend-Integration dieser Services.“

– Puschmann: Prozessportale – Architektur zur Vernetzung mit Kunden und Lieferanten[2]
Architektur von Prozessportalen

Überblick

Unternehmensportale lassen sich in zwei Kategorien einordnen:

Portale ermöglichen eine Entkopplung unternehmensinterner Kernprozesse von zielgruppenspezifischen internen und externen Prozessen. Beispielsweise lassen sich auf Basis eines einzigen internen Vertriebsprozesses verschiedene Kundengruppen individuell über eigene Portalprozesse abwickeln. Im Bereich Mitarbeiterportale wird diese Form der zielgruppenspezifischen Bereitstellung für die aufgabengerechte Prozessbereitstellung genutzt.

Die einzelnen Anwendungen werden oft in Unterfenstern, den sogenannten Portlets, organisiert. In den Portlets werden Inhalte aus unterschiedlichen Quellen auf einer Portalseite zusammengefasst. Die einzelnen Portlets können vom Benutzer teilweise personalisiert werden. Die Portlets können minimiert oder entfernt werden und bieten oft auch eigene Hilfe- und Konfigurationsmenüs.

Eine weitere Funktionalität ist die Integration von Webservices. Da diese ursprünglich für die Kommunikation zwischen Anwendungen geschrieben wurden, ist die Präsentation nicht trivial, da beispielsweise Eingabefelder zu den benötigten Werten nur mit internen Variablennamen versehen sind. Neuere Entwicklungen wie GUIDD versuchen, diesen Missstand zu beheben.

Vorteile

Der Vorteil der Portaltechnik liegt darin, dass eine grundlegende Infrastruktur zur Verfügung gestellt wird, die einen Teil der Standardfunktionalität von Webanwendungen bereithält. Je nach Hersteller ist diese Basisfunktionalität mehr oder weniger ausgeprägt. Bei den großen Anbietern umfasst die Standardfunktionalität das Zusammenarbeits-Management, Personalisierung sowie Dokumentverwaltung und Wissensmanagement. Weiterführende Funktionalitäten reichen bis hin zu Expertensystemen auf Basis eines Portals.

Ein zentraler Aspekt des Portals ist mittlerweile die Integration von Applikationen in einem gemeinsamen Portal. Dies bietet mehrere Vorteile:

  • Einheitliche Benutzeroberfläche, dadurch erhöhte Akzeptanz beim Anwender und reduzierter Schulungsaufwand.
  • Gemeinsame Datenbasis, dadurch Verknüpfung von Informationen über Applikationsgrenzen hinweg.
  • Prozessplattform auf Basis einheitlicher Daten, dadurch transparente und effizientere Prozesse.
  • Einmalige Anmeldung („Single-Sign-On“), also das portalweite Weiterreichen einer erfolgten Anmeldung des Benutzers; damit können Mehrfachanmeldungen und Mehrfachpasswörter entfallen.

Diese Vorteile kommen vor allem dann zum Tragen, wenn bei der Portalumsetzung konsequent die Sicht auf Ebene der Geschäftsprozesse gehalten wird. Daher ist ein Enterprise-Portal ein Baustein des Konzepts der Serviceorientierten Architektur (SOA).

Nachteile

Nachteile der Portaltechnik kommen vor allem dann zu Tage, wenn es darum geht, bestehende Anwendungen in ein Portal zu transferieren. Die Anzeige und Bearbeitung reiner Daten kann zwar meist über Webservices und Integrationsumgebungen wie Oracle Fusion Middleware, Microsoft BizTalk, SAP XI oder IBM WebSphere MQ vorgenommen werden, jedoch steigt dadurch auch die Komplexität des Gesamtsystems.

Kritische Erfolgsfaktoren sind dann die Konsistenz von Daten zwischen Portal und originärer Anwendung und auch die Implementation komplexer Prozesse im Portal über Anwendungsgrenzen hinweg. Es stellt sich auch die Frage, wann das Portal und wann die originäre Anwendung zu nutzen ist und wie sich dies in die Prozesshierarchie einfügt. Diese Aufgaben können beliebig komplex sowie kosten- und zeitintensiv werden.

Zunehmend achten Anwendungsentwickler auf die Nutzbarkeit der Software in einem Portalkontext, was die angesprochenen Nachteile teilweise zu vermeiden hilft.

Nachteile können auch entstehen, wenn das Portal zu einer einseitigen Festlegung auf eine gemeinsame Programmiersprache auch für die bestehenden, zu integrierenden Anwendungen führt. Spezialanwendungen, die in einer anderen Programmiersprache geschrieben wurden und nur in dieser verfügbar sind, können dann nicht mehr integriert werden. Stattdessen sollte man sich daher bei Portalen lediglich auf gemeinsame, standardisierte Schnittstellen einigen.

Architektur

Die generelle Architektur eines Portals sieht einen Server vor, der die Anfragen der Anwender entgegennimmt und an die „Portlet Engine“ weiterleitet. Diese verwaltet den Lebenszyklus der Portlets und gibt die Aktions- und Renderanfragen an die einzelnen Portlets weiter, die in der nachgefragten Seite angezeigt werden sollen. Die Portlets suchen sich aus den dazugehörigen Datenquellen ihren Inhalt zusammen. Hierbei ist festzustellen, dass Datenquellen klassische Datenbanken sein können, aber auch „Web Services“ und Anwendungen können hier als Quellen eingesetzt werden. Die Portlets sind nicht darauf beschränkt, sich aus einer Datenquelle zu bedienen, sondern können ihren Inhalt aus mehreren Datentöpfen zusammenstellen.

Kommunikation am Beispiel JSR-168- bzw. JSR-286-basierender Portale

Intern läuft die Kommunikation zwischen der „Portlet Engine“ und den Portlets wie folgt. Auf eine Anfrage, die dem Portal gestellt wird, identifiziert der Portlet-Container die benötigten Portlets. Ist die Anfrage eine Aktionsanfrage, so wird auf dem entsprechenden Portlet die Methode performAction() ausgeführt. Sobald diese beendet ist, werden die Rendermethoden doView(), doEdit() oder doHelp() der anzuzeigenden Portlets ausgeführt. Welche dieser Methoden ausgeführt wird, bestimmt der Zustand des Portlets, welcher vom Container verwaltet wird. Diese Zustände können um anwendungs- und portalspezifische Zustände erweitert werden. Innerhalb der Bearbeitung der Rendermethoden können nun Beans oder andere verarbeitende Klassen oder Funktionen angesprochen werden. Das Rendering kann zudem von JSPs unterstützt werden, welche über einen Dispatcher aufgerufen werden.

Standards

Präsentation und Layout

Als Standards für das Design eines webbasierten Portals gelten im Prinzip die gleichen Standards wie für eine beliebige Webseite:

Integration

Standards für die Integration von vorhandenen Systemen sind:

Portaltechnik

Für die Portaltechnik relevante Spezifikationen sind:

Portalinhalt

Zur Speicherung von Artikeln und deren Kurzbeschreibung (Web-Feed) bilden mehrere XML-basierte Dateiformate eine Familie von Standards:

Content-Management

Standards für die programmgestützte Verwaltung von Inhalten (Content-Management) sind:

Portalsoftware

Bei einem Portal steht das Bereitstellen von applikationsübergreifenden Leistungen und somit der Integrationsaspekt im Vordergrund. Daher ist es naheliegend, beim Aufbau eines Portals entweder auf eine Infrastruktur zurückzugreifen, die Enterprise Application Integration (EAI) zum Bestandteil hat, oder eine Portal-Standard-Software zu verwenden, die sich der EAI bedient.

Viele Portallösungen sind in Java programmiert, um eine größtmögliche Systemunabhängigkeit zu erreichen.

Ein Portal kann, braucht aber nicht auf Web-Protokollen zu basieren.

Portal-Standard-Software

Unter Portal-Standard-Software, häufig auch als Enterprise Portal bezeichnet, wird im Allgemeinen eine Software verstanden, welche es Unternehmen erlaubt, ein Portal aufzubauen. Dazu bietet eine solche Software Funktionen wie:

Hersteller

Nach der Gartner Group lässt sich der (kommerzielle) Portalsoftware-Markt abhängig von Marktpräsenz („Ability of Execute“, deutsch etwa „Fähigkeit zur Durchführung“) und Abdeckungsgrad („Completeness of Vision“, deutsch „Vollständigkeit der Vision“) in vier Quadranten einteilen:

Marktpräsenz

„Challengers“ („Herausforderer“)

Hersteller mit hoher Marktpräsenz, aber mit unzureichendem Abdeckungsgrad ihres Portalsystems.

„Leaders“ („Marktführer“)

Hersteller mit hoher Marktpräsenz und hochgradig integrierten und skalierbaren Produkten.

„Niche Players“ („Nischenakteure“)

Nischenhersteller mit der Konzentration auf kleinere Märkte und Spezialisierung auf einige Funktions- oder Einsatzgebiete.

„Visionaries“ („Visionäre“)

Hersteller ohne große Marktpräsenz, aber mit großen Visionen.

Markteinteilung nach Gartner (2011[4]) Abdeckungsgrad

Weitere bekannte Portalsoftwaresysteme sind zum Beispiel Intrexx, Apache Portals und Apache Cocoon der Apache Software Foundation. Eine neuere Software ist OpenSAGA.

Siehe auch

Literatur

  • Thorsten Riemke-Gurzki: Unternehmensportale und Intranet: konzipieren, realisieren, betreiben BoD Norderstedt, 2014, ISBN 978-3-7322-9241-7
  • Thomas Puschmann: Prozessportale – Architektur zur Vernetzung mit Kunden und Lieferanten. Springer Verlag, Berlin etc., 2004, ISBN 978-3-540-20715-3.
  • Martina Großmann, Holger Koschek: Unternehmensportale. Springer Verlag, Berlin Heidelberg, 2005, ISBN 3-540-22287-1.
  • Joannis Vlachakis, Thorsten Gurzki, Anja Kirchhof: Marktübersicht Portalsoftware 2005. Fraunhofer IRB Verlag, Stuttgart, 2005, ISBN 3-8167-6752-4.

Einzelnachweise

  1. ↑ Anja Kirchhof, Thorsten Gurzki, Henning Hinderer, Joannis Vlachakis: „Was ist ein Portal?“ – Definition und Einsatz von Unternehmensportalen. Whitepaper des Fraunhofer Instituts Arbeitswirtschaft und Organisation, Juni 2004 (PDF; 214 KB) (Memento vom 5. Februar 2013 im Internet Archive).
  2. ↑ Thomas Puschmann: Prozessportale: Architektur zur Vernetzung mit Kunden und Lieferanten. Springer Berlin/Heidelberg, Berlin 2004.
  3. ↑ Patrick Höfer: Unternehmensportale – eine kurze Übersicht zur Klassifizierung, Ausprägung und Funktion von Unternehmensportalen (PDF; 137 kB)
  4. ↑ Magic Quadrant for Horizontal Portals
Abgerufen von „https://de.wikiup.org/index.php?title=Portal_(Informatik)&oldid=223635977“