Portals: Architecture & Best Practices

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

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

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

4. 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. Portals - Architecture & Best Practices

5. 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 Portals - Architecture & Best Practices

6. 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 Portals - Architecture & Best Practices

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

8. 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 Portals - Architecture & Best Practices

9. 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 Portals - Architecture & Best Practices

10. 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 Portals - Architecture & Best Practices

11. 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 Portals - Architecture & Best Practices

12. 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 Portals - Architecture & Best Practices

13. 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 Portals - Architecture & Best Practices

14. 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 Portals - Architecture & Best Practices

15. 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 Portals - Architecture & Best Practices

16. 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); <portlet:actionURL var=“submitUrl”> <portlet:param name=“action” value=“save”/> <portlet:param name=“contentId” value=“<%=contendId%>”/></portlet:actionURL> <form action=“<%=submitUrl%>”> … </form> Portals - Architecture & Best Practices

17. 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”); Portals - Architecture & Best Practices

18. 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 Portals - Architecture & Best Practices

19. 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 Portals - Architecture & Best Practices

20. 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) Portals - Architecture & Best Practices

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