Der wesentliche Mehrwert eines Portals besteht darin, Inhalte aus unterschiedlichsten Bereichen und Anwendungen so auf einer Seite zusammenzuführen, dass dem Anwender gerade nur die Informationen dargestellt werden, die für eine bestimmte Situation relevant sind. Für einen Vertriebsmitarbeiter sind das in der Regel ganz andere Informationen als für seinen Kollegen im Einkauf. Dabei kommen die relevanten Informationen selten nur aus einem System, weshalb sie auf klassischem Wege für die Anwender nur mühsam über unterschiedliche Anwendungen und über mehrere Dialoge erreichbar sind. Ein sinnvolles Portal muss daher einzelne Informationsfragmente aus Systemen wie ERP, CRM, Groupware und DMS extrahieren und miteinander kombiniert auf einer Portalseite darstellen können. Auf diese Weise lassen sich Geschäftsprozesse deutlich besser und näher am Rollenkonzept darstellen und unterstützen als es mit einzelnen, separaten Anwendungen möglich wäre.

Leider ist die Umsetzung einer solchen Portalvision heute noch mit sehr großem Implementierungsaufwand verbunden und wird daher nur selten konsequent umgesetzt. Der Grund dafür liegt in der schwachen bis mangelhaften Unterstützung von Standardportalen durch die nahezu monolithisch entwickelten Unternehmensanwendungen. Portlets, entsprechende Schnittstellen und Werkzeuge fehlen meist. Hersteller von Enterprise Software wie beispielsweise SAP oder Microsoft bieten nur selten Standard-Portlets an, dafür aber proprietäre Portalsysteme, in die bereits die eigene Anwendung integriert ist. Das ist in etwa so, als würde jeder Fernsehsender eigene Geräte verkaufen, mit denen zwar theoretisch andere Sender empfangen werden können, das eigene Programm aber nur auf dem eigenen Gerät anzuschauen ist. Unterstützung erhält die Portalvision allerdings zunehmend durch Open-Source-Software und kleinere Unternehmen, die sich durch Offenheit der Standards einen Wettbewerbsvorteil gegenüber etablierten Anbietern versprechen.

Seit dem Release 2.1, das im Juli 2007 erschienen ist, bietet Alfresco eine einfache und flexible Möglichkeit, individuelle Portlets über Templates zu erstellen und sie über den Standard JSR-168 in beliebige Portale einzubinden. So steht zumindest einer Verwendung von Dokumenten und Content aus Alfresco in Portalen nichts mehr im Wege. In Open-Source-Portalen wie Liferay werden zukünftig bereits vorintegrierte Alfresco-Portlets wie beispielsweise „Meine Dokumente“, „Meine Arbeitsbereiche“ und „Meine Aufgaben“ angeboten.

Zur Vereinfachung der Integration von Inhalten in beliebige andere Anwendungen hat Alfresco die so genannten Web Scripts [1] eingeführt. Sie nutzen die in Alfresco eingebundene Template-Engine Freemarker und die serverseitig eingebundene JavaScript-Engine, um ohne großen Programmieraufwand dyna-mische HTML-Fragmente oder -Seiten generieren zu können. Der Name „Web Scripts“ soll ausdrücken, dass JavaScript- und HTML-Kenntnisse ausreichen, um die Elemente zu erstellen, wobei das JavaScript nicht im Browser, sondern auf dem Server ausgeführt wird. Alfresco spricht von „Scriptable MVC for REST, AJAX, Widgets and Portlets“, da die Web Scripts das Model-View-Controller-Konzept über moderne Protokolle und Webtechnologien unterstützen.

Die Web Scripts von Alfresco sind über ein REST-Interface aufrufbar, der einfachsten Form eines Web Service ohne das aufwändige SOAP-Protokoll. Dokumente und dynamische HTML-Fragmente können damit über eine parametrisierbare URL durch beliebige Anwendungen hindurch und aus beliebigen Programmiersprachen heraus eingebunden werden. Erste Anwendungsfälle für Web Scripts sind neben den nachfolgend beschriebenen Portlets die Integration von Alfresco-Dialogen in Microsoft Office und die Portlet-ähnlichen „Dashlets“ in der Webanwendung Alfresco selbst.

Zur Einbindung von Web Scripts und damit von Dokumenten und Content in Portale geht Alfresco einen eleganten Weg: Es stellt zeitgleich mit der im September erscheinenden Enterprise-Network-Version 2.1 ein generisches JSR-168-konformes Portlet zur Verfügung, das die im ECM-System abgelegten Portlet-Definitionen aufruft und die darin referenzierten Web Scripts ausführt. Im Gegensatz zu den meisten Portlet-Implementierungen wird daraufhin kein HTML zwischen Alfresco und dem Portlet ausgetauscht, sondern JSON, ein im Vergleich zu XML kompakteres Austauschformat. JSON hat nicht nur den Vorteil, dass es weniger Overhead erzeugt als XML, sondern auch recht einfach in JavaScript als Objekt verwendet werden kann. JSON wird nicht, wie man es vermuten könnte, serverseitig durch die Portletlogik in HTML aufbereitet, sondern direkt im Browser durch eine Kombination aus DHTML und JavaScripts gerendert. Man spricht dabei auch von Widgets.

Die Vorteile der beschriebenen Implementierungsvariante erschließen sich erst bei der Nutzung: Portalseiten werden dynamischer und schneller, da die im Browser geladenen JavaScript-Bi-bliotheken einzelne Elemente eines Portlets verändern und nachladen können, ohne dass vom Portalserver die gesamte Seite oder das Portlet neu erstellt werden muss. Das Konzept entlastet somit die Portalserver, die bei klassischen Portlets sehr schnell an ihre Leistungsgrenzen stoßen. Während auf dem klassischen Weg für viele Anwender gleichzeitig eine personalisierte Seite immer wieder aufbereitet werden muss, werden die Alfresco-Portlets nur einmal vom Client geladen. Um den Performance-Vorteil nutzen zu können, muss allerdings vom Browser JavaScript zugelassen werden, was in einigen Unternehmen nicht bei jedem Rechner gegeben ist. Allerdings dürfte diese Einschränkung vor dem Hintergrund vernachlässigbar sein, dass selbst die kommerziellen Portalserver nicht mehr ohne JavaScript im Browser auskommen.

Sollten andere Anbieter von Portlets dem Beispiel der Implementierung folgen, wird der sehr hohe Ressourcenbedarf von Portalservern deutlich sinken. Auf der anderen Seite profitieren auch die Anwender, weil die Interaktion zwischen Server und Client mit Portlets deutlich schneller umgesetzt werden kann. Doch die möglichen Vorteile des beschriebenen Ansatzes gehen über eine verbesserte Performance hinaus. Zukünftig wird Alfresco die JavaScript-Bibliotheken so erweitern, dass auch sichere Up- und Downloads zum und aus dem Alfresco-Repository direkt vom Client über REST und JSON erfolgen können. Heute erfordert das sichere Durchleiten von Binärströmen (Dateien) durch ein Portal erheblichen Programmieraufwand und erzeugt große Serverlasten.

Ein weiterer Vorteil der Technik liegt darin, dass die Portlets auch dann in proprietären Portalen wie Sharepoint eingebunden werden könnten, wenn diese keine Portletstandards unterstützen oder nicht in Java umgesetzt sind. Eine minimale Portletlogik zum Laden der Alfresco-WebScripts könnte leicht in andere Programmiersprachen wie PHP oder .NET übertragen werden. Das Rendern der Portlets im Browser durch JavaScript-Bibliotheken, DHTML und JSON erfolgt schließlich unabhängig von der serverseitig verwendeten Programmiersprache.

Der Wermutstropfen an der Portalintegration von Alfresco ist derzeit, dass sie sich noch in der Entwicklung befindet. In der seit Ende Juli 2007 verfügbaren Alfresco-Community-Version 2.1 ist zwar schon die Technologie der Web Scripts angelegt, doch die entsprechenden Portlets fehlen noch. Sie sollen aber bis Mitte September, zeitgleich mit der neuen Enterprise-Version 2.1 folgen und sind dann auch in der Community-Version nutzbar. Wer die wenigen Tage bis zum Release nicht abwarten kann und schon vorher testen oder eigene Portlets entwickeln möchte, kann sich den Sourcecode selbst kompilieren oder sich eine fertige Version der Nightly Builds herunterladen [2].

Mit den neuen Ansätzen zur Portalintegration bestätigt Alfresco den Trend, dass Open Source der Innovationstreiber für Unternehmenssoftware und damit auch für Enterprise Content Management ist. Durch den Ansatz der offenen Schnittstellen ist es sogar möglich, die Lasten von Portalservern zu reduzieren und damit Kosten zu ersparen.

Es bleibt zu hoffen, dass die Innovation nicht nur von Unternehmen wie Liferay und Alfresco getrieben wird, sondern dass auch andere Unternehmen Weiterentwicklungen in Form von neuen Portlets und Portierungen an die Community zurückgeben, sodass die Umsetzung neuartiger Portalvisionen mit vertretbarem Aufwand möglich wird. Doch in Anbetracht der lebhaften Open-Source-Community und der wachsenden Notwendigkeit für offene Unternehmensapplikationen gibt es kaum Alternativen zu Portalen mit offenen Schnittstellen.