Resource breakdown structure

Abstract: Resource management architectures implemented in computer systems to manage resources are described. In one embodiment, a general architecture includes a resource manager and multiple resource providers that support one or more resource consumers such as a system component or application. Each provider is associated with a resource and acts as the manager for the resource when interfacing with the resource manager. The resource manager arbitrates access to the resources provided by the resource providers on behalf of the consumers. A policy manager sets various policies that are used by the resource manager to allocate resources. One policy is a priority-based policy that distinguishes among which applications and/or users have priority over others to use the resources. A resource consumer creates an “activity” at the resource manager and builds one or more “configurations” that describe various sets of preferred resources required to perform the activity. Each resource consumer can specify one or more configurations for each activity. If multiple configurations are specified, the resource consumer can rank them according to preference. This allows the resource consumers to be dynamically changed from one configuration to another as operating conditions change.

Abstract: A method and a system for providing resource management in workflow processing of an enterprise include a multi-level resource manager hierarchy. An upper level includes at least one resource manager having data that represents an enterprise-wide view of resource capabilities. A subordinate second level of resource managers provides partial views of the resource capabilities of the enterprise. These partial views may be based upon organizational or physical boundaries. At a lowermost level of resource managers are local resource managers (LRMs) that include data to track individual resources. Above this lowermost level, the resource managers in the hierarchy track the resources based upon types of resources. Thus, a second level resource manager is configured to be aware of availability of a resource type, but not the availability of an individual resource. Also above the lowermost level, the resource managers are configured to exchange requests for the resources using a number of different messages. A Plead message is used to send a request to a higher level manager. On the other hand, a Delegate message is used to send a request to a lower level manager. A Refer message allows a request to be sent horizontally. Report messages are sent among resource managers to allow updates of cache entries regarding capabilities of other resource managers.

Abstract: This paper presents the design and implementation of Shirako, a system for on-demand leasing of shared networked resources. Shirako is a prototype of a service-oriented architecture for resource providers and consumers to negotiate access to resources over time, arbitrated by brokers. It is based on a general lease abstraction: a lease represents a contract for some quantity of a typed resource over an interval of time. Resource types have attributes that define their performance behavior and degree of isolation. Shirako decouples fundamental leasing mechanisms from resource allocation policies and the details of managing a specific resource or service. It offers an extensible interface for custom resource management policies and new resource types. We show how Shirako enables applications to lease groups of resources across multiple autonomous sites, adapt to the dynamics of resource competition and changing load, and guide configuration and deployment. Experiments with the prototype quantify the costs and scalability of the leasing mechanisms, and the impact of lease terms on fidelity and adaptation.