1 Ivan Lanese Computer Science Department University of Bologna Italy Evolvable systems: some ideas for modelling With input from Davide Sangiorgi, Fabrizio Montesi, …

Disclaimer

Evolvability and adaptability l Evolvability: a system may change l Adaptability: a component has to adapt to the changing system –E.g., since the system is evolving l We concentrate more on adaptability –However the two concepts are strongly related –Internalized vs externalized? –Expected vs unexpected? l We concentrate more on the behavioral system model level

Adaptability for components l We concentrate on components to have some framework to work in –Suitable framework for our aims –Exploit our expertise in the field of services (Sensoria project) –Exploit connections with INRIA »Stefani, Schmitt l What is a component? l How it can be modelled? l What means adaptability for components? l Which primitives are needed to model adaptability?

What is a component? l Components have a name, a behaviour, and one or more interfaces (provide interfaces, require interfaces) l Interfaces are sets of functionalities l Components are connected to each other via their interfaces l Components may be nested

An algebra of components l We want an algebra of components –To exploit inductive techniques –To study different alternatives –Usual process calculi approach l Components as first-class entities –Should include description of the interfaces –Functionalities denoted by names l Operators for composing components

A possible algebra of components l C ::= O[P] n I –O and I are the output and input interfaces –n is the name of the component –P is a process in some calculus »May use names in the input interface »Those names will be bound to functionalities offered by other components –Output interface contains names of provided functionalities »Upon invocation a process Q realizing the functionality is added in parallel to P l Components are composed and connected by suitable operators –Parallel composition for putting them together –Name fusion for connecting functionalities l P can include other components if nesting is allowed

Adapting components l Components are adapted by –Changing a functionality –Changing the interface of a component –Changing the connections between components l Which are the best primitives for this aim? –Easy modelling –Expressive power –Minimality

Ideas for possible primitives l Merge and split of interfaces –How to specify the split? –Changing a functionality can be implemented by splitting it, and merging with the new one l Stop and go for components [cfr. Dave talk] –A component is asked to stop –It terminates its activities (will not accept new requests) –It is reconfigured –It is restarted

Adaptability/evolvability in Jolie l Jolie is a language for programming and orchestrating services –Developed by UNIBO and ItalianaSoftware –Inspired by BPEL and WSDL –With a formal semantics (SOCK) l It is an open source project l It is Java-based l It can exploit different communication protocols –HTTP, SOAP, SODEP l It provides mechanisms for adaptability/evolvability

Dynamic embedding l Embedding: a Jolie service may execute another service in its own environment (Java virtual machine) –More easy and fast communication l Dynamic embedding: services may be downloaded and embedded at runtime l Can be exploited for adaptability –A new functionality can be downloaded and replace an old one –A service can be embedded in a wrapper to adapt it to the new environment

Adaptability through meta-programming l Meta-programming allows programs to change other programs l Starting from HOpi Add a construct like if Q=pattern then P l Allows to analyze and update the code l Allows partial evaluation –May be used to connect components to the new environment l How expressive it is?

Dynamic update of error handlers l An idea from error recovery that can be exploited for adaptability l Error recovery: when an activity fails some work is done to take the whole system to a consistent state l Error recovery done by executing suitable handlers –E.g., Java try-catch l In Java the handler is fixed l Our proposal: allowing the program to change the handlers at runtime

Handler adaptation l Allows a more fine grain control on what to do in case of errors l If new handlers can be received at runtime, error recovery policies for new errors can be added –As in YAWL l Handlers can trigger adaptation of the component

Summarizing l Main objective: building an algebra of adaptable components l Inspiration from different sources –Calculi for concurrency and for objects –Meta-programming –Error handling l Jolie can be used to apply those ideas in practice

End of talk