Channel Development Strategies June 21, 2004 Steve Barrett.

Channel Development Strategies

June 21, 2004Steve Barrett

2

Introduction

Stephen Barrett – [email protected]

Lead Analyst – Infrastructure

Technical Lead, uPortal.Cornell

Jon Atherton – [email protected] Lead, uPortal.Cornell

Mike Oltz – [email protected] Support, uPortal.Cornell

3

History

Inquiry on discussion list about Channel Development Strategies documentation

BOF at Winter ’02 JA-SIG conference Channel Development Strategies

document at:

http://www.uportal.org/developers/channel_docs/

4

Agenda

Initial commentsAdoption/Rejection of uPortalReview of channel types availableEffects of available resourcesSupporting the strategyRecruitment of channel developersConclusion

5

Initial CommentsThere is no Channel Development Strategy!

Any strategy will utilize more than one channel type

Any given strategy is neither right or wrong

6

Analysis for Adoption

Is uPortal what you need?Static layout or customizable?

Is the deliverable just a collection of links?

Understand the difference between a portal and a web site

Enough political clout to properly steer/control the effort?

7

Review of Channel Types

Image Inline Frame RSS (GenericXSLT)

Web Proxy Simple XML Transformation Remote Channel Proxy Custom (native)

Applet

8

Review of Channel TypesImageSimpleNot very useful

9

Review of Channel Types

Inline FrameBehaves like a browserNot all browsers support inline framesCan not receive uPortal events, parameters

and/or credentials from uPortalChannel state is not preservedEasiest to define

10

Review of Channel Types

RSSEasy to create (expressed via XML)Looks like a custom (native) channelBest use results in links to external pages Limited by specification and XSLT

implementation in uPortal

11

Review of Channel Types

Web ProxyConverts well formed HTML into XML

that can be rendered within uPortal as a channel

Existing web-based applications can be “portalized” with relative ease

CPU intensive applications do no effect performance of uPortal

12

Review of Channel Types

Simple XML TransformationGenericXSLTRenders XML documents as channelsRequires applications to speak HTTP

13

Review of Channel Types

Remote Channel ProxyFirst attempt as a webservices channelNo complex authentication mechanismsStalled awaiting Web Services for Remote

Portals (WSRP) standard from OASIS (http://www-106.ibm.com/developerworks/webservices/library/ws-wsrp/)

WSRP channel may replace RCP

14

Review of Channel TypesCustomImplements specific interfaces that allow

execution within uPortalOften referred to as “native” channelsProvide a “crisp” interactive experience Can call other channelsEverything in uPoral is a channelCan negatively effect performance

15

Review of Channel Types

AppletChannel definition is easy and they run fineProvide feature rich graphical environmentsSelf distribution mechanismHorror stories aboundDesign complexity on the scale of

distributed systems

16

Environment Variables

Time, when is the delivery date? Hardware; old, new, co-existence? What Web Server, if any? Servlet hosting environment – application server, tomcat? Authentication

Single web sign-on?Central mechanism such as a direcrtory?

AuthorizationCentral mechanism?

Availability of coders and taggers.Java developers.HTML taggers.XML/XSLT knowledge?

17

Environmental Constraints

Project delivery date = Time Customization of uPortal = Customization Budget

Small/Some/Limited Medium Large or Long

18

Result of Analysis and Review

Careful evaluation of environment reveals Channel Development Strategy.

ST, SC, SB = all RSS channelsMT, SC, SB = mostly RSS, some local Web ProxyMT, SC, MB = RSS, local and some “outer” Web ProxyM-LT, SC, M-LB = RSS, Web Proxy, some NativeM-LT, LC, M-LB = RSS, some local Web Proxy

19

Result of Analysis and Review

Careful evaluation of environment reveals Channel Development Strategy.

ST, SC, SB = all RSS channelsMT, SC, SB = mostly RSS, some local Web ProxyMT, SC, MB = RSS, local and some “outer” Web ProxyM-LT, SC, M-LB = RSS, Web Proxy, some NativeM-LT, LC, M-LB = RSS, some local Web Proxy

20

Support of the strategy

AuthenticationWhy?

• Channels such as Web Proxy and RSS (GenericXSLT) communicate with

servers in the 3rd tier • 3rd tiers need to authenticate the user at the edge as if they were being

accessed directly

21

Support of the strategy

AuthenticationHow?

• Pass a token to the 3rd tier that can be used to establish the identity of the user at the edge

• There are several ways to do this:Basic HTTP AuthorizationURL Parameters (?

username=smb1&password=XXXX)

Custom HTTP AuthorizationCookies

22

Support of the strategyLocalConnectionContext.javapackage org.jasig.portal.security;

import org.jasig.portal.ChannelRuntimeData;import org.jasig.portal.ChannelStaticData;

public abstract class LocalConnectionContext {

protected ChannelStaticData staticData;

public void init (ChannelStaticData sd) { staticData = sd; }

public String getDescriptor(String descriptor, ChannelRuntimeData rd) { return descriptor; }

public void sendLocalData(Object connection, ChannelRuntimeData rd) { }

}

23

Support of the strategyTriggering LocalConnectionContext

Channel parameter “upc_localConnContext”

edu.cornell.uportal.LCCImpl

This class extends LCC

24

Support of the strategy

CWebProxy Presentation

Sarah Arnott

Programmer/Analyst Memorial University of Newfoundland

Monday, June 21, 2003 2:00PM-3:00PM

25

Buy-In Almost all of the necessary pieces

War of the religionsJava®

Microsoft® (.asp, VB, .net)Coldfusion®

PERLC/C++PHPFileMaker®

26

Buy-InPlays well with other religions

The faithful do not need to buy into Java

Authentication of the user at the edge is available IF required

Little or no knowledge of uPortal is required

Retention of hosting rights

Ownership of channel and content guarenteed

27

Conclusion Strategies are not static, they change!

Management of channel categorizationsOnly ONE weather channel is necessary

Coaching the channel developersChannels have titles by definitionMultiple document form elements with the same nameUsers select skins they are most comfortable withLimited amount of available real estateIcons consume a lot of real estate

28

Conclusion