Pattern-Oriented Software Architecture, Patterns for Resource Management

Michael Kircher, Prashant Jain

• Publisher: Wiley
• Year: 2013
• ISBN:
  9781118725238
• Edition: 1
• Topic: Computer Science
• Subtopic: Object Oriented Programming
• Index: Computer Science

The first volume of the POSA pattern series introduced a broad-spectrum of general-purpose patterns in software design and architecture. The secondnarrowed the focus to fundamental patterns for building sophisticated concurrent and networked software systems and applications. This volume uses design patterns to present techniques for implementing effective resource management in a system.

The patterns are covered in detail making use of several examplesproviding directions to the readers on how to implement the presented patterns. Additionally, the volume presents a thorough introduction into resource management and a case study where the patterns are applied to the domain of mobile radio networks. The patterns are grouped by different areas of resource management and hence address the complete lifecycle of resources: resource acquisition, coordination and release.

Chapter 1

Introduction

“A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.”

Douglas Adams

A resource is an entity that is available in limited supply such that there exists a requestor, the resource user, that needs the entity to perform a function, and there exists a mechanism, the resource provider, that provides the entity on request. In the context of software systems, a resource can include, among other things, memory, synchronization primitives, file handles, network connections, security tokens, database sessions, and local as well as distributed services. A resource can be anything from a heavyweight object such as an application server component [VSW02] to a fine-grained lightweight object such as a file handle.

Determining what is a resource can sometimes be challenging. For example, in programming environments an image, such as a JPEG or GIF file, is often referred to as a resource. In reality, however, there are no acquisition and release semantics defined for an image— instead, it is the data that makes up the image that constitutes a resource. Therefore a more accurate representation would be to treat the memory an image is using as a resource, which needs to be acquired when the image is loaded and released when the image is no longer needed.

There are numerous ways of categorizing resources. In the simplest, resources can be viewed as either reusable or non-reusable. Reusable resources typically are acquired from a resource provider, used and then released. Once the resources have been released they can be acquired and used again. An example of a reusable resource is memory that is allocated by and released to the operating system. Other examples of reusable resources include file handles and threads. Reusable resources are the most important form of resource, because the resource provider typically only has a limited number of resources, and therefore reusing resources that are not consumed makes logical sense. In contrast, non-reusable resources are consumed, and therefore once acquired are either not released, or their release is implicit. An example of a non-reusable resource is processing time in a computing grid [Grid04]—once the processing time is acquired and used, it is gone and cannot be returned.

A different method of categorizing resources is based on how the resources are accessed or used. A resource, once acquired, can be concurrently used either by multiple users or a single user. Examples of resources that are concurrently accessible by multiple users include services, queues, and databases. If a resource that can be concurrently accessed by multiple users has changeable state, then access to that resource needs to be synchronized. On the other hand, if a resource that can be concurrently accessed by multiple users does not have state, then no synchronization is needed. An example of a resource that does not need synchronization is a stateless session bean of a J2EE EJB [Sun04b] application server. On the other hand, a network communication socket is an example of a resource that needs synchronization. A resource that can be concurrently accessed by multiple users need not be acquired explicitly by each user. Instead, resource users can share references to the resource, such that a resource user initially acquires the resource reference and others just use it.

In contrast, if a resource can only be used by a single user, it is called an exclusive resource. An example of an exclusive resource is the processing time of a service. The processing time can be regarded as a non-reusable exclusive resource that is provided by the service, which is the resource provider. Resource users can acquire processing time from the service. The service itself can be regarded as another resource. Acquiring the service means acquiring the processing time.

Exclusive resources can be both reusable as well as non-reusable. However, if a resource is non-reusable, it is always exclusive, since it can only be used by a single resource user. Furthermore, if an exclusive resource is reusable, then it must be serially reusable—the resource is reused over time through the resource provider.

