Kito Mann is here to talk about Portlets (though I normally relate him to JSF). The nice thing about portlets is that they make portals not just a capital-P Portal that the vendors all try and sell, they help commoditize the idea of a portal into a lower-case-p, somewhat portable aggregation of componentized applications. Back at S.P. Richards, we found single sign-on, minor user personalization, and content aggregation to be the most valuable aspects of a portal to our business, and created a “portal” with a few webapps and Tomcat’s single sign on valve. The other bits – multiple device support, portlets, and complex personalization, weren’t really necessary for the needs of the business. At the time, the open source portals didn’t seem mature, and the Portlet spec had just been approved.

A question to ask shortly… Many Java APIs are fairly useless without the vendor-extensions. How much of the common portlet functionality depends on vendor-specific configuration?

Generally, portals are bite-sized applications that can be embedded in a portal view alongside other portlets. Google has an example of a non-hideous portal.
The “Top Stories”, “Weather”, and “Quote of the Day” would be portlets in Java land.

The rest of the session has been a fairly mundane tour through the Portlet API itself. Mostly stuff you could pick up from a magazine article. The actual demo of the portal using Liferay is fairly interesting. It looks like Liferay has come a long way in the past year or two, in terms of look and usability. Getting it working was also a beast at the time, and it didn’t respect J2EE security, but if I need a portal, I’d have to at least give Liferay a second look, based on what I’m seeing.

Where am I blogging from? No Fluff Just Stuff’s Greater Atlanta Java Software Symposium.