Mapping PASSI to Rolex...authors were lost!

WARNING: I believe that a scientific contribution should always be discussed.
This could not be the right place to discuss it, but it could be a starting point.
The following blog entry discusses a paper on a system I designed and developed that is, in my opinion, wrongly adapted to provide a scientific contribution I don't agree with.
Please remind that all opinions expressed here are on my own.

As the main designer and developer of RoleX (aka BlackCat), a Java framework for dynamic role injection thru run-time bytecode manipulation, I cannot express positively about the paper "Mapping PASSI and RoleX". Such article in fact presents a description of RoleX that is almost wrong, and therefore I don't believe that the conclusions this paper presents are scientifically valid.

Such paper, written within the MENSA project (a multi-university project)

should have been written with a stricter description of RoleX and of the design/aim of the latter.

Having read a work in progress draft in the beginning of 2008, before the final paper was published, I claimed about several errors in the RoleX description, but I see authors did not fix the paper. If authors asked me for an explaination of those concepts of RoleX that are still not clear to them, I surely provided all the required details.

It seems to me that the paper is trying mapping apples to oranges, nevertheless it has been succesfully published to the 2nd International Symposium Agent Based Modeling and Simulation, the 19th European Meeting on Cybernetics and Systems Research (EMCSR 2008), and this also means not all the paper is wrong. Let's say it is a nebolous paper to me.

Interested readers should read [1] before continuing, in order to acquire needed RoleX background.

General Discussion
The paper proposes an interesting aim: mapping the RoleX implementation to the PASSI methodology. This is surely interesting and challenging, but it must stand out on a clear RoleX background and experience, as well as a PASSI knowledge able to cover lacks in the former or the latter and how to overtake migration and integration issues.

The Rolex Meta-Model
The RoleX meta model described on section 2.2 has several errors, most of them clearly visible in Figure 2. First of all, from Figure 2 it is possible to note how a RoleDescriptor is composed by one or more ActionDescriptor and one or more EventDescriptor. This is not correct, since as it is possible to see from [1], Figure 5, where it is clearly shown how descriptor are nested. Authors seems to have reported a distorted version of [1], Figure 6, where it is shown how an EventDescriptor can be embedded directly into a RoleDescriptor, even if no ActionDescriptor is provided for it. Nevertheless, the important thing is that the descriptor are usually nested (RoleDescriptor contains ActionDescriptor that contains EventDescriptor), with the exception that a RoleDescription can directly contain one or more EventDescriptor. Instead from the Figure 2 only such exception is possible.

Another interesting mistake is about the association between a Role and its descriptors. From Figure 2, it appears that a Role has a RoleDescriptor, and that is true, but it is not as depicted in Figure 2. First of all, a Role and a RoleDescriptor are not tied in any way. The agent works always using RoleDescriptors and never using Roles, and this is visible in code snippet of [1], Figure 17, where the agent searches for and assumes a role only thru its descriptor. The adoption of descriptors is better explained in [2]:

The descriptors are useful also for hiding to the agent the physical
location of the role implementation, allowing agent programmers
to disregard about the work of role programmers, and viceversa,
because the role behavior is described in a separate way.

Here the key is role implementation hiding: in order to allow an agent to use the role only thru the injection mechanism, RoleX does not allow an agent to get (and instantiate) a role implementation directly. In other words, the Role Repository keeps the role implementation hidden, exposing only the RoleDescriptors, that are not tied to the role implementation in any way. In fact, it is the Role Repository that knows each descriptor to which role is tied and not, as suggested in Figure 2, a role that knows its descriptor. More details on the adoption of descriptors and role repository can be found in [3] and [4].

A close look to Figure 2 emphasizes another embarassing detail: a role class has a navigable link to a role descriptor, and that is not true. Roles and descriptor are developed separately and are kept separate untill they are installed in the system. Installing a role in the system means that the role repository keeps information about a role and its descriptor. This also means that the role repository is the only component that, at run-time, contains a binding between a role and its descriptor. Thanks to that, it is possible to install the same role several time with different descriptors, or even to substitute a role behind a descriptor, and so on.

Now, having a look at older papers about RoleX, it is clear that a class diagram such as that of GFigure 2 has never been depicted. The reason is simple: RoleX is a dynamic framework, and being dynamic means that a lot of bindings are resolved only at run-time and through connection components (e.g., the role repository above). Therefore, it does not make any sense at all showing a static class diagram to glance at a dynamic system.

But section 2.2 lies on the RoleX role definition itself, and in fact it states that:

In RoleX, a role is defined as a set of actions that an agent playing such role can perform to achieve its task, and a set of events that an agent is expected to manage in order to “behave” as requested by the role it plays.

That's not true, since the action-event definition is specified in the BRAIN framework and not in RoleX! In fact, in [5] section 2.1 there is the declaration of the BRAIN role model:

In BRAIN, a role is defined as a set of capabilities and an expected behavior. The former is a set of actions that an agent playing such role can perform to achieve its task. The latter is a set of events that an agent is expected to manage in order to “behave” as requested by the role it plays.

As stated later in [5], RoleX is just one of the available implementation of BRAIN, and thus it is compliant to such role model. Not only the authors confuse BRAIN and RoleX, but they ignore the RoleX role definition, that being compatible with the BRAIN one, is expressed in [1] as:

Defining a role as a few classes and interfaces

It's now time to see how the authors describe the invocation translator:

The use of descriptors means that the programmer cannot write code that invokes methods corresponding to role actions in the usual way, because a compile-time error will occur. Therefore, there must be an invocation translator that do introspection on the extended agent to dynamically find which method must be called in response to an invocation on an action description.

