Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

Portale: Open Source nur mit Augenmaß

16.02.2007
Von Torsten Rosensteil 
Quelloffene Portal-Server können sich zwar funktional mit der kommerziellen Konkurrenz messen, aber nicht alle Projektanforderungen von Unternehmen gleich gut erfüllen. Tipps für die Auswahl.
Vielfalt der Portaldienste: Je weiter sie von den (roten) Kerndiensten entfernt sind, desto größer sind üblicherweise die Aufwände für spezielle Anpassungen. Diese Faustregel gilt für Open-Source-Portale in verstärktem Maße.
Vielfalt der Portaldienste: Je weiter sie von den (roten) Kerndiensten entfernt sind, desto größer sind üblicherweise die Aufwände für spezielle Anpassungen. Diese Faustregel gilt für Open-Source-Portale in verstärktem Maße.

Portalsoftware soll heute vor allem Geschäftsabläufe effizient gestalten helfen und eine interne und externe Zusammenarbeit ihrer Benutzer ermöglichen - und das am besten einfach und kostengünstig. Das Herzstück solcher Software ist meist ein Portal-Server, der als Laufzeit- oder Integrationsumgebung für höherwertige Portaldienste arbeitet. Er sollte daher deren Entwicklung umfassend, einfach und verlässlich unterstützen können, indem er insbesondere eine gute Integration von Anwendungen und Diensten auf unterschiedlichen Ebenen erlaubt. Dies kann über spezialisierte Portlets, den Zugriff auf ein "Remote Portlet" oder sogar über technische Schnittstellen mit unterschiedlichen Techniken oder Protokollen erfolgen.

Leitfaden für die Produktauswahl

Je individueller die Anforderungen, desto sinnvoller ist ein Open-Source-Produkt. Der Fragenkatalog kann als Leitfaden dienen:

• Wie gut unterstützt der Portal-Server Single-Sign-on-Funktionen? Können die vorhandenen Schnittstellen bedient werden (zum Beispiel von LDAP/Active Directory)?

• Wie einfach kann die Portaloberfläche an das Corporate Design angepasst werden? Welche Mechanismen bietet das Produkt?

• Wie ausgeprägt ist die Personalisierung? (Layout/Portlet-Auswahl /Content-Auswahl / Profilverwaltung)?

• Werden ausreichend Komponenten (Portlets) mitgeliefert oder lassen sie sich mit wenig Aufwand anpassen? Helfen die Beispiele (Portlets/Layouts/Look-and-Feels)?

• Sind Schnittstellen zu einem bestehenden CMS-System vorhanden oder genügen die integrierten CMS-Funktionen des Portals?

• Wie werden Prozesse und Workflows von der Portalinfrastruktur unterstützt?

• Welche Anwendungsschnittstellen sind im Lieferumfang bereits enthalten.

• Wie detailliert lässt sich das Portal administrieren und betreiben? Wie brauchbar sind die Monitoring- und Logging-Tools, wie komfortabel und eingängig die Administrationsumgebung? Lassen sich verschiedene Administrationsrechte vergeben? Skaliert die Portallösung, beispielsweise durch Clustering?

• Ist eine gute Integration des Portals in Entwicklungsumgebungen geboten beziehungsweise wie leistungsfähig ist die mitgeliefert Entwicklungsumgebung?

• Welche technische Basis haben das Portal seine mitgelieferten Komponenten und Beispiele (Spring, EJB, JSF, Struts)? Ist intern für die Techniken Know-how vorhanden, sind sie zukunftssicher und lassen sich in die Anwendungslandschaft integrieren?;

• Welche Standards und Spezifikationen verwendet das Portal, und gibt es Erweiterungen der Standards? Wie groß ist der Aufwand, Standard-Portlets an die Besonderheiten des Portals anzupassen?

In zehn Schritten zum Open-Source-Portal

Stakeholder identifizieren:

Wegen der oft übergreifenden Ausprägung des Portals kann seine Umsetzung viele Anwender betreffen. Damit diese das Ergebnis akzeptieren, muss die Anforderungsanalyse sie einbeziehen.

Portalstrategie festlegen:

Bei der Definition und Formulierung der strategischen Ziele müssen unbedingt für das Projekt entscheidende Stakeholder einbezogen werden. Ausarbeitung einer strategischen Roadmap.

