Skip to main content

Portal: Select Application pattern

Overview

After identifying the Business and Integration patterns that comprise the Portal composite pattern, the next step in planning an e-business application is to choose the Application pattern(s) that apply to the business drivers and objectives. An Application pattern shows the principal layout of the application, focusing on the shape of the application, the application logic, and the associated data.

The selection of an Application pattern is based on the selected Business patterns, Integration patterns, and Composite patterns. The Application patterns use logical tiers to illustrate various ways to configure the interaction between users, applications and data.

The building of each solution requires that specific business drivers be satisfied. There is a high probability that each solution will share characteristics with many of the Application patterns mentioned; however, the Application patterns available range from simple to more complex. Therefore, chose the simplest Application pattern that satisfies the requirements of your business objectives.

Each Application pattern has associated Business and IT drivers. The architect should review each of the Business and IT drivers with the associated Application pattern to determine the best fit for the requirements.

Recall the Business and Integration patterns identified earlier as the mandatory building blocks of the Portal composite pattern were:

Portal application patterns

The figure below shows the specific Application patterns that can be used to enable various types of functionality found in each Business and Integration pattern. Note that some of these Applications are mandatory (blue type) to a properly-functioning Portal, and some are optional (red type).

This figure differs slightly from the original redbook (SG24-6087) because the Dec 2004 re-engineering of the Information Aggregation and Data Integration patterns changed some of the Application pattern names.

Portal application patterns

The specific Application patterns that can be used to enable various types of functionality found in each Business and Integration pattern are:

  • Access Integration
    • Web Single Sign-On
    • Personalized Delivery
    • Extended Single Sign-On (optional)
    • Pervasive Device Access (optional)
  • Self Service
    • Directly Integrated Single Channel
  • Collaboration
    • Store and Retrieve
    • Directed Collaboration (optional)
  • Information Aggregation
    • User Information Access
  • Extended Enterprise (optional)
  • Application Integration
    • Population
    • Population=Multi Step Gather
    • Population=Multi Step (optional)

Though a complete Portal solution requires multiple Application patterns, each Application pattern can be analyzed individually in terms of the functionality it brings to the overall solution, and the business and IT drivers it satisfies. Review the following Application patterns and select those for which you would like to see additional Runtime information.

SOA

The original set of PI patterns is intended to satisfy a wide generic set of integration requirements, not just SOA. The SOA profile specialises these more general patterns for the SOA environment.

Access Integration::Web Single Sign-On application pattern

Select this Application pattern
Access Integration::Web Single Sign-On application pattern

The Web Single Sign-On application pattern (as part of the Access Integration pattern) provides a framework for seamless application access through unified authentication services.


Business and IT Drivers

The primary business driver for choosing this Application pattern is to provide seamless access to multiple applications with a single sign-on while continuing to protect the security of enterprise information and applications.

Simplification and increased efficiency of user profile management is the main IT driver for Single Sign-On.


Benefits

Limitations

Many existing applications are not capable of accepting a standard set of user credentials as a substitute for local authentication. Integration with such systems can be difficult or even impossible.


The Portal composite pattern

A fundamental characteristic of a portal implementation is that of information aggregation. In order to enhance this experience for the user, a Single Sign-On (SSO) solution makes sense. This allows the user to more quickly access the information and avoid worrying about which application they are accessing. It also allows for easier maintainability by the organization sponsoring the portal.

Single Sign-On functionality requires more than just making sure that the applications that already exist in an enterprise support a central authentication capability. The existing processes must be changed to accommodate this new method of validating a user’s access capability. An analysis of the existing profiling mechanisms and overall security policies in a organization is the starting point for this type of effort.

For more information, please see the IBM Redpaper A Secure Portal Extended With Single Sign-On, REDP-3743.

Access Integration::Pervasive Device Access application pattern

Select this Application pattern
Access Integration::Pervasive Device Access application pattern

The Access Integration pattern is used to provide consistent access to various applications using multiple device types. In order to provide pervasive device access to an existing Business pattern, the Pervasive Device Access application pattern adds a new tier to the architecture. This tier is responsible for the pervasive extensions to the original application. The function of this tier is to convert the HTML issued by the application presentation logic into a format appropriate for the pervasive device. In this way, the Pervasive Device Access application pattern provides a structure for extending the reach of individual applications from browsers and fat clients to pervasive devices such as PDAs and mobile phones.


Business and IT Drivers

Striving to provide universal access to information and applications is often the primary business driver for choosing this Application pattern. The primary IT driver for choosing this Application pattern is to quickly extend the reach of applications to new device types without having to modify every individual application to enable its use by additional device types.


The Portal composite pattern

The Portal composite pattern supports the use of pervasive device access. In fact, "any type of device" access is supported through the use of templates in the pervasive access device tier. At this tier, the session data containing the type of device is known and the properly formatted content can be delivered. This formatted content can be transcoded in content management or datasource nodes, or it can be transcoded "dynamically" when requested by a specific type of client. This will depend on the frequency of updates to the data.

