Hardware, software, database, and network technologies all contribute to distributed and cooperative computer architectures. In its most ge...
Hardware, software, database, and network technologies all contribute to distributed and cooperative computer architectures. In its most general form, a distributed and cooperative computer architecture is as illustrated in figure. A root system, sometimes a mainframe, serves as the repository for corporate data. The root system is connected to servers (typically powerful workstations or PCs) that play a dual role. The servers update and request corporate data maintained by the root system. They also maintain local departmental systems and play a key role in networking userlevel PCs via a local area network (LAN).
In a c/s structure, the computer that resides above another computer is called the server, and the computer(s) at the level below is called the client. The client requests services, and the server provides them. However, within the context of the the architecture represented in figure below, a number of different implementations can be achieved :
File servers. The client requests specific records from a file. The server transmits these records to the client across the network.
Database servers. The client sends structured query language (SQL) requests to the server. These are transmitted as messages across the network. The server processes the SQL request and finds the requested information, passing back the results only to the client.
Transaction servers. The client sends a request that invokes remote procedures at the server site. The remote procedures are a set of SQL statements. A transaction occurs when a request results in the execution of the remote procedure with the result transmitted back to the client.
Groupware servers. When the server provides a set of applications that enable communication among clients (and the people using them) using text, images, bulletin boards, video, and other representations, a groupware architecture exists.
Software Components for c/s Systems
Instead of viewing software as a monolithic application to be implemented on one machine, the software that is appropriate for a c/s architecture has several distinct subsystems that can be allocated to the client, the server, or distributed between both machines:
User interaction/presentation subsystem. This subsystem implements all functions that are typically associated with a graphical user interface.
Application subsystem. This subsystem implements the requirements defined by the application within the context of the domain in which the application operates. For example, a business application might produce a
variety of printed reports based on numeric input, calculations, database information, and other considerations. A groupware application might provide the facilities for enabling bulletin board communication or e-mail. In both cases, the application software may be partitioned so that some components reside on the client and others reside on the server.
Database management subsystem. This subsystem performs the data manipulation and management required by an application. Data manipulation and management may be as simple as the transfer of a record or as complex as the processing of sophisticated SQL transactions.
In addition to these subsystems, another software building block, often called middleware, exists in all c/s systems. Middleware comprises software components that exist on both the client and the server and includes elements of network operating systems as well as specialized application software that supports database-specific applications, object request broker standards , groupware technologies, communication management, and other features that facilitate the client/server connection. Orfali, Harkey, and Edwards have referred to middleware as “the nervous system of a client/server system.”
The Distribution of Software Components
Once the basic requirements for a client/server application have been determined, the software engineer must decide how to distribute the software components that constitute the subsystems between the client and the server. When most of the functionality associated with each of the three subsystems is allocated to the server, a fat server design has been created. Conversely, when the client implements most of the user interaction/presentation, application, and database components, a fat client design has been created.
Fat clients are commonly encountered when file server and database server architectures are implemented. In this case, the server provides data management support, but all application and GUI software resides at the client. Fat servers are often designed when transaction and groupware systems are implemented. The server provides application support required to respond to transactions and communication from the clients. The client software focuses on GUI and communication management.
Fat clients and fat servers can be used to illustrate the general approach for the allocation of client/server software systems. However, a more granular approach to software component allocation defines five different configurations:
Distributed presentation. In this rudimentary client/server approach, database logic and the application logic remain on the server, typically a mainframe. The server also contains the logic for preparing screen information, using software such as CICS. Special PC-based software is used to convert character-based screen information transmitted from the server into a GUI presentation on a PC.
Remote presentation. An extension of the distributed presentation approach, primary database and application logic remain on the server, and data sent by the server is used by the client to prepare the user presentation.
Distributed logic. The client is assigned all user presentation tasks and the processes associated with data entry, such as field-level validation, server query formulation, and server update information and requests. The server is assigned database management tasks and the processes for client queries, server file updates, client version control, and enterprise-wide applications.
Remote data management. Applications on the server create a new data source by formatting data that have been extracted from elsewhere (e.g., from a corporate level source). Applications allocated to the client are used to exploit the new data that has been formatted by the server. Decision support systems are included in this category.
Distributed databases. The data forming the database is spread across multiple servers and clients. Therefore, the client must support data management software components as well as application and GUI components.
In recent years, there has also been considerable emphasis on thin-client technology. A thin client is a so-called “network computer” that relegates all application processing to a fat server. Thin clients (network computers) offer substantially lower per unit cost at little or no significant performance loss when compared to desktop machines.
Guidelines for Distributing Application Subsystems
While no absolute rules cover the distribution of application subsystems between the client and server, the following guidelines are generally followed:
The presentation/interaction subsystem is generally placed on the client. The availability of PC-based, Windows-based environments and the computing power required for a graphical user interface makes this approach cost effective.
If the database is to be shared by multiple users connected by the LAN, it is typically located on the server. The database management system and the database access capability are also located on the server together with the physical database.
Static data that are used for reference should be allocated to the client. This places the data closest to the users that require them and minimizes unnecessary network traffic and loading on the server.
The balance of the application subsystem is distributed between the client and server based on the distribution that optimizes the server and client configurations and the network that connects them. For example, the implementation of a mutually exclusive relationship typically involves a search of the database to determine if there is a record that matches the parameters for a search pattern. If no match is found, an alternate search pattern is used. If the application that controls this search pattern is contained fully on the server, network traffic is minimized. The first network transmission from the client to the server would contain the parameters for both the primary and secondary search patterns. Application logic on the server would determine if the secondary search is required. The response message to the client would contain the record found as a result of either the primary or the secondary search. The alternate approach of placing on the client the logic to determine if a second search is required would involve a message for the first record retrieval, a response over the network if the record is not found, a second message containing the parameters for the second search, and a final response with the retrieved record. If the second search is required 50 percent of the time, placing the logic on the server to evaluate the first search and initiate the second search, if necessary, would reduce network traffic by 33 percent.
The final decision on subsystem distribution should be based not only on the individual application but on the mix of applications operating on the system. For example, an installation might contain some applications that require extensive GUI processing and little central database processing. This would lead to the use of powerful workstations on the client side, and a bare bones server. With this configuration in place, other applications would favor the fat client approach so that the capabilities of the server do not need to be upgraded.
As the use of the client/server architecture has matured, the trend is to place volatile application logic on the server. This simplifies deployment of software updates as changes are made to the application logic.
Linking c/s Software Subsystems
A number of different mechanisms are used to link the various subsystems of the client/server architecture. These mechanisms are incorporated into the network and operating system structure and are transparent to the end-user at the client site. The most common types of linking mechanisms are:
• Pipes. Widely used in UNIX-based systems, pipes permit messaging between different machines running on different operating systems.
• Remote procedure calls. These permit one process to invoke the execution of another process or module which resides on a different machine.
• Client/server SQL interaction. This is used to pass SQL requests and associated data from one component (typically on the client) to another component (typically the DBMS on the server). This mechanism is limited to relational database management system (RDBMS) applications.
In addition, object-oriented implementation of the c/s software subsystems results in “linkage” using an object request broker. This approach is discussed in the following section.
Middleware and Object Request Broker Architectures
The c/s software subsystems discussed in the preceding sections are implemented by components (objects) that must be capable of interacting with one another within a single machine (either client or server) or across the network. An object request broker is middleware that enables an object that resides on a client to send a message to a method that is encapsulated by an object that resides on a server. In essence, the ORB intercepts the message and handles all communication and coordination activities required to find the object to which the message was addressed, invoke its method, pass appropriate data to the object, and transfer the resulting data back to the object that generated the message in the first place.
Three widely used standards that implement an object request broker philosophy— CORBA, COM, and JavaBeans. CORBA will be used to illustrate the use of ORB middleware.
The basic structure of a CORBA architecture is illu strated in figure. When CORBA is implemented in a client/server system, objects and object classes on both the client and the server are defined using an interface description language, a declarative language that allows a software engineer to define objects,attributes, methods, and the messages required to invoke them. In order to accommodate a request for a server-resident method by a client-resident object, client and server IDL stubs are created. The stubs provide the gateway through which requests for objects across the c/s system are accommodated.
Because requests for objects across the network occur at run time, a mechanism for storing the object description must be established so that pertinent information about the object and its location are available when needed. The interface repository accomplishes this.
When a client application must invoke a method contained within an object elsewhere in the system, CORBA uses dynamic invocation to (1) obtain pertinent information about the desired method from the interface repository, (2) create a data structure with parameters to be passed to the object, (3) create a request for the object, and (4) invoke the request. The request is then passed to the ORB core—an implementation-specific part of the network operating system that manages requests—and the request is fulfilled.
The request is passed through the core and is processed by the server. At the server site, an object adapter stores class and object information in a server-resident interface repository, accepts and manages incoming requests from the client, and performs a variety of other object management functions . At the server, IDL stubs that are similar to those defined at the client machine are used as the interface to the actual object implementation resident at the server site.
Software development for a modern c/s system is object oriented. Using the CORBA architecture described briefly in this section, software developers can create an environment in which objects can be reused throughout a large network environment.
