Download Systems Architecture: Client/Server Systems

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

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

Document related concepts

Microsoft SQL Server wikipedia , lookup

Transcript
Systems Architecture:
Client/Server Systems
Naim R. El-Far, PhD Candidate
TA for SEG3202 Software Design and Architecture with
N. El-Kadri (Summer 2005)
Tutorial 1 of 4 – 27/5/2005
About Me







2
Naim R. El-Far
PhD Candidate
DISCOVER Lab @ SITE
Email: [email protected]
Please always start your email subject line
with the course code (SEG3202)
Office: SITE 5-077 (DISCOVER Lab).
Office Hours: None scheduled. By
appointment only.
Naim R. El-Far
Friday 27/5/2005
About Today’s Material
Slides based on presentations by N. El-Kadri
of the University of Ottawa
(http://www.site.uottawa.ca/~nelkadri) and
Dr. D. Penny of the University of Toronto
(http://www.cs.toronto.edu/~penny).
Material also from the Carnegie Mellon
Software Engineering Institute web site
(http://www.sei.cmu.edu).
3
Naim R. El-Far
Friday 27/5/2005
Tutorial Outline
1.
2.
3.
A Re-introduction to Software Engineering
The Software Engineering Process: Architecture vs.
Design
Classification of Software Architectures
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
4
Monolithic
Client/Server
N-tiered
Introduction to Client/Server Architectures
Examples of Client/Server Architectures
Division of Work in Client/Server Architectures
Inter-Process Communications
Quantifying Communication Performance
A Quick Survey of Socket Programming in Java
A Quick Survey of SQL Programming in Java
Naim R. El-Far
Friday 27/5/2005
Introduction:
Software Engineering
In the context of engineering a sizable
software project:
 Plan your work, and work your plan.
 Modifications along the way are
inevitable, but the more work you put
in planning out the project up front,
the more likely the project would go
smoothly.
5
Naim R. El-Far
Friday 27/5/2005
Introduction:
Software Engineering (cont.)


This is what software engineers do!
More formally, IEEE defines software
engineering as:

“The application of a systematic, disciplined,
quantifiable approach to the development,
operation, and maintenance of software”.
To be systematic, disciplined, and able to
quantify our work, we need to …
classify, categorize, and divide into modules!

6
Naim R. El-Far
Friday 27/5/2005
Introduction:
Software Engineering Process

1.
2.
7
The Software Engineering process,
is twofold:
Make decisions regarding the
systems-level architecture.
Implement and perform
programming-level design.
Naim R. El-Far
Friday 27/5/2005
Introduction:
Software Engineering Process
(cont.)
vs
The concept of
The concept of
Architecture
1.
2.
3.
8
Design
Strategic
High-level decisions
about the system
structure and
components
System-scope
Naim R. El-Far
1.
2.
3.
Tactical
Programming-level
decisions about
how to implement
the architecture
Component(s)scope
Friday 27/5/2005
Introduction:
Software Engineering Process
(cont.)
Architecture and design in the development process:
9
Naim R. El-Far
Friday 27/5/2005
Introduction:
Software Architecture Definition

How do we formally define
Software Architecture?

10
(SEI) Structure or structures of
the system, which consists of
software components, the
externally visible properties of
those components, and the
relationships among them.
Naim R. El-Far
Friday 27/5/2005
Introduction:
Software Architecture Design

What do software architecture decisions involve?
Specifying at the highest level the construction of the system:
 Technology choices
• Platforms, language, database, middleware, etc
 System construction
• How can we best construct the system logically and
physically
• Hardware interfaces (if any)
 Division into programs
• E.g. a program for data entry, another for data analysis,
a Web-oriented interface, etc.
 Division of programs into major subsystems
• Reuse strategy (shared subsystems)
• Calls constraints
• Major strategies (e.g., for persistence, IPC, etc.)
11
Naim R. El-Far
Friday 27/5/2005
Introduction:
Software Architecture Classification

How do we classify different software architectures?
 Convention is to classify based on number of
conceptual/physical layers running the software
components.
 In other words, a tier-based system:
1. 1-tier software architectures: Aka Monolithic systems
(from the Greek mono-lithos, or single rock), e.g. word
processors, PowerPoint, and stand-alone applications.
2. 2-tier software architectures: Aka Client/Server systems,
e.g. Internet browsers, large database systems, etc.
3. N-tier software architectures: Systems that have 3 or
more layers as described above, e.g. complex business
and banking databases.
12
Naim R. El-Far
Friday 27/5/2005
Introduction:
Software Architecture Classification
(cont.)
Monolithic architecture example:
Payroll for a small business
Scenario:
 Small business with 1 location
 5 Employees
 Single computer (computer A) with local database
containing each employee’s hourly rate and number of
hours worked.
 John’s pay (calculated on A) = John’s hourly rate (stored
on A) x the number of hours John worked (stored on A)
 But what if the business grows and now has several
locations and tens of employees?
13
Naim R. El-Far
Friday 27/5/2005
Introduction:
Software Architecture Classification
(cont.)

14
Monolithic architecture
Naim R. El-Far
Friday 27/5/2005
Introduction:
Software Architecture Classification
(cont.)
Server/Client architecture example:
Payroll for a large business
Scenario:
 Large business with 6 locations and 80 employees.
 4 locations share a single employee database (stored on server A)
while the other 2 share another database (stored on another
geographically distant server B)
 Payroll report generated at business headquarters at a third
location on computer C.
 John’s Pay (calculated on C) = John’s hourly rate (stored on A) x
the number of hours John worked (stored on A)
 Computer C is a client computer that requests information from
server A. A “client” requests, and a “server” serves, hence
client/server architecture.
 But what if the business goes multinational and calculating payroll
becomes different from one employee to another?
15
Naim R. El-Far
Friday 27/5/2005
Introduction:
Software Architecture Classification
(cont.)

16
Client/Server architecture
Naim R. El-Far
Friday 27/5/2005
Introduction:
Software Architecture Classification
(cont.)
N-tier (N=3) architecture example:
Payroll for a large multinational business
Scenario:

Large business with 400 employees in 2 different countries: Canada and
France.

Full work week in Canada is 40 hours, but in France is 35 hours.

Overtime in Canada is calculated at 1.5 times the hourly rate, but in France it
is 1.3 times the hourly rate.

Different deductions in Canada than those in France.

More “business rules”.

To calculate payroll in a client/server architecture, we will need to modify the
rules at the client level for each client.

If we introduce a middle-tier to host all “business rules” then all client
requests can be standardized, and all database schemas can remain
independent (in that they are not affected by changes in the client or middleware software). The middle-tier will take care of everything else.
17
Naim R. El-Far
Friday 27/5/2005
Introduction:
Software Architecture Classification
(cont.)

18
3-tier architecture
Naim R. El-Far
Friday 27/5/2005
Introduction:
Software Architecture Classification
(cont.)
Today’s emphasis is on the
Client/Server Architecture
19
Naim R. El-Far
Friday 27/5/2005
Client/Server Architecture:
Introduction

How do we formally define the
client/server software architecture?

20
(SEI) The client/server software
architecture is a versatile, messagebased and modular infrastructure that
is intended to improve usability,
flexibility, interoperability, and
scalability.
Naim R. El-Far
Friday 27/5/2005
Client/Server Architecture:
Introduction

In general, any application where
multiple clients connect to a single
server.
client1
client2
client3
server
21
Naim R. El-Far
Friday 27/5/2005
Client/Server Architecture:
Introduction
Worth noting, client/server systems
were not the first response to the
inadequacy of monolithic systems.
Before, there was:
1. The Mainframe (dumb terminal/
smart mainframe) architecture, and
2. The File-Sharing (smart
desktop/dumb storage) architecture.
22
Naim R. El-Far
Friday 27/5/2005
Client/Server Architecture:
Examples

Relational Database Management System
(RDBMS)
 Most common client/server program is where the
server is a relational database server.
 Warning: some use the term client/server to refer to
this usage exclusively.
client1
client2
client3
RDBMS
23
Naim R. El-Far
Friday 27/5/2005
Client/Server Architecture:
Examples (cont.)

RDBMS Implementation
client1
client2
client3
RDBMS Server
disks
24
Naim R. El-Far
Friday 27/5/2005
Client/Server Architecture:
Division of Work
Mainframe architecture: dumb client
(terminal), overworked smart server
(mainframe).
 File-sharing architecture: smart but
irresponsible client (terminal), dumb
server (networked storage device).
 Client/Server architecture: smart
client, smart server.

25
Naim R. El-Far
Friday 27/5/2005
Client/Server Architecture:
Division of Work (cont.)
Client machine’s typical responsibilities:





26
Manage the user interface (typically a GUI)
Manage the interface with the operating
system (and by extension, system
resources)
Validate data before communicating with
server
Communicate with server (send/receive)
Some logic (depending on the application)
Naim R. El-Far
Friday 27/5/2005
Client/Server Architecture:
Division of Work (cont.)
Server’s typical responsibilities:
Listen for and receive requests from
clients
 Process the request enforcing all
relevant logic
 Respond to client

27
Naim R. El-Far
Friday 27/5/2005
Client/Server Architecture:
Inter Process
Communications
Q) How do the clients/servers and
clients/servers communicate (InterProcess Communication – IPC)?

Remember, client/server architectures
must respect the heterogeneity of their
components and the need for their
interoperability.
A1) How about memory sharing?
•
•
•
28
Makes no demands on heterogeneity and
interoperability
Very fast!
Not ideal for networks
Naim R. El-Far
Friday 27/5/2005
Client/Server Architecture:
Inter Process
Communications (cont.)
A2) How about message passing?
•
•
•
Preserves heterogeneity and interoperability (if
standardized)
Not as fast as shared memory but if
standardized correctly, fast enough
Ideal for networks
Common protocols for IPC in Client/Server
architectures:
1. Socket (Transmission Control Protocol - TCP,
User Datagram Protocol - UDP)
2. Remote Procedure Calls – RPC
3. Distributed Objects - DO
29
Naim R. El-Far
Friday 27/5/2005
Client/Server Architecture:
Quantifying Communication
Performance
Remember, Software Engineering is
““The application of a systematic,
disciplined, quantifiable approach to
the development, operation, and
maintenance of software”.
We’ve so far been systematic and
disciplined in our approach. We’ve
have nothing to quantify really, until
now.
30
Naim R. El-Far
Friday 27/5/2005
Client/Server Architecture:
Quantifying Communication
Performance (cont.)
How fast you get information
(communication speed) is two-fold
(disregarding monetary cost for the
moment):
1. How much information you can get
at a time (bandwidth), and
2. How long it will take to get more
information (latency).
31
Naim R. El-Far
Friday 27/5/2005
Client/Server Architecture:
Quantifying Communication
Performance (cont.)
Concorde:
100 passengers (low
bandwidth), 3 hour London
to New York flight time (low
latency).
Boeing 747:
500 passengers (high
bandwidth), 8 hour London
to New York flight time
(high latency)
32
Naim R. El-Far
Friday 27/5/2005
Client/Server Architecture:
Quantifying Communication
Performance (cont.)
Q) How do we formally define bandwidth (in
the context of quantifying communication
performance)?
A) The amount of data that can be transferred
through a digital connection in a given time
period (i.e., the connection's bit rate). In
such cases, bandwidth is usually measured
in bits or bytes per second.
33
Naim R. El-Far
Friday 27/5/2005
Client/Server Architecture:
Quantifying Communication
Performance (cont.)
List of common connection bandwidths:
Device
Bandwidth
56k Modem
53.3 kb/sec
128k ISDN
128 kb/sec
USB Full-Speed
12 Mb/sec
Bluetooth 2
3 Mb/sec
T1
1.54 Mb/sec
Ethernet
10 Mb/sec
Gigabit Ethernet
1 Gb/sec
34
Naim R. El-Far
Friday 27/5/2005
Client/Server Architecture:
Quantifying Communication
Performance (cont.)
How accurate are these bandwidth
numbers?
If we send a large file on a round-trip
through a connection medium, then
chances are, it’ll come back later than
the theoretic values in the table
predict.
35
Naim R. El-Far
Friday 27/5/2005
Client/Server Architecture:
Quantifying Communication
Performance (cont.)
Q) How do we formally define latency (in the
context of quantifying communication
performance)?
A) The time it takes for a given message to
make a “round-trip” to a given destination
in a network.
Throughput: the observed bit rate as opposed
to bandwidth, which is the theoretic bit
rate.
Throughput < Bandwidth because of
overhead.
36
Naim R. El-Far
Friday 27/5/2005
Client/Server Architecture:
Quantifying Communication
Performance (cont.)
Balancing Bandwidth and Latency:


