| Introduction | Client/Server on the Web | |
This chapter introduces some of the basic principles of client/server applications and explains their advantages over the more traditional monolithic architecture. It also suggests how to divide your application into modules that make the most of client/server architecture, and outlines the platforms on which Net Express applications can be deployed.
Despite a rapid increase in the deployment of client/server applications, there is still a certain amount of mystique surrounding the term 'client/server', especially as the same term is often used to describe a number of different concepts.
In principle, a client/server application consists of a client program that consumes services provided by a server program. The client requests services from the server by calling functions in the server application. In a distributed computing environment, where the client program and the server program execute on different machines and possibly even on different platforms, the client and server communicate through a communications layer that is often called middleware.
Figure 2-1: Basic client/server architecture
Although applications that are running on different machines obviously require those machines to be physically connected in some way - usually by a network (LAN, WAN or Internet) - it is important to distinguish between the network architecture and the client/server application architecture. The client application might run on a network client or a network server. The client and server applications might run on the same machine, which could be a network client or a network server, or neither! A client/server application is described as such solely because of its own architecture, without reference to how it is deployed on a network. For example, the X system used for graphical front-ends on many UNIX systems is a client/server application. However, the server part of the application often runs on the network client machine, with the client part of the application running on the network server! The easiest way to remember which is the client part of an application is to remember that the client is always the requestor of services.
The following are typical features of a client/server application:
COBOL applications request services by using the CALL statement. The request for a service is actually a call to a function implemented in a procedure. Although CALL statements are usually associated with local functions - that is, procedures that execute on the same machine as the calling program - they can equally be associated with remote functions that execute on a different machine. When a CALL is used in this way, it is often referred to as a remote procedure call, or RPC. A key requirement for the rapid development of client/server applications is that remote procedure calls should be handled independently of the network protocol in use; this enables you to concentrate on coding your application rather than handling the underlying network. Net Express is supplied with a simple RPC mechanism called client/server binding, which provides a straightforward network-independent communications layer between client and server programs.
Most of the benefits of using client/server architecture for enterprise applications relate to flexibility of deployment and relative ease of maintenance. For example, using client/server architecture you can typically:
To maximize the potential value of using a client/server architecture, you should adhere to some basic design guidelines. These are outlined below.
To gain the most benefit from using a client/server architecture for new applications or as a conversion exercise when updating existing applications, it is essential to logically (and often, physically) separate the different layers of functionality in the application so that they are not indiscriminately mixed together. A typical approach is to split the logical functions of the application into three:
Conceptually, each of these three areas of functionality - or layers - are handled by separate programs. The user interface logic is always handled by the client application. If the client application handles only the user interface logic, it is called a thin client. Sometimes some, or even all, of the business logic is also handled by the client application; this is called a thick client.
When you create a client/server application, it makes a lot of sense to apply this conceptual division of functionality to the actual program code, so that you create physically separate programs for handling each of the three layers. In a distributed computing environment, each of these programs might run on different machines - but they would work equally well if they were all running on the same machine.
A Web application is the ultimate thin client. The user interface is handled entirely by the user's Web browser. Although the definition of the interface is provided as an HTML form which resides on the Web server, it is downloaded temporarily under the control of the Web browser.
Net Express is designed to enable you to create 32-bit Web-based and network-based client/server applications that can be deployed on the following platforms:
(Applications created with Internet Application Wizard are not suitable for deploying on UNIX)
We have tested the following platforms and believe them to be generally compatible with Net Express Web applications:
As Web applications created by Net Express conform to the relevant international, platform-independent standards, it is highly likely that they will work correctly when deployed on other TCP/IP-capable client platforms with appropriate Web browsers. However, as each application has individual requirements, we advise you to test your application thoroughly on all target systems before deployment.
Copyright © 2000 MERANT International Limited. All rights reserved.
This document and the proprietary marks and names
used herein are protected by international law.
| Introduction | Client/Server on the Web | |