In which Andrew discusses when it is appropriate to write and use IChannels and when it is appropriate to write JSR-168 (or JSR-286) portlets.

Draft in progress This page is a draft in progress that doesn't make much sense yet. Maybe it never will.

Executive Summary

The answer to the question of whether a particular widget should be implemented as an IChannel or as a JSR-168 portlet is the answer to all interesting design questions: "it depends". There are circumstances in which JSR-168 is a far superior solution. There are circumstances in which IChannels are a better solution.

Give up on that IChannel cruft and write JSR-168 portlets

Heads up channel developers, the world has passed you by. Quit writing to an esoteric, uPortal-specific, sadly under-documented API, and embrace standards and frameworks and classloader isolation.

JSR-168 is a standard

Action vs. Render distinction is way cool

Spring PortleMVC makes JSR-168 worthwhile

Control complexity and leverage uPortal by writing an IChannel

Focus on providing real value

Multiple subscribability is a good thing

Multiple publishability is a good thing

Cross-portal? YAGNI

Channel Cache Keys

More .wars means more complexity

JSR-168 is too heavyweight for my problem

More moving parts means more can break

Avoid Both IChannel and JSR-168

If you don't have to run in uPortal's JVM, don't

Loosely coupled is a good thing

Concluding remarks