Transcript 1. The Client Server Model (Chapters 1 and 2, Berson)

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.
2.
3.
4.
5.
240-322 Cli/Serv.: Models/1
Client/Server Basics
Client/Server in More Detail
Client/Server Summary
Standards Organisations
DCE
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,
Fig 1.4, p.8
240-322 Cli/Serv.: Models/1
Server
Data
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.
2.2.
2.3.
2.4.
2.5.
2.6.
2.7.
240-322 Cli/Serv.: Models/1
Converting a Database App.
Component Placement?
The 2-tier Model
The 3-tier Model
Locating the Business Logic
Locating the Data
Multi-tier Model
9
2.1. Converting a Database App.
Presentation Logic
Stand-alone
Application
Business Logic
Database Logic
DBMS
240-322 Cli/Serv.: Models/1
Data
base
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
Client
Presentation Logic
Business Logic
Database Logic
Fig. 2.3, p.41
Server
Database Logic
DBMS
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
Win/NT
Application servers
240-322 Cli/Serv.: Models/1
ServerServer
Data Data
Data Servers
16
The 3-tier Model Again
Fig.2.6, p.48
Price/Performance
Functionality
Local Autonomy
Mainframe
host(s)
Server
Greater Integrity
Security
Central Control
Tier 1
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
continued
240-322 Cli/Serv.: Models/1
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
Client
Presentation Logic
Business Logic
Server
Business Logic
Database 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
base
240-322 Cli/Serv.: Models/1
Data
Data
base
base
28
Issues
 Dividing
up the data.
 Transparency
of the distribution.
 Data
integrity / synchronisation /
consistency.
 Data
240-322 Cli/Serv.: Models/1
administration / management.
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
240-322 Cli/Serv.: Models/1
complex data types
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, realtime, 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
Server
Client
Application
code
Application Remote
Procedure
code
RPC
Stub Code
Stub Code
RPC runtime
library
RPC runtime
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 highlevel 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
DCE Application
Executive
Distributed
DCE Application
Services Data Sharing
OS and Network
Interface
OS and Network
Interface
Network
240-322 Cli/Serv.: Models/1
50
DCE Architecture
Fig. 1.9, p.23
Applications
PC Integration
Security
Dist. Services
DFS: Dist. File Services
Naming
Services
Time
Services
Mgmt
Future Core
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