uPortal-Sakai integration JA-SIG Winter 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 LMS Moodle WebmailAnnouncements 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 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 Sakai WSRP producer

Tool identifiers in webapp\tools\*.xml <tool id="sakai.announcements" title="Announcements" …

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

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