Client/Server Distributed Systems

240-322, Semester 1, 2005-2006

1. The Client Server Model

(Chapters 1 and 2, Berson)

 Objectives
– introduce the client/server model
– give an overview of DCE and Java RMI

240-322 Cli/Serv.: Models/1 1

 Overview
1. Client/Server Basics
2. Client/Server in More Detail
3. Client/Server Summary
4. Standards Organisations
5. DCE

240-322 Cli/Serv.: Models/1 2

 1. Client/Server Basics

 A first examination of client/server

functionality.

 A brief definition:
– A server is a program (or collection of
cooperating programs) that provides services
and/or manages resources on the behalf of other
programs (its clients).

240-322 Cli/Serv.: Models/1 3

 1.1. Client/Server Environment

clients

LAN
or WAN
network

Berson, Server Data

Fig 1.4, p.8
240-322 Cli/Serv.: Models/1 4
 1.2. Example

 The ATM network:

– the clients are the ATM machines
user interfaces;
some simple application processing

– the server is at the bank

most application processing;
very large database of customer accounts

240-322 Cli/Serv.: Models/1 5

 1.3. Architectural Requirements

 Reliable, robust communication between the clients

and server.
 Client/server cooperation
– started by the client
 Application processing is usually distributed
between a client and the server.
 Server controls services/data that the client accesses.
 Server handles conflicting requests.

240-322 Cli/Serv.: Models/1 6

 1.4. Recent Client/Servers Architectures

 More complex networking

– LAN, WAN --> Web, Internet
– client mobility

 More complex data structures

– relational --> multimedia, OO, deductive
– size
– distributed databases
– parallelism
240-322 Cli/Serv.: Models/1
continued 7
  Separation of ‘business logic’ (i.e. program
code for manipulating data) from the data
– 3-tier (multi-tier) architectures
– distributed business logic

240-322 Cli/Serv.: Models/1 8

 2. Client/Server in More Detail
2.1. Converting a Database App.
2.2. Component Placement?
2.3. The 2-tier Model
2.4. The 3-tier Model
2.5. Locating the Business Logic
2.6. Locating the Data
2.7. Multi-tier Model

240-322 Cli/Serv.: Models/1 9

 2.1. Converting a Database App.

Presentation Logic
Stand-alone Business Logic
Application Database Logic Data
DBMS base

240-322 Cli/Serv.: Models/1 10

  Different client/server models are obtained
by locating different components and
combinations of the application on the
client and server(s).

 In general:
– presentation logic stays on the client
– DBMS and database move to the server
– parts of the business and database logic that can be used
by several clients are placed on the server
240-322 Cli/Serv.: Models/1 11
 2.2. Component Placement?

 How much data is required by the local

application?
 How many application users require the
same data?
 How many interactions occur between the
application parts?
 Technical issues
– platforms, networking
240-322 Cli/Serv.: Models/1 12
 2.3. The 2-tier Model Fig. 2.3, p.41

Client
Server
Presentation Logic
Database Logic
Business Logic
DBMS
Database Logic

Data
base

240-322 Cli/Serv.: Models/1 13

 Points
 The database is on the server
– could some of it be moved to the client?
 Distributed database logic
– most of it is on the client
 The client does the presentation.
 ‘Fat’ versus ‘thin’ clients.
 Much simpler if all the database servers are
the same (homogenous).
240-322 Cli/Serv.: Models/1 14
 Drawbacks

 It is difficult to build heterogeneous database

environments.

 Transaction processing is limited by the DBMS.

 Asynchronous processing is difficult

– i.e. the client doesn’t wait for the server’s answer

 Scaleability?
240-322 Cli/Serv.: Models/1 15
 2.4. The 3-tier Model Fig. 1.6, p.12

UNIX

Clients ServerServer
Win/NT Data Data

Application servers Data Servers

240-322 Cli/Serv.: Models/1 16

 The 3-tier Model Again
Fig.2.6, p.48
Price/Performance Greater Integrity
Functionality Security
Local Autonomy Mainframe Central Control
host(s)
Tier 1

Server
Tier 2
LAN

Tier 3
240-322 Cli/Serv.: Models/1 17
 Points

 The “Mainframe host” is usually a very

large database (or databases)
– sometimes called a back-end server

 The “server” usually holds shared

applications (application/business logic)
– sometimes called the middle-tier server

240-322 Cli/Serv.: Models/1 18

 Benefits of 3-tier over 2-tier

 The application logic in the middle-tier is more

