Main Concepts

The main concepts of DEECo are heavily inspired by the concepts of the SCEL specification language. The main idea is to manage all the dynamism of the environment by externalizing the distributed communication between components to a component framework. The components access only local information and the distributed communication is performed implicitly by the framework. This way, the components have to be programmed as autonomous units, without relying on whether/how the distributed communication is performed, which makes them very robust and suitable for rapidly-changing environments. The key DEECo concepts are:

##Component A component is an autonomous unit of deployment and computation, and it consists of:

• Knowledge
• Processes

Knowledge contains all the data and functions of the component. It is a hierarchical data structure mapping identifiers to (potentially structured) values. Values are either statically typed data or functions. Thus DEECo employs statically-typed data and functions as first-class entities. We assume pure functions without side effects.

Processes, each of them being essentially a "thread", operate upon the knowledge of the component. A process employs a function from the knowledge of the component to perform its task. As any function is assumed to have no side effects, a process defines mapping of the knowledge to the actual parameters of the employed function (input knowledge), as well as mapping of the return value back to the knowledge (output knowledge). A process can be either periodic or triggered when (a part of) its input knowledge changes.

Currently, we envision to employ the single-writer paradigm (i.e., readers - writers), meaning that at any time each value in the knowledge of a component has at most one writer while it can have multiple readers.

##Ensemble Ensembles determine composition of components. Composition is flat, expressed implicitly via dynamic involvement in an ensemble. An ensemble consists of a single coordinator component and multiple member components. Two components can communicate only if they are in the same ensemble and one of them is the coordinator of the ensemble. Therefore, the definition of an ensemble is described pair-wise, defining the cuples coordinator - member. A component can be in multiple ensembles (this will be described in more detail later). An ensemble definition consists of:

• Required interface of the coordinator and a member
• Membership function
• Mapping function

Interface is a structural prescription for a view on a part of the component's knowledge. An interface is associated with a component's knowledge by means of duck typing; i.e., if a component's knowledge has the structure prescribed by an interface, then the component reifines the interface. In other words, an interface represents a partial view on the knowledge.

Membership function declaratively expresses the condition, under which two components represent the pair coordinator-member of an ensemble. The condition is defined upon the knowledge of the components. In the situation where a component satisfies the membership functions of multiple ensembles, we envision a mechanism for deciding whether all or only a subset of the candidate ensembles should be applied. Currently, we employ a simple mechanism of a partial order over the ensembles for this purpose (the "maximal" ensemble of the comparable ones is selected, the ensembles which are incomparable are applied simultaineously).

Mapping function expresses the implicit distributed communication between the coordinator and a member. It ensures that the relevant knowledge changes in one component get propagated to the other component. However, it is up to the framework when/how often the mapping function is invoked. Note that (except for component processes) the single-writer rule applies also to mapping function. We assume a separate mapping for each of the directions coordinator-member, member-coordinator.

The important idea is that the components do not know anything about ensembles (including their membership in an ensemble). They only work with their own local knowledge, which gets implicitly updated whenever the component is part of a suitable ensemble.