Skip to content
COMET is a distributed RESTful provider-independent meta-data service for cloud-based systems.
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
SimpleHTTPS
aws-accumulo
comet-accumulo
docker-compose
specifications
.gitignore
Dockerizing.md
LICENSE
README.md

README.md

COMET Documentation

About

COMET is a distributed RESTful meta-data service which stores key-value oriented configuration information about resources and applications running in the distributed cloud. Clients of COMET are elements of IaaS cloud provider system, user client tools, applications running in tenant virtual systems/slices. COMET provides strong authorization controls ensuring that information is only shared with appropriate clients.

COMET (phase 2) is based on new design of mapping cloud service entries to Accumulo table entries.

comet accumulo architecture

COMET API implementation

The COMET Accumulo Query Layer API has been created using Swagger API 2.0, and is also available as YAML in specifications/swagger.yaml

Running the server

The server within this repository is based on Spring Boot and Java API for RESTful Web Services (JAX-RS) and uses Maven to control the build process.

$ cd /PATH_TO/COMET-Accumulo/comet-accumulo/
$ mvn clean spring-boot:run

Validate that the server is running at: http://localhost:8080/swagger.json (Example below)

http://localhost:8080/swagger.json

Or Running the server in Docker

Please refer to Dockerizing.md

Initial Code Generation

API Server

Swagger enables the generation of clients and servers in a variety of common programming languages via the swagger codegen project.

  • Clients are generated to be fully formed and functional from the generated files including documentation
  • Servers are generated as stubbed code, and require the logical operations to be added by the user

The server within this repository is based on Spring Boot and Java API for RESTful Web Services (JAX-RS)

Generate a new server stub

Running the server

The server stub is runnable upon generation, though may require a small modification to the pom.xml file to do so the first time.

Remove the provided scope line from the pom.xml file as discussed in swagger-codegen/issues/5091.

  • From:

     ...
         <!-- Bean Validation API support -->
         <dependency>
             <groupId>javax.validation</groupId>
             <artifactId>validation-api</artifactId>
             <version>1.1.0.Final</version>
             <scope>provided</scope>
         </dependency>
     ...
  • To:

     ...
         <!-- Bean Validation API support -->
         <dependency>
             <groupId>javax.validation</groupId>
             <artifactId>validation-api</artifactId>
             <version>1.1.0.Final</version>
         </dependency>
     ...

Run the server

cd /PATH_TO/jaxrs-server-generated/
mvn clean package jetty:run

Validate that the server is running at: http://localhost:8080/swagger.json

The stubbed server will not have any logic encoded into it, however should return the response magic for calls made to valid endpoints.

Example:

$ curl -i "localhost:8080/readScope"
HTTP/1.1 200 OK
Date: Wed, 10 Jan 2018 18:56:27 GMT
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, DELETE, PUT
Access-Control-Allow-Headers: Content-Type
Content-Type: application/json
Content-Length: 41
Server: Jetty(9.2.9.v20150224)

{"code":4,"type":"ok","message":"magic!"}

Updates to Swagger specification

Since swaggerhub only generates server stub code, it becomes the task of the developer(s) to differentiate foundational code changes that occur when the underlying specification is updated.

There is no good way to predict a-priori which elements will need to be modified, and the experience of the developer(s) integrating the updated code will be relied upon to do the updates effectively.

Workflow for updates:

  1. Update the specification in swaggerhub and save the results
  2. Generate new Spring Boot server stub code into a separate directory
  3. Diff the elements of the new stub code as they correspond to their counterparts in the repository
  4. Manually implement the diffs where needed
  5. Add new code to enable the new features of the updated specification
You can’t perform that action at this time.