Architecture of AMP Metering
This section will cover the fundamental architecture of the service.
Technical Overview
The metering microservice is written in Java, making heavy use of spring boot. It is designed as a standalone application, and tries to conform to the principles laid down in the twelve-factor app.
Specifically, it is a stateless application, designed to be created/destroyed frequently which is backed by a database. This allows easy load-balancing and scaling.
The application makes use of the Java Persistence API (JPA) to define its data model. Specifically, we use hibernate as the JPA provider . This allows the application to be plugged into a number of different databases.
The application uses Spring Boot to define RESTful endpoints. The endpoints are designed to consume and return JSON. Spring makes use of Jackson to convert text to JSON.
The application is designed to run in an embedded jetty server. The application is built using Apache Maven. The produced artifact is a runnable JAR that creates a jetty server and deploys the application.
The static application configuration is stored in an application.properties file. The dynamic configuration (e.g. database endpoint) is set at runtime by setting command line arguments.
Application Purpose
The application is designed to receive usage information deployed AMPs. This information is fine grained usage information about individual events (CREATED, DESTROYED etc.) for an application or location. The microservice validates and stores this information in a database.
Data consumers can query the microservice about a particular AMP and retrieve a summary of this usage information. Currently, an AMP ID is provided along with a start and an end date. The microservice returns the usage information in hours for all the locations the AMP manages.
AMPs push events to the metering microservice by configuring the MeteringPusher UsageListener. This could potentially be extended in the future to provide more data on each event.
The concept of Data Consumer is not fixed, it is purely whoever has access to the API. For example, this consumer could be:
- A master AMP that provisioned the Customer AMPs, which is reporting back to a billing API
- A separate billing service
- A separate web application
- A human
Authentication
There are currently two roles defined in the metering microservice:
- Admin: May create new (non-admin) users and query the metering microservice for usage summary. By default there is a single user with this role.
- User: May only record usage information. AMPs are configured with a user, and will send usage information as that user. When the admin is retrieving usage information they will supply a user name to retrieve the usage for. This is to allow usage to be grouped in a convenient manner. For example, if this Microservice takes usage information from AMPs that serve different customers, the user ID can be thought of as a Customer or Tenant ID. In the REST API this is frequently refered to as the tenantID.