Charles Severance-Sakai and Portals.pptVIP

Sakai and Portals Charles Severance Portals and Portlets Workshop July 2006 Outline History Sakai and JSR-168 Sakai and WSRP Sakai and JSR-168 (part 2) Going Forward JSR-168 portlets WSRP / uPortal UNISA’s Work Sakai and RSS Sakai’s internal JSR-168 This is a moving target and it has been a challenge to find dedicated resources for this portal/portlet work History - Sakai and JSR-168 What we hoped in 2003 Sakai’s presentation layer *would* be JSR-168 Using JSR-168 would make Sakai tools portable between JSR-168 compliant portal containers Sakai tools would just “be portlets” which would work in any portal What happened As a standard, JSR-168 was just too small and basic to support Sakai’s requirements in critical areas Navigation Cross-portlet context Support for “services” that work across portlet How we reacted Look into WSRP and see if we could solve the problems using two JVMs (one for the Portal and one for Sakai) History - Sakai and WSRP 1.0 What we hoped By separating the problem into two JVMs across WSRP Sakai could provide our tools all the support we needed and just move markup back and forth. What happened We built a tightly integrated WSRP producer in Sakai 2.1 WSRP provisioning is very poor - does not meet user requirements - perhaps this is just a limitation of how portal writers architect simple WSRP consumers - but it is reality WSRP interoperability is poor between containers Dual provisioning does not make administrators happy How we reacted Wrote the JSR-168 Sakai proxy portlets Sakai WSRP Alpha quality consumer from Daresbury Alpha quality producer from SunGard Sakai has a “sakai.fragment” - indicates body only response, and delegated URLs Not all tools - velocity tools work best CSS is still Sakai’s CSS Provisioning is weak - must look at Sakai tool placement GUIDs and construct handles High Level Architecture Sakai Tools in uPortal 2.4.2 Announcement Tool (Mercury Context) in LIFERAY Portal History - Sakai and 168 (v2) What we hoped Provide a