client server lecture
Post on 18-Nov-2014
122 Views
Preview:
TRANSCRIPT
University of British ColumbiaSoftware Practices Lab
CPSC 410: Client/Server Software Architecture
Trevor Young
September 25th, 2003
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
3
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
4
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
5
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
6
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.
7
Context
Motivation:
• To share resources among many users – client interacts with end user– server interacts with shared resource(s)
8
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
9
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
10
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
11
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
12
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
13
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
14
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 GUIand the database E.g., TP Monitors, Application Servers
15
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)
16
Next Evolution?
• Peer to Peer,
• Distributed Systems,
• Grid Computing
• …?
17
Client Server examples• Most popular Client/Server application:
World Wide Web
18
Client Server examples• Class Compass
19
Client Server examples
• E-Mail, Telnet, FTP• H/R, Payroll, Accounting Systems, etc.• Viruses• Web Services
• Almost anything can be client/server
Enterprise Server
COINS/COLT - OS/390
IMSMsg
Queue
OTMA
Database Server
Operating System - Solaris
Relational Database Manager -Oracle PS
Application Database
Enterprise Server
Base 24 - Tandem
MQSeriesServer
Base24
MQSeriesServer
XCF
XCF
IMSConnect
MQ-IMS
Bridge
Application Server
Operating System - Solaris
Application Server - WebLogic
MQSeriesServer
JVM
EJB Server
BankFrameTransaction
Handler
SSB
Common Connector Framework
IMS EABCommands
MQ EABCommandsRMI
TrustedInterface
Component
(Release 1Bonly)
BankFrameBusinessObjects
BMP EntityBeans
BankFrameBusinessServices
SSBs
BankFrameBusinessObjects
CMP EntityBeans
(1)RMI
(2)RMI
Web Server
Operating System -Solaris
Web Server - iPlanet
HTTPServer
ServletProxy
Client
Operating System - MSWin2000
JVM
Java Application
BankFrame UI
Comm.Mgr.
HTTP
Servlet Engine
BankFrameHTTP
ChannelManagerServlet
Acronyms
BMP Bean Managed PersistenceCMP Container Managed PersistenceEAB Enterprise Access BuilderEJB Enterprise JavaBeansHTTP Hypertext Transfer ProtocolIMS TOC IMS TCP/IP OTMA ConnectionJVM Java Virtual MachineOTMA Open Transaction Manager Access (from IMS)RMI Remote Method Invocation (from Java)SSB Stateless Session Bean (EJB)XCF Cross-system Coupling Facility (from MVS)
RMI(DataPacket)
MQConnector
IMS TOCConnector
Client Tier
Web Tier Business Logic Tier - App Server
Data Tier (Legacy EIS)
21Data
IPlanetE420
4 CPU x 4 GB
IPlanetE420
4 CPU x 4 GB
WebLogic/MQ/CCFSF3800
4 CPU x 4 GB
WebLogic/MQ/CCFSF3800
4 CPU x 4 GB
WebLogic/MQ/CCFSF3800
4 CPU x 4 GB
CIBC CEnet
OPS/Sun Cluster Agent
SF48002 CPU x 4 GB
OPS/Sun Cluster Agent
SF48002 CPU x 4 GB
Sun Cluster AdminSun Blade 100
1 CPU x 512 MB
WebLogic/MQ/CCF/
OracleE450
4 CPU x 4 GB(Training machine)
WebLogic/CCFSun Blade 100
1 CPU x 512 MB
Clients
Comparing 2- and 3-Tier
23
Comparing 2- and 3-Tier2-Tier 3-Tier
System Admin.
Complex(more logic on the client to manage)
Less Complex(the application can be centrally managed on the server –application programs are made visible to standard system management tools)
Security Low(data-level security)
High(fine-tuned at the service, method, or object type level)
Encapsulation of data
Low(data representation exported)
High(client invokes services or methods)
Performance
Poor(many SQL statements are sent over the network; selected data must be downloaded for analysis on the client)
Good(only service requests and responses are sent between client and server)
Comparing 2- and 3-Tier2-Tier 3-Tier
Scale Poor(limited management of client communication links)
Excellent(concentrates incoming sessions; can distribute loads across multiple servers)
Applicationreuse
Poor(monolothic application on client)
Excellent(can reuse services and objects)
Legacy application integration
No(limited management of client communication links)
Yes(via gateways encapsulated by services or objects)
Ease of development
High Getting better (tools are emerging that can be used to develop both the client and the server side of the application)
Comparing 2- and 3-Tier2-Tier 3-Tier
Internet support
Poor(Internet bandwidth limitations make it harder to download fat clients)
Excellent(very often, only web-browser is required as client side software)
Hetero database support
No Yes(can use several databases within the same business transaction)
Architecture flexibility
Limited(you have a client and a server)
Excellent(all tiers may reside on different machines, or 2nd and 3rd tier on the same machine, or the middle-tier accross multiple servers)
26
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
27
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
28
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)
29
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.)
30
Case StudyScenario:
• 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.
31
Case StudySome 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
32
Case StudyMore 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
33
Case StudyAssumptions:
• Experienced Development Team• Hardware is not an issue• Users must be ‘connected’ to use the
application
34
Case StudyProblems:• 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)
35
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?
36
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?
37
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?
38
SummaryBasics:• 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
39
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…
top related