9 - Architetture Software - SOA Cloud

Architectures for
software services
and cloud computing
Paolo Ciancarini

Agenda

  Rationale: the Service Economy
  Software as a Service (SaaS)
  Service oriented architectures
  The REST architectural style
  AJAX and mashups
  Cloud computing architectures

The Service Economy

  Modern economies rely upon services
  This means that several companies offer support for
activities in the primary (agricolture) or secondary
(industry of goods) sectors, or to other companies
offering services themselves
  A service company is usually independent (not
owned) from other companies and their services;
however in several cases they should cooperate or at
least be coordinated in some way

From Products to Services
  Our society is shaped by the forces of
  Specialization
  Standardization
  Scalability
  It is now mostly “service” oriented
  Transportation
  Telecommunication
  Retail
  Healthcare
  Financial services
  Education and training
  …

Attributes of physical services
  A service is not owned by its user (compare with product)
  Well defined, easy-to-use, standardized interface
  New services can be offered by combining existing services
  (almost) always available but idle until requests come
  “Provision-able” (used by someone only when necessary,
then reassigned to someone else)
  Easily accessible and usable readily
  no “integration” required
  Self-contained : no visible dependencies to other services
  Coarse grain
  Independent of consumer context
  but a service can have a context
  Quantifiable quality of service
  Do not compete on “What” but “How”

Example: mail
  Customers use mail everywhere
  Interfaces: PostOffice, Mail Box, stamp, postman
  Apparently no relationship with other services (eg.
Transportation, payments)
  Quality of service: price, delivery time, lost
messages

The global service economy

Top Ten Nations by Labor Force Size
(about 60% of world labor in just 10 nations)
A = Agriculture, G = Goods, S = Services
Nation % % % % 25 yr % 2008
WW A G S delta S
100%

90%

Labor 80%

70%

China 21.0 50 15 35 191 60%

50%

India 17.0 60 17 23 28 40%

30%

U.S. 4.8 3 27 70 21
20%

10% China
0%
Indonesia 3.9 45 16 39 35 1810 1835 1860 1885 1910 1935 1960 1985 2010

Brazil 3.0 23 24 53 20 100%

90% (S) Services:
Russia 2.5 12 23 65 38 80%
Value from enhancing the
capabilities of things (customizing,
70%
distributing, etc.) and interactions between things
Japan 2.4 5 25 70 40
60%

50%

40%

Nigeria 2.2 70 10 20 30 30%

20%
United States
Banglad. 2.2 63 11 26 30
10%

0%
1800 1820 1840 1860 1880 1900 1920 1940 1960 1980 2000

Germany 1.4 3 33 64 44

>50% (S) services, >33% (S) services

What is meant by Service?

  In economics and marketing, a service is the intangible
equivalent of an economic good. Service provision is an
economic activity where the buyer does not generally, except by
exclusive contract, obtain exclusive ownership of the thing
purchased (Wikipedia, 2010)
  A service is a “provider to client” interaction that creates and
captures value while sharing the risks of the interactions
  Services are the application of specialized competences (skills and
knowledge) through deeds, processes, and performances for the
benefit of another entity or the entity itself (Vargo & Lusch, 2004a)
  Services are value that can be rented (in the broad sense) by the
application of some process that the renter (client) participates in.
This contrasts with goods, whose value (once purchased) is owned
by the customer (Lovelock & Gummesson, 2004)

What is a
Service (1)

  A facility supplying some
public demand
  the work performed by
one that offers help, use,
or benefit

Merriam-Webster

What is a Service (2)
  In economics and marketing, a
service is a non-material
equivalent of a good
  Service composition is
managed by service providers
who have to offer or provision
more complex services
  The service-good spectrum
shows that most services
include some goods, and also
that most goods involve some
service
  Example: restaurant

en.wikipedia.org/wiki/Service

Discussion

Is software a good or a service?

11