Anforderungen erheben und priorisieren:

Für die Produktauswahl müssen klare Anforderungen vorliegen (siehe Kasten "Leitfaden für die Produktauswahl"). Sie helfen bei einer ersten Einschätzung des Return on Investement (RoI).

Ausarbeitung eines fachlichen Grobkonzepts:

Auf Basis der Anforderungen ist eine grobe fachliche Konzeption möglich. Sie soll die Vorgaben besser einschätzen helfen.

Einsatz von Portalsoftware hinterfragen:

Es kann auch ohne Portal-Server gehen. Allerdings sollte die Entscheidung auch langfristig Sinn machen.

Vorauswahl:

Meist reduzieren schon die Ausgangslage im Projekt sowie ein Blick auf die wichtigsten Anforderungen die Zahl der in Frage kommenden Portalprodukte.

Portalsoftware evaluieren:

Mit den verbleibenden Produkten sollte eine Evaluierung anhand der konkreten Anforderungen erfolgen.

Proof of Concept mit dem favorisierten Produkt:

Dabei sollten die Anforderungen mit dem größten Entwicklungsrisiko umgesetzt werden, um das Gesamtprojektrisiko zu verringern und die Produktauswahl zu bestätigen.

Erkenntnisse auswerten:

Mit dem Wissen aus dem Proof of Concept lassen sich Projektumfang und Aufwand für die Umsetzung der restlichen Anforderungen besser abschätzen. Anhand dieser Erkenntnisse sollten noch einmal Architektur, Konzepte und Lösungsansätze hinterfragt werden.

Umsetzung:

Je nach Größe des Vorhabens wird entweder zunächst eine Roadmap erstellt, oder es lassen sich dank des Proof of Concept unmittelbar das Gesamtkonzept und die noch fehlenden Anforderungen umsetzen.

Hier lesen Sie ...

• welche Stärken und Schwächen Open-Source-Portale haben;

• was bei ihrer Auswahl zu beachten ist;

• wie man sie einführen sollte.

Funktionsvergleich hilft wenig

Weiter verfügt ausgereifte Portalsoftware stets über einen Basisdienst, der Benutzer authentifiziert und autorisiert und den Verbindungsaufbau sichert, und sie gestattet eine Zusammenstellung und grundlegende Personalisierung der Oberfläche. Eine Integration von Inhalten aus Content-Management-Systemen (CMS) oder die Bereitstellung von CMS-Funktionen im Portal-Server sind ebenfalls ein Muss. Manche Projekte legen zudem auf Suchfunktionen von Portalinhalten großen Wert.

Gängige quelloffene Portalprodukte und -projekte sind "Exo Platform", "Liferay", "Jboss Portal", "Jetspeed" oder "Gridsphere". Wie gut diese Angebote zur kommerziellen Konkurrenz stehen, lässt sich heute allein anhand von Feature-Listen kaum noch beurteilen, da sich die Produkte technisch stark ähneln. Deshalb sollten Unternehmen bei der Auswahl immer ihre aktuellen Projektanforderungen zugrunde legen (siehe Kasten "Leitfaden für die Produktauswahl"). Vorsicht ist auch bei Kostenbetrachtungen geboten. So ist Open-Source-Portalsoftware zwar kostenlos als Quellcode oder als ausführbares Programmpaket erhältlich, bei Anpassungen, Pflege oder Weiterentwicklungen entstehen jedoch Folgekosten, die oft die gesparten Lizenzkosten relativieren.

Last der Freiheit

Ebenso scheint es vorteilhaft, wenn sich offene Portalsoftware von Entwicklern selbst an spezielle Anforderungen anpassen oder als Quellcode-Referenz verwenden lässt. Dies kann je nach Lizenzmodell aber dazu führen, dass die Anpassungen allgemein zugänglich gemacht werden müssen, was wiederum bei einem unvorsichtigen Konfigurations-Management schnell zu Problemen beim Upgrade der Portalsoftware führen kann.

