Sakai Portal Integration Charles Severance September 9 2004
Sakai / Portal Integration Charles Severance September 9, 2004 Not all those who wander are lost. J. R. R. Tolkien, The Fellowship of the Ring
Chalk Talk: School of Portals NEES 1. 1 NEES 3. 0 NEES 4. 0 OGCE 1. 2 ? CHEF OGCE 1. 1 Jetspeed OGCE 2 Sakai Grid. Port 2 Grid. Port 3 Grid. Port XCAT Competition Alliance u. Portal Collaboration Grid. Sphere Convergence
Current Status • Sakai Educational Partners Meeting - June 04 200 attendees - 40 members • Sakai 1. 0 - Beta June - Release Sept – In production at UM 10 K users – In production pilot IU – Very small pilot Stanford • Distributed development of 2. 0 begins Sept (3 months late) • Sakai-Grid component pre-Alpha Aug
Problems Along the Way • Sakai Educational Partners wasted about 2 months of our focus • IU, Stanford, and MIT evaluated CHEF and wanted to save it rather than throw it away • Sakai Board pressed for Sakai to work beyond u. Portal - leads to re-evaluation of 168
Initial Design Plan (10/2003) • The original design was to use JSR 168 and modify u. Portal to meet the navigational needs of Sakai • Sakai would only have full functionality in u. Portal (see the historical slide on the following page) Note - Part of the 11/2003 design mistakenly assumed that u. Portal *already* supported multilevel hierarchy and the management of pushed fragments in u. Portal 2. 2 - this was Chuck’s error back in late 2003.
The Big Picture of The Future Portal Configuration Implementations (need examples) Portal and site service implementation specific to the chosen portal technology (eg, chef/js, chef/ws…) Non-portable code Portal Technology (e. g. , Jet. Speed, Web. Sphere, Sun. One…) Portlet Aggregation Portal Navigation Portal Configuration Portlet Technology (JSR-168 / Jakarta - Pluto) Teamlet i. Channel Stell. Let CHEF 1. X Teamlets u. Portal Channels Stellar Modules JSR-168 Portlets Choices to be made Portable code 12/2003 CHEF Services OKI Services Other Services
Recent Activities • As part of the Sakai 1. 0 effort, modifications were made to u. Portal to handle two level navigation and pushed fragments • This work was completed and identified needed modifications to u. Portal to fulfill the original vision - (See the David Haines document for more detail) – Support for dynamic very large layouts – Support for layout information from plug-in source – Support for providing a portlet awareness its placement in the navigational hierarchy – Ability to manage multilevel hierarchies – A need for humanly readable URLs
Additional Information • As we interacted with the SEPP two important messages emerged – There is a large need to integrate non-Java applications into “Sakai” – There is a need for a web-services approach rather than the one-JVM approach – There is a need for Sakai to function fully in portals beyond just u. Portal • Tools Team Style Guide – A direction has been set regarding the general look, feel and layout of navigation. • Technical and Performance – Moving from a single web-app to multiple webapps in a servlet container means that there is increased likely hood of a jar conflict in shared/lib or common/lib between, Sakai, the portal, and other portlets. – As we increase the dependency on features in the latest versions of Tomcat, we begin to make it more difficult to drop into just any servlet container. – As we have done performance tuning, we have found that different elements of code running in the JVM can have significant performance impacts on one another. This is the nature of Java application tuning.
Summary • If we stick with the current course – We will be fully functional only in u. Portal with locally built and supported non-standard 168 extensions – We must immediately begin work on the needed u. Portal modifications to meet out timeline
Alternative Approach • Change the priorities from “JSR-168 first” to “WSRP first”. – We spend the next 3 months implementing WSRP in Sakai as described in the following slides – The URL convention described in this document is a big part of the change and is what makes this feasible. – At that point we have WSRP in time for the 1. 5 release or we fully understand the challenges and flaws with WSRP – Understand that WSRP is effectively the “Web-Service version of JSR-168” • Advantages of this approach – u. Portal already is in the process of adding WSRP support - we may find problems as we explore WSRP but the code modifications would simply be u. Portal bug-fixes and help u. Portal along the path to WSRP compliance – We work equivalently in all WSRP compliant portals • Risks in this approach – WSRP 4 J may not be ready for prime time - but it is already in u. Portal – WS-Security support in WSRP must be there and transmit identity
Design Details • We change Sakai to support a set of URL patterns which reflect the hierarchy of the sites within a Sakai instance – – / or /site - The entire page including top logo and login /site/sp 04/eecs/280 The entire page pre-navigated to the EECS 280 site /site/sp 04/eecs/280/sakai. chat The entire page pre-navigated to the chat in EECS 280 /app - the Sakai page minus the top bar (no logo, no login) - includes the top site tabs – /app/sp 04/eecs/280 - The EECS 280 Spring 2004 site (buttons on left and tool space) no logo, login nor site tabs – /app/sp 04/eecs/280/sakai. chat The chat tool in the EECS 280 Spring 2004 site with no other navigation • • These patterns are available through both as http URLs and WSRP web-service handles When using http, the /app and i. Frame portlets work best when the portal and sakai share single-signon although Sakai will support in-window authentication via redirect within the iframe
Serving Concentric Rectangles http: //sakai. edu/ and http: //sakai. edu/site http: //sakai. edu/app/sp 04/eecs/280/sakai. chat http: //sakai. edu/app/sp 04/eecs/280/ http: //sakai. edu/app
i. Frame and Single-sign-on Direct viewing In a browser Portal HTTP WSRP /site servlet /app servlet WSRP 4 J servlet JSF tool Sakai WSRP in portal JSF tool JSF Vel tool legacy tool
The “New” Big Picture (9/04) * Portal tool WSRP tool Non-Sakai Tool Non-Sakai Non-Java Tools WSRP Sakai P WSR HTTP tool WSRP tool HTTP tool Sakai * There may be a surprise or two along this path as well. tool Sakai tool
Integration Architecture Portal Non-Sakai Tool tool Non-Sakai Non-Java Tools HTTP WSRP OKI OSIDs tool Sakai OSIDs Enterprise Information
Recommendations w. r. t u. Portal • I suggested the following to the u. Portal team at their Developer Retreat in Boston 8/30/04 – Make u. Portal aware that we will be working with the WSRP implementation in u. Portal and ask for any guidance they might have in that effort based on their experiences with WSRP to date – Suggest that u. Portal begin to look into implementing plug-in callouts for Users and Groups based on the OKI AUTHN and AUTHZ OSIDs and design the plugin architecture so that multiple plug-in can be supported. Also the plug-in support should be architected so as to allow for multiple out-of-band agreements.
Recommendations w. r. t. OGCE • Adopt a container and portal and accept it – Suggest u. Portal/Tomcat • We do three things short-term – Have one container which is Gridized and WSRPized (recommendation: u. Portal) – Have a few simple portlets (recommendation: JSR-168/propext, Proxy, FTP, etc) – Have some big applications which interact via Gridized WSRP (GPIR, Sakai) these are a large collection of “instanced Portlets” • • Help u. Portal - become WSRP producer from 168 - it will be cool thing and make our little 168 portlets far more useful. Compatibility – Sakai can handle legacy CHEF stuff for a long time – We have 60% of a Velocity. Portlet Servlet (not portlet) wrapper… • • We may have several Tomcats in our out of the box experience for a while P. S. Maven is not so bad…
Conclusion • Making this shift improves a number of things – – – Control of our own destiny in areas like URL conventions No need to fire up large u. Portal development effort Uniform support of WSRP portals (includes Microsoft) Allows natural federation of Sakai sites using portals HTTP will work right away so Portals can use i. Frame portlets and single sign on as soon as a few weeks – Eliminates technical and performance conflicts of being in the same JVM and servlet container – Allows separate scaling of the Sakai servers and portal servers – We have an excellent story for the non-Java tools - WSRP has an extensive extension mechanism (JSR-168 is not extendible in a standard way) and we could begin to pass extra information like site membership and role information across WSRP in time • Because WSRP and JSR-168 are designed to work together, we can revisit JSR -168 later when we have WSRP completed and much of our WSRP work will be directly applicable in a JSR-168 context.
- Slides: 19