Introduction

With the growth of mobile devices and computer systems, many advanced and large applications run on these devices where resources are compact. Even though nowadays there are devices with more heavy capacity of resources still sometimes the poor design of a software can deplete all the resources of the system and so the developer need to design the app and software in such  a way that the resources are used judiciously, so that the neither the app or software crashes nor it slows down the normal user interaction of the clients with the devices. In terms of software systems a resource can be memory, synchronization primitives, file handles, network connections, security tokens, database sessions, and local as well as distributed services. It can be a heavyweight object such as an application server component or it can also be a fine-grained lightweight object such as a file handle. It can be categorised in many ways and broadly it is of two types reusable and usable and another way of categorisation is based on how the resources are accessed or used and many more types of classification. [2] As described in [2] managing resources is hard; managing them efficiently is even harder. Resource management in Software systems is the process of controlling the availability of resources to the resource users. Resource users can be anything that acquires accesses or releases resources. Resource management includes ensuring resources are available when needed, that their lifecycle is deterministic and they are used and released at a timely manner to ensure the liveliness of the system that uses them.

 Resource management challenges 

Some non-functional requirements like scalability, flexibility, stability, security and quality of service depends on effective resource management. These forces together make effective software. These forces can be independently addressed but to balance among several of these is a challenge. So we have to either trade-off between these forces or try to balance all these forces while building. To address these forces we have to do right from the beginning of system development i.e. starting from resource acquisition to resource access to the resource release. A system whose performance is critical must have high throughput and low latency. So the challenge to have a good performance software system is to avoid unnecessary resource acquisition, access and release and which in turn if not handled could have incurred overhead and delay. To address the scalability the resource management and their lifecycle play an important role. Apart from this the synchronization and release of resources accounts for larger CPU cycles. The system must also be able to scale down which means the software designed for larger systems has to adapt to smaller systems and run with fewer resources. The system must be predictable which means the maximum response time must be predictable. While designing systems care must be taken when optimizations are applied. We should also remember that predictability must not be compromised in lieu for scalability and performance. The system must be flexible enough for customizations and configurations and for this the resource acquisition, release and lifecycle control of resources must be flexible and for this other forces must not be compromised. To make a system stable frequent resource acquisition and release must be managed properly else the system might be unstable or inconsistent. Resource acquisition, access and release must leave a software system in a consistent state i.e. any interdependencies among resources must be well managed.

Selection of resource management patterns 

While developing application the design techniques that must be used for resource management depends largely on the domain, system constraints, system requirements and also the set of forces that the pattern helps to address. To address performance factor eager acquisition, caching and pooling pattern can be used. Eager acquisition speeds up the initial resource access and thus improves the response time while caching pattern improves the performance by avoiding excessive resource acquisition and pooling improves the performance as it helps reduce the time spent in costly release and reacquisition of resources. The leasing, evictor, coordinator, caching, pooling, lazy acquisition, partial acquisition and resource life cycle manager patterns help to address the system scalability. The leasing and evictor frees the unused resources and hence it reduces the resource starvation which increases system scalability and stability. Coordinator provides a solution that is scalable with number of participants in system. Caching and pooling avoids excessive resource acquisition and release and thus it improves scalability. Lazy and partial acquisition ensures that resources are needed only when needed and thus it reduces the number of resources needed at a particular time. Resource life cycle manager manages life cycle of resources and ensures that the optimal resources are maintained through a session which helps in scalability. Eager acquisition pattern improves predictability by avoiding expensive resource acquisition at run time and thus ensures that the response time for resource acquisition and access is fairly consistent. The look up pattern decouples the resource providers for resource users which makes the system flexible. The partial and lazy acquisition allow for flexibility at different level by allowing flexible exchange of acquisition strategies. Lazy acquisition, eager acquisition, pooling, evictor, leasing, resource life cycle manager are the design patterns that address the stability of the system. Lazy and eager acquisition minimises the resource consumption ensuring system stability. Pooling improves stability by avoiding regular low level acquisition and release of resources. Evictor reduces the probability of resource exhaustion and thus improves the stability. The leasing pattern reduces the wastage of unused resources and also it ensures that the resource users do not access invalid resources. This behaviour of leasing improves the stability. Resource life cycle manager makes the system stable by avoiding situations in which a user may cause resource starvation by acquiring resources from the system directly. The coordinator pattern helps to ensure consistency among local as well as the distributed resources. For small systems with limited memory, paging which is the specialization of the caching can be used. Similarly variable allocation, pooled allocation and fixed allocation are specialization of lazy acquisition, eager acquisition and pooling. The garbage collector is same as evictor pattern. These patterns can be used in systems with low memory.

