zzPortal: Select Application pattern

http://www.ibm.com/developerworks/patterns/portal/select-application-topology.html

 

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:

• Access Integration
• Self-Service
• Collaboration
• Information Aggregation
• Application Integration

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).

Portal application patterns
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.

Application patterns
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.

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

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

Benefits

• Users can access their application portfolio 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.

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

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

• Provide universal access to information and services
• 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.

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

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

• 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.

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

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

• Improve the organizational efficiency
• Reduce the latency of business events
• Leverage existing skills
• Leverage legacy investment
• Back end application integration

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.

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

• Time to market
• Improve the organizational efficiency
• Reduce the latency of business events
• Easy to adapt during mergers and acquisitions
• Require deferred collaboration
• Many users
• Leverage existing skills
• Network addressing independence
• Managed service
• Maintainability

Guidelines for use
This Application pattern should be used when:

• The physical or direct addresses of other clients on the network are not known
• The pattern can support both synchronous and asynchronous communication. This provides ability to support a wide range of solutions from bulletin boards and workrooms to interactive chat rooms
• A server can be set up that will allow multiple clients to log in and share information with other users by posting messages on (or sending e-mail to) the server for later retrieval

Benefits

• This Application pattern is simple to implement
• Since this Application pattern does not require that a client know the direct address of the destination, it is ideal for solutions where the network addresses are not published or where these addresses change frequently
• Most of the functions of this pattern can be implemented using commercially available collaboration solutions
• This pattern requires very minimal custom code and is cost effective to maintain

Limitations

• This pattern calls for the implementation of server software and associated hardware to support new users. This means that this will add to the overall complexity of the solution
• The nature and type of collaboration supported by this pattern are simplistic. For more complex communications, later Application patterns are more appropriate

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

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

• Time to market
• Improve organizational efficiency
• Reduce the latency of business events
• Easy to adapt during mergers and acquisitions
• Require instantaneous collaboration
• Many users
• Leverage existing skills
• Network addressing independence
• Managed service
• Maintainability
• Complex data types
• Significant network bandwidth

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

Business and IT Drivers

• Require specialized derived data (e.g. subset, point in time, correlated datat, targeted to user group etc)
• Distil meaningful information from a vast amount of sructured and unstructured data
• Require R/O access to derived or aggregated data allowing data manipulation under user control
• Require option to drill through source data
• Require reliable, extended availability of the data
• Optimized for future access performance
• Require protection of operational system performance

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

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

• Improve organizational efficiency
• Reduce the latency of business events
• Distill meaningful information from a vast amount of structure data
• Minimize total cost of ownership (TCO)
• Promote consistency of Operational Data
• Maintainability

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

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

• Improve organizational efficiency
• Reduce the latency of business events
• Distill meaningful information from vast amounts of structured data
• Extensive reconciliation, transformation, and restructuring of structured data
• Minimize total cost of ownership (TCO)
• Promote consistency of Operational Data
• Maintainability

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

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

• Improve organizational efficiency
• Reduce the latency of business events
• Provide easier access to vast amounts of unstructured data through indexing and categorization
• Reduce information overload
• Identify the experts for collaboration to improve decision cycle times
• Reduce knowledge loss from personnel turnover
• Help new employees to reduce the learning curve
• Minimize total cost of ownership
• Promote consistency of Operational Data
• Maintainability

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.