The 'multi-tier' architecture concept, so expertly manipulated by SAP and others, is one of the smartest confidence tricks I've come across. There is no other way to build interactive commercial applications!
The key feature that SAP exploited was the implementation of the three-tier architecture in three different computers, interconnected on a network. Previously all three components were implemented in the same computer, interconnected by operating system functions; the only difference was that the actual physical user interface...
was a dumb terminal, and there was therefore only minimal support for the user layer. Mainframes implemented the three-tier architecture best of all by using logical partitioning to separate the application logic (Cics) from the database (DB2). Unix and earlier mainframes all ran the same combination of program and data management, in which the separation of logic and data was non-distinct (Unix with C-ISAM for instance).
Instead of properly developing the three-tier architecture, the availability of the PC and the RDBMS led up the wrong path to thick-client systems. Despite the advance of the GUI interface, this was a worse architecture than the terminal-based Unix systems, since now all the business logic was implemented in each and every PC, a concept doomed to failure from the beginning. The thin-client architecture is the only possible solution for multi-user, interactive business systems. In fact the only basic difference from the mainframe is that the user layer is separated to achieve the GUI interface. What we must recognise is that the three-tier architecture is one of logical and not physical partitioning.
IBM very nearly missed the boat with the three-tier architecture simply because they made it extremely difficult to replace the 3270 interfaces with thin client GUI terminals, by failing to solve the simple connectivity demands until late in the day. Now Ethernet, TCP/IP and remote calls such as Cics-client are readily available, making Cics the ideal logic layer and DB2 the database. If they had done this from the beginning, there would have been no thick-client problems to replace! But now there has been another revolution, e-commerce, which introduces a new dimension, namely support for a whole variety of remote users, connected over the Internet. They cannot be supported by thick-client software nor for that matter by PC/based thin clients a la SAP, thus the new requirement is to support the Web browser as the new GUI user interface, a BUI. But this is almost as dumb as a 3270 or ASCII terminal! Thus the concept of downloading executable code to the browser is the obvious answer and Java became the high profile solution.
Nowadays, since most new applications must be Web-enabled and most need internal interfaces as well, it makes sense to build both Internet and intranet interfaces the same, which implies a migration from Windows desktops to browser desktops (even those running on PCs).
Now that the basic three layers of the architecture are reasonably understood, there is an attempt to introduce some new, more descriptive terminology. Database server is the obvious one for the data layer. The term 'Application Server' has now been introduced for the business logic layer, but I particularly like IBM's terminology for the user layer, which they refer to as the 'Appliance Server'.
Application Server is a bit of a misnomer because most Application Servers are running code, which integrates with other system, particularly legacy business applications. Unless the Application Server is running the whole business logic component directly linked to the database, then it is more an 'Integration Server'. Further the term Application Server has in the main been applied to Java based servers with browser front-ends, whereas various technologies could be used for the same role e.g. Cics or Microsoft ASP.
However, the term Appliance Server is a good one, because the time has come to recognise that just as the PC replaced dumb terminals, the thin client architecture enables the use of a wide variety of user interfacing devices, including terminals and PCs, but also including telephony, kiosks, voice input, and a whole new range of devices. Thus a properly designed application can be used with a wide variety of front-end devices which requires some special services to match the specific device to the application since some devices can't support all functions. A PC can do more than a mobile phone, which is the obvious example, but there will be other variations coming along, hence the need for intelligent Appliance Servers. How about speech recognition and natural language devices as the next step?