Transcript IWSC 2012 16 July 2012, Izmir, Turkey

Applied Formal Methods Seminars
Cloud Software Engineering
-- A vision of research on software
engineering in the era of cloud computing
Hong Zhu
Department of Computing and Communication Technologies
Oxford Brookes University, Oxford OX33 1HX, UK
Email: [email protected]
Outline
•
•
•
•
•
•
•
What is Cloud computing?
What are the quality concerns?
What is the ideal architecture for Cloud?
What is the process model?
How to specify SaaS?
How to program SaaS?
How to test SaaS?
What is Cloud Computing
What are the differences:
•
•
•
•
•
Personal computing,
Enterprise computing,
Grid computing,
Service oriented computing,
Cloud computing
Computing Paradigm as a Socio-Technical
System
What are the
technologies
used to?
How resources
Technology
are managed?
What are the
management
goals?
Computation
resources
Management
model
Managers
Relationships
between the
resource owner,
customers and
users
Business
model
Users
What are the types and numbers
of computation resources in a
computation system?
Customers
Characteristics of Cloud Computing
Technology
Business
model
• Pay-for-use
• Service level
agreement
• Multiple
customers
and users
Management
• Centralized
resources
management
• Optimized for
the owners
economic
benefits
•
•
•
•
•
•
•
•
•
•
Internet
Virtualization
Security
Web
Mobile
communication
QoS
Cluster
Client-server
programming
Load balancing
etc.
Resource
• Types:
• compute
• Storage
• Communication
• Database
• Software
• Number:
• Huge scale
Constraint: Service Level Agreement
Comparison with other paradigms
Paradig
m
Technical model
Management model
Business model
Personal
• Single small scale computer system
• All software installed on the computer
• Personal responsibility,
• little support from product
producer
• No clearly defined financial
purposes,
• For personal or family uses
Enterpris
e
• Large scale, multiple servers
• Connected through LAN, sometime also
the Internet
• Purposely built software
• IT department
• For maximal availability and
throughput
• Responsible for security, etc.
• No direct financial target
• To serve enterprise’s
business goal
Grid
• Multiple clusters of servers
• Connected through LAN plus the Internet
• Special middleware for network
transparency
• Multiple purposely built software systems
• Owned by multiple institutes
• Managed by owner institutes
• Exchange of resources for
each institute’s own benefit
and to serve each
institutes own business
goal
Serviceoriented
•
•
•
•
• Each service is own by an
institute and managed by the
owner
• Maintain QoS to attract external
uses
• To improve business
environment
• To gain market advantages
through provide wider
automated access to the
business functions
Cloud
• Large scale of combination of computing
resources through LAN plus the Internet
• Flexibility of usage through virtualization,
etc.
• Separation between large number of
tenants x users
• Centralized management of all
resources by the owner
• To meet SLA to every tenant x
user
• Maximal owner’s financial
benefit through efficiency
• Rent resources to tenants
to gain financial benefit
• Pay-per-use of the
resources to the tenants
Multiple clusters of servers
Connected through LAN plus the Internet
Use standard interface
Published and searchable
Cloud Computing and Software Engineering
 Software engineering for cloud computing
 The engineering (i.e. the development, operation and
maintenance ) of software systems in cloud
computing
 Software systems that realize cloud computing
 Software delivered as services in cloud
computing
 Cloud computing for software engineering
 An application of cloud computing to software
engineering, i.e. using cloud computing facilities for the
development, operation and maintenance of software (of
all types, also include cloud software)
We use the phrase cloud software engineering to include
both of the above.
Why cloud software engineering is difficult?
Essences of Software Engineering
Complexity. It is an essential property of software.
Conformity. Software is expected to conform to the
standards imposed by other components, such as hardware,
or by external bodies, or be existing software.
Changeability. Software suffers from constant needs of
changes.
Invisibility. Any forms of representations that are used to
describe software will lack any form of visual link that can
provide an easily grasped relationship between the
representation and the system.
Brooks, F. P. Jr, No silver bullet: essence and accidents of
software engineering, IEEE Computer, 1987, pp10~19.
Essences of Cloud Software Engineering
 Complexity
 services can be discovered and composed at runtime into composite
services by the users
 Conformity
 to the platform and environment
 to the semantics of services when they are dynamically searched and
