uPortal Sakai Integration

About this page

This page is for outlining modules of integration, nuggets of integration goodness to be accomplished, and providing links to information about and a summary of progress on these goals.

Infrastructure and administrivia

Resources for uPortal-Sakai integration efforts.

SEPP Portal Discussion Group

Sakai / SEPP uses a "Discussion Group" concept to organize its community. There's a DG for Portal integration. It's named "Portal" and it's available on the SEPP Sakai instance.

Email list

An email list comes along with the SEPP Portal DG. You'll first need to join the DG to email it.

Email list archive

The email list archive is available via the Collab Sakai instance. However, the email archive isn't Googleable and it isn't easy to hyperlink to its messages. There's room for improvement in the email archive capabilities for this.

JSR-168s accessing Sakai SOAP services

Sakai can expose interesting SOAP. Interesting JSR-168s could consume that soap to provide Sakai-powered user experiences in portals.

Basic Portlet linking to Sakai content

JSR-168 that consumes Sakai Web Services to produce a tree control to provide links into Sakai. Status: basically no progress.

Portlet rendering Sakai content

JSR-168 that consumes Sakai Web Services to produce a Sakai-like user experience right inside the portla. Status: excellent progress by Dr. Chuck. You may even regard this as immediately deployable.

uPortal Layouts reflecting Sakai sites

uPortal 2 ILayoutManager implementation

A uPortal2 ILayoutManager implementation that consumes Sakai SOAP to generate the layout. The generated layout might be more or less sophisticated (channels that are IFrames pointed at Sakai, channels that are WSRP consumers for the WSRP productions corresponding to the content, etc).

uPortal 3 LayoutManager implementation

A uPortal 3 layout manager implementation that consumes Sakai SOAP to generate the layout. The generated layout might be more or less sophisticated (channels that are IFrames pointed at Sakai, channels that are WSRP consumers for the WSRP productions corresponding to the content, etc).

nested tabs structure/theme/skin

A nested tabs structure/theme/skin for uPortal so that uP can emulate Sakai navigation of sites across top as big tabs, pages within site as small tabs down the left column, content in a center pane (which can consist of one or more channels).

Sakai content available via WSRP in uPortal

uPortal consumes WSRP producers hosted by the Sakai deployment.

Infrastructure in support of WSRP in uPortal

demo WSRP producers to point uPortal WSRP consumers at for testing

demo WSRP consumers to point at uPortal WSRP producers at for testing

uPortal 3 enhanced consumer

Writing the consumer

It's written.

Testing against Sakai

This consumer needs to be tested against Sakai-produced WSRP.

uPortal 2 WSRP4J ProxyPortlet consumer

Writing the consumer

It's written and included in uPortal 2.x. It's just a thin wrapper around the WSRP4J ProxyPortlet.

Testing against Sakai

This consumer needs to be tested against Sakai-produced WSRP.

Porting the uP 3 enhanced WSRP consumer to uP2

Can the uP3 enhanced WSRP consumer code be made to run in uP 2? Should it? Would this be a quick path to getting this code out into the community where it can begin to be used and fire tested and so forth?

Sakai content available via WSRP

uPortal WSRP consumers won't be much use without Sakai WSRP to consume. What tools will be available via WSRSP when?

Sakai tools available via WSRP in Sakai 2.1

Exactly what tools will be available via WSRP in Sakai 2.1?

Sakai content subscribable in uPortal

Channels from Sakai

End user is customizing her layout and edits a tab and goes to add a channel to this tab. In the content chooser UI, the end user can see channels published in uPortal and available to her, and can also see channels representing Sakai tools in the context of particular Sakai sites available to her. As in, a user might add the Weather Channel to her custom tab, she might also add the Sakai Discussion Tool for EE 101. End user can produce a tab consisting of some Sakai content and some uPortal content.

Implementation is presumably a plugin to the ChannelManager component in uPortal.

Fragments from Sakai

