Unit 05: Physical Architecture Design


Published on

Published in: Technology
No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Unit 05: Physical Architecture Design

  1. 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 WebAppsdsbw 2011/2012 q1 1
  2. 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., 2003dsbw 2011/2012 q1 2
  3. 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) DBMSdsbw 2011/2012 q1 3
  4. 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. 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 deploymentdsbw 2011/2012 q1 5
  6. 6. Non-functional requirements that may affectArchitecture 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 todsbw 2011/2012 q1 6
  7. 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. 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. 9. Architecture Pattern: Single Server Host · Web server HTTP HTTP · Script engine rooter/ · DBMS Client firewall (browser)dsbw 2011/2012 q1 9
  10. 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. 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 complexitydsbw 2011/2012 q1 11
  12. 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. 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
  14. 14. Architecture Pattern: Replicated Web Server WS + Script engine #1 HTTP Host 2 HTTP HTTP HTTPS rooter/ firewall/ WS + Script engine #2 Client firewall load balancer HTTPS(browser) DBMS WS + Script engine #3 (secure) Demilitarized Zone (DMZ)dsbw 2011/2012 q1 14
  15. 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. 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. 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. 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. 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 waydsbw 2011/2012 q1 19
  20. 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 commandsdsbw 2011/2012 q1 20
  21. 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 eachHTML pages and multimedia files used to resource requested by users, and avoidspeed up the rendition of pages that accessing the Internet for retrievingcontain cached objects. frequently asked pagesdsbw 2011/2012 q1 21
  22. 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. 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. 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 Computingdsbw 2011/2012 q1 24
  25. 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
  26. 26. Cloud Computing – Service Models Source: http://www.collab-ogce.org/gce08/images/7/76/LamiaYouseff.pdfdsbw 2011/2012 q1 26
  27. 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: Amazons EC2. Enomalism Elastic Cloud. Cloud Software Storage: Amazons 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 Stanleys Computing Sublease, and Hardware IBMs Kittyhawk Project.dsbw 2011/2012 q1 27
  28. 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 architecturedsbw 2011/2012 q1 28
  29. 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 Systemdsbw 2011/2012 q1 29
  30. 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 Systemdsbw 2011/2012 q1 30
  31. 31. Ad hoc J2EE Architecture without EJB Web Container J2EE Servlets / Web Classes Server Business Interface Implementation DBMS Legacy Systemdsbw 2011/2012 q1 31
  32. 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 resourcedsbw 2011/2012 q1 32
  33. 33. J2EE Architectures: A Comparison Architect. Simplicity Productivity Transaction Horizontal Testability Capable ScalabilityRemote Complex to Poor, Yes Inherent support Poor. Its veryEJBs 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 onhoc 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 toweight business AOP. container to test businesscontainer objects are deliver clustering. objects outside POJOs. an application server.dsbw 2011/2012 q1 33
  34. 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.htmldsbw 2011/2012 q1 34
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.