uPortal Roadmap

1. uPortal Roadmap Ken Weiner, UNICON-IBS Dan Ellentuck, Columbia University

2. Release timeline uPortal 2.1 New features for uPortal 2.2 Beyond uPortal 2.2 Overview

3. uPortal Release Timeline AL, etc. 1st Release Performance Misc. 1.0 Jul 1.6Jun 2.1 Dec 2.0.1 Apr 2.1.2 Apr 2.1.3 Jun 2.1.x Oct 2000 2001 2002 2003 1.5 Feb 2.0 Feb 2.2 Oct 2.0.2 Jul 2.0.3 Dec 2.1.1 Feb Roles XSLT Arch.

4. uPortal CVS File Lines Source: http://www.rootbin.com/cgi-bin/cvsmonitor/cvsmonitor.pl?cmd=viewBrowseModule&module=JASIG.uPortal on June 7, 2003

5. uPortal CVS “karma” 2000-2003 Source: http://www.rootbin.com/cgi-bin/cvsmonitor/cvsmonitor.pl?cmd=viewBrowseModule&module=JASIG.uPortal on June 7, 2003

6. Applet publishing CWebProxy enhancements Local connection context Channel rendering groups Remote channels Groups and permissions managers Composite group service + LDAP impl. Usage statistics gathering CAR file support JNDI data sources uPortal 2.1 Features

7. Aggregated layouts Integrated preferences management Internationalization Multiple permissions sources WSRP client, server Channel archive (CAR) improvements Channel publishing tool Transient channels Secure channels XML parser independence LDAP Context Lookup Planned for uPortal 2.2

8. Experience constructed for the end user by the implementers/administrators of the portal combined with the end user's customized content System for constructing, managing, and administering grouped content, such that the presence and level of visibility of this content is guaranteed to appear in a users layout System allowing users to subscribe to grouped content Aggregated Layouts

9. Aggregated Layouts Fragment aggregation A user layout constructed from pre-defined layout fragments

10. Aggregated Layouts Subscribing to fragments Health & Legal Services Column User adding content that has been grouped by content administrators Tab by Faculty and course Departmental Calendar and Events Column

11. Preferences – Separate Channel

12. Integrated Preferences Source: http://www.immagic.com/uPortalprefs/tour/

13. Adding a New Column Source: http://www.immagic.com/uPortalprefs/tour/

14. Content Subscription - Channels Source: http://www.immagic.com/uPortalprefs/tour/

15. Content Subscription - Fragments Source: http://www.immagic.com/uPortalprefs/tour/

16. Support for multiple locales Locale = Language + Country Levels of personalization uPortal installation Layout or profile Channel definition Channel instance Session Internationalization I18N

17. public class ChannelRuntimeData … { . . public Locale[] getLocales() {…} . . } Locales in ChannelRuntimeData

18. Groups and Permissions Roadmap Introduction to Groups and Permissions A little past history Current Release: What’s in, what’s missing Plans for Future Releases: 2.2 and beyond…

19. What do these systems do? They collaborate on authorization: deciding what a user can see and do. In the portal, the most basic authorization question is, what channels is a user is permitted to subscribe to and render. Permissions manages authorization data and answers questions about what permissions a user has. Groups is a more general and lower-level service that manages membership information about portal entities, enabling the portal operate on these entities collectively. Besides authorization, it supports other group-y activities like channel publication and layout management. Introduction to Groups and Permissions

20. Why does this matter to you? Any uPortal deployment beyond prototype will spend time and effort integrating Groups and Permissions with pre-existing external resources, e.g., LDAP. The success of this integration is a good index of how well the portal as a whole collaborates with its surroundings. Introduction to Groups and Permissions

21. Ancient History: Release 1.x Authorization performed by roles framework. Role is an arbitrary symbol with some significance to the portal, e.g., Publisher, Developer, Administrator, Honored Guest, etc.. Each user had a list of roles. Portal could query roles framework to find out what roles a user had and act accordingly. Example: only users with the role Publisher were permitted to publish channels. Prior Releases: some history

22. Recent History: Release 2.0 Roles framework split in half: Groups service to track user roles (memberships) Authorization to compute user permissions. Rationale: Groups have uses that transcend authorization. Wanted richer authorization model to include a Permission that authorized a user or principal to perform some activity on some target in a context provided by some owner. The process of assessing a user’s memberships is different from deciding what those memberships entitle a user to do. Prior Releases: some history

23. Prior Releases: some history Recent History: Release 2.0 Included: • Groups model • Groups service API • Groups Manager channel • Permissions model • Authorization service API • Permissions Manager channel • But, Groups and Permissions in Release 2.0 were essentially prototypes. Even though they worked, they only worked with the reference portal database, so you had to re-implement one or both of them if you wanted to integrate them with pre-existing external services, like LDAP, which is what any medium- to large-scale portal deployment had to do.

24. Groups and Permissions in Release 2.1: Groups rewritten as a composite service with multiple component services, each with its own group source and its own adaptor to make the external information look like group memberships. Highly configurable. Group sources can be added or dropped by editing a configuration file and restarting the portal. Sources can have varying relationships to the composite service; internally vs. externally managed; read-write or read-only. All group information aggregated by the composite service looks the same to clients; they do not have to be aware of service of origin. Foreign group memberships enables creation of new groups (roles) out of old ones. Example: a group derived from LDAP, supplemented by memberships from a group of read from the user database of a legacy system, plus additional members not found in any current group source all appear to be members of the same group. Two adaptors: LDAP and reference portal db. All permissions derived from a single source: reference portal db. Logic for authorization can be overridden on a per-call basis (pluggable permission policy). Current Release: what’s in, what’s missing…