End user is customizing her layout and wants to pull a fragment. In the content chooser UI, the end user can see fragments published in uPortal and available to her, and can also see fragments representing Sakai sites available to her. As in, a user might add the "Dining at Yale" tab to her layout, and she might also add the "EE 101" Sakai site as a uPortal fragment, with uPortal rendering the various pages of this site.

Sakai tools providing integration opportunities

Syndicated Sakai Content

Some Sakai content would be suitable for RSS syndication.

Deep links into Sakai

To the extent that Sakai tools support deep links (links not only to Sakai itself, not only to a particular Sakai site, not only to a particular Sakai site page, but a link into a tool in a site with the particular context of looking at something in particular, then they support more integration opportunities (links from other sites into particular content). For instance, a Sakai email archive tool that supports linking to a particular archived email message allows referencing a particular email from a Wiki page. Or from a portal.

Running Sakai Tools natively in JSR-168 portlets

Running the Sakai Kernel in the context of a JSR-168

Sakai tools rely upon the kernel. Need a lightweight version of the kernel to run in a JSR-168 to support a JSR-168 adaptor to a Sakai tool.

JSR-168 adaptor for Sakai tools

An adaptor that emulates the Sakai framework to support running a single Sakai tool in a JSR-168. Take an interesting Sakai tool (chat). Stick it into this adaptor (a JSR-168). Publish it into uPortal. Viola! A Chat portlet in uPortal. Ideally, would reduce reduplication of effort in producing JSR-168s and also producing Sakai tools.

Running IChannels / JSR-168s / WSRP in Sakai Tools

IChannels adapted to be Sakai tools

Adapting uPortal channels / portlets to be Sakai tools, getting an IChannel to run in Sakai / be aware of Sakai context. Thereby combatting duplication of effort between Sakai implementations and uPortal implementations of things like Announcements. Does this make any sense?

JSR-168 portlets adapted to be Sakai tools

Adapting JSR-168 portlets to be Sakai tools, getting a JSR-168 to run in Sakai / be aware of Sakai context. Thereby combatting duplication of effort between Sakai implementations and uPortal implementations of things like Announcements. Does this make any sense?

WSRP adapted to be Sakai tools

A Sakai tool that consumes WSRP. Anything available over WSRP can be a degenerate "tool" available in a site in Sakai. Does this make any sense?

Backing service integration

Groups and Permissions

uPortal Groups and Permissions Refactoring

While not directly related to integration, Dan Ellentuck et al.'s efforts on GAPs Springification should make the other projects here much easier.

uPortal backed by Sakai services

Sakai-backed GroupsService implementation

A uPortal GroupService implementation that consumes Sakai SOAP and makes Sakai groups available in uPortal. Becomes possible to publish a uPortal channel to a particular Sakai group. Or for uPortal channels to predicate their behavior upon Sakai groups. Or for administrators to browse the Sakai groups in the uPortal GroupsManager. Etc.

Sakai-backed Permission service implementation

A uPortal Permission service implementation that consumes Sakai SOAP and makes Sakai permissions available in uPortal. Becomes possible for uPortal channels to predicate their behavior on Sakai-configured permissions.

Sakai-backed IPersonAttributeDao implementation

A uPortal IPersonAttributeDao implementation that consumes Sakai SOAP and makes the Sakai person directory available in uPortal. (Maybe this just isn't needed).

Sakai backed by uPortal services

Backing Sakai user attribute acquisition with an IPersonAttributeDao

Adaptor from uPortal person attribute acquisition APIs to Sakai APIs.

Backing Sakai group memebership on uPortal GAPs.

Adaptor from uPortal GAPs to Sakai groups. Result is ability to define Sakai site membership, etc. in terms of uPortal groups.

Skinning

Skinning uPortal to make it look like something Sakai would want to integrate with

A uPortal skin that looks like the default Sakai Skin would ease some kinds of integration (IFrames, etc.)

Footnotes

Icon key

This page commits the Wiki sin of using a Wiki page for issue tracking. It may be forgivable as this page is intended to be very high-level and summary - it should link out to more detail, real issues as appropriate. Or maybe we'll drop this page in favor of something better. Meanwhile, trying to get a level set...