Implementation

The application working with the journal service (either a JDBCJournal class instance or any other user-written service that subclasses from Journal or that implements the JournalService interface) should always work with the JournalService interface instead of casting the object returned by the toolkit externalizer to the specific Java type implementing this interface. This makes particular implementations of the JournalService transparent to the application implementation at any time. Using this approach enables you to use a dummy journal service during development and later change it to the real journal service. To access the appropriate service instance, you only need to modify the external toolkit definition files (services and context definitions), as required by the environment. It is not necessary to modify the written application.

A journal keeps information about the daily operations performed in a branch. The type of information to be included, as well as when that information is to be written, is part of the design of the teller application. A journal record consists of a string of bytes containing the data that the operation wants to store, formatted in a certain way. Each journal record is identified by a unique record number, which is maintained by the journal object. Record numbers are always increasing, although they are not necessarily consecutive.

Different tables within a journal can be organized by user, by workstation, or by any other criterion. Because there can be different tables for a single journal entity, it is possible to define a journal for a certain entity, where the journal comprises the set of journal tables belonging to that entity.

The period over which a journal table exists is normally one day. Therefore, a reference to the journal of a certain entity usually refers to today's journal, a unique table known as the current journal. Older data for the same entity is kept in other journal generations. The system is predefined to keep a fixed number of journal generations for every entity (usually six, which is one working week). At the abstract class level, only the current journal can be accessed. Access to older generations is defined at each platform implementation level.

Two processes are used to define the characteristics of the Electronic Journal:

Journal objects are inactive just after instantiation, and no connection to the database is set at that point. The application must request the database connection and send the open() method to the journal instance to make it active. The open() method selects the table that this journal instance is going to use, and the current journal will work with it for any database operation that is requested while the instance is active. A close() message reverts the state back to inactive, and closes or releases the database connection (if connection pooling is being used).

The current journaling date, a java.lang.String instance with a format of yyyymmdd (yyyy = year, mm = month, dd = day), is obtained by calling the today() method of the journal instance as soon as it is created. The default implementation of this method returns the system date, but this date can be overwritten if a different behavior is required (for instance, the current journaling date can be tomorrow if the current system time is later than 6:00 p.m.). When a journal is opened, the date of the current journal table and the current journaling date are compared. If the latter is greater, then the next generation is selected for the specific entity (and the oldest generation is deleted if the maximum number of generations is reached). If the dates are equal, then the current generation is opened.