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)


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


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)


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


Current Point

Main characteristics of SOAService Composition Industrial and formal approaches

comparison “Dynamicity” in GC systems Dynamic Software Architecture

(DSA) oriented approach


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


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


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


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


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


Dynamisms in SA


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 style

a configuration

a rewriting production



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


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)


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


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


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


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


Car Assistance Example –II

Architectural Style

An instance


Programmed Dynamism

Architectural Style New vehicle connected to the server

Vehicles approximation

Initial configuration


A comparison

“When” the changes are defined “Who” monitors and triggers the

reconfiguration Flexibility degree


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


Questions?

[email protected]

Date post:	15-Jan-2016
Category:	Documents
View:	215 times
Download:	0 times

A. Bucchiarone / Pisa/ 30 Jan 2007 Dynamic Software Architectures for Global Computing Antonio...

Documents