The above seems a raw cut-and-paste of different articles and concepts. The fact is this (see [1], Figure 4 and description on page 190): when RoleX performs bytecode manipulation, it injects into an agent new members (the role members). It is clear that the agent has now new methods and properties, that before the role injection it didn't have. For this reason, the programmer cannot invoke directly the new methods because they are not present at compile time and because it does not know them directly (the role implementation is hidden). For this reason, the agent have to perform introspection to get knowledge of the new members and to use them. It is only to simplify such introspection process, and to complete the adoption of descriptors, that the invocation translator exists, and in fact it allows to:

1. access an added member without having to adopt introspection;
2. execute an action starting from its descriptor, and thus without the needing to know which action to execute.

It is thus clear that (i) the presence of an invocation translator is not a must (an agent can perform introspection by its own) and (ii) the invocation translator is not a consequence of the adoption of role descriptor, but rather a feature that helps programmer using descriptors.

Mapping PASSI to RoleX

Section 3 of the article shows the concrete mapping between PASSI and RoleX. Having provided readers with an almost totally wrong definition of RoleX, the mapping cannot not be correct, and in fact there are several mistakes. Let's start from Table 1, where PASSI concepts are mapped 1:1 to RoleX ones. First of all, it is worth noting how RoleX does not have a concrete action, but only a concrete action descriptor. As described before, the action concept derives from BRAIN, while RoleX implements it only by means of action descriptors. It is therefore incorrect to map the PASSI agent action to a RoleX action, while it is correct to map the former to a RoleX action descriptor (as the authors partially do).

Authors identify a PASSI service with the event handling mechanism of BRAIN/RoleX, and this is not fully correct. In fact, even if it is true that an incoming event can represent a service request, RoleX injects into agents role members, that can be accessed (if publicly available) from other agents. In other words, a role service could be also an OOP-method injected into an agent, therefore a PASSI service should be mapped both on event handling and role methods (or better action descriptors).

Finally, it is almost wrong the mapping between a PASSI goal and a RoleX role descriptor. First of all, a role (and its descriptor) is not a goal in RoleX, rather an enabler to achieve one or more goals. It is clear that a role cannot be a goal in RoleX also for the external visibility: a role has a set of static properties, such as its exeternal visibility that allows another agent to know which role an agent is playing simply "watching" at it. How can it be expressed as a goal? A goal is something that an agent should actively achieve, and thus it can be specified by actions, as stated in [5]:

In BRAIN, a role is defined as a set of capabilities and an expected behavior. The former is a set of actions that an agent playing such role can perform to achieve its task.

It is therefore clear that a role, in RoleX, is not a goal, rather a goal container, since it contains actions that can be used to achieve goals. Moreover, to achieve a goal, the actions could be serialized into one or more sequences, that is not imposed in any way in RoleX. This, again, specifies how a RoleX role cannot be a goal. It is interesting to note that the authors themselves recognize this, in contrast to Table 1, stating that:

One of the major drawbacks of RoleX is that it fails in defining goals (or tasks in PASSI terminology). Actually, the goal is distributed in the role descriptors, but there is not a way to directly define it.

This sentence must be analyzed very well. First of all, it is not RoleX's fault if the definition of goal is scattered within a role descriptor, since this is the definition that comes from BRAIN. It is worth noting, at this point, that while BRAIN does not include a definition of goal anywhere, RoleX does. In fact, as shown in [6] Figure 5, each kind of descriptors include an aim specification, that can be used to specify the goal of the element. In particular, applying the aim to action descriptors, we can express the goal of each action.

It's now time to examine the context element, that even if virtually available in RoleX, does not find any concrete implementation, and in fact is not either specified in the XRole schema definition (see [6]). So, the mapping between the PASSI scenario and the RoleX context cannot be possible, being the latter not present at all. This should be listed in the last paragraph of section 3, that explains which concept do not have a 1:1 mapping.

With regard to such last paragraph, it is interesting noting that the role repository should not be listed there. In fact, each role approach could have a way to list and provide roles to agents, and the role repository is, after all, doing that. So, while it is true that the adoption of the repository is an implementation issue, it is also true that PASSI is lacking modeling it and that a lot of other role approaches have their kind of role library.

What is the key point authors missed?

In my opinion, this article is wrong even in the title. Authors are trying to map a methodology (PASSI) over an implementation (RoleX), and there's nothing wrong with that. But they discard that RoleX is compatible with another methodology, that is BRAIN. So, before showing how PASSI could be mapped on RoleX, they should demonstrate that PASSI and BRAIN can coexist and can be mapped each other, or at least that RoleX has so many implementation details that go out of bounds of BRAIN and that can be used in PASSI.

Having that, it is possible to demonstrate and convince readers about the PASSI to RoleX mapping.

REFERENCES

1 CABRI, FERRARI, AND LEONARDI, Injecting roles in Java agents through runtime bytecode manipulation, IBM SYSTEMS JOURNAL, VOL 44, NO 1, 2005

2 Cabri, Ferrari, Leonardi, Enabling Mobile Agents to Dynamically Assume Roles, The 2003 ACM International Symposium on Applied Computing (SAC), Melbourne, Florida, USA, March 2003

3 Luca Ferrari, master degree thesis (december 2002), "Middleware per agenti mobili con interazioni event-driven basate su ruoli e tecnologia XML"

4 Luca Ferrari, PhD thesis (February 2006)

5 Cabri, Ferrari, Leonardi, Supporting the Development of Multi-Agent Interactions via Roles, The International Workshop on AGENT-ORIENTED SOFTWARE ENGINEERING (AOSE-2005)

6 Cabri, Ferrari, Leonardi, Exploiting Run-Time Bytecode Manipulation to Add Roles to Java Agents, Science of Computer Programming, (Elsevier, Amsterdam-NL), Vol. 54, No. 1, pp. 73-98, January 2005 ISSN: 0167-6423