Resource management consists of three parts. These are resource acquisition, resource life cycle and resource release. To manage all these together is the resource management. The life cycle of the resource begins with the resource acquisition. By optimising the resource acquisition time the system performance can be improved. Before the resource is acquired finding of resource is important and look up pattern addresses this issue. After finding the resource it must be acquired and to improve the acquisition time lazy and eager acquisition can be used. Lazy acquisition defers acquisition of resources to the latest possible time whereas the eager acquisition strives to acquire the resources as early as possible. Resources that get acquired if not used immediately can lead to their wastage and this can be addressed by lazy acquisition and this it helps in improving the system stability. On the other hand eager acquisition improves the system performance and predictability by accessing the resources at correct time. A large and unknown resource may not be needed as it is and thus a scaled down version of it can be used and so in this case partial acquisition helps to address this. The look up pattern can be used for reusable, non-reusable resources, concurrently accessible resource and exclusive resource as it focuses on providing access to resources and does not deal with how resources are actually used. The lazy, eager and partial acquisition pattern can also be used from both reusable and non-reusable resources. After a resource is acquired the management of the resource life cycle is very important. This involves making the resource available for all users, handling inter-resource dependencies, acquiring any dependent resources if necessary and finally releasing of resources which are no longer needed. The caching pattern can be used to manage the life cycle of the resources. It maintains the identity of the resources. The pooling pattern optimizes acquisition and release of resources but does not maintain the identity of the resources. Pooling is therefore used in stateless resources. Both the caching and pooling are used for reusable resources that are serially being used by users. In some cases it can be used for concurrently accessible resources. Two or more entities sometimes interact with each other and produce changes to a system and any changes that are produces should keep the system in consistent state and for this coordinator pattern can be used. The resource life cycle pattern can be used to manage the resource life cycle for all types of resources. At the end timely release of resources is also important to keep the system stable and to prevent resource exhaustion. Both the leasing and evictor pattern helps in release of the resources in timely manner. The leasing pattern uses time based methodology to release resource where the resources are automatically released when the lease expires and they are not renewed again. The evictor pattern determines when to release what resource. Please refer figure 1.3  for the resource pattern map with the non-functional requirements.

                                     Figure 1.3 Selection of resource management pattern

With the above knowledge we need to know how to apply the resource management. Resource management is a four step process. First we need to identify the key components by analysing the functional, non-functional requirements and also by analysing the runtime behaviour by profiling to identify intensive resource use. The key components are those that consume the most expensive resource. Second, we need to identify the initial context of the application. For example the lazy acquisition is applicable to the initial contexts where there is a large time lag between resource acquisition and release. So the resulting context after applying the pattern is that the resources are acquired as late as possible. But this may lead to performance factor at run time. Third, we need to identify the hot spot which can be a resource consumption, performance, scalability and stability. In case of more resource consumption all components that consume resources dynamically can be declared as possible hot spots. Fourth is the application of pattern by finding the root cause of the hot spots based on the category and the context it belongs. It is possible that by applying patterns one set of issue get resolved while the other issue may creep in and in this case additional set of patterns can be applied.

Concept behind each resource management pattern and their usage

In this section instead of discussing on all the patterns that I have discussed in section 1.3, I will choose the 5 main patterns and will discuss on the same.

