1. 1 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, 23-04-2005 MTCoord'05 Roles as Coordination Construct: Introducing powerJava M. Baldoni 1, G. Boella 1, L. van der Torre 2 1 Dipartimento di Informatica Università degli Studi di Torino 2 SEN3 – CWI Amsterdam and Delft University of Technology

2. 2 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, 23-04-2005 Data vs Control driven coordination ● Data-driven coordination (typical of OO): – computation evolves driven by the data involved in the coordination ● Control-driven coordination: – computation evolves according to events following state changes – Separation between coordination and computation (different processes) – Black-boxes with input/output interfaces – Dynamic reconfiguration

3. 3 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, 23-04-2005 Coordination in OO model ● The introduction of coordination components in OO presents some difficulties [Arbab] ● Asimmetry: the caller must know the callee (syntax and semantics of the invoked methods) ● The control is passed to callee ● The “pluggability” of pre- existing components in a new system is reduced Object B Object A Message

4. 4 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, 23-04-2005 Alternative view ● To use untargeted passive messages that do not imply method invocation ● For example by introducing channel ● The sender is not required to know the receiver a third party sets up the interaction between a sender and a receiver of its choice ● How to introduce this view preserving the OO characteristics? Object B Object A Message channel Message

5. 5 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, 23-04-2005 Aim of the work ● Coordination models often refer to some metaphor: Shared dataspace, Blackboard model, Actor model, Chemical model, Channel model,... ● Aim of this work: To introduce the “role metaphor” in OO programming (Java) for allowing control-driven coordination ● powerJava: A proposal of extension of Java with roles

6. 6 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, 23-04-2005 A proposal: the role metaphor ● It is a basic metaphor in social and organization theories ● Role often defined as the description of an expected behaviour ● Used to distribute responsabilities, obligations, and rights among the entities of an organization ● Playing a role means acquiring specific powers (given by the organization) ● For playing a role some requirements are needed ● Roles (as entities endowed with powers) are a means to coordinate the behavior within an organization

7. 7 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, 23-04-2005 Our notion of role ● Definitional dependence: the definition of a role must be given inside the definition of the its institution ● Foundation: an instance of a role must always be associated with an instance of the institution it belongs to (besides being associated with its player) ● Institutional empowerment: the role actions can access the state of the institution

8. 8 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, 23-04-2005 Use of roles ● Roles can be a means for improving the pluggability ● Simmetry vs asimmetry ● The institution and its roles play as the third party that controls the interaction ● The players will interact according to the acquired powers (they will follow the protocol implemented by the institution and its roles)

9. 9 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, 23-04-2005 Introducing roles in Java: powerJava ● We define roles as instances associated at runtime to objects (their players) ● The extension of objects to roles is transparent to the programmer ● The language is extended preserving the characteristics of the original language to make its use natural to the Java programmer ● The current implementation requires a preprocessing (by JavaCC) step to produce a pure Java program

10. 10 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, 23-04-2005 Introducing roles in Java ● A construct for defining roles as interfaces ● A construct that allows to implement a role inside an institution ● A construct to associate a role to an object ● A construct to allow a role to pass information to the players ● A construct to allow an object to play a role, i.e. to invoke the power

11. 11 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, 23-04-2005 Role as “double” interface ● Role specification – Requirements: the methods required to a class playing the role (the “pluggability”) – Powers: the methods offered to objects playing the role ● The use of interfaces increases the modularity and the component-based programming [Steimann] powers requirements interface PhilosopherReq { void putData(... ); void processData(); } role Philosopher playedby PhilosopherReq{ void eat(); void think(); }

12. 12 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, 23-04-2005 Role implementation as inner classes ● Role implementation – Java inner classes that implement the powers specified by the role definition – keyword “realizes” – keyword “that” ● A role implementation has access to the state of the institution (like inner classes w.r.t. outer classes) ● that is used to invoke methods (requirements) of the player role Philosopher playedby PhilosopherReq{ void eat(); void think(); } class Table { [...] class PhilosopherImpl realizes Philosopher { [...] public void eat() { [...] public void think() { that.processData(); }

13. 13 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, 23-04-2005 Role instance creation ● Roles: created similarly to instances of inner classes ● Implicit parameter of type “requirements” (the player of the role) ● Each role instance has a reference to the instance of its institution, like an instance of an Java inner class has a reference to its outer class (directly provided by Java compiler) interface PhilosopherReq { void putData(... ); void processData(); } class Consumer implements PhilosopherReq { public void putData(... ) { [...] } public void processData() { [...] } [...] Consumer consumer = new Consumer(); [...] Philosopher phil = new table.PhilosopherImpl(consumer); [...]

14. 14 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, 23-04-2005 Playing a role ● Role instances do not exist by themselves ● Role powers are invoked starting from the associated players ● Cast to a role: casting the player of a role to the role implementation instance it refers to (it is necessary to specify the institution the role belongs to) ● Delegation mechanism role Philosopher playedby PhilosopherReq{ void eat(); void think(); } [...] Consumer consumer = new Consumer(); [...] Philosopher phil = new table.PhilosopherImpl(consumer); [...] ((table.Philosopher) consumer).eat(); ((table.Philosopher) consumer).think(); ((table.PhilosopherImpl) consumer).myEat();

15. 15 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, 23-04-2005 Overview ● Overall model using a UML class diagram ● Translation in pure Java by means of a pre-processor built by JavaCC (http://www.powerjava.org)

16. 16 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, 23-04-2005 An example: dining philosophers ● Resource: requires a method for getting data ● Consumer: requires methods for receiving and processing data ● Table: the coordination environment ● Philosopher: offers to the consumer the method to eat (grabbing two resources and getting data), think (using data), start the process and leave the table ● Chopstick: offers the method for being used table resource consumer philosopher chopstick

17. 17 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, 23-04-2005 An example: dining philosophers ● The table is the coordination environment, coordination between resources and consumers is carried on through the roles ● Private methods for grabbing and realising chopsticks in a synchronized way ● Philosophers obtain chopsticks and use them table resource consumer philosopher chopstick

18. 18 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, 23-04-2005 An example: dining philosophers ● Use chopsticks becomes getting data from the resources (that.getData()), invocation of a method from role to player (resource) ● The philosopher passes the obtained data (that.putData(...)) to the consumer, and releases the chopsticks (resources) ● The philosopher comunicates to the consumer that it can now process the data (that.processData()) table resource consumer philosopher chopstick

19. 19 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, 23-04-2005 Summary of the example ● Sequence diagram of the dinning philosophers ● The coordination happens all inside the “table” throgh the roles table

20. 20 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, 23-04-2005 powerJava pre-processesing ● JavaCC (Java Compiler Compiler) using Java 1.4.2 grammar ● Role specifications are translated into interfaces ● Role implementations are traslated into inner classes whose constructors are extedend appropriately ● Players are modified in order to manage a list of roles ● Role casting is translated into an instruction that allows to find the corresponding roles inside its list (using the name of the role and the instance of institution), then delegating this object for the execution of the power

21. 21 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, 23-04-2005 Conclusions ● By roles we implement control-driven coordination in an OO language ● powerJava introduces roles in Java preserving the natural OO programming style (expecially for the use of interfaces) ● Type checking is demanded to the Java compiler ● On-going work: studying a notion of type for the role definition and implementation ● powerJava shares some features with Object Teams, Caesar, AspectJ, Traits, Mixins, its originality mainly stands in the use of interfaces, a key choice to support modularity and reuse