Section 31.5. WEAVING ASPECTS IN A COMMUNITY OF NODES

31.5. WEAVING ASPECTS IN A COMMUNITY OF NODES

31.5.1. Aspect Distribution

In the production hall scenario, we want to weave aspects at runtime through several nodes accessible through the local networks (fixed or mobile).

For this purpose, we distinguish two roles for nodes. Aspect base nodes contain a database of aspects. They discover new nodes joining the network and send aspects to the newcomers. Aspect receivers carry the component that receives aspects from aspect bases. We assume that each aspect receiver has PROSE activated on its JVM. When it obtains an aspect from an aspect base, it immediately inserts the aspect using the PROSE API. Aspect receivers also discard aspects when they leave a network or lose contact with the aspect base.

By appropriately assigning aspect base and aspect receiver roles, one can achieve adaptations of various service communities. At one extreme, each node can contain an aspect base. When it joins a new community, it distributes its aspects and receives others from the existing nodes. This type of organization is appropriate for creating an application-aware system infrastructure in entirely ad-hoc communities. At the other extreme, each physical location (e.g., a production hall) may have a base station as aspect base. All other nodes (e.g., the mobile nodes) are aspect receivers. This organization is appropriate for adaptations that correspond to infrastructure and organizational requirements. Between the two extremes, many other configurations are possible.

31.5.2. Lifecycle of Aspects

Application awareness must be designed for device mobility. This requirement implies that aspects must transiently adapt a service (for as long as the service is working in a given network). To model this behavior, the aspects must be leased to each node (i.e., to the adaptation service of a node). It is the responsibility of each aspect base to keep alive the functionality it has distributed among nodes. When a node leaves a given space, the leases on the aspects acquired in that space fail to be renewed, and corresponding aspects are revoked. Each aspect sender keeps track of its aspect activity (what nodes where adapted at what point in time) and may implement a simple roaming algorithm to deal with nodes migrating between areas.

31.5.3. Software Architecture Issues

Aspects range from service-generic to fully service-customized. For generic aspects, no specific information on services implementation is needed. For instance, one can replace the communication layer of a service with a new one that encrypts data without any particular knowledge of the adapted service. Specific adaptations may require either a black-box view (information on particular interfaces) or glass-box view (knowledge on how a service is implemented) of the service to be adapted. We assume that each aspect base has many aspects ranging from generic to service-specific. This approach, also followed by [17], accommodates incremental evolution of the software at every node (because generic aspects still work even if the node application has changed).