A. Bucchiarone / Dagstuhl/ 2007 APL Antonio Bucchiarone PhD Student – IMT Graduate School Piazza...

A. Bucchiarone / Dagstuhl/ 2007

APL

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)


Outline

Global Computing Systems SW Architecture view Service-Oriented Vision

From SA to SOA Dynamic Systems Why DSA? Dynamisms in SA Main Issues for the future


Global Computing (GC) Systems

Heterogeneous, geographically distributed and highly dynamic

Communication topology can vary The components can , at any

moment, connect to or detach from the system

Evolving systems (dynamicity and adaptability)


SW Architecture View

To abstractly model the overall structure of a system in terms of communicating subsystems

Structural description (Topology) Behavioral description (Behavior) In a service oriented vision, SOA are

meant to abstractly model the overall structure of service-centric sw systems in terms of communicating services

SA

SOA


Service Oriented Vision

A new paradigm for specifying and implementing such global systems

Services as fundamental elements for developing applications

Services are autonomous, platform-independent and mobile computational entities

Design-Time: services can be independently described, published and categorized

Run-Time: services are searched/discovered and dynamically assembled for building wide area distributed systems


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

SA elements SA elements in SOA

Component Service

Port Interface: WSDL

Connector Protocol: SOAP, WS-Coordination

Role Invocation relationship between services

Configuration Service Composition Structure

Style Composition Pattern

Constraints Composition Constraints

Dynamism of the architecture Dynamic reconfiguration is prerequisite

for more extensible and efficient service-oriented applications

Dynamism in SA specification is naturally reflected to the runtime evolution of SOA

SA

SOA

WS-SA GS-SA p2p-SA


Dynamic Systems

To support execution during runtime (SOA) for adapting to changes

Changing Requirements Request for new functions May require to integrate new components (statically or at run-time)

Changing Environments Faulty communication channels Mobility leading to a reduced bandwidth May require to replace unreachable components

Key Requirement: “a dynamic system should keep the application in the same state after a change”

Dynamic Reconfiguration


What is DSA?

DSA models a system that reacts to certain events at runtime by supporting reconfiguration of the system’s architecture (Garlan ’98)

Support runtime management and reconfiguration of the systems without human interference (Self-adaptive Systems)

Monitoring, analyzing, implementing and validating systems changes

Internally or externally to the application

Reconfiguration operations Adding interfaces or components Removing interfaces or components Updating interfaces or components Changing the architecture topology by adding

or removing connections between interfaces

DSA

SA

SOA

WS-SA GS-SA p2p-SA


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


Repairing Dynamism - I

Communication between vehicles is not reliable and can be lost

The architecture should repair itself GA=<T,Gin,P> P = Ppgm U Penv U Prpr

Ppgm contains the same productions as Programmed Dynamism


Repairing Dynamism - II

Penv contains a unique production It models the loss of connectivity

between vehicles

Prpr : “whenever a vehicle without outcoming connections is found, then the vehicle should be connected directly to a server”


Constrained and Self Dynamism

Constrained vs unconstrained (When)Transformation rules can take place at

any moment or not

Self vs external (Where)Whether changes are fired internally by

the system itself or activated externally


Constrained vs Unconstrained

Constrained A change may occur only after pre-defined

constrains are satisfied When components are not connected in a specific

way The state of a component, e.g., when a

component enters into a quiescent state The constraints are naturally modeled by

both positive and negative application conditions of graph productions

Unconstrained The transformations can be applied at any

moment


Self dynamism

Programmed and Repairing are “self” The changes are initiated by the system

itself and not by an external agent Explicit

The reconfiguration rule is selected by an external source and not by the system itself

Autonomous The system selects one of all the applicable

transformations in a non-deterministic way Pre-defined

The system selects in a deterministic way (if-then-else)


A comparison

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

reconfiguration Flexibility degree


Main Issues for the Future

To extend the comparison with a “verification power” column

To map these dynamicities in an Architectural Programming language (ArchJava or Java/A) as new primitives

To verify properties of interest in GC Consistency and Correctness of the

composition (orchestrations and choreographies in SOA)

Non-Functional requirements (QoS)


Questions?

[email protected]

Date post:	19-Dec-2015
Category:	Documents
View:	213 times
Download:	1 times

A. Bucchiarone / Dagstuhl/ 2007 APL Antonio Bucchiarone PhD Student – IMT Graduate School Piazza...

Documents