composed
 Changeability
 users’ requirements and platform changes
 the services changes
 the ontology in which semantics of services are defined changes
 the users and tenants (and the human society) is changing
 Invisibility
 the documents, even the source code, of the software from third party
services are not available
A Model of Cloud SW
SignAsServiceProvider
ResourceManager
ServiceLevelAgreement
SignAsCustomer
+ResourceRequest
Pay
Customer
Bill
ResourceAllocator
ResourceMonitor
CloudUI
Results in
Authorises
Usage
ResoruceControler
User
RequestService
+GetState
+SetState
Automatic,
Autonomic,
Self-adaptive,
Optimization w.r.t.
SLA
+SetAssiment
Resouce
+Type
+PerformanceParameters
+State
+Assignment
Software
Hardware
Services
CPU
Database
Storage
Platform
Communication Bandwidth
Application
Automatic and
continuous
integration and
testing,
Self-configuration
and composition,
Self adaptation,
etc.
McCall’s Software Quality Model
Maintainability:
Can I fix it?
Flexibility:
Can I change it?
Testability:
Product Product
Can I test it? revision transition
Product
operations
Portability:
Will I be able to use it on
another machine?
Reusability:
Will I be able to reuse some of
the software?
Interoperatability:
Will I be able to interface it
with another machine /
software?
Correctness: Does it do what I want?
Reliability: Does it do it accurately all the time?
Efficiency: Will it run on my machine as well as it can?
Integrity: Is it secure?
Usability: Can I run it?
11
Quality Model for Cloud Software
Product
operations
Product
operations
Product
operations
Product
operations
Quality Model of Cloud Computing
Customer concerns:
 Operation: Security, privacy, availability, reliability
 Transition: Interoperability (locked in)
 Revision: Maintainability, etc.
Management concerns:
 Operation: Monitoring, control, Energy efficiency, running overhead,
book keeping and billing, etc.
 Transition: Legal implications
 Revision: Maintenance of resources
Technology concerns:
 Operation: Pervasive access to resources, elastic scale (supported
by virtualization), fault-tolerance
 Transition: Rapid development and deployment
 Revision: Online testing, online integration, continuous and online
integration and evolution, etc.
Models of SW Delivered by Clouds
Cloud Architecture
Software as a Service
Platform as a Service
Infrastructure as a Service
Hardware as a Service
Figure 1: Layered architecture of cloud services
Cloud Architecture
 IaaS = Infrastructure as a Service
 Delivery of computer infrastructure as a service
 Typical examples: GoGrid, Flexiscale, etc.
 PaaS = Platform as a Service
 A platform provided to software developers for developing cloud
applications
 Includes all systems and environments
 Covers end-to-end lifecycle of developing, testing, deploying, and
hosting of applications that are delivered as services
 Typical examples: GAE, Azure, EC2, etc.
 SaaS = Software as a Service (Application Service Provider
(ASP) model)
 Supporting multiple customers simultaneously
 Using a single instance of object code, underlying database, and other
common resources
 Typical examples: Salesforce.com, NetSuite, etc.
Multi-Tenancy Architecture
Tenant
User User
User
User
User
User
Tenant
Data
Data
Data
Data
Code/Meta-data
C-data
SaaS
Code
Code
Code
Code
Code
Code
C-data
Code
Data
Data
Code/Meta-data
Code
Code
PaaS Platform
IaaS (Cloud infrastructure/hardware)
Building the
software for a
new tenant is
by integration
and
composition of
existing
software.
Change of one
component
have impact on
many
customers.
The challenge:
Bob Warfield [October 20, 2007]:
It has to be possible to do all the customization
needed with the following qualities:
• It’s approachable by non-technical users
• It involves metadata, not code changes, and the
metadata can run in a multitenant single-instance
world without disturbing other tenants.
• The work to configure a new customer is a tiny
fraction of the annual SaaS contract even if you
farm the work out to consultants.
How can non-technical user customerize SaaS
application?
Process model for SaaS
Tenant
User
User
Requirements
Analysis
Service Registry
Requirements Spec
Ontology
of
Application
Domain
Design and
Implementation
New
New
services
service
Meta-data
Integration &
Testing
Deploy
Ontology
of
platform
services
Ontology
of HW
Data
Data
Meta-data
User
Data
C-dataSaaS
..
Code
(service)
Code
(service)
Code
(service)
Code
(service)
Code
(service)
Code
(service)
PaaS Platform
Infrastructure
Note:
• The heart of the long lasting debate between
multi-tenancy (single instance) and multiinstance approaches is which one can provide
best support to service evolution.
• It is also complicated by its relation to other
issues of cloud computing, such as security.
How to test SaaS?
Automation!
Review:
Automated Test Framework for OO SW
Class A
Class TA
Class B
Class C
Class TB
X-Unit Test Framework:
X: Java, C++, …
Class TC
Review: Test Automation Framework for WS
Match
maker
Tester T1
Test Broker
Tester T2
T-service of A1
T-service of A2
T-service of A3
F-service A1
F-service A2
F-service A3
[COMPSAC 2003]
Ontology Management
UDDI
Registry
22
Key technical issues
The key technique issues:
 How to describe, publish and register test services at WS