37
What does you application need more? A
“Concorde” or a “747 Jumbo jet”?
Satellite communication (16 Mbits/sec for
Internet) but 1 – 2 sec latency: Bad for
online gaming, great for TV broadcast.
Naim R. El-Far
Friday 27/5/2005
Client/Server Architecture:
Quantifying Communication
Performance (cont.)
Given that typically local communication has bandwidth
several orders of magnitude greater than network
communication, and has latency several orders of
magnitude less than network communication:
1.
Limit network communication as much as possible
(i.e. do as few calls as possible remotely)
2.
Preference given to asynchronous protocols
3.
Larger transactions
4.
Communication should maximize data while
minimizing frequency of communication.
38
Naim R. El-Far
Friday 27/5/2005
Client/Server Architecture:
A Quick Survey of Socket
Programming in Java
Good introductory tutorial available at
http://www.javaworld.com/javaworld/jw
-12-1996/jw-12-sockets.html
 Again, a socket is an IPC channel
identified uniquely by a port number
and an IP address
 Programming paradigm: Traditional
stream open  read/write  close,
just like file I/O

39
Naim R. El-Far
Friday 27/5/2005
Client/Server Architecture:
A Quick Survey of Socket
Programming in Java (cont.)

1.
2.
40
Socket programming can use two
communication protocols:
UDP/IP: User Datagram Protocol over
Internet Protocol. Connectionless and
does not guarantee delivery.
TCP/IP: Transmission Control Protocol
over Internet Protocol. Establishes a
connection, then streams data
guaranteeing sequential delivery.
Naim R. El-Far
Friday 27/5/2005
Client/Server Architecture:
A Quick Survey of Socket
Programming in Java (cont.)
Client side: Opening a socket:
Socket MyClient;
try {
MyClient = new Socket("Machine name",
PortNumber);
}
catch (IOException e) {
System.out.println(e);
}
Port number should be greater than 1023. (20 for FTP data, 21
for FTP control, 53 for DNS, 80 for HTTP, 110 for POP3, 443
for HTTPS, 569 for MSN)
41
Naim R. El-Far
Friday 27/5/2005
Client/Server Architecture:
A Quick Survey of Socket
Programming in Java (cont.)
Server side: Opening a socket:
ServerSocket MyService;
try {
MyServerice = new ServerSocket(PortNumber);
}
catch (IOException e) {
System.out.println(e);
}
We also need a socket to listen to and accept requests from clients:
Socket clientSocket = null;
try {
serviceSocket = MyService.accept();
}
catch (IOException e) {
System.out.println(e);
}
42
Naim R. El-Far
Friday 27/5/2005
Client/Server Architecture:
A Quick Survey of Socket
Programming in Java (cont.)
Client side: Opening an input stream:
DataInputStream input;
try {
input = new DataInputStream
(MyClient.getInputStream());
}
catch (IOException e) {
System.out.println(e);
}
43
Naim R. El-Far
Friday 27/5/2005
Client/Server Architecture:
A Quick Survey of Socket
Programming in Java (cont.)
Server side: Opening an input stream:
DataInputStream input;
try {
input = new DataInputStream(
serviceSocket.getInputStream());
}
catch (IOException e) {
System.out.println(e);
}
44
Naim R. El-Far
Friday 27/5/2005
Client/Server Architecture:
A Quick Survey of Socket
Programming in Java (cont.)
Client side: Opening an output stream:
PrintStream output;
try {
output = new
PrintStream(MyClient.getOutputStream());
}
catch (IOException e) {
System.out.println(e);
}
45
Naim R. El-Far
Friday 27/5/2005
Client/Server Architecture:
A Quick Survey of Socket
Programming in Java (cont.)
Server side: Opening an output stream:
PrintStream output;
try {
output = new
PrintStream(serviceSocket.getOutputStream(
));
}
catch (IOException e) {
System.out.println(e);
}
46
Naim R. El-Far
Friday 27/5/2005
Client/Server Architecture:
A Quick Survey of Socket
Programming in Java (cont.)
Client side: Closing the sockets:
try {
output.close();
input.close();
MyClient.close();
}
catch (IOException e) {
System.out.println(e);
}
47
Naim R. El-Far
Friday 27/5/2005
Client/Server Architecture:
A Quick Survey of Socket
Programming in Java (cont.)
Server side: Closing the sockets:
try {
output.close();
input.close();
serviceSocket.close();
MyService.close();
}
catch (IOException e) {
System.out.println(e);
}
48
Naim R. El-Far
Friday 27/5/2005
Client/Server Architecture:
A Quick Survey of SQL
Programming in Java
SQL: Structured Query Language. A
standard language for querying and
modifying relational databases
Very intuitive (although database
relations can become a little
convoluted)
49
Naim R. El-Far
Friday 27/5/2005
Client/Server Architecture:
A Quick Survey of SQL
Programming in Java (cont.)
SELECT *
FROM employees
WHERE DeptID=3
INSERT INTO supplier
(supplier_id, supplier_name)
VALUES (24553, 'IBM')
DELETE FROM supplier
WHERE supplier_name = 'IBM';
50
Naim R. El-Far
Friday 27/5/2005
Client/Server Architecture:
A Quick Survey of SQL
Programming in Java (cont.)
Java programs running on client machines
need a way (an API or middleware) to
communicate with the SQL engine running
on the server machine
Enter JDBC: Java Database Connectivity.
JDBC is a Java API that enables Java
programs to execute SQL statements. This
allows Java programs to interact with any
SQL-compliant database.
Note: Open Database Connectivity (ODBC)
and its up and coming successors are the
non-Java alternative.
51
Naim R. El-Far
Friday 27/5/2005
Client/Server Architecture:
A Quick Survey of SQL
Programming in Java (cont.)
import java.sql.*;
public class Main {
private static final query =
“select itemname,quantity “ +
“from orderitems,items “ +
“where orderid=1 and orderitems.itemid=items.itemid”;
public static void main(String[] args) throws Exception {
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
Connection c =
DriverManager.getConnection("jdbc:odbc:grocery");
Statement s = c.createStatement();
if( s.execute(query) ) {
ResultSet r = s.getResultSet();
printResults(r);
}
}
52
}
private static void printResults(ResultSet r) throws Exception {
final int nC = printHeadings(r);
printRows(nC, r);
}
…
Naim R. El-Far
Friday 27/5/2005
Recap






53
Software engineering is simply applying engineering
concepts to the software lifecycle.
System-level architecture (1-tier, 2-tier, 3-tier,
platforms, languages, hardware, etc) and
programming-level design (OO, procedural, logical,
data structures, etc)
Client/Server architecture in-depth: physical and
logical layers, division of work, inter-process
communication
Communication metrics: speed, latency, bandwidth,
and throughput
Java socket programming in client/server architecture
Java interfacing with SQL-based RDBMS
Naim R. El-Far
Friday 27/5/2005