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 Legacy Homegrown LMS Moodle WebmailAnnouncements 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 <tool id="sakai.announcements" title="Announcements" …

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

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