Putting resources into different categories is often neither so simple nor even meaningful. For example, in contrast to the processing time of a service, CPU time can also be regarded as an example of a valuable resource. On one hand one might regard CPU time as a non-reusable exclusive resource that is acquired by a thread, which is the resource user. However, in reality CPU time is not under the control of any application, but is instead under the control of the operating system. From an application perspective, the operating system assigns the CPU to a thread, so the thread does not really acquire the CPU as resource.

Resources often depend on other resources. For example, a file handle as a resource represents a file, which can again be thought of as a resource. Another example is a service that is provided by a component, which consists of thread and memory resources. These resource dependencies can be represented in the form of a graph across multiple layers of resource providers.

The following table summarizes the categorization of resources, giving one example per category:

	reusable	non-reusable
exclusive	memory	processing time
concurrent	read-only object	–

1.1 Overview of Resource Management

Resource management in software systems is the process of controlling the availability of resources to resource users. A resource user can be any entity that acquires, accesses, or releases resources. Resource management includes ensuring that the resources are available when needed, that their lifecycle is deterministic and that they are released in a timely manner to ensure the liveliness of the systems that use them.

Managing resources is hard; managing them efficiently is even harder. Very often the non-functional requirements of a piece of software, such as performance, scalability, flexibility, stability, security, and quality of service, depend heavily on efficient resource management. These non-functional requirements act as forces that influence the way the software is designed and implemented. While each force can be independently addressed when developing a system, it is trying to find a balance among several of these forces that makes it especially challenging. In striking a balance among such forces, several questions and issues need to be addressed. For example, is the performance of a system more critical than making the system flexible and easy to maintain? Similarly, is predictability of the response time of a system more important than its scalability? Is fast initial access to a service more important than the average access time?

Addressing several of these forces simultaneously is challenging. This is because resolving one of the forces often requires compromising some other aspect of the system. For example, flexibility often comes at the expense of system performance. Similarly, optimizing special use cases, such as initial access to a service, usually results in an increase in complexity and very often an increase in latency in handling the average use case. A strong dependency on efficient resource management is tightly coupled with the challenge to address these often conflicting forces. Addressing most of the forces has to do with the way resources are acquired, accessed, and managed in general.

The following major forces need to be considered when designing systems with efficient resource management:

• Performance. A system whose performance is critical has to exhibit many properties. Among these are low latency and high throughput. Since each action typically involves many resources, it is important to avoid unnecessary resource acquisitions, releases, and accesses that incur processing overhead and delay.
• Scalability. Large and complex systems typically have a large number of resource users that access the resources multiple times. In many cases, systems are designed with use cases in mind, defining, for example the number of users to be expected. Very often these use cases are expanded over time as new requirements are added. For example, a new requirement could demand support for more users and higher transfer volumes while having minimum impact on system performance. If a system is able to fulfill these requirements it is said to be scalable. The way resources are managed and the way their lifecycle is managed plays a key role in achieving this goal. Besides the synchronization overhead, the acquisition and release of resources accounts for the largest portion of CPU cycles [SMFG01]. Besides scaling up, it is important to consider scaling down. To scale down means that software that has been designed and developed for large systems has to adapt to smaller systems and run with less resources.
• Predictability. Predictability means the system behaving as it is expected to behave. In systems with real-time requirements, the maximum response time of individual operations must be predictable. To achieve predictability, a system must manage its resources with care. When optimizations are applied, they must not diminish service predictability in favor of performance or scalability.
• Flexibility. A common requirement among systems is ease of configuration and customization. This implies that it should be possible to change the system configuration at the time of compilation, initialization, or run-time. Systems that are truly flexible leave this freedom to their users. In terms of resource management, therefore, the mechanics of acquisition, release and lifecycle control of resources need to be flexible, while still preserving performance, reliability, and scalability requirements.
• Stability. An important requirement of software systems is that frequent resource acquisition and release should not make the system unstable. Resource allocation and management must be done in a manner that leads to efficient use of resources and avoids scenarios of resource starvation that can lead to system instability. If multiple resources interact, or are involved as a group in any action, it has to be ensured that the system does not end up in an inconsistent state due to the failure of one or more resources.
• Consistency. All resource acquisition, access, and release must leave a software system in a consistent state. In particular, any inter-dependencies among resources must be well-managed to ensure system consistency.

