Can the web compete with client/server as a platform for OLTP computing?
Three years ago the World Wide Web was something very cool for a small minority of the IT community. Now the Web is seen as the ultimate leveler, with such potency that it has even forced Microsoft to change its strategy. (Bill Gates admitted in the July 15, 1996 issue of Business Week, however, that he doesn't need new revenue generation from the Web at all.) All of this attention has caused the Web to appear as a mythological giant that possesses miraculous curative powers. Can On-Line Transaction Processing (OLTP) computing be transformed by its touch? The answer is not a simple "yes" or "no," but a definite "it depends." In this article, I look at some of the basics of OLTP, review the strengths and weaknesses of running OLTP on the traditional mainframe and client/server platforms, and review some of the areas in which the Web can have a significant impact.
OLTP systems can have a profound effect on the businesses that run them. Apart from removing the drudgery of low-level atomic tasks from clerical workers, OLTP systems shift the "center of gravity" of the business. Airlines could not run the number of routes, daily departures, and size of fleets they do without the transaction systems they have in place. Their large investments in reservation systems were leveraged into offering a comprehensive range of travel services electronically. Robert Crandall, CEO of American Airlines, publicly stated his preference for the SABRE system over that of the actual airline. Although this example is often quoted in case studies, even the smallest company that has automated some business functions on a PC would find it difficult to fall back to manual procedures.
When it comes to developing and deploying an OLTP system, the availability, capability, and cost of technology play a significant role. Twenty-five years ago the only real choice you had was mainframes. Ten years ago it was mainframes and proprietary minicomputers, and since then it has been a plethora of client/server configurations utilizing workstations and servers of varying capacities (including mainframes). However, new technology can boost the price/ performance ratio, but it cannot always deliver the stability and reliability that OLTP systems demand. History has shown that new technology gets deployed where it can have a positive business impact and is precluded from areas in which the impact could be negative. For example, the cost of ownership of an existing OLTP system could be halved by implementing new technology, but there is a risk that these savings could be eaten up (or exceeded) by business losses resulting from increased downtime. It is easy to see why the status quo would prevail.
Mainframes. Though definitely not hip anymore, many mainframe OLTP systems still survive after being in operation for over two decades. We rely on them for posting our transactions when we visit an ATM - and a lot more besides. Mainframe OLTPs have some very important strengths and some significant weaknesses, including lengthy cycles to implement application changes. In the 1980s, there was much talk about the "application backlog" for major corporations; development on any new application would take at least two years to begin. More productive development techniques and platforms were seen as the answer, but there are reasons why wholesale change did not occur. Despite their many drawbacks, mainframe OLTP systems work well and reliably.
Operational characteristics can maintain systems availability greater than 99.9 percent because of the maturity of the major software components and management tools. With transaction-processing monitors, it is quite common for there to be concurrent user populations in excess of 2000.
Managing growth can be very challenging. Historically, mainframes have doubled their per processor capacity in every three to four years, but a user experiencing 27 percent growth in CPU cycles used is outstripping the technology two to one. The choices are to either repartition the work onto more machines or migrate off selected workloads onto other platforms. This "horizontal growth" is painful and difficult to manage while maintaining a highly available service. New CMOS-based mainframes may help by boosting the per processor power, provided that user application code (some of it more than 20 years old) can exploit their multi-CPU architectures.
Functional enhancements are slow to implement. A simple change such as adding a new field to a screen or changing an input field's edit mask can take weeks to implement. This inability to respond rapidly is a great source of frustration.
The user interface is very limited (block mode), but you can give it a facelift using a PC-based 3270 emulator and a GUI frontware product. However, distribution and control of the frontware code are significant issues.
The cost of ownership is generally considered to be high and relatively insensitive to technology price/performance improvements. This is usually because of the high proportion of fixed costs such as support, administration staff, and maintaining the premises that accompany a large installation, along with high-cost hardware that must be amortized over several years.
Client/Server. One of the most significant drivers for this platform has been the availability of functionally rich packaged software that can be deployed more quickly and cheaply than on mainframes. In addition, the adoption of open systems standards means that there are usually multiple hardware and RDBMS choices for the prospective purchaser.
Operational characteristics can sustain maximum concurrent user populations between 1000 and 1500 on a single server. They are anecdotally less reliable than mainframes because of technology immaturity and incomplete management tools.
Managing client/server growth is a lot easier than managing mainframe growth. New clients and more server power can be added easily to meet increased demand. (This assumes you deploy a standard hardware and software configuration, with all components tried and tested, and a good version control system is in place.) In theory, server power can even grow horizontally by being split amongst several machines if distributed database technology is utilized.
Functional enhancements are a snap. The logical (and physical) separation of application logic from the data lets simple changes occur in minutes or, at the most, hours.
The user interface is excellent. A variety of workstation-based GUIs can be exploited by many development tools to deliver functional systems complete with help and online documentation.
The cost of ownership is considered to be less than mainframes, although some would say that a lot of the data center costs are ignored. However, there is more sensitivity to technology price/performance improvements. About three years ago, the Gartner Group did a study of client/server versus mainframe system costs. When a detailed cost analysis was done to include the "soft" costs of users performing their own systems administration, the real cost of PC storage (for example, disk space wasted on old software versions not deleted), and the costs of regular back-ups that are implicit in a data center operation, client/server came out slightly higher over a five-year ownership period.
Software distribution is another constraint. There is a logistical challenge in distributing new versions of application code and/or software patches to 1000+ remote client workstations. There must be a high degree of confidence that the new software is, in fact, installed on every machine.
Systems management can be a drawback. Mainframe systems have a total "box count" in the tens of devices (mainframes, communications processors, and terminal controllers) as well as proven software for remote "lights out" management. A large client/server system has more than 1000 peer machines. The software to manage such a system to high levels of availability must be very comprehensive, and it is questionable whether the required maturity has been reached.
Performance management can be a difficult issue because client/server systems ship more traffic across a network than a mainframe system. A mainframe system sends and receives messages or screen images that do not vary much in size. The network can be optimally tuned around these transmissions. In a client/server system, each transaction can vary in the number and type of requests that are sent to the server. This traffic can also vary depending on the application development tools used and the vendor-supplied networking software that connects the clients to the server. Network traffic patterns are much more complex and difficult to control.
Server scalability can be a restriction. This is a generic issue for client/server systems that require more than about 1500 users. Each logged-on client invokes its own server process or thread and, in some cases, the allocation of at least 1.5MB of non-shareable memory. The concurrent user cut-off point is either the inability of the server to schedule more processes (or threads) or the point at which a maximum memory configuration limit is reached on the server itself.
There is absolutely no reason why you can't use this same pragmatic approach with the Web. The cost of ownership considerations are perhaps even more compelling. Instead of revolution, we might experience a rapid evolution.
The Web can be used as a centralized server with application code and data. The remote workstation merely provides the presentation layer. All of the issues of software distribution, version control, and systems management are gone, but an intuitive user interface remains. Remote clients can access the server via a private broadband network and/or over the Internet itself by using dial-up with a SLIP or PPP connection. Managing growth might be easier, assuming that HTTP servers can scale to the levels that large OLTP systems will require. (Such scalability is not a given at this time.)
Transaction predictability is far from a reality. In fact, the Internet has a quaint unpredictability about it: Sometimes URLs are located on the first submission and sometimes they are not. If you have ever "pinged" another site and run "traceroute," it is amazing to see the number of hops a packet can go through (and there is no guarantee that it will be the same path the next time). Slowdowns and outages do occur, too, which may be unacceptable to certain classes of OLTP users.
Transaction integrity requires some work, as well. An OLTP system must have the ability to commit transactions in near realtime and/or roll them back without altering the state of the referenced data. It is possible to provide this functionality in HTTP, but RDBMSs already have a proven track record.
An OLTP system must have the capability to handle a large user population with only a small proportion of the users actually active at any one moment. A lot of pauses, or "think time," occur when transactions are entered, and both mainframe and client/server system software can time-slice users to boost throughput. This requires the suspension of any user transaction, and its complete context must be available when reactivated. Mainframe TP monitors have being doing this for years, and some equivalent functionality must be delivered for managing the huge number of IP sessions that a very large HTTP server would need to handle.
Transaction security is a very thorny issue. Hacking is widely publicized and there is understandable nervousness about carrying out commerce over a medium that is considered suspect. A lack of standards does not help, either. In the United States, 128-bit encryption is possible, but 40-bit encryption technology is the maximum that can be exported. A worldwide Internet security standard is required but is not yet available.
With all of the technical discussions, it is easy to forget just how affordable it is to gain access to the Web. Less than $10,000 could probably get you a Web server, software, and even an HTML developer to write a few pages, including templates for catalog browsing and submitting orders. All you need now is an Internet provider and your shingle is out there in cyberspace. Given time, the Web crawlers will find your site, search engines will get updated, and 20 million people will have the capability of finding you. For niche or boutique businesses that usually rely on mail-order catalogs, this is incredibly cheap access to a huge audience. It may not be glamorous, but it is OLTP!
The Web has also caught the imagination of people who can see the potential for new ways of conducting business. Already, companies are running auctions over the Internet. The transactions are not too complex to write, and the fixed costs could probably be spread by running several auctions concurrently. This is just one idea, and there will be many more. For example, with a Web-based application, you can surf through graphic representations of supermarket shelves, click on items, and have the store bill your credit card and deliver the groceries to your home.
Given the large investment already made in OLTP systems, any incremental investment that can stimulate additional business is always welcome. The Web is merely an extra distribution channel for the existing OLTP system; it does not interfere with the core, legacy code. Enter the Web-based add-on to create a hybrid system that can be brought to market quickly. Following are some current examples.
Travel Reservations. There are already HTML "front ends" to some of the major computer reservation systems. Given that the underlying systems are very cryptic and definitely not intuitive, the ones I have used (for example, PC Travel at http://www.pctravel.com) have proven to be very frustrating. However, the person who perseveres and makes a booking saves the airline the commission payment to the travel agent. So although booking volumes are unlikely to grow, profits could improve because airlines may pay fewer travel agents' commissions, which previously cost the airlines billions of dollars each year.
Online Stock Trading. A recent article in Business Week counted 24 companies offering Web users the ability to trade stocks online. It is unlikely that new OLTP applications have been written, but the direct placement of trades into the existing system means fewer brokers, the floorspace they occupy, and their commission payments. The transaction fees seem very attractive, which could induce some people to trade more frequently. Web-based broker fees are around $25 per transaction, while a full-service broker will charge approximately $75 per transaction.
Home Banking. It is costly for banks to run and staff a branch network. They already know that the direct costs of a transaction via an ATM are a lot lower than one via a teller. If people could be persuaded to bank electronically, infrastructure costs could be reduced substantially. Some banks are already offering "no fee, no minimum balance" Internet accounts. Although the economic case is compelling, the security issues I discussed earlier are a very real stumbling block. Enough has been written on this topic for most people to accept that full-blown commerce on the Internet cannot happen without resolution of this security issue.
With the trend toward outsourcing many corporate functions, the Web could even give Federal Express (or the U.S. Post Office) a run for its money. Everything from bids, proposals, and initial design documents to final specifications could move over the Web. Marketing collateral would no longer be mailed out, it would be downloaded by clients or emailed to them. There are already examples of this electronic cooperation in the high-tech industry. View the home pages of any major high tech corporation, such as IBM, Hewlett-Packard, Microsoft, Oracle, Sun, and Cisco, to see examples. One very elaborate example, the Disney Web site, has in excess of 1000 HTML pages (http://www.disney.com). A large number of high-tech companies have plants in Scotland, all within 30 miles of each other. Major companies have invested in a private ISDN network to link up the "virtual teams" and major component vendors on new products or projects. Design changes are approved electronically online, saving time and expense. The Internet could offer this facility to any two companies anywhere in the world.
Web applications will peacefully coexist with, and complement, existing mainframe and client/server systems for years to come. The Web will not be ready for prime-time, major-league OLTP applications until it can offer the transaction predictability, system security, and high availability of existing mainframe systems. To illustrate the point, major reservation systems' planned outages can be as brief as 30 minutes per year! It has been said that if the price is right, an IBM mainframe could act as a Web server, which would solve this problem.
New products to make Web-based OLTP systems are on the way. Connect Inc. (http://www.connectinc.com) has developed an order management package for the Web. The architecture includes a TP monitor for handling a large number of IP sessions. Ensodex Inc. (http://www.ensodex.com) has developed an ODBC driver to let client/server applications run over the Web. Many more companies are working on tools and interfaces, as they too have faith in Web-based OLTP.
Technology costs will continue to drop as companies such as Microsoft bundle Web tools with updated products - in this case, Windows NT release 4. Web-based OLTP applications let external customers do business when it suits them -as opposed to having to do business when it is convenient for the company, within the business hours it sets. This is especially important to international businesses with customers in many time zones, as long as the security issues are resolved.
Web-based OLTP is here to stay. But rather than being an overnight sensation, it will take hold over time. In some ways it supports the mainframe paradigm, "Centralize everything except the presentation layer." If Web-based OLTP can mature (and that is a big if), perhaps the mainframes that are steadfastly generating our utility bills, running the banking system, and so on can be retired sooner than expected. However, I do not see Web-based OLTP replacing the huge airline reservation and credit authorization systems. These systems have in excess of 150,000 terminals and printers configured. There are probably about 20 systems of this size, although I am only guessing. However, with a low cost of entry it is not unreasonable to assume that an equal number of new users will carry out OLTP over the Web, albeit to many new sites; therefore, there may be 150,000 new Web sites with 20 users each. And more than likely, those numbers will continue to increase.