IChannel Deprecation Announcement

Owned by Jonathan Markow
Last updated: Feb 08, 2010 by Eric DalquistVersion comment
4 min read

The uPortal Steering Committee would like you to know about planned future support for the JSR-286 portlet API and for uPortal's IChannel interface.

uPortal intends to prioritize JSR-286 support for the 3.3 release. Introducing JSR-286 will provide uPortal with support for the most current portlet standard, offering features such as inter-portlet communication and improved use of portlet-based AJAX technologies.

In order to expedite the integration of JSR-286 support, and for a number of other reasons specified below, uPortal intends to deprecate the IChannel interface. "Channels" were the original proprietary content containers for uPortal before the emergence of the industry-standard JSR 168 "Portlet" specification. While we have been advising users to deploy Portlets for all new development, we are now embarking on a path to fully eliminate Channel support as of uPortal 3.3, due in 2010. As of the upcoming 3.2 release, the IChannel interface will be deprecated, and new portlet types will be provided for many of the publishing types previously implemented as Channels.

Why add JSR-286 support?

JSR-286 provides quite a few useful new features for portals:

  1. ResourceRequests allow portlets to serve arbitrary content directly to the user from within the portal user's session. In Portlet 1.0 the only way to serve direct content was via a Servlet in the application and then the application did not have access to all of the portlet APIs that are normally available. Some uses of ResourceRequests are:
    • Responding to AJAX requests
    • File downloading from a portlet, including the ability to embed generated images.
  2. A two-part render lifecycle. Optionally portlets can participate in a two-part render lifecycle where the first render request can contribute to the <head> of the page as well as set cookies and other headers. The second render request renders the actual portlet content.
    • Portlets won't have to have CSS and JS includes in the middle of the page and a portal will be able to render valid HTML without lots of manual work.
    • The portal can allow these contributions using the first request while still performing streaming of the portlet content during the second request to maintain performance.
  3. Key based caching controls will allow portlets to specify the scope of the cached data (public|private) and use cache validation via an ETag generated by the portlet in addition to the expiration caching available now.
    • The scope option will allow for shared output, such as an RSS feed having a shared cache.
    • The ETag validation will allow the portlet to perform more complex checks to see if the cached data is still valid for a particular request.
  4. "Eventing" adds an additional step to the portlet lifecycle that resides between Action and Render. During the handling of an ActionRequest that portlet may set an event. Other portlets can subscribe to events and then be called when that event occurs via an EventRequest. The eventing model provides a core part of the inter-portlet communication supported by JSR-286.
    • During the EventRequest handling, each portlet can fire more events allowing for complex notification schemes to be implemented
  5. Shared rendering parameters are the second part of the inter-portlet communication supported by JSR-286. They allow a portlet to set a render parameter that other portlets on the page can see as well when they render.
  6. Portlet Filters offer the same support for request/response manipulation that the ServletFilter provides for servlets.
    • Action, Event, Render and Resource filters are all available.

Detailed Portlet 2.0 Review

Why drop Channel support?

Support for Channels has imposed a considerable maintenance burden on uPortal, resulting in many additional developer hours and design compromises. Removing IChannel support will allow us to proceed with JSR-286 and will greatly improved and simplify the uPortal API.  A few examples:

  • Introducing support for the Portlet 2.0 specification (JSR 286) has been problematic because currently all portlets are wrapped by an IChannel. This scheme is no longer practical for Portlet 2.0 support. Portlets will need to become first class citizens, entailing both a significant rewrite effort and a continued burden in order to support IChannels.
  • We now have a custom authentication framework that is tied to our security context, making it extremely difficult to move to a preferred framework like Spring Security. Channels use a specific implementation in the security API; if we were to move to Spring Security, channels would break.
  • The Groups and Permissions framework in uPortal would be improved by refactoring. However, some IChannels, which are able to access any internal portal API directly, depend on it remaining the way it is. In fact, there is no defined API for IChannels. Because of their lack of constraints, we cannot guarantee that any refactoring effort would be safe.

We will also see some immediate advantages by ending support for Channels:

  • The ability to switch to third party code libraries will both reduce native uPortal code and at the same time increase the portal's functionality
  • We will be able to build in support for the newest portlet standard, JSR 286, in 2010.
  • We can now accelerate a move to "bookmark-able URLs" and other high priority features for uPortal campuses.

How will this change affect uPortal users?

  • Starting with uPortal 3.2, any remaining default Channels that now ship with uPortal will be delivered as Portlets instead. For example, CWebProxy will be replaced by the WebProxy Portlet, etc.
  • Many of our early Channels already have Portlet versions. For example, most of the CAnnouncements Channel functionality is duplicated and improved by the Announcements Portlet.
  • Third party Channels such as those that are maintained locally on campuses will not work starting with uPortal 3.3. These Channels will need to be rewritten as Portlets or replaced with other functionally equivalent Portlets.

What are the implications for our campus's uPortal upgrade plans?

  • If your portal content is already based on the Portlet standard, this change should not affect your upgrade planning.
  • Legacy Channels will run in uPortal 3.2, but not in version 3.3, due in 2010.
  • Campuses running uPortal 2.5 and 2.6 should upgrade to 3.2 regardless of their Channel/Portlet mix, if only to take advantage of the many new features in the 3.2 releases.
  • The 3.0, 3.1 and 3.2 versions will be maintained well after the 3.3 release.

We feel that the move from legacy Channels to standard-compliant Portlets will help advance uPortal development more effectively in the years to come.   Please address any questions you might have to the uportal-user list.

-The uPortal Steering Committee