Quantcast

Sakai: Powered by uPortal?

[Single Mind Consulting – Summary of Sakai](href=”http://www.singlemindconsulting.com/files/white_sakai_described_v1.pdf)

> Furthermore, Sakai is designed as a series of independent tools built upon a
robust, standards-based framework (uPortal).

> ``

> Sakai’s uPortal is a powerful portal environment
that utilizes the portlet specification to ensure interoperability.

This particular perception – that Sakai contains an embedded uPortal instance which it uses to do the aggregation of tools and services is not correct — (though it’s understandable given historical context — see below). Sakai actually includes a custom developed portal engine “Charon” which is used to handle site aggregation and display. In the 2.4 branch, Charon has some preliminary integration with Pluto 1.1 to handle rendering JSR-168 portlets. While this is the same approach taken by uPortal, the integrations don’t share implementation details beyond the common adoption of the Pluto portlet driver.

The original Sakai vision (I wasn’t involved at the time — this is just my perception/understanding) was for Sakai to **just** produce a collection of instructional tools. The uPortal angle is that the tools were going to be implemented as JSR-168 portlets, with some framework-style glue to support integration and common functionality, but leveraging the portlet spec to provide isolation, separation, and markup aggregation.

This plan resulted in discussion about partnership, and resulted in a portion of the initial Sakai Mellon grant being allocated to uPortal for development of the PortletAdaptor for uPortal 2.x, as well as creation of uPortal 3 — a rewrite of the uPortal framework intended to enhance/provide native JSR-168 portlet support.

During the course of development of both projects (Sakai & uPortal 3) however, delivery pressures and emerging understanding of the needs of both camps caused development efforts to drift apart. As a result, Sakai 1.0 shipped with a custom portal which I believe was a derivative of CHEF’s portal infrastructure (based on JetSpeed1?). As Sakai has evolved, a number of Sakai-specific metaphors like site-membership have been introduced, further splitting the functionality of Sakai and uPortal.

Currently efforts are focused more on integration between Portals and Sakai. Chuck Severance has done a large amount of work on summary views and other proof-of-concept exercises, and Sakai 2.4 ships with an enhanced Charon portal which supports alternate views like RSS which are intended to aid integration.

Hope this helps clear things up…

Tags: