Page Comparison

I spent a few weeks researching different approaches and frameworks to developing portlets. The basis for this research was to find a good methodology to developing portlets for uPortal 3.0. A specific desire was to try to find a way to reuse as much functionality as possible across different portlets.

Portlets are different from uPortal Channels. uPortal Channels are not an industry standard. Portlets are different from Servlets. Portlets are and Servlets are both industry standards, but Portlets may not assume complete ownership of the web page they are presented in.

...

In the last year the JavaServer Faces (JSF) technology has gathered a pretty decent following. JSF 1.0 was created under the Java Community Process with JSR-127. Since then version 1.1 has been released and version 1.2 is in the works (JSR-252). The goal of JSF was to allow people to think about building web applications in a different way. Allow developers to build components and not worry about creating servlets, pages, or views. The way this is accomplished in a web environment is with the JSF technology owning the servlet that is used and playing a heavy role in the resulting HTML that is sent to the browser. JSP pages seem to be the only popular view technology current available (although the specification allows room for other view technologies to be developed). JSF has a rich lifecycle that is not entirely compatible with JSPs (see http://www.onjava.com/pub/a/onjava/2004/06/09/jsf.html and comments for more info). The Facelets view technology has been developed to avoid that.

Portlets are not servlets, and there is a slight problem with having your core application be a JSF servlet. A Porlet "add-on" library was written to allow a JSF application to be distributed as a Portlet Web application. I was able to take two examples from the JSF Reference Implementation and get them running as portlets inside of uPortal 2.4+ (CVS Head on March 21, 2005, they would NOT run in uPortal 2.4.2) with this add-on library. My impressions were pretty sub par. The portlets would consistently flake out. It was very common to have to logout/login, or stop/start the server, multiple times, with no other changes, to get the portlets to run. Another design issue seems to be the idea of the 'beans' it creates for each user session. There did not appear to be a way to specify any beans as 'reusuable' across multiple sessions. This means for every user login every bean configured for this application, must be created. The memory overhead that could be associated with this is a concern. Correction: beans can be specified to have application scope

JSF was specified to allow implementations to support portlets (ExternalContext is used to wrap either PortletContext or ServletContext). Apache MyFaces now has support for portlets which works fairly well in uPortal 2.5.0, but is still a little buggy.

I recommend against using JavaServer Faces for the following reasons. 1) portlets are not officially supported, and the portlet-add on library appears unstable in uPortal 2.4+. 2) memory could be a concern if all beans are always created for all user login sessions and there is no way to reuse a paticular bean acrosss different users sessions. 3) it's very different from other portlet/servlet technologies and could be harder for the uPortal community to initially support. 4) There is no apparent support for Portlet Modes or Preferences. Correction: Modes can be handled, but not extremely elegantly. See http://wiki.apache.org/myfaces/UsingPortletModes. I believe Preferences can be accessed within the methods of MyFaces' MyFacesGenericPortlet.

Struts

Struts is a very popular and widely adopted MVC framework for the web. The current stable version is 1.2.4 and 1.2.6 is currently in beta. Struts is also based on Servlet technology and does not currently directly support Portlets. There are currently two proposals for Struts 2.0.x (Shale and Jericho) and it is not clear what the timeframe is for direct Portlet support.

...

I do not currently recommend using Spring Web MVC for the following reasons. 1) Portlet support is not part of an official release and could potentially change before making it into one. Changes could cause any uPortal code to need to be rewritten to upgrade to a more stable version of Spring. 2) uPortal 3 is currently using Spring, however, it is being written to a version that does not include Portlet support. There is a chance the version that would include portlet support might be incompatible with the version that the other uPortal code was written to. 3) the design choice of calling both the render and action methods 'handleRequest' diminishes the significant importance of these two operations.

Tapestry

Tapestry now fully supports portlets. The original author did not consider Tapestry in his investigation.

The Code

As part of this research I tried to create an equivalent application in the frameworks I could get running. I was able to get a version of the standard number guessing game running under JavaServer Faces, Spring and "no framework". I was able to convert my "no framework" application to a Spring Portlet based example in less then a couple of hours. I made no attempt to go to/from the JavaServer Faces code, and instead just based my examples on the funcationality provided.

...

I recommend not using any existing framework I reviewed at this time. Instead coding our portlets with a common dispatcher pattern that can be easily converted to another framework in the future (e.g., Spring Portlet MVC). I recommend we use JSP pages for view technology to take advantage of the Portlet tag library for handling Portlet URLs within the view page. We can accomplish reusability between portlets we write by using the include mechanism of JSP pages and writing coresponding backing data beans. This approach leaves uPortal as decoupled as possible from frameworks that are still in development, and does not require us spending a large number of hours writing our own framework.

Now with uPortal 2.5.0, you should consider JSF, possibly with Facelets instead of JSPs.

Future Considerations

Although not originally looked at by this research a couple of other projects seem related that should be considered in the future.

...

Tiles offers a more robust way to put together web pages. Although the technology is roughly equivalent to the include mechanism of JSP pages it can offer a lot more if a lot of thought goes into setting up the pieces correctly. There is no reason Tiles cant be used right away with the approach recommended, this is simply pointing out that to make effective use of Tiles, would require some more time in coming up with the best ways to use it.

Cris J. Holdorph