1. Sakai / Portal Integration
Charles Severance
August 25, 2004
Not all those who wander are lost.
J.R.R. Tolkien, The Fellowship of the Ring

2. 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 this was Chuck’s error back in late 2003.

3. The Big Picture of The Future
Portal
Configuration
Implementations
(need examples)
Portal Technology
(e.g., JetSpeed, WebSphere, SunOne…)
Portlet Aggregation
Portal Navigation
Portal Configuration
Portlet Technology (JSR-168 / Jakarta - Pluto)
Portal and site service implementation specific to the chosen portal technology (eg, chef/js, chef/ws…)
Teamlet
iChannel
StellLet
CHEF 1.X
Teamlets
uPortal
Channels
Stellar
Modules
JSR-168
Portlets
Non-portable code
Choices to be made
Portable code
CHEF
Services
OKI
Services
Other
Services
12/2003

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

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

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

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

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

9. Serving Concentric Rectangles
and

10. HTTP HTTP WSRP Sakai /site servlet /app servlet WSRP4J servlet JSF JSF
Portal
iFrame and
Single-sign-on
HTTP
Direct viewing
In a browser
WSRP
Portal
WSRP in portal
Sakai
/site servlet
/app servlet
WSRP4J servlet
JSF
JSF
JSF
Vel
tool
tool
tool
legacy
tool

11. The “New” Big Picture (9/04) *
Portal
Non-Sakai
Tool
Non-Sakai
Non-Java Tools
tool
tool
WSRP
WSRP
WSRP
WSRP
HTTP
HTTP
HTTP
Sakai
Sakai
Sakai
tool
tool
tool
tool
tool
tool
* There may be a surprise or two along this path as well.

12. Integration Architecture
Portal
Non-Sakai
Tool
OKI
OSIDs
WSRP
WSRP
HTTP
Sakai
Non-Sakai
Non-Java Tools
tool
tool
tool
tool
OSIDs
OSIDs
Enterprise Information

13. Recommendations w.r.t uPortal
If this plan is accepted, then I would communicate the following to the uPortal team:
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.

14. 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 servelt 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.

15. Risks I have thought of WSRP4J is incubator status
Counter - it has been in uPortal for nearly a year
Depth of support for WS-Secure in WSRP4J is unknown (i.e. I have not yet investigated)
This should be easy to evaluate (< 1 week) by simply installing, and getting wsrp4j to work on someone’s workstation - is WS-Secure support is weak then we know what our first development task will be