Transactions through an encapsulated API - Get, SetAllow and SetCommit

The operations of adding users, adding solutions and cloning solution tokens are all defined as transactions run on our cloud-based time-limited transaction manager. As noted earlier, all data involved is stored inside a finite state automaton and not directly accessible to developers (or any other kind of user), but are encapsulated, in a sense similar to the object-oriented programming concept.

As depicted in Figure 7, all this state data is encapsulated using one single and coherent strategy across the design of our cloud-based time-limited transaction manager.

Every time a piece of data needs to be accessed, an API call ending in '…Get' must be used (for example, the 'ErrorDocumentationGet' API provides the documentation for a specific error code in a specific human language). If the piece of data requested is sensitive (as is the case, for example, for the 'TransactionNameGet' and 'TransactionParameterGet' APIs), then the corresponding '…Get' API will use one or more certifying parameters, like for example an operation handle of a previous user login, or a specific kind of solution token. Calls of the 'TransactionNameGet' API, for example, require the user's login operation handle plus the operation handle of the transaction for which it will retrieve its name.

When such an encapsulated piece of data needs to be changed, the corresponding '…Set' APIs must be used. However, these are not single calls on our cloud-based time-limited transaction manager (in order to secure those changes). Each '…Set' operation is defined as a transaction, started by a '…Allow' API call, and ended (successfully) by a corresponding '…Commit' call.

For example, to store the documentation for a specific error code (it might, for example, be a custom error code defined by a back-end server) the transaction starts with a call to the 'ErrorDocumentationSetAllow' API (requiring a Valid previous user login, a solution token, the error code, the documentation string and the language it is express in as its parameters) and ends with a call to the 'ErrorDocumentationSetCommit' API.

Across the whole design of our cloud-based time-limited transaction manager, all '…Commit' APIs require just a single parameter: the operation handle of the corresponding '…Allow' API call which started the transaction to be committed. As this operation handle is available only to the caller of the '…Allow' API (and each call returns a different value), we assure each API caller only can commit his own transactions (and only before their 'time to die' has been reached).

In short, this means that our time-limited transaction concept is just implemented by '…Allow' and '…Commit' API calls. A successful '…Allow' API call (it could fail for various reasons; for example, using an already 'died' login) starts a transaction, which will remain active until the corresponding '…Commit' call is received by our transaction manager's single entry point engine, or the transaction is ended automatically because it remained active without a corresponding '…Commit' call being received until its 'time-to-die' has been reached.

US Patent Requested