unit 05: physical architecture design

34
1 dsbw 2011/2012 q1 Introduction Dimensions to be considered Architecture Patterns: Single server Separate database Replicated Web servers Separated scripting engines Application servers Web Caching Cloud Computing J2EE architectures for WebApps Unit 5: Physical Architecture Design

Upload: dsbw-20112002-carles-farre-barcelona-tech

Post on 29-Nov-2014

1.135 views

Category:

Technology


0 download

DESCRIPTION

 

TRANSCRIPT

Page 1: Unit 05: Physical Architecture Design

1dsbw 2011/2012 q1

Introduction

Dimensions to be considered

Architecture Patterns:

Single server

Separate database

Replicated Web servers

Separated scripting engines

Application servers

Web Caching

Cloud Computing

J2EE architectures for WebApps

Unit 5: Physical Architecture Design

Page 2: Unit 05: Physical Architecture Design

2dsbw 2011/2012 q1

(physical) architecture design concentrates on the choice of

the hardware, network, and software components that make

up the system, to find the mix of these components that best

meets the application requirements, and at the same time

respects the technical and economic constraints of the

project.

Ceri et al., 2003

Physical Architecture Design: A Definition

Page 3: Unit 05: Physical Architecture Design

3dsbw 2011/2012 q1

Architecture: Logical vs. Physical

2(+)-Tiered Client/Server

Physical Architecture

3-Layered Logical Architecture

AppServer

WBWB

.gif.gif

.html.html

Server

