Portals:Architecture & Best Practices

Greg Hinkle

February 2005

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

Questions?

February 2005

Download the slides for this presentation and Part 1 – Portals: Background from:

http://chariotsolutions.com