registry;
 How to retrieve test services automatically for testing
dynamically composed services;
 How invoke test services by both a human tester and a
program;
 How to report test results in the forms that are suitable for
both human beings to read and machine to understand
These issues can be resolved by the utilization of a software
testing ontology. [COMPSAC 2003]
23
Architecture of the Test Broker
We have developed a prototype test broker to demonstrate
the feasibility and sclabality of the approach. [IEEE TSC]
24
Fit into the SaaS architecture and process
Tenant
User
User
Requirements
Analysis
Service Registry
Requirements Spec
Ontology
of Application
Domain
Design and
Implementation
New
New
service
service
Meta-data
Ontology
of
platform
services
Data
Data
Meta-data
User
Data
Data
SaaS
service
service
service
T-service
T-service
T-service
service
service
service
T-service
T-service
T-service
PaaS Platform
Integration &
Testing
Deploy
Ontology
of Ontology
Test
of HW
Infrastructure
How to program SaaS?
Agent-orientation
Example: A Simple Program (1)
caste Peer;
observes all p in Peer;
action
say(word: String) { };
body
say(“Hello”);
end Peer.
caste FriendlyPeer <= Peer;
body
when exist p in Peer: [say(“Hello”)]
-> then say(“Welcome”);
end;
end FriendlyPeer.
caste CheerfulPeer <= Peer;
body
when exist p in Peer: [say(“Hello”)]
-> then say(“Hi, good morning.”);
end;
end CheerfulPeer.
Main features:
Network transparency:
• Multiple agents
running on computers
over a network
• Code deployed on
different computers
Heterogeneous
behaviours in response
to an event
Agent-orientation is for the Internet
 Proposed in [Zhu 2000] for internet computing
 Key features: (modelling how people collaborate)
• Autonomous: each people can only change its own state;
• Active behaviour: take action as you like
• Sociability: find/meet people and make links dynamically
• Communication: Asynchronous and unreliable
 Software running on the internet today fits well to this model
 For example:
 Facebook, YouTube, Tweeter, LinkedIT, Web Services, etc.
 Key features:
 Autonomous: my resources and my states are management by myself only
 Active behaviour: I take action as I want to, not just react to calls
 Sociability: make links dynamically
 Communication: asynchronous and unreliable
Architecture of CAVM Virtual machine
CAVM Object Code
CAOPLE Source Code
Caste SC1
Compile
Caste OC1
Caste SCn
Caste OCn
Deploy
Communication
Engine
Computer C2
CE2
Local Execution
Engine
Computer C1
CE1
Computer Cn
Instantiate
Computer C3
LEE1
LEE2
LEEk
CAVM -- LEE
local
network
Communication Manager
Memory Space
Agent Am
context data
Program Space
Central
Processing
Unit (CPU)
Context
Registers
List of Loaded Castes (LLC)
List of Agents (LoA)
…
Loader
PC
Environment data
Agent A1
context data
network
object code
OC1
object code
OC2
…
object code
OCn
CAVM - CE
network
local
network
Publication Space
Receiver
Dispatcher
Communication
Manager
Deployment
Manager
Agent A1 s/a data
…
Agent Ai s/a data
Membership List
(of active Agents)
Membership
Manager
Caste
object code
Example: A Simple Program (2)
caste Peer;
observes all p in Peer;
action say(word: String) { };
body say(“Hello”);
end Peer.
Separation of concerns:
• Computation algorithm
• Input/output
• Book keeping
caste Monitor;
caste Display<= Textbox;
observes all p in Peer;
observes all p in Peer;
var MessageCount: Integer;
var m: String;
initiate MessageCount := 0;
body
body
when exist p in Peer: [say(m)]
when exist p in Peer: [say(x)]
->begin
->begin
OutputText:=
MessageCount :=
AgentID(p)# “ says: ” # m;
MessageCount + 1;
end
end
end
end
end Display
end Monitor
Example: A Simple Program (3)
caste Peer;
observes all p in Peer;
action
say(word: String) { };
body
say(“Hello”);
end Peer.
Context and environment
caste SmartPeer <=Peer;
Observes LocalDateTime: Clock;
body
When
LocalDateTime.Day = Monday
-> Join (FriendlyPeer);
LocalDateTime.Day <> Monday
-> Join (CheerfulPeer);
end;
end SmartPeer.
Adaptive behaviour
• An agent can
autonomously join
and quit a caste to
change its role and so
to change its
behaviour
• An agent’s behaviour
can be context
sensitive to the
change in its
environment
Adaptation of behaviour
according to the context
How to Specify SaaS?
Algebraic/Coalgebraic Specification
The Challenges
Specify services with high flexibility in the
composition of Services
 Modularity,
 composeblility,
 hiding design and implementation details
