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 SystemMotivationThis 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 SequenceFigure 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 .
Data Access Involving An External SystemMotivationThis 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 SequenceFigure 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:
ReportMotivationA 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:
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.
Interaction Sequence from an Application ComponentThe 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.
Interaction Sequence from a Service ComponentThe 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.
Ad Hoc QueryMotivationThis 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 SequenceFigure 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.
Roll-UpsRoll-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-UpMotivationThe 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 SequenceFigure 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.
The sequence of operations during synchronization once a day, by request, or any other policy is as follows.
Continuously Updated Roll-UpMotivationThis 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 SequenceFigure 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.
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. TransactionsMotivationThis 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.
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 SequenceFigure 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.
Data WarehousesThis 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. MotivationIf 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 BSRsThe 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.
Figure 12-20. Pull option for data warehouse population using BSRs
Interaction Sequence Using the Reporting LayerThe 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.
Figure 12-21. Pull option for data warehouse population using the reporting layer
MotivationIf 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 BSRsFigure 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.
Figure 12-22. Push option for data warehouse population using BSRs
Interaction Sequence Using a Wrapper ComponentFigure 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.
Figure 12-23. Push option for data warehouse population using a wrapper component
|