| Journal: Patricia Seybold's Unix in the Office August 1990 v5 n8 p1(17)
* Full Text COPYRIGHT Seybold Office Computing Inc 1990.
------------------------------------------------------------------------------
Title: Unix OLTP: getting ready for commercial prime time. (on-line
transaction processing) (includes a related article on open
struggles with remote procedure calls and one on OLTP heavyweights
moving in to the Unix market)
Author: Rymer, John R.
------------------------------------------------------------------------------
Descriptors..
Topic: On-Line Transaction Processing
UNIX
Market Penetration
Market Analysis
Performance Specifications
Industry Analysis.
Feature: illustration
table
chart.
Caption: The OLTP spectrum. (table)
FT Unix extensions. (table)
The X/Open OLTP model. (chart)
Record#: 09 447 421.
- -----------------------------------------------------------------------------
Full Text:
Unix OLTP
ONLINE TRANSACTION PROCESSING (OLTP) and Unix have arrived at the same point
at the same time. OLTP is changing. It is no longer confined to the
high-capacity, high-speed, dedicated systems used by airlines, banks, and
credit card companies. OLTP has spread into applications that involve
smaller amounts of data and fewer users and transactions than the massive
traditional OLTP systems.
Unix plays a prominent role in these new "OLTP Light" applications. The
reason is low costs.
As users scale OLTP downward, they find that Unix systems offer the right
performance at the right price for their new applications. A systems
integrator reports delivering a big claims processing system for 20 percent
of the estimated cost of an IBM Customer Information Control System (CICS)
equivalent. Another user, David Sherr, director of equity systems software
architectures for Shearson Lehman in New York, sought bids for hardware to
support an OLTP application with a $3 million budget. The winning bid was
$1.7 million. "We have a Unix strategy," he says. "But even if we weren't
disposed to Unix, you just can't argue with economies like that." Indeed,
the low cost of Unix systems makes it possible to build OLTP applications
that would be prohibitively expensive on proprietary systems.
Unix has also grown up to meet the challenges of OLTP applications. Unix and
its file system were not designed to satisfy the special reliability and
control requirements of OLTP applications. However, hardware vendors such as
Sequent and Pyramid provide extensions that make Unix reliable enough for
OLTP. Relational DBMS (RDBMS) vendors fix the file system problem by
creating their own file systems, and provide transaction control mechanisms
like transaction queue management, transaction logging, and rollback/recovery
within their database management software. The result is a solid foundation
for OLTP Light applications.
But Unix OLTP users want more--they want to run bigger OLTP applications on
Unix, and they want software independence. Currently, most are dependent on
their DBMSs. They have the freedom to change hardware vendors when they need
to, but if they change DBMS vendors, they sacrifice their applications. The
best hope for software independence--what David Sherr calls "the Holy Grail
of open systems"--lies with X/Open Limited and the International Standards
Organization (ISO). The two organizations are working in concert to create
standard protocols and interfaces for Unix OLTP in a distributed environment.
Unix vendors hope the new standards will allow them to compete with
proprietary OLTP systems such as IBM's CICS/MVS/VSAM to build reservation
systems as well as for OLTP Light applications.
The first products based on the X/Open and ISO work will start appearing this
fall, beginning a period of superheated development in Unix OLTP. This
report examines the state of the art in Unix OLTP and the chances that Unix
will grow to become the predominant basis for transaction processing.
The New OLTP
The OLTP applications based on Unix today are different from reservation
systems or bank networks. But they're no less vital to their users. Take,
for example, the OLTP applications running at Tootsie Roll Incorporated
outside of Chicago. Three or four order entry clerks (more are added to
handle the Halloween rush) complete about 70 transactions per hour using an
Oracle DBMS running on a Sequent processor. Tootsie Roll's main criterion
was Oracle's reporting and analysis tools. "We used to have a big cart that
delivered batches of thick IBM reports to us every day," says President Ellen
Gordon. "But, to compete, we needed more immediate information." Now, when
decision-makers need information, they either get it themselves or have a
quick 4GL routine written by MIS.
Access to information its transaction information is what's most important to
Tootsie Roll. The company doesn't require nonstop availability of the
transaction system. Tootsie Roll won't lose millions of dollars a minute if
its system goes down. This is a fundamental difference between applications
like Tootsie Roll's and reservation or banking networks.
Are systems like Tootsie Roll's OLTP? Veterans of mainframe OLTP say these
are just database--primarily decision support--applications. Users like
Tootsie Roll, however, say OLTP isn't useful without effective decision
support. These business users live by former Citicorp chairman Walter
Wriston's insight into competing in an information economy: Information about
money, said Wriston, is more valuable than the money itself. The same is
true of goods and services. In embracing this view, users like Tootsie Roll
are changing the way we view OLTP, and changing it in a way that favors Unix.
WHAT IS A TRANSACTION? OLTP starts with the transaction. A retailer sells a
red dress to a customer. A bank customer withdraws $100 from a checking
account using a teller machine. A furniture maker orders a load of oak from
a supplier.
Each of these interactions is different, yet each has two things in common.
First, each changes the state of the participating entity's information about
itself. The retailer's revenues go up. The bank customer's checking-account
balance goes down. An amount is deducted from the furniture manufacturer's
budget account for lumber supplies. And so on.
Second, each transaction has two states: It is either in process or complete.
A transaction is complete when all parties can keep their parts of the
bargain. For example, the retailer won't sell the red dress if the customer
doesn't have enough money to pay for it. In OLTP, completed transactions are
said to have been "committed." If a transaction can't be completed, all
parties must be able to cancel them and return to the conditions prevailing
before the transaction began. The retailer, for example, won't record the
dress sale as revenue. In OLTP, this process is called "aborting a
transaction."
ONLINE TRANSACTIONS. OLTP systems don't change these fundamental
characteristics of transactions. Rather, they seek to reduce the time needed
to complete transactions and the time between the completion of a transaction
and its reflection in an organization's data about its business--its
inventory, revenues, costs, etc. The teller machine saves the bank customer
from standing in line to cash a check. The sale of the red dress may be
immediately posted against inventory and revenue files, giving the retailer
immediate information from the field.
An OLTP system collects information about transactions and posts the changes
to the organization's information dictated by updating a shared database or
file. The nature of transactions imposes four basic requirements on all OLTP
systems. The four, called the ACID properties, are: atomicity, consistency,
isolation, and durability.
Atomicity. Atomicity recognizes that a transaction involves two or more
discrete pieces of information. All pieces of information in a transaction
must be committed, or none are. In the red-dress example, the sale of the
dress involves, at minimum, a purchase price and an inventory adjustment. If
the customer buys the dress, the purchase price is added to a revenue file,
and a unit representing the dress is deducted from an inventory file. Both
files must be changed to avoid inconsistent information. If one can't be
changed, neither is.
Consistency. Consistency requires that a transaction either create a new and
valid state of the organization's shared data or, if the transaction aborts,
return the data to its previous state. If, at the last minute, the customer
can't pay for the red dress, the retailer must be able to back out of the
sale, returning the revenue and inventory files to their pre-sale conditions.
Isolation. While a transaction is in process, its details must be isolated
from other transactions. Only when a transaction is committed can its
effects on shared data be shown to other transactions. In the red-dress
example, the customer may run down to the teller machine on the corner to
withdraw enough money to pay for the dress. While she does, other
transactions must proceed on the assumption that the dress hasn't been sold.
Durability. Durability means that an OLTP system saves a committed
transaction's changes to shared data in the event of a subsequent failure.
If the retail store is hit by a blackout a minute after the customer buys the
red dress, that sale must be reflected in the appropriate files when the
system recovers.
The ACID requirements say nothing about OLTP system availability. A system's
availability depends on the cost of lost time to conduct transactions.
Reservation or telephone-switching systems require nonstop availability,
called 24 x 7 (24 hours, 7 days a week) by OLTP specialists. The reason is
that the cost of business lost during a reservation system outage justifies
the cost of building systems that tolerate faults extremely well. For other
businesses, however, short outages may be tolerable. Many users can afford
lower guaranteed system availability. Users and vendors alike tend to view
OLTP applications as fitting into a spectrum, as depicted in Illustration 1.
Unix: From Laggard to Leader
Five years ago, the phrase "Unix OLTP" was a contradiction in terms. There
was no Unix OLTP to speak of. Today, Unix is hot as an OLTP technology.
What has happened to thrust Unix into the limelight as an OLTP technology?
There are several factors, both technical and nontechnical.
USERS WANT IT. The most important reason for the spread of Unix OLTP is the
trend toward pushing OLTP applications closer and closer to the customer.
For example, in a bank, that means installing teller machines that capture
transactions directly from the customer's fingertips. In a retail store, it
means capturing transactions at smart cash registers that are linked to
servers running inventory and pricing databases. In the furniture
manufacturer example, it means using electronic data interchange to swiftly
process orders. The closer OLTP systems are to the customer, the quicker
transactions can be processed, making a treasure trove of information about
trends in buying, costs, consumer preferences--you name it--available to
business decision-makers.
If a bank processes thousands of transactions a day and each transaction is
worth an average of $100, it's not hard to justify big expenditures on OLTP
systems like teller machines. But, as daily transaction rates and
per-transaction values fall, traditional OLTP systems become too expensive.
The new in-store systems planned by companies such as K-mart and JC Penney
are small Unix servers, not big minis. Their system cost is more in line
with smaller transaction volumes and values.
Low costs are part of the story. A growing number of users are moving to
Unix as a strategy to adopt open systems. "We moved to Unix OLTP as part of
a larger commitment to Unix for our business," says George Caneda, a systems
development manager at B.E.A. Associates, a Wall Street money management firm
with $9 billion under management. Telephone companies, which constitute a
large market, require Unix System V compliance in their OLTP systems, as do a
growing number of federal government agencies.
The phone companies, the federal government, and the number of corporate
users committing to Unix add up to a substantial market. No one knows
exactly how big it is, but, given that OLTP systems as a whole are believed
to generate $50 billion a year in revenues, even a small share of the total
is lucrative. High-end Unix performance specialists like Sequent and Pyramid
are out to capture this market. Later this year, they'll be joined by Tandem
and Stratus, the most successful vendors of proprietary fault-tolerant (24 X
7) systems. Unisys, Hewlett-Packard, IBM, and Digital won't be far behind.
UNIX KERNEL FIXES. A big part of the reason Unix OLTP has caught on is
because vendors have fixed Unix's inherent weaknesses. The proof of their
success is the final small amount of attention Unix OLTP users pay to their
operating system software. Most have few, if any, problems.
Vendors such as Sequent, Pyramid, and, more recently, Stratus and Tandem,
have each had to solve the same basic problems in their Unix versions.
They've done so without compromising the standard Unix interface. (See
Illustration 2.) However, the Unix kernels provided by Sequent, Pyramid, and
others in this field are no longer the standard System V kernel.
Interestingly, many of the common fixes undertaken by these vendors will be
incorporated into Unix System V Release 4, which will allow Unix OLTP vendors
to bring their kernels into closer compliance with the standard kernel over
time.
The fixes fall into four major areas: system robustness, data integrity, file
system, and process management.
System Robustness. Unix has a reputation for being unreliable that is no
longer deserved. It used to be that system errors, known as panics, could
hang Unix. The default remedy: reboot, and often, Management processes that
clean out system log files and kill off obsolete daemons eliminate the most
troublesome panics. Unix System V Release 4 incorporates these fixes in a
standard way.
Data Integrity. Standard Unix processes I/O by writing first to system
buffers and then flushing the buffers to disk. Applications run using data
in the buffers. This design raises a risk to data integrity. A power outage
can blow away data in buffers before it is written to disk. The simple
solution is to use Unix's synchronous write-through feature to bypass Unix's
buffers and go directly to disk. This improves reliability, but at the
sacrifice of performance.
The popular approach is to let the DBMS take care of the problem. The DBMSs
institute their own buffer schemes, and all have begun using parallel
management of multiple queues to preserve data integrity without compromising
performance.
File System. The standard Unix file system is tuned to access lots of small
files--exactly the opposite of what's needed by OLTP applications. Most OLTP
applications demand fast access to large files at random. Indexed file
schemes like ISAM and IBM's VSAM are very successful in meeting this need.
The simple solution is to use a more efficient, tunable file system, such s
the Fast File System (FFS) included in the Berkeley Unix, or to provide
access to ISAM. The RDBMS vendors start from scratch, creating their own
file systems using Unix's "raw I/O" feature. Raw I/O allows an application
to take direct control of an I/O device, in this case, a disk. The raw I/O
approach adds a proprietary element to an open system. Dharma Systems
Incorporated (Hollis, New Hampshire) is the one vendor we've found that
rejects the raw I/O approach. The reasons: Users have access to standard
Unix system admin tools from within Dharma, and the Dharma system is more
easily ported across Unix versions.
Memory Management. Unix's standard memory management is inappropriate to
OLTP. Unix assigns one process to each user. The operating system must load
new memory page tables, process control areas, and user registers--a
procedure called a context switch--every time one user session ends and
another begins. Context-switching eats up a lot of system overhead and
memory, and can limit the number of users on a Unix OLTP system to a couple
of hundred. Supporting more users requires memory management or a subsystem
that can field user requests for services, store them in queques, and match
them to available processes as they become available.
Unix OLTP vendors and users deal with this problem in a wide variety of ways,
from writing a daemon to field and handle multiple user requests for
individual server processes to writing their own transaction-control
software--called a transaction monitor--to service multiple user tasks within
single Unix processes.
24 x 7 AND SMP. Solving the fundamental limitations of off-the-tape Unix is
only part of what's necessary to support OLTP applications. High
availability OLTP applications require disk-mirroring and/or automatic
process recovery. In disk-mirroring, every disk I/O is written to two disks,
preserving a spare copy of the data. Automatic process recovery shifts
processing to a hot standby machine in a "cluster" configuration.
The next level up on the OLTP Spectrum (see Illustration 1) is fault-tolerant
systems, which duplex every system component, provide for online component
replacement, and support sophisticated diagnostic and configuration
management capabilities. Applications in this range are called "24 x 7"
because they, theoretically, will never go down.
Lastly, there's a big push on among Unix OLTP vendors to support symmetrical
multiprocessor (SMP) hardware designs. The Unix kernel and RDBMS software
both need special hardware extensions to support these configurations. SMP
promises to allow Unix systems to grow without swapping out processors. In
the future, vendors will also boost performance by using multiprocessors to
process instructions, queries, service requests, etc. in parallel streams.
Proprietary OLTP systems like Stratus's VOS and Tandem's Guardian don't have
these difficulties. They were written to support OLTP, and they've been
improved during years of experience with critical applications. The
proprietary solutions cost more than Unix OLTP solutions. Vendors say the
years of tuning and optimization that have gone into the proprietary systems
are the reasons for their higher costs. Prices also reflect what the market
will bear, given limited competition.
FOCUS ON TP MONITORS. The typical Unix OLTP system today comprises a Unix
hot box, a version of the Unix kernel that's been extended to support
redundant disks, multiprocessing, and other performance and/or availability
features, and an RDBMS. The RDBMS usually provides support for the
atomicity, consistency, isolation, and durability (the ACID properties)
required by OLTP applications.
The central role of RDBMSs in Unix OLTP makes a lot of people uncomfortable.
Users committed to open systems strategies are keenly aware that their
dependence on an RDBMS limits the openness of their systems RDBMS software
locks in users with a variety of proprietary elements, from their custom file
systems to transaction management features like queue management to
performance features like stored procedures. If I use Sybase, for example, I
write my applications in a proprietary version of SQL, Transact SQL, and use
a private service applications programming interface (API). Even if other
RDBMS vendors support the same functions Sybase does, they usually implement
these functions in different ways. One way to increase the openness of Unix
OLTP systems is to separate transaction management services from data
management facilities, making transaction management services available
through a separate API.
OLTP professionals trained in CICS don't like assigning transaction
management to an RDBMS. They'd rather have a separate piece of software--a
transaction monitor--to coordinate the execution of transactions. A
transaction monitor is responsible for managing the procecesses, queues, and
system states involved in processing and committing or aborting online
transactions. Transaction monitors generally have the following components:
Name Service. The name service in a transaction monitor stores the names and
adresses of data management and I/O services. When an application requests a
service, the name service fields the request and delivers it appropriately.
Queue Manager. If the name service fields a request for a service that is
currently occupied in another transaction, it places the request in a queue.
The effect of queueing is to bypass Unix's requirement that each service
request have a dedicated process. Transaction managers allow multiple
applications to use a single process, and can dramatically raise the number
of users supported on a system.
Scheduling Service. The scheduling service in a transaction monitor
schedules processes to handle competing requests for transaction services.
Communications Service. The communications service allows the transaction
monitor to deliver service requests to appropriate services.
Log Service. As it coordinates the execution of transactions, the
transaction monitor stores information about the transaction's progress and
the state of the systems involved in executing it in a log. The information
must be current and detailed enough to roll back the transaction if
necessary.
In our red-dress example, a transaction monitor would identify the steps
needed to complete the transaction as a discrete unit of work. It would
track the correct completion of data-gathering and the updating of shared
data. It would store in a log reference information about the steps of the
transaction and the state of the systems involved. The information in the
transaction manager's log would then be used to roll back the transaction if
aborting it became necessary.
Transaction monitors offer another important benefit to Unix OLTP: support
for more users. Currently, most Unix OLTP systems top out at about 200
users. A transaction monitor, by scheduling and managing user requests for
transaction services more efficiently than current RDBMSs do, could raise the
user threshold of Unix to 1,000 or more. Independence Technologies
Incorporated (Fremont, California), a systems integrator-turned-Unix OLTP
vendor, used a version of AT&T's Tuxedo transaction monitor for Unix to build
a health care claims system that supports 3,000 users.
In this case, the proprietary-system users and Unix users agree: Unix OLTP
will benefit if the transaction management is separated from the RDBMS.
Unix has never had a standard transaction monitor--RDBMSs have filled this
role, or users have written their own monitors. Users and vendors alike
agree that transaction monitors are necessary to make Unix a serious
contender in OLTP. But what's the best way to fill the need for better
transaction monitor software in a standard--even better, an open--way? This
is, after all, Unix OLTP. It should be open.
THe X/OPEN MODEL. If Unix OLTP is going to be open, applications must be
able to call on databases or transaction monitors through a set of common
APIs. What's needed is a set of Posix-like interfaces for OLTP. X/Open
Limited is defining a series Of APIs to allow, for example, an OLTP
application with components that execute on an Oracle RDBMS or an Ingres
RDBMS using the same calls. A different API would allow an application to
call transaction monitors from different vendors using common commands.
Like the promise of Posix itself, the X/Open OLTP model will take years to
become a working reality. Nevertheless, it's crucial to the development of
open OLTP systems.
X/Open is defining its APIs by breaking OLTP into three functional
components--resource managers, transaction managers, and applications--and
defining open APIs to each component. (See Illustration 3.)
Resource Manager. Resource managers include RDBMSs, file systems, and print
services. A resource manager is responsible for managing a shared resource
according to the ACID properties. Transaction managers and applications work
with resource managers by asking them to perform services on their behalf.
Applications and transaction managers don't have to know how the requested
service is performed. As long as all elements support the same service
interface, users should be able to plug in new components as they need to.
X/Open has circulated for industry comment a formal proposal for an
interface--the XA interface--to resource managers. (See Illustration 4.)
TRansaction Manager. A transaction manager provides the transaction
management services that today's transaction monitors provide. It also gives
applications access to communications services. Transaction managers use the
XA interface to obtain the services of resource managers to complete a
transaction. X/Open has reserved a place in its model for the emerging ISO
Distributed Transaction Processing (DTP) protocol as the interface between
two transaction monitors cooperating in a single transaction.
Application. Applications define transactions as having a beginning, a
sequence of operations, and an end. The transaction manager coordinates and
tracks the execution by resource managers of the operations defined in an
application. They ask transaction managers to complete transactions on their
behalf through a still-to-be-specified interface.
In our red-dress example, an application defines the operations that must
occur during any sale to a customer, from the collection of data at the cash
register to the updating of the inventory and revenue files on a server. A
transaction manager directs the steps in the process, making sure that all of
them are performed properly. A resource manager updates the inventory and
revenue files at the direction of the transaction manager.
Distributed OLTP. The X/Open's model assumes its interfaces must allow
different parts of a transaction to be executed on different, heterogeneous
systems linked by a network. This is known as distributed transaction
processing.
Distributed transaction processing is the future of OLTP. By allowing
transactions to be executed across a network, users can provide additional
capacity to existing applications without swapping in new systems, and can
leverage older OLTP systems in new applications. For instance, the store in
our red-dress example might want to add a dynamic pricing application to its
systems that allows a regional office to monitor how merchandise is moving
and to transmit price changes to stores to help stimulate demand. If the
retailer's pricing database is on an IBM mainframe and its in-store systems
are based on Unix, a distributed OLTP system might allow it to implement the
new application without rewriting its pricing database.
The X/Open model incorporates two concepts to accomplish distributed
transactions. First, it distinguishes between local transactions and global
transactions. A local transaction is a set of operations that a resource
manager executes as a local unit of work under its own control. A global
transaction is a set of operations that is under the control of transaction
managers and that includes local transactions.
Second, the X/Open model assumes that the transaction manager and resource
managers in an OLTP system use a two-phase commit (2PC) protocol. A 2PC
protocol builds an extra step into the process of committing a transaction.
It allows the transaction manager to tell all involved systems to prepare to
commit their parts of the transaction. If all of the involved systems
respond to the "prepare to commit" message by saying they are ready to
commit, the transaction manager then issues a Commit command. (See
Illustration 5.)
The X/Open transaction processing model gives OLTP vendors an important
target. X/Open has a long road to travel before its work on OLTP is
complete. The X/Open OLTP group released an interim model a year ago. We
expect it to introduce another interim version soon that will move
communications management from the transaction manager to a new
communications manager. (See "X/Open Struggles with RPCs page 5.") Beyond
fine-tuning the model, X/Open faces other issues as it seeks to define open
distributed OLTP. System management, for example, is a gaping hole. No
standards organization or vendor has crafted a unified way to administer and
manage distributed networks. And there are other issues X/Open hasn't
addressed at all. For example, what is the standard way to identify a set of
distributed operations as a single transaction? And how can sophisticated
transaction structures, such as nested transactions, be performed in a
standard way across distributed systems?
In the meantime, the Unix OLTP vendors are pushing to expand beyond their
base in OLTP Light applications by offering transaction monitors and a
variety of performance enhancements. IBM, Unisys, and systems vendors are
building integrated OLTP environments for Unix. (See "The OLTP Heavies Weigh
In," page 14.) All but two of the major vendors are proceeding with
commitments to abide by the X/Open model and its interfaces. However, it
remains to be seen how quickly X/Open's work will be implemented across a
variety of products. The X/Open dissenters--VISystems Incorporated (Dallas),
which provides a CICS-like environment under Unix, and Dharma
Systems--believe the X/Open model is impractical because it doesn't address
the need to optimize the components of an OLTP system.
What Unix Offers Now
Users building Unix OLTP solutions today have three basic choices: They can
rely on the facilities of a general purpose RDBMS, they can implement one of
several independent transaction monitors, or they can build atop an optimized
OLTP operating environment that includes a database built for OLTP and a
transaction monitor.
There has been much activity in each of these three areas as Unix OLTP
vendors seek better performance and support for bigger systems than are
feasible today.
FROM DSS TO OLTP. The RDBMS cut its teeth in information processing as a
decision support engine. As we've seen, users like Tootsie Roll have pushed
the RDBMS vendors to support OLTP in addition to easy data access. To keep
pace with demands for bigger, faster Unix OLTP systems, Oracle, Ingres,
Informix, and Sybase have each announced "OLTP releases" during the last
year. Among these vendors, only Sybase was designed originally to support
OLTP.
The OLTP releases of the major RDBMSs are either retuned or wholly redesigned
to better support OLTP's requirements, which would allow their RDBMS engines
to function as resource managers in heterogeneous OLTP environments under the
control of transaction monitors. This report covers the highlights of these
efforts.
Tuning the Engines. Each of the major RDBMS vendors has tuned its engine in
essentially the same ways. They all allow databases to be locked by the row
page during a transaction, rather than requiring entire tables to be locked.
And they all employ the same techniques to reduce the amount of I/O required
to service transanctions.
Architectural Adjustments. Each of the major RDBMS vendors has also changed
the architecture of its software to support more uses and higher throughput
in OLTP applications. There are two possible approaches. The first is to
build a multithreaded OLTP operating system on top of Unix. The second
approach is to layer a transaction monitor between a conventional RDBMS and
applications to give the apprearance of multithreading.
To speed the proc-essing of transactions, RDBMSs can simultaneously process
two or more transactions by using multiple server processes. This approach,
called the multiclient-multiserver, or multithreaded, architecture, processes
transactions in parallel, usually on multiprocessor hardware. An alternative
to the multiclient-multiserver architecture is integrating a transaction
monitor and a multiclient-single server RDBMS. In that configuration, the
transaction monitor can achieve the same benefits as a multithreaded RDBMS
engine.
Sybase and Ingres both have multiclient-multiserver architectures. Sybase
added this feature with a virtual server architecture that allows an SQL
Server process to two or more of the processors in a multiprocessing system.
Ingres provides multiserver support with a multithreaded RDBMS kernel. Both
of these database vendors provide their own transaction management software.
The Multiclient Server option of Oracle Release 6, due out this fall, and
Informix Online, an OLTP version of Informix, both use the transaction
monitor approach.
Oracle and Informix both plan to rely on their own transaction managers as
well as on AT&T's Tuxedo transaction monitor technology. Both vendors are
working with systems vendors such as Unisys and Hewlett-Packard to provide
suppport for Tuxedo within their DBMS software.
Optimization vs. Openness. It is too early to tell which pair of vendors has
the architectural advantage. Both the multiserver architecture and the
transaction monitor approaches will yield systems that can support larger
number of users. And so users of all these major RDBMSs will be able to do
more with the Unix OLTP systems. We believe the winner in the competition
for ever-better performance will be the vendor that can best optimize its
transaction management components and RDBMS kernel, while leveraging
standards.
We believe Sybase, Ingres, and Dharma Systems may have a short-term advantage
in optimizing their systems. Each of these vendors provides what we call
OLTP operating environments--data management and transaction management
software created, optimized, and controlled by one vendor. Dharma's TPE*
combines a multithreaded SQL RDBMS kernel and a Network Transaction Kernel
based on Hewlett-Packard/Apollo's Network Computing System (NCS) RPC that
manages transactions.
In contrast, Oracle and Informix appear more interested in moving to
available standards by embracing Tuxedo. In the short term, both vendors may
be at a disadvantage in optimizing their systems because Tuxedo is a
source-level product over which neither has total control. Systems vendors
will actually be handling the integration of the DBMS and transaction
management software. We expect these vendors to need time to learn what it
takes to make the combination of Tuxedo and their RDBMSs really hum.
The wild card in the database market will be user demand for openness. By
integrating AT&T's Tuxedo, Oracle and Informix will be early adopters of what
looks like an important standard in Unix OLTP. Tuxedo is the first product
to support X/Open's XA interface. As RDBMS vendors implement support for the
XA interface in their products, applications written to Tuxedo should be able
to access heterogeneous DBMSs without requiring modification.
Users talk about openness--witness David Sherr's earlier comment about the
Holy Grail of software independence--but we doubt many commercial will move
to XA-based open OLTP architectures soon. There are very practical reasons
for this conclusion. First, none of the big RDBMS vendors are likely to
offer XA interfaces until early 1991. Second, users say they are reluctant
to support more than one RDBMS until they see a greater payoff for the
additional effort required.
Still, both Sybase and Ingres are hedging their bets by moving to open their
own APIs and committing to support the X/Opens XA interface at a future date.
TP MONITOR OPTIONS. And what of the transaction monitors the industry agrees
are so critical to the future of Unix OLTP? At this point, users have two
major options: a version of AT&T's Tuxedo Release 4.0 or VIS/TP, a CICS-like
transaction monitor for Unix from VISystems.
Tuxedo and VIS/TP provide basic transaction-monitoring capabilities. But
they are targeted at different groups of users. VIS/TP offers IBM CICS shops
a practical approach to Unix OLTP. VISystems provides tools to port CICS
applications to run under its own transaction system, and consulting services
to optimize ported applications.
The one question about VIS/TP is its future position in IBM's Unix OLTP
strategy. VISystems has a cooperative marketing agreement with IBM. But IBM
will port a future version of CICS under Unix, and VISystems says it is not
working with IBM on the project.
AT&T's Tuxedo, in contrast, doesn't provide tools to migrate proprietary OLTP
applications to Unix. AT&T's strategy is to provide interoperability
facilities, not migration facilities. Tuxedo is a new API aimed at users who
are willing to start with a clean slate to develop applications. There are
very few third-party applications for Tuxedo 4.0 at this point.
AT&T's "Wanna Be" Standard. AT&T announced Tuxedo 4.0 in February 1989 and
has been pushing it hard as the standard Unix transaction monitor. Some
vendors are taking the bait. At press time, Unisys, Amdahl, AT&T computer
Systems (no surprise there), and Sequent had licensed Tuxedo technology.
Oracle and Informix have announced they will support Tuxedo. Hewlett-Packard
appeared ready to license an enhanced version of Tuxedo from Independence
Technologies Incorporated (ITI). ITI has added software layers to Tuxedo
that make it easier to support additional communications and
industry-specific protocols in the product. The first versions of Tuxedo
should start appearing this fall.
Tuxedo appears to be catching on because it works, because the market is
ready to consider a Unix-based transaction manager, and because it implements
emerging OLTP standards. Licensees like the client-server architecture and
support for distributed transaction processing of Release 4. (See
Illustration 6.) There are even second sources for Tuxedo software (ITI).
Licensees also like the opportunities AT&T has given them to add value to the
base product.
Predictions that Tuxedo will dominate the market, however, are premature.
Even big licensees hedge their bets on the technology. "Tuxedo is there and
it works," said one licensee privately. "It gives us a foundation for added
value, but we're not making a strategic commitment to it yet."
Vendors are reluctant to make strategic commitments to for two reasons. The
first is key gaps in Tuxedo's functionality. Tuxedo does not support PCs or
Macintoshes as clients. It only supports character-based Unix clients. In
early 1991, AT&T will begin fixing this problem by releasing a generic DOS
client. In addition, Tuxedo relies on standard Unix password security. Even
AT&T concedes that it needs a validation service to check the passwords users
submit against access control lists.
The second reason for vendors' hesitation about Tuxedo is their doubts about
its openness to new technologies. Vendors who believe remote procedure calls
are the simplest method for building network applications, for example, point
out that Tuxedo doesn't support an RPC yet. Others see Tuxedo as a
monolithic product that won't be easy for AT&T to open up. AT&T has not, for
example, provided an open interface to its logging service. If a licensee
wants to substitute a new logging service, it is very difficult to do so.
These vendors would rather see a modular architecture akin to the Open
Software Foundation's Distributed Computing Environment (DCE). Others worry
that the industry doesn't know enough yet about transaction monitors in open,
distributed OLTP to intelligently choose a standard.
Users, on the other hand, appear much less interested in debating Tuxedo's
merits than in evaluating it. The big users we talked to were all either
using Tuxedo, evaluating it, or planning to evaluate it in the very near
future. Tuxedo is the most immediately available alternative among Unix
transaction monitors today, they say.
The Distributed Future
Vendors and users alike believe the future of Unix OLTP lies in distributed
transaction processing. This is why distributed OLTP is at the heart of
X/Open's project to define open OLTP interfaces in addition to ISO's effort
to define transaction processing protocols.
Distributing the execution of transactions across a network is a difficult
technical feat, particularly in an environment that is not under the control
of one vendor. Users are skeptical that reliable distributed OLTP systems
will be available anytime soon. "We haven't built enough distributed systems
to know what the proper constructs for distributed OLTP are," says Shearson's
David Sherr. Still, Sherr is one of many who are closely watching the
efforts of the OSF and others to deliver on the promise of flexibility and
scalability of distributed systems.
Earlier this year, assumptions about distributed transaction processing were
challenged by the OSF's DCE technology initiative. DCE goes further than
most previous technologies supporting distributed OLTP by insisting that any
system must be totally modular in structure and be portable to a variety of
operating system kernels, not just Unix. (See Network Monitor, July 1990.)
Modularity promises to ensure that systems, resource management, and
communications software will evolve to higher function and greater efficiency
without blowing away applications built on it. Portability to a variety of
kernels promises application portability. Ultimately, the user's investment
in applications is protected and extended. No Environment/toolkits or RDBMSs
discussed above meet both conditions.
Transarc Corporation (Pittsburgh), vendor of the Andrew File System selected
as part of the DCE, has become a leading proponent of the DCE approach for
OLTP. Transarc expects to begin announcing the first products that conform
to its DCE-aligned architecture for OLTP in late 1990, with products becoming
available in 1991. Transarc also has a strong IBM connection; IBM has an
equity investment in the company. We expect IBM to work with Transarc to
deliver a future CICS version for AIX.
TRANSARC SOFTWARE ARCHITECTURE. Transarc's distributed OLTP environment can
be layered atop a variety of operating system kernels. It incorporates the
services provided with OSF's DCE: threading services, RPC, distributed time
service, naming services, authentication services, and user and group
management. Transarc calls these Core Services, and they support a variety
of distributed applications. (See Illustration 7.)
Extended Services. Atop this distributed services platform, Transarc adds
the following Extended Distributed Systems Services that support OLTP
application development and management:
* Distributed Transaction Service, which coordinates and manages transactions
involving multiple processors and shared resources using a 2PC protocol
* Transactional RPC, which is Hewlett-Packard/Apollo's NCS with additional
semantics that describe transactions
* Logging Services, which information needed to recover after a transaction
aborts for any reason
* Recovery and Locking Services, which are available for use by a variety of
resource managers
* Protocol and Interface Translators, which allow interoperability of OLTP
systems using different protocols (LU6.2, etc.) and interfaces (XA, etc.)
* Programming Veneer, which uses C procedures and macros to shield developers
from the details of transaction management as they build their applications
Taken together, these services define the components of a transaction
manager. Transarc plans to call them, collectively, the Transarc Toolkit.
Resource Managers, Management, Development Tools. Resource Managers in the
Transarc architecture conform to the X/Open model by accommodating RDBMSs,
file systems like C-ISAM and VSAM (as well as Transarc's own Structured File
System), and distributed Unix file systems. Systems management is a big
question mark in the architecture because so much work is still to be done to
define utilities in distributed environments. Transarc hopes the OSF will
provide help in this area with an upcoming technology initiative.
At the highest level of the architecture are high-level tools like screen
builders and CASE environments. Transarc is developing an application
development and run-time environment called the Transarc Application
Programmers Environment. The environment will provide a screen generator, a
transaction monitor library, a security library, and basic system
administration facilities. In addition, Transarc hopes to attract
third-party tool vendors to its environment.
Conclusions
There are a lot of reasons to be excited about Unix OLTP. It clearly
comprises a set of technologies that can help businesses solve problems at
attractive costs today. At the same time, however, Unix OLTP technology is
very much in flux. Vendors and users are struggling to understand how they
can build bigger systems, more powerful systems, and distributed Unix OLTP
systems. As they do, they're redefining OLTP. IBM mainframe veterans are
horrified by the thought of exposing OLTP systems to the inquiries of users.
Unix OLTP users reply: "Sorry, we need it that way. Change the rules."
We believe the number of Unix OLTP applications will continue to grow. The
rate of that growth, however, will be determined by the success of vendors
and users in dealing with four issues: system management, integration and
optimization, and standards.
System Management. Transarc is about as bullish as a company can be about
open and distributed OLTP. Yet even Transarc concedes that it will be years
before users have the kind of system management tools they'll need to manage
large distributed OLTP systems. OSF's next big technology initiative will be
in distributed systems management. Everyone in Unix OLTP hopes OSF finds a
robust basket of system management technologies to back--and fast.
Integration and Optimization. Tight integration and optimized interactions
between the elements in a system are the keys to reliable performance.
Integration and optimization are real challenges in Unix OLTP systems because
of the number of vendors involved in the typical system. Today, most systems
are the products of a hardware (and operating system kernel) supplier and a
database vendor. Add to this mix a transaction monitor, and the number of
potential problems goes up.
Standards vs. Innovation. There's a tug-of-war in Unix OLTP between those
who believe Unix OLTP needs standards now and those who believe Unix OLTP
needs innovation now and standards later. The standards agreements needed to
open up Unix OLTP are complex and intertwined. The fact that the industry
has been able to agree on the XA interface for RDBMS services is a positive
sign. However, we don't expect a full suite of standards to be complete for
two years.
We expect the industry will need three years to sort out these issues. In
the meantime, Unix OLTP will appear to be a fertile field to some, an
unstable landscape to others. We don't believe users should preoccupy
themselves with the standards fights in Unix OLTP. Unix OLTP presents real
opportunities to deliver quality applications at low costs today, and
functionality is advancing rapidly. If you don't take advantage of the
technology where you can, your competitors will.
|