It is architecturally sound to separate the storage, management, and transcoding of content from the presentation of that content. This means that it is best to allow the content management system to reduce the requirements of the Web server tier to the output of this already formatted content.

Access Integration::Personalized Delivery application pattern

Select this Application pattern
Access Integration::Personalized Delivery application pattern

The Access Integration::Personalized Delivery application pattern provides a framework for giving access to applications and information tailored to the interests and roles of a specific user or group. This Application pattern extends basic user management by collecting rich profile data that can be kept current up to the user’s current session. Data collected can be related to application, business, personal, interaction, or access device-specific preferences.


Business and IT Drivers

The primary business driver for choosing this Application pattern is to increase usability and improve the efficiency of Web applications by tailoring their presentation to the user’s role, interests, habits and/or preferences.


Benefits

Limitations

Personalized Delivery can be very complex and expensive to fully implement.


The Portal composite pattern

This Application pattern supports the separation of the business logic, business rules, and presentation. Each one of these has part of the responsibility for providing the personalized experience to the user of the portal. The application server handles business logic that implements the business rules meta-data contained in the personalization server node. Once presentation of the personalized data is required, the presentation server node will access the correctly formatted and/or aggregated data for display to the portal user.

Self-Service::Directly Integrated Single Channel application pattern

Select this Application pattern
Self-Service::Directly Integrated Single Channel application pattern

The Directly Integrated Single Channel application pattern (from the Self-Service business pattern) provides a structure for applications that need one or more point-to-point connections with back-end applications but only need to focus on one delivery channel. This Application pattern can also be used to implement any one of the delivery channels.


Business and IT Drivers

The primary business driver for choosing this Application pattern is to reduce the latency of business events by providing real-time access to back-end applications and data from Web applications.

The IT Driver for choosing this Application pattern is to leverage legacy investments and existing skills.


The Portal composite pattern

The Portal composite pattern is involved in the direct connection between the portal user and a back-end application (e.g. Lotus Sametime or CICS based application). Once the portal user is authenticated via the directory and security services node and the session level security in the application server node, the WPS Portlet API will pass authentication credential information to the back-end application or datasource. Once complete, the user will now have a direct connection to that application and the portal system will not generally broker the communication. This works in most implementations.

As shown in the figure below, the Directly Integrated Single Channel application pattern can be used in a variety of ways. For example, the portal application can be more than just green screen scraping with Host on Demand/Host Publisher portlet. The portal application can also be a collaboration portlet using collaboration services as well as a roll your own portlet for using Web services.

Directly Integrated Single Channel application pattern

The Physical device can be:

  • Browser
  • Visual Phone

The Portal view can be:

  • Browser
  • Visual Phone

The Portal application can be:

  • HOD/HP portlet
  • None
  • Re-engineer JSP/iFrame
  • RYO portlet + JCA/CTG
  • RYO portlet + JCS/IMS Conn. for Java
  • RYO portlet + JMS/MQ Classes
  • RYO portlet JDBC
  • RYO portlet + Web services
  • Local portlet
  • Collab portlets
  • iView ERP portlets
  • Web page portlet

New or existing Apps, DBs, Services or Portlets can be:

  • Green Screen
  • C/S GUI
  • Browser UI
  • CICS
  • IMS
  • MQSeries
  • DB2/OEM DB
  • Web Service
  • Web Service (remote portlet)
  • Collab Service
  • iView
  • Content Service

Collaboration::Store and Retrieve application pattern

Select this Application pattern
Collaboration::Store and Retrieve application pattern

The Store and Retrieve application pattern (as part of the Collaboration business pattern) allows users to collaborate with others on the network interactively. Unlike the Point-to-Point application pattern, this pattern does not require both partners to be online at the same time. It also does not require the client to know the physical or direct address of other users of the solution.

A common implementation of this pattern is content management. Content Management allows two or more users to interact on a single piece "content" (e.g. images, text, other data, etc.) via the content management mechanism.


Business and IT Drivers


Guidelines for use

This Application pattern should be used when:


Benefits

Limitations


The Portal composite pattern

The Portal composite pattern supports this through the use of the content management and collaboration nodes. Content Management can provide asynchronous collaboration on content assets or documents and the collaboration can be in the form of threaded discussion forums or teamrooms where information is shared in a common space.

Collaboration::Directed Collaboration application pattern

Select this Application pattern
Collaboration::Directed Collaboration application pattern

The Collaboration::Directed Collaboration application pattern allows users to collaborate with others on the network interactively. This Application pattern requires the two interacting users to be online simultaneously. It also requires users to register with a server. In this pattern all of the users are peers and there are no client-server or master-slave relationships between the tiers in the pattern.


Business and IT Drivers

This approach can be used to quickly establish collaboration between users of a solution without having to go through the process of developing a lot of custom code. It allows users to simultaneously and interactively modify shared applications and data.

