Vrije Universiteit Brussel Composable Actor Behaviour Van Den
Total Page：16
File Type：pdf, Size：1020Kb
Vrije Universiteit Brussel Composable Actor Behaviour Van den Vonder, Sam; De Koster, Joeri; De Meuter, Wolfgang Published in: Distributed Applications and Interoperable Systems DOI: 10.1007/978-3-030-22496-7_4 Publication date: 2019 Document Version: Submitted manuscript Link to publication Citation for published version (APA): Van den Vonder, S., De Koster, J., & De Meuter, W. (2019). Composable Actor Behaviour. In J. Pereira, & L. Ricci (Eds.), Distributed Applications and Interoperable Systems (pp. 57-73). (Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics); Vol. 11534 LNCS). Springer Cham. https://doi.org/10.1007/978-3-030-22496-7_4 General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. • Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain • You may freely distribute the URL identifying the publication in the public portal Take down policy If you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediately and investigate your claim. Download date: 05. Oct. 2021 Composable Actor Behaviour Sam Van den Vonder, Joeri De Koster, and Wolfgang De Meuter Vrije Universiteit Brussel, Pleinlaan 2, 1050 Brussels, Belgium {svdvonde,jdekoste,wdmeuter}@vub.be Abstract Code reusability is the cornerstone of object-oriented pro- gramming. Reuse mechanisms such as inheritance and trait composition lay at the basis of a whole range of software engineering practices with the goal to improve software quality and reliability. In this paper we investigate code reuse mechanisms for actors, and find that it is cur- rently difficult to specify the behaviour of an actor out of reusable parts. We discuss different kinds of code reuse mechanisms in different kinds of actor model, and we motivate why these mechanisms are currently unsatisfactory. As a possible solution we define a new reuse mechanism based on delegation-based trait composition. In a nutshell, the mechan- ism allows programmers to compose the behaviour of actors, and every time a compound behaviour is spawned into an actor, it will cause mul- tiple actors to be spawned (one for each independent behaviour). Some messages will be automatically delegated to the actor that implements the desired functionality. We provide an implementation of this model in a prototype Active Object language called Stella, and we formalise a sub- set of Stella using a small-step operational semantics to unambiguously define the different steps involved in our reuse mechanism. Keywords: actors · delegation · active objects · code reusability 1 Introduction In object-oriented programming, the principle of “programming against an in- terface” helps to foster code reuse and reduce complexity, thus increasing the reliability of individual components [20]. Essentially it is beneficial for the over- all complexity of the program to design components as black boxes, because it is then the sole responsibility of each individual component to ensure the func- tionality it offers through its interface is correct. This principle manifests itself in many reuse mechanisms, such as inheritance [15] and trait composition [12] for class-based languages, and delegation for prototype-based languages [19]. In actor-based programs, using components as black boxes is equally important but for reasons other than just modularity and code reuse. The behaviour of an actor is usually a combination of its internal state and its interface, which is the set of messages that an actor can process [18]. The only way to communicate with an actor is to send it a message that matches an entry in its interface, which is important for two reasons. First, it makes it easier for actors to protect their internal state from race conditions via interface control [17] (essentially by asynchronously processing messages one by one). 2 S. Van den Vonder et al. Second, a message-passing communication model is beneficial for (among others) concurrency, fault tolerance, and distribution over a network. Despite the principle of “programming against an interface” being ingrained in the actor model almost by definition, it is rarely leveraged to facilitate mod- ularisation and code reuse among actors. More specifically, currently there is limited language support for composing the behaviour of an actor, i.e. its inter- face, out of reusable parts. Since code reuse is an important aspect of software engineering, we argue that actor-based programs can benefit from a simple and well-defined code reuse mechanism to control and reduce their complexity. To this end we introduce Stella, a prototype language that implements an actor composition mechanism based on asynchronous message delegation. The main contributions of this paper are the design and definition of Stella, and a formalisation of a subset of Stella that captures the precise semantics of the reuse mechanism. In Section 2 we discuss the requirements of a suitable code reuse mechanism for actors, and we discuss reuse mechanisms in a number of state-of-the-art actor languages. In Section 3 we define Stella, and in Section 4 we define an operational semantics for a subset of Stella. 2 Code Reuse in Actor-Based Languages Before we look into existing reuse mechanisms, we define the term actor behaviour and we specify the requirements of a reuse mechanism suitable for actors. We adopt the terminology of [18] that defines the behaviour of an actor as the description of its interface and state. The interface defines the list (and possibly types) of messages that an actor can process, as well as the program logic to process them. The state of an actor is defined as all the program state that is synchronously accessible by the actor. From a software engineering point of view it is beneficial to split up a mono- lithic behaviour into multiple “reusable components” that can be composed using a composition mechanism. We devise 2 goals or requirements for such a mech- anism that is suitable for the actor model, which we base on well-established design principles for object-oriented programming [24, Chapter 14]. Extensibility. The interface of behaviours can be extended to accept new mes- sages, and a behaviour can specialise the acquired components to adapt them to its own needs. Relating this to object-oriented programming, this is similar to how a class can add, override, and specialise methods of a superclass, or to how traits can add methods to a class which may also be further specialised. Reusability. Pre-existing behaviours can be reused by extending, adapting or specialising them via new behaviour definitions, without modifying the original behaviour. In object-oriented programming this is similar to how a class may be specialised via subclassing, while it remains independently instantiatable regardless of new class definitions that rely on it. Composable Actor Behaviour 3 Over the years a number of reuse mechanisms have been proposed in different kinds of actor languages that implement different kinds of actor model. In the fol- lowing sections we discuss inheritance, trait composition, function composition, and reuse via prototypes in the Communicating Event-Loops model. 2.1 Inheritance The relation between inheritance and concurrent object-oriented programming has been thoroughly researched. Part of this research is focussed specifically on inheritance in actor-based languages such as Act3 [4] and ACT++ [16], which are based on the work of Agha [3]. In these languages, a become statement (fundamental to the model) is used to replace the behaviour of the current actor with a new behaviour. This statement causes severe reusability issues due to the Actor-Inheritance Conflict [17]. Consider a behaviour as being similar to a class, then the conflict describes a fundamental issue where adding a new method to a subclass may invalidate many superclass methods. Classes in combination with inheritance fulfil the requirements of extensibility and reusability. However, inheritance is known to have reusability issues when used as the sole reuse mechanism [12]. Furthermore, nowadays it is generally accepted as a good design principe in object-oriented programming to favour object composition over class inheritance [7, 14]. For these reasons we do not consider inheritance by itself to be a suitable reuse mechanism for actors. 2.2 Trait Composition The Active Objects model is based on the work on ABCL/1 [27], and has modern implementations in languages such as Pony [9] and Encore [8]. Here, actors are typically instances of an active object class which describes mutable fields and a set of methods that can be asynchronously invoked via message passing. Pony and Encore support neither a become statement (which caused the Actor- Inheritance Conflict from the previous section) nor reuse via inheritance. In the case of Pony it is mentioned that composition is preferred to inheritance [1]. Instead of inheritance, Pony and Encore support stateless traits [12]. Traits can be composed with behaviours and other traits to add new methods to the composer. However, they do not fulfil our 2 requirements. Extensibility is only partially fulfilled because, while traits can be used to extend a behaviour with new functionality, they have a number of drawbacks. Most notably, stateless traits are likely to be an incomplete implementation of some functionality unless it is completely stateless [6]. The follow-up work on stateful traits also has some drawbacks such as possibly breaking black-box encapsulation, and difficulties regarding a linear object layout in memory [6]. Reusability is unfulfilled because the trait composition mechanism cannot be used to compose behaviours.