Lookup pattern: It is used in systems where resource users need to find & access local & distributed resources. The problems associated with it is How can a resource user find out on demand what resources are available in its environment? How can a resource user obtain an initial reference to a resource provider that offers the resource? Look up pattern provides the solution by providing a lookup service that allows resource providers to make resources available to resource users. The resource provider advertises resources via the lookup service along with properties that describe the resources that the resource provider’s provide. It allows resource users to first find the advertised resources using the properties, then retrieve the resources, & finally use the resources. Refer figure 1.4.a for the class diagram design .

                  fig1.4a Look up pattern design

For example, a client would need a reference of the Transaction Manager to participate in distributed transactions how can a client obtain the initial reference to an object that the client wants to access? By using Look up pattern the example issue can be resolved as follows. The server that creates the Transaction Manager should register the reference of the created Transaction Manager with the Lookup Service. The server is therefore the resource provider. A client can obtain the object reference of the Transaction Manager from the Lookup Service. Refer figure 1.4.b for the sequence diagram of the look up pattern example solution.

                                  figure1.4b Sequence diagram of look up pattern example solution [2]

Look up pattern is commonly used in Jini services are registered with Jini’s lookup service, & these services are accessed by users using Jini’s discovery protocol. In COM+ the Windows Registry is a lookup service that allows resource users to retrieve registered components based on keys. In Eclipse the eclipse plug-in registry holds a list of all discovered plug-ins, extension points, & extensions & allows clients to locate these by their identity.

Lazy acquisition: It is used for the context in a system with restricted resources that must satisfy high demands, such as throughput & availability. To design this following are the problems associated with it. Reduction of the initial cost of acquiring the resources and if systems were to acquire all resources up front, a lot of overhead would be incurred & a lot of resources would be consumed unnecessarily. So the solution is to acquire resources at the latest possible time. The resource is not acquired until it becomes unavoidable to do so and introduce a resource proxy that hides the lazy acquisition from the resource user. Refer figure 1.4.c for the lazy acquisition class diagram .

                                     figure1.4c Lazy Acquisition Class Diagram[2]

For example a Picture Archiving & Communication System (PACS) provides storage of patient data and the data includes patient details, such as address information, as well as digitized images & is represented by business objects. So for a patient with a long medical history & several digitized images, fetching all the data & creating the corresponding business object(s) can take a lot of time. So we can use here the Lazy Acquisition pattern by not fetch any image data, when fetching information for a particular patient. Create an image proxy for each image in the patient record returned and when an image is actually viewed, it is fetched (lazily) from the image store. Some of the specialized patterns to Lazy Acquisition are Lazy Instantiation, Lazy Loading and Lazy State. Refer figure 1.4.d for sequence diagram of the lazy acquisition pattern example solution.

                           fig1.4d Sequence Diagram Of Lazy Acquisition Pattern Example[2]

Some of the examples where this pattern is used is in J2EE: EJB containers use Lazy Loading & Lazy Instantiation to ensure that only components that are actually used by clients are active. Java Server Pages (JSPs) are typically compiled into servlets only when they are actually accessed, rather than when they are deployed. Eclipse plugin: Actual logic of a plug-in, which is contained in Java archives (JAR), is loaded lazily on first use of any of the plug-in’s functionality.

Caching pattern: It is used in systems that repeatedly access the same set of resources & need to optimize for performance. The problem associated for this is Repetitious acquisition, initialization, & release of the same resource causes overhead and so how can you reduce the acquisition, access, & release cost of frequently used resources to improve performance? Caching provides the solution by temporarily storing the resource in a fast-access buffer called a cache. Use the cache to fetch & return the resource instead of re-acquiring it. The cache identifies resources by their identity, such as pointer, reference, or primary key. Refer figure 1.4.e  for the design diagram of caching pattern.

                                                        fig1.4e Caching Pattern Design [2]

