Systems Architecture: Client/Server Systems - PowerPoint PPT Presentation

About This Presentation
Title:

Systems Architecture: Client/Server Systems

Description:

Systems Architecture: Client/Server Systems Naim R. El-Far, PhD Candidate TA for SEG3202 Software Design and Architecture with N. El-Kadri (Summer 2005) – PowerPoint PPT presentation

Number of Views:146
Avg rating:3.0/5.0
Slides: 54
Provided by: NaimR
Category:

less

Transcript and Presenter's Notes

Title: Systems Architecture: Client/Server Systems


1
Systems ArchitectureClient/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

2
About Me
  • Naim R. El-Far
  • PhD Candidate
  • DISCOVER Lab _at_ SITE
  • Email nelfar_at_site.uottawa.ca
  • 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.

3
About Todays 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).

4
Tutorial Outline
  • A Re-introduction to Software Engineering
  • The Software Engineering Process Architecture
    vs. Design
  • Classification of Software Architectures
  • 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

5
IntroductionSoftware 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.

6
IntroductionSoftware 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!

7
IntroductionSoftware Engineering Process
  • The Software Engineering process, is twofold
  • Make decisions regarding the systems-level
    architecture.
  • Implement and perform programming-level design.

8
IntroductionSoftware Engineering Process (cont.)
The concept of Architecture vs The concept of Design
Strategic High-level decisions about the system structure and components System-scope Tactical Programming-level decisions about how to implement the architecture Component(s)-scope
Strategic High-level decisions about the system structure and components System-scope Tactical Programming-level decisions about how to implement the architecture Component(s)-scope
Strategic High-level decisions about the system structure and components System-scope Tactical Programming-level decisions about how to implement the architecture Component(s)-scope
Strategic High-level decisions about the system structure and components System-scope Tactical Programming-level decisions about how to implement the architecture Component(s)-scope
9
IntroductionSoftware Engineering Process (cont.)
  • Architecture and design in the development
    process

10
IntroductionSoftware Architecture Definition
  • How do we formally define Software Architecture?
  • (SEI) Structure or structures of the system,
    which consists of software components, the
    externally visible properties of those
    components, and the relationships among them.

11
IntroductionSoftware 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.)

12
IntroductionSoftware 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-tier software architectures Aka Monolithic
    systems (from the Greek mono-lithos, or single
    rock), e.g. word processors, PowerPoint, and
    stand-alone applications.
  • 2-tier software architectures Aka Client/Server
    systems, e.g. Internet browsers, large database
    systems, etc.
  • N-tier software architectures Systems that have
    3 or more layers as described above, e.g. complex
    business and banking databases.

13
IntroductionSoftware 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 employees hourly rate and number
    of hours worked.
  • Johns pay (calculated on A) Johns 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?

14
IntroductionSoftware Architecture
Classification (cont.)
  • Monolithic architecture

15
IntroductionSoftware 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.
  • Johns Pay (calculated on C) Johns 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?

16
IntroductionSoftware Architecture
Classification (cont.)
  • Client/Server architecture

17
IntroductionSoftware Architecture
Classification (cont.)
  • N-tier (N3) 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 middle-ware software).
    The middle-tier will take care of everything
    else.

18
IntroductionSoftware Architecture
Classification (cont.)
  • 3-tier architecture

19
IntroductionSoftware Architecture
Classification (cont.)
  • Todays emphasis is on the
  • Client/Server Architecture

20
Client/Server ArchitectureIntroduction
  • How do we formally define the client/server
    software architecture?
  • (SEI) The client/server software architecture is
    a versatile, message-based and modular
    infrastructure that is intended to improve
    usability, flexibility, interoperability, and
    scalability.

21
Client/Server ArchitectureIntroduction
  • In general, any application where multiple
    clients connect to a single server.

22
Client/Server ArchitectureIntroduction
  • Worth noting, client/server systems were not the
    first response to the inadequacy of monolithic
    systems.
  • Before, there was
  • The Mainframe (dumb terminal/ smart mainframe)
    architecture, and
  • The File-Sharing (smart desktop/dumb storage)
    architecture.

23
Client/Server ArchitectureExamples
  • 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
24
Client/Server ArchitectureExamples (cont.)
  • RDBMS Implementation

client1
client2
client3
RDBMS Server
disks
25
Client/Server ArchitectureDivision 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.

26
Client/Server ArchitectureDivision of Work
(cont.)
  • Client machines typical responsibilities
  • 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)