Therefore, as can be seen, most of these forces are interdependent, and hence it is difficult to tackle one without influencing others. This is what makes resource management so hard and why it is important to address these issues in a well-structured way.

1.2 Scope of Resource Management

Resource management is an important aspect of almost every domain, ranging from small, embedded applications [NoWe00] to large enterprise systems [Fowl02], and even grid computing [BBL02]. Any system can benefit from efficient resource management regardless of the type of resources, or the availability of resources. For example, applications for small and embedded devices typically have limited resources, so the need for good resource management is obvious. The primary limiting factors are CPU performance, the available memory and the small bandwidth of networks and buses. Typical embedded applications include software for mobile phones and handheld devices.

Similarly, large enterprise systems run software for telecommunication switching and e-business applications. Such systems typically base their applications on top of frameworks and server-side component systems. In such systems, efficient resource management is essential to guarantee scalability, since adding additional hardware must be avoided to save cost.

It is common for the need for resource management to be discovered late in the development lifecycle, at the time of system integration and testing, when system analysis and performance analysis are performed. However, making changes to system design by that stage is difficult and costly. It is therefore important to address challenges in resource management early in the lifecycle of a software system.

Resources are acquired from some kind of resource provider. For example, memory is acquired from the operating system. Since acquisition is typically an expensive operation, the lifecycle of the acquired resource must be properly controlled to minimize additional overhead. Since an unused resource can also be considered an overhead, it is therefore important to control their timely release.

While it is important to address the primary forces of a software system that influence resource acquisition, access, and release, it is equally important to find solutions that are simple. Solutions that incur more overhead than benefit are not useful. Effective resource management should therefore result in simple programming models for the application developer. For example, introducing a level of transparency in the way resources are managed can help simplify the developer’s task.

Most modern applications are built in the form of a layered [POSA1] architecture. Typically, an OS abstraction layer forms the lowest layer, followed by a middleware layer [POSA2] [VKZ04], a component or basic services layer [VSW02], and finally the actual application logic layer.

Resource management is not restricted to any of these layers. Instead, it is applicable at all levels of abstraction. For example, OS resources such as file handles and memory need to be handled with care by the OS abstraction layer. Similarly, the middleware layer has to manage many types of resource, such as connections and threads.

Resource management is important not only in local systems, but also in distributed systems. Distributed systems are much more complex to manage, since remote communication is unreliable. As a result, managing resources that are distributed across process boundaries becomes even more difficult.

1.3 Use of Patterns

Patterns help capture best practice in solving problems in almost every domain. Patterns have been applied to areas ranging from the architecture of buildings [Alex79] to the architecture of software systems and to teaching [Peda04]. In this book we specifically look at patterns applied to software architecture.

Patterns in software architecture can show how one or several design principles can be applied in a concrete situation to find an optimal solution. As described in [POSA1], the application of design principles finds its manifestation through many enabling techniques, such as abstraction, encapsulation and modularization. Using patterns can help to identify and document some of the design principles that are above the level of single classes and instances. These identified abstractions can then facilitate reuse of successful software architectures and designs. By reusing successful software architectures, common mistakes and pitfalls in software design can be avoided. For a more in-depth understanding of what a pattern is, as well as a history of patterns, please refer to [POSA1] and [POSA2].

As described earlier, efficient resource management inherently affects the design and development of any kind of software. In a multi-tier system, resource management is important at every tier of the system and even across tiers. It is essential that resource management is implemented properly from a system perspective.

...