Defining a Channel Development Strategy is completely relative. There is no right or wrong strategy. A successful strategy could be one that restricts channel development to only one channel type, or it might be a strategy where all potential content providers accept the channel type recommendation of a uPortal committee whose task is to clearly identify the best channel type for any given application. Both solutions are perfectly acceptable.
Reality teaches that system implementation expectations have two extremes. One extreme includes the people depending on the functionality of the deliverable; they want it instantly and for free. On the other side of the extreme, people want it done in the most efficient and flexible means available, they want unlimited funding with no clearly-defined deadline. This lesson produces no useful information.
For any given problem, there is a window of opportunity and an available amount of resources with which a solution can be implemented. An understanding of the problem, the organization and its available resources is required in order to begin the evaluation process. The result is the definition of a mechanism to be employed to achieve resolution.
Organizations with limited resources and a narrow timeframe will most likely adopt channels that can be developed with little effort, sacrificing enhanced features and possibly performance in order to meet their objectives within constraints. Others with a larger time window and less funding restrictions can afford a more complex approach to channel development that could lead to a much more feature-rich portal experience. The likely scenario, though, would be a combination of these types.
Installation of uPortal is not a minor undertaking. This fact has a significant impact on Channel Development Strategies. Organizations with existing uPortal implementations do not bear the burden of start-up when deciding which channel type to deploy. Those who must factor implementation into their designs are at a slight disadvantage, resulting in a less functional approach. Steps should be taken to identify those "channels" which are essential and those which can be deferred until well after implementation of uPortal Simple critical path analysis will ease much of the burden of deployment.
Existing infrastructure within an organization must also be considered when defining a development strategy. Those with central authentication/authorization mechanisms in place will find it easier to implement distributed processing designs than those without these services. Lack of centralized services may force the strategy decision toward a more complex approach and may negate the possibility of channels as an interactive solution. More complex solutions will tend to push processes more toward the uPortal host, introducing performance concerns that can only be overcome through efficient design and coding. More complex solutions require a greater level of staff competency that is a scarce commodity for some.
Acknowledging the observations above, the remainder of this document consists of a scale of channel types and a matrix of information by channel type. The scale is an attempt to define channel types based on the level of difficulty they present in implementation. However it might be done, the scale is always inaccurate due to opinion, which differs from individual to individual. The matrix presents channel types as defined by the scale and attempts to provide non-biased Pros and Cons for each type. Wherever possible, each channel type in the matrix also contains links to additional resources to assist with their respective evaluations.
Inline Frame
RSS
Web Proxy
Simple XML Transformation
Remote Channel Proxy
Custom
Applet
| Channel Type | Pros | Cons | Additional References |
|---|---|---|---|
| Image | An Image channel is easy to define. Simply name the channel and provide a URL which is used to load the image. | While the Image channel is easy to define, it's usefulness is limited. It simply displays an image. A link my be specified for the image but the link loads within the current browser. | |
| Inline Frame | Inline Frames provide the easiest way to define a channel within uPortal. Defining the channel consists of naming the channel and providing a URL to the remote web server. The remote site is displayed within a channel on the portal as an Inline Frame. All interactions available when accessing the URL directly are available within the channel. | Not all browsers support inline frames. Channels based on Inline Frames cannot receive parameters and/or credentials from uPortal. The state of the channel is not preserved while interacting with other areas of uPortal. | |
| RSS | These are a very easy way to implement channels that "look" like native portal channels. RSS channels optionally contain an image icon providing a link to the "host" of the RSS channel as well as links to points of interest and an optional text input field. These are all rendered from an .RSS file that defines the content of the channel. .RSS files are expressed in XML. | RSS channels provide no internal navigation mechanisms. Control over the "look and feel" is suppressed by the specification. Best use of this channel results in links to external reference points. | http://backend.userland.com/rss http://www.w3.org/TR/REC-xml |
| Web Proxy | This channel attempts to convert well formed HTML from another web server and into XML which can be rendered as a channel in uPortal. It has several advantages with it's most significant being the ability to immediately utilize the significant amount of existing HTML expertise within the organization.
The methods employed by the remote web servers are inconsequential and, therefore, allow organizations to deploy applications in whatever current solutions are available. Complete control over the channel's layout and behavior is given to the remote HTML tagger. Forms processing is available. Web Proxy channels allow existing web based applications to become "portalized" with little or no modifications. Another significant advantage is that the web server hosting the channel is traditionally not the uPortal server. This is advantageous for two reasons: first, processor intensive applications are not taxing the uPortal server itself and second, availability of the remote web server and/or it's services does not effect the availability of the uPortal server. |
The obvious disadvantage of Web Proxy is the requirement of well formed HTML which taggers have traditionally not had to conform to. Embedded JavaScript, for example, will have to be loaded via .js files. A sophisticated channel will require Web Proxy to rewrite most all URL references within the HTML document. There are some "trigger" elements for specific types of tags that taggers will have to learn to provide more mature aspects of HTML rendering. | Official Web Proxy Documentation Cornell Channel Writer's Guide |
| Simple XML Transformation | Simple XML transformations convert XML documents into channel content. The documents are obtained via URL specified as channel definition. | Training staff to decipher and/or render results in XML can be a lengthy and costly undertaking.
Any application which does not currently render XML will require modification. Applications must also accept and process HTTP requests. |
|
| Remote Channel Proxy | Allows a complete interactive channel (as opposed to a simple data feed) to be offered in multiple portals while maintenance of the channel is only done in one portal. Easy to add interactive content into a uPortal instance without writing code, assuming a sufficient remote channel is available. Can be used to offload the work of a channel to a server separate from the portal server. Provides an easy way to preview a channel from another portal. This would allow channel vendors and sharers to arrange channel demonstrations with minimal setup effort. | A sufficient authentication strategy is not yet in place. If the remote channel displays user-specific information, then it may potentially need to manage user information for users accessing the channel via a remote channel proxy from another portal. There is no current API to "discover" the remote channels a portal has to offer. The current uPortal Remote Channel feature is similar to the developing Web Services for Remote Portals (WSRP) standard from OASIS. When the WSRP standard matures, a WSRP-compliant feature may replace the Remote Channel channel type in uPortal. | |
| Custom | Custom channels, often referred to as "native" channels, are those hosted by uPortal itself. To clarify, custom channels are those written in Java and implement specific interfaces that allow them to be executed within uPortal itself. These channels have several advantages: they can usually be shared with other organizations utilizing uPortal, they can easily make use of features of uPortal, and they can "call" other custom channels within uPortal to easily expand their capabilities. Custom channels produce the most efficient channels and, therefore, they present users with a "crisp" response.
Everything in uPortal is a custom channel. The header at the top of the page is a custom channel. The username/password login is a custom channel. |
Custom channels are the most difficult to develop.
These channels, when poorly designed, can have a significant negative impact on the performance of uPortal. Custom channels can affect the availability of uPortal by causing JVM core crashes. The source code of any custom channel should be thoroughly examined before channel publication. |
|
| Applet | Defining an Applet channel is actually very easy. Applets, as you know, are very powerful. They provide a distribution solution by requiring browsers to pull them, and their support libraries, from a server. The user interface that may be presented to a user is much more feature rich than is available through the use of standard browsers and HTML. | The decision to place Applets at the top of the difficulty scale is based largely on their absence in the industry. Conceptually applets are a savior; in reality they never met their objectives. Some have been very successful at Applet deployment, for others, horror stories abound. Success or failure, deployment of applets requires an effort on the scale of distributed systems where one component is a desktop application requiring human interaction. The complexity of such an implementation clearly pushed Applets to the far end of the difficulty scale. | |