Advanced Distributed Software Architectures and Technology group ADSaT 1 Application Architectures Ian Gorton, Paul Greenfield.

1Advanced Distributed Software Architectures and Technology group

ADSaT

Application Architectures

Ian Gorton, Paul Greenfield


ADSaT

Aim

• Cover some typical N-tier application architectures

• Look at their strengths and weaknesses

• Look at a sample complex application


ADSaT

N-Tier Applications

• Layered Architectures– Client layer taking care of user

interfaces – Some number of business logic

layers implementing business processes and rules

– Data layer for accessing data and implementing data integrity rules


ADSaT

N-tier Architectures

• Client layer– Static Web pages– Web-based through CGI programs– Active client-side Web pages

• Scripting and applets

– Active server-side Web pages– Traditional client applications– Background/batch processes


ADSaT

N-tier Architectures

• Business logic– Multiple layers possible

• Web scripts, server components

– Distribute and replicate as necessary– Re-use of logic a primary goal

• Data access– Components enforce data integrity– Isolate business logic from database– Can be partitioned and replicated


ADSaT

N-tier Example

Order component

Customer component

Payment component

Order component

Goods component

Stock component

Delivery component

MTS*

DCOM/COM*

Web server Scripted

Web pages

User interface

app

Print invoicesPrint ship requests

Background processes

* Or other transactional ORB of your choice

Business Logic Layer

Data Access Layer

Client Access Layer


ADSaT

Pooling

• Keep a shared pool of expensive or scarce resources– Database connections (ODBC, …)– Objects (COM+, EJB, …)

• Allocate from pool only when needed

• Release as soon as not needed• Makes stateless transactional

object designs really feasible


ADSaT

DB Connection Pooling

• Database connections are…– Expensive to allocate (performance)– Limited in number (scalability)

OLE DB ODBC OLE DB ODBCpooled pooled no pooling no pooling

VB 3.98 4.72 7.24 12.20J++ 4.83 4.83 7.27 12.37C++ 3.80 4.62 6.16 11.91


ADSaT

Object Pooling

• Client keeps reference to object • Allocate new object on every

method call– Stateless, transactional objects

• Discard objects at commit time• Objects recycled to reduce costs

– May only help with expensive objects


ADSaT

Object Pooling

0

200

400

600

800

1000

1200

1400

0 50 100 150threads

tps

128 Pooled ComponentsStateful (COM+)Stateless


ADSaT

Architectural Patterns

• Common models for building systems– Stateless or stateful?– Synchronous or asynchronous?– Data layer access

• Complexity and correctness– Recovery after failure– Scalability and parallelism– Simple, working and obviously

correct is a good goal


ADSaT

Stateful Session

Server object

Server object

Server object

Clients

Server objectFactory

New Client


ADSaT

Characteristics• One server object dedicated for

each client• Server object can hold client-

specific information (state) • New clients request a Factory

object to create them a server object. Can be distributed.

• Transactions can span multiple calls


ADSaT

Issues• How long do server objects live?

• Life of client?• Forever? reusable

• What happens if a server object/node dies unexpectedly?

• How do clients find a factory?• How does load balancing work if

load becomes uneven?


ADSaT

Stateless Session

Server object pool

Clients


ADSaT

Characteristics• Any client can use any server• Server object pool can be

distributed• Server objects maintain no state

on behalf of client, and pool DB connections

• Each client-server interaction is a single transaction


ADSaT

Design Issues

• How big is server object pool?• Static• Dynamic

• How do clients decide which server object to connect to?

• Finding servers?• Length of time they use a server

• Closely related to load balancing...


ADSaT

Stateful v Stateless

• Stateless scales better in practice– Stateful may be faster

• Stateless is easier to build• Stateful can be very useful in some

applications:– greatly benefit from data caching– load balancing is not too much of an

issue


ADSaT

Entity Pattern

Customer table

Customer Server object


Clients

CustomerServer object

Factory

1

2


ADSaT

Characteristics• Server objects represent specific

‘rows’ in the database• Client use a factory to create a

server object• Server objects have a get/set

style interface for each attribute of the database row


ADSaT

Issues

• How is concurrency control handled?

• 2 clients access same row at same time

• Scalability - many remote accesses to get/set individual attributes

• Plus all issues of stateful servers


ADSaT

State(ful/less) + Entity

Customer table



Server object

Server object


ADSaT

Characteristics

