Você está na página 1de 39

CPSC 410: Client/Server

Software Architecture
Trevor Young

September 25th, 2003

University of British Columbia


Software Practices Lab
Objectives
By the end of this lecture, you will be able to:
• Describe the basic features of a Client/Server architecture

• Describe Advantages and Disadvantages of two and three


tier client/server software architectures

• Understand the concerns involved in designing a


Client/Server Architecture

• Identify the resources available to you when designing a


Client/Server Architecture
Overview
• Summary from previous lecture
• Definitions and Context
• Evolution of Client Server Architectures
• Examples of C/S Implementations
• Comparing 2-Tier and 3-Tier
Architectures
• Considerations in C/S Applications
• Case Study
3
Context
• Talked about software architecture in
the abstract last class
• As an example of “an architecture”, we’ll
look at client/server software
architecture

• Client/Server encompasses many


different applications
• Generally accepted as the preferred
architecture for application design
4
Definitions
• “Client/Server software architecture is a
versatile, message-based and modular
infrastructure that is intended to improve
usability, flexibility, interoperability, and
scalability as compared to centralized,
mainframe, time sharing computing”

• Client: A Requestor of Services

• Server: A Provider of Services


– Communication (talk to each other in same
language)
– Hardware (Physical separation) is not relevant
– Platform (Wintel, Unix…) is not relevant
5
Definitions
• Tier = Layer (Abstract Software Layer)

• Thin Client:
– Client application that relies on most of the function being available on
the server
• Fat (Rich) Client:
– Opposite of Thin Client; Client application is installed on the users
machine and contains most of the business functionality
• Middleware:
– Connectivity software that sits between the client and shared resources
on a server. Eg. TP Monitors, MOM, RPC, ORBs
• ORB – Object Request Broker (Message Broker)
• TP Monitor – Transaction Processing Monitor
• MOM – Message Oriented Middleware
• RPC – Remote Procedure Call

• RDBMS: Relational Database Management Server

• Lines are blurring between different middleware, databases etc.


6
Context
Motivation:

• To share resources among many users


– client interacts with end user
– server interacts with shared resource(s)

7
Evolution: Mainframe (~1970’s)
• ~ One tier Client/Server
• Host computer that users time-shared
through a terminal that passes
keystrokes
• “Big Iron” – huge machines, air
conditioning, filled entire room, cost
millions of dollars… (IBM, Unisys etc.)
• Buzzwords: Green screens, dumb
terminals, legacy systems

8
Evolution: Mainframe ctd.
• Still in use today (Banks etc.)

• (Very Reliable) Claim: Mainframes still house 90% of


the data major businesses rely on for mission-critical
applications

• What happened: applied a giant chainsaw to


monolithic (mainframe based) applications and
separated them into Client and Server components

• “New” definition: mainframe has


– Maximum reliable single-thread performance
– Maximum I/O connectivity
– Maximum I/O bandwidth

9
Evolution: File Sharing Arch

Sharing files across a


network
• PC requests file (records) from a file server
• Business logic all on client, shared resources on
server
• Works when shared usage, update contention, and
data volume are low
• Didn’t scale well
10
Evolution: 2-Tier Client/Server

• Databases replaced File Server


• Term Client/Server traditionally associated with
desktop PC connected over a network to a SQL-
database server
• Server’s database system (typically RDBMS) can
answer a user’s query (SQL)
• Lowered network usage because sending queries
and responses rather than files
11
Evolution: 2-Tier Client/Server

• Typically a GUI front-end


