A. Bucchiarone / Pisa/ 30 Jan 2007 Dynamic Software Architectures for Global Computing Antonio...
-
date post
15-Jan-2016 -
Category
Documents
-
view
216 -
download
0
Transcript of A. Bucchiarone / Pisa/ 30 Jan 2007 Dynamic Software Architectures for Global Computing Antonio...
A. Bucchiarone / Pisa/ 30 Jan 2007
Dynamic Software Architectures for Global Computing
Antonio BucchiaroneAntonio Bucchiarone
PhD Student – IMT Graduate School PhD Student – IMT Graduate School Piazza S. Ponziano, 55100 Lucca Piazza S. Ponziano, 55100 Lucca
(Italy)(Italy)
A. Bucchiarone / Pisa/ 30 Jan 2007
Agenda
Global Computing Systems Starting Point
SA for Global Computing Systems Validation and Verification of SA
Current Point Service-Oriented Computing (SOC)
Service Composition and Evolution Dynamic Software Architecture (DSA)
oriented approach
Main Issues for the future
A. Bucchiarone / Pisa/ 30 Jan 2007
Global Computing (GC) Systems
Autonomous computational entities where activity is not centrally controlled (global services) The entities are created or controlled by different owners
The system is open to the introduction of new computational entities, the behavior may vary over time (dynamic systems)
The offer is expected to evolve from relatively simple (customer) services to global complex (business) solutions (service-oriented computing).
Evolving systems (dynamicity and adaptability)
A. Bucchiarone / Pisa/ 30 Jan 2007
Starting Point
To develop an architecture-centric approach for the modeling and validation of (GC) Systems
Analysis and TestingDefinition of approaches to analyze
the architectural specification against various kinds of properties
Tool Support
A. Bucchiarone / Pisa/ 30 Jan 2007
Current Point
Main characteristics of SOAService Composition Industrial and formal approaches
comparison “Dynamicity” in GC systems Dynamic Software Architecture
(DSA) oriented approach
A. Bucchiarone / Pisa/ 30 Jan 2007
Service Oriented Computing
Services as fundamental elements for developing applications
SOC relies on Service-Oriented Architecture (SOA)
SOA is a kind of SA in the context of WSs This model involves three indispensable
participants Service Provider, Service registry and Service
requestor
A. Bucchiarone / Pisa/ 30 Jan 2007
Service Composition - I
It combines existing services following a certain pattern to form a new service.
Web Service Composition Approaches: From Industrial Standards to Formal Methods [ICIW’07]. Syntactic WS Composition
BPEL4WS, WS-CDL Semantic WS Composition
OWL-S, WSMO Formal Methods for WS Composition
Automata, Petri Nets, Process Algebras
A. Bucchiarone / Pisa/ 30 Jan 2007
Service Composition - II
Connectivity Correctness QoS
ReliabilityAccessibility
Exception HandlingCompensations
SafetyLivenessSecurity
Trust
AccuracyAvailabailityPerformance
BPEL
Connectivity
Correctness
QoS
Syntax-based Semantic-based
CHARACTERISTICS
Exception handling
WS-CDL OWL-S WSMO
± +± +
- - - -
+ + + +
Compensations -
+
+ + +
+ ± +
Neither of these approaches offer any direct support for the verification of WS compositions at design-time.
Lack of software tools to verify the correctness of WS compositions
A. Bucchiarone / Pisa/ 30 Jan 2007
Service Composition - III
Automata I/O automata, timed automata, team automata A lot of framework to analyze and verify properties of WS
composition of BPEL processes From BPEL to automata (SPIN and LTL properties) From WS-CDL to timed automata (UPPAAL MC)
Petri Nets BPEL control-flow constructs into labeled PNs BPEL2PN automatic transformation of BPEL processes in
PNs
Process Algebras Π-calculus, LOTOS,..to describe, compose and verify WSs
A. Bucchiarone / Pisa/ 30 Jan 2007
From SA to SOA
SA is intended to describe the structure of a system Interactions of Computational components Patterns that guide their composition and constraints on
these patterns SOA
Services as fundamental elements for developing applications
SOA should support evolution during runtime for adapting to changes of environment and requirements
Service Composition combines existing services following a certain pattern to form a new value-added service
Support for “dynamism” of SOA is fundamental to its evolution
A. Bucchiarone / Pisa/ 30 Jan 2007
Dynamisms in SA
A. Bucchiarone / Pisa/ 30 Jan 2007
Formal Definition of Dynamicity
Hypergraph that describes a style (or meta-model)
Components and Connectors are hyperedges Component exposes different ports Connector has tentacles to the ports
Ports are nodes
A. Bucchiarone / Pisa/ 30 Jan 2007
Formal Definition of Dynamicity
a style
a configuration
a rewriting production
A. Bucchiarone / Pisa/ 30 Jan 2007
Formal Definition of Dynamicity
The set R(G) of reachable configurations, i.e., all configurations to which the initial configuration Gin can evolve.
}|{)( * GGGGR in The set D(G) of desirable configurations,
i.e., the set of all T-typed configurations that satisfies a desired property p.
}|{)( G inholds p graphtyped-a T isGGGD
A. Bucchiarone / Pisa/ 30 Jan 2007
Programmed dynamism
All architectural changes are identified at design-time and triggered by the system itself
A programmed DSA is associated with a grammar GA=<T,Gin,P> T stands for the style of the architecture Gin is the initial configuration P is a set of productions gives the evolution of
the architecture Dp(G) = R(G)
A. Bucchiarone / Pisa/ 30 Jan 2007
Ad-hoc dynamism
All architectural changes are established by the user at unpredictable run-time.
An ad-hoc DSA is associated with a typed grammar GA=<Tah,Gin,Pah> Tah is a graph that contains an infinite
number of components and connectors The initial graph Gin is any Tah-typed
hypergraph that describe a configuration The set of production Pah is infinite
They can be the combination of add/remove components and add/remove connectors actions
A. Bucchiarone / Pisa/ 30 Jan 2007
Constructible dynamism
All architectural changes are identified at run-time and triggered by the user.
It is similar to ad-hoc but the rewriting productions are not the free combination of basic primitives
GA=<Tah,Gin,PLc> Tah and Gin are as ad-hoc dynamism Lc is a language for writing reconfiguration programs PLc is the set of all valid reconfiguration programs that can
be written in Lc
),,(),,( ahin
ahLin
ah PGTRPGTR c
A. Bucchiarone / Pisa/ 30 Jan 2007
Repairing dynamism
Repairing systems are equipped with a mechanism that monitors the system behavior.
GA=<T,Gin,P> P = Ppgm U Penv U Prpr
Ppgm describe the normal, ideal behavior of the architecture
Penv model the einvironment “ the communication among components may be lost” “ a non authorized connector become attached to a particular
component” Prpr indicate the way in which an undesirable configuration
can be repaired in order to become a valid one
A. Bucchiarone / Pisa/ 30 Jan 2007
Car Assistance Example - I
Components: Vehicle (V): responsible for transmitting messages destined to the assistant
server. Accident Assistant Server (S): handles help requests
Connectors: (V/V) : used for mediating the communication between two vehicles (V1/V2) (V/S) : used for supporting the interaction between a vehicle and a server
(V1/S)
SV1 V2
V1/S
V1/V2
A. Bucchiarone / Pisa/ 30 Jan 2007
Car Assistance Example –II
Architectural Style
An instance
A. Bucchiarone / Pisa/ 30 Jan 2007
Programmed Dynamism
Architectural Style New vehicle connected to the server
Vehicles approximation
Initial configuration
A. Bucchiarone / Pisa/ 30 Jan 2007
A comparison
“When” the changes are defined “Who” monitors and triggers the
reconfiguration Flexibility degree
A. Bucchiarone / Pisa/ 30 Jan 2007
Main Issues for the Future
High-level modeling of dynamic and service-oriented systems Compare SMRL and UML profiles defined in Sensoria w.r.t. the
WS Composition Characteristics To understand what kinds of dynamicity they are able to specify To use them to model the scenarios of Sensoria
Model Transformation To implement some approach to map high-level models to
languages used for verification using methods like MDD Verification Methods
To adapt the approaches already proposed in the field of SA for the SOA (or DSA)
To verify properties of interest in GC Consistency and Correctness of orchestrations and choreographies, Exception Handling and Compensation QoS