A significant trend in modern computing is for commercial organisations to rent or lease processing resources, and especially Web server capacity, from a service provider, rather than using their own in-house systems. Typically the computer systems are owned and operated by the service provider, but are then used to run various applications as required by the commercial organisations.
A major advantage of this approach for the commercial organisation is that it allows them much more flexibility, especially if their system demands are liable to significant fluctuations on a relatively short timescale. This can often be the case, for example, if a special advertising promotion is being run. This will (hopefully) generate an intense peak of on-line inquiries, orders, and so on. The commercial organisation temporarily acquires the additional computing power to cope with this increase by leasing or renting capacity from the service provider.
Usually a service provider will be hosting multiple applications at the same time, on behalf of one or more organisations. A typical installation for a service provider has multiple computing systems, each comprising one or more domains. Each domain has processing facilities that are largely independent from other domains, and each runs its own operating system.
The advantage of the multi-domain structure is that it provides a flexible and scalable architecture. Thus typically a domain runs only one application at a time. In cases of high demand, multiple domains can then be assigned to the same application (or more accurately, a separate copy of the same application can be run in multiple, different domains) in order to satisfy this demand. Conversely, multiple applications having low priority may in some situations run in parallel on a single domain. This approach is also robust, in that if one particular domain fails, then its processing can be reassigned to one or more other domains.
An important consideration in the operation of such systems is ease of reconfiguration. Thus it can be necessary to assign resources (i.e. domains) from one application to another application relatively quickly in order to meet real-time shifts in demand. An example of where this situation might arise is when the demand for a particular task (such as responding to requests for a given Web site) is significantly greater than anticipated (or indeed a lot less than anticipated). This may involve a re-boot of the relevant domain, for example if the new application is to run on a different operating system from the previous application. It will be appreciated that having to perform such re-configuration for each individual domain represents a time-consuming task.
A further concern for the service provider relates to the security of their systems. Thus the applications that are being run are frequently supplied from the commercial organisation renting or leasing the system. Staff from this organisation may desire some form of management or administrative control over the running of the applications, in order to make real-time changes. Thus if this organisation is running multiple applications across a set of domains, it may want to take responsibility for deciding how many domains to allocate at any given time to a particular application. It may also be desired to modify system behaviour in response to a change in circumstances. For example, if a problem appears in the operation of a particular application, it may be desired to start this application up in one domain in debug mode, in order to try to resolve the problem as quickly as possible.
On the other hand however, the service provider generally wants to restrict the ability of its customers to reconfigure the domains. For example, there is a risk that such reconfiguration might possibly result in the boot code becoming corrupted. If this prevents the system from booting, then there is no software mechanism available to further modify or correct the boot code (since the system cannot initialise itself properly). Furthermore, it is difficult to maintain a reserve or fallback boot code, in that by convention CPUs are generally designed to load boot code from a single, predetermined location. Consequently, corruption of the boot code typically requires an expensive hardware replacement in order to restore a workable boot code to the system.
USPTO Backgrounds
USPTO Backgrounds