Business Objects vs. Business Transactions: Object Model Challenges in Implementing a Transaction Monitor for a Clinical Patient Data System

OOPSLA'97 Mid-year Workshop Position Paper on Business Transactions

Quentin King and Jeff Sutherland, IDX Systems Corporation

Summary

Microsoft Transaction Server is being considered for deployment of business transaction logic in a three-tier environment. In these discussions, questions arise about the differences between business objects and business transactions. A proposal is included for a pilot project to evaluate the product.

Overview: Microsoft Transaction Server

Microsoft Transaction Server (MTS) provides an infrastructure, for development of multi-tier client/server applications. It includes many of the features of a traditional DBMS transaction monitor, in addition to those of an object request broker.

MTS was designed to allow business transactions to be visualized from the perspective of a single user, without considering issues such as multi-user concurrency, security, transaction control, distributed processing, and other "complications." Business transactions are encapsulated in components that can be managed "from the outside" by MTS to provide many of these services. More complex business transactions can be built as packages of components that interact with one another. This single-user perspective seeks to simplify the design phase, so that attention can be focused on the business logic, rather than on the "plumbing" required to make the various layers of the application communicate. Costs of development should be reduced, since application programmers do not need to write code to implement the services provided by MTS.

Components for the MTS environment can be developed in various programming languages, including Microsoft Visual Basic, C++, and Java. These code modules are compiled into ActiveX DLLs, and objects can then be instantiated either within the process space of the client application, or within the MTS environment on a remote system. Again, from the design perspective, these objects can (for the most part) be thought of in a location-independent manner. Communication between distributed objects is handled by Microsoft’s Distributed Component Object Model (DCOM) protocol. Directory services for locating the objects are provided by the Windows registry.

Services to support database management systems include:

  1. Pooling of database connections
  2. Serialization of database access
  3. Commitment control across multiple (and perhaps heterogeneous) databases
Services to support multiple users and resource allocation:
  1. integration with the Windows/NT security model
  2. thread and process management (to provide a pool of recyclable objects)
  3. a shared memory pool to allow communication between objects
More information is available at http://www.microsoft.com/transaction.

Design goals for business transaction objects

