Difference between revisions of "Resource Accounting ABANDONED"
| Line 16: | Line 16: | ||
=== Philosophy === | === Philosophy === | ||
| − | to | + | Resource Accounting exploits the Messaging Infrastructure to deliver the message containing the accounting info to the proper instance of the Consumer for storage. In particular each time a new Resource Accounting record is generated a new message is enqueued into the local Producer which is in charge to dispatch it to the proper Message Broker instance. The Consumer(s) in charge to process this message, will then be notified and will store the information on the Resource Accounting DB. |
=== Architecture === | === Architecture === | ||
| − | |||
| − | |||
[[File:Resource_Accounting_Architecture.png]] | [[File:Resource_Accounting_Architecture.png]] | ||
Revision as of 18:26, 31 October 2013
Overview
The goal of the Resource Accounting is to allow gCube services to account their own custom information within the iMarine infrastructure
Key Features
to do
Design
Philosophy
Resource Accounting exploits the Messaging Infrastructure to deliver the message containing the accounting info to the proper instance of the Consumer for storage. In particular each time a new Resource Accounting record is generated a new message is enqueued into the local Producer which is in charge to dispatch it to the proper Message Broker instance. The Consumer(s) in charge to process this message, will then be notified and will store the information on the Resource Accounting DB.
Architecture
Resource Accounting sub-system is built around the Usage Tracker service whose goal is to keep track of resource usage by receiving and archiving accounting records. It provides create and query operations on the accounting records exposing RESTful API. The Usage Tracker adopts a document-oriented database (MongoDB in the current implementation) to persist accounting records. The adopted data model to represent accounting records is implemented by the common-accounting-model library.
The common-accounting-lib allows to produce/consume Resource Accounting records. At the service-side, each service could use the library to publish accounting information to the proper Message Broker instance, which is retrieved by querying the IS. At the Resource Accounting sub-system side, the Usage Tracker use the library to consume the accounting information published by the services. All the Resource Accounting records will be persisted using MongoDB.
The accounting information will be available both as reports (aggregated accounting records) and as raw data (single accounting record) through the Resource Accounting portlet, which is integrated with the Resource Accounting sub-system through the Usage Tracker RESTful API. The Resource Accounting portlet retrieves the proper Usage Tracker endpoint by querying the IS.
Use Cases
The use cases covered by the Resource Accounting sub-system are described in this section.
