Difference between revisions of "Resource Accounting ABANDONED"
(→Architecture) |
|||
Line 1: | Line 1: | ||
+ | {| align="right" | ||
+ | ||__TOC__ | ||
+ | |} | ||
+ | |||
+ | == Overview == | ||
+ | |||
The goal of the Resource Accounting is to allow gCube services to account their own custom information within the iMarine infrastructure | The goal of the Resource Accounting is to allow gCube services to account their own custom information within the iMarine infrastructure | ||
− | == Architecture == | + | == Key Features == |
+ | |||
+ | to do | ||
+ | |||
+ | |||
+ | == Design == | ||
+ | |||
+ | === Philosophy === | ||
+ | |||
+ | to do | ||
+ | |||
+ | === Architecture === | ||
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. | 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. | ||
Line 7: | Line 24: | ||
[[File:Resource_Accounting_Architecture.png]] | [[File:Resource_Accounting_Architecture.png]] | ||
− | Resource Accounting system is built around the [https://gcube.wiki.gcube-system.org/gcube/index.php?title=Usage_Tracker_Installation 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. | + | Resource Accounting sub-system is built around the [https://gcube.wiki.gcube-system.org/gcube/index.php?title=Usage_Tracker_Installation 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 [https://gcube.wiki.gcube-system.org/gcube/index.php?title=Common-accounting-model common-accounting-model] library. | The adopted data model to represent accounting records is implemented by the [https://gcube.wiki.gcube-system.org/gcube/index.php?title=Common-accounting-model common-accounting-model] library. | ||
The [https://gcube.wiki.gcube-system.org/gcube/index.php?title=Common-accounting common-accounting-lib] allows to produce/consume Resource Accounting records. | The [https://gcube.wiki.gcube-system.org/gcube/index.php?title=Common-accounting 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 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 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. | + | 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 [https://gcube.wiki.gcube-system.org/gcube/index.php?title=Accounting_Portlet 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. | ||
+ | |||
+ | === Well suited Use Cases === | ||
+ | |||
+ | === Less well suited Use Cases === | ||
− | + | == Notes == | |
+ | <references/> |
Revision as of 13:20, 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
to do
Architecture
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.
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.