Open Online Transaction Processing

This summary is a re-write of a re-write of an executive summary that used to be handed out to folks who asked what we did. Hopefully you will get a reasonable idea yourself and follow the links to deeper (but hopefully not too technical) papers elsewhere on this site.

What is Open OLTP?

OLTP is Online Transaction Processing.

Over the past half decade the computing world has seen the rise of the World Wide Web on the Internet. It has enthused companies with the idea that they can conduct business with the population of the planet and give even modest sized ones a global reach.

The demands for computing power in this new world are never ending. To provide this power architectures are tending towards clusters of cheap Central Processor Units (CPU) which share memory. In turn these clusters of CPU cooperate with other shared memory clusters over high speed networks, sharing nothing but the network connection. These clusters of shared nothing computers will cooperated and communicate with other such clusters over huge distances on networks that span the globe. Clients of business using these networks will be in their thousands will demand that failures in these networks will be rare and will not harm them financially.

Although at the moment a bottle-neck, as time progresses these networks will acquire impressive bandwidths but will still have large latencies (the time taken for a message to pass) simply because they span large distances. Typically the round trip for a message to the other side of the world is a second.

The implications for all of this is that communication will be organized around specialized clients making requests to specialized servers. The concept of Remote Procedure Calls (RPC) can be used to distribute computations between these compartments. The concept of a Transaction is used to handle exceptions and ensures high reliability.

Transactions are bracketed, atomic, units of work which once committed allow a server or client to be in a known stable state.

The concept of a Remote Procedure Call can also be applied generally to the idea of Messages being passed to Services and to the concept of a Request being made to a computational Object.

Transactions demand scaling. It is perhaps the most important rôle of a Transaction Processing Manager (TPM) to handle large numbers of such Transactional RPCs in a robust and economical fashion. This property of handling large numbers of relatively long lived but light weight computational units gives a notion of Scalability, such that increases in work load can be relatively easily accommodated by similar increases in hardware.

Why Open?

Open in this instance is Transaction processing running on platforms which are Open in that they have the properties of:

Portability

The ability of a program to be easily moved between different vendors hardware and supporting software.

Scalability

The ability of the software to run on small minimally sized machines to the largest Massively Parallel Mainframe.

Interoperatability

The ability of software to communicate and interact with other software including rival software from rival companies.

The software that performs the Transaction management should also have these properties for it also provides a platform for programs. The ability of TPMs to do this has been enhanced by a standard programming model based on Java and Enterprise Java Beans (EJB).

Open Platform?

Operating Systems which conform to published standards and are Vendor Independent. This largely and practically means UNIX and systems of that ilk (AIX, OSF/1, Ultrix, HP-UX, BSD, SunOS, Solaris, &c.).

Open Transaction Management?

Like the Operating System this means TPMs which conform to published standards. Unfortunately the waters got a bit muddy here, with at least three competing standards, all endorsed by OSI, the world standards body. They are CPI-C (pronounce this as sip-ick), currently widespread in the IBM Mainframe world; XATMI the X-Open version of ATMI from AT&T and UI; and TxRPC, the Transactional version of DCE RPCs promoted by The Open Software Foundation (OSF).

That was then and this is now. A fresh impetus to the interoperability of TPM has come from the Object Oriented community. A new intercommunication method called the Internet Inter-ORB Protocol (IIOP) found in the Common Object Request Broker Architecture (CORBA) (and backed by the Open Management Group) has been introduced. This does not suffer from the fragmentation of standards that traditional TPMs had seen and it supports Transactions. Importantly, IBM have signed up to this and support (or will support it soon) in their larger Mainframe based TPM, CICS and IMS.

Client/Server was Mentioned

Client/Server has increasingly come to mean proprietary Microsoft Windows based products running on Intel x86 PCs talking to Databases on small to medium sized server over relatively fast and low latency Ethernet. These systems have rudimentary transaction control and are proprietary. They do not scale.

It has also come to mean programs, again running in the computer the client is using (usually through the mediation of a World Wide Web Browser) written in Java and communicating with a database using networked database access methods. As with their more proprietary Microsoft cousin this approach suffers from poor compartmentalisation (the business logic's in the wrong place) and high Database overheads. They do not scale either.

Ok, Name some Names

Amongst the traditional TPM, there are:

Tuxedo

Tuxedo is an the industry leader in Open OLTP. With its origins in Bell Labs, it is now supplied by BEA Systems. Tuxedo is a message based TPM with a paradigm not dissimilar to SNA, in that messages are passed to 'Services' through a hierarchical network. There is an excellent short history of Tuxedo in the preface to [Andrade &al]. One of a number of books on TPM.

Encina

Encina has a radically different model of communication. It is based on DCE RPCs which it makes Transactional, further, Encina is the only TPM currently supporting Nested Transactions. Nested Transactions allow smaller sub-transactions to be controlled by larger transactions within which they are contained.

CICS

CICS from IBM and ports to open platforms other than the RS/6000 are IBM's idea of how the market should look. It is based on the Encina Toolkit. These TPM are designed to look like CICS in the Mainframe and AS/400 world, thus easing porting, but there the similarity stops. A similar approach has been taken to DEC's ACMS which thanks to the Encina Toolkit also exists as ACMSxp. IBM have taken to bundling CICS and Encina together calling the result TXSeries.

In addition to this there are a number of Object Transaction Managers (OTM) based TP Managers, which are embedded in Enterprise version of Java Application Servers, such as M3 found in BEA Systems's Weblogic and Component Broker in IBM's Websphere Enterprise Edition (WSEE).

Where would a TP Manager Fit In?

Transaction managers are most useful in large scalable applications where there is an element of distribution. Often such systems start as the kind of Client/Server systems mentioned before but, by the introduction of a TPM, they are opened up and can be scaled to enterprise dimensions. Alternatively, a TPM can be a component from the design stage on. This method is vastly better because the small Client/Server model is usually inappropriately compartmentalized.

With the advent of the Enterprise Java Bean rapid deployment of prebuilt components is promised using Graphical User Interface (GUI) tools. These tools will use and be based on Unified Modelling Language (UML) [Rumbaugh, Jacobson & Booch].

More Information

We hope that the above was interesting enough to get you to look at the rest of the site (see the Table of Contents). The target audience is much the same as for this page so we have endeavored to keep Transaction Processing theory and wads of incomprehensible code out of it, the pages to under 2000 words and reasonably understandable to the computer literate. If you found this page a little daunting, however, then there is a page for non-cognoscente, such as Brain Surgeons and Rocket Scientists.

$Date: 2008/07/03 12:36:10 $