Channel Development Strategies June 10 2003 Steve Barrett

Channel Development Strategies June 10, 2003 Steve Barrett

Introduction Stephen Barrett – smb 1@cornell. edu Lead Analyst – Infrastructure Technical Lead, u. Portal. Cornell Jon Atherton – jca 8@cornell. edu Project Lead, u. Portal. Cornell Mike Oltz – mdo 1@cornell. edu Technical Support, u. Portal. Cornell 2

History Ø Inquiry on discussion list about Channel Development Strategies documentation Ø BOF at Winter ’ 02 JA-SIG conference Ø Channel Development Strategies document at: http: //mis 105. mis. udel. edu/ja-sig/uportal/developers/channel_docs/ 3

Agenda Ø Initial comments Ø Adoption/Rejection of u. Portal Ø Review of channel types available Ø Environment variables Ø Supporting the strategy Ø Recruitment of channel developers Ø Conclusion 4

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 5

Analysis for Adoption Ø Is u. Portal 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? 6

Review of Channel Types Ø Image Ø Inline Frame Ø RSS (Generic. XSLT) Ø Web Proxy Ø Simple XML Transformation Ø Remote Channel Proxy Ø Custom (native) Ø Applet 7

Review of Channel Types Ø Image ü Simple ü Not very useful 8

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

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 u. Portal 10

Review of Channel Types Ø Web Proxy ü Converts well formed HTML into XML that can be rendered within u. Portal as a channel ü Existing web-based applications can be “portalized” with relative ease ü CPU intensive applications do no effect performance of u. Portal 11

Review of Channel Types Ø Simple XML Transformation ü Generic. XSLT ü Renders XML documents as channels ü Requires applications to speak HTTP 12

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 (http: //www-106. ibm. com/developerworks/webservices/library/ws-wsrp/) ü WSRP channel may replace RCP 13

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

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 15

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 directory? Authorization Central mechanism? Availability of coders and taggers. Java developers. HTML taggers. XML/XSLT knowledge? 16

Environmental Constraints § Project delivery date = Time § Customization of u. Portal = Customization § Budget § Small/Some/Limited § Medium § Large or Long 17

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 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

Support of the strategy Ø Authentication Why? • Channels such as Web Proxy and RSS (Generic. XSLT) 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 20

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=smb 1&password=XXXX) Custom HTTP Authorization Cookies 21

Support of the strategy Ø Local. Connection. Context. java package org. jasig. portal. security; import org. jasig. portal. Channel. Runtime. Data; import org. jasig. portal. Channel. Static. Data; public abstract class Local. Connection. Context { protected Channel. Static. Data static. Data; public void init (Channel. Static. Data sd) { static. Data = sd; } public String get. Descriptor(String descriptor, Channel. Runtime. Data rd) { return descriptor; } public void send. Local. Data(Object connection, Channel. Runtime. Data rd) { } } 22

Support of the strategy Ø Triggering Local. Connection. Context Channel parameter “upc_local. Conn. Context” edu. cornell. uportal. LCCImpl This class extends LCC 23

Support of the strategy ØCWeb. Proxy Presentation Sarah Arnott Andrew Draskoy Memorial University of Newfoundland Tuesday, June 10, 2003 1: 45 PM-2: 45 PM Standley I 24

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

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 u. Portal is required üRetention of hosting rights üOwnership of channel and content guaranteed 26

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 üIconsume a lot of real estate 27