Commonly written client/server. The concept behind this system design architecture, is that the task at hand can be divided into a client part and a server part.

The client part sends requests to the server part: the server part tries to satisfy them.
Usually the client handles the user interface, that's to say, the typical user of the system uses the client, while the server handles the data storage and computation.

Examples:

  1. airline reservation systems (like SABRE). You have a million terminals that operators use to reserve and buy seats on planes. The actual reservation and ticketing data is stored on a big computer somewhere, called the server.
  2. The WWW. A client program (normally called a browser) sends requests to a server: the requests are coded in HTTP, and the server sends back text and images.
  3. Checkout systems in supermarkets: each cashier mans a client, and a central inventory and accounting system receives the transaction information and updates the inventory and the books.
  4. A MOO: the central server maintains reality consistent, while the clients modify bits of the world and interact with it.
A client server system is well suited to situations where you want to centralize data (either because it is very expensive or because it has to be consistent) or where you have a very expensive resource that has to be shared (like a very big iron).
Client server systems are inherently asymmetric, that's to say that there is a different load on the server than on the client (that is why usually a server is a big system).
There can be also asymmetries in communications traffic. For example, Web network traffic is highly asymmetrical, because for every tiny (1 Kilobyte) client request there is a usually larger server answer.

Opposed to peer to peer, where the participating entities are on the same level (a good example of this is Windows 98 file sharing)

Client Server computing is rapidly changing as three main forces attempt to set a standard. One camp is Microsoft with its Windows operating system and DCOM. Another is the Object Management Group (OMG) and its CORBA-based distributed- objects model. The third group is SUN and the Enterprise JavaBeans (EJB) environment based on the Java programming language.

The material presented in this node is derived primarily from an article on the CORBA-based model published in ACM Computing Surveys (Lewandowski 1998). Mr. Scott Lewandowski presents a technologically superior model for Client/Server computing, but goes on to imply that technological superiority does not guarantee dominance. 1 The EJB environment is described separately in Enterprise JavaBeans.

I. Definition of Client/Server

Client/Server is an interrelated, but independent, set of software and hardware components that dynamically open and close transparent relationships, based on the request/response paradigm, that are mutually beneficial to the participating entities.2

An interrelated set of software and hardware components means there are at least 3-tiers of interacting entities: a client, a server, and a data repository. A client is a net consumer requesting services from a server, which is a net provider. The server may in turn obtain informational resources from a data repository in order to meet the client request. The entities are independent and self-contained and may interact with any number of other Client/Server entities. The relationships are dynamic in that they begin and end based on the request and response of the entities. When the request has been fulfilled the relationship ends. The relationships are transparent in that each entity is self-contained. The method by which each entity carries out its part in the relationship is not visible to any other entity.

Lewandowski presents this vision of Client/Server based on Distributed Objects interconnected via the Common Object Request Broker Architecture (CORBA). Objects encapsulating data and functionality would be created new or be "wrapped around" legacy informational systems. Under a distributed environment these diverse objects would take responsibility for managing their own resources. Distributed objects could then form relationships ad hoc in diverse configurations creating applications to fill specific requests. CORBA provides the language- and system implementation-neutral communications mechanism to allow such relationships.

Compare the CORBA vision to the Microsoft ideal. The latter wish to maintain control of their installed base of Windows operating systems. Distributed Component Object Model (DCOM) is actually a set of services or interfaces and does not follow the traditional, independent-object model. This version of Client/Server computing tries to incorporate too much functionality in a central location - the operating system. The technologically superior version is the CORBA-based distributed object model. It will allow the type and number of interactions between objects to grow exponentially developing new relationships and ideas that will benefit commerce. The DCOM model is too centralized and will in the long run constrain the relationships that can enhance commerce.

II. Glossary of Client/Server Terms
1. Client
A net consumer of services. It is presentation software that makes a request for information and then displays it in a user-desired manner. Most often via a graphical user interface (GUI).


