Dynamic Software Architectures for Global Computing

1. Dynamic Software Architectures for Global Computing Antonio Bucchiarone PhD Student – IMT Graduate School Piazza S. Ponziano, 55100 Lucca (Italy) A Joint work with S. Gnesi, R. Bruni and H. Melgratti

2. 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

3. 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)

4. 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

5. 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

6. 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 • 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

7. 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

8. 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

9. Dynamisms in SA Programmed Self-adaptive Ad-hoc Self-organizing Self-repairing Constrained Unconstrained Constructible

10. 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

11. Formal Definition of Dynamicity • a style • a configuration • a rewriting production

12. Formal Definition of Dynamicity • The set R(G) of reachable configurations, i.e., all configurations to which the initial configuration Gin can evolve. • The set D(G) of desirable configurations, i.e., the set of all T-typed configurations that satisfies a desired property p.

13. 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 • Ginis the initial configuration • P is a set of productions gives the evolution of the architecture • Dp(G) = R(G)

14. 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

15. 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

16. 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

17. 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) V1/V2 V2 V1 S V1/S

18. Car Assistance Example –II Architectural Style An instance

19. Programmed Dynamism Architectural Style New vehicle connected to the server Vehicles approximation Initial configuration

20. 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

21. Repairing Dynamism - II • Prpr : “whenever a vehicle without outcoming connections is found, then the vehicle should be connected directly to a server” • Penv contains a unique production • It models the loss of connectivity between vehicles

22. 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

23. 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

24. 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)

25. “When” the changes are defined “Who” monitors and triggers the reconfiguration Flexibility degree A comparison

26. 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)

27. Questions?  antonio.bucchiarone@imtlucca.it