uPortal System Architecture Overview

1. uPortal 3sneak preview Eric Dalquist, Peter Kharchenko Unicon Inc.

2. Outline • Project goals • Architecture overview • Flexibility through configuration • Demonstration • uPortal2 UI support • Features • What’s currently there • Release targets and timelines • More features to come

3. Project goals • Long-term goals for the framework • configuration flexibility • rendering mechanisms • HTTP parameter generation/processing mechanisms • data layer implementations • code maintenance in a long run • isolated, individually configured groups of components • transparent, sparse coupling

4. Project goals • Goals for the initial release • Spring framework • Dependency injection • Unified configuration • JSR168 support • Complete WSRP integration • uPortal2 backwards-compatibility • Modular support for subprojects: GAP, PersonDir • Shedding custom code: ACEGI, Hibernate

5. Outline • Project goals • Architecture overview • Flexibility through configuration • Demonstration • uPortal2 UI support • Features • What’s currently there • Release targets and timelines • More features to come

6. Architecture overview: portal contexts • What is a Portal Context ? • Defines all aspects of a traditional portal instance • Parameter syntax • Design, navigation, profiles • Portlet selections, session scopes • Multiple, concurrent contexts can be used • Example contexts • uPortal2 clone • static frame showing a single portlet • service context for AJAX callback uPortal context

7. Alternative context resolution strategies user information authentication state user affiliation (groups), attributes (permissions) user agent information (browser) internal states, session (i.e. down for maintenance) Servlet Path resolver switch contexts by going to a specific servlet path http://host/uPortal/context/... ContextResolver AJAX callbacks uPortal2 lookalike Single portlet … Architecture overview: context resolvers

8. Architecture overview: rendering • Rendering is compiled by components • Rendering trees • Linear pipelines • Rendering component • Creates or modifies content • Determines viable rendering path • Multiple component types • SAX components • XSLT transformer filter • String components • Portlet content injector • Built to accommodate other component types output

9. Architecture overview: Spring configuration uPortal2 lookalike context rendering pipeline configuration … <property name=“pipelineElements”> <ref bean=“layoutSource”/> <ref bean=“transientLayoutInjector”/> <ref bean=“structureTransfromationFilter”/> <ref bean=“themeTransformationFilter”/> <ref bean=“sax2StringCachingFilter”/> <ref bean=“renderingInitiationFilter”/> <ref bean=“portletIncorporationFilter”/> <ref bean=“servletResponseWriter”/> </property> … User layout Structure and theme Caching/Serialization Portlet rendering

10. Architecture overview: render caching • Some components cache content • ICacheFilter interface • Independent of the content type (SAX, String) • Cache manager • Determines available cache entry points • Checks entry point validity • Chooses optimal entry point • Replays cache output

11. Architecture overview: URL parameter syntax • URL construction and request parameter processing is programmatic and modular • URLs are generated by implementations, not by hand • Framework components come with their own URL constructors and parameter processors <property name=“urlConstructorProviders”> <ref bean=“transientLayoutUrlConstructor”/> <ref bean=“portletErrorHandlerUrlConstructor”/> </property> <property name=“processors”> <ref bean=“transientLayoutParameterProcessor”/> <ref bean=“portletErrorHandlerParameterProcessor”/> </property> Constructors Processors

12. Architecture overview: URL construction • URL construction in Java code • Construct URLs by calling methods on command interfaces • Portlet error handler URL example: • Portlets can access framework URL syntax • Outside of JSR168 • Used by uPortal3 management portlets IPortletErrorCommands c = portalUrl.getUrlConstructor (name); c.restartBrokenPortlet (portletWindowId); portalUrl.toString ();

13. Architecture overview: URL construction • URL construction in XSLT stylesheets • Using extension elements portlet <portlet:renderUrl> <portlet:parameter name="parameterName" value="parameter value"/> <portlet:portletMode windowId="anotherId" mode="view"/> </portlet:renderUrl> framework <portal:url> <rendering:parameter source=“theme” name=“skinName” value=“matrix”/> <rendering:attribute source="structure" name=“minimized" value=“true" select="//folder[@type='someType']"/> </portal:url>

14. Architecture overview: Examples of URL syntax features • uPortal2 syntax support • Layout management, Channel/Folder attributes, etc. • Encode navigational state • Chemistry Tab: http://host/uPortal/Chemistry101/ • Mail portlet: http://host/uPortal/portlet/mail • Encode user spaces • Users’ tab: http://host/uPortal/~peter/blogPage/

15. Architecture overview: controllers • User • Keeps track of the current user • Distributes authentication events • ACEGI implementation • Persistence • Coordinates persistence for a context • Locale manager • Maintains and resolves multiple sources of locale preference