(tier #2)

HTTP

WS

WapServer

WS

Scripting Eng.

DBMS

DBMSHOSTHOST

Client

(tier #1)

Server

(tier #3)......

File/Database Management System

......

Presentation Layer

Business Logic Layer

Data Mapping Layer

Page 4: Unit 05: Physical Architecture Design

4dsbw 2011/2012 q1

One fragment of the Web presentation layer is executed on the Web browser:

Download and rendering of HTML (XML, …) documents

Client-side scripting: JavaScript, VBScript

Execution of embedded components: Applets, ActiveX

The other fragment of the Web presentation layer is executed on the server side:

Retrieval and delivery of static documents/files

Execution of server scripts

Interaction with the Business Logic Layer

The other layers are executed on the server tier(s)

AJAX (RIA) applications may change this paradigm.

Logical-Physical Mapping:Distributed Presentation

Page 5: Unit 05: Physical Architecture Design

5dsbw 2011/2012 q1

Non-functional requirements that pursue the achievement of an adequate level of service

Physical, financial and organizational constraints that may affect decision-making

Alternative scenarios in architecture deployment

Dimensions of Architecture Design

Page 6: Unit 05: Physical Architecture Design

6dsbw 2011/2012 q1

Performance: The application must sustain the expected workload defined in terms of

the maximum number of concurrent users,

the number of page requests served per unit of time,

the maximum time for delivering a page to the client

Scalability: The architecture must be easily extensible

Availability: Faults should not affect significantly the service delivered to users

State maintenance: The state of the user interaction must be preserved, even when the application is distributed on multiple machines or failures occur

Security:

Data should be protected

Users should be identified and granted access only to the data and functions they are entitled to

Non-functional requirements that may affect

Architecture Design

Page 7: Unit 05: Physical Architecture Design

7dsbw 2011/2012 q1

Cost

Every configuration requires a different investment, in terms of processors, network infrastructure, interfaces, and software licenses

The application budget may limit the choice of hardware resources and software products

Complexity

Some configurations are simpler than others to set up and maintain

The unavailability or the cost of specialized technical skills may constrain the architecture design

Corporate standards and infrastructures

The WebApp may be deployed within a corporate IT infrastructure, which may constrain the selection of hardware resources and software products.

Constraints of Architecture Design

Page 8: Unit 05: Physical Architecture Design

8dsbw 2011/2012 q1

Internal

The application architecture is kept inside the enterprise and maintained by the internal IT department.

Housed

The application architecture is maintained by the internal IT department of the enterprise, but is physically installed at an external service provider.

Hosted

The application architecture is located at the premises of an external service provider, who also maintains it.

Scenarios of Architecture Deployment

Page 9: Unit 05: Physical Architecture Design

9dsbw 2011/2012 q1

Architecture Pattern: Single Server

Client

(browser)

rooter/

firewall

HTTP HTTP· Web server

· Script engine

· DBMS

Host

Page 10: Unit 05: Physical Architecture Design

10dsbw 2011/2012 q1

Performance

Depends on the configuration of the server: CPU speed, available memory, disk access latency, etc.

The DBMS is both memory and CPU-intensive

Scalability

Is bound by the hardware architecture of the selected server

Availability

Every software and hardware element is a single point of failure: if it breaks, the entire system hangs.

Can be improved by adding redundant hardware resources (multiple CPUs, mirrored disks) and by installing multiple processes running different instances of the Web server, script engine, and database …

Single Server Pattern: Evaluation (1/2)

Page 11: Unit 05: Physical Architecture Design

11dsbw 2011/2012 q1

State maintenance

No problems with none of the three possibilities to store user data: client, server or database

Security:

This the weakest aspect of is configuration: attackers breaking the firewall and the Web server can take control of the host and gain direct access to the database, violating data protection

Low cost, as far as massive parallelism is not required.

Low complexity

Single Server Pattern: Evaluation (2/2)

Page 12: Unit 05: Physical Architecture Design

12dsbw 2011/2012 q1

Architecture Pattern: Separate Database

Host 2

DBMSWeb server + Script engine

Host 1

firewallClient

(browser)

rooter/

firewall

HTTPHTTP

Demilitarized Zone (DMZ)

Page 13: Unit 05: Physical Architecture Design

13dsbw 2011/2012 q1

Better performance

One extra machine

Each tier can be tuned to the requirements of the installed software

More scalable

It is possible to act separately on each tier.

Normally, the first bottleneck is in the middle tier

Availability is not improved

Each component is still a single point of failure

Significantly improved security

The inner firewall may disallow HTTP requests at all and let only database requests pass, making it more difficult for attackers to reach the data tier.

Separate Database Pattern: Evaluation

Page 14: Unit 05: Physical Architecture Design

14dsbw 2011/2012 q1

Architecture Pattern: Replicated Web Server

Host 2

DBMS

firewallClient

(browser)

rooter/ firewall/

load balancer

HTTP

HTTP

Demilitarized Zone (DMZ)

WS + Script engine #1

WS + Script engine #2

HTTP

HTTPS

WS + Script engine #3

(secure)

HTTPS

Page 15: Unit 05: Physical Architecture Design

15dsbw 2011/2012 q1

Improved performance and scalability: Load balancing

Clustering: A cluster is a group of servers (aka nodes) that provide a unified view of the services that they individually offer

Improved availability: Fail-over: if a cluster node fails, its workload can be redistributed to

the other nodes of the same cluster

Session state maintenance on the replicated servers Session affinity (aka sticky sessions): The load balancer sends all the

incoming requests pertinent to a given session to the same server.

Session migration: Session state is shared by the servers in the cluster

Improved data transmission security One of the Web servers may be configured to handle the connections

that require cryptographic protection.

Replicated Web Server Pattern: Evaluation

Page 16: Unit 05: Physical Architecture Design

16dsbw 2011/2012 q1

Architecture Pattern: Separate Script Engine

Client

(browser)

rooter/ firewall/

load balancer

HTTP

HTTPS

Host 2

DBMS

firewall

WS #1 SE #1

WS #3

(secure)

SE #2

SE #3

WS #2

HTTP

HTTPS

HTTP

Page 17: Unit 05: Physical Architecture Design

17dsbw 2011/2012 q1

Improved performance, scalability and availability

Web server and the scripting engine can be replicated independently so that the number and configuration of the hosts can be optimized: a well-balanced configuration may require more machines for the scripting engines than for the Web servers.

The communication overhead introduced by the separation should be compensated by the performance increase.

Separate Script Engine Pattern : Evaluation

Page 18: Unit 05: Physical Architecture Design

18dsbw 2011/2012 q1

Architecture Pattern: Application Server

Client

(browser)

rooter/ firewall/

load balancer

HTTP

HTTPS

Host 2

DBMSfirewall

WS #1 SE #1

WS #3

(secure)

SE #2

SE #3

WS #2

HTTP

HTTPS

HTTP

Application

Server

Application

Server

Application

Server

Page 19: Unit 05: Physical Architecture Design

19dsbw 2011/2012 q1

An application server is a software platform, distinct from the Web server, dedicated to the efficient execution of business components for supporting the construction of dynamic pages.

Improved performance, scalability and availability:

Transparent component distribution, replication, and load balancing: The application server automatically manages the creation of processes, the replication of business objects and their allocation to the available processes, and the allotment of client requests to the increase and decrease of the actual workload.

Automatic failure recovery: The application server may detect hardware, software and network failures, and avert client requests addressed to a failed component and route them to available replicas of the same business object.

Resource pooling: The application server may handle pools of expensive resources, like database connections, and share these resource among multiple business objects in an optimized way

Application Server Pattern: Evaluation

Page 20: Unit 05: Physical Architecture Design

20dsbw 2011/2012 q1

Caching consists of temporarily storing resources in a fast access location, for later retrieval.

Benefits:

Reduction of the response time

Reduction of computation effort when the resource is dynamically build

Anything can be cached:

Static HTML pages and multimedia files.

Fragments of pages computed by scripting programs.

Intermediate data consumed by the scripting programs for producing page, e.g. XML files.

The result of database queries or other application commands

Web Caching

Page 21: Unit 05: Physical Architecture Design

21dsbw 2011/2012 q1

Web caching: Where to Cache (1/3)

Browser caching:

Every Web browser contains a cache of HTML pages and multimedia files used to speed up the rendition of pages that contain cached objects.

Proxy caching:

Proxy caches store a local copy of each resource requested by users, and avoid accessing the Internet for retrieving frequently asked pages

Page 22: Unit 05: Physical Architecture Design

22dsbw 2011/2012 q1

Server accelerators

A server accelerator is a “buffer” placed in front of a server cluster that intercepts requests, caches copies of the objects produced by the servers, and delivers them to the subsequent requests.

Page prefetching: Based on the last request, the server accelerator loads into cache those pages that are more probable of being requested next.

Web caching: Where to Cache (2/3)

Page 23: Unit 05: Physical Architecture Design

23dsbw 2011/2012 q1

Content delivery networks (CDNs)

CDNs are systems of computers networked together across the Internet that allow content providers to outsource their caching infrastructures

When a client requests a page to the origin server, this returns a page with rewritten links that point to the nodes of the CDN

The CDN serves requests selecting the optimal copy of the page by taking into account the geographical location of the user and the real-time traffic conditions.

Web caching: Where to Cache (3/3)

Page 24: Unit 05: Physical Architecture Design

24dsbw 2011/2012 q1

Is “a model for enabling convenient, on-demand network

access to a shared pool of configurable computing resources

(e.g., networks, servers, storage, applications, and services)

that can be rapidly provisioned and released with minimal

management effort or service provider interaction”

The NIST Definition of Cloud Computing

Cloud Computing – A Definition

Page 25: Unit 05: Physical Architecture Design

25dsbw 2011/2012 q1

On-demand self-service

A consumer can unilaterally provision computing capabilities as needed

Broad network access

Capabilities are available over the network and accessed through standard mechanisms.

Resource pooling

Physical and virtual resources are dynamically assigned and reassigned according to consumer demand.

Rapid elasticity

Capabilities can be rapidly and elastically provisioned.

Measured Service Resource usage is monitored, controlled, and reported providing

transparency for both the provider and consumer of the utilized service.

Cloud Computing – Essential Characteristics

Page 26: Unit 05: Physical Architecture Design

26dsbw 2011/2012 q1

Cloud Computing – Service Models

Source: http://www.collab-ogce.org/gce08/images/7/76/LamiaYouseff.pdf

Page 27: Unit 05: Physical Architecture Design

27dsbw 2011/2012 q1

Cloud Computing - Some Providers

Cloud Layer Examples of Commercial Cloud Systems

Cloud Application Layer

Google Apps and Salesforce Customer Relation Management (CRM) system

Cloud Software Environment

Google App Engine and Salesforce Apex System

Cloud Software Infrastructure

Computational Resources: Amazon's EC2. EnomalismElastic Cloud.

Storage: Amazon's S3. EMC Storage Managed Service.

Communication: Microsoft Connected Service Framework (CSF).

Software KernelGrid and Cluster Computing Systems like Globus and Condor.

Firmware / Hardware

IBM-Morgan Stanley's Computing Sublease, and IBM's Kittyhawk Project.

Page 28: Unit 05: Physical Architecture Design

28dsbw 2011/2012 q1

“Classic” J2EE architecture, using remote EJBs and entity beans

Local EJB architecture, using local EJBs

Ad hoc J2EE architecture without EJB

Lightweight container architecture

J2EE Architectures for Web Applications

Page 29: Unit 05: Physical Architecture Design

29dsbw 2011/2012 q1

“Classic” J2EE Architecture

Web Container

Servlets / Web Classes

Business Delegate

Business Interface

EJB Container

Session EJB

Entity EJB (optional)

DBMS Legacy System

RMI

J2EE

Server

J2EE

Server

(Same or

Separate

JVM

Page 30: Unit 05: Physical Architecture Design

30dsbw 2011/2012 q1

Local EJB architecture

Web Container

Servlets / Web Classes

Business Delegate

Business Interface

EJB Container

Session EJB

Entity EJB (optional)

DBMS Legacy System

J2EE

Server

(Single

JVM)

Local EJB Invocation

Page 31: Unit 05: Physical Architecture Design

31dsbw 2011/2012 q1

Ad hoc J2EE Architecture without EJB

Web Container

Servlets / Web Classes

Implementation

Business Interface

DBMSLegacy System

J2EE

Server

Page 32: Unit 05: Physical Architecture Design

32dsbw 2011/2012 q1

Lightweight Container Architecture

Web Container

O/R Mapping Layer

POJO

Implementation with declarative

services via AOP

Business Interface

RDBMS(Optional) Other

transactional resource

J2EE

ServerMVC Web Framework

Page 33: Unit 05: Physical Architecture Design

33dsbw 2011/2012 q1

J2EE Architectures: A Comparison

Architect. Simplicity Productivity Transaction

Capable

Horizontal

Scalability

Testability

Remote

EJBs

Complex to

implement and

use business

objects.

Poor,

because of

complexity of

distribution

and EJB

programming

model.

Yes Inherent support

for distributing

objects.

Poor. It's very

hard to test

EJBs outside a

container. In-

container

testing is slow

and complex.

Local EJBs Slightly less

complex to

access

Slightly better

than for

remote EJBs.

Yes Relies on web

container to

deliver clustering.

Poor. As for

remote EJBs.

No EJB, ad

hoc

Typically

simpler than

architectures

using EJB.

Productivity is

usually better

than with EJB

architectures.

No. Explicit

use of

specific APIs

is required.

Depends on

implementation

strategy.

Depends on

implementation

strategy.

Light-

weight

container

Good, as

business

objects are

POJOs.

High Yes, if using

AOP.

Relies on web

container to

deliver clustering.

Good. Easy to

test business

objects outside

an application

server.

Page 34: Unit 05: Physical Architecture Design

34dsbw 2011/2012 q1

S. Ceri et al. Designing Data-Intensive Web Applications. Capítol 10. Morgan Kaufmann, 2003.

JOHNSON, Rod and HOELLER Juergen. Expert One-on-One J2EE Development without EJB. Willey Publishing, 2004

Youseff, L.; Butrico, M.; Da Silva, D. Toward a Unified Ontology of Cloud Computing. Grid Computing Environments Workshop, 2008. GCE '08, pages 1-10. http://www.cs.ucsb.edu/~lyouseff/CCOntology/CloudOntology.pdf

National Insitute of Standards and Technology. Cloud Computing Definition, V.15. http://csrc.nist.gov/groups/SNS/cloud-computing/index.html

References