12.4 Architectural Patterns

Architectural patterns are templates that represent generic functions required by the system. Patterns can be used as a guide by component developers. This section describes some patterns that can be applied in developing an enterprise information system: data access within the system, business object, data access involving an external system, report, ad hoc query, batch roll-up, continuously updated roll-up, transaction, and data warehouses.

Each architectural pattern describes the motivation for using the pattern, as well as a UML sequence diagram accompanied by a step-by-step explanation of the component interactions defined by the pattern.

Data Access Within the System

Motivation

This pattern is used when an operation accesses data that is fully contained within the system. This pattern should not be used if the operation communicates with an external system using BSRs.

Interaction Sequence

Figure 12-11 shows the sequence of operations for accessing data from a single data component. An operation requiring access to multiple tables would include calls to other data components that have access to the tables.

Figure 12-11. Data access within the system

The sequence of operations for data access within the system is as follows .

1. The GUI confirms the operation to the session manager.

2. The session manager invokes the service component that performs the operation.

3. The service component communicates with the data component that has access to the data.

4. The data component executes the SQL command to select the data.

Data Access Involving An External System

Motivation

This pattern is used when an operation accesses data that is not fully contained within the system. In this case, access to an external system is needed to complete the operation. This pattern assumes that the BSR that returns the data requested by the system exists. If not, a BSR for this purpose must be defined.

Interaction Sequence

Figure 12-12 shows the sequence of operations for a simple example that communicates with an external system. An operation requiring access to multiple tables would include calls to other data components that have access to the tables.

Figure 12-12. Data access involving an external system

The sequence of interactions for an access operation involving an external system is as follows:

1. The GUI confirms the operation to the session manager.

2. The session manager invokes the service component that performs the operation.

3. The service component communicates with the data component that has access to the data.

4. The data component executes the SQL command to obtain the data.

5. Because it has to obtain data from another system, the service component sends a request to the BSR interface.

6. The BSR interface constructs a BSR and sends it to the BSR interface of the external system.

7. The BSR interface of the external system invokes the component that performs the operation.

8. The external components obtain the necessary data.

9. The external BSR interface constructs a BSR with the obtained data and sends it to the RSS BSR interface.

Report

Motivation

A report is a formatted and organized presentation of data. The report pattern is used when a report must be produced in the system. The output for a report can be printed on paper, written to a file, or sent to an external system. It can be generated from the application component or as part of an operation in a service component.

The report is an exception to the rule of always going through business objects to access data, because SQL is recognized as the best way to handle reports . An example of this is the J2EE Fast-Lane Reader pattern, which states:

The Fast-Lane Reader pattern can accelerate the retrieval of large lists of items from a resource. Instead of going through an enterprise bean, an application accesses data more directly by going through a data access object. This way, the application avoids the overhead associated with using enterprise beans (remote method invocation, transaction management, data serialization, etc.). [J2EE 01b]

Reports use the JDBC-based reporting layer to access data used only for display, because, in this case, transactional support is unnecessary. (When the application needs to update the database transactionally , it uses enterprise beans.)

Another option for reports is stored procedures in the database. These procedures can be written in SQL as either PL/SQL-stored procedures or Java-stored procedures. ^[2] However, this option makes the reports database dependent. If the database changes, all the procedures stored in the database must be ported to the new database. Additionally, even though most databases support standard SQL, some have enhancements or additional features that, for example, work only for that particular database and can be used only inside PL/SQL. If this is the case, the procedures will not work when ported to the new database. Another potential problem is that the new database may not support Java-stored procedures.

^[2] These are the options for writing stored procedures in Oracle. Other databases may have other options.

Interaction Sequence from an Application Component

The sequence of operations for a report executed from an application component is shown in Figure 12-13. The report output is not represented in the sequence diagram but should be defined in the report.

Figure 12-13. Sequence diagram for a report executed from an application component

The sequence of interactions for a report executed from an application component is as follows.

1. The GUI confirms the operation to the session manager.

2. The session manager invokes the report script.

3. The report script invokes the Java program, which uses JDBC to access the database, for the report in the reporting layer.

4. The reporting layer obtains the information from the tables in the database.

Interaction Sequence from a Service Component

The sequence of operations for a report executed from a service component is shown in Figure 12-14. The report output is not represented in the sequence diagram but should be defined in the report.

Figure 12-14. Sequence diagram for a report executed from a service component

The sequence of interactions for a report executed from a service component is as follows.

1. The GUI confirms the operation to the session manager.

2. The session manager invokes the service component that performs the operation.

3. The service component executes the operation.

