A. Bucchiarone / Dagstuhl/ 2007 APL Antonio Bucchiarone PhD Student – IMT Graduate School Piazza S. Ponziano, Lucca (Italy)

A. Bucchiarone / Dagstuhl/ 2007 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

A. Bucchiarone / Dagstuhl/ 2007 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)

A. Bucchiarone / Dagstuhl/ 2007 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

A. Bucchiarone / Dagstuhl/ 2007 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

A. Bucchiarone / Dagstuhl/ 2007 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 elementsSA elements in SOA ComponentService PortInterface: WSDL ConnectorProtocol: SOAP, WS- Coordination RoleInvocation relationship between services ConfigurationService Composition Structure StyleComposition Pattern ConstraintsComposition 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

A. Bucchiarone / Dagstuhl/ 2007 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

A. Bucchiarone / Dagstuhl/ 2007 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

A. Bucchiarone / Dagstuhl/ 2007 Dynamisms in SA

A. Bucchiarone / Dagstuhl/ 2007 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. Bucchiarone / Dagstuhl/ 2007 Formal Definition of Dynamicity  a style  a configuration  a rewriting production

A. Bucchiarone / Dagstuhl/ 2007 Formal Definition of Dynamicity  The set R(G) of reachable configurations, i.e., all configurations to which the initial configuration G in can evolve.  The set D(G) of desirable configurations, i.e., the set of all T-typed configurations that satisfies a desired property p.

A. Bucchiarone / Dagstuhl/ 2007 Programmed dynamism  All architectural changes are identified at design-time and triggered by the system itself  A programmed DSA is associated with a grammar G A =  T stands for the style of the architecture  G in is the initial configuration  P is a set of productions gives the evolution of the architecture  D p (G) = R(G)

A. Bucchiarone / Dagstuhl/ 2007 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 G A =  T ah is a graph that contains an infinite number of components and connectors  The initial graph G in is any T ah -typed hypergraph that describe a configuration  The set of production P ah is infinite  They can be the combination of add/remove components and add/remove connectors actions

A. Bucchiarone / Dagstuhl/ 2007 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  G A =  T ah and G in are as ad-hoc dynamism  L c is a language for writing reconfiguration programs  P Lc is the set of all valid reconfiguration programs that can be written in L c

A. Bucchiarone / Dagstuhl/ 2007 Repairing dynamism  Repairing systems are equipped with a mechanism that monitors the system behavior.  G A =  P = P pgm U P env U P rpr  P pgm describe the normal, ideal behavior of the architecture  P env model the einvironment  “ the communication among components may be lost”  “ a non authorized connector become attached to a particular component”  P rpr indicate the way in which an undesirable configuration can be repaired in order to become a valid one

A. Bucchiarone / Dagstuhl/ 2007 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) SV1V1 V2V2 V 1 /S V 1 /V 2

A. Bucchiarone / Dagstuhl/ 2007 Car Assistance Example –II Architectural Style An instance

A. Bucchiarone / Dagstuhl/ 2007 Programmed Dynamism Architectural Style New vehicle connected to the server Vehicles approximation Initial configuration

A. Bucchiarone / Dagstuhl/ 2007 Repairing Dynamism - I  Communication between vehicles is not reliable and can be lost  The architecture should repair itself  G A =  P = P pgm U P env U P rpr  P pgm contains the same productions as Programmed Dynamism

A. Bucchiarone / Dagstuhl/ 2007 Repairing Dynamism - II  P env contains a unique production  It models the loss of connectivity between vehicles  P rpr : “whenever a vehicle without outcoming connections is found, then the vehicle should be connected directly to a server”

A. Bucchiarone / Dagstuhl/ 2007 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

A. Bucchiarone / Dagstuhl/ 2007 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

A. Bucchiarone / Dagstuhl/ 2007 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. Bucchiarone / Dagstuhl/ 2007 A comparison  “When” the changes are defined  “Who” monitors and triggers the reconfiguration  Flexibility degree

A. Bucchiarone / Dagstuhl/ 2007 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)

A. Bucchiarone / Dagstuhl/ 2007 Questions?