2. Server
A net provider of services. It generally is software running on a separate machine from the client. It is encapsulated so that its service- providing mechanisms are hidden from clients. A server may assist many clients.


3. Middleware
A framework of software that facilitates the communication between the parts of Client/Server systems. Examples include CORBA, DCOM, ODBC, SQL and EJB.


4. Objects
A software abstraction that couples data and the operations to process that data together into a self-contained entity. "Objects provide a clean way separating related data and functionality from other parts of a system in order to ease system construction and maintenance"3


5. Distributed Objects
An extension to the Object paradigm. The objects may reside anywhere on a network. They will retain their existence independent of any program, application, or other objects. They may be accessed by other objects or programs via standard message protocols contained in the Middleware.


6. Business Objects
Self managing components representing key objects or processes of a real-life system. They are composed of three cooperating components: Presentation Objects to represent the Business Object to a user; Business Logic Object to embody functionality and data of the Business Object; and Business Process Object to interact with the system as a whole and maintain long-lived processes.


7. CORBA
Common Object Request Broker Architecture. It is middleware software that provides structure for the client, server, data repositories, and other distributed objects to interact seamlessly. CORBA supports the traditional notion of encapsulated, self-operating objects. It is an open-standard supported by many competing companies in the industry, but not by Microsoft.


8. IDL
Interface Definition Language. It is a language-neutral mechanism to define the services an object provides to a CORBA based Client/Server system. IDL is part of the CORBA specification for the seamless interaction between objects written in different computer languages or structured in diverse ways: from current object formats back to mainframe data structures on legacy business systems.


9. COM/DCOM
Component Object Model and Distributed Component Object Model. This is the Middleware standard supported by Microsoft and competes directly against CORBA. DCOM does not support the traditional notion of objects. Instead it is a collection of interfaces to services. DCOM objects do not provide "state": the results of a request/response interaction are not available to other clients.


10. Tiers
Tiers refer to the number of interacting components in a Client/Server system.

2-Tier refers to a two-component architecture predominant in the early 1990s. The two components were just the client and the server. A data repository was an integrated part of the server, if present. The business logic portion of the interaction was placed in either the client, the server, or both. This led to undesirable higher coupling between the client and server.

3-Tier refers to the current predominant model involving three interacting components: client, server, and data repository. This is a better model because the three components are encapsulated and hide the mechanisms by which each operates.

A variation on 3-Tier is N-Tier. N-Tier indicates that a higher number of interacting components may cooperate to fulfill a request. N-Tier describes the multi-object relationships that exist under a CORBA-based distributed component architecture.

Footnotes
1. Page 27, Lewandowski, 1998. As with VHS and BETA video technologies in the 1970-80s, dominance may result from the superior marketing efforts, in the present case, of Microsoft (DCOM) rather than technological superiority of OMG's CORBA/JAVA/Distributed Objects model.
2. Page 8, Lewandowski 1998.
3. Page 20, Lewandowski 1998.


Bibliography
Gama, E., Helm, R., Johnson, R., and Vlissides, J. 1995. Design Patterns: Elements of Reusable Object Oriented Software., Addison Wesley, Reading, MA.
Gralla, P. 1996. How Intranets Work, Ziff-Davis, Emeryville, CA.
Lewandowski, Scott M., 1998. "Frameworks for Component-Based Client/Server Computing", ACM Computing Surveys, Vol. 30, No. 1, March, pages 3 - 27.
Linthicum, D., 1997, David Linthicum's Guide to Client/Server and Intranet Development, John Wiley, New York.
Orfali, R., and Harkney, D. 1998. Client/Server Programming with Java and CORBA, 2nd ed. John Wiley, New York.
Orfali, R., Harkney, D., and Edwards, J. 1999, Client/Server Survival Guide, 3rd ed. John Wiley, New York.

Log in or registerto write something here or to contact authors.