4. The service component invokes the Java program, which uses JDBC to access the database, for the report in the reporting layer.

5. The reporting layer obtains the information from the tables in the database.

Ad Hoc Query

Motivation

This pattern is used to obtain information from the database when no predefined report or operation returns the data in the desired form. Ad hoc queries are also an exception to the constraint of going through business objects to access data.

Interaction Sequence

Figure 12-15 shows the sequence of operations for an ad hoc query using a generic query-builder tool. Another option for entering ad hoc queries is to use SQL directly.

Figure 12-15. Sequence diagram for an ad hoc query

The sequence of interactions for an ad hoc query is as follows.

1. The GUI confirms the query to the session manager.

2. The session manager invokes the generic query builder.

3. The generic query builder sends the user query to the SQL engine.

4. The SQL engine retrieves the results from the tables in the database.

Roll-Ups

Roll-ups are persistent reports (summaries) that require consolidating data from one or more tables, potentially located on different machines or different locations. There are two types of roll-ups. On-the-fly roll-ups are generated as needed from the operational data and can be treated as reports. Persistent roll-ups are incrementally updated so that the information can be quickly provided when required. Persistent roll-ups use tables to synchronize roll-up data with operational data. Roll-up tables have an associated data component, shown in Figure 12-16, located inside a business object. The roll-up tables are either batch updated or continuously updated, but the actual roll-up generation is a report and is treated as such.

Figure 12-16. Roll-up data component

Batch Roll-Up

Motivation

The batch roll-up pattern is used when an operation requires data to be extracted from different sources and consolidated in a persistent table that does not need to be immediately synchronized with the tables from which it obtains its data. A procedure is executed on demand to synchronize the roll-up table with its related tables.

Interaction Sequence

Figure 12-17 shows a sequence diagram for a roll-up table that needs to synchronize with one other table. If the number of related tables is greater, a SELECT operation has to be performed against each of the tables to obtain the necessary data.

Figure 12-17. Sequence diagram for a batch roll-up

The sequence of interactions during on-line transaction processingday-to-day operationsis as follows.

1. The GUI confirms the operation to the session manager.

2. The session manager invokes the service component for the operation.

3. The service component communicates with the data component that has access to the data.

4. The data entity executes the necessary SQL command to update the data.

The sequence of operations during synchronization once a day, by request, or any other policy is as follows.

1. The GUI confirms the operation to the session manager.

2. The session manager sends a synchronization request to the roll-up data component. ^[3]

   ^[3] This is an exception to the rule of going through a service component to access a data component. It is not necessary to create a service component, because this is a simple batch synchronization operation on the data.

3. The roll-up data component obtains the necessary data from the table associated with the roll-up table.

4. The roll-up data component updates the roll-up table.

Continuously Updated Roll-Up

Motivation

This pattern is used when an operation requires data to be extracted from different sources and consolidated in a persistent table that must be immediately synchronized with the tables from which it obtains its data. In a continuously updated roll-up, the roll-up table must be updated every time any of its associated tables is updated. This operation is based on the Subject-Observer pattern [Gamma 95]. In this case, the roll-up table acts as the observer by registering an interest in knowing when its associated tables have been updated. The associated tables are the subject. After this, every time an update occurs, the roll-up table is notified.

Interaction Sequence

Figure 12-18 shows a sequence diagram for a roll-up table that synchronizes with one table. If the number of related tables is greater, a select operation has to be performed against each of the tables to obtain the necessary data.

Figure 12-18. Continuously updated roll-up

Only once, the roll-up data component registers an interest in changes made to Table 1 by sending a registration message to the data component associated with the table. During normal day-to-day operations, the sequence of operations is as follows.

1. The GUI confirms the operation to the session manager.

2. The session manager invokes the service component for the operation.

3. The service component communicates with the data component that has access to the data.

4. The data component executes the necessary SQL command to update the data.

5. The data component notifies the roll-up data component that there has been an update.

6. The roll-up data component obtains the necessary data from the table associated with the roll-up table.

7. The roll-up data component updates the roll-up table.

The operations that take place after the notification can be considered part of the transaction or can be executed outside of the transaction if the response time is inadequate.

Transactions

Motivation

This pattern is used when an operation updates data that is entirely contained within the system. Transactions that span to external systems are not covered in this pattern, because transaction context cannot be maintained when component interactions rely on MQSeries. ^[4] Also, because of the asynchronous nature of message-based communication, the time required to perform the transaction across components can vary.

^[4] This rule does not apply when the business objects are running on the same platform or LAN and are coupled using J2EE transactional method invocation instead of asynchronous message passing.

