To paraphrase a slogan: The Internet -- this changes everything. What that means for most people who design and develop applications has yet to sink in, but it will. Even if you don't develop for the Internet, its influence on the design of your applications will be powerful. This might happen in several ways, but near the top of the list is application partitioning, which is often defined as breaking an application into components to improve performance and effectiveness. The Internet is an environment that almost demands this approach. It's a fairly sure bet that within 10 years nobody will build an application without at least considering how it can be made into components and then partitioned. This, of course, needs some explanation.
There was a simpler time, about 15 years ago, when applications of all kinds ran either on a central computer or on individual personal computers. To use a slightly pejorative term, these were monolithic applications, built as a complete unit for one environment. This type of architecture has faded rapidly in the last 10 years. The need to share data forced developers to connect computers of all kinds. Soon came the notion that PCs and their inexpensive processing power should run the user interface, and larger computers (such as mainframes, minicomputers, and server PCs) should handle the data. In effect, the PC user-interface part of an application became the client of the database management server. In terms of partitioning, client/server is described as two-tier. Two-tier client/server is the simplest form of partitioning; the trend toward n-tier architectures is an extension of this first step.
There are many reasons to use this approach, but they can be boiled down to three:
More efficient use of resources. By dedicating hardware and specialized software to specific tasks, you can achieve better performance. In essence, multiple CPUs in their own optimized environments are better than one giant, centralized CPU. Furthermore, instead of shipping vast amounts of data across a network to be processed at each workstation, the processing takes place at the server, and only the requested data is sent to the workstation. For transaction processing (TP) monitors, the server also saves resources by channeling many clients through fewer database connections.
Improved maintenance. By breaking up functionality between data and user interface, a greater degree of fault tolerance and data integrity is possible. A fault-tolerant architecture means that one server can pick up the workload of another server that fails. This is easier to do if an application is partitioned as opposed to monolithic. To a certain extent, the ongoing chore of data maintenance is easier because it is (more or less) centralized. In theory, a partitioned application requires less work if one of the major components such as the database management software is changed. There is a degree of hardware and software independence.
Scalability. Once the partition is made, it becomes easier to use more and/or bigger data servers to scale up the application to include different platforms and networks. The general rationale for client/server computing has become familiar. PCs should run the user interface because their CPU time is less expensive, and server machines should handle data processing rather than clog networks transmitting data to "fat-client" PCs. Still, it took over 10 years for client/server implementations to become widespread. There are reasons for the delay, which are also applicable to other partitioning schemes:
In 1992, the successful store instituted a buyer's club that offered CDs at a substantial discount depending on a variety of factors such as season, volume of purchases, and type of music. In the terms we use today, the store added over 300 business rules to the system. Their innovation, and it was an important one, was delivering the club members' current standing with every purchase -- on the spot -- as a marketing tool. The club idea was successful, bringing in 2,500 new members in one year, which suggested that additional stores might be appropriate. In 1993, the company built two new stores and was faced with the typical design issues involved with linking the stores via computer.
A difficult factor, as you might guess, was the desire to continue providing a realtime summary for the club members at the point of purchase. Because of the geographic separation, the speed and reliability of communications (or the lack thereof) would affect the normal transaction processing that assembled the customer's information, updated it, and prepared the printed form. Up to this point, most of the business rules had been coded into the client software, but now the company faced an unwieldy communications bottleneck getting data to and from the workstation, and it also faced the difficulty of updating each store's software when the business rules changed (which they often did).
The company could have thrown a fast and expensive communications link at the problem, but instead it chose to use one of the new partitioning products, in this case from Forté Software Inc. (Oakland, Calif.). This decision separated the business rules from both the data management and client software, putting them into an independent process. Using this approach, the system assembled club member's status summaries at a central server and only the final format -- ready for printing -- was sent to the workstation at a store. This is a representative description of three-tier partitioning.
Obviously, not all of these services are appropriate for all applications, nor do they all necessarily coexist on a single server. There are so many options for application design that it can't really be called three-tier any more: The operative buzzword is "n-tier architecture." (See Figure 1.)
The flexibility of packaging an application within objects makes it much easier to segregate user-interface code from data and business rules. That, in turn, makes it easier to partition, especially for programs such as Four Seasons' SuperNova and Dynasty Technologies' Dynasty, which use the object (class) definitions to perform automatic or dynamic repartitioning.
Then, too, object-oriented programming is now the standard for developing the client side of an application. Nearly all client/server and partitioning products offer a GUI development system based on one version of OOP or another. At this point, only the environment of the relational database servers isn't object-oriented, and if that's bothersome, you can try one of the object-oriented DBMSs.
Without using scripting languages such as JavaScript or VBScript, browsers don't act like regular application clients because they can't be directly programmed, they don't have application logic capabilities, and they have a limited set of presentation tools. Then, too, HTML pages are a rather specialized type of form that don't behave like the sophisticated forms of most client/server applications. Nor are Web servers the same as LAN servers because specialized software is required -- in addition to the network operating system -- to provide services for the HTML pages (and other aspects of Web communication). Most data-management services are not part of the Web server and are usually provided by additional software with connections to external database systems.
Because of the somewhat limited features of the "basic" Web, we've witnessed an all-out creative (and competitive) assault on browser enhancements, Web application development, database connectivity, and (perhaps most important in the long run) object management. The results include the Java language, Java applets, JavaBeans, ActiveX components, Visual Café and InterDev programming environments, IIOP, CORBA, and DCOM. The last three are specifications for how objects can be passed around a network as components of applications.
That these are all object-oriented elements is no accident. You've probably heard the siren song of distributed objects and electronic commerce. It's sung by most of the heavyweights of the computer industry, and the baseline is object technology. In this environment, most applications -- big and small -- are going to be created from many components, more or less on the fly. This presents a very different paradigm from LAN-based applications. Even the data will be different -- everyone expects it to be loaded with multimedia datatypes and include streaming data (such as video and audio).
True Web applications will have some stiff requirements: They must cooperate with ORBs and browsers, which means adapting to standards (or sometimes the lack thereof). They must run with many different operating systems, user interfaces, and databases while the configurations used are changing unpredictably. Because the current Internet protocols are "stateless" (lacking essentials such as events and execution states), application partitioning will need to be dynamic while at the same time providing structure for coordinating objects.
In this environment of wide-traveling objects and their dense web of messaging, the concept of "tiers" makes little sense. Almost by definition, Web applications will be multitiered and partitioned. This doesn't mean that there is no role for traditional application partitioning. Most services, such as business-rule management, transaction monitoring, and fault tolerance, will be just as needed -- if not more so -- on the Web. But other services, especially application management, are going to play in a world controlled by ORB software, and the rules are going to be quite different.
Much of the Web approach (such as browsers and HTML servers) will even be carried over to Intranets, the close cousin of the corporate LAN. Consequently, here too partitioning will often be different: more distributed and more difficult to coordinate.
Eventually, all application design will change, if for no other reason than to keep up with the innovation and momentum of the Internet. For now, however, you can develop a traditional application that uses a gateway into the Internet, in effect adding another tier or two, or you can design the entire application to use Web browsers for the client partition and Web servers as the primary service of the network server. Most of the client/server and partitioning products are beginning to recognize the Internet, Java, and CORBA, but only a few such as Passport Corp.'s (Paramus, N.J.) IntRprise are able to handle traditional applications and Internet/Intranet applications with the same tools.
This is all well and good, but you can't assume that application components will fit like Legos into full-scale business applications. In principle, standards such as CORBA or DCOM should let you pluck components from all over that can interoperate as objects. But the objects must still be designed to work together or at least follow similar guidelines. They must also operate together in an extremely diverse and rapidly changing environment. Achieving such cooperation among objects will be difficult. It recalls what has been said about the reasons for slow acceptance of the client/server model: incompatibility, complexity, and lack of tools. Application-partitioning schemes could well be part of the problem as well as part of a solution. At the moment, with most of the grand vision for distributed objects still on paper, the situation can be summed up rather briefly: It's all new, exciting, and very unproven.
