Jewiki unterstützen. Jewiki, die größte Online-Enzyklopädie zum Judentum.
Helfen Sie Jewiki mit einer kleinen oder auch größeren Spende. Einmalig oder regelmäßig, damit die Zukunft von Jewiki gesichert bleibt ... Vielen Dank für Ihr Engagement! (→ Spendenkonten) |
How to read Jewiki in your desired language · Comment lire Jewiki dans votre langue préférée · Cómo leer Jewiki en su idioma preferido · בשפה הרצויה Jewiki כיצד לקרוא · Как читать Jewiki на предпочитаемом вами языке · كيف تقرأ Jewiki باللغة التي تريدها · Como ler o Jewiki na sua língua preferida |
Portal (Informatik)
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
„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.“
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.“
Überblick
Unternehmensportale lassen sich in zwei Kategorien einordnen:
- Integrationsportale dienen dem einheitlichen Zugriff auf verschiedene Anwendungen. Bei einem Integrationsportal steht das Bereitstellen von applikationsübergreifenden Leistungen im Vordergrund. Beispiele sind Oracle WebCenter, Websphere Portal und SAP NetWeaver Portal.
- Wissensmanagement- oder Zusammenarbeits-Portale dienen der Verteilung und dem Austausch von Informationen zwischen den Benutzern.[3] Beispiele sind Oracle WebCenter, Microsoft Sharepoint Portal oder Intrexx.
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 Web Services 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:
- Hypertext Markup Language (HTML) / Extensible Hypertext Markup Language (XHTML)
- Cascading Style Sheets (CSS)
Integration
Standards für die Integration von vorhandenen Systemen sind:
Portaltechnik
Für die Portaltechnik relevante Spezifikationen sind:
- Portlets (Java Specification Request (JSR) 168 bzw. 286)
- Web Services for Remote Portlets (OASIS-Standard WSRP)
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:
- WebDAV (Web-based Distributed Authoring and Versioning)
- Content Repository for Java Technology API (JSR 170 / JSR 283)
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, welches es Unternehmen erlaubt, ein Portal aufzubauen. Dazu bietet eine solche Software Funktionen wie:
- Erstellung von Frontends mit Portlets, (proprietäre Portlet-ähnliche APIs: iViews, Gadgets, I-Lets u. a.)
- Integratoren für vorhandene Systeme
- Personalisierung
- Suchfunktionen
- Listen aller Art
- Dokumentenmanagement
- Content-Management
- Enterprise-Content-Management
- Business Process Management
- Single Sign-on
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 Portalssoftwaresysteme sind zum Beispiel EXo Platform, Intrexx, Apache Portals und Apache Cocoon der Apache Software Foundation. Eine neuere Software ist OpenSAGA.
Siehe auch
- Intranetportal
- PADEM (Portal-Analyse-und-Design-Methode)
- Videoportal
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.
- Sue Lee, Peter Gentsch: Praxishandbuch Portalmanagement. Profitable Strategien für Internetportale. Gabler, 2004, ISBN 3-409-12454-3.
- Joannis Vlachakis, Thorsten Gurzki, Anja Kirchhof: Marktübersicht Portalsoftware 2005. Fraunhofer IRB Verlag, Stuttgart, 2005, ISBN 3-8167-6752-4.
Quellen
- ↑ Anja Kirchhof, Thorsten Gurzki, Henning Hinderer, Joannis Vlachakis: „Was ist ein Portal?“ – Definition und Einsatz von Unternehmensportalen (PDF; 214 KB)
- ↑ Puschmann:Prozessportale – Architektur zur Vernetzung mit Kunden und Lieferanten
- ↑ Patrick Höfer: Unternehmensportale – eine kurze Übersicht zur Klassifizierung, Ausprägung und Funktion von Unternehmensportalen (PDF; 137 kB)
- ↑ Magic Quadrant for Horizontal Portals
Dieser Artikel basiert ursprünglich auf dem Artikel Portal (Informatik) aus der freien Enzyklopädie Wikipedia und steht unter der Doppellizenz GNU-Lizenz für freie Dokumentation und Creative Commons CC-BY-SA 3.0 Unported. In der Wikipedia ist eine Liste der ursprünglichen Wikipedia-Autoren verfügbar. |