1 Jahr Liferay Portal Entwicklung

Es wird Zeit mal nach einem Jahr Liferay Entwicklung ein paar Erfahrungen wiederzugeben.

Als erstes muss man sagen: Es ist cool das man eine derartig umfangreiche Software als OpenSource vorfindet. Von Anfang an hat mich begeistert das es auch auf den Endanwender einen sehr positiven und Professionellen Eindruck macht. Bunt, massenweise Portlets, Drag & Drop, Viele Coole Effekte, man fühlt sich einfach wohl. Hier ist klar die GUI steht im Vordergrund (Da kenne ich andere OpenSource Software).

An diesem ersten Eindruck hat sich prinzipiell auch nach einem Jahr nichts geändert.

Der Erfahrungsbericht bezieht sich übrigens auf die 4.2.2 Version des Systems.

Um die nachfolgenden Bewertungen besser einordnen zu können ist der Kontext in dem wir Liferay einsetzten nicht uninteressant.

Wir entwickeln ein Internet Versicherungsportal (Portal, was für ein inflationärer Begriff im Heute) das zum einen technisch sehr modular aufgebaut sein soll da hier ein Fülle von Versicherungsprodukten angeboten wird, einen personalisierten „Self Service“ Bereich bietet, auf dem viele Contents zu finden sind, und zukünftig auch Extranet Funktionalitäten anbieten wird.

Die spannendste Aufgabe war jedoch die Integration eines Profilsystems das es ermöglicht individuelle Auftritte für eine Vielzahl unserer Kooperationen zur Verfügung zu stellen. Man muss sich vorstellen die haben derzeit schätzungsweise 20 „handgeschnitzte“ Webauftritte die unserer Versicherungen anbieten ,bei denen jedoch ca 95 % des Contents identisch ist. Das bedeutet derzeit einen hohen Wartungsaufwand, eine lange Vorlaufzeit für neue Kooperationen und eingeschränkte Flexibilität da die Inhalte statisch sind.

Das Konzept ist „Configuration by Exception“. Eine neue Betriebskrankenkasse möchte 2 Produkte von uns verkaufen – Wir legen nur noch fest „Welche Produkte“, „Welche Servicetelefonnummer“, „Logo der Kasse“ fertig. All dies über Admin Anwendungen konfigurierbar.

Dies macht klar welches Customizing wir an Liferay betrieben haben.

Aber genug zum Profilsystem des ging doch um Liferay und seinen ersten Eindruck!

Die Entwicklung mit Liferay

Wenn man versucht Liferay in diesem Umfang anzupassen kommt man nicht um die EXT Umgebung herum.
Die EXT Umgebung eine eine Erweiterungsumgebung für Liferay. Physikalisch gesehen ein eigenes Projekt was mit diversen ANT Files die Customizings mit der basis Liferay System Umgebung merged.

Die erste Frage die man sich bei der Begutachtung des erstellten „EXT“ Projektes stellt ist: „Wie bekomme ich das alles ins CVS?“.
Ja im EXT gibt es keine Trennung zwischen generierten und selbst erstellten Resourcen. So findet man auch mal eine angepasste „portal.properties“
im „classes“ Verzeichnis – alles wird gemischt .

Wir haben uns Abhilfe mit einem weiteren „EXT“ Projekt geschafft. Hier ist nur enthalten was im CVS auch abgelegt wird. Dies wird dann bei jedem Build ins originale EXT kopiert und funktioniert ganz gut. Den gleichen Ansatz haben wir fürs „portal“ Projekt (Liferay Source Projekt) gewählt um Bugs am System zu fixen die auch an Liferay gemeldet wurden.

By the Way: Der präferierte Container für Liferay scheint Tomcat zu sein. Das haben wir gerade in der Anfangszeit zu spüren bekommen. Im Weblogic 8.1 ging erst mal nix. Nach einigem debuggen und einigen fixes gings dann jedoch. Mittlerweile sind wir auf WL 9.2. Man sollte sich im klaren sein das die Liferay Jungs das System auf Tomcat entwickeln! Die Ext Umgebung deployed von haus aus nicht auf WL.

Die Enterprise Variante (EJB) würde ich selbst im EJB Container nicht empfehlen! Wird kaum getestet und bremst das System. Hier ist jeder Spring Service eine EJB und Spring Services sind hier reichlich vorhanden. Der start des Servers dauert subjektiv doppelt so lange. Wer glaubt er sei mit der EJB Variante flexibler durch die Nutzbarkeit von Portalservices aus anderen Applikationen, der irrt. Da hier direkt mit dem Domänen Modell kommuniziert wird nimmt man auch alle Abhängigkeiten mit zum Client – und das ist das halbe Portal.

