By Steve Crouch.

Developing portlets to run on a number of portal platforms is a tricky business. Plus, if you've already developed portlets to run on a single set up, it's difficult to choose what portal platform to support next. There are a host of portal implementations, development frameworks and containers to host your portal. Where should you start, which portal platforms should you support, and what mechanisms are there to help you support them?

Why write this guide?

This guide was written in response to an AskSteve! question on what one should consider when porting portlets to other portal platforms.

Why use portlet specifications?

Portlet specifications are designed to allow portability between portlets and portal platforms. They provide a common development model for portlet developers to code against, and any portal implementation worth its salt will support one of the two specifications described below.

Once you've chosen which specification you wish to follow, you should code portlets against it from the outset. If your portlets are compliant with a specification, getting them to work on other portal implementations should be much easier. It also means that any developers who are familiar with the specification will have an easy time developing your portlet. Another big benefit is that you need only maintain one core implementation, and not many implementation-specific versions.

Support the JSR-168 and JSR-286 specifications

The most important thing to consider is support for either the JSR-168 specification and its successor, JSR-286. Let's have a brief look at both of them.

JSR-168 (generally called 168) covers a basic programming model. Essentially, it describes how actions should be processed, how the portlet should be rendered, what tasks the portlet will perform, the size of the portal page space (the window) for rendering, the data model (for render parameters, session information and user preference data), and packaging formats for grouping different portlets.

JSR-286 (generally called 286)is an extension to JSR-168, and the good news is that JSR-286 "does not break binary compatibility with" JSR-168 portlets. So a 286-compliant infrastructure is mandated to support 168-compliant portlets and their associated deployment descriptors, albeit with two minor exceptions. It all comes down to whether you wish to make use of the more advanced features of 268 which include:

• Inter-Portlet Communication through events and public render parameters.
• Serving dynamically generated resources directly through portlets.
• Serving AJAX or JSON data directly through portlets.
• Introduction of portlet filters and listeners.

If you don't need 268's extra features, then it should be sufficient to support 168. If you're planning to develop multiple portlets, a key consideration is whether they will require inter-portlet communication. This may be required to share common events between the portlets, e.g. a user selects a specific tour date for a rock band from one portlet, and another portlet responds to that event and displays tour details for that event, whilst another displays a venue map for that part of the tour.

In any case, supporting 168 or 286 will greatly increase the portability, maintainability and hence sustainability of your portlets. So if you've already developed your portlets for one portlet platform, a good first step is to correct any platform-specific features to comply with the JSRs. Bear in mind this might not be trivial due to the complexity of your portlets and the platform features they use. You may find that your code is already compliant. It's certainly worth checking!

Which portal platforms to support?

The good news is that LifeRay, Sakai, JetSpeed, uPortal and GateIn (amongst others) all support the JSR specifications. The platforms you support should primarily be based on the platforms used by your intended user community, and their current and future requirements. A lot of platforms offer functionality far beyond mere JSR compliance, including content management systems and other collaborative features. Even though support for the JSRs will reduce a great many portability concerns, the platform you choose will often have implementation-specific aspects (e.g. for deployment, management and configuration) that you would need to learn, support and test against. It is a good idea to refactor the portlets and their packaging to account for any implementation-specific aspects in a clear and organised way.

This all takes effort, so you may want to keep you officially supported platforms to small core set. Where effort permits, you could always test against some new platforms. (One to avoid is GridSphere which - assuming you could get hold of it - is no longer supported or developed.)

Which portal containers to support?

A related question is which web servers/portal containers to support and test against. Two options are Tomcat or Glassfish (great for EE stuff like EJB). Again, this should be driven by your user community's requirements. Taking into account what we've already discussed, notice that the development and testing requirements are increase rapidly. Each additional combination of portal container and portal framework requires more development and testing. This means that you should be careful to select only the containers and frameworks that your user community needs.

What portlet development frameworks are available?

You may want to consider using a framework to support portlet development. There are a number available, including Struts2, Spring Portlet MVC and Java Server Faces-based frameworks (MyFaces and Mojarra). They have strong support within portlet implementations and often have built-in test frameworks (e.g. Spring MVC).

How to test the portability of portlets on different platforms?

After you've chosen your specification, container and framework technology, and refactored your portlets to comply with the JSRs, there are a few things you can consider to make sure it all works correctly.

Your set up for testing

It's a good idea to have completely separate installations of each combination of web server, portlet container and portal platform that you wish to test against. This is better than trying to deploy all of the platforms to single portlet containers. It ensures that you won't get any interference between the platform and portlet deployments (which can get messy and confuse testing results), and it makes log files clearer and debugging easier. 

Test frameworks

In terms of test frameworks, you may want to consider Selenium. It allows you to develop tests that require interactions with web applications, including portlets. It can even generate JUnit tests for you. You can directly code JUnit tests for portlets, but it can prove a bit tricky. Although PortletUnit sounds ideal, it's not well documented. Although it might be worth a look. If you use Spring, then there's a general article for unit testing in Liferay.

It's a good idea to manually test on a number of browsers to ensure your portlets render and interact correctly. Definitely test against Internet Explorer, Firefox, Chrome and Safari. Again the choice of browsers should be driven by your users. If you don't have any information about your user community's favourite browser, you can turn to the ample discussion about the market share of various browsers to help you decide on which ones to test.

One approach to scale up browser testing, is to write a simple test script that defines a list of portlet features to test and the pass and failure criteria. You can then ask volunteers to test across a number of browsers using your script.

One thing to bear in mind...

A good question to ask yourself: are portlets the right technology for your needs? If you're developing a single basic application, and don't require the extra multi-application and user-management capabilities typically offered by portal infrastructures, perhaps a straightforward web application is a more suitable approach.