Architecture Patterns for Portal Information Integration

From MIKE2 Methodology

Architecture Patterns for Portal Information Integration describe how different components in the SAFE Architecture interact to integrate a web portal to back-end systems for integration.

The Problem and its Symptoms

Portals are an emerging architecture construct for effectively aggregating the presentation of information from diverse point sources into a single, uniform medium—typically a web browser client, although the power of today’s portals is their ability to repurpose their content for a variety of channels and devices (e.g. PDA or pager with limited screen space). Portlets, the discrete presentation elements that comprise a Portal view, provide an (emerging) standard for developing snippets of presentation and interaction that can be styled, sized, positioned and composed according to end user preference. Together, portals and their portlet components, allow the presentation layer of a web application to be loosely coupled from its “container”—the web page and its enclosing web browser.

Portals and portlets are not a universal solution to web presentation problems, however, they are particularly effective for presenting a snapshot view of information gathered from multiple information sources in a single display. Therein lies the challenge: how to develop portlets that access a variety of back end applications and systems in a standardised fashion? Accordingly, a poorly design portal implementation will exhibit the following characteristics:

• Portlets built with a variety of embedded, endpoint specific integration mechanisms for connecting to back end information sources.
• Information access logic duplicated across portlets and integration architecture components.

Design Pattern for Portal Information Integration

The Portal Information Aggregation pattern abstracts the application access responsibility of individual portlets into discrete, reusable integration components hosted within a central Integration Broker. Whilst each portlet might traditionally be expected to handle its own integration and access to an associated information source, this pattern seeks to provide all portlets with uniform information access through the Integration Broker. Therefore, this pattern enforces the loose coupling of portlets and their application sources, and is effectively an “n tier architecture” for portlet construction.

1. Portlets executing within a server side Portlet Container are responsible for the client side presentation of information harvested from a number of back end applications. Portlets do not communicate directly with their associated back end applications, but instead, make service requests to a uniform layer of Business Services that are dedicated to information access.
2. Information-access services are exposed to portlets as Business Services by the Integration Broker. Service request messages encapsulate the retrieval parameters needed to construct application specific queries at the endpoints (either through APIs or direct database interrogation).
3. The unique, application specific mechanisms to connect with a system, marshal data, invoke an internal service and return a response, are encapsulated within integration components hosted by the Integration Broker. These are reusable components that are accessible by portlets or any other calling client.
4. Applications are finally delegated the task of retrieving or updating data on behalf of their portlet clients.

This pattern implies that each portlet is mapped to a single, back end application, however, the layer of indirection provided by Business Services and the Integration Broker do not make this a strict requirement. The Business Service can represent an arbitrarily complex service, possibly accessing more than one back end system in a single service request. The Business Service takes responsibility for harvesting information from whatever sources it requires, but should expose a very simple interface to the invoking portlet.