Noah

Overview

Noah is a framework in which software entities can interact without knowing their interlocutors.
Indeed, the implantation code of entities does not need to reference others entities they interact with.
Interactions between components are described in a language independant way (via the Interaction Specification Language).
Noah can be thought as a dynamic aspect repository with a weaver using an aspect composition mechanism to ensure commutable and associative adaptations.

Noah service can actually manages the following types of component:

• Pure Java Object
• Java RMI components
• Jonas 2.5 EJB components
• Fractal components (new)
• Microsoft .NET components

Interactions : a need

The behavior of an object is influenced by the interactions (the inter objects communications)
and the constraints implied by these interactions. In a traditional approach,
taking the environment into account is realized within the objects. Thereby the interaction management, and their semantic, is not easy. In fact,

interactions are tangled in the object code that describes the intrinsic features of the latter and specify the classes, send messages to other objects directly from the method code orreference interacting objects by the way of attributes.
This implies an important change in the semantic of the objects and makes the maintenance and the extension of such a code
very hard.

Interaction properties

The rainbow project proposes to consider an interaction with a high abstraction level which defines an inter object communication. Interaction properties are :

• their dynamically aspect. An interaction can be defined at any time during the application runtime, the user can add or remove dynamically interactions.
• their autonomy. They are described outside the object code and can be used for several object groups.
• their abstraction. They preserve encapsulation. They are defined only upon the interacting objects interface.
• their independancy. Their specification is independent of the target object oriented environment.

Interactions have powerful local expression of behavioral dependencies between objects. Their management, based on the maintain of a local consistency, allows the global consistency of the interaction graph.

Interactions : a specification language with its programming environment

The goal is to consider the interaction specification independently of any existing language. So we defined the ISL language (Interaction Specification Language). ISL allows to easily describe the interactions. With this language the semantic of an interaction is described using rules. Each rule specifies, for a given message, the inter object communications to execute when the message is sent. To do this, the language provides 3 reactive operators, one for a synchronous sending message, one for an asynchronous sending message, and another for a "future" sending message (asynchronous sending message with answering assurance), and a conditional operator (to simulate guards). To increase the expression of the interaction rules, the ISL language allows to refine, in an incremental way, the interaction semantic by providing an inheritance mechanism. So, an interaction can inherit of the semantic of another interaction, i.e. the rules of the inherited interaction.
Programming environments generate target code in C++/Corba  (Micado), Java /RMI (JavaInt) and in Smalltalk or Distributed Smalltalk (DSTInt).
These developments are further developped in the language & implementation section, and are downloadable in the results one.

Interactions can also be presented like an aspect of object oriented languages, ISL generator as weavers.

Interactions : their history

The first work on interaction was an extension of a logical object oriented language (links in Othello). This first model has been extended in FLO. FLO allows to express reactivity and guards between objects, and to assiciate behavior and information to an interaction. In these solutions, interactions are in fact extensions of object oriented languages where interactions are first class objects. So, an interaction can also be an object participating to another interaction semantic. Thanks to the implementation of an interaction semantic upon others interactions, it is possible to obtain a global management of the interactions from a local definition of the latter. This way, we can express the behavior of composite objects, the addition of new behaviors or the introspection on the interactions themselves.
The project team experience in dependencies concept is presented in the chapter Objet et Dépendances of the book [INT97]