© 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...

© 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 1

Software &EngineeringArchitecture

A Pattern Language for Resource Management in Three Tier Architectures

Prashant Jain,

Michael Kircher,

and Kirthika Parameswaran


C O

R P

O R

A T

E

T E

C H

N O

L O

G Y



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


C O

R P

O R

A T

E

T E

C H

N O

L O

G Y



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


C O

R P

O R

A T

E

T E

C H

N O

L O

G Y



Resource Management

Network Connections and GUI objects

Loaded Components

Database Connections

Presentation Layer

Application Layer

Persistency Layer


C O

R P

O R

A T

E

T E

C H

N O

L O

G Y



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


C O

R P

O R

A T

E

T E

C H

N O

L O

G Y



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.


C O

R P

O R

A T

E

T E

C H

N O

L O

G Y



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.


C O

R P

O R

A T

E

T E

C H

N O

L O

G Y



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.


C O

R P

O R

A T

E

T E

C H

N O

L O

G Y



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.


C O

R P

O R

A T

E

T E

C H

N O

L O

G Y



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.


C O

R P

O R

A T

E

T E

C H

N O

L O

G Y



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.


C O

R P

O R

A T

E

T E

C H

N O

L O

G Y



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]


C O

R P

O R

A T

E

T E

C H

N O

L O

G Y



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

© 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...

Documents

Transcript of © 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...