• Application or business logic either resides on the
client or on the database server in the form of stored
procedures
• Some examples: PowerBuilder, Visual Basic, Delphi
• More complex applications = fatter clients = more
expensive PC’s for each user
12
Evolution: 2-Tier Client/Server
• Tier 1: GUI + Business Logic, Tier 2: Database +
Shared Resources
• 2-Tier is simple
• Small departmental decision support
• Simple Web publishing applications
• C/S limitation – DB vendor lock-in (your GUI code is
directly tied to DB server
• 2-Tier doesn‘t scale
• E.g., With the Internet, servers can get requests
from any of the worlds millions of connected
browsers
• 2-Tier difficult to manage when deployed beyond
local environment Especially difficult to deploy and
manage fat clients
13
Evolution: 3-Tier Client/Server

• N-Tier
• Tier 1: GUI, Tier 2: Business Logic, Tier 3: Data
• Client Tier, Web Tier, App Server Tier, EIS (Data) Tier
• Adds a middle tier between the client (UI) and the server (DBMS)
• Application logic (or processes) becomes separated from the GUI
and the database E.g., TP Monitors, Application Servers
14
Evolution: 3-Tier Client/Server
• Changes in one tier should not affect changes in the
other (ie. Overhauling the GUI should not affect the
business logic in the middle tier)
• language independent ie. Client could be C++,
middleware could be Java etc.
• Can pool database connections
• Partition processing over many servers (load
balancing)
• Limitation of 3-tier is harder development procedures
(deployment etc.)
• 3 Layer view of an organization: User Interface layer,
Business Function layer, Data layer (Information
Model)
15
Next Evolution?

• Peer to Peer,
• Distributed Systems,
• Grid Computing
• …?

16
Client Server examples
• Most popular Client/Server application:
World Wide Web

17
Client Server examples
• Class Compass

18
Client Server examples

• E-Mail, Telnet, FTP


• H/R, Payroll, Accounting Systems, etc.
• Viruses
• Web Services

• Almost anything can be client/server

19
Web
Client Tier Business Logic Tier - App Server Enterprise Server

Tier Web Server


Application Server

MQ
Client MQ Series Base24
BankFrame Server
Connector MQ
Business
BankFrame Objects Series
HTTP Server
Comm.
Channel BMP Entity Base 24 - Tandem
Mgr. MQ EAB
Manager Beans
(1) RMI Commands
RMI
Servlet
(DataPacket) BankFrame RMI BankFrame
Business Transaction Trusted Enterprise Server
BankFrame UI HTTP Services Handler Interface
Component
Java Application HTTP Servlet IMS EAB
SSBs (2) SSB
Server Proxy Commands
JVM RMI BankFrame
Business MQ MQ-
Operating System - MS Series IMS
Win2000 Objects
Server Bridge
IMS TOC (Release 1B
CMP Entity Connector only) O
Beans IMS
T
Msg
M
Queue
A

Servlet Engine EJB Server Common Connector Framework XCF

IMS
Web Server - iPlanet JVM Connect
XCF
Application Server - WebLogic
Operating System -
Solaris
Operating System - Solaris
COINS/COLT - OS/390

Acronyms

BMP Bean Managed Persistence Database Server


CMP Container Managed Persistence
EAB Enterprise Access Builder Application Database
EJB Enterprise JavaBeans
HTTP
IMS TOC
Hypertext Transfer Protocol
IMS TCP/IP OTMA Connection
Data Tier
JVM Java Virtual Machine
OTMA
RMI
SSB
Open Transaction Manager Access (from IMS)
Remote Method Invocation (from Java)
Stateless Session Bean (EJB)
Relational Database Manager -
Oracle PS (Legacy EIS)
XCF Cross-system Coupling Facility (from MVS) Operating System - Solaris
Clients
CIBC CEnet

IPlanet IPlanet
E420 E420
4 CPU x 4 GB 4 CPU x 4 GB

W ebLogic/CCF W ebLogic/ W ebLogic/ W ebLogic/ W ebLogic/


Sun Blade 100 M Q/CCF MQ/CCF M Q/CCF M Q/CCF/
1 CPU x 512 M B SF3800 SF3800 SF3800 Oracle
4 CPU x 4 GB 4 CPU x 4 GB 4 CPU x 4 GB E450
4 CPU x 4 GB
(Training m achine)

Sun Cluster Admin OPS/ OPS/


Sun Blade 100 Sun Cluster Agent Sun Cluster Agent
1 CPU x 512 M B SF4800 SF4800
2 CPU x 4 GB 2 CPU x 4 GB

Data
21
Comparing 2- and 3-Tier
Comparing 2- and 3-Tier
2-Tier 3-Tier
System Complex Less Complex
Admin.
(more logic on the client to (the application can be centrally
manage) managed on the server –
application programs are made
visible to standard system
management tools)
Security Low High
(data-level security) (fine-tuned at the service, method,
or object type level)
Encapsulatio Low High
n of data
(data representation (client invokes services or
exported) methods)
Performanc Poor Good
e
(many SQL statements are (only service requests and
sent over the network; responses are sent between client
selected data must be and server)
downloaded for analysis on
the client) 23
Comparing 2- and 3-Tier
2-Tier 3-Tier
Scale Poor Excellent
(limited management of (concentrates incoming sessions;
client communication links) can distribute loads across multiple
servers)
Application Poor Excellent
reuse (monolothic application on (can reuse services and objects)
client)
Legacy No Yes
application
integration (limited management of (via gateways encapsulated by
client communication links) services or objects)
Ease of High Getting better
developme
nt (tools are emerging that can be
used to develop both the client and
the server side of the application)
Comparing 2- and 3-Tier
2-Tier 3-Tier
Internet Poor Excellent
support
(Internet bandwidth (very often, only web-browser is
limitations make it required as client side software)
harder to download
fat clients)
Hetero No Yes
databas
e (can use several databases within the
support same business transaction)
Architect Limited Excellent
ure
flexibility (you have a client (all tiers may reside on different
and a server) machines, or 2nd and 3rd tier on the
same machine, or the middle-tier
accross multiple servers)
Considerations: Where Should Functionality Go?

• Fat server model places more function on server


– E.g., Web
• Fat client model places more function on client
– E.g., Database and file server

26
Fat Servers vs. Fat Clients

• Fat client is more traditional


– Bulk of application run on client
– Clients know how data is organized and stored on
server
– Flexibility and opportunity to create front-ends
• Servers usually have more processing power,
memory, storage capacity etc.
• Fat server is easier to deploy and manage
– Minimize network exchanges
– Export procedures rather than raw data

27
Considerations
• Security
• Bandwidth (Network Traffic)
• Synchronization / Replication
• Synchronous / Asynchronous
• Fault Tolerance, Fail Over, Load Balancing
• Connected / Occasionally Connected
• Network reliability
• Transactional Integrity (ie. Bill Pay vs. Web
Page request)
28
Considerations
• Developer Experience
• Separation of Developer Roles
– Front End Developer, Server Side Developer,
Database Developer (DBA)
– Ie. Swing Developer + EJB or Servlet Developer +
Oracle DBA (Stored Procedures)
• End user or embedded
• Platform (In)dependency
• Proprietary Software ‘lock-in’ (Stored Procs
etc.)

29
Case Study
Scenario:

• Large Insurance company is developing a new


Employee Information Database and they want to
allow employees to update their own address and
personal information, and search on other employee
contact info
• Previous application was mainframe based, hard to
maintain. Employees would have to fill out paper
forms then submit them to HR who would key in the
changes.
• Hired UGrads-R-Us to consult them on the best way
to implement this new solution.

30
Case Study
Some Requirements Issues:
• Not all employees have the same
workstation:
– Windows 98, Windows 2000, Mac OS, Linux
• Not all employees are connected to the
company Intranet
– Some are on LAN, salesmen dial-in on the road,
some work from home (Therefore some will have
slow network access)
• The User Interface changes frequently
(Mergers and Acquisitions)
– Small IT Services team wants minimal
maintenance
31
Case Study
More Requirements Issues:
• Possible change in infrastructure next year
– DB license expires and they are investigating
other alternatives
• Must support 5000+ users
• Have to login securely (prevent false info)
• Needs future support for Transactional
Integrity
– Eventually want employees to access RRSP
and Benefits info
32
Case Study
Assumptions:

• Experienced Development Team


• Hardware is not an issue
• Users must be ‘connected’ to use the
application

33
Case Study
Problems:
• Mainframe, 2-Tier, 3-Tier?
• Thin client or fat client?
• Synchronous or Asynchronous?

• Where should functionality reside?


– Validation of input fields
– Complicated business logic (ie. check if
employee record already exists)

34
Case Study
• Possible Solution #1:

– Extend the mainframe


– ‘Screen Scrape’ the current system and
write a new GUI that connects to it

• Pros: Save money


• Cons: Doesn’t scale
• Others?
35
Case Study
• Possible Solution #2:
– 2-Tier Client/Server
– ‘Fat’ Client (ie. VB Windows Application)
– Socket connections to reliable Database
server
– Stored procedures in DB for complex
business logic

• Pros: Rich user interface, better scalability


• Cons: Difficult distribution/installation, Vendor
Lock-In, UI tied to DB
• Others?
36
Case Study
• Possible Solution #3

– 3-Tier Client/Server System (n-tier)


– Thin Client (ie. Browser Based, HTTP)
– Web Server
– RPC Middleware (EJB, CORBA, DCOM)
– Connection Pooling to Database

• Pros: Platform independent, scalable,


independent tiers
• Cons: Tricky to implement, Expensive
• Others?
37
Summary
Basics:
• Client requesting services from a Server that has
access to shared resources
• Thin client (little or no footprint) vs. Thick client
(installed code base)

3-Tier vs. 2-Tier:


• 3-Tier most popular architecture: scalable, flexible,
clear separation of application areas, network
efficient; expensive, difficult to implement
• 2-Tier more traditional: convenient for small user
base, easy to implement; not very scalable, db
vendor lock-in, not very flexible

38
Summary

Considerations/Concerns:
• Asynchronous/Synchronous, Fat/Thin client,
Connected/Occasionally Connected, Platform
Independence, Transactional Integrity, (Load
Balancing, Failover)

Resources:
• Application Servers (RPC, ORB), Message
Oriented Middleware (Queues), TP
Monitors…

39

Você também pode gostar