Channel Development Strategies
Introduction		Expand
Scale (from simplest to implement to the most difficult)
Image 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.