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