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

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Document related concepts

Database wikipedia, lookup

Concurrency control wikipedia, lookup

Clusterpoint wikipedia, lookup

Team Foundation Server wikipedia, lookup

Functional Database Model wikipedia, lookup

Open Database Connectivity wikipedia, lookup

Microsoft SQL Server wikipedia, lookup

Database model wikipedia, lookup

Transcript
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