Overview
In the Agent application pattern, the agent tier serves as an integration point for delivery channels in the presentation tier, allowing access to individual back-end applications. In the Runtime pattern, the functions of the Agent tier are performed by a process manager node. The functions of the presentation tier are performed jointly by a Web server redirector and the application server.
Key to this pattern is the use of an operational data store to provide a single point of access for the process manager node to access relevant business data congregated from a wide variety of dissimilar back-end systems.
Agent application pattern: Runtime pattern
Design Last Updated: 9-30-2004
(Click a node to get a detailed explanation.)
In addition to presentation logic (for example, JSPs), the application server contains limited business logic, primarily in the form of the controlling servlets required to access the business processes executing in the process manager node. The application server builds a request based on user input and passes it to the process manager.
The process manager node provides the execution engine for the business processes. It has the capability of executing activities in serial or parallel mode. It can invoke back-end services synchronously or asynchronously. In the event that human interaction is required by the business process, this node creates a work item and identifies a particular person or a department responsible for executing that task and adds the work item to its worklist. Processes that are interrupted can roll back completed tasks, returning the back-end applications to their original state.
A database is used to provide a persistent data storage and retrieval service in support of the execution of the process flow. It holds the process execution rules and intermediate results from the execution of certain activities within the context of an end-to-end process flow. The implementation of this node may involve several persistent data technologies (such as DBMS and flat file) for the different data types.
The operational data store (ODS) provides the data required for business execution in one central location. The ODS is populated in real-time or near real-time with current data from the legacy systems. It contains a subset of data that is relevant to the business processing requirements. The process manager node can access a cross-section of data relevant to the current transaction in a single access to the ODS. This provides performance and management advantages over accessing the data from each legacy system individually. Since the data is transformed in the ODS and not on the legacy system, integration of data during mergers and acquisitions can be done rapidly with little or no disruption to the back-end systems. The data provided by the ODS can be used for a full range of business functions, including personalization, cross-selling, and decision-making.
Building an operational data store can be a complex process. When approaching this task, it is advisable to start with the Data Integration pattern approach to design how the ODS will be populated and maintained. Information about data integration and the appropriate IBM products can be found in Patterns: Information Aggregation and Data Integration with DB2 Information Integrator, SG24-7101.In Figure 3-3 on page 43 the Data Integration::Population pattern is shown as an example.
The primary business logic resides in the back-end applications. Selected data from these systems is replicated to the ODS for use by business processes.