Building Portable Portlets that work in Sakai and uPortal

1. Building Portable Portlets that work in Sakai and uPortal Charles Severance JA-Sig Meeting Denver, CO - June 25, 2007

2. Sakai in one Slide.... • Collaboration, Teaching, and Learning • FOSS - 100% free to use, modify and contribute • Sakai is 3 years old • Non-profit Sakai Foundation January 2006 • Financial support from 100+ Higher Education, 15 companies • Six paid staff members • 100+ people developing and testing Sakai releases Overview Video: http://www.dr-chuck.com/media.php?id=64

3. Outline • Sakai’s JSR-168 Implementation • Developing JSR-168 Portlets in Sakai • Current Sakai Portlets Under Development • My ToDo list of Portlets • Dimensions of Portlet Portability • Open Issues / Discussion

4. Sakai’s JSR-168 Implementation

5. Sakai Implementation • Preferences • Require Sakai site.upd permission to change • Uses Sakai’s preferences as persistence • Portlets can view Sakai preferences (sakai:) • Edit button only appears for users with “site.upd” • In My Workspace - the person who owns the home directory has site.upd • isUserInRole can access any Sakai permission - site.upd, content.read, etc.

6. Developing Portlets in Sakai

7. Documentation • https://source.sakaiproject.org/svn//reference/trunk/docs/architecture/sakai-168-portlet-tool.doc • https://source.sakaiproject.org/svn//reference/trunk/docs/architecture/sakai-168-portlets.doc

8. When to Use JSR-168 in Sakai • When you don’t want an iFrame • When your persistence needs are easily modeled by per-placement preferences • When your functionality may be reused outside of Sakai • It is OK to write a very Sakai-specific Portlet - just understand it is not portable

9. JSR-168 Candidates • iFrame • Web-Proxy • RSS Reader • WSRP Consumer • Thin Shim on top of Web Services • IMAP Client • The portlet can be a lot of code and relatively complex - but it needs to be self-contained.

10. portlet.xml and web.xml • Exactly the same as Pluto 1.1 - allows binary war distribution and webapp drop-in

11. Sakai Implementation • Hot deploy of a war into webapps - just drop it in - auto registration • Hot re-deploy of a war into running Sakai • Recompile • Watch re-registration - hit refresh

12. Tool Registration • Sakai Tool registration is derived from the portlet.xml • Sakai tool registration file in the war file • webapps/iframe-portlet/WEB-INF/sakai/SakaiIFrame.xml • Sakai tool registration - in Sakai’s config area • ${sakai.home}/portlets/iframe-portlet/SakaiIFrame.xml • ${sakai.home}/portlets/SakaiIFrame.xml

13. <?xml version="1.0"?> <registration> <tool id="sakai.iframe.168" title="Web 168" description="For accessing an external website within the site."> <configuration name="source" value="" /> <configuration name="height" value="600px" /> <category name="course" /> <category name="project" /> <category name="portfolio" /> <category name="myworkspace" /> <configuration name="functions.require" /> </tool> </registration>

14. Sakai.properties You can control the behavior of portlet auto-registration by setting the following property in your sakai.properties. The key is whether tools are registered fully or stealthed. # Configure Sakai's JSR-168 Portlet Support # Valid values are # all - Register all portlets, checking for tool registrations - all # portlets appear in Site Setup(i.e. none stealthed) # stealth - If there is no tool registration found register the tool # as stealth (i.e. does not show up in Site Setup) portlet.support=all

15. Summary of 168 in Sakai • Designed to be trivial and simple out of the box - easier to configure than Pluto 1.1 itself • Permissions and preferences - wired to be Sakai-like with no changes to portlet • Drop in registration • Hot Deploy / Re-Deploy • Flexible and *optional* configuration to give tool developer more control over Sakai tool registration - equivalent to Sakai TPP tools

16. Portlets In Development

17. Portable Portlets • IMS Tool Interoperability 1.0 • Sakai Launch Portlet • iFrame Portlet • JSR-168 Test Portlet • https://source.sakaiproject.org/contrib/portlets

18. TI Portlet

19. 7 5 6 2 1 3 4 IMS TI Outcome Request Sakai IMS Proxy Session And Services Bootstrap Sakai APIs Application Code Sakai Samigo, ConceptTutor, Etc Sakai Blackboard WebCT Angel How IMS Tool Interoperability Works LMS System Outcome External Tool Launch

20. Sakai Launcher Sakai Launch View

21. How Tree/Gallery/Launch View Works Charon Portal /portal/page/FF96 Sakai uPortal, Pluto, or GridSphere ToolList Sakai Portlet Web Svcs Login

22. SakaiSite.getToolsDom <sites> <portal>http://localhost:8080/portal</portal> <server>http://localhost:8080</server> <gallery>http://localhost:8080/gallery</gallery> <site> <title>My Workspace</title> <id>~csev</id> <url>http://localhost:8080/portal/worksite/~csev</url> <pages> <page> <id>af54f077-42d8-4922-80e3-59c158af2a9a</id> <title>Home</title> <url>http://localhost:8080/portal/page/af54f077-42d8-4922-80e3-59c158af2a9a</url> <tools> <tool> <id>b7b19ad1-9053-4826-00f0-3a964cd20f77</id> <title>Message of the Day</title> <toolid>sakai.motd</toolid> <url>http://localhost:8080/portal/tool/b7b19ad1-9053-4826-00f0-3a964cd20f77</url> </tool> <tool> <id>85971b6b-e74e-40eb-80cb-93058368813c</id> <title>My Workspace Information</title> <toolid>sakai.iframe.myworkspace</toolid> <url>http://localhost:8080/portal/tool/85971b6b-e74e-40eb-80cb-93058368813c</url> </tool> </tools> </page> </pages> </site> </sites>

23. iFrame Portlet

25. Portlets I Want to Write

26. Dream Portlets • Portable Portlets • Proxy Portlet from uP3 • Bridge Portlet • WSRP Consumer Portlet • Del.icio.us Portlet • Flikr Portlet • Sakai Only Portlets • Site Hierarchy Tool • Complete iFrame Tool Replacement

27. JSR-168 Portability Issues

28. Three levels of Portable • Completely portable, self-contained war, runs in any compliant container • Virtually unportable - war has significant framework dependencies - that are to be provided by the “portal” • Sort-of portable - war has a set of clear pre-agreed dependencies to be provided by the portal

29. “Perfect” Portability • Differences with userinfo structures between portal implementations - Pluto 1.1 helps a little bit here (Gridsphere) • Differences between isUserInRole • we need a convention here • portlet.xml and security mapping can help • Preferences semantics and the edit button - we just have to write very clean code and check errors carefully

30. Sort-of Portable • We create agreement between Sakai and uP3 that certain framework elements can be assumed between the systems. • This makes a class of portlets that work in Sakai or uP3 but not other containers • We should encourage other containers to join our “JSR-168” container consortium. • The APIs should probably not be “Sakai” or uP3 branded APIs to enhance broad adoption.

31. Discussion Questions

32. Questions • How can 168/286 CSS be improved? Can we speak as one voice - can we add compatibility now? • Can we agree no a few isUserInRole strings between uP3 and Sakai? • Do we want to create a zone of “Sort of Portablility” between Sakai and uPortal where we agree that some bits of framework can be assumed between the systems? • If so, how does that work? What API’s? How to solve shared/war issues? Who is interested in this? • How do we develop/distribute shared portlets?