1. © Siemens AG, CT SE, Prashant Jain, October 15, 2001 C O R P O R A T E T E C H N O L O G Y OOPSLA 2001 Workshop Software & Engineering Architecture 1 A Pattern Language for Resource Management in Three Tier Architectures Prashant Jain, Michael Kircher, and Kirthika Parameswaran

2. © Siemens AG, CT SE, Prashant Jain, October 15, 2001 C O R P O R A T E T E C H N O L O G Y OOPSLA 2001 Workshop Software & Engineering Architecture 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. © Siemens AG, CT SE, Prashant Jain, October 15, 2001 C O R P O R A T E T E C H N O L O G Y OOPSLA 2001 Workshop Software & Engineering Architecture 3 Fundamental Forces N Layers Presentation Business Logic Data 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

4. © Siemens AG, CT SE, Prashant Jain, October 15, 2001 C O R P O R A T E T E C H N O L O G Y OOPSLA 2001 Workshop Software & Engineering Architecture 4 Resource Management Network Connections and GUI objects Loaded Components Database Connections Presentation Layer Application Layer Persistency Layer

5. © Siemens AG, CT SE, Prashant Jain, October 15, 2001 C O R P O R A T E T E C H N O L O G Y OOPSLA 2001 Workshop Software & Engineering Architecture 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. © Siemens AG, CT SE, Prashant Jain, October 15, 2001 C O R P O R A T E T E C H N O L O G Y OOPSLA 2001 Workshop Software & Engineering Architecture 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. © Siemens AG, CT SE, Prashant Jain, October 15, 2001 C O R P O R A T E T E C H N O L O G Y OOPSLA 2001 Workshop Software & Engineering Architecture 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. © Siemens AG, CT SE, Prashant Jain, October 15, 2001 C O R P O R A T E T E C H N O L O G Y OOPSLA 2001 Workshop Software & Engineering Architecture 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. © Siemens AG, CT SE, Prashant Jain, October 15, 2001 C O R P O R A T E T E C H N O L O G Y OOPSLA 2001 Workshop Software & Engineering Architecture 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. © Siemens AG, CT SE, Prashant Jain, October 15, 2001 C O R P O R A T E T E C H N O L O G Y OOPSLA 2001 Workshop Software & Engineering Architecture 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. © Siemens AG, CT SE, Prashant Jain, October 15, 2001 C O R P O R A T E T E C H N O L O G Y OOPSLA 2001 Workshop Software & Engineering Architecture 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. © Siemens AG, CT SE, Prashant Jain, October 15, 2001 C O R P O R A T E T E C H N O L O G Y OOPSLA 2001 Workshop Software & Engineering Architecture 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. © Siemens AG, CT SE, Prashant Jain, October 15, 2001 C O R P O R A T E T E C H N O L O G Y OOPSLA 2001 Workshop Software & Engineering Architecture 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