Evolvable systems: some ideas for modelling

1
Evolvable systemssome ideas for modelling
Ivan Lanese Computer Science Department University
of Bologna Italy
With input from Davide Sangiorgi, Fabrizio
Montesi,
2
Disclaimer

• Only preliminary ideas

• To be analyzed

3
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

4
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?

5
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

6
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

7
A possible algebra of components

• C OPnI
• 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

8
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

9
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

10
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/evolvabili
  ty

11
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

12
Adaptability through meta-programming

• Meta-programming allows programs to change other
  programs
• Starting from HOpi
• Add a construct like if Qpattern 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?

13
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

14
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

15
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

16
End of talk

• Thanks!

• Questions?