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:
-
Pooling of database connections
-
Serialization of database access
-
Commitment control across multiple (and perhaps heterogeneous)
databases
Services to support multiple users and resource allocation:
-
integration with the Windows/NT security model
-
thread and process management (to provide a pool of recyclable
objects)
-
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:
-
when using transaction control (particularly the "automatic"
transaction control which MTS provides, longer transactions decrease concurrency
-
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:
-
caching of dictionary data to reduce accesses to the database
-
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:
-
The "Dictionary" table, which defines all the CMS dictionaries,
will be modified to include two new attributes:
-
A new flag, "CanCacheFLAG", will indicate whether a dictionary
is a candidate for caching. Some might not be candidates because they’re
too big, or too dynamic.
-
An operational flag, "IsCachedFLAG", will indicate whether
a dictionary is cached at this time.
-
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.
-
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.
-
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.
-
When the lookup objects are not remote, caching will be disabled.
The request will always go to the database.
-
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.
-
Updates to dictionaries will be wrapped by MTS transactions.
The update component will be defined to MTS as "transactional."
-
The portion of the transaction that updates the dictionary
audit table might be constructed as an asynchronous update via Microsoft
Message Queue (Falcon.)
-
The update object will also check the cached dictionary information
and turn off the "IsCachedFLAG" and request the dictionary to be cached
again.
-
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.