web cloud architecture
play

Web Cloud Architecture Software Architecture Jay Urbain, Ph.D. - PowerPoint PPT Presentation

Web Cloud Architecture Software Architecture Jay Urbain, Ph.D. urbain@msoe.edu Credits: Ganesh Prasad, Rajat Taneja, Vikrant Todankar, How to Build Application Front-ends in a Service-Oriented World Darrly Nelson, Next Gen Web


  1. Web Cloud Architecture Software Architecture Jay Urbain, Ph.D. urbain@msoe.edu Credits: • Ganesh Prasad, Rajat Taneja, Vikrant Todankar, How to Build Application Front-ends in a Service-Oriented World • Darrly Nelson, Next Gen Web Architecture for the Cloud Era, 2013. • http://jayurbain.com/msoe/se2840/slides/RESTfulWebServices.pdf • http://jayurbain.com/msoe/cs4230/slides/Cloud%20Briefing/cloud_briefing_x2.pdf • http://martinfowler.com/eaaCatalog/ • Fowler, Martin. Patterns of Enterprise Architecture. Addison-Wesley Professional, 2003. • Fowler, Catalog of Enterprise Architecture Patterns. Updated 2013. 1/2015. 1

  2. Topics • Existing Web Application Architecture • Next generation Web Application Architectures - SOFEA • Lessons learned • Advanced tech 2

  3. History of Web Application Architecture 3

  4. Early Web Technology • HTML or HyperText Markup Language – Standard markup language used to create Web pages. • CGI – Common Gateway Interfaces – Scripts, commonly Perl, using common interface between the Web server and programs that generate Web content. • Servlet – Java programming for extending capabilities of web server. – Well defined API through run-time environment. – Typically used for dynamic web content generation. 4

  5. Web Templating Engine • Embedded code within static HTML elements • Mix of static and dynamic HTML – "Model 1" Architecture • Examples – Java Server Pages (JSP) – PHP – Active Server Pages (ASP) /.Net 5

  6. Web Templating Engine 6

  7. MVC Frameworks • Model View Controller pattern – Server side framework – “Model 2” Architecture • Examples – ASP.NET MVC Framework (.Net) – Struts, Spring MVC (Java) – Ruby on Rails (Ruby) – Django (Python) – Grails (Groovy) 7

  8. AJAX • A synchronous J avaScript A nd X ML • Dynamic content changes without reloading the entire page – interactive and dynamic web apps approaching rich client capability • HTML/CSS + DOM + XmlHttpRequest Object + JavaScript + JSON/XML 8

  9. Process of Web Applications 1. Application Download – Mobile code (JavaScript, HTML, Applets, Flash) download to the client (web browser) 2. Presentation Flow – Dynamic visual rendering of the UI (screen changes, new screens, etc.) in response to user input and data state changes 3. Data Interchange – The exchange of data between two software components or tiers (search, updates, retrieval, etc.) 9

  10. Process Allocation for Web Templating Engine Framework 10

  11. Characteristics of Web Templating Engines and MVC Frameworks • Tight coupling between presentation flow and data interchange (both in the web server) – Triggering a Presentation Flow (web page update) in a web application initiates a Data Interchange operation – Every Data Interchange operation results in a Presentation Flow operation • Presentation flow and data interchange are orthogonal concerns that should be decoupled – Separate concerns 11

  12. Typical Model 2 Architecture • Web templating engines + • MVC frameworks + • a sprinkling of Ajax 12

  13. SOA (Service Oriented Architecture), micro-services, and Cloud Computing SaaS – software as a service PaaS – platform as a service 13 IaaS – infrastructure as a service

  14. SOA Service-oriented architecture (SOA) • Architectural design pattern based on distinct pieces of software providing application functionality as services to other applications via a protocol. • Known as service-orientation. 14

  15. SOA Design Concept SOA is based on the concept of a service. • Each service is designed to perform one or more activities by implementing one or more service operations. • As a result, each service is built as a discrete piece of code. • Facilitates reuse of code/functionality in different ways throughout the application by changing only the way an individual service interoperates with other services - versus - making code changes to the service itself. • Trend is towards “micro services” – find grained, highly specific services that have minimal coupling within an app, and that can be easily reused across applications. 15

  16. SOA Terms • Service Endpoints – An endpoint is the entry point for such a SOA implementation. • Service Battery – Collection of collaborating services. • Governance – Control over resources to be leveraged for Service Oriented Computing to deliver value to the business. – SOA solutions require a number of IT support processes as well as organizational processes that will also involve the business leaders. – SOA needs a solid foundation that is based on standards and includes policies, contracts, and service level agreements. 16

  17. Cloud Computing • Based on utility and consumption of computing resources. • Deploy groups of remote servers and software networked that allow data storage and online access to computer services or resources. • Relies on sharing of resources to achieve coherence and economies of scale, similar to a utility (like the electricity grid) over a network. • At the foundation of cloud computing is the broader concept of converged infrastructure and shared services. • VM – statistical multiplexing • Clouds can be classified as public, private or hybrid. 17 http://jayurbain.com/msoe/cs4230/slides/Cloud%20Briefing/cloud_briefing_x2.pdf

  18. Service Oriented Front End Architecture (SOFEA) • S ervice O riented F ront E nd A rchitecture – Synonymous with “Single Page” Web Applications • Life above the Service Tier – How to Build Application Front-ends in a Service-Oriented World • Ganesh Prasad, Rajat Taneja, Vikrant Todankar • ReST Architectural Style – Not an implementation • Prasad, et al. propose that the SOA revolution has left behind application front ends/UI’s • Designing web services API’s: http://jayurbain.com/msoe/se2840/slides/RESTfulWebServices.pdf 18

  19. SOFEA – Feasible, necessary Feasible: 1. Maturity of the SOA paradigm in theory and practice 2. Advancements in browser-based client technologies, especially JavaScript browser engines and AJAX toolkits 3. Frameworks like Angular, React, Ember, etc. Necessary: 1. SOA is the defacto delivery mechanism for cloud-based services (Cloud and SOA are complementary technologies) 2. Diversity of client platforms 3. Growing dominance of Mobile clients – “mobile first design” 19

  20. Legacy Enterprise Architecture 20

  21. SOFEA 21

  22. SOFEA – Process Allocation 22

  23. Web Processes for SOFEA 23

  24. SOFEA Principles 1. Application Download, Data Interchange, and Presentation Flow must be decoupled – No part of the client should be evoked, generated or templated from the server-side. 2. Presentation Flow is a client-side concern only 3. All communication with the application server should be using services (REST, SOAP, etc.) 4. The MVC design pattern belongs in the client, not the server 24

  25. SOFEA Lifecycle 25

  26. MVC in the Web Browser 26

  27. Benefits of SOFEA • Scalability – Server has less work to do; no more presentation generation, just provide services • Higher ROI for each LOC – Expanded opportunity space due to the inherent reusable nature of SOA • Better user response – Low latency == happy end users J – After the app download, no presentation is transported over the wire, only business data • Natural fit into SOA and Cloud environments 27

  28. Benefits of SOFEA • Organized programming model – Client developers concentrate on the UI – Server-side developers concentrate on Services • Offline applications – When the network crashes, decoupled client can dynamically switch out their model objects • Interoperability – Easier integration with lower overhead from multiple platforms – Clients don’t care if services are Java, C#, Python, Cobol or a heterogeneous mix – Front-end developers can focus on front-end technologies 28

  29. SOFEA Client Implementation Archetype 29

  30. Angular 30

  31. Lessons Learned • The web client is a “Priority 1” architecture tier, not an after thought – Object-Oriented Analysis and Design principles – Design Patterns – Continuous integration, performance testing, etc. – Critical to expend significant engineering time and energy on the client architecture • Use a mature client-side libraries and frameworks – Dojo, jQuery, Angular, React, Ember, etc • The RESTful model is natural fit for SOFEA systems • Architects & developers should “bake-in” asynchronicity between the server and client layers pipes 31

  32. Lessons Learned • Leverage newer technologies where appropriate – HTML-5 Web Workers & Websockets – Web workers, web sockets – Javascript libraries: jQuery, Dojo, d3.js, – Javascript MVC frameworks: Angular, Bakcbone.js, Ember.js, React • Mobile first, cross-browser compatibility testing early in the development cycle – Fight the “add IE support later” temptation • SOFEA excellent choice for bandwidth starved environments – Very low latency for those customer’s with average-good network 32

Recommend


More recommend