Advantages of Algebraic Specifications
 Implementation independent
 Techniques and tools to support
 Automatic testing
 Theoretically foundation
 Concurrent systems, state-based systems, components
 Readable and easy to write specifications (Zhu&Yu, QSIC
2010)
2015/7/17
35
Typical scenario example
 A ticket booking service
 Input:
Such operators are not
 date of ticket required;
allowed by existing
 number of tickets;
algebraic specification
 Internal state:
languages
 number of tickets available
 Output:
 message about ticket booking success or failure
 Operator declaration in CASOCC-WS:
BookTicket: BOOKING, DATE, NAT -> MESSAGE, BOOKING.
BookTicket: [BOOKING] DATE, NAT -> MESSAGE.
2015/7/17
36
Syntax structure
 Importation relation
A binary relation﹤ to give the set of imported
sorts and their operators
BOOL ﹤Stack
NAT ﹤Stack
Spec Stack;
Import BOOL, NAT;
…
 Operator definition:
Format:
op_name: domain -> co-domain;
push: Stack, NAT -> Stack;
Context: the main sort name can be indicated as the
context of the operator if it occurs in both domain and
co-domain
And: [BOOL] BOOL -> VOID;
2015/7/17
37
Signature
Co-algebra operators
The co-domain is non-singleton
The domain is singleton
Spec STREAM;
Import NAT;
Operators:
Transformer:
NEXT: STREAM -> NAT,STREAM;
Axioms:
…
End
2015/7/17
38
Axioms
Conditional equations:
t1 = t2; if c1 = d1; c2 = d2; … ; cn = dn
S(x) = S(y), if EQ(x, y)=TRUE
S(x) = S(y), if EQ(x, y)
Local variable declarations
Let x1 = t1; ; xn = tn in Equs end
Let aID = B.OpenAccount(customer),
B’ = B.[OpenAccount(customer)]
in B’.Account(aID).CustomerInfo = customer end
Axioms
 Format: Forall <variable decls> Equs
2015/7/17
39
Semantics of specification
Given a system signature (S,), a (S,)-algebra is a
mathematical structure (A, F) that consists of a
collection A={As | s S} of sets indexed by s S, and
a collection F={f |  } of functions indexed by the
set  such that for each operator , the function f
has domain Aw and co-domain Au, where
 w = (s1; … ; sn), Aw = As1 …  Asn, and
 u = (t1; … ; tk), Au = At1 …  Atk.
2015/7/17
40
Satisfaction relation
An (S, )-algebra A =(A,F) satisfies equation e,
write A |- e, if for all assignments , we have that
[[e]] = true, whenever [[ci]]  =[[di]]  for all i=1..k.
The semantics of an algebraic specification is the
final algebra that satisfies the specification.
 an-algebra A is initial, if for all algebras B, there is a
unique homomorphism from A to B.
 The algebra A is final, if for all algebras B, there is a
unique homomorphism from B to A .
2015/7/17
41
Case Study
GoGrid
 IaaS provider
 Interface: RESTful web services
 HTTP operators to invoke services running on servers
 No standard for definition of the interface
Result of the Case Study [Liu et al]
 Detecting errors in GoGrid documents
 Ambiguity
 Incompleteness
 Inconsistency
Thank You