Präsentationskomponenten dienen dazu, in einem zugewiesenen Bereich innerhalb der Portalseite Inhalte aus unterschiedlichen Systemen und Datenquellen eines Unternehmens benutzergerecht, personalisiert und prozesszentriert darzustellen. Für die Entwicklung solcher Bausteine, die Hersteller als "Portlets", "Gadgets", "Iviews" oder "Connectors" bezeichnen, fehlten aber bisher Standards. Die Folge ist, dass bis heute jeder Anbieter von Portalsoftware ein proprietäres Entwicklungsmodell mit eigenen Präsentationskomponenten verwendet.

Klare Zuordnung der Funktionen von Portlets

Hilfe verspricht nun die von Anwendern und der Industrie seit langem erwartete Java-Portlet-Spezifikation, die vor kurzem in ihrer Endfassung veröffentlicht wurde. Sie ist aus einer Eingabe (Java Specification Request 168) beim Standardisierungsverfahren "Java Community Process" hervorgegangen und definiert, wie sich grafische Web-Komponenten in Java-basierende Portalsysteme integrieren lassen, um Inhalte unterschiedlcher Daten- und Informationsquellen darzustellen. Zudem grenzt die Spezifikation den Aufgabenbereich der Portlets ein. So sollen diese künftig ausschließlich dazu dienen, ausgewählte Funktionen und Inhalte von Informationssystemen darzustellen, und sich nur innerhalb eines Portlet-Containers ausführen lassen. Das Portalsystem soll sich hingegen auf Dienste für Sicherheit, Single-Sign-on und Personalisierung sowie Verwaltung beschränken.

Technisch orientieren sich die Portlets an den Java Servlets, die seinerzeit die Entwicklung "klassischer" Web-Anwendungen standardisiert haben. Das Erben der grundlegenden Strukturen sowie bestimmter Eigenschaften dieses verbreiteten Standards erhöht die Akzeptanz bei den Entwicklern, die für die Implementierung der neuen Portlets verantwortlich sind. Die Lernkurve ist entsprechend flach, da die Einarbeitung in den Portlet-Standard auf vorhandenem Wissen aufsetzt.

Entfernter Zugriff über Web-Services

Parallel dazu hat das Herstellerkonsortium Oasis mit WSRP einen weiteren Standard vorgestellt, der eine Integration von Portlets, die auf entfernten Servern von Portlet-Diensteanbietern implementiert sind, ermöglichen soll. WSRP-kompatible Portlets bieten ihre Dienste nicht nur über die in der Portlet-Spezifikation beschriebenen Programmier-Schnittstelle an, sondern auch als Web-Services. Damit lassen sie sich über das Internet ansprechen und in beliebige Portalsysteme integrieren. So können zum Beispiel Inhalte externer Informationsanbieter (Börsen- oder Wetterdienste) nahtlos in das eigene Portal eingebaut werden.

Beide Spezifikationsteams haben eng zusammengearbeitet, um eine gute Verträglichkeit und Ergänzung der beiden Standards zu gewährleisten und deren Implementierung in die existierenden Portalsysteme zu vereinfachen.

Sollten sich die Vorschläge wie erwartet am Markt durchsetzen, müssten Unternehmen bei der Auswahl eines geeigneten Portalsystems nicht mehr ihre fachlichen Anforderungen von der Verfügbarkeit entsprechender Präsentationskomponenten für dieses Portalsystem abhängig machen. Vorstellbar ist auch, dass die Hersteller mit der Zeit ihre proprietären Präsentationskomponenten dem Portlet-Standard anpassen und so ein umfangreicher Portlet-Katalog entsteht. Kunden könnten aus diesem auswählen und so die Portlet-Eigenentwicklungen auf ein Minimum reduzieren sowie den zeitlichen und finanziellen Aufwand für die Einführung eines Portalsystems verringern.