• Combines service-based patterns with entity pattern

• Clients access state(ful/less) server objects (see previous slides)

• Server objects create entity objects as needed

• Server objects isolated from DBMS - a good thing...


ADSaT

Issues

• All of the previous ones…• Need to rely on DBMS locking to

handle concurrency• Need to be careful with DBMS

deadlocks• Scales only if server object and

entity object in same process/node


ADSaT

Synchronous Messaging

Server object

Client

Request Queue

Reply Queue


ADSaT

Characteristics• Client writes a service request to a

queue in a transaction, and indicates where to write the results

• Server object removes request, performs service, and writes results to a reply queue (all in a transaction)

• Client removes results from reply queue in a transaction


ADSaT

Issues• Emulating synchronous behaviour

with asynchronous technology• Breaking 1 transaction up in to 3

• client has to remember state for recovery purposes

• How do we scale up to many clients?

• many request and reply queues• many server objects• many queues per server object


ADSaT

Asynchronous Messaging

QueueServer object

Client

Request Queue

State(ful/less)Server object


ADSaT

Characteristics

• Client makes synchronous call to server object

• Server object updates DBMS, places request on queue and returns results to client in a transaction

• Queue server object takes request from queue and updates DBMS in a transaction


ADSaT

Issues

• Used for delayed processing• when part of a synchronous transaction

is slow • write slow part to queue transactionally• no need to delay client, process request

some time later (but will get processed)

• Very commonly deployed architecture, one of the strengths of messaging


ADSaT

Example

Customercomponent

Paymentcomponent

Ordercomponent

Goodscomponent

Stockcomponent

Deliverycomponent

DCOM/COM

MTS

Databaseserver

Applicationserver

Warehousemanager

Printinvoices

Webserver

Webserver

Local clientworkstations

Internet/Intranet

Remote warehouses ScriptedWeb

pages

Central Office

Userclientapps

Remote sales offices

Router

Remote sites

HTTP

ORPC

ORPC/MQ

Userclientapps

CICSinterface

Externalcompany

accountingsystem


ADSaT

Web-based Clients

Paul Greenfield


ADSaT

The Web

• A single standard user interface technology– Web browsers

• A common client platform

– Using HTML to get to a Web server• A common protocol

• Except for ….– Many variations and standards to

choose from….


ADSaT

Static Web Pages

• Static HTML– Simple forms – No complex logic– Simple HTML is very portable

across browsers– Very limited as a tool for building

user interfaces• No way to include user logic • Presentation/forms only


ADSaT

CGI Scripts

• Running logic on the server– The traditional UNIX way– URL references a CGI program

rather than a web page– Web server runs a program or

script (C, Perl, …) when the page is requested

– Program/script runs and returns HTML

– Complex to write and scales poorly


ADSaT

ISAPI and NSAPI

• Call a library rather than starting a program– Microsoft and Netscape APIs– Much faster than CGI (no startup time)– Call returns HTML

• code has to write HTML strings

– Still hard to write and complex– Java servlets are a later equivalent


ADSaT

Client-side Scripting

• Add logic to the HTML– Logic in Jscript, VBscript, …– Script sees Web page as an object

• Manipulate the page being displayed• Change text, check values, hide fields,…

– Portability? • MS, Netscape; v3, v4, v5, …

– Useful for building dynamic, responsive Web-based user interfaces


ADSaT

Applets

• Downloadable code run inside the Web page– Java applets, ActiveX controls– Severe security restrictions?

• Java sandbox (no files, little networking, …)

• Code signing (ActiveX and Java)

– Relegated to niche usage• Graphics, expanding indexes, viewers


ADSaT

Server-side Scripting

• Scripted Web pages with the Web server running the script– Easier programming than CGI

• Script running within a Web page

– Script can call on business components• Fits in with n-tier model• Script does UI/presentation functions

– Can produce portable HTML– ASP (Microsoft) and JSP (SUN)


ADSaT

N-tier Clients

• Simple browsers on desktops– Good chance of portability– Simple HTML

• Server-side scripted Web pages– ASP or JSP– Calling on transactional

components for business processes (COM, EJB)


ADSaT

Next Week…

• CORBA

Advanced Distributed Software Architectures and Technology group ADSaT 1 Application Architectures Ian Gorton, Paul Greenfield.

Documents

technology group adsat

object pooling slide

feasible slide

replicated slide

object pooling client

number scalability slide

rules data layer

good goal slide