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)

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

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

4. Starting Point • To develop an architecture-centric approach for the modeling and validation of (GC) Systems • Analysis and Testing • Definition of approaches to analyze the architectural specification against various kinds of properties • Tool Support

5. Current Point • Main characteristics of SOA • Service Composition • Industrial and formal approaches comparison • “Dynamicity” in GC systems • Dynamic Software Architecture (DSA) oriented approach

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

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

8. Service Composition - II • 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

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

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

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

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

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

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

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

16. 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> • Tahis a graph that contains an infinite number of components and connectors • The initial graph Ginis any Tah-typed hypergraph that describe a configuration • The set of production Pahis infinite • They can be the combination of add/remove components and add/remove connectors actions

17. 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> • Tahand Gin are as ad-hoc dynamism • Lc is a language for writing reconfiguration programs • PLcis the set of all valid reconfiguration programs that can be written in Lc

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

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

20. Car Assistance Example –II Architectural Style An instance

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

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

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

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