27
Client/Server ArchitectureDivision of Work
(cont.)
  • Servers typical responsibilities
  • Listen for and receive requests from clients
  • Process the request enforcing all relevant logic
  • Respond to client

28
Client/Server ArchitectureInter Process
Communications
  • Q) How do the clients/servers and clients/servers
    communicate (Inter-Process Communication IPC)?
  • Remember, client/server architectures must
    respect the heterogeneity of their components and
    the need for their interoperability.
  • A1) How about memory sharing?
  • Makes no demands on heterogeneity and
    interoperability
  • Very fast!
  • Not ideal for networks

29
Client/Server ArchitectureInter 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
  • Socket (Transmission Control Protocol - TCP, User
    Datagram Protocol - UDP)
  • Remote Procedure Calls RPC
  • Distributed Objects - DO

30
Client/Server ArchitectureQuantifying
Communication Performance
  • Remember, Software Engineering is The
    application of a systematic, disciplined,
    quantifiable approach to the development,
    operation, and maintenance of software.
  • Weve so far been systematic and disciplined in
    our approach. Weve have nothing to quantify
    really, until now.

31
Client/Server ArchitectureQuantifying
Communication Performance (cont.)
  • How fast you get information (communication
    speed) is two-fold (disregarding monetary cost
    for the moment)
  • How much information you can get at a time
    (bandwidth), and
  • How long it will take to get more information
    (latency).

32
Client/Server ArchitectureQuantifying
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)

33
Client/Server ArchitectureQuantifying
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.

34
Client/Server ArchitectureQuantifying
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
35
Client/Server ArchitectureQuantifying
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, itll come
    back later than the theoretic values in the table
    predict.

36
Client/Server ArchitectureQuantifying
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 lt Bandwidth because of overhead.

37
Client/Server ArchitectureQuantifying
Communication Performance (cont.)
  • Balancing Bandwidth and Latency
  • 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.

38
Client/Server ArchitectureQuantifying
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
  • Limit network communication as much as possible
    (i.e. do as few calls as possible remotely)
  • Preference given to asynchronous protocols
  • Larger transactions
  • Communication should maximize data while
    minimizing frequency of communication.

39
Client/Server ArchitectureA Quick Survey of
Socket Programming in Java
  • Good introductory tutorial available at
    http//www.javaworld.com/javaworld/jw-12-1996/jw-1
    2-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

40
Client/Server ArchitectureA Quick Survey of
Socket Programming in Java (cont.)
  • 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.

41
Client/Server ArchitectureA 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)

42
Client/Server ArchitectureA 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)

43
Client/Server ArchitectureA Quick Survey of
Socket Programming in Java (cont.)
  • Client side Opening an input stream
  • DataInputStream input
  • try
  • input new DataInputStream (MyClient.getInputStr
    eam())
  • catch (IOException e)
  • System.out.println(e)

44
Client/Server ArchitectureA 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)

45
Client/Server ArchitectureA 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)

46
Client/Server ArchitectureA Quick Survey of
Socket Programming in Java (cont.)
  • Server side Opening an output stream
  • PrintStream output
  • try
  • output new PrintStream(serviceSocket.getOutputS
    tream())
  • catch (IOException e)
  • System.out.println(e)

47
Client/Server ArchitectureA 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)

48
Client/Server ArchitectureA Quick Survey of
Socket Programming in Java (cont.)
  • Server side Closing the sockets
  • try
  • output.close()input.close()serviceSocket.clos
    e()MyService.close()
  • catch (IOException e)
  • System.out.println(e)

49
Client/Server ArchitectureA 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)

50
Client/Server ArchitectureA Quick Survey of SQL
Programming in Java (cont.)
  • SELECT
  • FROM employees
  • WHERE DeptID3
  • INSERT INTO supplier
  • (supplier_id, supplier_name)
  • VALUES (24553, 'IBM')
  • DELETE FROM supplier
  • WHERE supplier_name 'IBM'

51
Client/Server ArchitectureA 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.

52
Client/Server ArchitectureA 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 orderid1 and orderitems.itemiditem
    s.itemid
  • public static void main(String args) throws
    Exception
  • Class.forName("sun.jdbc.odbc.JdbcOdbcDriver")
  • Connection c DriverManager.getConnection("jdbc
    odbcgrocery")
  • Statement s c.createStatement()
  • if( s.execute(query) )
  • ResultSet r s.getResultSet()
  • printResults(r)
  • private static void printResults(ResultSet
    r) throws Exception
  • final int nC printHeadings(r)

53
Recap
  • 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
Write a Comment
User Comments (0)
About PowerShow.com