IBM WebSphere Multichannel Bank Transformation Toolkit, Version 7.1

Implementation

The toolkit provides the following:

Class diagram showing relationships among the JDBC store, StoreService interface, and Store class

The application working with the Store service (either a JDBCStore class instance or any other user-written service that subclasses from Store or implements the StoreService interface) should always work with the StoreService interface, instead of casting the object returned by the toolkit externalizer to the specific Java type implementing this interface. This makes the application code independent of the actual store service implementation used at any time. During development, you can use a dummy store service that will later be replaced by the real store service. You will only have to modify the toolkit definition files, not the application code, to access the appropriate service instance.

The Store class provides facilities to off-line operations for storing and updating data, and to a forwarder for retrieving and deleting the data when it is processed. Although an operation may need to store its data in more than one STORE table, a Store object works with only one table at a time. Therefore, if the operation needs more than one table to keep its information, it should instantiate several Store objects. When you are designing a teller application, the information to be included in each STORE table is part of that design. You will also need a specific off-line processing policy to determine when the operation information must be added to the STORE table and when the forwarder application will go through all the pending operations and try to execute them.

As described previously, each store record has a record mark that is used by the formatter to determine its status: added, updated, or retrievedForForwarding. These record marks are retrieved from a StoreConstants class.

A retrievedForForwarding mark does not mean that the record has successfully arrived at the host system. The forwarder is responsible for processing records marked as retrievedForForwarding once it receives positive acknowledgment from the host application. In this case, it can delete the record from the STORE table so that the next time it is processed, any retrievedForForwarding record can be sent to the host as potentially duplicated. Each forwarder will decide which criteria to follow.

Store objects are inactive just after instantiation; initially, no connection to the database has been set. The application must first request a database connection from the store instance and then explicitly call the open() message to make it active. A close() message reverts the state back to inactive. Most of the store object operations (for instance, changing the table associated with that store object) can be run only if the store object is active.

See Creating a forwarder application for more information about how the store-and-forward process works.



Feedback