IChannel or JSR-168

(Reposted, edited, from something I wrote on the jasig-portal list).

Should I write an IChannel or a JSR-168 portlet?

You should do whatever makes the most sense for whatever it is you're trying
to accomplish. Which is a fairly generic meaningless thing to say, but I
think it's the truth.

If you care about cross-portal, if you're building the portlet to end all
portlets and you want to run it anywhere, if you want to run it in uPortal
3, if you're building something sufficiently generic that you'll want to
share it with or collaborate on it with folks using other portals, if you're
looking to use JSP or some other templating technology other than XSLT, if
you're looking to maximize the re-usability and value of your learning
investment, or if you're looking to take advantage of an excellent MVC
framework (Spring PortletMVC), then JSR-168 can be a good choice.

If you're writing a quick one-off, a throwaway channel, something that will
run afoul of known uPortal JSR-168 support eccentricities (bugs?), then
IChannel can be a good choice. IChannels can better implement
unauthenticated portal page use cases and multiply subscribable widget use
cases. IChannels can incur less configuration pain, being multiply
publishable via the uPortal UI rather than requiring portlet.xml files.
JSR-168 portlets typically incur an additional web application on your
server, and get their own classloader, which is really neat isolation unless
it isn't that neat because it's getting in the way of something you want to
do, like share services between portal and portlet. And sure, you can solve
this via putting services in shared classloader locations etc., but it can
get complex. Channels have a few neat tricks up their sleeves, such as
ability to register IPermissibles with the PermissionsManager and delegate
to the GroupsManager and PermissionsManager servant channels. For specific
use cases where this accomplishes your goal, this can be pretty neat.

And often, a good choice is to write neither, and instead host the
applications or content remotely from the portal and use a web proxy
(CWebProxy) to proxy it, thereby keeping the software outside of the running
portal. This can ease the complexities of rolling new versions of the
widgets in your portal into production. With customer JSR-168 or with
custom IChannel this requires coordination with portal server maintenance.
When proxying remotely hosted content, the particular remotely hosted widget
can have independent outages, upgrades, and all that is affected is that one
widget. And, of course, the proxied application could be implemented in PHP
or Ruby on Rails or Spring WebMVC or really whatever is most convenient.
Judicious use of proxies can also reduce load on your portal server itself.

Which of these options is the "right" answer in any given case depends. I
don't think you get any bonus points for doing JSR-168 where it doesn't
actually buy you anything you want. However, there are some significant
advantages of JSR-168 *if* they are advantages for the particular problem
you're solving.