1

Ivan LaneseComputer Science Department

University of BolognaItaly

Evolvable systems:some ideas for modelling

With input from Davide Sangiorgi, Fabrizio Montesi,

…

Disclaimer

Evolvability and adaptability

Evolvability: a system may change Adaptability: a component has to adapt to the changing

system– E.g., since the system is evolving

We concentrate more on adaptability– However the two concepts are strongly related

– Internalized vs externalized?

– Expected vs unexpected?

We concentrate more on the behavioral system model level

Adaptability for components

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

What is a component? How it can be modelled? What means adaptability for components? Which primitives are needed to model adaptability?

What is a component?

Components have a name, a behaviour, and one or more interfaces (provide interfaces, require interfaces)

Interfaces are sets of functionalities Components are connected to each other via their

interfaces Components may be nested

An algebra of components

We want an algebra of components– To exploit inductive techniques

– To study different alternatives

– Usual process calculi approach

Components as first-class entities– Should include description of the interfaces

– Functionalities denoted by names

Operators for composing components

A possible algebra of components

C ::= O[P]nI– 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

Components are composed and connected by suitable operators– Parallel composition for putting them together

– Name fusion for connecting functionalities

P can include other components if nesting is allowed

Adapting components

Components are adapted by– Changing a functionality

– Changing the interface of a component

– Changing the connections between components

Which are the best primitives for this aim?– Easy modelling

– Expressive power

– Minimality

Ideas for possible primitives

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

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

Jolie is a language for programming and orchestrating services– Developed by UNIBO and ItalianaSoftware

– Inspired by BPEL and WSDL

– With a formal semantics (SOCK)

It is an open source project It is Java-based It can exploit different communication protocols

– HTTP, SOAP, SODEP

It provides mechanisms for adaptability/evolvability

Dynamic embedding

Embedding: a Jolie service may execute another service in its own environment (Java virtual machine)– More easy and fast communication

Dynamic embedding: services may be downloaded and embedded at runtime

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

Meta-programming allows programs to change other programs

Starting from HOpi Add a construct like if Q=pattern then P Allows to analyze and update the code Allows partial evaluation

– May be used to connect components to the new environment

How expressive it is?

Dynamic update of error handlers

An idea from error recovery that can be exploited for adaptability

Error recovery: when an activity fails some work is done to take the whole system to a consistent state

Error recovery done by executing suitable handlers– E.g., Java try-catch

In Java the handler is fixed Our proposal: allowing the program to change the

handlers at runtime

Handler adaptation

Allows a more fine grain control on what to do in case of errors

If new handlers can be received at runtime, error recovery policies for new errors can be added– As in YAWL

Handlers can trigger adaptation of the component

Summarizing

Main objective: building an algebra of adaptable components

Inspiration from different sources– Calculi for concurrency and for objects

– Meta-programming

– Error handling

Jolie can be used to apply those ideas in practice

End of talk