uPortal-Sakai integration

1. uPortal-Sakai integration JA-SIG Winter 2005 @ Austin

2. 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?

3. Why integrate? • Portal as aggregator? • Portal as one content delivery mechanism to rule them all… • (Layout management) • Provisioning efficiencies?

4. Portal as aggregator uPortal Sakai Moodle Legacy Homegrown LMS Webmail Announcements Summarization, Syndication, Navigation

5. One portal to rule them all… • Single look and feel • Layout management and navigation • Consider the Hypercontent counterexample

6. Provisioning efficiencies • Custom plugin re-use across systems • Group membership • Driving uPortal AuthZ, channel availability, fragment pushing off of Sakai groups

7. Kinds of integration • Sakai instance as service provider • Provisioning • Sakai as service library

8. Sakai as Service Provider • WSRP: provide services and markup • Web Services: provide just services, portlet provides markup.

9. 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)

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

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

12. Configuring WSRP consumer

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

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

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

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

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

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

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

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

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

23. Sakai syndicated content • Sakai tools exposing RSS feeds and the like • Allow users to roll their own aggregation

24. XML feeds out of Sakai • Poor man’s web services • A lot of mileage out of this for specific use cases

25. Provisioning • Groups and permissions • Layout • Available channels

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

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

28. Externally defined layout fragments • Use GAPS and DLM, ALM, etc. to select content based on Sakai groups

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

30. Sakai as service library

31. MVC: re-using the model • Sakai models and provides service APIs and implementations for learning and collaboration domain • Chat service, discussion service, scheduler service…

32. JSR-168 on these APIs • Example: a personal scheduler portlet built around the Sakai scheduler implementation • Minimize code duplication

33. Pieces of Sakai, running in JSR-168 portlets under uPortal • Mix and match tools • Include alongside portlets, channels developed in other ways

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

35. How to get involved / contribute

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

37. Sakai Portal DG • Portal discussion group

38. Sakai Integration DG • Integration discussion group • Collects integration use cases

39. Birds of a Feather • Further collect integration scenarios, requirements, desires, plans