independent of the client and the back-end server
– it should be more robust

 The application logic in the middle-tier can work

more easily with data from multiple sources.

 Encourages multiple back-end servers

– encourages data distribution

240-322 Cli/Serv.: Models/1 19

 Problems

 Much more complex:

– network management, data integrity,
maintenance, development

 Still (partially) dependent on platforms

– e.g. the client may still be restricted to a certain
application server, but not (maybe) to any data
server

240-322 Cli/Serv.: Models/1 20

 Examples
 A ‘real’ ATM network
– the ATM machines are the clients (as before)

– the middle-tier servers provide certain processing

 checking balances, money transfer requests
 directing queries to the relevant back-end server

– back-end server(s)
 specialized by account type
 very robust concurrency control, transaction processing

240-322 Cli/Serv.: Models/1

continued 21
  Many Web applications are 3-tier:
– the Web browser is the client software

– the embedded components in Web pages (e.g.

Java applets) come from the middle-tier

– the back-end server contains the

database/groupware

240-322 Cli/Serv.: Models/1 22

 2.5. Locating the Business Logic
Fig.2.12, p.60

Server
Client
Business Logic
Presentation Logic
Database Logic
Business Logic
DBMS

Data
base
240-322 Cli/Serv.: Models/1 23
  Three ways of distributing the ‘business
logic’ (i.e. the program code):
– locate it entirely on the client (‘fat’ client)
– locate it entirely on the server (‘fat’ server)
– split it between the client and server

240-322 Cli/Serv.: Models/1 24

 Fat Server Advantages
 Easier to update the application logic since
clients not involved.

 Data is better hidden from clients.

 Easier to manage and debug since data and

code is centrally located.

 Reduces bandwidth problems since data

processing stays on the server.
240-322 Cli/Serv.: Models/1
continued 25
  Better for mission-critical applications
when
fault-tolerance and stability are important.

 Encourages client simplicity and

compatibility since the server must be able
to work with many types of client.
– e.g. serve Web pages without ActiveX

240-322 Cli/Serv.: Models/1 26

 Fat Client Advantages

 The server is unaffected when updates

are done to the client’s application logic
– the server will be more stable

 Easier to program
– less networking
– more direct access to client platform
features, such as GUI

240-322 Cli/Serv.: Models/1 27

 2.6. Locating the Data
Fig.2.14,p.69

Multiple Servers
Client
Database Logic
Presentation Logic
DBMS
Business Logic
Database Logic
DBMS Data
Data Data
base
base base
240-322 Cli/Serv.: Models/1 28
 Issues

 Dividing up the data.

 Transparency of the distribution.

 Data integrity / synchronisation /

consistency.

 Data administration / management.

240-322 Cli/Serv.: Models/1 29

 Transaction Processing

 A transaction is a sequence of actions which

takes a system (usually a database) from
one consistent state to another.
– e.g. change a customer’s record

 A transaction should possess the “ACID”

properties:
– Atomicity, Consistency, Isolation, Durability

240-322 Cli/Serv.: Models/1

continued 30
  Recovery and concurrency mechanisms are
necessary, typically implemented in a
Transaction Processing Management (TPM)
system.

 TPMs become very complex when data is

distributed.
– ACID must be distributed as well

240-322 Cli/Serv.: Models/1 31

 2.7. Multi-tier Model Fig.2.9,p.53

Middleware

Physical Network
240-322 Cli/Serv.: Models/1 32
 Common New Features

 Asynchronous connectivity
– e.g. asynchronous RPCs

 Data distribution using replication

 Name/directory services for resource

location independence

 More complex data types

240-322 Cli/Serv.: Models/1
continued 33
  More complex analysis
– e.g. data mining, network characteristics

 Authentication services
– you must 'prove' who you are to the system

 Distributed file system(s)

 Time services

240-322 Cli/Serv.: Models/1 34

 Examples
 Domain-specific:
– ODBC, SQL, Oracle Glue

 Groupware middleware:
– Microsoft Exchange, Lotus Notes

 Object middleware:
– CORBA, DCOM (more on these in part 2)

240-322 Cli/Serv.: Models/1 35

 Mult-tier Web Applications

 The Web browser is the client software on the

first tier.

 Web page components come from the second

tier.

 The third tier is a database front-end for a series

of fourth tier heterogeneous databases
– the third tier database may have been constructed
with data mining techniques
240-322 Cli/Serv.: Models/1 36
 3. Client/Server Summary

3.1. Recurring Issues

3.2. Advantages of Client/Server

3.3. Disadvantages of Client/Server

