uportal-sakai integration ja-sig winter 2005 @ austin
TRANSCRIPT
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