ICT role in 21st century education and its challenges
Unit 05: Physical Architecture Design
1. Unit 5: Physical Architecture Design
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
dsbw 2011/2012 q1 1
2. Physical Architecture Design: A Definition
“
(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
dsbw 2011/2012 q1 2
3. Architecture: Logical vs. Physical
3-Layered Logical Architecture 2(+)-Tiered Client/Server
Physical Architecture
......
Client WB
WB
(tier #1)
HTTP .gif
Presentation Layer .html
WS
WS
Business Logic Layer Server
(tier #2)
Data Mapping Layer AppServer
Scripting Eng.
WapServer
DBMS
File/Database Management System
Server HOST
...... (tier #3)
DBMS
dsbw 2011/2012 q1 3
4. Logical-Physical Mapping:Distributed Presentation
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.
dsbw 2011/2012 q1 4
5. Dimensions of Architecture Design
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
dsbw 2011/2012 q1 5
6. Non-functional requirements that may affect
Architecture Design
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
dsbw 2011/2012 q1 6
7. Constraints of Architecture Design
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.
dsbw 2011/2012 q1 7
8. Scenarios of Architecture Deployment
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.
dsbw 2011/2012 q1 8
9. Architecture Pattern: Single Server
Host
· Web server
HTTP HTTP
· Script engine
rooter/
· DBMS
Client firewall
(browser)
dsbw 2011/2012 q1 9
10. Single Server Pattern: Evaluation (1/2)
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 …
dsbw 2011/2012 q1 10
11. Single Server Pattern: Evaluation (2/2)
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
dsbw 2011/2012 q1 11
12. Architecture Pattern: Separate Database
Host 1 Host 2
HTTP
HTTP
rooter/
Client firewall
firewall
(browser) Web server + Script engine DBMS
Demilitarized Zone (DMZ)
dsbw 2011/2012 q1 12
13. Separate Database Pattern: Evaluation
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.
dsbw 2011/2012 q1 13
15. Replicated Web Server Pattern: Evaluation
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.
dsbw 2011/2012 q1 15
16. Architecture Pattern: Separate Script Engine
WS #1 SE #1 Host 2
HTTP
HTTP
HTTP
HTTPS
rooter/ firewall/ WS #2 SE #2
Client firewall
load balancer
(browser) HTTPS DBMS
WS #3 SE #3
(secure)
dsbw 2011/2012 q1 16
17. Separate Script Engine Pattern : Evaluation
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.
dsbw 2011/2012 q1 17
18. Architecture Pattern: Application Server
Application
WS #1 SE #1 Server
HTTP Host 2
HTTP
HTTP
HTTPS Application
rooter/ firewall/ WS #2 SE #2 Server firewall
Client load balancer DBMS
(browser) HTTPS
Application
WS #3 SE #3 Server
(secure)
dsbw 2011/2012 q1 18
19. Application Server Pattern: Evaluation
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
dsbw 2011/2012 q1 19
20. Web Caching
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
dsbw 2011/2012 q1 20
21. Web caching: Where to Cache (1/3)
Browser caching: Proxy caching:
Every Web browser contains a cache of Proxy caches store a local copy of each
HTML pages and multimedia files used to resource requested by users, and avoid
speed up the rendition of pages that accessing the Internet for retrieving
contain cached objects. frequently asked pages
dsbw 2011/2012 q1 21
22. Web caching: Where to Cache (2/3)
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.
dsbw 2011/2012 q1 22
23. Web caching: Where to Cache (3/3)
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.
dsbw 2011/2012 q1 23
24. Cloud Computing – A Definition
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
dsbw 2011/2012 q1 24
25. Cloud Computing – Essential Characteristics
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.
dsbw 2011/2012 q1 25
27. Cloud Computing - Some Providers
Cloud Layer Examples of Commercial Cloud Systems
Cloud Application Google Apps and Salesforce Customer Relation
Layer Management (CRM) system
Cloud Software
Google App Engine and Salesforce Apex System
Environment
Computational Resources: Amazon's EC2. Enomalism
Elastic Cloud.
Cloud Software Storage: Amazon's S3. EMC Storage Managed
Infrastructure Service.
Communication: Microsoft Connected Service
Framework (CSF).
Grid and Cluster Computing Systems like Globus and
Software Kernel
Condor.
Firmware / IBM-Morgan Stanley's Computing Sublease, and
Hardware IBM's Kittyhawk Project.
dsbw 2011/2012 q1 27
28. J2EE Architectures for Web Applications
“Classic” J2EE architecture, using remote EJBs and entity
beans
Local EJB architecture, using local EJBs
Ad hoc J2EE architecture without EJB
Lightweight container architecture
dsbw 2011/2012 q1 28
29. “Classic” J2EE Architecture
Web Container
J2EE
Servlets / Web Classes
Server
Business Interface
Business Delegate
RMI
EJB Container J2EE
Server
Session EJB
(Same or
Separate
JVM
Entity EJB (optional)
DBMS Legacy System
dsbw 2011/2012 q1 29
30. Local EJB architecture
Web Container
J2EE
Servlets / Web Classes
Server
Business Interface
Business Delegate
Local EJB Invocation
EJB Container
(Single
Session EJB JVM)
Entity EJB (optional)
DBMS Legacy System
dsbw 2011/2012 q1 30
31. Ad hoc J2EE Architecture without EJB
Web Container
J2EE
Servlets / Web Classes
Server
Business Interface
Implementation
DBMS
Legacy System
dsbw 2011/2012 q1 31
32. Lightweight Container Architecture
MVC Web Framework
J2EE
Server
Web Container
Business Interface
POJO
Implementation
with declarative
services via AOP
O/R Mapping Layer
RDBMS
(Optional) Other
transactional resource
dsbw 2011/2012 q1 32
33. J2EE Architectures: A Comparison
Architect. Simplicity Productivity Transaction Horizontal Testability
Capable Scalability
Remote Complex to Poor, Yes Inherent support Poor. It's very
EJBs implement and because of for distributing hard to test
use business complexity of objects. EJBs outside a
objects. distribution container. In-
and EJB container
programming testing is slow
model. and complex.
Local EJBs Slightly less Slightly better Yes Relies on web Poor. As for
complex to than for container to remote EJBs.
access remote EJBs. deliver clustering.
No EJB, ad Typically Productivity is No. Explicit Depends on Depends on
hoc simpler than usually better use of implementation implementation
architectures than with EJB specific APIs strategy. strategy.
using EJB. architectures. is required.
Light- Good, as High Yes, if using Relies on web Good. Easy to
weight business AOP. container to test business
container objects are deliver clustering. objects outside
POJOs. an application
server.
dsbw 2011/2012 q1 33
34. References
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/CloudOntolo
gy.pdf
National Insitute of Standards and Technology. Cloud
Computing Definition, V.15.
http://csrc.nist.gov/groups/SNS/cloud-computing/index.html
dsbw 2011/2012 q1 34