For example in a Network management system that needs to monitor the state of many network elements, establishing a new network connection for every network element selected by the user & destroying it after use incurs overhead in the form of CPU cycles. The average time to access a network element can be too large. So how can the average time to access a network element are optimized, while also reducing the number of network connections that are created & destroyed? It can be done by using Caching pattern. Implement a cache of connections of network elements. On user access of a specific network element, the connection to the network element is acquired. When the connection is no longer needed, it is not destroyed but is added to the cache. Later, when a new request for the connection arrives, the connection is acquired from the cache, thus avoiding high acquisition cost. Transparent Cache, Read-Ahead Cache and Cached Pool are some of the variants of it. Refer figure 1.4.f  for the sequence diagram of caching pattern solution of the example.

                      figure1.4f Sequence Diagram Of Caching Pattern Example[2]

Some of the uses of caching pattern are as follows. In EJB: EJB entity beans represent database information in the middle tier. The entity beans therefore help avoid expensive data retrieval (resource acquisition) from the database. Web proxy: A Web proxy is a proxy server located between a Web browser & Web servers. The Web proxy caches a Web page that is fetched by a browser from a Web server, & returns it when a subsequent request is sent for the same page.

Resource life cycle manager: It can be used in the context where large & complex systems require simplified management of lifecycle of their resources. Resources in systems can be of many different types, such as network connections, threads, synchronization primitives, servants & so on. Resources of the same or different types might depend on each other. So how can the lifecycle of interdependent resources are managed such that it does not make the business logic of the system hard to understand & manage? Resource life cycle manager provides the solution by separating resource usage from resource management. Introduce a separate Resource Lifecycle Manager whose sole responsibility is to manage and maintain the resources of a resource user .The Resource Lifecycle Manager maintain the dependencies between resources. Refer figure 1.4.g for the design diagram of this pattern.

fig1.4g Resource Life Cycle Manager Class Diagram[2]

For example in Distributed system that needs to service thousands of clients. Clients establish connections to communicate with remote services. The complexity in managing the lifecycles of connections can affect the core functionality of the application. Resource management can make its business logic hard to understand & maintain due to the entangled connection-management code. Then how can the lifecycle of interdependent resources are managed while ensuring that the business logic of a system does not become too hard to understand & maintain? It can be done by applying the Resource manager life cycle pattern. Introduce a component that is responsible for the resource lifecycle management & hence free the application from this responsibility. The clients then use the resource lifecycle manager to request new connections to the server. Once these connections are given to the clients, their lifecycle is managed by the resource lifecycle manager. Some of the places where resource life cycle manager pattern is used are as follows: Grid computing: A resource lifecycle manager is typically used to manage the local resources of computers participating in a grid .Resource lifecycle manager ensures that resources in a grid are available & fulfils local as well as distributed requests to those resources. In remote accessing middleware: Middleware technologies such as CORBA & .NET remote access ensure the proper lifecycle management of resources such as connections, threads, synchronization primitives, & servants implementing the remote services.

Leasing pattern: It is used in systems where resource use needs to be controlled to allow timely release of unused resources. How can resources that are not used by a resource user or no longer available be automatically freed as soon as possible to make them available to new resource users? How can the system load caused by unused resources be minimized? How can it be ensured that a resource user does not use an obsolete version of a resource when a new version becomes available? To address these entire how’s question leasing pattern can be used. Introduce a lease for every resource that is held by a resource user. A lease is granted by a grantor & is obtained by a holder. A lease specifies a time duration for which the resource user can hold the resource. Once the time duration elapses, the lease is said to have expired & the corresponding resource is released. Refer figure 1.4.h for the design diagram of the leasing pattern.

    fig1.4h Leasing Pattern Design Diagram[2]

For example consider a Quote service, which provides stock quotes to clients. Reference of Quote service is made available to clients via Lookup service. Suppose the Quote service were to crash & not come up again. Quote service reference would become invalid but would still be available via the Lookup service. How can the invalid Quote service reference be automatically removed at the Lookup service? This can be done by Leasing. Server containing Quote service is resource user & Lookup service is resource provider. When the Quote service is registered at the Lookup service, a lease is created. The lease specifies the duration for which the Quote service is available. Once the lease expires, the Lookup service automatically removes the Quote service reference. Refer figure 1.4.i  for the sequence diagram of the leasing pattern solution.

