1 / 27

Dynamic Software Architectures for Global Computing

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. Outline. Global Computing Systems SW Architecture view Service-Oriented Vision

kyla-gordon
Download Presentation

Dynamic Software Architectures for Global Computing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related