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.
2.1 Client/Server Architecture
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.
2.1.1 What is a Client/Server Application?
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:
- A client program can request services from multiple server programs
- A client program does not need to be aware of the actual subprograms that provide a service
- Multiple subprograms can work together to provide the service
- Multiple client programs can request services from a single server program
- A server program can provide multiple services
- Typically, the server program runs on a machine that is remote from the machine running the client program
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.
2.1.2 Client/Server Benefits
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:
- Re-use existing legacy code for the business logic
- Run each functional layer of the application on the platform most suited to the task
- Distribute the processing and network loads
- Quickly and easily change business logic procedures without changing the client program or user interface
- Provide simple and convenient delivery of the application and any updates to end-users
- Provide alternative client user interfaces to the same server-side program
- Use development tools that are designed to work together
To maximize the potential value of using a client/server architecture, you should adhere to some basic design guidelines. These are outlined below.
2.2 Suggested Approach
2.2.1 Separating Program Logic
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:
- User interface logic (screen handling)
- Business logic (data processing)
- Data access logic (file or database handling)
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.
2.2.2 Supported Platforms
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:
- Operating systems supported directly:
- Windows NT V4.0 with Service Pack 3, 4 or 5
- Windows 2000
- Windows 98
- Windows 95
- Operating systems supported in conjunction with Object COBOL for UNIX V4.1 and/or Server
Express:
- Most SVR4-based UNIX systems, including:
- SCO
- AIX
- HP/UX
- Sun Solaris
(Applications created with Internet Application Wizard are not suitable for deploying on UNIX)
- Most SVR4-based UNIX systems, including:
- Network protocols supported:
- TCP/IP
- Microsoft Network
- IPX (Novell NetWare)
- NetBEUI
We have tested the following platforms and believe them to be generally compatible with Net Express Web applications:
- Web servers:
- Microsoft Information Server V4.0
- Microsoft Personal Web Server (as supplied with Windows NT V4.0 Option Pack)
- Netscape FastTrack Server V2.01
- Netscape Enterprise Server
- Apache web server (on UNIX)
- Web browsers:
- Microsoft Internet Explorer V5
- Netscape Communicator V4.7
- HTML Painters:
- Microsoft FrontPage 97
- NetObjects Fusion
- Sausage Software HotDog
- Softquad HotMetal Pro
- Middleware:
- IONA Technologies Orbix V2.3c
- Microsoft Transaction Server
- Oracle Pro*Cobol V1.8 and V8.0.4 database precompiler
- Sybase Open Client Embedded SQL/COBOL precompiler V11.5
- XDB ExpressLane V2.0
- Databases:
- Oracle V7 and V8
- Sybase V11.0.1
- Informix V9.x
- Microsoft SQL Server V7.0
- Microsoft Access 2000
- IBM DB2 V6.1 for Windows NT
- Source code control systems:
- MERANT PVCS Version Manager V5.3 and V6.0
- Microsoft Visual SourceSafe V6.0
- VisualAge TeamConnection
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 |