Privacy Policy Cookie Policy Terms and Conditions Portal (Informatik) - Wikipedia

Portal (Informatik)

aus Wikipedia, der freien Enzyklopädie

Dieser Artikel beschäftigt sich nur mit dem Anwendungssystem der Informatik. Wenn sie auf das Portal Informatik gelangen wollen, dann bitte klicken Sie hier: Portal:Informatik

Der Ausdruck Portal (lat. porta, „Pforte“) bezeichnet in der Informatik ein Anwendungssystem, das durch folgende Eigenschaften gekennzeichnet ist:

Inhaltsverzeichnis

[Bearbeiten] 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.“ [1]

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

Bei einem Portal steht das Bereitstellen von applikationsübergreifenden Leistungen und somit der Integrationsaspekt und nicht die technische Implementierung im Vordergrund. Ein Portal kann – muss aber nicht – auf Webtechnologie basieren.

[Bearbeiten] Überblick

Die einzelnen Anwendungen werden oft in Unterfenstern, den so genannten 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 verfügen oft auch über 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.

[Bearbeiten] Vorteile

Die Vorteile der Portaltechnologie liegen darin, dass eine grundlegende Infrastruktur zur Verfügung gestellt wird, die einen Teil der Standardfunktionalität von Webanwendungen bereithalten. Je nach Hersteller ist diese Basisfunktionalität mehr oder weniger ausgeprägt. Bei den großen Anbietern reicht die „out of the Box“ Funktionalität von Collaboration Management über Personalisierung bis hin zu Document- und Knowledge Management Integration. Weiterführende Funktionalitäten reichen bis hin zu Expertensystemen auf Basis eines Portals. Kleine und Open Source Anbieter kommen meist (noch) nicht über Navigation und Benutzermanagement hinaus.

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

  • Einheitliche Benutzeroberfläche, dadurch erhöhte Akzeptanz beim Anwender und reduzierter Change Management/Schulungsaufwand.
  • Gemeinsame Datenbasis, dadurch Verknüpfung von Informationen über Appliaktionsgrenzen hinweg.
  • Prozessplattform auf Basis einheitlicher Daten, dadurch transparente und effizientere Prozesse.
  • Single Sign On, also eine Anmeldung innerhalb des Portals, dadurch geringere Ausfallzeiten der Mitarbeiter für wiederkehrende Tätigkeiten.
  • Aktualität von Daten erlangt bei Portalen an Bedeutung, die Daten in Echtzeit oder quasi-Echtzeit in die zugrundelegenden Applikationen schreiben oder auslesen.
  • usw.

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

[Bearbeiten] Nachteile

Nachteile der Portaltechnologie kommen vor allem dann zu Tage, wenn es darum geht bestehende Anwendungen in ein Portal zu transferieren. Die Anzeige und Bearbeitung reiner Daten kann dann zwar meist über Web Services und Integrationsumgebungen wie 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, als auch die Implementation komplexer Prozesse im Portal über Anwendungsgrenzen hinweg. In der Folge stellt sich dann 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.

Es ist zu beobachten, dass Anwendungen immer stärker auf die Nutzung in einem Portalkontext entwickelt werden, was in der Folge die aufgeführten Konsequenzen aus diesen Nachteilen minimieren würde.

[Bearbeiten] Architektur

Die generelle Architektur eines Portals sieht einen Server vor, der die Anfragen der Anwender entgegennimmt und an die Portletengine 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.

[Bearbeiten] Kommunikation

Intern läuft die Kommunikation zwischen der Portletengine und den Portlets wie folgt. Auf den Request, der 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.

[Bearbeiten] Standards

[Bearbeiten] 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:

[Bearbeiten] Integration

Standards für die Integration von vorhandenen Systemen sind:

[Bearbeiten] Portaltechnik

Für die Portaltechnik relevante Spezifikationen sind:

[Bearbeiten] Portalinhalt

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

[Bearbeiten] Content-Management

Standards für die programmgestützte Verwaltung von Inhalten sind:

  • WebDAV ("Web-based Distributed Authoring and Versioning")
  • Content Repository for Java Technology API (JSR 170 / JSR 283).

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

[Bearbeiten] Portal-Standard-Software

Unter Portal-Standard-Software, häufig auch als Enterprise Portal bezeichnet, wird im Allgemeinen ein Softwareprogramm verstanden, welches es Unternehmen erlaubt, ein Portal aufzubauen. Dazu verfügt eine solche Software über Funktionen wie:

[Bearbeiten] 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:

\uparrow

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.

  • TIBCO Software
Markteinteilung nach Gartner (2006, vgl. [2]) Abdeckungsgrad \rightarrow

Neben kommerzieller Portalsoftware existieren aber auch Open-Source-Portalsysteme, zum Beispiel Liferay, DotNetNuke oder Apache Portals und Cocoon der Apache Software Foundation.

[Bearbeiten] Siehe auch

[Bearbeiten] Literatur

  • Martina Großmann, Holger Koschek: Unternehmensportale. Springer, 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-816-76752-4

[Bearbeiten] Weblinks

[Bearbeiten] Quellen

  1. Thorsten Gurzki et al.: »Was ist ein Portal?« Definition und Einsatz von Unternehmensportalen
  2. Gartner: Magic Quadrant for Horizontal Portal Products, 2006
Andere Sprachen

Static Wikipedia 2008 (no images)

aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - bcl - be - be_x_old - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - co - cr - crh - cs - csb - cu - cv - cy - da - de - diq - dsb - dv - dz - ee - el - eml - en - eo - es - et - eu - ext - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gan - gd - gl - glk - gn - got - gu - gv - ha - hak - haw - he - hi - hif - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kaa - kab - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mdf - mg - mh - mi - mk - ml - mn - mo - mr - mt - mus - my - myv - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - quality - rm - rmy - rn - ro - roa_rup - roa_tara - ru - rw - sa - sah - sc - scn - sco - sd - se - sg - sh - si - simple - sk - sl - sm - sn - so - sr - srn - ss - st - stq - su - sv - sw - szl - ta - te - tet - tg - th - ti - tk - tl - tlh - tn - to - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu -