The Basics of N-Tier Architecture
In the beginning, there were programs and databases running on computers that most users accessed via dumb terminals. That was a single-tier architecture--all of the data and all of the program logic typically ran off of the same machine. Then came two-tier, client-server systems, where the database sat on a back-end server and some or all of the programs and/or business logic was moved from the server down to the clients which were usually PCs or workstations. This took some of the load off of the servers, and was generally viewed as a good thing.

However, the client-server architecture has some inherent limitations. First, client software must be distributed and managed on a potentially large number of separate, diverse clients across the entire enterprise. If the software is changed, updated or replaced, the procedure to roll out the new client programs to all of the client computers across the enterprise in an organized fashion can be extremely challenging. Additionally, traditional client-server systems tend to be susceptible to interruption of service if the back-end server fails. So if that goes down or is inaccessible for any reason, nobody can access the system at all.

And now we have three-tier systems. There are a number of reasons for adding another layer, and two of the better ones are thin clients and distributed processing (for more on this see "Specifications for a Distributed World"). In a typical three-tier system, the first layer still houses the database or other centralized data stores; the second layer is where the programs and/or business logic is locatedsometimes on specialized application servers; and the third layer is the client.

In the thin client model, the client consists almost entirely of the user interface (UI). Here, the client layer can be lightweight, without a lot of code to port and maintain, because the business logic is handled in another layer, usually through the use of some form of middleware product, such as an application server. In fact, if a three-tier system uses a standard Web browser as the UI/client layer, it can reduce or eliminate the need to program a custom client at all, making the applications accessible to a wide range of client types and platforms. Anything that can run a Web browser is usable, including PCs, Macs, Network Computers, Unix workstations and Javastations. This increases portability across platforms and machine types, and also allows organizations to use older computers for accessing their state-of-the-art enterprise applications.

Residing the business logic on a middle-tier also allows for development, deployment and maintenance of most of the code on a small number of dedicated application servers, instead of onto hundreds or thousands of desktops. Three-tier systems can be engineered so that redundant copies of the application have access to redundant, replicated copies of back-end data sources. Back-end and middle-tier services can handle the details of data replication and synchronization, automatic load-balancing and failover in case of host failure. This increases overall system availability, performance and reliability for the users.

Specifications for a Distributed World
To take advantage of the benefits of distributed or cross-platform operation in a middleware solution, you need to understand the following terms and specifications. Most middleware products support one or more of these models:

· CORBA/IIOP (Common Object Request Broker Architecture/Internet Inter-ORB Protocol) This is the most widely used specification for communication and coordination between components. Working with the CORBA 2.0 specification generally requires highly trained engineers to write at a low level to a particular vendor's implementation of the standard. Using CORBA, an ORB (object request broker) coordinates communication and interaction between platform-independent components, which can be located on separate physical machines and written in different languages. CORBA 3.0, slated for final release during the first half of 1999, is expected to include asynchronous messaging and distributed computing features.

· COM/DCOM (Component Object Model/Distributed Component Object Model) DCOM is the distributed form of Microsoft's COM technology. COM components can be written in a variety of languages, including C++, Visual Basic and Java, and let developers deploy components that communicate transparently via any underlying form of network transport, such as TCP/IP, UDP/IP, HTTP and AppleTalk. Many of the services that make DCOM most useful, including transaction coordination and rollback, are handled by the underlying NT operating system or by the bundled Microsoft Transaction Server (MTS). MTS 2.0 will be folded into NT 5.0 as a part of Microsoft's move to COM+.

· EJB (Enterprise JavaBeans) Sun's EJB 1.0 specification is supported by IBM, Oracle, Netscape, Sybase and others, but it is relatively immature. Like CORBA, it remains to be seen just how much interoperability we'll see in products from different vendors, but it does promise support for distributed objects across multiple platforms.