In order to be both efficient and general purpose, business transaction objects should, as much as possible, be "stateless". Two factors in particular encourage the development of stateless objects:
  1. when using transaction control (particularly the "automatic" transaction control which MTS provides, longer transactions decrease concurrency
  2. stateless objects can be used by a wider variety of client applications, including web-based clients

Overview: IDX’s Clinical Management System and its business objects

The IDX Clinical Management System (CMS) is an electronic medical record application, which is implemented as three logical tiers, but currently has only two physical tiers. User interface and business logic both reside on the client workstation.

The logical middle tier of CMS – the business layer – is built as collection of ActiveX DLLs. These are exactly the types of components that the MTS environment is designed to manage. There is some temptation to want to simply move these existing components to MTS. And, in fact, a design goal of MTS is to provide a mechanism for moving physical two-tier applications into a physical three-tier model without significant recoding.

Certain limitations, however, prevent these existing business objects from being simply "dropped into" the MTS environment.

Context

CMS maintains a great deal of context information associated with the user. This makes sense for a client that communicates directly with the database. Although maintenance of context is not specifically prohibited for MTS objects, the goal of a stateless component is not achieved. The context information is maintained in global variables on the client workstation. A "user" object, for example, is instantiated at login, and not destroyed until logout. Other CMS objects make direct reference to properties of this user object. Consequently, all subsequent objects must be created in the same process space as the user object.

Transaction Control specific to the target RDBMS is built-in

The preferred method of transaction control in MTS is through the creation of components that correspond to a single transaction. The transactions can then be monitored and managed by MTS. The CMS business objects currently use explicit transaction control embedded within the code. Naturally, only the database update methods within the business objects are wrapped by transactions.

MTS limitation on number of methods

In preliminary testing, one of the CMS business objects, "CMSActivity", was modified to run under MTS control. In addition to the expected code changes to provide the missing context information, it was necessary to remove many of the object’s properties. MTS reported that the object had "too many methods" when presented with the original object, which had about 80 properties. The complaints ended only when the number of properties was reduced to fewer than 50. MTS does not document an upper limit on properties of an object, but clearly is unable to handle objects as "wide" as many of those in the existing business layer.

These problems certainly preclude a "no-coding" implementation of CMS business objects into MTS, but they also help to point out some of the differences between business objects and business transactions. In general, business objects contain lots of data, and a few methods. In general, business transactions are methods, and they act upon one or more business objects. Moving the data along with the methods into distributed business objects is certainly possible, but not necessarily desirable. The "automatic" transactions in which MTS wraps components do not fit well with the design of the current CMS business objects. Under this mode, a transaction is started when an object is created, and committed or rolled back only when the object is destroyed. CMS business objects tend to persist for relatively long periods of time, and holding open transactions throughout these periods would severely reduce concurrency, and consume lots of resources at the application server.

To use MTS to its fullest, it seems that data should stay with the client while only the methods are moved to an application server. How can the business transactions (methods) be physically separated from the data while still maintaining a good object design?
 
The business object conceptually should be thought of as a single unit. From the point of view of the user, it still presents both data and methods. For purposes of implementation, however, it may be desirable to physically partition methods and data of the business object. The business object will normally be created in the physical process space of the client. When a method is invoked, however, only a stub of code will be executed in the client process. The stub code will create a new business transaction object remotely in the MTS environment. This business transaction object will implement the code to actually do work. The work will automatically be wrapped by MTS in a transaction, and the transaction will be completed when that method is complete.
 

Conceptual Business Object
 
Client
Application Server (MTS)
BusinessObject1
.Property1 = 5
.Property2 = ‘x’
.Method1 (stub)
.Method2 (local)
BusinessTransactionObject1
 
 
.Method1
 

An implementation candidate for MTS: CMS Dictionary lookup and update

A Data Access Layer (DAL) for CMS is currently under development. The DAL will abstract the data access methods from the business objects. When complete, these data access methods will be ideal candidates for implementation as MTS components. The DAL, however, will not be included in the upcoming release of CMS. IDX wants to implement some part of the CMS application in MTS in this next release.

MTS Version 1.0 has been released only since December of 1996, and still lacks debugging facilities and any sort of auditing capabilities. For these reasons, IDX has decided to implement only a subset of the CMS application within MTS. Lookups in and updates to CMS dictionaries were judged to be good candidates, since they are fairly simple objects and have code which can be partitioned from the rest of the application with relative ease. On the other hand, access to dictionaries generates a large number of queries against the CMS database, so performance should be easily measurable.

The role played by dictionaries

CMS stores definition data in a set of application "dictionaries." Dictionaries include lists of such things as medical diagnoses, allergies, and medications. These define the domain of legal values for instance data associated with a given patient – only those medications defined in the dictionary may be prescribed, for example. Lookups into application dictionaries form a substantial part of the query mix against the CMS database. Dictionaries range in size from a few rows to tens of thousands. Different clients repeatedly access the same data from these dictionaries. Updates to dictionaries do not occur with great frequency.

The proposed project will use MTS to perform two functions:

  1. caching of dictionary data to reduce accesses to the database
  2. updates to dictionaries, potentially affecting multiple databases
Only the second of these functions, of course, can really qualify as a "transaction."

Dictionary Lookups

Dictionary lookups may be either "singles" or "plurals". Single lookups take a known identifier and return all attributes of the specified dictionary entry. Plural lookups take "search value", "search by", and "order by" arguments, and return identifiers for all entries which qualify. The result sets produced by the plural lookups obviously vary in size, membership, and ordering, so they are not likely to be of value on subsequent searches. However, for the single lookups, a cache of all dictionary entries will eliminate the need to go to the database more than once. MTS will allow these dictionary caches to be maintained on one or more application servers, sharply reducing the number of database server accesses.
 
Currently, CMS "simple" dictionaries have a standard format – each entry in the dictionary has several attributes, such as "name", "mnemonic", and "code". These database attributes map directly to business object properties. The business object representing the dictionary also has "load" and "save" methods. Single dictionary lookups are accomplished by mapping of the business object properties to SQL stored procedure parameters. So, to perform a lookup, the client instantiates the dictionary object, sets the "ID" property, and calls the "load" method.

The structure of the existing dictionary objects will remain unchanged. These will continue to be instantiated in the process space of the client. The proposal is to create new dictionary lookup components which consist of a single method – "lookup". These new lookup components (ActiveX DLLs) can be deployed either locally or remotely via MTS. The existing Dictionary business objects will have their "load" methods replaced by "proxy" code that creates a new instance of the lookup object, and invokes the "lookup" method. The lookup method will behave as follows:

  1. The "Dictionary" table, which defines all the CMS dictionaries, will be modified to include two new attributes:
  1. When a service request for a dictionary entry is received, the lookup object will check the Dictionary table reference to determine if a dictionary is cached. If not, the request is handled normally (only the requested row is retrieved from the database and returned to the client.) In addition, a request to cache the dictionary is submitted.
  2. The request to cache dictionary information will be handled asynchronously. In other words, clients will not have to wait for the cache to be populated before receiving a response.
  3. Caching a dictionary will simply mean keeping a result set representation of the entire dictionary in the lookup object. Once cached, future requests will extract data from the result set rather than access the database.
  4. When the lookup objects are not remote, caching will be disabled. The request will always go to the database.
  5. Any updates to a dictionary will also turn off the "IsCachedFLAG" and trigger another request to cache the dictionary.

Dictionary updates

Dictionary updates use the same stored procedure mapping scheme as lookups. To perform an update, the client instantiates the dictionary object, sets the various properties, and calls the "save" method. The proposed update mechanism is similar to the lookup: new dictionary update components will be deployed within MTS. A proxy that creates an instance of the update object, and calls its "update" method will replace the "save" method of the existing dictionary objects.
  1. Updates to dictionaries will be wrapped by MTS transactions. The update component will be defined to MTS as "transactional."
  2. The portion of the transaction that updates the dictionary audit table might be constructed as an asynchronous update via Microsoft Message Queue (Falcon.)
  3. The update object will also check the cached dictionary information and turn off the "IsCachedFLAG" and request the dictionary to be cached again.
  4. Based on additional information in the Dictionary table, provision may also be made to invoke additional MTS transaction objects to update another system. This other system might not support stored procedures or SQL. The specific logic to update the other system would be contained in the specified transaction object. While not a current requirement, the next version of CMS will need to synchronize dictionaries in multiple databases.

Conclusion

Implementation of dictionary lookups and updates within the MTS environment will give an opportunity to understand the features and limitations of MTS in much greater depth. Separation of transaction logic (methods) from business objects must be done thoughtfully in order to maintain a good object model.

This raises some interesting questions.  As we make the client thinner, eventually moving to a Web-based architecture, should the business object reside in a component on the server that provides a "view" of the business object to the client on demand? The component on the server would handle dictionary load requests transparently in the background. Updates to the business object would be transmitted to the server and persistence would be made automatic in the background.