Wir nutzen auch die Liferay Services aus anderen EAR´s jedoch verwenden wir die Classpath Singleton Variante. Die funktioniert meistens und bewegt sich meines Erachtens im Graubereich der JEE Spec. (Classloader Probleme bleiben nicht aus )

Beim Blick auch die bestehenden Portlets und des Systems wird klar: „Es gibt nichts was man nicht auch als JSP Scriptlet Programmieren könnte!“. Man findet als JSP getarnte Java Files die nicht mehr als Java Source und Whitespaces haben. „render_portlet.jsp“ da hauts einen glatt den Vogel raus.

Ansonsten arbeitet man mit Struts, was historisch begründet ist. Auf der Roadmap stand schon mal die Migration auf JSF mittlerweile ist sie wieder weg. (Schade)

Das Meer von JSP ist gigantisch und zugleich erschreckend. Ich hab mal gezählt und bin auf 657 gekommen. WOW! Und damit kommen wir zum meinen größten Kritikpunkt die Modularisierungsarchitektur. Ich hätte gedacht ein Projekt was sich mit dem Thema Portal und Portlets auseinander setzt sollte eine gut modularisiere Portal Impl zu Stande bringen. Wenn jedoch in der portal-ejb neben dem Core auch das Bible Portlet, Amazon, Google, Blog, Wiki, Workflow, Chat, Messenger und viele weitere ihren Auftritt haben, ist es nur noch eine Frage der Zeit bis der Portal Core absäuft.
Man muss sich vorstellten der ganze Kram wird immer mit deployed. Wer kann diese Codebase von (334 Packages) noch beherrschen?!

Cool in diesem Zusammenhang ist die „GlobalShutdownAction“. Hier geben sich core, ICQ, Mail, Msn die Hand. Das Zeigt für die enge Verwebung der Portlets. Aussichtslos die mehr als 70 MB große Anwendung zu strippen.

Das Thema Spring wurde anscheinend nur fürs Marketing integriert. Ich würde sagen man nutzt Spring für die Instanzierung der Pojos mehr jedoch nicht.
Es gibt eigene FactorySingeltons für jedes Pojo, kein AOP, kein Spring Hibernate (sondern direkt), kein Dependency Injection… Und damit wirds schwer minimal invasiv ins Portal einzugreifen.

Hier muss Refactored werden anstatt die Oberfläche mit neuen Themes und weiteren Portlets in jedem Release wieder auf Hochglanz zu bringen.
Ein kleiner Schmaler Portal Kern als Webapp und der Rest als eigenständige Portal Webanwendungen würde hier helfen. Das Grund System würde vermutlich nur noch wenige Megabyte groß sein und mann könnte deployen was man auch wirklich braucht.

Für mich war klar: Im „EXT“ wird nur entwickelt wenns nicht anders geht.

Ein Wort zur Doku darf nicht fehlen. Die ist nämlich ein Witz – insbesondere die JavaDoc!
So in etwa ist dann jede Quelle dokumentiert:

/**
 * View Source
 *
 * @author  Brian Wing Shun Chan
 *
 */
public class GlobalShutdownAction extends SimpleAction {

	public void run(String[] ids) throws ActionException {

Genug gejammert über die Architektur!

Wo Schatten da Licht.
Stellt sich die Frage: Was Liferay von den anderen JSR 168 Portalen abhebt:

• das UI ist genial
• ein integriertes CMS
• ein gutes Fachliches Portal Strukturierungs Konzept (Communitys, Pages…)
• zahlreiche Portlets out of the Box
• ein umfangreiches Berechtigungskonzept
• es ist open source

Das CMS,
sollte man nicht überbewerten ist aber ausreichend. Es ist nicht baumartig was sehr unüblich für ein CMS ist. Bilder und Dokumente werden in einem eigenen Repository verwalltet. Eine Linkverwaltung fehlt leider und dies ist gravierend. Images werden mit Ihrer ID im Artikel referenziert (id=1232). Mit einem Kommerziellen CMS System kann es „Journal Content“ nicht aufnehmen. Aber es währe auch paradox sich wegen des CMS für ein Portal zu entscheiden.

Mein Resümee.

Liferay dürfte die am weitesten entwickelte JSR 168 basierte Portallösung auf OpenSource Basis sein. Es deck alle relevanten funktionalen Anforderungen ab hat jedoch Schwächen in Architektur und Design. Solle man am Customizing des Portals selbst interessiert sein, ist die Lernschwelle sehr hoch. Das integrierte CMS ist ein Alleinstellungsmerkmal, jedoch kann das System nicht mit etablierten CMS Lösungen mithalten.

Ich neige zum Schlusssatz: „Außen Hui innen Pfui“

Jedoch muss man sagen das Closed Source Projekte nicht die Flexibilität bieten und diese art Einblicke gewähren.
Wer weiß schon was man da so manches mal betreibt (Weblogic, Bea Portal, Websphere Portal usw.).