Client Server Lecture

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…