The Application Designer in DITAS represents the user of the DITAS solution which wants to find, retrieve and use the data exposed by the Data Administrator. About the data finding, the concept of Abstract VDC Blueprint holds a role of mediator between the actual data set owner by the Data Administrator and which are the data that are actually available to the final user. In fact, the Application Designer, exploring the Abstract VDC Blueprint repository can be aware of the data source made available by the Data Administrator. To improve the experience of the Application Designer, the repository exposes several functionalities which allows to find the blueprints by keywords, tags, and ability to satisfy the data utility requirements as expressed in the application requirements file. In this file, not only the data needed are listed but, optionally, also the resources made available by the Application Designer to run the VDCs. By means of the Resolution Engine, the set of Abstract VDC Blueprints able to satisfy the requirements are returned and, among them, the Application Designer has to select the preferred one which will be next deployed.

To support the Application Designer in performing the assigned tasks, the DITAS-SDK – in addition to the BPGen used by the Application Developer and the Data Administrator, includes two specific tools: an Application Requirements file Editor, and a Resolution Engine Service. While the former is offered only via GUIs, the latter can be accessed through an API. The aim of these tools is to assist the Application Design to express the needs in terms of data (functional perspective) and data utility (non functional perspective) in a way that can be exploited by DITAS to retrieve the set of Abstract VDC Blueprints defined by the Application Developer / Data Administrator which are able to fulfil such needs. More specifically, the Application Requirement file editor allows the Application Designer to express the type of needed data, which are the data utility parameters considered relevant, and the resources owned by the Application Designer which can be accessed by DITAS Execution Environment to run the application. Focusing on the data utility, to make easier the work of the Application Designer, a goal-based model is adopted to express at different levels of abstractions the data quality and quality of service constraints. Concerning the Resolution Engine Service, it receives as input an application requirement file (as created with the editor) and returns a list of Abstract VDC Blueprint which satisfy all the constraints. This list is properly ranked according to the degree of satisfaction of the constraints. Due to the variety of the dimensions to be considered in the selection of the best Abstract VDC Blueprint, the approach followed by DITAS is to leave the final word in choosing the best one to the Application Designer. In fact, the ranking reflects a suggestion that the Resolution Engine Service proposes to the Application Designer which, in turn, can select the top-most in the list as the Abstract VDC Blueprint as well as any other in the list.

Application Requirement File Editor

To assist the application designer in creating the application requirements file, a graphical web editor has been developed. In particular, the application guides the application designer with a step-by-step approach organized along four main phases: functional requirements definition, goal trees and metrics definition, provided resources definition, and application requirements file generation.

1 – Functional requirements definition

In this step the application designer specifies the tags that will be used in the blueprint negotiation phase to find blueprints that fulfill the functional requirements of the application. To this aim, the application designer has to specify the tags that identify the functions offered by the VDC and by its methods. In addition, to better assess the potential data utility, the application designer can specify the attributes of the data that will be provided when the VDC methods are invoked.

2 – Goal trees and metrics definition

In this step the application designer specifies the goal models that will be used to rank and filter the blueprints according to the non functional requirements, i.e., data utility, privacy, and security. To this aim, by specifying the type of application that will use the VDC methods, standard goal trees that are optimized for the application will be proposed. The application designer can then customize both the goal trees and the associated metrics. For the goal tree, she can delete nodes or leaves if they predicate on metrics that are not relevant to her.

For the metrics, she can customize them by specifying either an actual value (e.g., 2 seconds maximum response time) or a fuzzy one (e.g., high service availability). For the latter, the editor will automatically replace it with an optimum value once the application requirements file is generated.

3 – Provided resources definition

In this step the application designer specifies the resources that she makes available when the VDC is instantiated. By default, one resource definiton is already present. However, if the application designer does not have any resource available, she can delete it and leave this section empty. Also, she can add additional resources.

For each resource, she has to specify the type, i.e., cloud, fog or edge, the infrastructure API (e.g., kubernetes), the endpoint, and the access credentials. Then, for each resource, she can add one or more machines. For each machine, she can specify the configuration (CPU, RAM, etc.) and the attached disks.

4 – Application requirements file generation

Once the application designer has completed all the previous steps, she can generate the application requirements file. In addition, she can directly invoke the resolution engine passing the generated application requirements file.

Resolution Engine Services

Content-Based Resolution  Service
Description/Usage This method searches into specific fields on the blueprint, the tags and also the description of the blueprint, in order to find the most suitable blueprints based on the content they deliver.
Input
URL POST /searchBlueprintByReq
Parameters
  • none
