Pervasive Commerce Portal composite pattern::Runtime pattern and
Access Integration::Web Single Sign-On 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 Pervasive Commerce 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 Pervasive Commerce 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 Pervasive Commerce 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, eCommerce and collaboration.

Access Integration::Web Single Sign-On 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.

Web Single Sign-On=Homogeneous Application Servers
The homogenous application server design illustrates how, in a Web tier environment, all applications implemented on the same application server can exploit that application server's security mechanisms for single sign-on functionality.

Access Integration::Web Single Sign-On=Homogeneous App. Servers
(Click a node to get a detailed explanation.)
Design Last Updated: 12-07-2004

Applying it to the Pervasive Commerce Portal composite::Runtime pattern
The Pervasive Commerce Portal composite runtime pattern supports the Access Integration::Web Single Sign-on=Homogeneous Application Server runtime pattern. The Web Single Sign-on application pattern overlays the Pervasive Commerce Portal composite runtime pattern as shown in the figure below.

Single Sign-On application pattern and Pervasive Commerce Portal composite runtime pattern
(Click a node to get a detailed explanation.)
Design Last Updated: 12-20-2004

This Runtime pattern is supported since it treats the concept of the application server node as the central mechanism where data is pulled from multiple data sources and, if user display is required, passes that information to the presentation server. In this type of implementation this centrality would also include an integrated security mechanism which could leverage an external LDAP directory source.

Web Single Sign-On=Heterogeneous Application Servers
In this pattern, a Web tier with multiple different vendor application servers can only implement Single Sign-On with the deployment of a separate security server. The external security server provides an authentication proxy that intercepts requests to map or transform user credentials into the appropriate credential format for that application server.

Access Integration::Web Single Sign-On=Heterogeneous App. Servers
(Click a node to get a detailed explanation.)
Design Last Updated: 12-07-2004

The advantages of this design is that it provides a unified, secure authentication model, and supports multiple vendors/platforms. Its disadvantages include:

• It requires modification and migration to include existing applications.
• It can be difficult to model the separation or aggregation of authorization data across many applications.
• It requires that applications support an externally-managed security proxy.

Applying it to the Pervasive Commerce Portal composite runtime pattern
The two characteristics that are leveraged in the Pervasive Commerce Portal composite runtime pattern are the ability to have different vendor application servers and the separated security server.

The Pervasive Commerce Portal composite runtime pattern indicates a single node for the application server; however, this can represent more than one physical application server instance. In fact, because of the separated security mechanism, the impact of having application servers from multiple vendors versus a single vendor is mitigated. In addition, this allows for adding more application servers as load and/or performance demands increase. The Pervasive Commerce Portal composite runtime pattern supports this component based architecture which isolates functionality (e.g. business logic vs. data sources vs. security vs. presentation) allowing the enhancement of specific areas of functionality with minimal affect on the whole system.

The use of a separated security server allows for the upgrade of user and organization profile management without affecting the rest of the system. For example, a modification to the hierarchy between user types and group types in the LDAP server can take place, as long as backward compatibility is maintained, without requiring a shut down of other components in the system (e.g. the application server, database server, firewalls, etc.). This represents a best architectural and implementation practice in having a component based systems architecture where there is separation of concerns between the presentation, business logic, security, and data source tiers.

Web Single Sign-On=Central Authorization Service
Another alternative for extending the security context to back-end systems is to allow the same security service that controls the Web tier to control the back-end applications. The security server provides the role-based authorization for controlling back-end resources. No credential mapping or transformation is required. The security context is preserved all the way through to the back-end system.

Web Single Sign-On=Central Authorization Service runtime
(Click a node to get a detailed explanation.)
Design Last Updated: 12-07-2004

This use of a common security mechanism is important from an architectural best practices perspective. Wherever possible is makes the best strategic sense to have a single mechanism. This allows central management of users and groups at the enterprise level and also mitigates the risk of enterprise level security policies not being followed. Additionally, if there needs to be an upgrade to the capabilities of the security model and/or technology implementation, this can be done without having to modify the other components of the portal implementation. The reality is that this is often impractical other than in an environment where an almost total re-architecture of existing systems is undertaken.

Advantage
The benefits of this solution is that it simplifies user management across all applications, and unifies user profile information and reduces redundancy.

Disadvantage
Its main disadvantage is that it requires all applications to support the chosen security proxy and may require complex modification and migration. Many organizations prefer to leverage the existing multiple security mechanisms and synchronize these mechanisms with the understanding that, at least initially, this will require less time, people and people resources. In addition, if existing systems are in place and there is an identified need to move a central mechanism, more up front re-architecture will need to be performed to consolidate the existing data. This is a common scenario.

Applying it to the Pervasive Commerce Portal composite runtime pattern
The Pervasive Commerce Portal composite runtime pattern supports this Runtime pattern since the Pervasive Commerce Portal composite runtime pattern is based on a physical and logical separation of concerns between the view, logic, security, and data sources systems. When this separation of concerns occurs, there can be a single security mechanism that handles credential authentication and user authorization for all applications and data sources.

Note that this is an ideal situation and, unfortunately, is not practical in environments where there are existing IT systems (which is most environments). Consider this when there is an opportunity to re-architect the existing infrastructure in an end-to-end manner.

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

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