16. Architecture overview: portlet handling • PortletWindowManager • Coordinates portlet render/action requests • Rendering models • Linear • Multithreaded • Error handler • Portlet Domain Objects • Deployment (as distributed) • Definition (published) • Entity (subscribed) • Window (placed in the layout)

17. Architecture overview: portlet registries uPortal Framework Domain objects Registries Domain objects Transfer objects DomainObjectFactories Caching DAO’s DAO Implementations e.g. Spring JDBC Database

18. WSRP • Consumer Support • Similar to uPortal 2.4 • Confirmed integration to the Sakai framework • Producer Support • Any portlet can be exposed • Re-use configured instances • uPortal as a service provider

19. Porltets • Specification Compliance • Complete JSR-168 specification compliance • Ease of extension for custom features • Management • Better use of portlet deployment data • Administrators need less detailed portlet knowledge • Future compatibility • JSR-286 on the horizon • Significantly less effort for integration with uPortal3

20. Object Caching • uPortal2 has no explicit caches • Caches are hidden in the framework • Difficult to configured • One cache per object type • Reduces long term references • Lowers the possibility of memory leaks long term • Less complicated framework code • Performance tuning for your environment • Fine grained controls provide flexibility

21. Object Caching • Cache Configuration registries Context <bean id="portletDefinitionRegistry" class=“...PortletDefinitionRegistryImpl"> <property name="cache"> <ref bean="/caches/portletDefinitionCache"/> </property> </bean> caches Context <bean id="portletDefinitionCache" class="...EhcacheAdapter"> <property name="ehcache"> <bean parent="baseEhCacheBean"> <property name="maxElementsInMemory"> <value>32</value> </property> </bean> </property> </bean>

22. uPortal 2 Compatibility • Full uPortal 2 stylesheet support is available • Structure and theme style compatibility • URL Syntax • Stylesheet Definition Files (SDFs) • Support provided by uPortal3 API implementations • Simple User Layout Management • Port of the basic uPortal 2 layout manager • Provides layout customization for uPortal 3 • Template user support

23. uPortal 2 Compatibility - TODO • IChannel Support • We need community feedback • What APIs do your channels use? • IBM’s API Scanner: • http://www.alphaworks.ibm.com/tech/aus • DLM Integration • Targeted as the default layout manager • Database Upgrade Tools • Layout customizations • User preferences

24. Hibernate • Standard persistence mechanism for uPortal3 • All DAOs will use Hibernate for persistence • Greatly reduced persistence code • No SQL to maintain • Simplifies adding persisted data • Integrated schema update tools • Provides greater range of database support

25. Unit Testing • New design is easier to test • Smaller components are more specialized • Long term stability • Tests provide assurance during customization • Greater initial coverage • Majority of the code is covered by tests

26. Services • Sub-Project Development • Break out uPortal independent services • Provides functionality to more than just uPortal • Current Sub-Projects • Groups and Permissions • Person Directory

27. December January February March April May Release Strategy • Milestone 3 • Released December 2nd • Group management portlet ported • User locale preference framework • uPortal 2 stylesheet support • uPortal 3 Rendering context • Service integration • Person Directory • Groups Framework

28. December January February March April May Release Strategy • Alpha • Target: End of February 2006 • Implementation cleanup • Permissions framework integration • Service integration testing • Portlet support verification

29. December January February March April May Release Strategy • Beta • Target: End of March 2006 • Ready to Rock! • Complete ‘Portlet Only’ portal • Usable by new adopters for evaluation and planning

30. Release Strategy • Release Candidates & 3.0 Final • Need community involvement! • IChannel support • Database migration tools • Distributed Layout Management

31. Architecture overview: rendering attributes • Rendering attributes – “rendering preferences” • Information associated with layout elements • Defined by users, transforms, components • uPortal2 example: column width • Generalized in uPortal3 • Providers: determine appropriate attribute sources • By folderId, portletWindowId, element name, etc. • Values: handle persistence, scoping • Injectors: insert rendering attribute information • XSLT params, <parameter/> elements, etc. • Multiple attribute scopes: transforms, layouts, portlets

32. Architecture overview: rendering attributes • Simple rendering attribute provider example • Recognizes <folder/> elements by @ID attribute • Stores attribute values for that user in a DB • Outputs default values for missing attributes • Configured to inject attributes as <parameter/> elements • Hierarchical rendering attribute provider • Recognizes <folder/> elements by @ID attribute • Outputs attribute values defined by the user • Recognizes <folder/> by @fragmentId attribute • Outputs attribute values defined by the fragment author