Four Main Models of Client-Server Application Models

When client-server technology was being developed there were 4 dominant models: SQL (Structured Query Language) databases; Transaction Processing (TP) monitors; Groupware; and distributed objects.

SQL is the standardized query language used to make requests from databases. SQL supports distributed databases, which are different databases spread across several computer systems. This allows many users/employees to access databases that are networked together through LANs (Local Area Networks) simultaneously, insuring that all the data available throughout an organization is consistent and up-to-date. In addition to just manipulating data through simple commands/requests, SQL must also manage the functions that define these command/requests. This is done through stored procedures.

Stored procedures are a collection of commands and logical procedures that are stored on a server-side database. These procedures protect data integrity, conduct system maintenance, and execute the server’s application logic. Previously, SQLs were not standardized for database management, data replication, and user-defined data types. They were also not standardized in relation to format and protocols over networks. This made them costly and difficult to maintain due to the level of complexity in the using the language to write commands.

It is important to remember that SQL is a declarative programming language, which describes a problem rather than solving it. Data is retrieved by giving criteria rather than employing commands on ‘how’ to find the requested data. It is a declarative language rather than a function one. However, SQLs are popular because it is easy to build client-server applications in a single-vendor or single-server environment. (However, we know that this is increasingly not the case for larger businesses who mix-and-match products from different vendors.) GUI (graphic user interface) tools also make it easy to build SQL applications.

Transaction Processing monitors or TP monitors are another popular model for building client-server environments. TP monitors were programs developed to protect against system crashes when too many clients make too many requests from a single server. Originally, TP monitors were known as teleprocessing monitors and were used for multiplexing, allowing several clients to connect and work through one server. However, it developed into a program that breaks down other applications into pieces of code called transactions. Each transaction consists of a set of actions that comply with four properties known as ACID. Therefore, the actions within a transaction must be Atomic, Consistent, Isolated, and Durable. TP monitors are not necessary in single vendor/single server environments. They work best in three-tier architectures that employ load balancing. These three tier architectures are the user interface (UI), the functional logic for processing requests, and data storage/access. They are created on different platforms as independent modules and are then linked according to the business model’s needs.

Load balancing, another feature of TP monitors, is the even distribution of communications and processing over a network so that no device becomes overwhelmed. When one server reaches its threshold, requests are sent to other available servers. TP monitors ensure this process. Middleware employed by TP monitors is usually a transactional RPC (Remote Procedure Call) or peer-to-peer middleware. Peer-to-peer middleware insures that all users have access to the same data, execute the same procedures, and initiate communication.

Groupware uses five technologies to allow users to collect unstructured data into a set of documents. This is done by having multimedia management, e-mail, work-flow management, conferencing, and scheduling work together collaboratively. E-mail is its primary middleware. However, its greatest contribution comes from work-flow management. Work-flow is the process by which data gets sent to the appropriate parties that can act on it to move the work forward. It simulates real-life worker collaboration electronically, reducing the amount of manpower required to complete a business task.

The distributed object client-server model is the most flexible and is currently the vanguard of client-server architecture. Distributed objects are software modules that exist on multiple computer systems but are designed to work together. Objects are the individual units of data storage that are acted upon in object-oriented programming. Unlike other forms of programming that are mostly a collection of functions, object-oriented programming allows objects to receive and send messages and process data within the object. One of the factors that make distributed object models so flexible is their standardization. For example, OMG (Object Management Group) was one of the first to contribute to standardization by creating CORBA (Common Object Request Broker Architecture). CORBA allows objects or pieces of programs to communicate with each other regardless of operating systems or what programming language they were written in.

Benefits of Client-Server Models

The benefits of client-server models help businesses confront challenges in a variety of ways. For example, increasing complexity due to global marketing and remote online distribution requires a level of de-centralized accessibility to data and processes. Client-server models allow for easier and quicker communication between business departments and individuals. It also allows for easier coordination between customers, the businesses providing the service, and any supporting businesses outside the organization that are used to execute its services. The most powerful model currently is the distributed object model (DOM).

First Page: Client-Server Computing : Butler Model