External References Concept

TheExternal Referenceconcept extends the component-based model to allow ex-

ploration of communication patterns and the system topology through component replacement in the local software instances. The External Reference concept solves two main problems: i) the inability of component developers, using a component- based model, to write components that require to interact with external services, and ii) enabling the Learning module to experiment, through the component-replacement experimentation learning process, different system’s topologies, for example, by con- necting the component to the service running in nodeA and B, or only to node C. This section details how the development of the External Reference interface in tan- dem with the Registry and Factory modules realise the External Reference concept. The ExternalReference interface (Fig. 4.8) is used by components developers to express a component’s requirement to interact with external systems. The inter- face provides a function that returns a list of IP addresses and port of executing emergent systems. This information is dynamically generated after the system’s deployment, and are used by components to locate and interact with their required external services. The details of the ExternalReference interface is depicted in Fig. 4.8, illustrating the single function (ServerInfo[] getServersInfo()) and the ServerInfo data type. In a component-base model, a component that re- quires an interface expects to be connected to a component that provides such interface at runtime. Based on that assumption, the External Reference concept uses the Registry and Factory modules to generate components that implement

4.5. Distributed Emergent Systems 98

Figure 4.9: The image shows the Registry information table with data about poten- tial services provided by nodes A, B and C.

theExternalReference interface. The generated components are connected to the component who requires theExternalReference interface, providing it with infor- mation about the nodes where the services are running. The component generation process and the generated components are described later in this section.

The Registry module is a regular naming service that contains the services’ name and the server information running the services (IP address andport number). Considering that in an Emergent Software System the services are autonomously assembled at runtime, and that the services provided are changed when the nodes composition changes, the Registry stores information of the nodes and the potential services each node might provide. For example, as illustrated in Fig. 4.9, the server A(IP address: 10.0.0.1) has the potential to either provide a HTTP service onport

80, or provide a SQL service onport 3306. The Registry data illustrated in Fig. 4.9 informs that the node A has the potential to be a HTTP server (i.e. web server, web cache or a load balance)ora SQL server (i.e. a relational database), depending on its composition. Based on the information stored in the Registry, the Factory generates components that provide theExternalReference interface.

The Factory module provides the function‘generateExternalRefVariations()’ responsible to generate components that provide theExternalReferenceinterface. This function expects a JSON string (char servicesInformation[]) as parameter with the data to generate the components (e.g. "IPAddr", port, etc.). An example of data required to generate theExternalReference components is presented:

4.5. Distributed Emergent Systems 99 {"name": "SQL", "IPAddr": "10.0.0.1", "port": "3306"},

{"name": "HTTP", "IPAddr": "10.0.0.2", "port": "80"}]}

Based on the example of data to generateExternalReference components, the Factory module generates component variants to each of the participating nodes. The example described on the list above illustrates the C node’s (in Fig. 4.9) re- quest to the Factory module. The C node requires the Factory module to generate ExternalReference component variations passing as parameters the IPAddr and

port number of all the other nodes in the system (excluding itself) in the Registry. Based on the information provided, the Factory module generates 7 component vari- ations (Fig. 4.10). The Factory considers the services information (IPAddr andport number) passed as parameters as a set. The Factory then generates thepower set2_,

excluding the empty set, of all the elements it receives. EachExternalReference component generated by the Factory is a set of the resulting power set. In this exam- ple, the Factory generates 7ExternalReferencecomponents, making combinations of the items1 by 1,2 by 2and3 by 3. The resulting components produced by the Factory toC node, considering the presented input example, is shown in Fig. 4.10. As a result of generating ExternalReference components, the External Ref- erence concept enables the experimentation of the system’s topology by exploring ExternalReference components in the local architecture. For example, node C, depending on theExternalReferencecomponent connected to its architecture, en- ables the node to communicate to only node A on port 80 (when selecting Ahttp

component in Fig.4.10); or to bothA on ports80and 3306, and nodeB on port80, when the component AHT T P ASQL BHT T P is connected to the architecture. This

allows the PAL framework, through the experimentation process, to discover the optimal communication pattern and topology to best satisfy the system goal.

The External Reference concept enables the exploration of communication pat- terns and system topology by the Learning module, but does not prevent invalid global compositions resulted from Behavioural Mismatches, e.g. a node sending HTTP requests to another node running a relational database (see Sec.3.2.3 in Chap-

2_{A power set is a mathematical concept and is defined as: a set composed of all subsets of a} given set. E.g.: Given setS {0,5}, the power set ofS is{{}, {0},{5},{0,5}}

4.5. Distributed Emergent Systems 100

Figure 4.10: Example of resulting External Reference components. All possible components generated from services information are illustrated on the left part of the image. An External Reference component code is represented on the right.

ter 3). The next section (Sec. 4.5.2) presents theValidator module responsible to identify invalid global compositions and prevent system failures during exploration.