Client/Server Distributed Systems

warmersafternoonΔίκτυα και Επικοινωνίες

23 Οκτ 2013 (πριν από 3 χρόνια και 5 μήνες)

55 εμφανίσεις

240
-
322 Cli/Serv.: Models/1

1

Client/Server Distributed Systems


Objectives


introduce the client/server model


give an overview of DCE and Java RMI

240
-
322, Semester 1, 2005
-
2006

1
. The Client Server Model

(Chapters 1 and 2, Berson)

240
-
322 Cli/Serv.: Models/1

2

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

3

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

4

1.1. Client/Server Environment

LAN

or WAN

Server

Data

Berson,

Fig 1.4, p.8

clients

network

240
-
322 Cli/Serv.: Models/1

5

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

6

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

7

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

continued

240
-
322 Cli/Serv.: Models/1

8


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

9

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

10

2.1. Converting a Database App.

Presentation Logic

Business Logic

Database Logic

DBMS

Data

base

Stand
-
alone

Application

240
-
322 Cli/Serv.: Models/1

11


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

12

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

13

2.3. The 2
-
tier Model

Fig. 2.3, p.41

Presentation Logic

Business Logic

Database Logic

DBMS

Data

base

Database Logic

Client

Server

240
-
322 Cli/Serv.: Models/1

14

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

15

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

16

2.4. The 3
-
tier Model

Fig. 1.6, p.12

Server

Data

Application servers

Data Servers

Server

Data

UNIX

Win/NT

Clients

240
-
322 Cli/Serv.: Models/1

17

The 3
-
tier Model Again


Fig.2.6, p.48

Server

Mainframe

host(s)

Tier 1

Tier 2

Tier 3

LAN

Price/Performance

Functionality

Local Autonomy

Greater Integrity

Security

Central Control

240
-
322 Cli/Serv.: Models/1

18

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

19

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

20

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

21

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

22


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

23

2.5. Locating the Business Logic


Fig.2.12, p.60

Presentation Logic

Business Logic

DBMS

Data

base

Database Logic

Client

Server

Business Logic

240
-
322 Cli/Serv.: Models/1

24


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

25

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.

continued

240
-
322 Cli/Serv.: Models/1

26


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

27

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

28

Data

base

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

Presentation Logic

Business Logic

DBMS

Data

base

Database Logic

Client

Multiple Servers

DBMS

Database Logic

Data

base

240
-
322 Cli/Serv.: Models/1

29

Issues


Dividing up the data.



Transparency of the distribution.



Data integrity / synchronisation /
consistency.



Data administration / management.

240
-
322 Cli/Serv.: Models/1

30

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:


A
tomicity,
C
onsistency,
I
solation,
D
urability

continued

240
-
322 Cli/Serv.: Models/1

31


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

32

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

Middleware

Physical Network

240
-
322 Cli/Serv.: Models/1

33

Common New Features


Asynchronous connectivity


e.g. asynchronous RPCs



Data distribution using replication



Name/directory services for resource
location independence



More complex data types

continued

240
-
322 Cli/Serv.: Models/1

34


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

35

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

36

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

37

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

38

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

39

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

40

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

continued

240
-
322 Cli/Serv.: Models/1

41


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

42

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

43

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.


continued

240
-
322 Cli/Serv.: Models/1

44


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

continued

240
-
322 Cli/Serv.: Models/1

45


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

continued

240
-
322 Cli/Serv.: Models/1

46


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

47

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

48

DCE RPC

Client

Application

code

RPC

Stub Code

RPC runtime

library

Server

Network

Input

Output

Application

code

Remote

Procedure

Stub Code

RPC runtime

library

240
-
322 Cli/Serv.: Models/1

49

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

50

DCE Client/Server Model (v.2)

Distributed

DCE Application

Executive

OS and Network

Interface

Distributed

DCE Application

Services

Data Sharing

OS and Network

Interface

Client

Server

Network

Fig 1.10, p.27

240
-
322 Cli/Serv.: Models/1

51

DCE Architecture

Applications

PC Integration

Dist. Services

Mgmt

Security

DFS: Dist. File Services

Naming

Services

Time

Services

Future Core

Services

RPCs

Presentation Services

Threads Services

OS

Network Services

Fig. 1.9, p.23

240
-
322 Cli/Serv.: Models/1

52

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

53

Issues


Access security and protection


user authentication (Kerberos) + user control


Data reliability


Data availability


Performance


Management

240
-
322 Cli/Serv.: Models/1

54

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.