I looked into using an open source enterprise portal solution for my employer a while ago and concluded that the right answer for us is "none of the above".
Our primary interest in an enterprise portal lies in (1) information aggregation (dashboards) and (2) consistent, elegant look/feel. End-user personalization and customization are less important, as long as we can define dashboards for different user communities. Single sign-on, which is another key element of a portal, is necessary, but not a driver to get a portal... it's available as a standalone functionality (e.g. Yale CAS).
I've personally installed and kicked the tires on four excellent open source portal servers: (1) eXo Portal 1.1, (2) Liferay 4.0, (3) Apache Jetspeed-2, and (4) JBoss Portal 2.2. I've also worked with Pluto, the reference implementation of a portlet container from Apache. We have a pilot implementation of Liferay 4.0 up and running on a test server for people to experiment with. My recent focus has been on tools and techniques for creating portlets, with a view toward promoting JSR-168 compliant portlets among our developers as a user-interface strategy within our enterprise architecture. After weeks of further research and development-centric effort on the topic, I reached the following conclusions...
In the age of rich internet applications (RIA, aka Ajax, etc.), the architecture of JSR-168-compliant portals is fundamentally flawed. It was designed before Ajax. They do the aggregation at the server for a single request/response cycle when logically the aggregation should occur at the client via asynchronous requests (Ajax). The portlet version 2 specification, JSR-286, focuses on inter-portlet communications, which would be helpful, but it still keeps the aggregation-at-the-server paradigm. This intoduces all kinds of challenges, not the least of which are portlet content caching decisions and slow response cycles as the page is not delivered to the browser until the last portlet is rendered. I could go into this further, but suffice it to say that with a little bit of javascript on the client side, the bulk of the portal server's functionality and challenges go away. The portal server application would simply authenticate users, remember their preferences, and deliver the Ajax-based portal application to the client browser. The aggregation fundamentally belongs on the client, not the server. Of course the WSRP (Web Services Remote Portlet) specification may still be quite relevant, even if the aggregation happens at the client instead of on a server.
There aren't very many books available on portlet development. It's a topic that's largely being ignored. Manning assembled the all-star team for such an effort and then abandoned the manuscript after it was written, without printing it. This tells me that the Java portlet specification landed with a thud when it was released in October 2003. They just aren't getting much interest. On a related note, Forrester had an interesting Trends article in March of 2005 entitled "Say Goodbye to Portal Servers". They assert that the functionality found in traditional portal servers has migrated to application servers and other infrastructure elements (workflow engines, etc.).
Three years after the specification was released, tools for developing portlets are either primitive or non-existant, which is another indicator of a lack of adoption by the industry as a whole. Eclipse has nothing going within their web tools platform (WTP) project to help developers create portlets, particularly with respect to debugging. Their support for developing regular web applications on typical Java application servers, however, is quite robust.
Debugging portlets is nasty; it's much more difficult than debugging a stand-alone web application. You need to either (1) run the whole portal server inside the debugger and debug your portlet as part of the whole portal, or (2) deploy your portlet to a portal server running in remote debug mode (with sluggish performance) and re-deploy it each time you make any little change. There's no support for portlet containers like there is for servlet containers (at least, that I can find for Eclipse).
There aren't very many portlet-centric applications being developed out there, and I can't think of any being marketed to us. The Alfresco enterprise content management system is fairly typical: it was designed to run either stand-alone or as a portlet, but the whole thing is a single portlet. They didn't really design their app as a collection of portlets, dependent on having a portal server. I have yet to find a true composite application built on portlets as a user interface strategy.
Users benefit more from RIA applications than traditional portals. I couldn't find any RIA portals. The Google Home Page (www.google.com/ig) comes the closest, with it's Gadget API (http://www.google.com/apis/homepage/reference.html). The Google Web Toolkit (http://code.google.com/webtoolkit/) also looks really promising for developing rich Internet applications. Perhaps one could even code their own lightweight client-side portal server application that consumes WSRP portlets?
Posts
