# The Next Generation Platform as A Service: Composition and Deployment of Platforms and Services
## 3 The Next Generation PaaS: Architecture, Concepts, Processes, and Workflows
### RFB Description and Composition Languages Design, Deploy and Direct Tool  
To fully exploit the RFB concept, NGPaaS is utilising the RDCL 3D tool: a web-based framework that allows the composition of RFB graphs. By composing graphs comprising multiple RFBs, it is possible for a VSP to define complex platforms and services for deployment. Apart from composing RFB graphs, the RDCL 3D tool is also responsible for \"shipping\" them to an RDCL agent. Every RDCL agent is tied to an execution environment (e.g., an infrastructure or a platform) and its role is to deploy the services/platforms composed by the graph into this execution environment. To facilitate this action, each RFB leaf in an RFB graph is mapped to an Ansible-based [29] workflow which is executed onto the execution environment of the RFB by the agent. By selecting different execution environments for different RFBs of an RFB graph, it is possible for a deployment to span multiple execution environments. For example, a platform deployment can span across a public and private cloud infrastructure. For the RFBs to be executed in the desired order, a priority mechanism is used in which each RFB is assigned a priority value. The RDCL 3D tool was initially developed in the 5G-PPP Superfluidity [30] project but has been heavily extended to meet the requirements of NGPaaS. Figure 3 illustrates the operation of the RDCL 3D tool in greater detail.  
A VSP uses the web-based interface of the RDCL 3D tool to describe the desired service or platform using an RFB graph; this comprises of RFBs from the catalogue of RFBs made available by the NGPaaS operator. The RDCL 3D tool provides a full separation between platform and service deployments by assigning each RFB to either a service or platform category. Then when composing a service or platform graph, the VSP will be only presented with the corresponding RFBs. Once the composition of the RFB graph is completed, the VSP selects an appropriate RDCL agent (In this case the service agent of IaaS A). The RFB graph is encoded as a JSON string and is shipped to the agent. Once the agent receives the deployment request, it initiates the execution of the corresponding Ansible roles, each mapping to an individual RFB leaf of the RFB graph. Finally, these Ansible roles are executed into the appropriate execution environment (Platform A in this case) and the desired service is provisioned. Figure 3 also illustrates the possibility to control multiple RDCL agents, via a single RDCL 3D instance.  
Figure 3: Overview of the RDCL 3D tool.  
Figure 4 depicts a simple example of an RFB graph as it appears in the RDCL 3D tool web interface. A root RFB (service1_fb) comprises two RFB children (Service A, Service B) each corresponding to a different logical subcomponent of the parent service. Each of these RFB comprises of two RFB leaves (VNF A, VNF B, VNF C, and VNF D) -these leaf RFBs are the ones directly mapped to the deployment micro-services (e.g., containers) in the execution environment. Finally, the figure also shows as an example the metadata tied to leaf RFB VNF B (two key-value pairs).