A Framework for Rule-based Dynamic Adaptation

1. A Framework for Rule-basedDynamic Adaptation Ivan Lanese Computer Science Department Focus research group University of Bologna/INRIA Bologna, Italy Joint work with Antonio Bucchiarone (Fondazione Bruno Kessler - IRST, Trento) and Fabrizio Montesi (University of Bologna/INRIA, Bologna)

2. Roadmap • Dynamic adaptation • A rule-based approach • The JoRBA prototype • Conclusions

3. Roadmap • Dynamic adaptation • A rule-based approach • The JoRBA prototype • Conclusions

4. Adaptation • Applications should change to adapt themselves to changes in the operating conditions • So to always meet user expectations • Without intervention from technicians • Adaptation can be triggered by • Dynamicity of the environment • Mobility • Communicating partners can appear and disappear • Changes in user needs • …

5. Built-in adaptation • The application includes the logic to adapt itself • Different approaches in the literature • Example: workflows extended with • Constraints on the environment • Handlers for environment events • … • Requires to foresee during application development most of the information concerning adaptation • Which event will trigger adaptation • Which new behavior will be required • This is not always possible

6. Dynamic adaptation • Aims at adapting applications to changes that were not predictable at application development time • Applicable also when built-in adaptation is not • Main challenges: • The adaptation logic cannot be part of the application • We want to update the application logic, not only the application state

7. Travelling scenario • Bob is travelling from University of Bologna to University of Trento for a working meeting • Bob has a mobile phone with a Travelling application • Booking the train ticket from Bologna to Trento • Instructing Bob to take the booked train • Booking the bus from Trento train station to Trento University • Instructing Bob to take the bus

8. High speed trains • Assume a new high speed connection has been createdbetween Bologna and Trento • Applications involving taking trains may require adaptation • For instance, our Travelling application • When the Travelling application connects to Bologna train station information system, Bologna train station adaptation middleware • Discovers that the application may be adapted to exploit the new high speed connection • Checks if adaptation is possible • The application provides the needed adaptation interface • Checks if adaptation is desirable according to Bob’s preferences • Sends the updated code for booking the new high speed train

9. A few observations • The creation of an high speed connection was not expected when the travelling application has been developed (or even when it was started) • Booking the high speed train may exploit a different protocol than booking other trains • If the old connection still exists, Bob may still want to use it (e.g., for price reasons)

10. How to implement this scenario? • Which kind of information about adaptation is required at application development time? • Difficult to adapt a black box (wrappers, …) • How can such an adaptation be specified? • How can those mechanisms be implemented in practice?

11. Roadmap • Dynamic adaptation • A rule-based approach • The JoRBA prototype • Conclusions

12. Our approach: main ideas • The application should provide an adaptation interface • A list of adaptable activities • And a few pieces of information about them • Adaptation is specified as a set of adaptation rules • One for each possible adaptation • External to the application • That can be created/modified after the application has been fully developed • Managed by an adaptation manager • Possibly implemented as a set of distributed adaptation servers

13. Our approach: an intuition

14. Our approach: an intuition

15. Adaptation interface • For each activity the adaptation interface should provide • A description of the activity • At least its name • Possibly its goal, a description according to some ontology, … • The set of variables that the activity uses to interact with the rest of the application • The non functional properties guaranteed by the current implementation • A comparator function allowing to compare two sets of non functional properties according to the user preferences

16. The Take Train activity • Description: Take Train • Variables: source (Bologna Train Station), destination (Trento Train Station), number (IC2356) • Non functional properties: time = 2h41m, cost = 20€ • Comparator function: new implementation is better if requires less time and each saved minute costs less than 0,3€

17. Adaptation rules • An adaptation rule specifies when, where and how adaptation will be performed • Implements adaptation logic • Each rule includes: • A description of the activity to be adapted • An applicability condition (involving the state of the environment and the public state of the application) • The updated code for the activity • The set of variables needed by the new code to interact with the rest of the application • A state update • A compulsory flag • The non functional properties provided by the new activity

18. High speed train rule • Description of the activity: Take Train • Applicability condition: number = IC2356 • Updated code: code for booking and taking high speed train • Variables: source, destination, number • State update: number = FR82 • Compulsory flag: false • Non functional properties: time = 1h23m, cost = 32€

19. Triggering adaptation • Adaptation can be either application-triggered or manager-triggered • Application-triggered approaches • On initialization • On wait • On activity enter • Manager-triggered approaches • On registration • At time intervals • On rule update

20. Checking for adaptation • The adaptation manager checks the matching between a rule and an activity • The two descriptions should match • All the variables needed should be available • The applicability condition should be satisfied • The compulsory flag should be true OR • The non functional properties provided by the new implementation should be better than the old ones according to the user defined preferences

21. Applying adaptation • If all the conditions are satisfied adaptation can be applied • The new code is sent from the adaptation manager to the application replacing the old one • The non functional properties are updated • The state update is applied

22. Roadmap • Dynamic adaptation • A rule-based approach • The JoRBA prototype • Conclusions

23. JoRBA • Jolie Rule-Based Adaptation framework • A proof-of-concept implementation of our approach including • A skeleton for adaptable applications • An adaptation manager • A skeleton for adaptation servers • Includes the implementation of the Travelling application • Is written in Jolie

24. Jolie • A language for programming service oriented applications • Developed by Univerisity of Bologna spinoff ItalianaSoftware s.r.l. • Implemented by a Java interpreter • Takes inspiration from • sequential languages (assignment, if-then-else, while, …), • concurrent calculi (parallel composition, …) • workflow languages (one-way and request-response communication patterns) • Has native mechanisms for implementing loosely-coupled interactions such as the ones between adaptation servers and adaptable applications

25. JoRBA architecture • JoRBA exploits service oriented architectures to implement adaptation • Adaptation managed by an AdaptationManager • Rules managed by distributed AdaptationServers • Applications can invoke the AdaptationManager to check for updates • Activities are externalized as services, and updated thanks to dynamic embedding • A state service provides support for the common state

26. JoRBA at work Demo time!!!

27. Roadmap • Dynamic adaptation • A rule-based approach • The JoRBA prototype • Conclusions

28. Summary • A novel approach for dynamic adaptation • Based on the interaction between adaptable applications and external adaptation rules • Very flexible framework • A prototype implementation in Jolie

29. Future work • Still lot of work to do on the framework • Descriptions of the activities • Treatment of compulsory updates • … • (Anyone interested in working on the implementation?) • Applying the approach to other languages • Lot of related topics to explore • Typing of rules and activities • Adapting ongoing activities • …

30. Finally Thanks! Questions?