Consistency Management in the Presence of Dynamically Scoped Adaptations Eddy Truyen and Wouter Joosen DistriNet Dept. of Computer Science, Celestijnenlaan 200A, 3001 Leuven
[email protected] February 23, 2009 Abstract Ensuring that software can display different behavior in different use contexts requires adapting software at runtime in dynamically created scopes (e.g. in a thread, in a client session, in a collaboration). ContextOriented Programming (COP) offers dedicated language constructs for performing such dynamically scoped adaptations. COP supports powerful customizations such as concurrent customization where independent clients can concurrently customize the functionality of a shared component, and system-wide customizations that cross technical boundaries. However, like any dynamic software adaptation technique, COP hits a conceptual barrier when new variations of existing program entities are integrated into a running system: if applied uncarefully, dynamically scoped adaptations may lead to faulty behavior especially when layer activation occurs at stages where the affected system components themselves are in a transitional, inconsistent state. Inherently, the ways of managing state consistency is highly specific to the application at hand and therefore requires additional application-specific logic from the system itself. What is needed is a consistency management framework that guides the programmer in specifying this application-specific logic in a principled way.
1
Flavors of context-oriented programming
Many COP languages exists to date. Althoug there may be different flavors of COP, a common goal of most COP languages is to enable activation of layers of behavior in a specific dynamic scope of the program, in parallel with other dynamic scopes of the program. For example, our research platform Lasagne [7] supports per-client request activation of aspectual layers. This allows different clients to customize the same component instance in parallel. Looking further however at the different flavors of COP, it can be seen that at least two types of dynamically scoped adaptations are supported [2]: loyal adaptations where layers, once activated, are continously activated in their current dynamic scope, versus prompt adaptations where layers can be flexibly activated and deactivated in the same dynamic scope. For instance, Lasagne is a loyal COP language. The notion of per-request activation implies that the 1
selected layers are loyally executed during the complete processing of that client request across the system.
2
Consistency management
An important issue in COP is to understand what type of layer activations can be tolerated by the system without yielding incorrect program states. For example, layer activation may occur at stages where the affected system components themselves are in a transitional, inconsistent state. This remains a critical consistency issue even in the face of loyal activations, especially in distributed systems. For example, dynamic deactivation of a message fragmentation feature in an instant messaging service may induce undesired reorderings of message sends. This causes a problem if the messaging service has promised ordered and reliable text messaging in its service-level agreements. Another example is when the fragmentation layer is deactivated ‘in the middle’ of processing, this leads to message omissions because messages get fragmented but these fragments are never properly reassembled. In Lasagne, this issue is currently dealt with by a consistency management framework [6, 8] that enforces an architectural style onto the applications. This architecture style basically puts two kinds of restrictions on the application’s structure and behavior: (i) restrictions wrt the type of operations layers can perform (e.g. no updates of externally dependent state) and (ii) restrictions about when layers may be activated (e.g. only at the start of new transactions). Moreover, explicit deactivation of layers is forbidden. This solution of enforcing an architectural style is a robust solution that works in all cases but is too rigid in some cases. In particular, it probibits a range of useful adaptations such as the prompt adaptations mentioned above. Moreover, layers that update persistent state (e.g. updating the balance of an BankAccount object) are forbidden by Lasagne’s consistency management framework, while it is clear that such adaptations may be useful in many application scenarios.
3
Reflective design of a generic consistency management framework
In order to overcome these limitations, we believe that the way of preserving system consistency should be an application-specific endeveaour. In other words, not a “one-size-fits-all” solution should be hardcoded inside the consistency management framework. Instead, the consistency management framework needs to offer a set of abstractions that can be used to express applicationspecific policies for dealing with state inconsistencies. It is currently not well understood what are the right set of abstractions that enable the application developer to reason about the consistency of the system in the presence of dynamically scoped adaptations. Existing research on dynamic software reconfiguration [4, 5, 1, 3] has proposed reusable abstractions for coordinating dynamic software adaptations in global scopes (i.e., all processes in a system or subsystem are affected). However, no principled reconfiguration model exists for dynamically scoped adaptations (i.e., where a
2
single thread or a single session is affected). Moreover the design of a generic reconfiguration model that subsumes loyal as well as prompt adaptations is an outstanding challenge. The realization of such generic consistency management framework on top of a COP language is typically most easy to achieve if the COP language has a reflective architecture. The reification of the abstractions through reflection enables then the programmer to write application-specific metaprograms that can exercise the appropriate forces for keeping the running system in a consistent state. We are interested to discuss at the workshop what are the right set of abstractions and how to reify these as a meta-interface for COP languages.
References [1] Jo˜ ao Paulo A. Almeida, Maarten Wegdam, Marten van Sinderen, and Lambert J. M. Nieuwenhuis. Transparent Dynamic Reconfiguration for CORBA. In Proceedings of DOA 2001, Rome, Italy, 2001. [2] Brecht Desmet, Jorge Vallejos, Pascal Costanza, and Robert Hirschfeld. Layered design approach for context-aware systems. In Klaus Pohl, Patrick Heymans, Kyo Chul Kang, and Andreas Metzger, editors, VaMoS, volume 2007-01 of Lero Technical Report, pages 157–165, 2007. [3] Nico Janssens, Wouter Joosen, and Pierre Verbaeten. NeCoMan: Middleware for Safe Distributed-Service Adaptation in Programmable Networks. IEEE Distributed Systems Online, 6(7), 2005. [4] Jeff Kramer and Jeff Magee. The Evolving Philosophers Problem: Dynamic Change Management. IEEE Trans. Softw. Eng., 16(11), 1990. [5] Kaveh Moazami-Goudarzi. Consistency preserving dynamic reconfiguration of distributed systems. PhD thesis, Imperial College, London, 1999. [6] E. Truyen, B. Vanhaute, W. Joosen, and P. Verbaeten. Consistency management in the presence of simultaneous client-specific views. In Proceedings of the International Conference on Software Maintenance (ICSM’02), pages 501–510. IEEE Computer Society, 2002. [7] E. Truyen, B. Vanhaute, W. Joosen, P. Verbaeten, and B. Nørregaard Jørgensen. Dynamic and selective combination of extensions in componentbased applications. In Proceedings of the 23rd International Conference on Software Engeneering (ICSE’01), pages 233–242. IEEE Computer Society, 2001. [8] Eddy Truyen and Wouter Joosen. Run-time and atomic weaving of distributed aspects. Transactions on Aspect-Oriented Software Development II, 2006.
3
