Portals: Architecture

1
PortalsArchitecture Best Practices
February 2005

• Greg Hinkle

2
Agenda

• Opportunities
• Challenges
• Best practices
• Strengths Weaknesses

3
Opportunities

• User centric applications
• Personalized and customizable by users
• Aggregated views of many systems and content types

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.

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

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

7
Challenges

• Performance
• Data Consistency
• Communication
• Proprietary extensions
• Security
• Dynamic layout

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

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

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
  cant 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
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
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
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
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
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
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/Po
rtletView.jsp)Prd.include(request,response)


value/ m action
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/rs
s)
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

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

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)

21
Questions?
February 2005

• Download the slides for this presentation and
  Part 1 Portals Background from
• http//chariotsolutions.com