A transaction is an atomic operation that follows the ACID properties for transaction-processing systems (see Section 8.3). A transaction involves two or more operations on the database, where either all or none of the operations are done. An operation to commit to keep changes (or a rollback operation to remove changes) ends a transaction.

Interaction Sequence

Figure 12-19 shows a sequence diagram for a transaction that updates multiple tables as part of the same transaction. The number of tables updated as part of the transaction is irrelevant, as the EJB framework manages all updates within the same transaction context.

Figure 12-19. Transaction

The sequence of interactions for a transaction is as follows.

1. The GUI confirms the operation to the session manager.

2. The session manager invokes the service component that performs the operation.

3. The EJB framework creates a transaction context.

4. The service component communicates with the first data component participating in the transaction.

5. The first data component executes the necessary SQL command to update the data.

6. The service component communicates with the second data component participating in the transaction.

7. The second data component executes the necessary SQL command to update the data.

8. The EJB framework commits or rolls back the transaction.

Data Warehouses

This pattern is used to interface to data warehouses and data marts. Because data marts are usually subsets of data warehouses, the data warehouses communicate with the operational database, and then the data marts populate themselves from data in the data warehouse. This pattern depends on the specific tool that is used for data warehouse population.

Data warehouses can be populated using either a pull or a push mechanism. With a pull mechanism, the data warehousepopulation application pulls the data from the operational database either by request or through automated update procedures. In this case, an interface to the operational database has to be implemented. With a push mechanism, the operational database pushes data to the data warehouse either by request or through automated update procedures. In this case, an interface to the data warehousepopulation application has to be implemented.

Motivation

If a pull mechanism is implemented, the functionality for data warehouse population resides in a third-party data warehousepopulation tool. This tool can be treated as a business object, with population operations using BSRs if the tool has a BSR-based communication interface. The tool can also be treated as an application-specific component, with population operations using the reporting layer.

Interaction Sequence using BSRs

The pull option for data warehouse population using BSRs is shown in Figure 12-20. The population interactions that take place inside the business objects are omitted in the pull option for data warehouse population using BSRs. The sequence of steps in this option is as follows.

1. The data warehousepopulation application communicates with its BSR interface to request a population operation.

2. The BSR interface constructs a BSR and sends it to the RSS BSR interface.

3. Components inside the RSS obtain the information and use the RSS BSR interface to construct a BSR that sends the requested information to the data warehousepopulation application.

4. The data warehousepopulation application populates the data warehouse with the obtained data.

Figure 12-20. Pull option for data warehouse population using BSRs

Interaction Sequence Using the Reporting Layer

The pull option for data warehouse population using the reporting layer is shown in Figure 12-21. The sequence of steps in the pull option for data warehouse population using the reporting layer is as follows.

1. The data warehousepopulation application communicates with the reporting layer to obtain the data.

2. The reporting layer performs the necessary SQL SELECT operations to obtain the data.

3. The data warehousepopulation application populates the data warehouse with the obtained data.

Figure 12-21. Pull option for data warehouse population using the reporting layer

Motivation

If a push mechanism is implemented, the functionality for data warehouse population resides within the system. As in the previous option, if the tool has a BSR-based communication interface, communication can take place through BSRs. If this is not a possibility, an adapter for communication with the tool should be implemented as a wrapper component.

Interaction Sequence Using the BSRs

Figure 12-22 shows the push option for data warehouse population using BSRs. The operations that take place inside the business objects are omitted in the push option for data warehouse population using BSRs. The sequence of steps in this option is as follows.

1. RSS uses its BSR interface to construct a BSR that sends information to the data warehousepopulation application.

2. The data warehousepopulation application BSR interface sends the data warehousepopulation application the incoming data.

3. The data warehousepopulation application populates the data warehouse with the incoming data.

4. (Optional) The data warehousepopulation application BSR interface constructs a confirmation BSR and sends it back to the RSS BSR interface.

Figure 12-22. Push option for data warehouse population using BSRs

Interaction Sequence Using a Wrapper Component

Figure 12-23 shows the push option for data warehouse population using a wrapper component. The operations that obtain the data from the data components in the push option for data warehouse population using a wrapper component are omitted. The sequence of steps in this option is as follows.

1. A service component sends a request to a wrapper component to populate the data warehouse. Data obtained from the operational database is attached to this request.

2. The wrapper component sends the request and data to the data warehousepopulation application.

3. The data warehousepopulation application populates the data warehouse with the incoming data.

Figure 12-23. Push option for data warehouse population using a wrapper component