OLTP represents the corporate lifeblood of many organizations, as a direct correlation usually exists between OLTP performance and corporate revenue. OLTP rarely involves sophisticated data manipulation or analysis, but it requires raw speed and data integrity. As the availability of OLTP tools increases, corporate developers will build distributed OLTP systems on top of UNIX, Windows NT, Linux, and other operating systems, increasing support for Web applications as well.
On-Line Transaction Processing (OLTP) applications are order entry systems that allow hundreds of customer agents to simultaneously access a data base, while providing users with rapid response time in mission-critical business applications such as airline reservation systems, banking, order processing, and inventory management. OLTP applications rely on data bases, front-end applications for real-time entry, and tools to monitor performance. OLTP applications are best where speed and accuracy are needed for rapid data base inserts, updates, and deletes.
The earliest OLTP systems date back to the mainframe days, and the most popular ones are still flourishing in new incarnations that support a wide range of distributed operating environments. Newer OLTP software supports applications over the World Wide Web, where the tremendous growth in electronic commerce is creating enormous demands for transaction processing systems.
The Transaction Processing Monitor (TPM) is software layered on top of a Database Management System (DBMS) to ensure the accuracy of the transactions. It is used with large, complex applications and includes data recovery and security in order to ensure reliability of the computing infrastructure (e.g., the operating system, network, and data base). The TPM allows rollback of transactions when a system module fails and can hold transactions in memory while a system component is changed or upgraded. Without a monitor, a company would get incomplete transactions resulting in errors. TPMs provide:
Unlike standard decision support applications, OLTP applications are written so that each transaction conforms to a set of properties known as ACID (Atomicity, Consistency, Isolation, Durability, and Serializability):
ACID properties are designed to ensure data integrity and reliability, and guarantee that data will not be lost. The last property, serializability, is a more recent addition to ACID and the OLTP environment, and its data locking implementation is a complicated process for OLTP system developers.
Data locking can be performed at a number of levels or refinements, which are also known as "granularity." Basically, granularity refers to how much control is available in a process. For example, a brute force, or low-granularity, approach to data locking is to make any data required by a transaction inaccessible to any other transaction. Increasing the granularity would allow other transactions to read the data but not change it while it is locked by the controlling transaction. This is known as "write locking." Problems arise when trying to decide when to let other transactions read write-locked data. If the data is going to be changed by the controlling transaction, should other transactions be required to wait until after the new data is written, or let them read whenever they make a request? Computer scientists have spent many thousands of hours developing computer algorithms to deal with these types of OLTP issues.
IBM's Customer Information Control System (CICS) is the premier example of a TP monitor and the industry's dominant transaction processing environment. CICS runs in IBM's MVS mainframe environments, but it is also available on a variety of popular operating systems including AIX, OS/2, Windows NT, UNIX, Solaris, and HP-UX as the IBM Transaction Series which is a cross-enterprise, Web-enabled, DCE (Distributed Computing Environment) compliant OLTP system. DCE is a layered architecture pioneered by the Open Software Foundation (OSF). DCE integrates a set of key technologies that enable users to build distributed client/server systems.
In either incarnation, whether mainframe CICS or Transaction Series, critics of IBM maintain that CICS implements a comprehensive and robust OLTP framework that guarantees the ACID properties. CICS defined a mechanism for transaction processing, and the understanding of what it means to develop an OLTP system.
Business logic functions are distributed among several systems in a distributed transaction processing environment. The TPM must manage transactions affecting multiple systems. Each distributed node performs part of the work in its portion of the still atomic "local" transaction. Distributed transaction atomicity requires consistency, isolation, and durability. These properties are handled by the distributed transaction processing managers. Each transaction is designed so that its processing depends directly on the results of other transactions.
An enterprise-wide distributed transaction processing environment should support the local TPM on each distributed node. At the same time, the distributed transaction processing system should provide a global, logically centralized TP coordinator that can communicate with and control each of its participant TPMs. Figure 1 shows an example of a three-tiered client/server OLTP environment. In this configuration, the client workstations can perform local transactions under the control of a local TPM. Concurrently, they may participate in a workgroup transaction coordinated by a server TPM. The server may itself participate in a distributed transaction spanning multiple servers and/or in a global transaction initiated and coordinated by a host TPM.
The key to this type of integration is the existence of a common transactional application programming interface (API) such as Common Object Request Broker Architecture (CORBA), Object Request Broker (ORB), or Microsoft ActiveX.
Users interested in deploying Web-based OLTP applications can choose from several vendors, including BEA Systems, IBM, IBM/Transarc, UniKix, Microsoft, and NCR.
All of these vendors have tools that allow companies to give their intranet and Internet customers secure access to their OLTP systems. Web-based OLTP forces developers to find ways to keep most of the OLTP application on the server and off the client. The result is what is called a "thin client" or even an "ultra-thin client" that can load and run their applications dynamically with the same look and feel across heterogeneous platforms. These tools work with most off-the-shelf Web browsers, and use Java applets and CGI (Common Gateway Interface), standard Web browser and server technology, to ensure platform independence.
A major advantage of this type of interface is the familiarity of Web browsers to many users, which lowers training costs. Users do not need to understand how the underlying OLTP application works or learn arcane Structured Query Language (SQL) syntax to use the application.
As medium and large-size organizations deploy client/server systems to implement their OLTP services, data integrity remains critical. Although it has been around a long time, data replication is becoming increasingly popular as a solution to data reliability requirements. Developers and users need to employ a robust, flexible data replication utility, and they want the utility to work with both LANs and relational data base servers as well as Virtual Private Networks on these services. There are two primary goals that users have for replication:
Replication is not the only answer to all distributed data base needs. Two-phase commit is also required, although replication is more usable in most real-world situations. A two-phase commit is useful when there are a small number of updates and only one other remote data base. It does not make sense in situations with many sites and many updates. Replication provides better performance characteristics and less interference.
There are other data base-related rules for OLTP that should be met. The first is to place within a transaction only what is necessary to maintain the unit's atomicity of work, keeping transactions as short as possible. Because DBMS locks are held for a transaction's duration, the longer a transaction remains open, the higher the probability for contention with other "process" locks. Also, the lock queue builds, causing more lock administration overhead and reducing the amount of resources available for data access.
Since transactions are atomic units of work, a journaling facility is used to provide rollback capabilities. A file exists for each process attached to the data base, storing "before" images of all updates, inserts, and deletes that have occurred within a given transaction.
If a system or hardware failure occurs, when the system returns, the DBMS takes the "before" images from all processes with open transactions at the time of the failure, and puts them back into the data base. This action will restore the data base to the last successful commit point for each active process.
If an application cancels a transaction, that process's journal file will be rolled back into the data base. The time it takes to roll a transaction back is proportional to the size of the transaction. A long transaction causes the journal file to grow, requires more management of "before" image records, and increases the data base's freeze time.
The second rule is never to allow user interaction within a transaction. And finally, do not use implicit transactions but set the transaction explicitly.
Data base servers are increasingly being used in mission-critical applications. The number of applications that use data base servers for OLTP and other enterprise systems is growing. The following list provides several data base server features that should be seriously considered:
Different processing environments require different methods to optimize performance. In OLTP, the system must provide quick access to small pieces of data and must minimize locking overhead and contention. On the other hand, decision support systems are optimized by performing efficient I/O operations. These different processing environments require different benchmark criteria to measure performance.
The Transaction Processing Performance Council (TPC) was founded to establish a consistent set of performance measures for OLTP. The TPC publishes benchmark specifications of how tests are to run and how results are established. Reports submitted to the TPC include data on system configuration, pricing, and performance measures, along with documentation showing that the test conformed to the ACID properties. Two types of benchmark tests are identified: TPC Benchmarks A and B. TPC-A measures performance in an update-intensive data base environment typical of OLTP environments. It measures how many transactions per second can be performed using multiple terminals. Although the benchmark does not specify the number of terminals, the number of terminals used for the initial test must be raised or lowered depending on throughput rates. The benchmark can be run on LANs or WANs. TPC-B benchmarks consist of a data base stress test that includes a high level of disk I/O, a moderate level of system and application execution time, and transaction integrity.
The OLTP market is led by BEA Systems, IBM, UniKix, and Microsoft, NCR, and Ironworks.
BEA Systems offers a full line of OLTP middleware offers Tuxedo (Tuxedo 7.1), Jolt, and WebLogic (WebLogic 5.1). Originally developed by AT&T and then sold to Novell, BEA Systems acquired Tuxedo from Novell in 1996. Tuxedo origins go as far back as those of CICS itself. Although Tuxedo was developed as a native UNIX transaction monitor, CICS interoperability was an early assumption for the product. Tuxedo can now operate in a fully distributed environment, including NT. It uses object-oriented technology and supports the widest range of operating systems of any TPM on the market today.
Tuxedo-based programs can be divided into cross-platform components, called application services, which allow companies to balance the processing load across a multi-tiered, heterogeneous network without having to rewrite an application. Tuxedo uses a set of graphical tools to make it easier to manage these applications. The management scripts generated by the applications may be written in C, C++, COBOL, Java, or any high-level 4GL tool, to determine how the application services interact as a single system. Tuxedo supports NT, UNIX, OS/400, OS 390, Open VMS and Cobolt applications.
Jolt 1.1. Systems' Web-based OLTP product, Jolt, gives users transaction, data integrity, object-oriented features, security, and firewall protection, as well as communication with client/server and legacy applications.
The Jolt client is a Java application and will run in any Java-enabled browser. Administrators can selectively make Tuxedo-based OLTP applications available to Internet users through a Jolt repository. Furthermore, Jolt's three-tiered application architecture lets developers create robust, scalable Internet applications that are modular and require minimal time to download and reload applets. This release of Jolt supports all BEA TUXEDO releases (6.1 - 7.1).
The BEA WebLogic brand of products includes BEA WebLogic Commerce Servers and BEA WebLogic Application Servers. This brand includes application servers for the full spectrum of Web and e-commerce applications enable you to develop and deploy mission-critical e-business solutions quickly. Also included is a commerce solution these Java-based products speed e-commerce time-to-market while allowing the builders competitive advantage. A new software tool called WebGrain studio is included in this brand and is an integrated e-commerce development environment for BEA WebLogic that enables customers to move quickly from e-concept to e-business. WebGain Studio provides an integrated suite of tools for rapid development of Java-based Web and e-commerce applications.
IBM has a comprehensive OLTP program through its own CICS applications, Transaction Server, and its wholly-owned subsidiary Transarc, which created Encina--an OLTP monitor application. IBM has folded Transarc's Encina OLTP monitor into its CICS product line. Encina 2.5.Encina 2.5 is available for OS/2, AIX, Digital UNIX, Solaris, HP-UX, and NT. Encina 2.5 deploys distributed objects for both CORBA and DCE, is platform independent, and supports SMP through a multithreaded architecture and nested transactions. Transarc has increased DCE's transaction processing with additional tools designed to simplify application programming while providing high throughput and access to large amounts of data. The DCE RPC allows programmers to transparently invoke software from anywhere on the network.
Transarc's augmentation of the RPC, called Transactional RPC (TRPC), operates by piggybacking its transaction management protocol on the standard DCE RPC. With TRPCs, applications can use the DCE's RPC facility to invoke transactions on a network as if they were local. The TRPC invocation is contained with a distributed transaction. All necessary transaction processing, including state information, is delivered over an existing client/server RPC connection totally transparent to users and applications. Another important feature of the Transactional RPC is its support of the DCE authentication and security down to the RPC level.
IBM originally created CICS for the mainframe market. The company entered the UNIX transaction monitor business with the introduction of CICS/6000, which was a RISC System/6000-based version of its CICS TPM. IBM CICS/6000, also called Open CICS, now runs on a variety of operating systems including Windows, OS/2, NT, UNIX, AIX, and MVS, and it supports SMP hardware.
IBM's main goal with Open CICS is to convert its existing mainframe CICS customers to the UNIX product using two methods. The first one, designed for sites running mainframe COBOL programs under CICS, allows them to recompile their legacy programs when downsizing their information systems. IBM also has a special interface library supporting CICS and IBM's VSAM for files.
For the second migration process, IBM provides gateways for connecting to its mainframe-based DB2 and IMS data bases, or ISAM/VSAM files, under the CICS OLTP framework. The data is still remote, and the mainframe operates as a data base server in a client/server environment. Transarc's Encina provides a gateway to XA-compliant data base management systems.
IBM has bundled Encina with CICS and offers it as a package called Transaction Series. Transaction Series 4.2 is a full-featured, robust OLTP system that is CORBA and DCE compliant. It competes directly with Microsoft's Viper and BEA Systems' Tuxedo. IBM, Transarc, and the Web. IBM is using Transarc as its technology leader to bring OLTP to the Web and corporate intranets. Transarc has introduced DCE-compliant Encina Lightweight Client for the Internet/intranet (DE-Light Client). This product develops Java applets for downloading and execution by Java-enabled Web browsers. Java automatically locates and downloads applets that are not cached locally on the client. The combination of Java and DE-Light Client lets Encina safely distribute client applications across the Internet while corporate data and business logic are safe behind corporate firewalls.
PeerLogic's LiveContent Trans enables companies to rehost their existing CICS,COBOL, PL/1, VSAM , DB2 and batch applications to Unix or NT with little or no change to the application code or data files with dramatic cost reduction. VSAM can support individual file sizes up to 16G bytes. LiveContent Trans also supports Java code to add to existing CICS/COBOL apps, or can reuse COBOL code in new Java/EJB applications.
LiveContent TRANS includes connectivity extensions, provideing a large set of distribution and intercommunication services between LiveContent TRANS and IBM CICS systems. To LiveContent TRANS, the IBM CICS mainframe system appears as a local region, allowing LiveContent TRANS to fully support InterSystemCommunications (ISC), MQSeries, and SNA networking. And since LiveContent TRANS provides the RACF-level security through its LiveContent TRANS/Secure option working with CA-Unicenter, allowing UNIX and Windows servers to enjoy the same high level of security for which mainframe platforms are known.
Viper is Microsoft's code name for its Transaction Server product. Viper uses ActiveXT components, which reduces development costs because of the large number of developers creating ActiveXT components. Viper is bundled with NT Server and does not operate as a separate server or on other operating systems.
Like all sophisticated OLTP systems, Viper uses a three-tiered architecture and supports multiple users. It also takes advantage of NT Server's fault-tolerance and automatic fail-over for robust, highly-available operation, but does not support DCE standards.
NCR's Top End provides real-time OLTP over MVS, UNIX, Windows (2000, NT, 98, 95, 3.x), and MS-DOS that is full-featured and fine-grained. NCR has built in automatic management for parallelization, application replication, and workload balancing to take advantage of network efficiencies.
Users are presented with graphical interfaces and menus to make the tool easy to use, and Top End is Java-client-enabled. Top End is able to package system components and automatically distribute them to client nodes, and it features some of the finest control of transactions of any of the TPMs featured in this report.
Ironworks 4.0 for NT resides on the Internet server and provides direct, interactive and real-time session between your customer and your host order management system. Ironside Technology uses Java TM to ensure the initial access to the application is measured in seconds with sub-second responses to queries. The system is customizable using the Ironside Powered Developers Kit (IDK) gives the ability to adapt the environment as an optional toolkit allowing the development of customized applications that complement the core Ironworks application.
Ironworks 4.0 for AS/400 is a highly flexible product that helps you implement business-to-business electronic commerce. Ironside resides on an AS/400 Internet server and provides a direct, interactive and real-time sessions between customers and the host order management system. Ironside uses Java TM to ensure that initial access to the Ironworks application is measured in seconds with sub-second responses to queries. As with Ironworks 2.3, Ironworks 2.1 is customizable using the Ironside Power Developers Kit (IDK).
As the availability of OLTP tools increases, and existing client/server infrastructure has and will improved, corporate developers will continue to build distributed OLTP systems on top of UNIX, NetWare, OS/2, Windows NT, and the Internet and intranets.
All of this is good news for companies that want to exploit the commercial opportunities of the Web, but have been held back by the pace of OLTP technology. For companies to survive, Web-based OLTP must take on the attributes of production-class systems.
Chrystie Terry is a freelance writer, editor, and Web page designer. She has worked for print and on-line magazines such as BYTE Magazine, ExtraCheez.com, and PCWorld.com, and others. She has written and edited articles on a variety of IT topics including networking, Web development hardware, software, and the Internet.
[return to top
of this report]