Summary

Some components of the CloudSocket Environments need to access a set of information related to different entities, such as external services, software components, and cloud providers. For this reason, the CloudSocket project needs a specific transversal component allowing the population, browsing and searching of this information using standard web technologies. The Repository Manager has the responsibility to satisfy those functionalities and has a key role into the CloudSocket architecture because it’s exploited by all the CloudSocket Environments to access this information, which for now, there is only one structural level of registries is offered. For the next release, the consortium might consider leveraging upon this structural level in order to create a semantic one on top of it so as to be also aligned with the research results in WP3. This will allow the posing of more advanced and semantic queries which can enhance the different scenarios/tasks that can be performed by the respective exploiting components as well as enable better query response accuracy levels. The repository manager offers the information needed by the CloudSocket Environments by the means of a number of registries. The main registries identified for the CloudSocket context are the followings:

• Cloud Provider Registry: it contains the information about a cloud provider like the name, the type of offering that it provides (i.e. Platform as a Service or Infrastructure as a Service) and technical details, specified using the CAMEL language, which enable the Cloud Provider Engine to have the exact knowledge of how to access and exploit the (cloud) services of this Cloud Provider.
• Virtual Machine Offering Registry: it contains the information about a Virtual Machine offering provided by a specific Cloud Provider. Such information includes the number of cores, the size of the main memory and disk storage as well as the price of the given offering.
• Abstract Service Registry: it contains the information about abstract services mapping to an abstract functionality; these services are of course not real in the sense that they are not developed, deployed and executed and thus available in a certain endpoint. Such information includes the abstract service name, short textual description, and interface. It also includes the specification of semantic annotations oriented towards semantically explicating the exact service functionality as well as the respective input and output that is provided by each method of this service. Such information can enable a semantic discovery of services which has been proven to reach higher discovery accuracy levels.
• Concrete Service Registry: it contains the information about concrete atomic services already up and running. Such information includes the name, the description, the interface definition, the interface protocol (i.e. SOAP or REST) and a list of instances for this service which are associated to a pair of location and endpoint URL (thus enabling us to know exactly where each instance of a certain atomic service is available).
• Software Component Registry: it contains the information about software components developed. Such information includes the name, the description, the set of commands to install the software component to specific operating system images, the communication port(s) exposed, the minimum hardware requirements for the proper functioning of this component and the dependencies it has with other components.
• Metrics Registry: it contains the information about the metrics handled by the CloudSocket platform. Such information includes the name of the metric, its short description, the property that is being measured, the definition of the sensor which captures the measurements for a raw metric, the derivation formula for composite metrics, the unit and the type of the metric as well as default measurement schedule and window information.

Architecture design

The figure below shows the Repository Manager's internal architecture.

[TODO-IMAGE]

The Repository Manager follows a classic three-tier architecture pattern in which the user interfaces (presentation), functional process logic, computer data storage and data access are developed and maintained as independent modules. The three layers are described in detail below:

• In the Data Layer, there exists a sole component mapping to the MongoDB NoSQL database: The latter is a free and open-source cross-platform document-oriented database. It is classified as a NoSQL database. MongoDB avoids the traditional table-based relational database structure in favour of JSON-like documents with dynamic schemas (MongoDB calls the format BSON), making the integration of data in certain types of applications easier and faster. It is used to implement the persistency layer to store the registry JSON documents. Each JSON document of the registry describes a different resource. The resources can refer to each other. For example, we are able to describe a Virtual Machine offering as a JSON document and associate it using an object id reference to a specific Cloud Provider.
• Functional Layer: There lies the Restheart WebAPI which is a Java open source Web API server built on top of the MongoDB database. RESTHeart exposes a RESTful application programming interface with CRUD operations, following the Hypertext Application Language (HAL) standard. RESTHeart naturally fits an architecture where there is the need to invoke document-oriented data services on top of MongoDB via HTTP. The main features of the framework are the followings:
  • Lightweight Server: the API is ready to use and does not require any coding;
  • Built on standards like HTTP, JSON, RESTful, HAL, json-schema;
  • Pluggable Authentication and Authorization with ready to use Identity Managers and role based Access Manager. This feature will be used in order to integrate the Repository Manager with the Identity Manager provided by the Marketplace;
  • Data operations API enabling document management and including the following operations:
  • create, read, update, delete and query documents; o Data validation with json-schema.
• User Interface Layer: There lies, the Restheart SchemaForm UI which is a custom AngularJS application, developed by FHOSTER for the CloudSocket project, based on two main angular-js modules:
  • angular-restheart: it is the client provided by RESTHeart project to facilitate the access to the webapi from an angular-js client;
  • angular-schemaform: it is a set of AngularJS directives (and a couple of services) to generate Bootstrap 3 ready forms from a JSON Schema. The main features of this angular-js module are:
    • Validates the form using a JSON Schema;
    • Fine tunes presentation with a form definition, changes field types, changes order and so on;
    • Lots of basic form types out of the box;
    • Supports array with drag'n'drop or in tabs;
    • Easily extended with custom form field types.

The web application has all the features useful to access the content of the registries and modify the content of each object. It provides mechanisms for validation of the data and a user-friendly interface that simplifies the population process of the registries. It allows also to create new kind of registries by providing the JSON Schema and a form definition compliant with the angular-schemaform framework which instructs it on how to render the form of the registry object.

Installation manual

Prerequisites:

• install npm
• install node.js
• install gulp

To get up and running the web application as docker container (you need to install restheart docker image before, see https://hub.docker.com/r/softinstigate/restheart/ for more information) and then run the following command after cloning this repository https://omi-gitlab.e-technik.uni-ulm.de/cloudsocket/restheart-schemaform-ui:

• npm install
• npm run build
• docker build -t restheart-schema-form-ui
• docker run -d -p 80:3000 --name restheart-schema-form-ui --link restheart restheart-schema-form-ui

then access to http://<server-ip>:80 once the docker image is up and running.

Test cases

User manual