Sakai-uPortal Assessment
Here is a compact assessment of how Sakai and uPortal could fit together. Comments are very welcome.
- Dave ()
Sakai-uPortal Assessment 1
1 Sakai Portal needs 3
1.1 Access to a Dynamic Portal Page Space 3
1.2 Enable Navigation within that Portal Page Space 3
1.3 Context-driven Display Processing 3
1.4 Context Aware Portlet Processing 4
1.5 Federate Data Sources 4
1.6 Understand / Generate Humane URLs 4
2 UPortal and Sakai 5
2.1 Access to a Dynamic Portal Page Space 5
2.2 Enable Navigation within the Portal Page Space 5
2.3 Context-driven Display Processing 5
2.4 Context Aware Portlet Processing 5
2.5 Federate Data Sources 5
2.6 Understand / generate humane URLs 5
3 Work to be done 7
3.1 Context driven data processing 7
3.1.1 Code base - uPortal 7
3.1.2 Code base - Sakai 7
3.2 Navigation in portal page space 7
3.2.1 Code base - UPortal 7
3.3 Humane URLs 7
1 Sakai Portal needs
What does Sakai need from a portal engine? Sakai requires some functionality that goes beyond the normally expected major functions (control of display and establishing an execution environment for portlets / channels) provided by a typical portal. This document seeks to expose these and to see what uPortal provides.
There are a couple of terms for which it would be good to provide up front definitions so that people can have a common starting ground.
Portal Page Space (PPS) - This the space of pages managed by the portal. It does not include external pages that are available by links from portal pages but that aren’t managed by the portal.
Page context – This is the defined location of the page in the PPS. The set of portal pages aren’t necessary arbitrary and unrelated. For example Spanish 101 and Spanish 101 / section C can both have separate pages and while the pages are separate they aren’t totally independent. Information about Spanish 101 is critical for the Spanish 101 / Section C page. At the very least the page for Section C shouldn’t be displaying information about Ancient Esperanto 203 Section G. Pages are often related and are viewed in a context of other pages. That context provides useful, even critical, information about what should appear on a page. This context need not extend to all pages in the portal but many applications (e.g. course management systems) will have natural relationships between pages. Those relationships are useful to know explicitly to support navigation and processing.
To be fully integrated in a portal Sakai will need to have a portal that supports the following abilities.
1.1 Access to a Dynamic Portal Page Space
The portal needs to be able to deal with a space of pages whose size and content are not known in advance and which, even for a single user, might encompass hundreds or thousands of different pages.
1.2 Enable Navigation within that Portal Page Space
The portal must be able to display the contextual location of the current page in the page space and must be able to present navigation links to related pages within the page space. The depth of navigation supported should not have arbitrary limits. The portal needs to able to administer the layout of the links. This goes beyond tree-based navigation as pages in the PPS can have multiple parents so the navigation is within a lattice.
1.3 Context-driven Display Processing
The portal needs to be able to have the layout / formatting of particular pages depend on the page being visited. Some pages may use an out-of-the-box portal layout with local skins while others will need to have Sakai layout with Sakai skins. Both must be available within the same portal.
1.4 Context Aware Portlet Processing
The portal needs to be able to supply portlets with information they can use to determine their context of execution. For example a chat portlet must be able to know that it is executing for a page representing Section C of the Spanish 101 in Ann Arbor. A different instance of the same portlet needs to know that it is in the context of the page for buying football season tickets.
1.5 Federate Data Sources
The portal needs to not assume that there is a single source of information for information it requires. For Sakai tools the information will come from Sakai services. For non-Sakai pages an enterprise database or a dedicated portal database might supply information. There is even the situation where a single page may have both Sakai based portlets and non-Sakai portlets: multiple sources may be needed even for a single page. The same federation concern that applies to layout and content issues will also apply to authentication and authorization.
1.6 Understand / Generate Humane URLs
It must be possible for a user to navigate in the portal via URLs that make sense. As a rule of thumb it should be possible to read the URL over the phone (say for tech support purposes). It should be possible for a user to make reasonable guesses about what the URL for particular information should be. If you know the URL for Spanish 101 you should at least have a chance to figure out the URL for Spanish 201.
2 UPortal and Sakai
This section assesses how the current uPortal implementation and the Sakai needs align.
2.1 Access to a Dynamic Portal Page Space
There is currently a uPortal assumption that the entire layout for a user can be processed at login and kept during the current session. The version of uPortal adapted for Sakai has some proof of concept code that shows that it is possible to implement incremental (and therefore context dependent) loading of the portal pages. It is not natively supported in uPortal.
2.2 Enable Navigation within the Portal Page Space
UPortal currently has single level navigation. There is an expressed intension to produce tree navigation. The sakai-uPortal version has demonstrated that dynamic multi-level navigation is possible. However this is a limited implementation and does not handle the general case of multiple level links. It does not handle the administration of links either. Given that the PPS is dynamic the link management will also need to be dynamic: the full set of links will not be available a-priori.
2.3 Context-driven Display Processing
The ability to pick up different layout managers and data sources is not available in the base uPortal code. This functionality will require re-examining a fundamental assumption in the uPortal code that the processing methods will be the same once they are established. On the other hand the uPortal code has many examples of deferring processing to a configurable implementation. Page layout functionality in uPortal is configurable by instance but doesn’t vary within a single session. For Sakai the layout manager and data sources will need to vary on a page-by-page basis.
2.4 Context Aware Portlet Processing
Current uPortal channels can get both static and runtime parameters to customize their processing. The mapping of this to location in the PPS and the methods for doing this with JSR 168 portlets still need examination. It is also not clear what would be the appropriate implementation for expressing the context.
2.5 Federate Data Sources
uPortal has some support for federated authentication and authorization. It does not support multiple sources for layout, content, and navigation information.
2.6 Understand / generate humane URLs
UPortal URLs are tailored to the needs of the portal and are not friendly to people. It will be reasonable for some portal URLs to be tailored to portal purposes provided that people would have no reason to type in that URL. However navigation within the portal needs to be possible with understandable URLs. It should be possible to go directly to a known page without having to navigate there by clicking on portal pages. This approach is not supported within uPortal currently.
3 Work to be done
The list of potential tasks below is meant as a Strawman starting point for discussing what work would need to happen to support uPortal Sakai cooperation. It will undergo significant revision. Obviously without final designs a fixed task list isn’t feasible.
The tasks are divided into related functional areas. There is an attempt to indicate whether the Sakai or uPortal code base is involved in particular functions. That will change as designs are fleshed out.
3.1 Context driven data processing
This requires that uPortal abstract out the coordination of processing from the actual data processing. As the context of processing varies the sources of data and the processing rules may change. This does not change the central coordination functions of the uPortal kernel; it does require the flexible and dynamic delegation of processing.
It may be possible for uPortal to delegate much of the implementation of managing context to external code built specifically for hierarchy management. UPortal would need to be set up to consult this external source when it needs context al information.
3.1.1 Code base - uPortal
· Add abstraction level so that page processing is delegated for each page.
· Abstract out dependencies on implementation.
· Add framework for data source federation.
· Supply portlet with current context upon invocation.
· Consult data sources to obtain specific layout / processing implementations.
3.1.2 Code base - Sakai
· Implement hierarchy management system that will manage the lifecycle of nodes with locations, links to parents and children, and the ability to store arbitrary data.
3.2 Navigation in portal page space
This work involves changes to uPortal presentation to make explicit the navigation links in the PPS.
3.2.1 Code base - UPortal
· Record the current location in the PPS
· Display navigation links to the children (and possibly parents) of the current location.
· Administer the layout of the links.
3.3 Humane URLs
If the responsibility to deal with these URLs is built into uPortal this may require significant work. If the task of using humane URLs is approached by using a translation service then less work would be required in uPortal. Since the approaches of having uPortal handle translation and having an external translation mechanism are so different it is premature to have any listing of tasks.
David Haines Page 8 8/11/04