Channels or Portlets
This page will explain when it is appropriate to write a channel and when it is a good idea to write a JSR-168 portlet. It will also address reasons for and against converting a given channel to a portlet.
New Development
new JSR-168 Portlets
Cross-portal
JSR-168 is a standard and so a portlet written to the JSR-168 standard may work across multiple JSR-168 compliant portals. This is very important if you have a need to re-use this portlet across multiple portal platforms or if you're looking to share the portlet with or collaborate with a larger developer community beyond JA-SIG and uPortal. Your Bookmarks Portlet project might very well find application and engagement from developers working with Jetspeed2, or Liferay, or any of a number of JSR-168 portals. You will miss this engagement opportunity if you stick with the uPortal-specific IChannel API.
TODO: add more pros/cons
new Channels
Channels are appropriate when the advantages of JSR-168 are not applicable or compelling and when there is some advantage to be had from IChannel.
Neither! Re-use an existing IChannel or JSR-168
Instead of looking to write new Java widgets to run inside the uPortal JVM – IChannels or JSR-168s – often it is feasible to instead integrate with an existing channel or portlet. CGenericXSLT provides for the rendering of XML with XSLT – and the interactivity of applicationlets so delivered, with links able to direct the channel to consume different XML URLs or even to render using different XSLTs. CWebProxy provides an even richer mechanism for proxying remote web applications.
Not running in uPortal's JVM is a good thing
This allows the custom application to be hosted, maintained, and updated remotely, without having to synchronize with portal upgrade schedules. Typical changes to the remote application require no changes portal-side. Since the application runs outside the uPortal JVM, the worst it can do is individually break, there is little it can do to damange the whole portal.
New CPDs freshen old code
A new CPD (Channel Publishing Document) can provide a usage-specific configuration workflow for an existing channel or portlet. For instance, a suitable CPD can provide an RSS-consumption-speciifc workflow for configuring the CGenericXSLT channel to render XSLT. A new channel is not necessarily needed, even to provide an appropriate configuration workflow, when an old channel will do the job.
Develop using your framework of choice
Now that you're building a traditional web application following some conventions for presentation through the portal, you can make use of web application frameworks such as SpringWebMVC, Struts, etc. Even non-Java platforms, such as Ruby on Rails, PHP, Perl, .NET ASP.
Existing IMultithreaded channels
Refactor as IChannel
Converting an IMultithreaded channel to an IChannel is a straightforward refactor.
Rewrite as Portlet
Converting to a portlet is closer to a rewrite and may have a high cost. You might want to consider looking for a portlet that already does what you need and port it into uPortal.
University of Wisconsin - Madison will soon be making the source of their ports of WebProxy and XSLT available. They rewrote WebProxy and XSLT as Portlets. More information on their proposed contributions can be found here.
Existing IChannels
TODO: add info here