Policies for AOP Based Adaptive Behaviour

1
Policies for AOP Based Adaptive Behaviour

• Phil Greenwood and Lynne Blair

2
Overview

• AOP Introduction
• Dynamic AOP and Adaptive Behaviour
• Undesirable Interactions
• Examples
• Our solution
• Analysis
• Summary

3
Aspect-Oriented Programming (AOP) Introduction

• AOP enables the encapsulation of cross-cutting
  concerns such as
• Logging and Tracing
• Security
• Performance
• Specifies these concerns in terms of
• Aspects
• Advice
• Pointcut Designators/Joinpoints
• Combining the AO code and OO code is known as
  weaving.

4
Dynamic AOP

• Allows aspects to be woven at run-time.
• Several advantages over static approaches
• Improved flexibility.
• Unanticipated aspects can be applied.
• Ability to apply patches.
• Drawbacks
• Negative impact on performance.
• Not as mature as static approaches.
• Errors can be introduced.

5
Dynamic AOP and Adaptive Behaviour

• Dynamic AOP is a useful concept when adaptive
  behaviour is required
• Features can added/removed.
• Natural encapsulation of the features.
• Allows fine-grained changes to be made.
• Extend this to auto-adaptive behaviour
• Specify certain exception in the system state
  using policies based on ECA rules.
• Monitor the system state.
• Weave the most appropriate aspect at run-time.

6
Problems

• Weaving aspects automatically can introduce
  various errors.
• Undesirable Interactions
• Aspect execution order.
• An aspect require the presence of others.
• Aspects are incompatible with each other.
• Resolution aspect could solve incompatibilities.

7
Example Setting

• Client-server system.
• The client requests various resources from the
  server.
• Client primarily adapted using a series of
  aspects
• Cache Aspect
• Authentication Aspect
• Logging Aspect
• Encryption Aspect
• Not concerned with the server.
• Initially no aspects are applied.

8
Execution Order (1)

• Suppose network delays occur.
• Results in the cache aspect being woven.
• System needs to operate in secure mode.
• Results in the authentication aspect being woven.
• There is a direct relationship between these
  aspects in terms of the execution order.
• Authentication aspect must be executed first.

9
Execution Order (2)
10
Requires Relationship

• Extend the authentication aspect to illustrate a
  requires relationship
• A logging requirement could be added to the
  authentication feature.
• Logging aspect must be woven/executed each time
  the authentication aspect is woven/executed.
• A requires relationship exists between the
  authentication and logging aspect.

11
Incompatible Relationship

• Security needs to be improved further when
  operating in secure mode.
• Consider the effects of introducing an encryption
  feature on the cache.
• Security concerns of caching encrypted objects.
• Encryption keys expire.
• Incompatible regardless of the execution order.
• Depending on priorities one of the features
  should be removed in the presence of the other.

12
Resolution Aspects

• The changes made means it is necessary to
  introduce a resolution aspect.
• Conflict exists between encryption and logging
  aspects.
• Encryption maintain the users privacy.
• Logging feature stores the entries in plain-text.
• Can be resolved by introducing an aspect that
  encrypts the log file.
• Woven when both the encryption and logging
  aspects are present.

13
Examples Summary

• Using static approaches these problems are more
  easily detectable.
• System configuration will not alter.
• When applied automatically operators may be
  unaware of the problems.
• Require a mechanism which prevents these
  interactions from occurring.
• Current solutions not adequate enough.

14
Policy Extensions

• Our proposed solution to these problems is to
  extend the policies mentioned earlier.
• Allow the specification of relationships.
• Able to edit at run-time (inc. add/remove).
• Have an immediate effect.
• Resolve conflicts.
• High-level specification.

15
Policy Base

• ltpolicy name"CachePolicy"gt
• ltcondition attribute"ExecutionTime"
  condition"more-than" value"200"gt
• ltpoints pointcutResource Client.getResource(
  String)/gt
• lt/conditiongt
• ltaspect-type nametype"Cache" advicecache
  pointcutResource Client.getResource(String)/gt
• lt/policygt
• ltpolicy name"AuthenticationPolicy"gt
• ltcondition attribute"fieldvalue"
  condition"equals" value"secure"gt
• ltpoints pointcut"String Client.mode"/gt
• lt/conditiongt
• ltaspect-type name"Authentication"
  adviceauth pointcutResource
  Client.getResource(String)/gt
• lt/policygt

16
Execution Order (1)

• Specifies the authentication policy and its
  aspects has priority.
• Used to resolve conflicts.
• Large disturbance when changes are made.

ltpolicy name"CachePolicy"gt ltrank
value2/gt lt/policygt ltpolicy name"Authenticatio
nPolicy"gt ltrank value1/gt lt/policygt
17
Execution Order (2)

• Solution is to assign relative priorities.
• Allows changes to be made without disturbance.

ltpolicy name"CachePolicy"gt ltrank
value--AuthenticationPolicy/gt lt/policygt ltpolic
y name"AuthenticationPolicy"gt ltrank
value1/gt lt/policygt
18
Required and Incompatible Aspects

• Two simple extensions.
• Can introduce conflicts
• Use the priorities to resolve these.

ltaspect-type nameAuthentication adviceauth
pointcutResource Client.getResource(String)gt
ltrequires-aspect nameLogging
advicelog/gt lt/aspect-typegt ltaspect-type
nameEncryption adviceencrypt
pointcutResource Client.getResource(String)gt
ltincompatible-with nameCache/gt lt/aspect-typegt
19
Resolution Aspects

• Should be woven when a certain combination of
  aspects are present.
• Implemented via a new attribute available to be
  monitored.

ltpolicy name"ResolutionPolicy"gt ltcondition
attributeAspectWoven conditionequals
valueLogginggt ltcondition
attributeAspectWoven conditionequals
valueEncyption/gt lt/conditiongt
lt/policygt
20
Run-Time Checks

• Necessary to ensure correctness
• Ensures all required aspects are present.
• Removes any incompatible aspects.
• Abandons any adaptation which would introduce
  undesirable interactions.

21
Analysis

• Reuse
• Separation of adaptation logic.
• Makes use of Framed Aspects
• Adaptability
• Allows changes at run-time.
• Has an immediate impact.
• Interaction Definition
• Simple specification of relationships.
• Requires an understanding of the target system.
• Portability
• Policy definitions are portable.
• Need to re-implement run-time checks.

22
Summary

• Overview of AOP.
• Suitability of Dynamic AOP for Adaptive Systems.
• Highlighted interaction problems.
• Provide a solution which addresses these issues.

23
Policies for AOP Based Adaptive Behaviour

• Phil Greenwood and Lynne Blair