figure1.4i Sequence Diagram Of Leasing Pattern Example Solution[2]

Some of the places where leasing pattern is used are as follows. Web-based e-mail accounts: Many web-based e-mail accounts, for example MSN Hotmail or GMX become inactive automatically if not used for a certain period of time. The time duration can be regarded as a lease whose renewal requires use of the email Account. Dynamic Host Configuration Protocol (DHCP): A DHCP lease is the time that the DHCP server grants permission to the DHCP client to use a particular IP address.

Refer to figure 1.4.j for resource management pattern map on which all patterns can be clubbed.

                                                                   fig1.4j Resource Management Pattern Map

Advantages and disadvantages of each resource management pattern

Lookup pattern:

Advantages:  User can find out what resources are available in its environment. The lookup service allows a resource user to obtain initial resources. In distributed systems a bootstrapping protocol allows the resource user to find the lookup service and then use it to find other distributed services. It provides the location transparency by shielding the location of the resource providers from the resource users. Distributed systems based on look up service are very simple and need no manual configuration. Resources can be chosen based on properties which allow fine grained matching of user needs with resource advertisements.

Disadvantages: If an instance of a lookup service crashes, the system can lose the registered references along with the associated properties. This is knows as single point of failure. Once the lookup service is restarted, the resource providers would need to re-register the resources with it unless the lookup service has persistent state. This can be both tedious and error-prone, since it requires resource providers to detect that the lookup service has crashed and then restarted. It can also act as a bottleneck, affecting system performance. A better solution, therefore, is to introduce replication of the lookup service. Another issue with this pattern is the dangling reference. The registered references in the lookup service can become outdated as a result of the corresponding resource providers being terminated or moved. In this case the leasing pattern can help. Problems can occur when similar resources with the same properties are advertised but replication is not wanted. Depending on the implementation of the lookup service, multiple instances of the same resource may be registered erroneously, or one resource provider may overwrite the registration of a previous resource provider. Enforcing that at least one of the properties is unique can avoid this problem.

Lazy Acquisition:

Advantages: It makes sure that not all resources are acquired upfront which helps to minimize the possibility that the system will run short of resources. It also avoids needless acquisition of resources upfront and thus reducing the possibility of resource exhaustion. It makes sure that the resources that are not needed immediately are acquired at later stage. This helps to optimize system start up time.

Disadvantages: This pattern requires additional space overhead as additional memory is required for proxies resulting from the indirection. It introduces significant time delay when a resource is acquired and also overhead during regular program execution due to additional level of indirection and for a real time system such behaviour is unacceptable.

Caching pattern:

Advantages: It improves the accessing of the frequently used resources to many folds. It maintains the identities of the resources so if the same resource needs to be accessed again, it need not the acquired or fetched from somewhere. Caching helps to avoid the cost of resource acquisition and release. This especially pays off in frequent usage, therefore improving scalability. Caching ensures that the complexity of acquiring and releasing resources from a resource user perspective does not increase, apart from the additional step required to check the availability of the resource in the cache. Caching resources increases availability of resources whose resource providers are temporarily unavailable, since the cached resources are still available. Since Caching reduces the number of releases and re-acquisitions of resources, it reduces the chance of memory fragmentation leading to greater system stability.

Disadvantages: Depending on the type of resource, complexity increases, because consistency between the state of the cached resource and the original data, which the resource is representing, needs to be ensured. This complexity becomes even worse in clustered environments, which in some extreme cases might render the pattern useless. Changes to the cached resource can be lost when the system crashes. However, this problem can be avoided if a synchronized cache is used. The run-time footprint of the system is increased, as possibly unused resources are cached. However, if an Evictor is used, the number of such unused cached resources can be minimized.

