uPortal-Sakai integration

JA-SIG Winter 2005 @ Austin

What is “integrated”?

• SSO between uPortal and Sakai?

• Shared provisioning?

• Sakai rendered using uPortal?– Sakai provides markup?– Portal provides markup, Sakai provides

content?

• Shared codebase?

Why integrate?

• Portal as aggregator?

• Portal as one content delivery mechanism to rule them all…– (Layout management)

• Provisioning efficiencies?

Portal as aggregator

uPortal

Sakai Legacy Homegrown LMSMoodle

Webmail Announcements

Summarization, Syndication, Navigation

One portal to rule them all…

• Single look and feel

• Layout management and navigation

• Consider the Hypercontent counterexample

Provisioning efficiencies

• Custom plugin re-use across systems

• Group membership– Driving uPortal AuthZ, channel availability,

fragment pushing off of Sakai groups

Kinds of integration

• Sakai instance as service provider

• Provisioning

• Sakai as service library

Sakai as Service Provider

• WSRP: provide services and markup

• Web Services: provide just services, portlet provides markup.

Sakai as WSRP producer

• Vishal Goenka’s excellent work

• Sakai 2.1.0 produces WSRP for– Tools in the abstract– Specific placements (tool-in-context)

How this works

• Select a tool and identify its id key (“sakai-announcements”, e.g.)

• Use the tool id as the portlet handle

• Unblock Sakai WSRP for your portal

• Point uPortal WSRP consumer @ Sakai WSRP producer

Tool identifiers in webapp\tools\*.xml

<registration>

<toolid="sakai.announcements"title="Announcements"

…</tool>

</registration>

Configuring WSRP consumer

Authenticating consumer to provider

• By remote address of the consumer

• By HTTP_BASIC authentication (over a secure channel) – no built in support for doing this in uP WSRP consumer

How this works in context

• Obtain a tool’s placement ID– Tool in context of a site

• Use the placement id as the portlet handle

Placement identifiers

• <iframe name="Maincdf9fd58x398bx45d7x808fx76381f9c736c" id="Maincdf9fd58x398bx45d7x808fx76381f9c736c" title="Schedule Content" … src="http://deimos.unicon.net:8081/portal/tool/cdf9fd58-398b-45d7-808f-76381f9c736c?panel=Main"> </iframe>

Wrinkle

• Tools-in-context (with placement ids) are very numerous

• So not reported as available portlets via WSRP – consumer has to know they are there and request them despite their not being advertised

• Current WSRP consumers balk at attempting to consume unadvertised

Issues here

• No existing uP releases cope with Sakai’s requirement of out of band provisioning of portlet

• uPortal 2.5.x WSRP consumer doesn’t work at all

• (Consuming the WSRP nicely demonstrated in uP3)

• wsrp4j as incubated work in progress makes fixing this difficult

It’s time to fix and enhance uP WSRP consumption

• Sakai 2.1.0 produces compelling WSRP

• So let’s consume it

• Reasons to be positive and expect progress here

• WSRP4j opportunities

Co-developing WSRP consumption with Sakai WSRP production

• Sakai’s HTTP Basic authentication

• Eventually other authentication mechanisms (proxy CAS)

• uPortal needs to “catch up” with Sakai here.

Sakai instance as service provider

• WSRP gives Sakai control over the service and the markup

• But a custom, portal-appropriate view may be more effective

• A custom JSR-168 (or IChannel) can provide this view on Sakai

• Enabled by Sakai’s web services– And ease of exposing more such services

Sakai Portlet

• Dr. Chuck Severance’s Sakai JSR-168 portlet demonstates this “portlet consumes Sakai web services” approach

Sakai syndicated content

• Sakai tools exposing RSS feeds and the like

• Allow users to roll their own aggregation

XML feeds out of Sakai

• Poor man’s web services

• A lot of mileage out of this for specific use cases

Provisioning

• Groups and permissions

• Layout

• Available channels

Sakai groups as uP GAPs

• GAPs becomes abstract API with its own jars

• Sakai groups store implementation

• Sakai group information then available in uPortal

• Not just groups of users– Groups of channels / portlets

Externally defined channels

• Available channels are defined in terms of Groups and Permissions

• Implement a source of channels backed by Sakai containing channels that present Sakai content

Externally defined layout fragments

• Use GAPS and DLM, ALM, etc. to select content based on Sakai groups

Why provisioning integration is important

• With a working WSRP consumer, there’s still the matter of obtaining and using the right tool placement ids for the right users.

Sakai as service library

MVC: re-using the model

• Sakai models and provides service APIs and implementations for learning and collaboration domain

• Chat service, discussion service, scheduler service…

JSR-168 on these APIs

• Example: a personal scheduler portlet built around the Sakai scheduler implementation

• Minimize code duplication

Pieces of Sakai, running in JSR-168 portlets under uPortal

• Mix and match tools

• Include alongside portlets, channels developed in other ways

JA-SIG: climb the value stack?

• We’ve had excellent collaboration on building a portal framework

• And excellent collaboration on channel projects

• As JA-SIG members look to do this more, and look to do this in Learning and Collaboration domain, be aware of Sakai

How to get involved / contribute

There are too many options

• There are too many options here, it’s hard to know what to focus on, how far to take what when

• Input please: what is needed most urgently, who plans to do what

Sakai Portal DG

• Portal discussion group

Sakai Integration DG

• Integration discussion group

• Collects integration use cases

Birds of a Feather

• Further collect integration scenarios, requirements, desires, plans