Application Architectures
© 2001 Lawrence G. DiGiovanni
Digico, Inc.
www.digicoinc.com
Preface
One of the primary descriptors of a data processing application refers to the method of distribution of the workload. This paper is an attempt to describe four of the well-known arrangements with respect to the technology, the benefits, and the downsides of each.
Introduction
This paper will describe, compare, and contrast the following four architectures commonly used to develop and deliver data processing applications. The goal of this paper is to impart to the reader not only the what, but also the why, and the resulting understanding can hopefully dispel some commonly held misconceptions to each.
The architectures we will focus upon are as follows:
Host Based
Desktop
Client/Server
N-Tier
For each, we will present an overview of the technology arrangement, describe one or more common implementations of each, and describe pros and cons of each.
Host Based
Most early data processing systems ran on mainframe and minicomputers, and user interaction was via desktop terminals (a.k.a. "dumb" terminals).
Technology |
A "host" system (usually a mainframe or minicomputer), upon which the entire application executes, with user interaction occurring via terminal or terminal emulator. Every aspect of the application occurs at the host, from data access to the processing of each individual user keystroke. The user interface is rendered on the terminal through the interpretation of character data and escape codes sent by the host. |
Example |
An IBM mainframe, running a COBOL program, with the user interacting via a 3270 terminal (or terminal emulator).
Or
A VAX 11/780, running a C application, with the user interacting via a VT-100 terminal (or terminal emulator).
Or
An IBM PCAT, running RBBS PC (or Fido, or Galacticomm, etc.) Bulletin Board software, with the user interacting via a VT-102 or ANSI terminal emulator.
|
Pros |
Because of the level of access to which the administrators can usually restrict the users, security on such systems can be very tight.
All of the components of such a system are maintained on the host system itself, so system maintenance and upgrades are a function of the host machine only. Configuration management can be rigidly controlled, and software upgrades need only be performed on the host system.
This type of architecture can be used to develop a workable user interface in extremely low bandwidth implementations, even below 9600bps.
|
Cons |
Such systems limit the complexity of the user interface, and they usually cannot use modern user interfaces, like a mouse.
Most incarnations of this architecture are fairly expensive with respect to both equipment and personnel costs, are and usually overkill for personal or small business use.
|
Desktop
The advent and widespread use of the personal computer led to the development of a number of desktop database systems and languages geared towards this market. With the development of personal computer networking technologies, it was also possible to develop multiuser versions of such systems.
Technology |
A personal computer running a program that directly accesses data and index files located on the computer’s local storage or on network accessible (shared) storage. All aspects of the application execute from the user’s computer, from the user interface to the data access logic. On a network, the network OS handles remote, low-level file handling capabilities. |
Example |
An IBM PC, running an executable program, written in Clipper Summer ’87, which writes to and reads from data (.dbf) and index (.ntx) files located on it’s local C: drive.
Or
A Windows 98 PC, running Paradox 10, executing an application which reads from and writes to data (.db) and index (.PX, .X*, .Y*) files located on a Novell file server, shared by 30 other users.
|
Pros |
The cost of the tools is usually low, and most contemporary packages promote rapid prototyping and rapid application development.
Because these tools provide the developer direct access to the data files, a skilled developer can tune data access routines for excellent performance, rather than relying on the data access decisions made by query optimizers, etc.
|
Cons |
Since they require direct access to the data, these systems require high bandwidth available between the client machine and the data, usually Local Area Network or high speed leased lines.
The ability of these systems to support large numbers of simultaneous users is limited by a number of factors, including network bandwidth and shared file server performance.
Since program execution occurs on the user’s computer, all of the required software must be accessible to the user’s computer, including application executables, any required runtime for the application executables, and data access middleware. For larger systems, this can create a significant burden for configuration management.
Because data access is accomplished via direct file access by the user’s workstation, such architectures are more exposed to data corruption than those that limit such access. Also, data security is an issue, since there is no foolproof way to isolate users from the data.
|
Client/Server
Client/Server architectures isolate data access from user interface through the use of a database server. This technology grew in use during the 1980s and became the prevalent enterprise architecture during the 1990s.
Technology |
A database server running one of a variety of client/server RDBMS systems, interfaced with a client application through a middleware layer, such as SQL Links, or OCI, which in turns "rides" upon a lower level network interface, such as TCP/IP or IPX. Instead of accessing the database through low-level file access, the client communicates with the server using some form of a call interface. Typically, this interface allows compact requests for data to be communicated to the server from the client, and result sets or cursors to be returned to the client from the server. |
Example |
An MS-DOS application, written in Magic, which communicates with a Btrieve database hosted on a Novell file server, which communicates via the proprietary Btrieve interface.
Or
A Windows application, written in C++, which communicates with an Oracle database hosted on a Unix server, which communicates via OCI and SQL*Net.
Or
A Windows application, written in Paradox 10, which communicates with a MS SQL Server database hosted on an NT Server, which communicates via ODBC and NetBeui.
|
Pros |
This technology can be implemented so as to drastically reduce bandwidth requirements between the client workstation and the server database, so that effective applications can be developed which can be run over 56k analog phone connections.
Databases hosted on database servers can have business rules enforced directly by the database server. This aids in enforcing business rules within the database.
Because the client machine does not have direct access to the database, data integrity and security are more readily achieved.
System scales easily by improving the performance of the database server only.
|
Cons |
Program execution still occurs on the client workstation, requiring application executables, runtimes, as well as the middleware and network interface software be distributed to the user workstations. This results in a configuration management overhead similar to or exceeding desktop architectures.
Data access is accomplished via data sublanguages, which create an additional development discipline to be utilized and maintained by developers.
The resources required to develop, deploy and maintain such an architecture can be expensive. Many client/server RDBMS packages require at least a part time database administrator (DBA).
|
N-Tier
N-Tier (or multi-tier) architectures are generally equated with Web based development, but there are non-web based platforms which are also multi-tier capable.
Technology |
The technology is characterized by a physical or logical partitioning of user interface, data access, and application processing between three distinct platforms: the client, the database server, and the application server. |
Example |
A browser based application, which browses dynamic HTML rendered by an IBM Websphere application server, connected to a DB/2 database.
Or
An Xwindows application, running on an X client, which processes Xwindows input/output to a Unix HP9000 application server, running a C application which uses embedded SQL to communicate with an Informix database.
Or
A browser based application, which browses dynamic HTML rendered by the Paradox web OCX, connected to a Paradox database.
|
Pros |
Distribution of code is within the application server and database servers only, which allows for easier configuration management. In many cases, the client software requirements are a web-browser and a TCP/IP connection to the application server. This "thin-client" paradigm allows multiple business applications to be deployed and enabled to the desktop with no impact to the desktop.
Data are isolated from the user, enabling better data integrity and security, and limited risk of corruption.
Bandwidth requirement can be very minimal.
Exceptional scalability. Application servers remove some of the load from the database server, and application servers can be farmed for load balancing.
|
Cons |
Usually results in multiple skills requirements and code base maintenance across multiple languages.
In a Web environment, the immediacy of the data and the ability to create a rich user interface are somewhat limited by the nature of the display medium. This can be improved by installing server side applets, etc., but that begins to eat into some of the other benefits.
As with client/server, the backoffice requirements for such a solution usually involve someone to assume the responsibility for the application server(s) and database server(s).
|
Summary
The four application architectures we have presented here each have different strengths and weaknesses that make each attractive for some application requirements and less attractive for others. Hopefully, we have reduced thinking along the lines of "old" vs "new" technology, and have demonstrated that all of the above application architectures will continue to play important and permanent ongoing roles in software development.
Discussion of this article
|