1. Portals: Architecture & Best Practices Greg Hinkle February 2005

2. Portals - Architecture & Best Practices2 Agenda Opportunities Challenges Best practices Strengths & Weaknesses

3. Portals - Architecture & Best Practices3 Opportunities User centric applications Personalized and customizable by users Aggregated views of many systems and content types

4. Portals - Architecture & Best Practices4 User centric Enterprise portals applications typically fall into two categories –Information integration portals provide access to data from many systems in an enterprise. They are oriented at visibility and should provide context and taxonomy. Search functionality is often the most difficult feature to implement –Process integration portals provide one place to accomplish human driven tasks that previously required accessing multiple systems.

5. Portals - Architecture & Best Practices5 User centric (cont…) For task-based applications, focus on providing users with the best user interface for the tasks they accomplish –Provide only the information they need –Reduce steps to complete tasks For information applications, allow the user to rearrange and reconfigure portlets to their liking –Make sure portlets work anywhere with no dependencies –Provide search capabilities to find data across sytems

6. Portals - Architecture & Best Practices6 Personalization Create common content hierarchies and utilize CSS for formatting –CSS also allows for easier use of customizable look & feels Standardize user interface elements across portlets –Standardize form layouts, tabular data views and common user experiences such as search-list-detail –Reduces the “whiplash” of dealing with so many different types of information

7. Portals - Architecture & Best Practices7 Challenges Performance Data Consistency Communication Proprietary extensions Security Dynamic layout

8. Portals - Architecture & Best Practices8 Performance The nature of portlet applications creates situations where the portlets rendered on a single page may each make calls to retrieve the same content Caching is the primary solution to reducing database overhead, but be prepared for large shared caches in sites where many different content types are being displayed on a single page Using multi-threaded rendering helps latency, but maintains the same database load Resist the urge to use session or request scope caches where portlets depend on each other for data retrieval

9. Portals - Architecture & Best Practices9 Caching Four places at which to cache –A portlet cache stores the rendered portlet fragment –A fragment cache stores rendered fragments –A service cache stores the results of service tier calls –An entity cache stores results from the data access tier Caching impacts inter-portlet communication –Portlets may not be rendered in order or may be rendered simultaneously –Even if forking is turned off, portlets should support being rearranged –Only action lifecycle methods are guaranteed to run before rendering

10. Portals - Architecture & Best Practices10 Caching (cont…) Portlet cache –The portal specification defines time-expiration based portlet caching WebSphere has customizable caching levels with custom keys and programmatic invalidation WebLogic has per user, time-based caching and can’t be programmatically invalidated (a portlet cache is invalidated when an action is sent to it) Fragment cache –Stores generated fragments by customizable keys –Solutions such as OSCache

11. Portals - Architecture & Best Practices11 Caching (cont…) Service cache –Utilize a custom cache or cache library –Use custom business logic to refresh as necessary Entity cache –Use the cache of your persistence layer such as Entity Bean caching or hibernate caching –One of the simplest to use

12. Portals - Architecture & Best Practices12 Communication Inter-portlet communication can be accomplished by setting application scope session variables Portlets should gracefully handle when those variables are not available Information for render can be passed to JSPs in the request Avoid situations where a portlet utilizes the result of an action execution on a portlet other than itself

13. Portals - Architecture & Best Practices13 Portlet extensions Many Portal servers provide proprietary extensions to the JSR-168 development model –Simplified development with provided tools –Enhanced inter-portlet communication such as event listeners –Complex, visual page flow management –Separation of view and controller with backing JSPs (model- 2 for portlets) These extensions are not portable to other servers and often require the use of provided development tools

14. Portals - Architecture & Best Practices14 Security Portlet access security is simply an extension of web application security with the same limitations Basic user portlet access can be controlled with isUserInRole() Data access control can be accomplished if the service API is built to support security checks End-to-end security may be best implemented with technologies such as Kerberos

15. Portals - Architecture & Best Practices15 Dynamic layout A single portlet may be displayed twice on the same page For these types of portlets, beware of request parameters and JavaScript –Use the namespace tag to differentiate document ids Portlet scope is safe and not shared between two portlets on the same page

16. Portals - Architecture & Best Practices16 Best practices Utilize JSPs for content display as with Model-2 Use Portlet JSP tags for forms PortletContext portletContext = getPortletContext(); PortletRequestDispatcher prd = PortletContext.getRequestDispatcher(“/jsp/PortletView.jsp”); Prd.include(request,response); ”/> ”> …

17. Portals - Architecture & Best Practices17 Best practices (cont…) Use a custom print mode to support simplified layouts for printing portlet contents Utilize web-app context parameters for initialization information common to multiple portlets Uses preferences to store user configurations of a portlet PortletPreferences prefs = request.getPreferences(); prefs.getValue(“RSS_URL”, “http://my.rss.com/rss”);

18. Portals - Architecture & Best Practices18 Best practices (cont…) Use createRenderURL() and createActionURL() to create links Use getContextPath() to link to images Only update state in action calls Group portlets that operate on the same data into a single portlet application to allow them to share initialization parameters

19. Portals - Architecture & Best Practices19 Portal strengths Replacing homegrown intranet applications for employees that were already portal-like Providing customizable user experiences by allowing application interfaces to be assembled according to their use A common platform that when implemented by more application providers will simplify development of complex systems

20. Portals - Architecture & Best Practices20 Portal weaknesses Using many complex Portlets can often cause performance issues due to the many round-trip and separate data retrievals Creating tight integration between applications built with varying technologies No provisions for detailed, data-level security within integrated applications The component like construction of portlets can lead to poor and inconsistent user interfaces Lacks the development benefits of the mature web frameworks such as Struts and WebWork (configurable page flow, validation, form management)

21. Questions? February 2005 Download the slides for this presentation and Part 1 – Portals: Background from: http://chariotsolutions.com