fle[ks]ray

IIn den letzten Jahren haben sich viele Opensource Enterprise Portale zu vollwertigen Businesslösungen entwickelt. Auch die IT-Riesen wie IBM und Sun stellen Teile Ihre Enterprisesoftware (wenigstens als Developerversion) zur freien Verfügung.
• Vergleich Enterprise Portale

Unterschiede Portal und CMS Was ist eigentlich der Unterschied zwischen den beiden Frameworks, deren Namen in fast jedem Projektmanagermeeting zur Sprache kommen? Hier ein kurzer Überblick über die wichtigsten Funktionen von Contentmanagementsystemen und Enterprise Portalen.

Funktionen eines Portals

• Benutzermanagement, (Unterscheidung nach Rollen, Gruppen und Userid)
• Benutzerauthentisierung (nicht jeder darf alles, Unterscheidung nach Rechten wie Lesen, Schreiben..)
• Personalisierung (User können ihre Portaloberfläche individuell gestalten)
• Integration von Applikationen (bestehende Anwendungen können durch Portlets in das Portal integriert werden)

Funktionen eines CMS

• Content strukturieren (redaktionelle Texte werden Layouteinheiten zugeordnet)
• Workflows (Content kann sich in verschiedenen Arbeitsphasen wie Entwurf, Geprüft oder Live befinden )
• Assetmanagement (Content kann in Einheiten gegliedert werden)

Wann was einsetzen?

Der Einsatz von Portalen macht besonders dann Sinn, wenn eine breite Anwendergruppe Zugriff auf unterschiedliche Anwendungen haben soll. Die Anwender können ebenfalls Content generieren. Wer wo publizieren darf und wer welche Anwendung nutzen darf, lässt sich durch eine feingranulare Rechteverwaltung managen. Ein Mitarbeiterportal bzw. ein Intranet einer Firma, in der jeder Mitarbeiter Beiträge publizieren kann, ist ein klassisches Einsatzgebiet eines Enterprise Portals. Jede Art von Backofficeanwendung ist ebenfalls ein Kanditat für den Einsatz eines Portals.
Ein CMS sollte dann eingesetzt werden, wenn eine bestimmte Personengruppe (z.B. eine Redaktion) für die Generierung des Content verantwortlich ist. Redakteure schreiben Artikel für einen Internetauftritt und veröffentlichen Bilder, der Chefredakteur schaltet die Beiträge frei und stellt diese einem breiten Publikum zu Verfügung (Workflow).
Der Anwender selbst ( z.B. der Leser einer Internetpräsenz einer Zeitschrift) hat keinen Einfluss auf den Content. Auch werden die Leser nicht in Gruppen unterteilt. Jeder kann in der Regel alles lesen. Bestenfalls existiert ein Login für autorisierte Leser (Onlineabo o.ä.).
Weiter oben war die Rede von Applikationsintegration in Portale. Eine solche Applikation kann auch ein CMS sein. Ein Portal kann also, neben anderen Anwendungen, ein Contentmanagementsystem enthalten. Dieses CMS kann im Bedarfsfall auch ausgetauscht werden, ohne das die Funktionalität andere Komponenten des Portals beeinflusst wird.

Bereits seit Januar 2002 gibt es einen Standard (JSR 168) für Enterprise Portale. Die Spezifikation wurde damals gemeinsam von Sun und IBM eingereicht und sollte eine gemeinsame Grundlage für die Entwicklung von Portalkomponenten, insbesondere für Portlets, schaffen.
Diese erste Spezifikation definierte hauptsächlich das Verhalten der Portlets. Ein typisches Portlet definiert, ähnlich einer gängigen Desktopanwendung, Schaltflächen zum Maximieren, Minimieren, Editieren und für einen Hilfetext.

Problem: Kommunikation der Portlets untereinander

In der JSR 168 wurden jedoch keine Standards für die Kommunikation der Portlets untereinander festgelegt. Diese zu implementieren blieb dem Entwickler überlassen. Eine Art "Bestpractice", die auch in der Fachliteratur empfohlen wurde, war der Austausch von Informationen über den Applicationcontext. Vergleichen kann man diesen Ansatz mit einem globalen Container, in dem ein Portlet Informationen hinterlegen konnte. Jedes andere Portlet konnte diese Information dann auslesen.

Die neue Spezifikation

In der der Portlet 2.0 (JSR 268) Spezifaktion, die seit Mai 2007 vorliegt, wurde für diese Art des Informationsaustausch wesentlich verbessert. Portlets können nun Informationen basierend auf Events austauschen. Die miteinander kommunizierenden Komponenten teilen sich eine Session, von der andere Portlots im Kontext nichts erfahren.
Der Lebenszyklus eines Portlets wurde aus diesem Grund, um die Phase processEvent erweitert. Events, sowie deren Sender und Empfänger können im Deployment-Descriptor festgelegt werden. Ein Blick in diese XML-Datei verrät also schon einiges über das Zusammenspiel der Portalkomponenten untereinander.
Ein sehr guter Überblick zur Portletspezifikationen im Allgemeinen findet sich hier.
Im Blog von SUN findet sich eine gute Beschreibung der neuen Features der Portlet 2.0 Spezifikation.