This pattern requires all the users to register with the server. The user’s profile, preferences and security privileges are stored on a server directory. This means that the client does not need to know the physical or direct address of other clients. It also allows us to implement different security levels, and implement more complex collaboration styles that include sharing applications and complex data types.

This is the ideal Application pattern to choose if the current focus is to establish synchronous sophisticated collaboration functions within a solution. This solution is also applicable when the clients have permanent and preferably high-speed network connections. The solution is also cost-effective to develop because many of these functions are available in off-the-shelf products.

This pattern is not a good fit for solutions where there are limitations on the processing power of the clients.


The Portal composite pattern

Collaboration in the case of the Portal composite pattern is usually enabled through this type of collaboration. It is generally in the form of instant messaging because communication is essentially a brokered real-time interaction.

Information Aggregation::User Information Access application pattern

Select this Application pattern
Information Aggregation::User Information Access application pattern


Business and IT Drivers


Benefits

The use of read-only data provides for maximum consistency in a multi-user analysis or reporting environment.

Limitations

As mentioned, the vast majority of access to data in the UIA pattern is read-only. However, this is really a convention, since UIA products and the data access methods they use are fully open to read/write access as well. As shown in the figure above, read/write access, when allowed, should be against data sources that are not owned or managed by applications. This reduces the risk to data integrity somewhat, but does not eliminate it entirely, depending on how the data source is maintained.


The Portal composite pattern

The Portal composite pattern supports this through the use of the Search & Indexing node. For more information on this application pattern, please see the IBM Redbook Patterns: Information Aggregation and Data Integration with DB2 Information Integrator, SG24-7101.

Application Integration::Population application pattern

Select this Application pattern
Application Integration::Population application pattern

The Application Integration::Population application pattern structures the population of a data-store with data that requires minimal transformation and restructuring. The Population application pattern is a preparatory step and is not documented to the Runtime pattern level for the Portal composite pattern.


Business and IT Drivers

The primary business driver for choosing Population is to copy data from the source data store to a target data store with minimal transformation. The main reason for creating a copy of the data is to avoid manipulating the primary source of a company’s operational data often maintained by Operational Systems.


The Portal composite pattern

The Portal composite pattern supports this no-transformation population through a centralized database server. However, in many installations, data will be transformed before reaching its final destination (e.g. database or file system for serving to the web).

For more information on this application pattern, please see the IBM Redbook Patterns: Information Aggregation and Data Integration with DB2 Information Integrator, SG24-7101.

Application Integration::Population=Multi Step application pattern

Application Integration::Population=Multi Step application pattern

The Information Aggregation::Population=Multi Step application pattern structures the population of a data-store with structured data that requires extensive reconciliation, transformation, and restructuring.


Business and IT Drivers

The primary business driver for choosing Population=Multi Step is to reconcile data from multiple data sources and to transform and restructure it extensively to enable efficient access to information.

This Application pattern is best suited for the aggregation and distillation of meaningful information from structured data.


Benefits

This is the ideal architecture when the complex transformation of structured data between the source and target data store is required.

Limitations

Reconciling data from multiple sources is often a complex undertaking and requires a considerable amount of effort, time, and resources. This is especially true when different systems use different semantics.


The Portal composite pattern

The Portal composite pattern supports the iterative transformation of data. This data transformation can take place in the datasource tier, in the content management node, in the presentation server node, or at the application server node (although this is not a suggested route). This pattern supports all of these options.

Application Integration::Population=Multi Step Gather application pattern

Select this Application pattern
>Application Integration::Population=Multi Step Gather application pattern

The Data Integration::Population=Multi Step Gather application pattern provides a structure for applications that retrieve and parse documents and create an index of relevant documents that match a specified selection criteria. This design is actually a specific instance of the Population application pattern described above. In practice, this design may also extend the Population=Multi Step application pattern, when transformation of data is required. In either case, the crawling and discovery mechanisms of this design aggregate a set of unstructured data. This pattern is also useful for solutions where there is a need to discovery content expertise within the organization.

The Population=Multi Step Gather application pattern is a preparatory step and is not documented to the Runtime pattern level for the Portal composite pattern.


Business and IT Drivers

The primary business driver for choosing Population=Multi Step Gather is to select relevant documents from a vast set of documents based on specified selection criteria. The objective is to provide quick access to useful information instead of bombarding the user with too much information.

Search engines that crawl the World Wide Web implement this Application pattern. It is best suited for selecting useful information from a huge collection of unstructured text data. A variation of this Application pattern can be used for working with other forms of unstructured data such as images, audio, and video files.


The Portal composite pattern

In any portal implementation, the ability to locate data and information as it is updated in the system is vital. The whole value proposition depends, in part, on a portal user’s ability to locate the information they need. The Portal composite pattern supports this through the Search and Indexing node. This represents both the ability to "free-text" search or navigate the content (but only that content that should be available to the user) and to index the content as it is updated.

Content navigation