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 Architecture—A 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