Payload free text
Output\Response
Content Type application/json
Body Request Body

  • Description: application requirements, list of blueprints to be filtered and ranked
  • Content-Type: application/json
  • Example:
{
  "applicationRequirements": {
    "applicationType": "regression",
    "functionalRequirements": {
      ...
    },"attributes": {
      ...
    },"goalTrees": {
      ...
    }
  },"candidates": {
    [ 
      {
        "blueprint": {
          ...
        },"methodNames": [
          "chosenMethod",...
        ]
      },...
    ]
  }
}

 

Data Utility Resolution Engine (DURE) Service
Description/Usage The Data Utility Resolution Engine (DURE) Service is used in the blueprint selection phase of DITAS. It is responsible for filtering and ranking blueprints according to non-functional requirements.
Input
URL POST /v2/filterBlueprints
Parameters
  • None
Payload Request Body

  • Description: application requirements, list of blueprints to be filtered and ranked
  • Content-Type: application/json
  • Example:
{
  "applicationRequirements": {
    "applicationType": "regression",
    "functionalRequirements": {
      ...
    },"attributes": {
      ...
    },"goalTrees": {
      ...
    }
  },"candidates": {
    [ 
      {
        "blueprint": {
          ...
        },"methodNames": [
          "chosenMethod",...
        ]
      },...
    ]
  }
}
Output\Response
Content Type application/json
Body
{
  "blueprint": {
    ...
  },"Score": 0.83,
  "methodNames":
  [
    "chosenMethod",...
  ]
}

Data Utility Refinement (DUR) Service
Description/Usage The Data Utility Refinement (DUR) Service is used in the blueprint selection phase of DITAS. It is responsible for rebalancing weights in the goal model based on the type of application developed by the application developer.
Input
URL POST /v1/refineDataUtility
Parameters
  • None
Payload Request Body

  • Description: application type, data utility metrics
  • Content-Type: application/json
  • Example:
{
  "application": "regression",
  "datautility":
  {
    "timeliness": 1,
    "accuracy": 1,
    "completeness": 0,
    "consistency": 1
  }
}
Output\Response
Content Type application/json
Body
{
  "timeliness": 0.7,
  "accuracy": 0.1,
  "completeness": 0,
  "consistency": 0.2
}

 

Data Utility Evaluator (DUE) Service
Description/Usage The Data Utility Evaluator (DUE) Service is used in the blueprint selection phase of DITAS. It is responsible for updating data utility attributes in the blueprint based on the columns that are relevant for the output desired by the application developer.
Input
URL DUE /v1/computeDataUtility
Parameters
  • None
Payload Request Body

  • Description: blueprint
  • Content-Type: application/json
Output\Response
Content Type application/json
Body Blueprint

 

Privacy Security Evaluation (PSE) Service
Description The Privacy Security Evaluator Service (PSES) is used in the blueprint selection phase of DITAS. It is responsible for filtering and ranking the security- and privacy-related properties of a Blueprint.
Input
URL POST /v1/filter
Parameters
  • None
Payload Request Body

  • Description: filter query
  • Content-Type: application/json
  • Example:
{
 "requirement": {
    "id": "1",
    "name": "<any>",
    "type": "<any>",
    "properties": }
     {
       "name": "<any>",
       "unit": "<any>",
       "value": "<any>"
     },
     ...
    }
 },
 "blueprintMetrics": [
    {
     "type": "object",
     "description": "<any>",
     "properties": {
       "id": "blue1",
       "name": "<any>",
       "type": "<any>",
       "properties": {
         {
           "name": "<any>",
           "unit": "<any>",
           "value": "<any>"
         },
        ...
       }
     }
    },
    ...
 ]
}
Output\Response
Content Type application/json
Body
[
    {
       "blueprint": {
           "id": "blue1",
           ...
           ]
       },
       "score": <num>
    },
    ...
]

 

Recommendation Service
Description/Usage This method compares the user requirements of other users that acquired and used each proposed blueprint with the user requirements of our current user and rates them according to their similarity rating in combination with their user rating.
Input
URL (Method TYPE: POST, GET, etc.)   URL
Parameters
  • {parameter}| description| Type(string, number, etc.)
Payload Request Body

  • Description: Find score of every Blueprint based on the current Application Requirements
  • Content-Type: application/json
  • Example:
    {
      "requirements": {
    "id": "1",
    "name": "<any>",
    "type": "<any>",
    "properties": {
       {
         "name": "<any>",
         "unit": "<any>",
         "value": "<any>"
       },
    }
      },
      "blueprintList": [
    {
         "blueprint": {
             "id": "blue1",
             ...
             ]
         },
         "score": <num>
    },
    ...
       ]
    }
Output\Response
Content Type application/json
Body
[
{
     "blueprint": {
         "id": "blue1",
         ...
         ]
     },
     "score": <num>,
      "rating": <num>
},
...
   ]