# DD-FoG: Intelligent Distributed Dynamic FoG Computing Framework
## 3 Proposed System
### Proposed Framework of Distributed Dynamic Fog Computing System (DD-Fog)
The level of decomposition (servers on the MVC-pattern model, server modules, classes, objects, databases, or even individual function-methods) is determined in each particular case, project by the development team. However, each of the above-defined modules can be represented in the form of generally accepted interpreted objects: container, virtual machine. For example, if the decomposition is not so low-level, then the architecture of the software that is developed according to the microservice architecture can be represented as the following diagram (Figure 3.)  
Figure 1: The common architecture of the framework. Thus, an application that implements one or another user service can be distributed in the network by modules. Considering the technologies of containerization and virtualization (Linux, VMware, etc. ), it is possible to distribute applications, taking into account the needs of each of the decomposed modules, on FoG structures controlled by a multi-tier cloud infrastructure MEC. Figure 3 summarizes the key elements of software implemented according to a microservice architecture approach. Below are brief descriptions of some of the items. 1. Balancer HAP proxy: It is a software module (proxy server) that accepts user requests, performs TCP / HTTP load balancing and distribution of requests between elements  
Figure 3: Typical microservice high-level functional architecture of the software. Figure 2: Use case of the framework. on the Backend. These user requests are generated by various client devices (browser, mobile application, smart device, etc.). 2. API GW-(Application Programming Interface): This is a software module (can be rendered as a separate microservice), which acts as a single accurate reception of requests from external users of the microservices API. API GW receives the request and, based on the URL, determines which microservice should receive/process it. After that, it sends the message through MQ Broker to the recipient microservice, waits for a response and returns it back. The second important function of the GW API is to create and maintain a user session. 3. MAIN DB-(Main Application Database): This database stores information about users and related information, as well as other application metadata. 4. MQ Broker-(Message Broker): This module is required to implement asynchronous communication between system components. Implements the functions of the microservices discovery service in the system. One of the main functions of the module is the implementation of queues: for receiving requests and sending responses to received requests. Each of the microservices connects to a given broker and corresponding message queues. The broker also performs the functions of routing messages based on the metadata transmitted in the message headers (including data about the current user session-authorization token). Each instance of a microservice of a particular type subscribes to listen on the request queue and fetches messages. When sending requests, the recipient is not a specific instance of the microservice, but the type to which it belongs. Since within the framework of the microservice approach, the implementation of each of the microservices can be made in such a way that to increase the performance of the microservice, only copying it is required. The data broker also takes over the load balancing function. In this case, balancing is done implicitly by the microservices themselves, listening to the request queue.