3-Tier Architecture: Chandrasekaran Rajagopalan

3-Tier Architecture
Chandrasekaran Rajagopalan
Cs6704
11/01/99
R ergence
File Sharing Architecture
Client/Server architecture
Two-Tier Architecture
Three-Tier Architecture
File Sharing Architecture
Server downloads files fro shared

location to Desktop environ ent
Job is run at the desktop environ ent
Works if

Shared usage is low

Data transferred is low

Contention is low
File-Server Architecture
Client/Server Architecture
Database server to replace File server
Query based approach
Reduced traffic, since required content is

only transferred
I proves ulti-user updating
RPC or SQL typically used

Ra ple of C/S Architecture
I proves scalability over File Sharing

Architecture
Consists of 3 co ponents

User syste interface

Processing Manage ent

Database Manage ent
Two Tier Architecture
Li itations

Perfor ance deteriorates if nu ber of users
is greater than 100

Restricted fleibility and choice of DBMS,
since data language used in server is
proprietary to each vendor

Li ited functionality in oving progra
functionality across servers
Three-Tier Architecture
To overco e the li itations of Two-Tier

Architecture
Middle tier between UI and DB
Ways of incorporating Middle-Tier

Transaction processing Monitors

Application Servers

Message Servers
3-Tier with a TP Monitor
Online access through

Ti e sharing or Transaction Processing
Client connects to TP instead of DB
Monitor accepts transaction, queues it and

takes responsibility until it is co pleted
Asynchrony is achieved
3-Tier with a TP Monitor
ey services provided by the onitor
ability to update ultiple different DBMS in a single

transaction
connectivity to a variety of data sources, including

flat files

non relational DBMS

ainfra e
ore scaleable than a 2-tier approach
ability to attach priorities to transactions
robust security
For large (e.g., 1,000 user) applications, a TP onitor is

one of the ost effective solutions.
3-Tier With a Messaging Server
A essage is a self-contained ele ent

(treated as objects)
Message knows what it is,where to go,

what to do (Intelligent)
Contains two parts

Message header

Address, id and priority

Body of the Message
Messaging Syste s
Designed for robustness
Independent fro underlying technologies

(wired or wireless protocols)
Use store& forward logic and provide

essage delivery after and around failures
Don¶t require persistent connection

between Client and Server
Rasier to ove to ORB-based 3TAs

Differences between onitor based and
essage based architectures
Transactions

Du b Vs Intelligent
Middle Tier

Less fleible Vs More fleible
Portability

Less portable Vs More portable (Reason: iddle
layer not abstract fro other layers)
3 Tier with an Application Server
Most of Application¶s business logic is

oved to Shared host server
PC is used only for presentation services
Approach is si ilar to X Architecture

Both ai at pulling the ain body of
application logic off the desktop and running
it on a shared host.
3 Tier with an Application Server
Advantages to Application Designer
Less software on client, hence less to worry

about security
Application is ore scalable
Less software aintenance cost
Rasier to design the application to be

DBMS-agnostic
Allows ³after the fact´ application

partitioning
3-Tier With an Object DBMS
Using ODBMS as Middle layer
ODBMS acts as ³hot Cache´
Retrieve, asse ble and Store persistent until

required

For Generalized for of storage in DBMS (server)
ay be inadequate for specific application

R.g: Voice or Video not supported by RDBMS
Distributed/Collaborative Rnterprise
Architectures
Based on ORB technology
Goes beyond CORBA by using shared,

reusable business odels(not just objects)
Applications built with ³plug &

play´co ponents
Perfor ance tuning can be ade, by

transferring processes
Distributed/Collaborative Rnterprise
Architectures
sa e interface can be used for building a

desktop, single location application or a
fully distributed application
application can be developed and tested

locally
technical issues like queuing, ti ing and

protocols aren't an issue for the application
developer
Future ?
References
http://news.dci.co /geos/
http://javaechange.co /dcb_white.ht l
http://www.sei.c u.edu/str/descriptions/

Distributed/Collaborative Rnterprise Architectures

Two Tier Software Architectures

Three Tier Software Architectures

Middleware

Client Server Software Architectures

3-Tier Architecture: Chandrasekaran Rajagopalan

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

3-Tier Architecture: Chandrasekaran Rajagopalan

Uploaded by

Copyright:

Available Formats

3-Tier Architecture

File Sharing Architecture

Server downloads files fro shared

Job is run at the desktop environ ent

Database server to replace File server

Query based approach

Reduced traffic, since required content is

I proves ulti-user updating

RPC or SQL typically used

Ra ple of C/S Architecture

I proves scalability over File Sharing

To overco e the li itations of Two-Tier

Middle tier between UI and DB

Ways of incorporating Middle-Tier

Online access through

Client connects to TP instead of DB

Monitor accepts transaction, queues it and

ability to update ultiple different DBMS in a single

connectivity to a variety of data sources, including

ore scaleable than a 2-tier approach

ability to attach priorities to transactions

For large (e.g., 1,000 user) applications, a TP onitor is

A essage is a self-contained ele ent

Message knows what it is,where to go,

Contains two parts

Designed for robustness

Independent fro underlying technologies

Use store& forward logic and provide

Don¶t require persistent connection

Rasier to ove to ORB-based 3TAs

Most of Application¶s business logic is

PC is used only for presentation services

Approach is si ilar to X Architecture

Less software on client, hence less to worry

Application is ore scalable

Less software aintenance cost

Rasier to design the application to be

Allows ³after the fact´ application

Using ODBMS as Middle layer

ODBMS acts as ³hot Cache´

Retrieve, asse ble and Store persistent until

Based on ORB technology

Goes beyond CORBA by using shared,

Applications built with ³plug &

Perfor ance tuning can be ade, by

sa e interface can be used for building a

application can be developed and tested

technical issues like queuing, ti ing and

You might also like