Resource life cycle manager:

Advantages: Resource Lifecycle Manager Pattern allows coordinated and centralized lifecycle management of resources. This in turn allows for better application of optimizations and a reduction in overall complexity. Using the Resource Lifecycle Manager Pattern allows for more efficient management of resources, allowing applications to make better use of available resources, which in turn allows higher application load. The Resource Lifecycle Manager pattern can ensure that various levels of optimizations are enabled to achieve maximum performance from the system. By analysing resource use and availability, it can use different strategies to optimize system performance. The Resource Lifecycle Manager pattern makes management of resources transparent to resource users. Different strategies can be configured to control resource creation and acquisition, management and release. By decoupling resource usage from resource management, the RLM reduces complexity of use and thereby makes the life of a resource user easier. The Resource Lifecycle Manager pattern can ensure that a resource is allocated to a user only when a sufficient number of resources are available. This can help make the system more stable by avoiding situations in which a resource user can acquire resources from the system directly, causing resource starvation.

Disadvantages:  A bug or error in the RLM can lead to the failure of large parts of the application. This is known as single point of failure. Redundancy concepts help only partly, as complexity is further increased and the performance is further constrained. When individual resource instances need special treatment, the Resource Lifecycle Manager pattern might be too inflexible.

Leasing Pattern:

Advantages: The Leasing pattern simplifies the management of resources for the resource user. Once the lease on a resource expires and is not renewed by the resource user, the resource can be released automatically. A resource provider can control resource use more efficiently through time-based leases. By bounding resource use to a time-based lease, the resource provider can ensure that unused resources are not wasted by releasing them as soon as possible, allowing them to be granted to new resource users. This can lead to minimization of the overall system load caused by unused resources. The Leasing pattern helps to increase system stability by ensuring that resource users do not access invalid resources. In addition, the Leasing pattern helps to reduce wastage of unused resources, and therefore helps to avoid shortage of resources.

Disadvantages: The Leasing pattern requires an additional object, a lease, to be created for every resource that is granted by a resource provider to a resource user. Creating a pool of lease objects and reusing them with different resource allocations can help to simplify this problem. In addition, on lease expiry, the lease grantor needs to send a notification to the resource user, adding additional overhead. The Leasing pattern requires the application logic to support the concept of leases as the glue between the resource providers and resource users.. Putting repetitious leasing code into a framework alleviates the coding complexity. Both the resource provider and the resource user need to be able to determine when a lease will expire. This requires support for some kind of a timer mechanism, which may not be available in some legacy systems. If however the legacy systems are event-based applications, they can be made timer-aware with very little overhead.

Conclusion

Managing resources effectively and efficiently is a challenge that spans domains and systems, as well as layers within a system. With the onset of grid computing resource management pattern will play a vital role in its success. Look up and Resource manager life cycle fits well for this. As the world is becoming small and there is hype in mobile application and also users want the application they use to be very rich in UI and also responsive. However, a designer cannot address all the forces of resource management in any application and hence need to trade off among these forces basing on the context and goal of the system they will be designing. This essay just touched upon some patterns however there is lot more to learn regarding resource management.

  References

[1] Gamma,E.,Helm,R.,Johnson,R.,Villsides,J.(1997)“Design Patterns- Elements of reusable Object oriented software”,August 1997,Addison Wesley

[2] Michael,K.,Prashant,J.,John.(2004) “Pattern oriented software architecture- pattern of Resource management”,Vol 3,2004,Wiley & Sons

[3] “Observer Design Pattern”. [Online]

.Available from: http://javapapers.com/design-patterns/observer-design-pattern/ (Accessed:07 September 2014)

[4] “Observer design pattern in Java- Tutorial”. [Online].Available from: http://www.vogella.com/tutorials/DesignPatternObserver/article.html (Accessed:09 September 2014)

[5]“Observer pattern”. [Online].Available from: http://www.tutorialspoint.com/design_pattern/observer_pattern.htm (Accessed:07 September 2014)