240-322 Cli/Serv.: Models/1 37

 3.1. Recurring Issues

 LAN, WAN, Internet scaling

 Data distribution/replication
 Distributed processing
 System management/maintenance
 Choice of middleware
 Standards / open systems

240-322 Cli/Serv.: Models/1 38

 What’s an Open System?

 An open system:
– complies with industry standards for
programming, communication, networking,
presentation, etc.

– is designed with portability/interoperability in

mind

– is scaleable
240-322 Cli/Serv.: Models/1 39
 3.2. Advantages of Client/Server

 Mainframe functionality can be made widely

available
– cost benefits

 Processing and data are localised on the server

– reduces network traffic, response time,
bandwidth requirements

 Business logic can be distributed (in 3-tier model)

– reuse, portability
240-322 Cli/Serv.: Models/1 continued 40
  Encourages open systems

 Present-day systems are too large and

involve too many users to be located on one
machine.

240-322 Cli/Serv.: Models/1 41

 3.3. Disadvantages of Client/Server

 The server becomes a bottleneck

 Distributed applications are much more complex

than non-distributed ones
– i.e. in development, run time, maintenance, upgrades

 Requires a shift in business practises

– local, simple data --> distributed, open, complex data

240-322 Cli/Serv.: Models/1 42

 4. Standards Organizations

 POSIX: Portable Operating Systems

Interface
– family of standards developed by IEEE

– POSIX working groups have standardised C,

UNIX shell, networking API for sockets, real-
time, threads, etc.

240-322 Cli/Serv.: Models/1 continued 43

  The Open Group
– consolidation of X/Open company and Open
Software Foundation (OSF)

– consortium of vendors and

industrial/government users

– developed API for UNIX, including XTI

(X/Open Transport Interface) network protocol

240-322 Cli/Serv.: Models/1 continued 44

  Internet Engineering Task Force (IETF)
– community of network designers, operators,
vendors, and researchers
– concerned with the evolution of the Internet
architecture
– e.g. sockets API for IP version 6 (IPv6)
 128-bit addresses, simpler header, multicasting,
authentication and security

240-322 Cli/Serv.: Models/1 continued 45

  ISO (International Organization for
Standards)
– main standards organization
– e.g. communications protocol: the Open
Systems Interconnection (OSI) reference model

 OMG (Object Management Group)

– object-oriented standards
– e.g. CORBA
240-322 Cli/Serv.: Models/1 46
 5. DCE
 The Distributed Computing Environment
– developed by the OSF (late 1980’s)
– open
– very extensive features (and complex)

 Basic programming feature is the Remote

Procedure Call (RPC)
– other features: name/directory services,
authentication, security, data pipes
240-322 Cli/Serv.: Models/1 47
 DCE RPC

Client Server
Application Application Remote
RPC
code code Procedure
Stub Code Stub Code

RPC runtime RPC runtime

library library
Input Output

Network
240-322 Cli/Serv.: Models/1 48
 Using RPC

 The data structures to be passed as arguments of

the RPC call are used by a compiler to generate
the client and server stub code.

 The data structures are written in a special high-

level language (simplified C types), which are
easily converted to network packets.

240-322 Cli/Serv.: Models/1 49

 DCE Client/Server Model (v.2)
Fig 1.10, p.27
Client Server
Distributed Distributed
DCE Application DCE Application
Executive Services Data Sharing
OS and Network OS and Network
Interface Interface

Network
240-322 Cli/Serv.: Models/1 50
 DCE Architecture Fig. 1.9, p.23
Applications
PC Integration Dist. Services

Security DFS: Dist. File Services Mgmt

Naming Time Future Core
Services Services Services

RPCs
Presentation Services
Threads Services
OS
240-322 Cli/Serv.: Models/1 Network Services 51
 5.1. Distributed File System (DFS)

 Problem: how to allow a user on one system

to modify data stored on a file in another
system?
– User = client
– Distant data is managed by a file server

240-322 Cli/Serv.: Models/1 52

 Issues

 Access security and protection

– user authentication (Kerberos) + user control
 Data reliability
 Data availability
 Performance
 Management

240-322 Cli/Serv.: Models/1 53

 5.3. More Details
 There are several books from O’Reilly on different
aspects of DCE:
– "Understanding DCE"
– "Guide to Writing DCE Applications"
– "Distributed Applications Across DCE
and Windows NT"
– "Introduction to OSF DCE" (in PSU library)

 We will look at simple RPC on UNIX later in the

course.
240-322 Cli/Serv.: Models/1 54