Channel Development Strategies June 21, 2004 Steve Barrett

2 Introduction Stephen Barrett – Lead Analyst – Infrastructure Technical Lead, uPortal.Cornell Jon Atherton – Project Lead, uPortal.Cornell Mike Oltz – Technical 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:

4 Agenda  Initial comments  Adoption/Rejection of uPortal  Review of channel types available  Effects of available resources  Supporting the strategy  Recruitment of channel developers  Conclusion

5 Initial Comments  There 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 Types  Image Simple Not very useful

9 Review of Channel Types  Inline Frame Behaves like a browser Not all browsers support inline frames Can not receive uPortal events, parameters and/or credentials from uPortal Channel state is not preserved Easiest to define

10 Review of Channel Types  RSS Easy to create (expressed via XML) Looks like a custom (native) channel Best use results in links to external pages Limited by specification and XSLT implementation in uPortal

11 Review of Channel Types  Web Proxy Converts 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 Transformation GenericXSLT Renders XML documents as channels Requires applications to speak HTTP

13 Review of Channel Types  Remote Channel Proxy First attempt as a webservices channel No complex authentication mechanisms Stalled awaiting Web Services for Remote Portals (WSRP) standard from OASIS ( WSRP channel may replace RCP

14 Review of Channel Types  Custom Implements specific interfaces that allow execution within uPortal Often referred to as “native” channels Provide a “crisp” interactive experience Can call other channels Everything in uPoral is a channel Can negatively effect performance

15 Review of Channel Types  Applet Channel definition is easy and they run fine Provide feature rich graphical environments Self distribution mechanism Horror stories abound Design 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?  Authorization Central 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 channels MT, SC, SB = mostly RSS, some local Web Proxy MT, SC, MB = RSS, local and some “outer” Web Proxy M-LT, SC, M-LB = RSS, Web Proxy, some Native M-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 channels MT, SC, SB = mostly RSS, some local Web Proxy MT, SC, MB = RSS, local and some “outer” Web Proxy M-LT, SC, M-LB = RSS, Web Proxy, some Native M-LT, LC, M-LB = RSS, some local Web Proxy

20 Support of the strategy  Authentication Why? Channels such as Web Proxy and RSS (GenericXSLT) communicate with servers in the 3 rd tier 3 rd tiers need to authenticate the user at the edge as if they were being accessed directly

21 Support of the strategy  Authentication How? Pass a token to the 3 rd tier that can be used to establish the identity of the user at the edge There are several ways to do this: Basic HTTP Authorization URL Parameters (?username=smb1&password=XXXX) Custom HTTP Authorization Cookies

22 Support of the strategy  LocalConnectionContext.java package 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 strategy  Triggering 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, :00PM-3:00PM

25 Buy-In  Almost all of the necessary pieces  War of the religions Java ® Microsoft ® (.asp, VB,.net) Coldfusion ® PERL C/C++ PHP FileMaker ®

26 Buy-In  Plays 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 categorizations Only ONE weather channel is necessary  Coaching the channel developers Channels have titles by definition Multiple document form elements with the same name Users select skins they are most comfortable with Limited amount of available real estate Icons consume a lot of real estate

28 Conclusion