25. Current Release bottom line: Pros: Lots of flexibility for configuring multiple sources of group information. LDAP support. Moderate flexibility in managing authorization, including pluggable permission policy. Cons: Not tested under heavy load. Single source of permissions. Can be tough to get going (learning curve). Current Release: what’s in, what’s missing…

26. Groups and Permissions 2.2: Improvements to LDAP adaptor. Caching, pre-load, etc. New Filesystem adaptor makes groups out of files with lists of user IDs. Can create a group system with minimal effort. Could be used to bridge deployment effort and encourage experimentation. Group Manager usability enhancements; more flexible permission policy makes it easier for native channels to use group manager servant to collect group selections. Support for multiple sources of Permissions, including pluggable priority policy for deciding which source takes precedence. Plans for Release 2.2

27. Remote Channel Web Service Swing client Channels Web Service SOAP Channels uPortal WSDL uPortal

28. Developed by OASIS WSRP will define: A WSDL interface description for invocation of WSRP services How to Publish, Find, Bind WSRP services and metadata Markup Fragment Rules for markup emitted by WSRP services Current spec 0.95, April 24, 2003 Web Services for Remote Portals (WSRP) Source: http://www.oasis-open.org/committees/wsrp/presentations/wsrp_overview.ppt

29. Markup Enable embedding of “Producer” markup Service description Queries the “entities” of the producer Portlet entity management Manage entities within the “Consumer” Registration “Consumer” registers with “Producer” WSRP Interfaces

30. Remote Channel Web Service WSRP Register portlet entity handle portlet handle Producer GetMarkup PerformInteraction Consumer Deregister Authenticate credentials Instantiate channel fname instance identifier Web Service Client Render channel Web Service instance identifier, runtime data channel markup Receive event instance identifier, portal event Free channel instance identifier Logout WSDL

31. Packaging and deployment of channel code and resources WEB-INF/cars directory  .car files Car resource worker org.jasig.portal.car.CarResourceWorker Channel ARchives (CAR)

32. CAR Viewer (Car Lot ) CAR file is a zip containingchannel sources, stylesheets, and resources such as images Images areloadedfrom car file

33. Support of more browser-accessible file types Automatic recognition of new or updated CAR Automatic channel publication Creation of database tables for a channel Externalized CAR resources Third party library support Ability to deploy services and channel types CAR Improvements

34. Maintain channel definitions as XML descriptors org.jasig.portal.tools.chanpub package ant pubish –Dchannel=mychannel.xml Channel Publishing Tool

35. Channel Definition Descriptor <channel-definition> <title>My Channel</title> <name>My Channel</name> <fname>my-channel</fname> <desc>My very own channel</desc> <type>Custom</type> <class>edu.myschool.portal.channels.CMyChannel</class> <timeout>30000</timeout> <hasedit>N</hasedit> <hashelp>N</hashelp> <hasabout>N</hasabout> <categories><category>Applications</category></categories> <groups><group>Everyone</group></groups> <parameters/> </channel-definition>

36. Channels appear on demand Not needed anymore in user layout Preferences (CUserPreferences) Channel Admin (CChannelManager) Transient Channels http://localhost:8080/uPortal/[…].uP?uP_fname=portal/userpreferences/general

37. Layout fragment management XLIFF-based channel development WSRP service implementation JSR-168 portlet wrapper Channel deployment automation GUI for registration of XSLT stylesheets Channel notification service Beyond uPortal 2.2…

38. Groups and Permissions post-2.2 Enhance Permission design to include a higher-level Permission object, a Permission-Set, containing multiple Permissions for a given target, activity or owner. Meant to model a complex role whose targets or activities could vary depending on the group or user associated with it. Example: Permission-Set for Club Treasurer could contain multiple activities that remain constant, but whose targets vary depending on the identity of the club: Glee Club, Debating Society, etc. Rework Permissions Manager for pluggable permissions policy, multiple permission sources and usability enhancements. Additional group adaptors contributed by the uPortal community. Plans for Release 2.2 and Beyond…

39. Set goals, prioritize features, technical discussions, work assignments 2 per year, usually in March and August Alternate east coast / west coast Previous meetings: University of New Mexico, 3/2002 Memorial University of Newfoundland, 8/2002 SCT, 3/2003 Next meeting: Cornell University, 8/2003 Developer Meetings

40. portal_channels CVS repository Blackboard - CalPoly Bookmarks - Various UBC_AddressBook - UBC UBC_Webmail - UBC Classifieds – Iowa State Elections – Iowa State Missing components Release managers Mailing lists Bug reporting Open Source Channels

41. jasig-announce@unm.edu Low traffic Open membership uPortal releases, conferences, training classes jasig-portal@unm.edu High traffic Open membership Discuss anything related to uPortal jasig-dev@unm.edu Medium traffic Membership restricted to uPortal framework developers Coordination of development work uPortal Mailing Lists

42. Speakers: Ken Weiner and Dan Ellentuck Presentation Title: uPortal Roadmap Date: 06/9/2003 Time: 3:30 PM – 4:30 PM Room: Westminster I and II The End Questions ? Speaker Evaluation Info: