Architecture Evolution
The Architecture of the old IA is depicted in the Figure below. Here you can see the deployment of the VIM and WIM containers and their modules inside. Both containers comprise the IA component and interact with the other internal components (mainly the MANO Framework) through a Message Bus (RabbitMQ), by using a predefined set of message requests and responses.
Common to all VIM/WIM modules is an NorthBound Interface (NBI) function, which is able to receive messages, unpack them and identify the VIM/WIM module to which it corresponds, and redirect the message internally to it. On return, the NBI function receives the data, packs it and sends the response back to the IA-outside through the Message Bus. In some messages, e.g. collect resources for all available VIMs, multiple VIMs may be queried to collect data. In this case, they are sequentially requested, the response data is appended, packed together to form the response, and sent it back towards the IA-outside.
The code for both containers is stored in a single repository.
The solution to fix the issues that motivated this IA refactoring can be summarized as follows:
- Create a NBI sub-component fully detached from the different VIM/WIM plug-ins, and running in a container;
- Create a VIM/WIM wrapper sub-components isolated from NBI, and running each in a single container;
- Introduce an internal Message Bus (RabbitMQ), used to communication between the NBI and the VIM/WIM plug-ins;
- Within the internal Message Bus, plug-in have its own topics, isolating the traffic from each others' (e.g. ia.deployment.heat)
- Unlike before, VIMs and WIMs share a common NBI, which acts as proxy for the different plug-ins;
- The NBI runs in a single containers and is maintained in an isolated repository;
- Each VIM/WIM plug-in runs in a single containers and is maintained in an isolated repository;
The Architecture of the new IA is depicted in the Figure below. Here you can see the multiple containers, 1 for NBI and N for each plug-in, as well as the internal Message Bus to interconnect them. The different topics are also shown, given that the Message Bus basically multiplies the messages coming from IA-outside by the number of VIMs and WIMs.
Using this architecture, the requests that involve the contribution of multiple VIMs/WIMs can be more efficient, as instead of going sequentially through all and append data, a parallel request can be sent to all simultaneously (sort of multicast) and respond when all have successfully responded.
Beyond messaging interaction, proxying and redirection functions, the NBI is also responsible to store in the database data which is common to all plug-ins, e.g. to provide the list of available VIMs/WIMs. Actually, some API requests e.g. asking for available VIMs/WIMs, doesn't need to be forwarded to the plug-ins, but instead they are directly responded by the NBI sub-component.
