Front-end Software Upgrades
Upgrading end-user software to a new version in the cloud computing environment can be a real challenge, as thousands or millions of users will need to download the new version of the software, often from a single or a few servers, hence overloading these. Situation can even be worse for smaller software companies, where the same server used for downloads is used as a back-end server to run transactions. Warranting smooth upgrades is another of our transaction manager's functionalities designed to be used by any end-user software developer.
The first step for a developer to upgrade his end-user software is obviously to develop the code for this new version: this task cannot be automated. However, the second step, which consists in having users transition from the old to the new piece of software, can be delegated to our cloud-based time-limited transaction manager by means of the 'SolutionUpgradeAllow' and 'SolutionUpgradeCommit' APIs. In order to call 'SolutionUpgradeAllow', the developer provides not only the solution tokens for the old and new software, the URL where the new software is available for users to download, but two fundamental pieces of data: the timestamp for starting and the duration of the upgrade process. We name this period of time during which the upgrade will take place as 'decayment', inspired on the random decay of radioactive atoms: the old version 'decays' gradually, being replaced by the new one.
Our decayment process consists in randomly and proportionally deciding which users are directed to the software upgrade based upon the decayment period: for example, if the decayment period is set to ten days, our transaction manager will randomly choose ten percent of users to migrate during each of those ten days. This random decision is made when the user requests using the solution being upgraded by having his old version end-user software calling the 'SolutionLoginAllow' API: if the solution has already started its upgrade period, probability of being forced to migrate gets gradually higher along the decayment period.
The 'SolutionLoginAllow' API returns a specific error code to signal to its caller (the now deprecated end-user software) that the specific solution is being upgraded: at this moment, the end-user software guides the user to do so, based on the information retrieved through calls to the 'SolutionUpgradeStartGet', 'SolutionDecaymentGet', 'SolutionUpgradeToGet' and 'SolutionUpgradeURLGet' API calls, which provide, respectively, the start date of the upgrade process, its duration, the name of the solution to be upgraded to and the URL where the new software can be accessed.
Developers may want to apply the software upgrade to a few users of a new version of their software (for example, to test a new feature being considered on a limited group of users, or for testing a beta version - prior to general release version). In order to handle this situation, our transaction manager's API includes 'UserSolutionUpgradeAllow' and 'UserSolutionUpgradeCommit', which work following exactly the same principles as a general upgrade, but being conducted on a single user per upgrade transaction.
The call to the 'SolutionLoginAllow' API will fail with a specific error code when the individual user is being forced to upgrade. In this case, the end-user software can guide the individual user based on information retrieved through calls to the 'UserSolutionUpgradeStartGet, 'UserSolutionDecaymentGet', 'UserSolutionUpgradeToGet' and 'UserSolutionUpgradeURLGet' API calls.
US Patent Requested