Pros and cons of Java Portlets?

Question

I have a project in which my client is asking me to use portlets 1.0 spec and Websphere Portal Server 6.0. I haven't worked with portlets before but what I've heard of them always have been bad critiques. What are the reasons besides the obvious of using them? If not reasons, what arguments could I use to avoid them?

Answer 1

As someone who has had several jobs (including my current one) developing Java portlets, I'd say don't use them.

Here's the problem:

If you just wanted to use the pre-existing functionality of the portal you are choosing, then use a portal.

If your use of portlets is just to construct a small, light, primarily read-only web-based dashboard where you can quickly look at disparate information, then that's fine.

But if you (or more likely someone higher up on the org chart) thinks of portlets as a way to put a bunch of different web apps on a page and have it all "just work", then you are headed for a world of hurt. Portlets are highly-restricted, self-contained islands of functionality, not web apps in tiny squares on a page.

Every one of my portlet-based jobs has made this mistake, and there's no light at the end of the tunnel. As a portlet developer, here's a small list of things you're used to doing in regular web apps, that you can't reliably do in portlets:

• Generate URLs to other pages. You'll need a vendor-specific way to do that, since the Portlet API only allows you to generate URLs that target the portlet that generated them.
• Read and set HTTP headers or set the HTTP response code (so no redirects or HTTP caching, since you don't own the page your portlet will be placed on)
• Having to namespace all identifiers in the generated page. This means HTML id attributes and JavaScript function names. Since the namespace has to be determined at runtime to ensure uniqueness, you can't have these Javascript functions reside in a separate browser-cachable file they have to be in the response body for your portlet.

Portlets feel as if they were designed for the state of web development as it was in the mid to late 90s (pre-AJAX). But they are ill-suited for today's web development environments (AJAX, single-page rich web apps, etc.) that assume you have complete control of the request/response cycle.

Answer 2

The problems I have with portlets remind me of the same problems as EJBs-

• portlets require you to write special code that can only be hosted and run in a special server;
• every portlet server vendor has custom extensions/configurations/additional abilities so it's not trivial to change server vendors;
• portlets seem to be overly complex to cover functionality that 90% of people wanting to use it don't need

I'd suggest something like Google Gadgets as the Hibernate to portlet's EJB -

• Javascript framework - server-side pieces can be written in any language, hosted on any server.
• simpler to use
• lots of portal servers support it, and it's more portable across vendors because it's not as complex, and it's not a spec for vendors to implement (and extend)

Answer 3

Portlets are attractive to a business because of the promise of flexibility, you an allow customers to tweak and rearrange components on the page, and if you are primarily serving content then they are an effective means of doing that.

In my opinion portals are well suited to aggregating portlets that are either pure content, functionally independent or simply related (e.g when you pick an item from a list in one portlet, you update another to show the details). Portlets can also enable reuse, because you can configure them into multiple pages/locations fairly simply.

Where the problems can start is when you are trying to decompose complex business functions with multiple steps and interactions. In this scenario determining the granularity of the portlets is more of an art than a science, and careful consideration needs to be given to the interactions between the portlets.

You also need to consider the flexibility of the UI. If you have a set of portlet building blocks your business need to be clear that they can rearrange those blocks, but moving items between portlets involves a rewrite. For example moving the submit button from one portlet to the bottom of the page is not trivial.

So in summary, I guess it depends on what you are trying to do and how much reuse you anticipate of the components. It may be simpler to manage the reuse by creating technical components that IT build into servlets, or it may be that portlets are perfect for your business. There's no right answer, you just need to carefully consider what you are trying to achieve. If you do decide on portlets, you need to embrace the full lifecycle, and avoid any temptation to work around them, you can quickly find yourself in a bad place with all the overheads and restrictions of portlets, without being able to realise the advantages.