A Pattern Language for Resource Management in Three Tier Architectures

1
A Pattern Language for Resource Management in
Three Tier Architectures

• Prashant Jain,
• Michael Kircher,
• and Kirthika Parameswaran

2
Background

• Effort started at The Jini Pattern Language
  Workshop, OOPSLA 2000
• Realized that Resource Management forms the heart
  of ad hoc networking technologies such as Jini
• Discovered and documented the Pattern Language
• Forms a subset of the Three-Tier Architecture
  Pattern Language
• Submitted the Pattern Language to EuroPLoP 2001

3
Fundamental Forces
Presentation

• Scalability
• Distribution of application components
• Reliability
• Multiple levels of redundancy
• Flexibility
• Separation of business logic from
• presentation logic
• Reusability
• Multiple layers help in implementing
• reusable components

N Layers
Business Logic
Data
4
Resource Management

Network Connections and GUI objects
Presentation Layer
Loaded Components
Application Layer
Database Connections
Persistency Layer
5
Motivating Example

• Say we want to
• Build an ad hoc network of mobile devices
• Transparently distribute and acquire services in
  the network
• Restrictions and Requirements
• Mobile devices have limited resources
• Can not accommodate multiple services
  simultaneously
• Services no longer needed should be automatically
  removed
• Should require no user intervention

6
Forces

• Optimality
• Unnecessary resource acquisitions should be
  avoided.
• System load caused by unused resources must be
  minimized.
• Simplicity
• It should be optional for a user to explicitly
  release the resources that the user no longer
  needs.
• Availability
• Resources not used by a user, or no longer
  available should be freed as soon as possible to
  make them available to new users.
• Lifecycle
• The frequency of use of a resource should
  influence the lifecycle of a resource.

7
Forces

• Control
• Resource release should be determined by
  parameters such as type of resource, available
  memory and CPU load.
• Actuality
• A user should not use an obsolete version of a
  resource when a new version becomes available.
• Transparency
• The solution should be transparent to the user.
• The solution should incur minimum execution
  overhead and software development complexity.

8
Lazy Acquisition Pattern

• Abstract
• Describes how services including resources can be
  acquired on demand at the latest possible point
  in time in order to avoid unnecessary resource
  consumption.
• Structure
• A resource provides some kind of functionality or
  service.
• A user uses a resource and can include an
  application or an operating system.
• A virtual proxy intercepts the use of a resource
  making it available dynamically.
• A resource environment manages several resources
  and recycles unused resources.

9
Eager Acquisition Pattern

• Abstract
• Describes how services including resources can be
  acquired in advance to ensure their availability
  when they are needed.
• Structure
• A resource provides some kind of functionality or
  service.
• A user uses a resource and can include an
  application or an operating system.
• A virtual proxy intercepts the use of a resource
  making it available dynamically.
• A resource environment manages several resources
  and recycles unused resources.

10
Leasing Pattern

• Abstract
• Describes the availability of a service in terms
  of time-based resource reservation with a service
  provider. This allows the service to cope with
  partial failure and to avoid accumulation of
  outdated and unwanted information
• Structure
• A resource provides some type of functionality or
  service.
• A lease provides a notion of time that can be
  associated with the availability of a resource.
• A grantor grants a lease on a resource.
• A holder obtains a lease on a resource and then
  uses the resource.

11
Evictor Pattern

• Abstract
• Describes how resource consumption can be
  optimized by strategizing eviction of resources
  consumed by services.
• Structure
• A resource provides some type of functionality or
  service and includes local as well as distributed
  objects and services
• A user uses a resource and can include an
  application or an operating system.
• An evictor evicts resources based on one or more
  eviction strategies.
• An eviction strategy describes the criteria that
  should be used to determine if a resource should
  be evicted or not.

12
Example Resolved

• A mobile device should load a service only when
  needed Lazy Acquisition
• The service should be acquired for a specified
  duration of time Leasing. Once the lease
  expires the device can no longer use the service
• Once the service is no longer going to be used,
  it can be automatically removed using Evictor

13
References

• GHJV E. Gamma, R. Helm, R. Johnson, J.
  Vlissides Design Patterns Elements of Reusable
  Object-Oriented Software, Addison-Wesley, 1995
• Jain01 P. Jain, Evictor Pattern, Pattern
  Language of Programs conference, Allerton Park,
  Illinois, USA, September 11-15, 2001
• JaKi00 P. Jain and M. Kircher, Leasing Pattern,
  Pattern Language of Programs conference, Allerton
  Park, Illinois, USA, August 13-16, 2000
• Kirc01 M. Kircher, Lazy Acquisition Pattern,
  European Pattern Language of Programs conference,
  Kloster Irsee, Germany, July 4-8, 2001
• POSA1 F. Buschmann, R. Meunier, H. Rohnert, P.
  Sommerland, and M. Stal Pattern-Oriented
  Software ArchitectureA System of Patterns, John
  Wiley and Sons, 1996
• POSA2 D. Schmidt, M. Stal, H. Rohnert, and F.
  Buschmann Pattern-Oriented Software
  Architecture Patterns for Concurrent and
  Distributed Objects, John Wiley and Sons, 2000