VersaCloud's Queries

An additional set of significant requirements for multi-tier cloud-based software is handled by our cloud-based time-limited transaction manager 'queries' concept, defined as the possibility to allow users to access part of the data stored inside our finite state automaton, under severe limitations: not only do users require special authorization (based on specific user rights and special clone solution tokens), but this query-based access to internal data is always read-only (that is, it is not possible to apply any changes) and sequential (following a pre-defined ordering).

This query concept is used by our cloud-based time-limited transaction manager, for example, to solve the auditability problem of multi-tier cloud-based software: this concept allows reporting to users how they spent their credits over time, tracing the usage of all security sensitive features, proving that Service Level Agreements provided by back-end server developers to end-user software are being honored as well as allowing developers to traverse our transaction manager's API documentation (that is also stored inside our finite state automaton).

The implementation of this Query concept uses the 'Auditor' 'right' (for API calls that access the call log) and the 'Query Manager' right (to manage 'Auditor' rights and eventually add new queries).

Queries are defined as associated to a specific solution: in order to check if a name has been defined as a query, the 'QueryValid' API is available. Also, queries are classified based on 'queryType' values, currently defined as being 'Audit', 'Enum', 'LogReport' and/or 'Stats'. The definition of new queries (restricted to users owning the 'query manager' right) occurs through calls to the 'QueryAddAllow', 'QueryParameterAddAllow' and 'QueryAddCommit'.

Queries and their parameters have their own documentation, which can be retrieved by calls to the 'QueryDocumentationGet' and 'QueryParameterDocumentationGet' APIs. Documentation can be defined by calls to the 'QueryDocumentationSetAllow', 'QueryDocumentationSetCommit', 'QueryParameterDocumentationSetAllow' and 'QueryParameterDocumentationSetCommit' APIs.

If necessary, query parameters can be removed through transactions consisting in calls of the 'QueryParameterRemoveAllow' and 'QueryParameterRemoveCommit' APIs.

Queries can be defined to be anonymous or not: when they are anonymous (no user login is required to run them), the query transaction is started calling the 'QueryAnonymousAllow' and ended calling the 'QueryAnonymousCommit' API. If a user login is required, then the transaction is delimited by calls to the 'QueryAllow' and 'QueryCommit' APIs. In both cases, parameter values are provided by calls to the 'QueryParameterValueAddAllow' API, and the values retrieved by the query are returned sequentially, one by one, through successive calls to the 'QueryNext' API, which returns a specific error code when the end of the set of values has been reached.

Non-anonymous queries can be defined to be limited to users owning specific rights, by adding these rights to the query through calls to the 'QueryRightAddAllow' and 'QueryRightAddCommit' APIs. The 'QueryRightValid' API call is useful to verify if a specific user right is adequate to run a specific query.

The remaining query attributes managed by our cloud-based time-limited transaction manager include a cost to run a query (to be debited from the calling user's balance), a maximum time to run the query, a time period during which the query is valid, and a minimum and maximum size for the set of values to be returned. All these attributes can be retrieved through calls to the 'QueryInfoGet' API, and modified through calls to the 'QueryInfoSetAllow' and 'QueryInfoSetCommit' APIs.

US Patent Requested