A SelfLet is a self-sufficient piece of software which is situated in some kind of logical or physical network, where it can interact and communicate with other SelfLets.
In general, the expected environment is indeed a distributed one, for example a wireless network of PDAs (each running a SelfLet) or a corporate network (with SelfLets being run on several machines), but several SelfLets could also run and intercommunicate on a single machine, thus behaving like interacting processes.
The SelfLet framework provides a set of means to specify the features of each SelfLet composing an autonomic architecture. The developer of such an architecture can indeed specify the behaviour of each single SelfLet in the network with respect to different aspects.
When deciding to develop a SelfLet, what is needed is the definition of the standard behaviour for each SelfLet, thus describing the tasks each SefLet should perform to achieve the service that has been assigned to it. The service is a description if what the SelfLet has been created for. Secondly, the developer can complete the definition of the behaviour, coding the actions, defining in the XML the conditinos that label the transitions in the behaviour. Then, the developer can implement the abilities, i.e., the lower level activities performed by the SelfLet. These are independent, modular pieces of code that can be easily installed on a SelfLet. Finally the developer can freely customise the provided set of policies to define the reactions to events that are not included within the standard behaviour designed.
In the following figure we give an idea of the internal architecture of a SelfLet.
The main component of the architecture is represented by the AutonomicManager that is responsible for the evolution of a SelfLet on the basis of the set of Autonomic Policies defined for the SelfLet. Such set could evolve over the time. Beside the AutonomicManager, the BehaviourManager controls the execution of the SelfLet's behaviour. When a request for a service arises, the AutonomicManager triggers the execution of a rule that verifies whether the service is locally available. If the service is not available it asks the NegotiationManager to retrieve the Service and negotiate with the corresponding SelfLet a proper offer mode.
The InternalKnowledge is composed of four parts: Knowledge Base (used to store and retrieve any kind of information needed by th SelfLet components), Service Repository (it lists the services SelfLet is able to offer), Behaviour Repository (used to contain all the behaviour the SelfLet is able to run) and the Attribute Repository (used to store the description about the SelfLet).
Other components of the architecture are the Ability Execution Environment (in charge of executing the Abilities), the Perfomance Manager (providing the functionalities to monitor the execution), the Dispatcher (in charge of receiving the subcription or publications event needed to enable the communication among SelfLets) and the Message Handler (in charge of managing the communications through the REDS middleware). Morever a further component is the Prediction Manager allowing the SelfLets autonomic policies to be activated not only when something happens but even when the probability that something will happen is high.
Which are the main features of a SelfLet?
SelfLet are defined by means of
A developer who wants to develop a SelfLet based application have to define the required features characterizing a SelfLet. To support the developer during such process, an Eclipse plugin (SelfLetClipse) is available at http://selfletclipse.sourceforge.net/.
The source code can be found here: https://sourceforge.net/projects/selfletclipse/files/downloads/SelfLetClipse_1.0.0.zip/download.
For any request or to signal a bug send and email to: calcavecchia |AT| gmail |DOT| com