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

web cloud architecture
SMART_READER_LITE
LIVE PREVIEW

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


slide-1
SLIDE 1

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.
slide-2
SLIDE 2

Topics

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

2

slide-3
SLIDE 3

History of Web Application Architecture

3

slide-4
SLIDE 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

slide-5
SLIDE 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

slide-6
SLIDE 6

Web Templating Engine

6

slide-7
SLIDE 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

slide-8
SLIDE 8

AJAX

8

  • Asynchronous JavaScript

And XML

  • 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

slide-9
SLIDE 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

slide-10
SLIDE 10

Process Allocation for Web Templating Engine Framework

10

slide-11
SLIDE 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

  • peration

– Every Data Interchange operation results in a Presentation Flow operation

  • Presentation flow and data interchange are
  • rthogonal concerns that should be decoupled

– Separate concerns

11

slide-12
SLIDE 12

Typical Model 2 Architecture

  • Web templating engines +
  • MVC frameworks +
  • a sprinkling of Ajax

12

slide-13
SLIDE 13

SOA (Service Oriented Architecture), micro-services, and Cloud Computing

13

SaaS – software as a service PaaS – platform as a service IaaS – infrastructure as a service

slide-14
SLIDE 14

SOA

Service-oriented architecture (SOA)

  • Architectural design pattern based on distinct pieces of

software providing application functionality as services to

  • ther applications via a protocol.
  • Known as service-orientation.

14

slide-15
SLIDE 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

slide-16
SLIDE 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

slide-17
SLIDE 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
  • r hybrid.

17

http://jayurbain.com/msoe/cs4230/slides/Cloud%20Briefing/cloud_briefing_x2.pdf

slide-18
SLIDE 18

Service Oriented Front End Architecture (SOFEA)

  • Service Oriented Front End Architecture – 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:

18

http://jayurbain.com/msoe/se2840/slides/RESTfulWebServices.pdf

slide-19
SLIDE 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

slide-20
SLIDE 20

Legacy Enterprise Architecture

20

slide-21
SLIDE 21

SOFEA

21

slide-22
SLIDE 22

SOFEA – Process Allocation

22

slide-23
SLIDE 23

Web Processes for SOFEA

23

slide-24
SLIDE 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

slide-25
SLIDE 25

SOFEA Lifecycle

25

slide-26
SLIDE 26

MVC in the Web Browser

26

slide-27
SLIDE 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

  • f 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

slide-28
SLIDE 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

slide-29
SLIDE 29

SOFEA Client Implementation Archetype

29

slide-30
SLIDE 30

Angular

30

slide-31
SLIDE 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

slide-32
SLIDE 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

slide-33
SLIDE 33

Javascript MVC

Angular:

  • Innovative component-based approach for extending HTML
  • Very popular, backed by Google
  • Good for quick prototyping + production.
  • 2-way binding

Ember:

  • MVC structure makes sense for developers who have an MVC

programming background in Ruby, Python, Java, C# or other OOL.

  • High performance, excels at saving you from writing boilerplate by favoring

convention over configuration. Backbone

  • Embraces minimalism.
  • Small, fast and easy to learn, and provides the minimum (less) than you

need to get going. React/Flux

  • React (View) virtual DOM, Flux (M+C)

https://www.airpair.com/js/javascript-framework-comparison

33

slide-34
SLIDE 34

Advanced Tech

  • WebSockets

– Full duplex protocol sitting on top of TCP/IP in place of HTTP over port 80. – Makes it possible to open an interactive communication session between the user's browser and a server. – With this API, you can send messages to a server and receive event- driven responses without having to poll the server for a reply.

  • Web workers

– JavaScript script executed from an HTML page that runs in the background, independently of other user-interface scripts that may also have been executed from the same HTML page. – Web workers are often able to utilize multi-core CPUs more effectively.

  • Making fast web sits according to Google

– https://developers.google.com/speed/spdy/

34