OBJECT MODELS FOR BUSINESS TRANSACTION PROCESSING SYSTEMS

This position paper presents some ideas on the use of object modeling for Business Transaction Processing Systems. In particular, I would like to present arguments for what I believe to be the key to successful modeling of transaction processing systems -- the treatment of EVENTs as first class modeling primitives, alongside OBJECTs.

To begin with, I would characterize a Business Transaction Processing Systems (BTPS) as follows:

a. A BTPS tracks the states of objects. The objects are persistent, in that their life extends beyond the life of a user session; and are numerous, in that they typically number more (by orders of magnitude) than the number of processors used to implement the system

b. The states of the objects are altered by events (which reflect instantaneous, atomic changes in the reality being modeled), and a given event may affect the state of more than one object. In general, a given object will be affected by many events during its life. Events are processed as they happen (or soon after -- e.g., they may be batched and submitted overnight).

c. The system must preserve the integrity of the objects, by ensuring:

i) That the sequence of events presented to an object can be given meaningful interpretation (where what is regarded as meaningful is part of the definition of the system)

ii) That it is never possible to observe a state of the system in which the occurrence of the event has been reflected in some but not all of the objects it affects.

d. The system supports many sources (input devices) by which events can be made known to the system. There is no necessary relationship between the source of an event and the object or objects whose states are affected by the event.

The first of these generally requires that the state (this includes data) of objects be stored persistently and, because of the volume, on storage that is relatively cheap. In practice, this means disk.

The second says that the system must be able to update the states of objects, and be able to handle relationships between objects (as reflected by events which affect multiple objects).

The need to preserve the integrity of the objects implies that the system has mechanisms to handle non-meaningful event sequences, either through input mechanisms at data entry time, or by validation and error correction. In addition, where an event affects the state of more than one object, the system must ensure that all objects are updated by the event or none.

The last requires that the system support the possibility of concurrency, because it allows that events which affect the state of a give object could originate simultaneously from different input devices.

EVENTS AS FIRST CLASS MODELLING PRIMITIVES

The "classical" object oriented paradigm uses the notion of OBJECT as the prime modeling primitive. The state of objects is altered by invoking a METHOD. Methods are defined within the context of objects. While it is possible to have methods in different objects with the same name and semantic (polymorphism) there is no sense in which it is possible to have a method defined independently of objects (or classes).

However, to model transaction processing systems, I would suggest that EVENTs should be prime modeling primitives, equal in status to OBJECTs.

First of all, an EVENT is distinguished from an OBJECT by the fact that events are instantaneous and stateless. Objects model the states of quiescent reality, events model atomic changes to reality. (Methods, in the OO sense, may be used to model the affect that an EVENT has on the state and data of an OBJECT, but this is not to equate methods with events -- methods may be defined for other, non transaction related, purposes and, in general, multiple methods in multiple objects will need to be invoked to process a single event instance. Also note that, where an event affects multiple objects, this can result in methods in different objects with the same name -- that of the event -- but this is not polymorphism).

The reasons for proposing the modeling of events separately from objects are as follows:

1. Economy of modeling

Economy of modeling is achieved by the identification of an event which affects more than one object with a relationship between the affected objects. For instance, the MARRY event between two INDIVIDUALs can be identified with the MARRIED relationship between them. This identification allows the normally separate STRUCTURAL MODEL (concerned with the relationships between objects) and DYNAMIC MODEL (concerned with object states and how these states are altered by events) to be collapsed into a single model which defines both.

2. Support for defining the role of the user interface behavior in ensuring system integrity

The key "unit of work" of the user interface of a transaction processing system is the capture of a business event. Using object/event modeling (and defining each object as a state machine which specifies the meaningful events for each object state),means that the meta-data contains enough information to determine the behavior of a user interface that preserves the integrity of the instantiated objects and their relationships (as defined in item c under the BTPS definition above).

For instance, in the example given above, a key part of the user interface will be concerned with capturing the MARRY event. The definition of MARRY will define that the event must be involve two INDIVIDUALs, both of whom (as specified in their state diagrams) must be single to participate in the event. The definition of the event may also specify other attributes (e.g., date, location) associated with the event. From this, it is possible (manually or automatically) to construct a user interface that will present the user with the means to select the individuals (e.g., from pick lists) involved, ensuring that non-eligible individuals (not in the right state to participate in the event) are not shown or are "grayed out".

By adopting this approach systematically, large parts of the behavior of the user interface is derived from, or driven by, the model; and the user interface behavior so defined guarantees the integrity of the object relationships (e.g., in this example, that an individual cannot be simultaneous married to two other individuals).

This relationship between the model and user interface behavior can be exploited, in an extreme form, to provide a completely generated transaction capture interface. While this has been done, with success, to support rapid prototyping, it remains an open question for me whether such a generated interface would be usable in a production system.

3. Providing a focus for implementation in the physical code structure required by DBMS and TP environments which support transaction processing

Implementation of transaction processing systems using the standard technology of today (RDBMS and TP Monitors) requires that physical code is structured according to transactions. In the modeling approach described here, the mapping of the event side of the model onto the physical code structure is trivial -- events map to transactions.

The object side of the model is mapped to server side code which implements required state and data updating. This mapping is not necessarily direct -- depending on the degree of support for objects provided by the implementation environment -- but is never hard (i.e., mechanical transformation to conventional code structures can be employed).

This implementations achieved from these models are generally suitable for multi-tier client/server architectures.

The ideas here are somewhat simplified -- in particular, I have ignored the whole question of derived data, which introduces a further set of considerations and techniques into modeling for transaction processing; and questions of specialization/generalization (i.e., inheritance) which can be appropriate for both objects and events. However, I hope I have indicated how it is possible for both front-end (user interface) and back-end (transaction processing) to be driven from a common object/event based meta-model. Single sourcing front and back end system definition through this meta-model during development maximizes the ease of incremental prototyping/development, and allows interesting code generation and/or model driven processing possibilities in system building.

These ideas have been put into practice in work I have done with colleagues at MCI Corporation (building systems to help track the configuration and capacity of their multiplexed network), and Fannie Mae (to support workflow and business decision processes associated with new business capture).

The author is an IT professional who has been working in systems development for over 15 years, and has been active in the development and use of object modeling techniques and tools in defining and building business transaction processing systems.