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 PortalsChalk Talk:School of Portals

OGCE 1.1OGCE 1.1

XCATXCAT

NEES 3.0NEES 3.0

GridPortGridPort

NEES 1.1NEES 1.1

GridPort 3GridPort 3

SakaiSakai

uPortaluPortal

CHEFCHEF OGCE 1.2 ?OGCE 1.2 ?

OGCE 2OGCE 2JetspeedJetspeed

AllianceAlliance

GridPort 2GridPort 2

NEES 4.0NEES 4.0

CompetitionCompetition CollaborationCollaboration ConvergenceConvergence

GridSphereGridSphere

Current Status

• Sakai Educational Partners Meeting - June 04 - 200 attendees - 40 members

• Sakai 1.0 - Beta June - Release Sept– In production at UM 10K 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 uPortal - leads to re-evaluation of 168

Initial Design Plan (10/2003)

• The original design was to use JSR168 and modify uPortal to meet the navigational needs of Sakai

• Sakai would only have full functionality in uPortal (see the historical slide on the following page)

Note - Part of the 11/2003 design mistakenly assumed that uPortal *already* supported multi-level hierarchy and the management of pushed fragments in uPortal 2.2 - this was Chuck’s error back in late 2003.

The Big Picture of The FuturePortal Technology

(e.g., JetSpeed, WebSphere, SunOne…)Portlet Aggregation

Portal NavigationPortal Configuration

PortalConfiguration

Implementations(need examples)

CHEF 1.X Teamlets

uPortal Channels

CHEF Services

Portlet Technology (JSR-168 / Jakarta - Pluto)

OKI Services

Teamlet iChannel

StellarModules

OtherServices

StellLet

JSR-168 Portlets

Portable code

Non-portable code

Choices to be made

Portal and site service implementation specific to the chosen portal technology (eg, chef/js, chef/ws…)

12/2003

Recent Activities

• As part of the Sakai 1.0 effort, modifications were made to uPortal to handle two level navigation and pushed fragments

• This work was completed and identified needed modifications to uPortal 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 uPortal

• 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 uPortal with

locally built and supported non-standard 168 extensions

– We must immediately begin work on the needed uPortal 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– uPortal already is in the process of adding WSRP support - we may find problems

as we explore WSRP but the code modifications would simply be uPortal bug-fixes and help uPortal along the path to WSRP compliance

– We work equivalently in all WSRP compliant portals

• Risks in this approach– WSRP4J may not be ready for prime time - but it is already in uPortal– 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/sp04/eecs/280 The entire page pre-navigated to the EECS280 site– /site/sp04/eecs/280/sakai.chat The entire page pre-navigated to the chat in EECS280– /app - the Sakai page minus the top bar (no logo, no login) - includes the top site

tabs– /app/sp04/eecs/280 - The EECS 280 Spring 2004 site (buttons on left and tool

space) no logo, login nor site tabs– /app/sp04/eecs/280/sakai.chat The chat tool in the EECS280 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 iFrame portlets work best when the portal and sakai share single-signon although Sakai will support in-window authentication via redirect within the iframe

http://sakai.edu/ and http://sakai.edu/site

http://sakai.edu/apphttp://sakai.edu/app/sp04/eecs/280/

http://sakai.edu/app/sp04/eecs/280/sakai.chat

Serving Concentric Rectangles

Sakai

tool tool tool

/site servlet

JSF JSF JSF Vel

legacytool

/app servlet WSRP4J servlet

HTTP

Direct viewingIn a browser

HTTP

Portal

iFrame andSingle-sign-on

WSRP

Portal

WSRP in portal

Sakai

tool tool

HTTP

WSRP

Portal

Sakai

tool tool

HTTP

Sakai

tool tool

HTTP

Non-Sakai Non-Java Tools

tool toolW

SR

P

Non-SakaiTool

WSRP WSRP

The “New” Big Picture (9/04) *

* There may be a surprise or two along this path as well.

Sakai

tool tool

HTTP

Non-Sakai Non-Java Tools

tool tool

WSRP

Portal

Non-SakaiTool

WSRP

Integration Architecture

OKIOSIDs

OSIDs OSIDs

Enterprise Information

Recommendations w.r.t uPortal

• I suggested the following to the uPortal team at their Developer Retreat in Boston 8/30/04– Make uPortal aware that we will be working with the

WSRP implementation in uPortal and ask for any guidance they might have in that effort based on their experiences with WSRP to date

– Suggest that uPortal 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 uPortal/Tomcat

• We do three things short-term– Have one container which is Gridized and WSRPized (recommendation: uPortal)– 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 uPortal - 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 VelocityPortlet 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 uPortal 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 iFrame 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.