Client/server is moving beyond two tiers to cope with increasingly complex computing models. Where-and how-can three-tier fit in your IT strategy?
By Charles Thompson
Modular design and structured programming seem to have been with us since the dawn of time. So why are so few applications built this way? To be fair, modern database technology has encouraged us to separate data and data management from programs. The separation of data and process is so ingrained in our minds that it can be difficult to remember a time when databases didn't exist.
Today's client/server technology has progressed beyond the "traditional" two-tiered concept to embrace three-tier architectures. But what exactly is a three-tier architecture? And what about all the current talk (mainly from vendors) about "multitier" (or "n-tier") platforms? How do they differ from three-tier?
I like to think of the architecture in logical terms; my
application architectures have three logical tiers: presentation services,
process services, and data services (see Figure 1).
Figure 1. Three-tier architecture components.
Note that in Figure 1 I've included a variety of interface technologies above the presentation services. A brilliant benefit of this architecture is that it becomes much easier to implement a variety of interface technologies using the same business processes. Object orientation makes this even more successful. Examples of such interface technologies include telephones via IVR, public-access kiosks, ATMs, and a broad variety of Internet devices, such as interactive TVs.
Tying all the tiers together is the middleware. Any client/server architecture, whether two- or three-tiered, requires middleware to provide the communications link among the layers. Middleware is normally provided as generic toolsets that can be configured to support your particular set of services. Physically, these three tiers can be implemented in a wide variety of ways, which is where multitier comes in. Any of the services can be set up as multiple layers, with one service calling other services to perform specialist tasks.
The three tiers can be spread out among a number of servers. For example, a separate server could be used for all process services, while another runs the database server. Alternatively, the database server can provide the process services, written as stored procedures, as well.
Internet or Web servers are often viewed as three-tier because they move program logic away from the client computer and sit in the middle between the user's machine and the database server. However, these servers are not truly three-tier, because although they separate the presentation services into two physical layers, they rarely distance the process services from the presentation services.
And then there's "n-tier," which is how Oracle characterizes its new network computing architecture (NCA). NCA is logically three tiers, but Oracle has taken the concept a little further and defined some of the services that can be implemented on any tier. NCA emphasizes flexibility through the use of third-party components called "cartridges."
If all this sounds familiar, that's because it is-these architectures are no great leap from the design concepts of the last 20 years. What's new and exciting are the technologies that can exploit these architectures: Networks are much faster. A broad variety of user interface technology is available. Development tools have recently embraced the separation of presentation and process logic. And middleware for managing communication among the services and tiers is growing in sophistication and integrating into many development environments.
As for objects, most implementations of object technology really only treat the presentation elements ("components") as objects in a class hierarchy. Data is still usually managed by a relational database, and process logic is often encapsulated in the presentation object, which limits flexibility in the interface. Logically, however, objects fit well into the three tiers. Each service-be it presentation, process, or data-can be supported by objects, and most of the latest three-tier technology does just that. Objects are easier to match to business requirements and processes and provide a nice mechanism for grouping services together.
Another huge benefit of object technology is that it simplifies the development of presentation services. A single team of hardcore developers can create an extensive object library, thereby dealing with all the technical issues up front and letting the more user-oriented people-shielded from some of the hairier business rules-develop all kinds of front ends using a simplified toolset.
Let's look at an example of a leading-edge set of technologies for implementing
a three-tier architecture. Figure 2 shows several application components
built using CORBA objects and messaging, Java as a programming language,
and an Oracle database server. The presentation layer in this example allows
two different kinds of access to the same business processes: through a
thin client and a fat client.
Figure 2. Sample three-tier architecture
In this example, the thin client is supported by an intranet server. This arrangement keeps the client PC "thin" by requiring only the installation of a browser. The presentation logic-including data validation checks, window navigation, and other pieces of the user interface-is stored on the server and passed to the client as needed. This client may even be an NC or NetPC.
In contrast, the fat client has all the presentation logic (and often much of the process logic) stored on its local hard drive (or a LAN). With Java, the presentation server components are still loaded as required, but not across the network. This approach really isn't very fat, but it does require that the client PC have more than just a browser loaded. The most fascinating thing about this technology is that the Java client application (consisting only of presentation services) runs in a completely identical manner in fat and thin clients.
By the way, this example is real as well as practical. I was part of a team that built a prototype customer management and scheduling system with the capabilities I've described. Aside from the Java IDE (Visual J++) and a couple of Java textbooks, we downloaded everything we needed off the Internet. The system took only a few weeks to build, even including the developers' learning curve.
A number of business benefits are provided by a three-tier architecture, even when compared with two-tier client/server. They include:
As with all technologies, three-tier gives you the opportunity to reap these benefits, but only if you use it correctly. To use three-tier architectures effectively, you must plan the infrastructure (organizational and technology), selection process, and development methods thoroughly. As with most client/server systems, cost savings will appear only over time, because of the inevitable learning curve and investment associated with new technology. Furthermore, three-tier systems are inherently more complicated because of the number of services that need to be managed, and because the tools are still basically skeletons around which developers will have to build. Over the long term, however, three-tier gives you flexibility that most legacy and two-tier systems simply cannot provide.
Probably the biggest implication for designers and developers is the
separation of presentation and process logic. It is so easy-particularly
if you use 4GLs such as Visual Basic and PowerBuilder-to combine the presentation
(visual or graphical processing) with the business-processing code. For
example, a search screen usually needs to include a set of fields into which
the user types the selection criteria. In the code for the search button,
it's easy to build the appropriate SQL by using the data in the fields.
The returned data is displayed in a grid control on the bottom of the screen.
All this code neatly fits in the "when search button clicked"
subroutine (see Figure 3).
Figure 3. Example program structures
In a three-tier architecture, you'll need to create a server process (service) for the "search," which would accept some parameters and return some memory structure. This service would then be invoked by the search button subroutine, eliminating data access code from the presentation code. Sounds fairly simple, but it is more work than the "old" two-tier way.
Most processes-such as insert, update, or delete on a single data item-are fairly easy to set up as services. The search process, however, is more complex: There is no way to know how many rows will be retrieved from the database. With some three-tier toolsets, this constraint can be problematic because of the limits to the available memory structures. If possible, the best method is to send all retrieved rows. If not, you should at least prescribe a set maximum of returned rows and let the presentation service handle the user (for example, "This query would retrieve more than 100 records. Please refine your criteria and try again"), or open a cursor and accept requests for the "next 100" records.
Object-oriented design can be a big help when planning for this extra complexity. By building a comprehensive library of business process objects, the people developing the presentation services are shielded from most of the technical complexities. This benefit makes the final system simpler, especially over the long run.
Another challenge when developing three-tier services is that of persistence. Some tools let you create a "conversational" link between the presentation and process services, which is similar to a database connection in a two-tier system. This link enables the process service to maintain information about each individual presentation client. One of the benefits of a three-tier architecture, though, is that the services need only be invoked as required, and each invocation should be a standalone transaction. Creating a persistent conversation would cause enormous overheads with a large number of users. Instead, persistence requirements (such as where you currently are in a search or the user's security access level) must be handled carefully-you'll have to experiment with your tool of choice.
On the positive side, three-tier techniques are an absolute requirement for Web-based applications; performing all your application development in three tiers now makes it that much easier to support your Internet, intranet, and extranet later. In fact, specifying individual process services lets you simplify the differences amongst your internal intranet/extranet users and your external Internet users.
As three-tier technology becomes more and more popular, more and more vendors are entering the market. Here's an overview, grouped into broad categories, of some of the available products. Note that many of these products are in fact middleware toolsets that provide a mechanism for you to build your own services.
TP monitors. The granddaddies of the three-tier world, TP monitors originate from the mainframe environments of the 1970s, when processors were becoming very adept at managing a large number of users on a single application (such as airline reservations and banking). IBM's CICS, one of the original TP monitors, is still around and has been reinvented as an "open" product, available now on non-IBM platforms such as the HP 9000. The top position, though, belongs to Tuxedo, which has changed hands a few times and is now the main product of BEA Systems. Tuxedo is the original "open" TP monitor, available on most Unix variants and supporting any XA-compliant data source. Other big players include Top End from NCR and Encina from IBM.
TP monitors offer some tricks that are particularly well suited to large-scale (over 500 users) OLTP applications. They inherently manage failover and load balancing when more than one server is involved, and they are very efficient at pumping transactions around the network. Most TPC benchmarks are performed using TP monitors to achieve the most efficient use of the hardware.
A TP monitor typically comprises an administration tool, a set of background processes that manage the work, and a set of subroutine libraries (the API) that you call from your programs (which become the services in our three tiers). The API usually supports a number of languages, such as C and Cobol, and it's getting easier to find 4GL products that can access (and be accessed by) TP monitors.
Database servers. Just about every multiuser database server these days provides stored procedures of some sort. The stored procedure language is not yet standardized, which gives database vendors an opportunity to lock you in (at least until the ANSI SQL stored procedure language is finalized and implemented). However, if you stick to stored procedures and refuse to include direct SQL calls in your presentation code (using only stored procedures to access the database), you'll have a tremendously flexible system that lets you place your application services wherever you'd like (provided a database engine is there). You could even set up a database server that processes stored procedure calls exclusively, accessing data on one or more separate servers.
Application Development Tools. A growing number of development tools provide mechanisms to support a three-tier approach in their own environment-including PowerBuilder, in which you can write server objects that communicate with client objects, and Oracle Developer/2000, which lets you place your PL/SQL modules in either the client code package or the database's stored procedures. Some purpose-built three-tier toolsets, such as Forté and Dynasty, provide similar facilities.
In general, these three-tier mechanisms are relatively easy to use because they're built into the development toolset. However, they're usually proprietary mechanisms that give vendors another potential lock-in. Regardless, the potential exists to link-in with open middleware, so a larger number of development tools support the big TP monitors directly.
Remote Procedure Call (RPC). An RPC is a simple mechanism (for programmers, anyway) that lets a client invoke a server process in the same way it might invoke a subroutine. To the programmer, it's just another procedure call.
As with normal procedures, this mechanism is a synchronous one: The server must be working at the time the call is made, and the client must wait until the call is finished (like a phone call). A stored procedure is basically a special type of RPC.
RPC is a relatively old technology and has a number of limitations, especially compared to more sophisticated mechanisms. For example, RPC mechanisms have no load balancing, nor do they manage multiple instances (multithreading).
MOM (Message-Oriented Middleware). MOM is a standard being developed by MOMA (the MOM Association). It works under an asynchronous concept in which the client sends a message and "forgets" about it-a bit like the postal system. IBM's MQSeries is a high-profile example of MOM, and BEA Systems (owner of Tuxedo) has recently purchased Digital's MOM product set. The exciting thing is that these very open products also have good links into TP monitors and other non-MOM tools, so you can mix and match to suit your needs.
Distributed Objects. The wave of the future, distributed objects are just now becoming realistic. The main object-oriented middleware products are governed by the universally accepted Common Object Request Broker Architecture (CORBA), a product of the Object Management Group (OMG). The number of CORBA-compliant tools is growing daily; many vendors consider it the most open and complete mechanism for three-tier objects. Other (competing) standards include Microsoft's OLE/DCOM (Distributed Component Object Model) one-two punch and Java's Remote Method Invocation, which is built into version 1.1 of the Java Development Toolkit.
This technology still has some major gaps to be filled (such as TP-level load balancing), but its capabilities are growing fast. Of special significance is the fact that most major R&D in the packaged applications area is based on distributed objects, so we'll probably see the big package vendors release applications using this technology within three or four years.
Despite these advantages, a number of challenges to implementing a three-tier architecture exist, including:
1. High short-term cost. Three-tier development is inherently more costly than more traditional models because you have to go out of your way to split process services from presentation services. Managing the development environment is also more complex and costly.
2. Training. Most three-tier toolsets are relatively immature, so only a limited choice of training is available. You may need to develop courses yourself, especially if you don't live in North America.
3. Experience. Same problem. It will be nearly impossible to find people who have any experience building three-tier systems.
4. Incompatible standards. TP monitors suffer from a virtual lack of standards and openness. Conversely, distributed objects suffer from a surfeit of competing standards, and no one knows which one will win out.
5. Few commercial distributed objects. Packages won't have object components for at least three years, and the rest of the third-party industry is still in its infancy. In the short term, a three-tier object architecture will cost more, because you'll be writing most of the code yourself.
6. Limited choice of tools. Integrated development toolsets (consisting of tools for modeling, data and code generation, visual programming, code editing, team development, testing, reporting, and deployment) are not available. Most 4GL tools make two-tier applications very easy to build, but they can make three-tier development a nightmare.
7. Lack of end-user tools that work with your services. Generic tools (such as end-user reporting tools and spreadsheets) are as yet incapable of operating through middle-tier services. CORBA holds the most promise because it includes an object dictionary much like those in the RDBMSs used by current tools. Without these dictionaries, you must severely restrict middle-tier services, and you don't have much flexibility in the presentation level.
Using a three-tier approach to systems development, you can cash in on a whole range of business benefits. In some cases, especially those involving very large client/server systems with many users, using some three-tier technology can't be avoided.
As for future developments, commercial components are becoming available that make the choice of selecting a package (or module) or developing one from scratch much easier. Designers will find that they need to learn new techniques to take advantage of three-tier technology. Analysts will also be encouraged to use object-oriented methods as business objects become more ubiquitous in the middle tier.
Business and technology change extremely rapidly, and a three-tier architecture helps your business react more quickly to these changes. In fact, three-tier technology has become so effective (and popular) that you would be foolish not to include it in your information technology strategy.
Charles Thompson is a manager at Deloitte & Touche Consulting Group in Wellington, New Zealand. He divides his work among information technology strategies, client/server project management, and database development, which lets him devote the rest of his waking hours to developing his three young kids. You can contact him via e-mail at [email protected].