Software-as-a-Service (SaaS)
  1990: Web 0.9 (Tim Berners-Lee)
  1995: Web 1.0 (some dynamic content, Netscape)
  1997: Services (Google, e-commerce...)
  1999: LoudCLoud (first infrastructure for SaaS)
  2000: Web 2.0 (rich UI's, social computing)
  2004: SaaS & SOA (Google Maps, Amazon S3...)
  2008: Cloud Computing (pay as you go)

12

Software as a service
Service: the non-material equivalent of a good

  Software is a service at heart, albeit an automated one, but
it is sold much like a manufactured good. Customers have
to pay large sums of money up front, bear much of the risk
that a program may not work as promised, and cannot
readily switch vendors.
The Economist, 2003

Software-as-a-Service (SaaS)
  Definition of SaaS: Internet-based deployment (for access
and management) of commercially available software
  Service managed from “central” locations enabling
customers to access applications remotely via web
  Delivery: one-to-many model (single instance, multi-tenant
architecture) including architecture, pricing, partnering, and
management characteristics
  Centralized updating, which obviates the need for end-users
to download patches and upgrades
  Frequent integration into a larger network of communicating
software—either as part of a mashup or a plugin to a
platform as a service

14

Software as a service
  An operating system service?
  Program execution, file management

  A Software Service?
  Messaging Service
  Log Service
  Peer to peer distribution
  Search engine

  A Business Service?
  Customer service
  Bidding service

Software services: a multidisciplinary problem

•  Industry policies
Business •  Industry imperatives
Issues •  Business priorities
Business Model

Functional Issues •  Functionality expressed as
Services
•  Map to Business Processes
•  Based on standards
Service Oriented Architecture

Operational •  Model Driven Development
Issues •  Middleware and Software
•  Technology Platforms &
Solutions Realized on an Infrastructure Frameworks
•  Network & Hardware

Dimensions of Sw Engineering for Services
Application Middleware Distributed
Model Computing
Mainframe MQ
Client/Server EAI, B2B DCE

Web Apps BPM CORBA, J2EE
Portals
WS, ebXML
Software
Construction
SalesForce.com
Service Orientation
SAP, Oracle… Object Orientation
MDD
Solutions XP Structured Computing
RUP Programming Model
Methodologies

SOC and SOA

  Service Oriented Computing is a distributed
programming paradigm for business
applications supporting complex enterprises
  Service Oriented Architectures are systems of
services producers and service consumers
  Mostly made of independent software systems
able to be dynamically integrated

SOA
  SOA = Service Oriented Architecture
  SOA is a recent term, but in the past have been
built many systems that today we could call SOAs.
Example: the Web
  The essence of a SOA lies in independent
services interconnected by messages
  On the Web, a specific SOA technology is Web
Services (W3C)

OMG Standards for SOA
http://www.omg.org/attachments/pdf/OMG-and-the-SOA.pdf

BPMN

Business
Process UML

BPDM

SBVR
Task
definition Interfaces defined by enterprise context
Task
implementation ODM UML

Business
Services

RAS
Interfaces defined by enterprise semantics and requirements

J2EE UML
Profile
Components

CORBA
UML Profile

CWM/
Operational IMM
Resources KDM
Servers
Mainframes Servers Mainframes
Data
Data Data Data

Typical topics in SOA
  Model, design, and implement a SOA
  Create an agile, reusable SOA
  Automate business processes by mapping to the
architectural model
  Orchestrate services and execute processes with the
Business Process Execution Language (BPEL)
  Achieve interoperability within a SOA using proven
standards and best practices
  Secure and govern an enterprise SOA

Standardizing bodies for SOAs
  W3C (1994)
  OASIS (1993), consortium of former GML
providers, deals with applications using XML
  OMG (1989)
  WS-I (2002), promotes interoperability among the
stack of Web Services speciﬁcations"

Elements of SOA Design
  Business Modeling
  Service Oriented Architectural Modeling and Design
  Model Driven assumptions (loose coupling)
  Distributed objects and MOM (Message Oriented
Middleware) for component-based sw systems

Business modeling

http://www.ibm.com/developerworks/rational/library/360.html

25

Service oriented modeling and architecting

26

Model driven SOA design

www.theenterprisearchitect.eu/archive/2009/06/03/a-framework-for-model-driven-soa
27

Services and SOAs
  A service is a program interacting via message
exchanges
  On Web all messages and service descriptions are
written in XML
  A SOA is a set of deployed services cooperating
in a given task
  Adapt to new services after deployment

SOA Concepts
Service manage
Operational
Requirements
bound by Expose itself using
enforce
State

Policies Edge

implement
Process/Create
governed by

Message Exchange
Pattern Messages
Contracts
describe direction & types of

contain Schemas define structure of

SOA Reference Architecture
AJAX Portlets WSRP B2B Other
consumers
Service Consumer

Integration (Enterprise Service Bus Approach)

Data Architecture and Business Intelligence
business processes
process choreography

Monitoring Infrastructure Service
QoS, Security, Management, and

Governance
services
atomic and composite
Service Provider

service components

operational systems Packaged Custom OO
Application Application Application

Main SOA Standards
  BPEL (Business Process Execution Language): a standard for assembling sets
of discrete services into an end-to-end business process
  J2EE: the Java Platform, Enterprise Edition, with APIs for deploying and
managing Web services
  JSR 168: standard for portal and portlet interoperability
  JSR 181: an API for Web services metadata annotation
  SOAP (Simple Object Access Protocol): a W3C-approved standard for
exchanging information among applications
  UDDI (Universal Description, Discovery, and Integration): an OASIS-approved
standard specification for defining Web service registries
  WS-I (Web Services Interoperability): an open industry organization promoting
Web services interoperability across platforms, operating systems, and
languages
  WS-Reliability (Web Services Reliability): a SOAP-based protocol for
exchanging SOAP messages, with delivery and message-ordering guarantees
  WS-Security (Web Services Security): a SOAP-based protocol that addresses
data integrity, confidentiality, and authentication in Web services
  WSDL (Web Service Description Language): a W3C-approved standard for
using XML to define Web services
  WSIF (Web Services Invocation Framework): an open source standard for
specifying, in WSDL, EJB implementations for the Web server
  WSRP (Web Services for Remote Portlets): an OASIS standard for integrating
remote Web services into portals
  XML (Extensible Markup Language): a data markup language for Web services

What is SOA?
  Use other services as RPC servers for your app
  Web 1.0: large sites organized this way internally
  Yahoo!, Amazon, Google, …: external “Services”
available, but complex: Doubleclick ads, Akamai
  XML based Web Services msgs and descriptions
  Web 2.0: consumer-facing service API’s
  Services: Google API, Google Analytics, Amazon
CloudFront...
  Platforms: Facebook, Google Maps, ...
  Mashups, e.g. housingmaps.com
  User-composable services, e.g. Yahoo Pipes

32

Amazon.com: Web 1.0 SOA
  ~50 “two-pizza” teams of
web server
“developer/operators” web server
web server

  ~10 operators
  monitor the whole site
  page the resolvers on alarm web server
web server
service A
web server
web server
service B
web server
web server
service C

  ~1000 resolvers
  10-15 per team, 1 on-call 24x7
DB DB DB
  monitor own service, fix problems
  Over 140 code change commits/month
  Internal microcosm of service-oriented architecture
(as were Yahoo, Google, others)

P. Bodík et al., Advanced Tools for Operators at Amazon.com, Proc. ICAC 2005

SOA = RPC
  Transport: HTTP(S)
  Data interchange:
  XML DTD (e.g., RSS)
  JSON (Javascript Object Notation)
  Request protocol:
  SOAP (Simple Object Access Protocol)
  JSON-RPC
  On the horizon: WebHooks (HTTP POST callback,
for “push”)

34

JSON-RPC
  Open connection to designated port on server
  Send HTTP method & request URI, with MIME type of body

set to application/json
  Then send request body:

{ "version": "1.1",
"method": "confirmFruitPurchase",
"id": "194521489",
"params": [ [ "apple", "orange", "pear" ], 1.123 ]
}
  Response might be something like this:
{ "version": "1.1",
"result": "done",
"error": null,
"id": "194521489"
}
  You have to handle substantially all errors
35

RSS
  Request is a regular HTTP GET to a specified URL

<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1">
<channel>
<title>Altarena Playhouse Ticket Availability</title>
<link>http://www.audience1st.com/altarena/store</link>
<description>Altarena Ticket Availability</description>
<item>
<title>Sylvia - Friday, May 14, 8:00 PM – Buy now</title>
<link>http://.../store?showdate_id=347</link>
<guid permalink="false">http://.../store?ts=1271058414</
guid>
</item>
<item>
...
</item>
</channel>
</rss> 36

AJAX and SOA

  AJAX: client  server
  client makes (async) requests to HTTP server
  client-side JavaScript upcall receives reply and
decides what to do
  commonly, response includes XHTML/XML to update
page, or JavaScript to execute
  Doesn’t really make sense except in context of client
  SOA: server  server or client  server
  one principal makes (sync or async) requests to an
HTTP server
  formerly, principal was a server running some app
  today, powerful JavaScript clients blur the line
37

Two ways to do it...

“Thin”
Web 2.0
browser Craigslist.org
app
client

“Fat” browser
Google Maps
client

+ Client portability
+/– Client performance (both app download &
JavaScript execution)
+ Availability of utility libraries for app development
– Privacy/trustworthiness of aggregator app
– Caching
38

REST (Representational State Transfer) style
  Architectural style:
  Client-server, stateless, cache
  description of properties that made Web 1.0 successful
by constraining SOA interactions
  In context of SOA for Web 2.0
  HTTP is transport; HTTP methods (get, put, etc.) are the
only commands
  URI names are a resource
  Client has resource  has enough info to request
modification of the resource on server
  A cookie can encode part of transferred state
  If your app is RESTful, it’s easy to “SOA”-ify
39

What is REST?
  REST is a term coined by Roy Fielding in his Ph.D
dissertation to describe an architectural style of
networked software systems
  "Representation State Transfer is intended to
evoke an image of how a well-designed Web
application behaves: a network of web pages (a
virtual state-machine), where the user progresses
through an application by selecting links (state
transitions), resulting in the next page (representing
the next state of the application) being transferred
to the user and rendered for use."

http://www.ebuilt.com/fielding/pubs/dissertation/top.htm

Why is it called
"Representation State Transfer"?

http://www.boeing.com/aircraft/747
Client Resource

Fuel requirements
Maintenance
...

747.html
The Client references a Web resource using a URL. A representation of the resource
is returned (in this case as an HTML document).
The representation (e.g., Boeing747.html) places the client application in a state.
The result of the client traversing a hyperlink 747.html is another resource is accessed.
The new representation places the client application into yet another state.
Thus, the client application changes (transfers)
state with each resource representation --> Representation State Transfer!

Motivation for REST

"The motivation for developing REST was to create
an architectural model for how the Web should work,
such that it could serve as a framework for the Web protocol standards.

REST has been applied to describe the desired Web architecture,
help identify existing problems, compare alternative solutions,
and ensure that protocol extensions
would not violate the core constraints that make the Web successful."

- Roy Fielding

REST with HTTP examples
HTTP GET! HTTP PUT! HTTP POST! HTTP DELETE!
Collection URI, such as http://example.com/customers/257/orders

List the members of Replace the Create a new entry in the delete the
the collection, entire collection collection. The ID created is entire
complete with their with another usually included as part of collection"
member URIs for collection" the data returned by this
further navigation" operation."

HTTP GET! HTTP PUT! HTTP POST! HTTP DELETE!
Element URI, such as http://example.com/resources/7HOU57Y
Retrieve a Update (or Treats the addressed Delete the
representation of create) the member as a addressed member
the addressed addressed collection in its own of the collection. ""
member of the member of the right and creates a "
collection in an collection" new subordinate of it."
appropriate MIME
type"
43

Example: REST vs SOAP-based
  A company deploying 3 Web services to enable its
customers to:
  get a list of parts
  get detailed information about a particular part
  submit a Purchase Order (PO)

  See the REST solution first, then the SOAP
solution

44

The REST way of Implementing the
Web Services

HTTP GET request URL 1
Parts
Response List
(HTML/XML doc) HTTP response

Web Server
HTTP GET request URL 2
Part
Response
(HTML/XML doc) HTTP response

HTTP POST (HTML/XML)
PO
URL 3
PO

URL to submitted PO HTTP response

Implementing the Web
Service using SOAP
•  Service: Get detailed information about a particular part
–  The client creates a SOAP document that specifies the procedure
desired, along with the part-id parameter.

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>

<p:getPart xmlns:p="http://www.parts-depot.com">
<part-id>00345</part-id>
</p:getPart>

</soap:Body>
</soap:Envelope>

Again, the client will HTTP POST this document to the SOAP server at:
http://www.parts-depot.com/soap/servlet/messagerouter
Note that this is the same URL as was used when requesting the parts list.
The SOAP server peeks into this document to determine what procedure to invoke.

Implementing the Web Services
using SOAP
SOAP envelope

Request
HTTP POST
(XML doc) URL 1
getPartsList()
Response
HTTP Response
(XML doc)

Request

Web Server
HTTP POST
(XML doc) URL 1

Response
SOAP Server getPart(id)
HTTP Response
(XML doc)

PO
HTTP POST
(XML doc) URL 1
submit(PO)
Response
HTTP Response
(XML doc)

Note the use of the same URL (URL 1) for all transactions.
The SOAP Server parses the SOAP message to determine which method to invoke.
All SOAP messages are sent using an HTTP POST.

A RESTful architecture for BPM

48

XML (eXtensible Markup Language)
<book year="1967">
<title>The politics of experience</title>
<author>
<firstname>Ronald</firstname>
<lastname>Laing</lastname>
</author>
</book>
  Really a metalanguage for describing
hierarchical, semistructured, schema-less data
  XML Document Type Definition (DTD) specifies
structural & content constraints on a particular
document type
49

XML (eXtensible Markup Language)
<book year="1967"> Attribute Value
<title>The politics of experience</title>
<author> Element
<firstname>Ronald</firstname> Element
<lastname>Laing</lastname>
</author>
</book>
  Really a metalanguage for describing
hierarchical, semistructured, schema-less data
  XML Document Type Definition (DTD) specifies
structural & content constraints on a particular
document type
50

XHTML & CSS
  XHTML: a document conforming to a particular DTD
describing a hierarchical collection of HTML elements
  Variants: Strict, loose, transitional (for compatibility with deterioriating HTML
syntax 1990-95)

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
  inline (headings, tables, lists...)
  embedded (images, video, Java applets, JavaScript code...)
  fill-in forms—text, radio/check buttons, dropdown menus...,
marshaling arguments into either URI or request body
  CSS (Cascading Stylesheets) for presentation
  Strict XHML forbids presentational markup
  Idea: complete separation of appearance from structure

51

CSS Styles get visual styling applying selectors

<link rel="stylesheet" href="mystyles.css"/>
<div class="pageFrame" id="pageHead">
<h1>
Welcome,
<span id="custName">Armando</span>
</h1>
</div>

  In mystyles.css (static asset with MIME type text/css):

div.pageFrame { background-image: url('/banner.gif'); }
h1 { font-size: large; float: left; }
#custName:hover { background-color: yellow; font-weight: bold; }
  Style properties include borders, background images, and layout
directives (floating, absolute positioning, min/max scaled sizes, etc.)
  Changing style properties has side effect of re-rendering
  e.g., change display or visibility property to show/hide elements

Dynamic content generation
  Most Web 1.0 (e-commerce) sites actually run a
program that generates the output
  Originally: templates with embedded code
“snippets”
  Eventually, embedded code became “tail that
wagged the dog” and moved out of the Web server
  Languages/frameworks evolved to capture
common tasks
  Perl, PHP, Python, Ruby on Rails, ASP, ASP.NET, Java
Servlet Pages, Java Beans/J2EE, ...

55

SaaS 3-tiers architecture
  Common gateway interface (cgi): allows a Web persistent

storage

server to run a program storage

  Server maps some URI’s to application names
  When the app is run, it gets the complete HTTP
request including headers app

application

server

  “Arguments” embedded in URL with “&”
syntax or sent as request body (with POST)
http://www.foo.com/search?term=white
%20rabbit&show=10&page=1 HTTP

  App generates the entire response server

  content (HTML? an image? some javascript?)
  HTTP headers & response code
  Plug-in modules for Web servers allow long-
running CGI programs & link to language
interpreters
•  Various frameworks have evolved to capture this structure!
56

SaaS 3-tiers deployment
  HTTP server (“web server”)
persistent

  “fat” (e.g. Apache): support virtual hosts, plugins for storage

storage

multiple languages, URL rewriting, reverse proxying, ....
  “thin” (nginx, thin, Tomcat, ...): bare-bones machinery to
support one language/framework; no frills app

application

  Application server server

1.  separate server process, front-ended by a “thin” HTTP
server
2.  or linked to an Apache worker via FastCGI or web server HTTP

plug-in: mod_perl, mod_php, mod_rails, ... server

  Apache can spawn/quiesce/reap independent processes
  Persistent storage
  Common RDBMS (MySQL, PostgreSQL, etc.)
  communicate w/app via proprietary or standardized
database “connector” (ODBC, JDBC, ...)
  Hence LAMP: Linux, Apache, MySQL, PHP/Perl
57

Frameworks
  Support for more languages: Apache modules
(mod_perl, mod_php, mod_rails ...)
  avoid spawning new process per request
  typically embed language interpreter in Apache
  Support for common idioms like sessions
  Cookie management
  virtualize connection to database
  “dispatcher” interactions with front-end HTTP server
  Early “templating systems” (e.g. PHP) vs. modern
“full stack frameworks” (e.g. Rails)

58

Example: Rails, a Ruby-based MVC Framework

•  Implemented almost entirely in Ruby
•  Distributed as a Ruby “gem” (collection of related libraries & tools)
•  Connectors for most popular databases
Relational mysql or
Model, View, Controller tables Database
sqlite3
Subclasses of
ActiveRecord::Base models/*.rb Ruby
your app interpreter
views/*.html.erb controllers/*.rb
Rails Rails CGI or other dispatching
rendering routing

apache

Subclasses of Subclasses of
ActionView ApplicationController firefox

What’s new in Web 2.0?
  Primitive UI => Rich UI
  enable “desktop-like” interactive Web apps
  enable browser as universal app platform on cell phones
  “Mass customize” to consumer => Social computing
  tagging (Digg), collaborative filtering (Amazon reviews), etc. =>
primary value from users & their social networks
  write-heavy workloads (Web 1.0 was read-mostly)
  lots of short writes with hard-to-capture locality (hard to shard)
  Libraries => Service-oriented architecture
  Integrate power of other sites with your own (e.g. mashups that
exploit Google Maps; Google Checkout shopping cart/payment)
  Pay-as-you-go democratization of “services are king”
  Focus on your core innovation
  Buy & rack => Pay-as-you-go Cloud Computing

60

Rich Internet Apps (RIAs)
  Closing gap between desktop & Web
  Highly responsive UI’s that don’t require server roundtrip per-action
  More flexible drawing/rendering facilities (e.g. sprite-based animation)
  Implies sophisticated client-side programmability
  Local storage, so can function when disconnected
  early example: Google Docs + Google Gears
  include offline support, local storage, support for video, support for arbitrary
drawing, ...
  currently many technologies—Google Gears, Flash, MS
Silverlight...
  client interpreter must be embedded in browser (plugin, extension, etc.)
  typically has access to low-level browser state => new security issues
  N choices for framework * M browsers = N*M security headaches
  proposed HTML5 may obsolete some of these

61

Rich UI with AJAX
(Asynchronous Javascript and XML)
  Web 1.0 GUI: click → page reload
  Web 2.0: click → page can update in place
  also timer-based interactions, drag-and-drop,
animations, etc.
How is this done?
1.  Document Object Model (1998, W3C) represents
document as a hierarchy of elements
2.  JavaScript (1995; now ECMAScript) makes DOM
available programmatically, allowing modification of
page elements after page loaded
3.  XMLHttpRequest (2000) allows async HTTP
transactions decoupled from page reload
4.  JavaScript libraries (jQuery, Prototype,
script.aculo.us) encapsulate useful abstractions
62

DOM & JavaScript:
Document = tree of objects
  hierarchical object model representing HTML or
XML doc
  Exposed to JavaScript interpreter
  Inspect DOM element value/attribs
  Change value/attribs → redisplay or fetch new
content from server
  Every element can be given a unique ID
  JavaScript code can walk the DOM tree or select
specific nodes via provided methods

<input type="text" name="phone_number" id="phone_number"/>!
<script type="text/javascript">!
var phone = document.getElementById('phone_number');!
phone.value='555-1212';!
phone.disabled=true;!
document.images[0].src="http://.../some_other_image.jpg";!
</script>!
63

JavaScript
  A browser-embedded scripting language
  OOP: classes, objects, first-class functions, closures

  dynamic: dynamic types, code generation at runtime

  JS code can be embedded inline into document...

<script type="text/javascript"> 
</script>
  ...or referenced remotely: <script src="http://evil.com/Pwn.js"/>
  Current page DOM available via window, document objects
  Handlers (callbacks) for UI & timer events can be attached to JS

code, either inline or by function name: onClick, onMouseOver,...
Changing attributes/values of DOM elements has side-effects, e.g.:
<a href="#" onClick="this.innerHTML='Presto!'">Click me</a>

64

AJAX = Asynchronous Javascript and Xml

  Recipe:
  attach JS handlers to events on DOM
objects
  in handler, inspect/modify DOM elements
and optionally do asynchronous HTTP
request to server
  register callback to receive server response
  response callback modified DOM using
server-provided info
  JavaScript as a target language
  Google Web Toolkit (GWT): compile Java => emit JS
  Rails: runtime code generation ties app abstractions to JS

65

A browser is an application container

  “Web apps” include animation, sound, 3D graphics,
disconnection, responsive GUI...
  Browser =~ new OS: manage mutually-untrusting apps (sites)
Source: Robert OʼCallahan (Mozilla.org),!
Inside Firefox!

66

Social Computing

  Web 1.0: add value via mass customization
  select content/presentation for you based on best guesses about
your interests
  resource: demographic/analytic data about you
  Web 2.0: add value via connecting to social network
  vendor: your friends’ interests are a good indicator of your interests
  user: value added to existing content == how your friends interact
with it
  resource: your social network
  From social networking site to social network as a way of
structuring applications
67

Social Computing
  Amount of content “created” by each user small!
  e.g., Digg article, rate video, play a Facebook game
  but still creates lots of short random writes
  consider “Like” feature on Facebook
  social graphs naturally hard to partition (though would
love to see a paper about this from FB)
  question for Web 2.0 developers is not whether
social computing is part of your app, but how
  later we will discuss technical architecture of
“connecting” an app to social networks

68

Facebook

  Facebook plug-in apps
FBQL!
FB data!
1.
Facebook.com! 2.! Your app!
html 4. 3.!

AJAX SO
•  Facebook platform (“Facebook Connect”)!
A

FB data!
REST!
1.
html+ Your app! 2 (opt.). Facebook.com!
3.
xfbml
4.
èREST via JavaScript &
XFBML!
69
ç HTML IFRAME w/FB content!

Google Maps

  Your app embeds Javascript-heavy client code (provided
by Google)
  client-side functionality: clear/draw overlays, etc.
  server-side functionality: fetch new map, rescale, geocoding
  Attach callbacks (handled by your app) to UI actions
  Result of callback can trigger additional calls to Google
Maps code, which in turn contact GMaps servers

1. Your Google
2. app Maps
html+
js 4.
3.
70

Mashups: housingmaps.com

71

Scaling via Replication

  The “most general” deployment scenario for
a 3 tier Web application
DB DB?
  Many Web servers
  possibly including static-asset servers
  L4/L7 load balancers distribute load among them App … App

  Caches and reverse proxies remember
previously-computed content $ … $
  whole page caching
  page fragment caching, query caching WS … WS
  Apache in reverse-proxy mode, or
memcached process(es) addressed by Asset
app server LB …LB
Svr
  Integration of caching with application logic the Internets
varies by framework
72

“Scale makes availability affordable”

  Goal: interchangeability (send any
user request to any available server) DB DB?
  each server handles 1/N load
  affinity can be used to “soft-pin” users to App … App
particular servers
  requires good support for session state $ $
…
abstraction in app framework
  lose 1 server => lose 1/N capacity WS … WS
  Load Balancers have logic to detect
failed servers & remove from rotation Asset LB …LB
Svr
until they are resurrected
the Internets

73

Asset Servers
  For serving static assets (images, sound clips,
CSS, etc.)
  Separate Web server process, configuration
optimized for fast static file serving
  Web 2.0: use Amazon S3 (blob store) or
CloudFront (CDN)
  helps to have good asset-server abstraction in app
framework

74

Deployment scenarios (& approximate pricing)
  Buy/rack/install/configure it yourself...that’s so Web 1.0
  Shared hosting ($3/month)
  turnkey support for popular frameworks, hosted versions of popular
building blocks (e.g. MySQL)
  highly variable performance, multitenant per machine
  Virtual private host ($10/month)
  better isolation and security through virtualization
  substantially more administration
  “Framework VM” or “curated” environments (Heroku,
Google AppEngine, Force.com) – pricing varies
  hosted extensions: memcached, profiling, etc.
  integration of 3rd party hosted services, e.g. Amazon S3 backup
  Cloud Computing

75

Pay-as-you-go Cloud Computing

  Amazon Elastic Compute Cloud (EC2)
  “Compute units” $0.085/hr & up
  1 CU ≈ 1.0-1.2 GHz 2007 AMD Opteron/Xeon core
“Instances”! Platform! Cores! Memory! Disk!
Small - $0.085 / hr" 32-bit" 1" 1.7 GB" 160 GB"
Large - $0.34/ hr" 64-bit" 4" 7.5 GB" 850 GB – 2 spindles"
  N
XLarge - $0.68/ hr"64-bit" 8" 15.0 GB" 1690 GB – 3 spindles"
  No up-front cost, no contract, noextra disk, ..."
Options....extra memory, extra CPU, minimum

  storage (~0.15/GB/month)
  network (~0.10-0.15/GB external; 0.00 internal)
  Everything virtualized, even concept of
76
independent failure 76

Cloud Economics: user side
Cloud Computing: User side "
Static provisioning for peak"
- wasteful, but necessary for SLA"
Capacity $
Machines

Demand Capacity

Demand
Time Time
“Statically provisioned” “Virtual” data center
data center in the cloud

Unused resources
77

Cloud Economics 101

Cloud Computing Provider: Could save energy
"

Capacity

Energy
Machines

Demand Capacity

Demand
Time Time
“Statically provisioned” Real data center
data center in the cloud

Unused resources
78

Risk of Overprovisioning

Underutilization results if “peak” predictions
are too optimistic"
Capacity
Unused resources
Resources

Demand

Time

Static data center

79

“Risk Transfer” to Cloud

  “Cost associativity” from linear pricing: 1,000 CPUs for 1
hour same price as 1 CPUs for 1,000 hours (@$0.10/hour)
  Washington Post converted Hillary Clinton’s travel documents to
post on WWW <1 day after released
  Lab graduate students demonstrate improved Hadoop (batch job)
scheduler—on 1,000 servers
  Major enabler for SaaS startups
  Animoto traffic doubled every 12 hours for 3 days when released as
Facebook plug-in
  Scaled from 50 to >3500 servers
  ...then scaled back down
  Goal: fix any transient problem by adding/removing nodes
  Single-node performance becomes much less important

80

Classifying Clouds for Web 2.0
  Instruction Set VM (Amazon EC2)
  Managed runtime VM (Microsoft Azure)
  Curated “IDE-as-a-service” (Heroku)
  Platform as service (Google AppEngine, Force.com)
  flexibility/portability vs. built-in functionality
Higher-level,
Lower-level,
More managed,
Less managed
more value-added SW

EC2 Joyent Azure Heroku, Force.com
AppEngine
81

Deployment
  “Deployment-as-a-service” increasingly common
  monthly pay-as-you-go curated environment (Heroku)
  hourly pay-as-you-go cloud computing (EC2)
  hybrid: overflow from fixed capacity to elastic capacity
  Remember administration costs when comparing!
  Good framework can help at deployment time
  Separate abstractions for different types of state: session state,
asset server, caching, database
  ORM – natural fit for social computing, and abstracts away from
SQL (vs Web 1.0 PHP, e.g.)
  REST – encourages you to make your app RESTful from start, so
that “SOA”-ifying it is trivial
  Scaling structured storage: open challenge

82

Cloud Computing
  CC makes it possible to obtain results on 1000’s of
servers
  Es. BOOM (declarative cloud programming)
boom.cs.berkeley.edu
  Eucalyptus www.eucalyptus.com makes hybrid
cloud computing reasonably practical
  Run small experiments locally, then “scale up” to cloud
for results
  Why aren’t you using cloud computing yet?

83

Example: Facebook
  Facebook has 2 datacenters, 1 per coast
  reads spread across both
  writes only to W. Coast; periodically (~10 minutes)
replicated to E. Coast
  >2000 MySQL servers, >25TB RAM for memcached
  Challenge: inconsistency due to stale data
  I change status message => Friends on East Coast
datacenter do not see my change for 10 min
  What if E.Coast person changes his own status??

84

Facebook cloud servers

Source: “How Facebook Works”,Technology Review, Jul/Aug 2008

85

SCADS: Scalable, Consistency-Adjustable Data Storage
  Most popular websites follow the same pattern
  Outgrow initial prototype (on MySQL) due to scale
  Build large, complicated ad-hoc systems to deal with
scaling limitations as they arise
  Want Scale Independence as new users join:
  No changes to application
  Cost per user & request latency don’t increase
  Key Innovations
1.  Performance-{safe,insightful} query language
2.  Declarative performance/consistency tradeoffs
3.  Automatic scale up & down using machine learning

M. Armbrust et al., SCADS: Scalable Consistency-Adjustable Data Storage for Interactive Applications. Proc. CIDR 2009!
M. Armbrust et al., PIQL: A Performance-Insightful Query Language. Proc. SOCC 2010. !

Understanding workload spikes
  death of Michael Jackson: 23% of tweets, 15% of Wikipedia
traffic...how to understand/synthesize spikes?
  characterized 5 real spikes
  large differences in many characteristics: steepness, magnitude, #
data hotspots, …
  spike synthesis tool generates realistic workload with few
parameters using statistically sound model
  Cloud computing offers alternative to overprovisioning?

model
Explora/on
of
performance
[ACDC
’09]

policy
Policy
simulator
[HotCloud
’09]

workload
ac/ons

statefu Resource
alloca/on
for
stateful

l
systems

system

P. Bodik et al., Characterizing, modeling, and generating workload spikes for stateful services, SOCC 2010!
P. Bodik et al., Statistical machine learning makes automatic control practical for Internet datacenters, HotCloud '09!
P. Bodik et al., Automatic exploration of datacenter performance regimes, ACDC '09 !
!
!

Browsers are more and more fat
  Performance, security and GUI choke point
  Cookie management, JavaScript, XSS attacks
  CSS layout, side-effects of DOM manipulation
  AJAX: document can change anytime after loading
  RIA frameworks/plugins: Flash, HTML 5, Silverlight
  Device variation: new twist due to power limits
  See http://www.google.com/googlebooks/chrome for a
great fun-to-read description in comic-book form
  Bring “desktop-quality” browsing to mobile tel
  Enabled by 4G networks, better output devices
  Parsing, rendering, scripting are all potential bottlenecks

88


Parallelizing the Browser (R.Bodík et al.)
  New algorithms for CSS, layout, rendering, up to
80X speedup on popular web sites
  Constraint-based browser programming language
unifies layout, rendering, scripting

Slashdot (CSS Selectors)
50
45
40 2ms
Speedup 35
30
25
20
15
10
5
0 84ms
1 2 3 4 5 6 7 8
Hardware Contexts

89

Try it yourself
1.  Download & install RoR (rubyonrails.org)
  A good intro book: Simply Rails 2 by Patrick Lenz
2.  Signup for a free Heroku.com trial account
3.  Install various useful “Ruby gems” (libraries):
gem install heroku cucumber-rails rspec-rails
4.  Create app skeleton:
rails mynewapp ; git commit –m “new app” mynewapp
heroku create mynewapp
5.  Start writing user stories and track your progress
(PivotalTracker.com)
6.  When ready to deploy on Heroku:
git push heroku master
More resources: http://radlab.cs.berkeley.edu > Courses

90

Summary
  New ecosystem: changes software process,
deployment process, interdependencies of DADO
(everything-as-a-service)
  Web 2.0 tools have reached a new plateau of
productivity
  Gap closing between “web app” user experience
vs. desktop app
  New interesting research problems

91

Self test
  Which are the consequences of defining software a
service insted of a good?
  What are the main original features of the REST
style?
  Which software architectural issues are typical of
social software?
  What are the economic basis of cloud computing?

92

References
  www.armandofox.com/geek/teaching/
  radlab.cs.berkeley.edu
  msdn.microsoft.com/en-us/library/aa479069.aspx

93

9 - Architetture Software - SOA Cloud

More Related Content

What's hot (14)

Viewers also liked (20)

Similar to 9 - Architetture Software - SOA Cloud (20)

More from Majong DevJfu (20)

Recently uploaded (20)

9 - Architetture Software - SOA Cloud