unit 05: physical architecture design
DESCRIPTION
TRANSCRIPT
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
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
“
”
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
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
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
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
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
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
9dsbw 2011/2012 q1
Architecture Pattern: Single Server
Client
(browser)
rooter/
firewall
HTTP HTTP· Web server
· Script engine
· DBMS
Host
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)
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)
12dsbw 2011/2012 q1
Architecture Pattern: Separate Database
Host 2
DBMSWeb server + Script engine
Host 1
firewallClient
(browser)
rooter/
firewall
HTTPHTTP
Demilitarized Zone (DMZ)
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
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
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
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
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
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
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
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
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
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)
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)
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
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
26dsbw 2011/2012 q1
Cloud Computing – Service Models
Source: http://www.collab-ogce.org/gce08/images/7/76/LamiaYouseff.pdf
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.
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
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
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
31dsbw 2011/2012 q1
Ad hoc J2EE Architecture without EJB
Web Container
Servlets / Web Classes
Implementation
Business Interface
DBMSLegacy System
J2EE
Server
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
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.
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