Auch wäre es beispielsweise einfacher, Standardsoftware in ein Portal einzubinden, da nicht mehr wie bisher für jedes ERP-System eine eigene, an das jeweilige Portalsystem angepasste Präsentationskomponente entwickelt werden muss. Für die Anbieter von Standardsoftware hätte dieses Szenario den Vorteil, dass sie ihre Bausteine für alle standardkonformen Produkte im Markt anbieten und ihren bisherigen Entwicklungs- und Wartungsaufwand ebenfalls vermindern könnten.

Allerdings bekennt sich zumindest SAP nicht klar zu den neuen Empfehlungen. Vielmehr gibt man in Walldorf der eigenentwickelten Iview-Technologie gegenüber dem Portlet-Standard den Vorzug, obwohl dieser viel Raum für herstellerspezifische Erweiterungen lassen würde. Zur Begründung hieß es von Seiten der SAP, dass JSR 168 nur der kleinste gemeinsame Nenner sei und funktional nicht ausreiche, um alle Anforderungen bei der Portalentwicklung abzudecken. So wird die SAP in der Praxis Standard-Portlets im eigenen "Enterprise Portal" zulassen. Iviews werden sich hingegen nicht in anderen Portal-Servern einsetzen lassen.

Dennoch zählt SAP zu den Unterstützern des Portlet-Standards, zu denen neben Sun Microsystems und IBM, die diese Spezifikation entwickelt haben, unter anderem auch Bea Systems, Oracle und Vignette gehören. Diese und weitere Hersteller von Portalsystemen haben bereits mitgeteilt, beide Standards implementieren zu wollen, wenn sie auch insgeheim die Kritik der SAP teilen. So ist zu befürchten, dass auch andere Anbieter ihre Portalsoftware mit proprietären Zusätzen zum Standard versehen werden, um funktionale Lücken zu schließen oder sich Wettbewerbsvorteile zu verschaffen.

Als einer der ersten Hersteller veröffentlichte Bea Systems bereits im Juli ein Paket für die Portlet-Unterstützung als Teil der Version 8.1 von "Weblogic Portal". Da dieses noch auf dem "Public Review Draft" der Portlet-Spezifikation basiert, ist in Kürze ein Update zu erwarten. Früh dabei war auch der Anbieter Plumtree, der die Standards schon heute in den Versionen 4.5, 4.5WS und 5.0 seines "Plumtree Corporate Portal" unterstützt. Dessen Konkurrent Vignette will sie mit der nächsten Version seiner Portalprodukte "Vignette Application Builder" und "Vignette Application Portal" einführen, die Ende dieses Jahres auf den Markt kommen.

Seitens der Branchengrößen erklärt Sun, dass es die Portlet-Spezifikation in Version 6 seines "Portal Servers", der Teil des Softwarepakets Enterprise Java System ist, verwenden wird. Allerdings schweigt sich das Unternehmen über seine Pläne mit WSRP bisher aus. IBM will die Integration von standardkompatiblen Portlets mit Hilfe eines "Fixpack Release" zum "Websphere Portal" in Version 5 ermöglichen. Oracle hat angekündigt, den Portlet-Standard und WSRP als ein Patch Release für den seit kurzem verfügbaren "Oracle Application Server 10g" auszuliefern.

Um die Entwicklung standardkonformer Portlets voranzutreiben, haben zudem Plumtree, Documentum, Bea Systems und Sun eine "Portlet Open Source Trading Site" eingerichtet (http://portlet-opensrc.sourceforge.net/). Diese Initiative dient dem Erfahrungsaustausch mit JSR 168 und WSRP sowie der Schaffung eines Archivs frei verfügbarer Portlets. Die Gründungsmitglieder verpflichten sich dem Open-Source-Gedanken. So stehen die Ergebnisse dieser Initiative, die als Sourceforge-Projekt gehostet ist, auch anderen Organisationen und Individuen offen. (as)

*Holger Koschek ist Consultant für den Bereich Enterprise Portals bei der Resco GmbH in Hamburg.

Links

JSR 168 "Portlet Specification":

http://www.jcp.org/en/jsr/detail?id=168

Web Services for Remote Portlets (WSRP):

http://www.oasis-open.org/committees/tchome.php?wgabbrev=wsrp