Portal composite pattern::Runtime pattern and
Access Integration::Personalized Delivery application pattern

Overview
Runtime patterns define functional nodes that underpin an Application pattern. The Application pattern exists as an abstract representation of application functions, whereas the Runtime pattern is a middleware representation of the functions that must be performed, the network structure to be used, and the systems management features.

A portal implementation leverages the concept of personalization, multi-device type access, a presentation rendering mechanism, and a business rules engine. These are combined with the ability to search and index content (of various types and formats), provide collaboration, and manage content via a workflow to provide both content aggregation and a collaborative environment.

The Portal composite runtime pattern represents a starting point for most portal implementations, providing a way to identify those functional areas that will likely need to be addressed when considering this type of implementation.

Consequently, the Portal composite runtime pattern represents a preliminary step towards an operational architecture that can be implemented in a target environment to provide secure data aggregation, multi-client access and collaboration.

Access Integration::Personalized Delivery runtime patterns
The Access Integration pattern describes those recurring designs that enable access to one or more Business patterns. In particular, this pattern enables access from multiple channels (devices) and integrates the common services required to support a consistent user interface.

From the business perspective this will enable the portal implementation to provide information to a variety of end user groups that need targeted information by allowing multiple channels now and in the future to be supported with a minimum of overall system modification. Allowing the other parts of the portal system (e.g. security mechanisms, data sources, business logic) to be protected from modification in order to support new end user channels saves in time, people and money.

Personalized Delivery=Participatory Personalization
Participatory personalization allows the user to design the content and the layout of the content that they see by explicitly choosing from a selection of options. The personalization service stores the customization results in a profile record.

Access Integration::Personalized Delivery=Participatory Personalization
(Click a node to get a detailed explanation.)
Design Last Updated: 12-07-2004

The main benefit of a participatory personalization solution is that it allows users to modify the navigation and information presentation of their interface for maximum comfort and efficiency. Its disadvantages include that it can be difficult to encourage users to participate due to trust issues, and follow-up efforts to refresh user preferences may be perceived as intrusive.

Applying it to the Portal composite runtime pattern
The Portal composite runtime pattern supports the characteristics of this pattern by having a separated presentation mechanism (presentation server). Users can choose which portlets they want on their page, add new page groups (also known as places) and add new pages (within a page group). Additionally, a user can select a theme which defines some aspects of the color scheme and graphics used when information is displayed to the user.

Personalized Delivery=Prescriptive Personalization
Prescriptive personalization provides a rules engine that delivers targeted content based on business rules defined by the enterprise. The personalization rules are based on data being requested by the user and the user’s profile information.

Access Integration::Personalized Delivery=Prescriptive personalization
(Click a node to get a detailed explanation.)
Design Last Updated: 12-07-2004

The benefits of this solution are that it enables the enterprise to have fine-grained control over access to applications and data while improving users’ efficiency, and facilitates a better end-user experience. The main disadvantage is that proper implementation can be challenging if business rules are complex.

Applying it to the Portal composite runtime pattern
The Portal composite runtime pattern supports this via a rules engine node which is an external mechanism to house the rules that match users and groups to specific types of information. In the parlance of WPS, these are called resources. The figure below shows the Personalized Delivery application pattern overlaid on the Portal composite runtime pattern.

Personalized Delivery application pattern and Portal composite runtime pattern
(Click a node to get a detailed explanation.)
Design Last Updated: 12-07-2004

The Personalized Delivery application pattern is logically shown by the Personalization Server node in the figure above.

What's Next
If you would like to review additional Application patterns, and their corresponding Runtime patterns, return to the Portal: Select Application pattern page.

For a mapping of products that support the Runtime nodes shown above, review the Portal product mapping.