Framework for Dynamic and Automatic Connectivity in Hierarchical - PDF document

Framework for Dynamic and Automatic Connectivity in Hierarchical Component Environments G´ abor Paller Nokia Research Center, K¨ oztelek str. 6, Budapest, 1092, Hungary, email: gabor.paller@nokia.com Abstract must configure and reconfigure itself under varying (and in the future, even unpredictable) conditions.” All these prob- lem statements lead to dynamic architectures. Component frameworks have been receiving continuous Today the research scene is dominated by dedicated attention in the last decade. Dynamic component-based reconfiguration managers that listen to context changes composition plays central role in the area of reflective soft- and adapt the target software configuration accordingly ware where the structure of the application and the sup- porting middleware can be changed during the execution [3],[4],[5],[8]. The event-conditions-action pattern is fre- to adapt the software to environmental changes. Selection, quently used and the action part is often described by some instantiation and wiring of the components are generally script that reconfigures the component network. [15]. Some the tasks of “reconfiguration managers” that are able to in- approaches allow for the fine-tuning of the rule-set by learn- terpret context changes and to create the appropriate com- ing [9] but the rule-set is still enforced by the dedicated con- ponent network. This centralized approach is not satisfac- figuration manager. tory for more complex systems because the reconfiguration The vision of the Dynacomp framework presented in managers must be aware of all the relevant context combi- this paper is an architecture that automatically rearranges nations and the relationships to component configurations. the components according to component constraints when Even in hierarchical component networks the complexity of a component instance is inserted, removed or its constraints reconfiguration managers could quickly get out of control are changed. There is no specialized reconfiguration man- as the number of components and context states grow. ager, the introduction of a component into the component This paper proposes a more distributed approach for network is enough in itself to trigger reconfiguration. Simi- dynamic, hierarchical component composition where com- lar systems have already been presented, e.g. [11] and Ser- vice Binder [13]. These systems, however, are able to work ponents themselves influence component instantiation and in non-hierarchical component frameworks only and in Ser- wiring. The proposal is based on an analogy with biological vice Binder ambiguity resolution is inadequate. cell transfer processes. The paper presents this approach The Dynacomp framework overcomes these limitations. and demonstrates its use on a Fractal-based demo imple- Dynacomp differs from Service Binder in the following fun- mentation motivated by a mobile application use case. damental ways: • Richer meta-information attached to components that 1. Introduction allows them to influence the reconnection process more precisely. Systems that change their architectures dynamically • Ability to work in component hierarchies. emerged during the analysis of many domains. Reflec- Dynacomp components can also be compared to tive middleware [2],[7] identified the need for such sys- classpects [14] of the aspect-oriented world. Like tems for middleware serving applications in dynamically classpects, Dynacomp components are self-contained be- changing environments. It was pointed out that dynamic cause the functionality of the components and the way the architectures can be efficiently used for self-healing/self- component changes its environment are combined into one management systems [4]. The relationship between reflec- unit. The fact that component frameworks may be used tive systems and self-healing systems was analyzed in [6]. to implement aspect-like behavior has already been pointed One main objective of IBM’s Autonomic Computing initia- out in [16]. tive 1 is the following: “An autonomic computing system Dynacomp’s support of hierarchical component archi- 1 http://www.research.ibm.com/autonomic/ tectures is important because the number of connections 1

is lower in component hierarchies therefore the automatic connection can finish faster (see appendix for discussion). Dynacomp was inspired in many ways by the internal processes of a biological organism. Similarly to biological organisms, components are arranged hierarchically. Com- ponents can be created and destroyed continuously while Figure 1. Bidirectional interfaces components can reach the location where they are eventu- ally used by means of transfer processes. Unlike in bio- logical organisms, component transfer in Dynacomp serves to be satisfactory during the case study implementation. mainly the purpose of architectural reconfiguration, while This declarative approach adds further meta-information to data transfer is accomplished by the usual mechanism (e.g. the - quite limited - meta-information already available in method calls). Dynacomp’s component transfer also dif- the Fractal framework. The following meta-information is fers from data-driven approaches e.g. architectures based proposed by this paper: on Chemical Abstract Machine (CHAM) [10] the principles of which are very similar to those of Dynacomp. CHAM, Interface name Each interface is named and only inter- however, uses its “molecule” and “transfer process” abstrac- faces with the same name can be connected. The in- tions to describe computations, while in Dynacomp these terface name convention comes directly from Fractal. abstractions are used solely for component network adap- tation purposes. Applying biological principles to the self- Interface direction Beside Fractal’s client (outgoing) and healing problem was already discussed in [18] although the server (incoming) interfaces, the dynamic composition architecture presented in the paper is still based on dedi- framework introduces the bidirectional interface type. cated reconfiguration managers. A component exposing bidirectional interface has one client and one server interface with logically the same name (due to a Fractal restriction, the real names can 2. The dynamic composition framework not be identical). One bidirectional interface can be connected only to another bidirectional interface. The Dynacomp is built on top of the Fractal framework [1]. bidirectional interface is connected at a random direc- The Dynacomp framework uses two types of components tion, e.g. the client interface of the first component that extend Fractal’s composite and primitive component will be connected to the server interface of the second types. Additionally to Fractal’s features the following func- component. The server interface on the first compo- tionalities are provided by Dynacomp component types. nent and the client interface of the second component will be left unconnected (see figure 2). Bidirectional Dynacomp primitive components are able to expose their interfaces are able to express the statement that cer- constraints to be used for dynamic composition. tain component instances of same type have to be con- Dynacomp composite components are able to rearrange nected with each other. Without the notion of a bidirec- other components contained in the composite com- tional interface, this statement would create loop in the ponent and to participate in transferring components connection graph hence the component network could into and out of the composite component. The collec- not be started. tion of components managed by Dynacomp composite component is also called the domain of the composite Interface multiplicity Fractal differentiates between the component, while the composite component contain- singleton and collection cardinality. Automatic com- ing other component is referred to as the container of position needs more precise description of allowed in- the components it contains. Composite components terface connections. Dynacomp adopts the cardinality description of Service Binder [13]. The cardinality of are able to expose their constraints in the same way as the interface (both client and server) can be one, one primitive components do. or more, zero or one, zero or more connections. Cardi- As described previously, containers arrange components nality can be specified for both client and server inter- in their domain according to constraints. The constraints are faces. provided by individual component instances thus compo- nent instances control the reconnection procedure directly Interface priority Priority is assigned to all component in- by means of these constraints. In a border-line case express- terfaces. Priority determines which component inter- ing constraints needs a programmatic approach with full ac- face to select for connection in case there are multi- cess to the component to be connected. However, a much ple component interfaces satisfying the search crite- simpler declarative approach was chosen which was found ria. The priorities of the interfaces to be connected are 2