Open-Source-Produkte haben meist sehr dynamische Release-Zyklen. Vor allem populäre Projekte werden laufend überarbeitet und um neue Funktionen ergänzt. Fehler werden auch dank des engen Kontakts zwischen Entwicklern in der Regel schnell behoben. Kommerzielle Portalanbieter brauchen meist wesentlich länger, bis sie Entwickler auf größere Fehler hinweisen und ein entsprechendes Bugfix-Release verfügbar haben. Zudem lassen sich Fragen zu Open Source meist schnell durch eine Recherche in Foren, über "Frequently Asked Questions" oder Wikis klären. Das gilt auch bezüglich der Integration von Drittsystemen: den Programmierern bleibt zwar Handarbeit nicht erspart, doch können sie auf einen großen Fundus an Wissen zugreifen, was ihre Flexibilität deutlich erhöht.

Open-Source-Portalsoftware ist insbesondere auf Plattformen wie J2EE-Applikations-Servern und Servlet-Containern wie "Tomcat" einsetzbar. Sie gilt als leicht zu portieren und lässt dem Anwender bei der Wahl der Datenbank weitgehend freie Hand.

Content-Management an Bord

Zum Lieferumfang gehören manchmal auch einfache CMS-Lösungen beziehungsweise Schnittstellen zu quelloffenen CMS-Projekten. Gibt es im Unternehmen keine speziellen Anforderungen an das CMS, können diese Lösungen durchaus eine Alternative sein, sollten aber trotzdem gesondert auf ihre Tauglichkeit für das jeweilige Szenario überprüft werden. Dank fast durchgängig umgesetzter offener Portalstandards wie die Portlet-Spezifikation in Version 1 (JSR-168) und WSRP (Web Services for Remote Portlets) lässt sich quelloffene Portalsoftware einfacher austauschen oder mit anderen Systemen integrieren.

Sicherheitsstandards

Die Unterstützung der Programmierschnittstelle für die Anbindung an Content Repositories (JSR-170) etabliert sich ebenfalls langsam zur Standardfunktion für Portal-Server. In puncto Sicherheit bieten alle gängigen Produkte eine Reihe von Autorisierungs-, Authentifizierungs- und Sicherheitsmechanismen. Diese sind im Wesentlichen der Java Authentication and Authorization Service (JAAS), Single-Sign-on, Möglichkeiten der LDAP-Anbindung (Lightweight Directory Access Protocol), Rollen- und Rechteverwaltung und die gesicherte Verbindung über Secure Sockets Layer (SSL).

Die von quelloffener Portalsoftware gebotenen Administrationsfunktionen sind denen kommerzieller Produkte ebenbürtig, doch ihre Benutzeroberflächen bieten oft weniger Komfort. Die Server-Verwaltung und Integration in den Betrieb ist bei Open-Source-Produkten meist aufwändiger und erfordert bei der Konfiguration mehr "Handarbeit"- ein Punkt, der wohl nur technisch versierten Anwendern und Produktkennern gefallen wird, da sie die Konfiguration individueller kontrollieren können. Ferner bieten kommerzielle Hersteller meist integrierte, auf ihre Produkte abgestimmte Entwicklungsumgebungen, während in Open-Source-Produkten oft mit Skripten gearbeitet werden muss und Programmierer ihre Entwicklungsumgebung über Plug-ins auf die Anforderungen der Portalentwicklung abstimmen müssen. Entscheidend ist aber letztlich, in welcher Umgebung Entwickler sich besser zurechtfinden.

Wenig Hilfe bieten Open-Source-Portale bei der Einbindung von Groupware wie "IBM Lotus Notes/Domino" und "Microsoft Exchange". Mitgelieferte "Beispiel-Portlets" für die Integration mit externen Anwendungen haben meistens wirklich nur beispielhaften Charakter, während die kommerzielle Konkurrenz durchaus nutzbare Komponenten bereithält. Zum Teil können hier kleinere kommerzielle Anbieter mit JSR-168-kompatiblen Portlets aushelfen. Zur Vorsicht sei vor allem Unternehmen geraten, die eine bereits stark vereinheitlichte IT-Landschaft haben und deren Anwendungen über eine quelloffene Portal-Lösungen integrieren wollen. So sind die Produkte unterschiedlich gut dokumentiert. Manche von ihnen zwingen Entwickler, sich zunächst in Teile des Quellcodes einzuarbeiten, wenn sie mehr als nur ein Standard-Portlet entwerfen müssen. Dabei steht ihnen im Vergleich zu kommerziellen Anbietern mit großen Serviceabteilungen nur eingeschränkter professioneller Support zur Seite. (as)