| Name (Title) |
Singleton Resource Manager |
| Description |
This pattern can be used to manage resources where many consumers can have a relationship with one resource. |
| Alias |
Many to One Resource Manager |
| Intent |
The pattern describes two main interfaces to satisfy consumer and internal state maintenance needs. Since there is only one resource provided by the allocation manager, the resource can be implemented as a singleton. The resource state table keep track of consumers who have acquired the resource. |
| Motivation |
In automated distributed systems management, there are several resources that are consumed and released throughout the life of a service (generally as parameters to a provisioning or state change operation). In large-scale environment such as clouds, the complexity of these resources easily goes beyond paper or spreadsheet management, and requires an automated management system. |
| Applicability |
This pattern applies when you want to automate some or all of a service lifecycle, and the service requires initialization or configuration questions to be dynamically answered. The specific types of questions addressed by this pattern are ones where you want the same answer (object) returned regardless of who is asking. An example question is: "Which DNS server should I use?" |
| Structure |
 |
| Participants |
Resource consumers request resources for their configuration needs. The resource allocation manager is responsible for satisfying the resource requests. The resource state manager is responsible for tracking the available resources and their respective states. |
| Collaboration |
The resource consumer interacts with the queue via the interface to acquire or release one or more instances of the queue's resource. The queue is responsible for satisfying consumer requests by returning the singleton resource object for an acquire request, or calling the resource state table interface to synchronize the state for a release request.
 |
| Consequences |
The primary benefit is that resources can be tracked and reported on. There is no duplication of resource instances. Deeper system automation is enabled. The primary risks relate to proper definition of the rules that define and control the resource state, and the reliance on the external requester to properly communicate the release of resource instances. |
| Implementation |
It might seem unnecessary to track the state of a singleton resource, but consider the case of a DNS server. When you want to change the DNS server address, you would like to know who is using the address so they can also be updated. Care should be taken to ensure that robust persistence services are in place for the resource states. There may be a need for an auditor of resource usage in the environment to account for misbehaving clients. |
| Known uses |
|
| Related patterns |
Configuration Resource Manager, Pooled Resource Manager, Generated Resource Manager |
| Author |
John Stanford < john.stanford at sun.com > |
| Reviewer |
Name and email of Cloud Pattern COE reviewer |
Sign up or Log in to add a comment or watch this page.