Chapter 3: Selecting the Application Patterns

After identifying the Composite, Business and Integration patterns that comprise the Pervasive solution, 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 Application patterns use logical tiers to illustrate various ways to configure the interaction between users, applications, and data. Based on the Application patterns, a set of Runtime patterns is identified. These Runtime patterns are discussed in Chapter 4, "Selecting the Runtime patterns" on page 39.

3.1 Application patterns described

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. In this section, the Application patterns that apply to the Access Integration pattern are described. Please note that you may have different Application patterns based on your business requirements.

We did not need to introduce any new Application pattern for our solutions to implement Pervasive Portal applications.

3.1.1 Access Integration application patterns

Application patterns for Access Integration are composed of four services described on the patterns Web site found at:

• http://www-106.ibm.com/developerworks/patterns/access/index.html

Based on the specific installation needs of the application being built, developers can mix and match these services to facilitate consistent and seamless access to multiple applications. Three commonly observed Application patterns for Access Integration are presented below. It is highly probable that a solution will utilize more than one of these Application patterns.

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, we therefore need to use an Access Integration application pattern as shown in Figure 3-1 on page 29. The Pervasive Device Access application pattern brings a new tier into the architecture. This tier is responsible for the pervasive extensions to the original application. The function of this tier is to convert the source (for example 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.

Figure 3-1: Access Integration ” ”Pervasive Device Access

Business and IT drivers

• Provide universal access to information and services

• Reduce time to market

• Reduce Total Cost of Ownership (TCO)

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.

Note  

WebSphere Everyplace Access V4.2 currently supports different types of wireless phones and PDAs.

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 device access 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.

Web Single Sign-On application pattern

The Web Single Sign-On application pattern provides a framework for seamless application access through unified authentication services. Figure 3-2 shows an example of this pattern.

Figure 3-2: Access Integration ” ”Web Single Sign-On

Business and IT drivers

• Provide Single Sign-On across multiple applications

• Reduce Total Cost of Ownership (TCO)

• Reduce user administration cost

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 are the main IT driver for Single Sign-On.

Benefits

• Users can access their application portfolios easily and securely.

• User profile information is centralized in a common directory, simplifying profile management and reducing costs.

• Application development cost is reduced by providing a standard security solution.

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 .

Personalized Delivery application pattern

The 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. An example of the Personalized Deliver application pattern is shown in Figure 3-3.

Figure 3-3: Access Integration ” ”Personalized Delivery

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

• Users' interaction with the site is benefited because of increased perception of control and efficiency.

• Fine-grained control of users' access to applications is enabled according to role and preferences by the enterprise.

• Improved user effectiveness is enabled by adapting the complexity and detail of content to a user's skill level.

Limitations

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

3.1.2 Self-Service application patterns

As you can see in Figure 3-4, the Self-Service business pattern covers a wide range of uses. Applications of this pattern can range from the very simple function of allowing users to view data built explicitly for one purpose, to taking requests from users, decomposing them into multiple requests to be sent to multiple, disparate data sources, personalizing the information, and recomposing it into a response for the user. For this reason, there are currently seven defined Application patterns that fit this range of function. We summarize these for you here. More detailed information can be found in Patterns for e-business: A Strategy for Reuse , by Jonathan Adams, Srinivas Koushik, Guru Vasudeva, and George Galambos.

Figure 3-4: Self-Service application patterns

1. Stand-alone Single Channel application pattern: provides for stand-alone applications that have no need for integration with existing applications or data. It assumes one delivery channel, most likely a Web client, although it could be something else. It consists of a presentation tier that handles all aspects of the user interface, and an application tier that contains the business logic to access data from a local database. The communication between the two tiers is synchronous. The presentation tier passes a request from the user to the business logic in the Web application tier. The request is handled and a response sent back to the presentation tier for delivery to the user.

2. Directly Integrated Single Channel application pattern: provides point-to-point connectivity between the user and existing back-end applications. As with the Stand-alone Single Channel application pattern, it assumes one delivery channel; the user interface is handled by the presentation tier. The business logic can reside in the Web application tier and in the back-end application. The Web application tier has access to local data that exists primarily as a result of this application, for example, customer profile information or cached data. It is also responsible for accessing one or more back-end applications. The back-end applications contain business logic and are responsible for accessing the existing back-end data. The communication between the presentation tier and Web application tier is synchronous. The communication between the Web application tier and the back-end can be either synchronous or asynchronous, depending on the characteristics and capabilities of the back-end application.

3. As-is Host application pattern: provides simple direct access to existing host applications. The application is unchanged, but the user access is translated from green-screen type access to Web browser-based access. This is very quickly implemented but does nothing to change the appearance of the application to the user. The business logic and presentation are both handled by the back-end host. Because the interface is still host driven, this is more suited to an intranet solution where employees are familiar with the application.

4. Customized Presentation to Host application pattern: this is one step up from the As-is Host application pattern. The back-end host application remains unchanged, but a Web application now translates the presentation from the back-end host application into a more user-friendly, graphical view. The back-end host application is not aware of this translation.

5. Router application pattern: the Router application pattern provides intelligent routing from multiple channels to multiple back-end applications using a hub-and-spoke architecture. The interaction between the user and the back-end application is a one-to-one relation, meaning the user interacts with applications one at a time. The router maintains the connections to the back-end applications and pools connections when appropriate, but there is no true integration of the applications themselves . The router can use a read-only database, most probably to look up routing information. The primary business logic still resides in the back-end application tier.

   This pattern assumes that the users are accessing the applications from a variety of client types such as Web browsers, voice response units (VRUs) or kiosks . The Router application pattern provides a common interface for accessing multiple back-end applications and acts as an intermediary between them and the delivery channels. In doing this, the Router application pattern may use elements of the Integration patterns.

6. Decomposition application pattern: the Decomposition application pattern expands on the Router application pattern, providing all the features and functions of that pattern and adding recomposition/decomposition capability. It provides the ability to take a user request and decompose it into multiple requests to be routed to multiple back-end applications. The responses are recomposed into a single response for the user. This moves some of the business logic into the decomposition tier, but the primary business logic still resides in the back-end application tier.

7. Agent application pattern: the Agent pattern includes the functions of the decomposition tier, plus it incorporates personalization into the application to provide a customer-centric view. The agent tier collects information about the user, either from monitoring their habits or from information stored in a CRM. It uses this information to customize the view presented to the user.

Stand-Alone Single Channel application pattern

The application in this book is based on the simplest pattern, the Stand-Alone Single Channel application pattern. This pattern provides for stand-alone applications that have no need for integration with existing applications or data. It assumes one delivery channel, most likely a Web client, although it could be something else. It consists of a presentation tier that handles all aspects of the user interface, and an application tier that contains the business logic to access data from a local database. The communication between the two tiers is synchronous. The presentation tier passes a request from the user to the business logic in the Web application tier. The request is handled and a response is sent back to the presentation tier for delivery to the user.

There are other IBM Redbooks on the Self-Service Business pattern which you can reference:

• Self-Service Patterns using WebSphere Application Server V4.0 , SG24-6175

• Patterns: Connecting Self-Service Applications to the Enterprise , SG24-6572

• Self-Service Applications using IBM WebSphere V4.0 and IBM MQSeries Integrator , SG24-6160

• Patterns on z/OS: Connecting Self-Service Applications to the Enterprise , SG24-6827

• Patterns: Building Messaging-based and Transactional Applications , SG24-6875

3.1.3 Identified Application patterns for the Portal composite pattern

The Business and Integration patterns that we have identified as the building blocks to the Portal composite pattern are:

• Access Integration

• Self-Service

• Collaboration

• Information Aggregation

Note  

The discussions involving the identified Application patterns use this naming convention:

 <business/integration pattern name>::<application pattern name> 

For example, in discussing the Access Integration pattern and the Web Single Sign-On application pattern, the format is:

 Access Integration::Web Single Sign-On 

Figure 3-5 shows the identified Application patterns that make up a Portal composite pattern.

Figure 3-5: Application patterns in a Portal composite pattern

Over time in the marketplace , the definitions of the Composite patterns are becoming more defined. The mandatory patterns represent the occurring patterns that are being implemented by companies in a portal solution. The optional patterns are not yet implemented with each portal solution but are optional for a specific company's requirements and would be implemented as a Portal custom design. Over time, we may see that all the patterns in Figure 3-5 on page 35 are shown as mandatory. For now, the mandatory and optional patterns for the Portal composite pattern are as follows :

• Mandatory Business and Integration::Application patterns

  • Access Integration::Single Sign-On, Personalized Delivery

  • Self-Service::Directly Integrated Single-Channel

  • Collaboration::Store and Retrieve

  • Information Aggregation::Population Single Step, Population Crawling and Discovery

• Optional Business and Integration::Application patterns

  • Access Integration::Pervasive Device Access

  • Collaboration::Directed Collaboration

  • Information Aggregation::Population Multi-Step

These identified Application patterns are based on the requirements of a typical portal implementation.