Additional frameworks for aspects: BBN and others

1
Additional frameworks for aspects BBN and others

• Presented by Zakhar Borodin

2
Authors

• BBN, Cambridge
• Gary Duzan
• Joseph Loyall
• Richard Schantz
• Richard Shapiro
• John Zinky
• Supporters
• Defense Advanced Research Project Agency
• Air Force Research Lab

3
Distributed Objects

• CORBA
• Remote and local objects have similar interface
• Remote and local objects behave in different
  manner
• Can require different amount of time to perform
  the same actions
• Can fail/succeed separately

4
Quality of Service

• Need to examine the environment
• Tangling application and management logic
• Different logic for local and remote
• Breaks object-model concept

5
QoS as an Aspect

• QoS logic is best inserted into middleware level
• Dynamic QoS management
• Aspects
• Can access application and environment
  information
• No need to modify the application/system code

6
QuO Adaptation Model

• Regions
• Contracts
• Sysconds
• Callbacks
• Kernel
• Qosket

7
QuO Adaptation Model - Regions

• Represents states of the system
• Represents criteria for transition
• May be nested

8
QuO Adaptation Model - Contracts

• Defines a number of regions
• Can capture a set of static regions
• Level of service expected
• Can capture a set of reality regions
• Can be encountered at run time
• Defined using QuOs Contract Definition Language

9
QuO Adaptation Model - sysconds

• System condition objects
• Monitor/Control system low-level details
• Used as variables in predicates by contracts
• Trigger a reevaluation of contracts
• Reevaluation of predicates
• Transition actions

10
QuO Adaptation Model - Callbacks

• Side effects between state transitions
• Invoked by the contract
• Used to change attributes of the application
• Used to affect the system

11
QuO Adaptation Model - Kernel

• Contains contracts and sysconds
• Can live in a separate process

12
QuO Adaptation Model - Qosket

• A collection of contracts, sysconds, callbacks
  and support code
• Reusable
• Not bound to any particular application/interface

13
QuO Aspect model - delegates

• ASL is compiled to delegate
• Acts as a proxy for calls
• Adds desired behavior to method invocation
• Support multiple interfaces
• Many ASL specifications can be woven into a
  single delegate

14
Advice model - Method

• Advice can be applied to a method/interface
• Common method signature format
• Allows language independency
• Simplifies implementation
• Can not cope with overloaded methods

15
Advice model Join Points

• METHODENTRY
• PREMETHODCONTRACTEVAL
• METHODCALL
• POSTMETHODCONTRACTEVAL
• METHODRETURN

16
Advice model Join Points(2)

• Have default behavior
• METHODCALL
• Invoke a method
• PRE/POST METHODCONTRACTEVAL
• Evaluate delegates contract
• Determine current region
• METHODRETURN
• Return a value

17
Advice model - Advice

• May be executed
• BEFORE
• AFTER
• INPLACEOF
• ONEXCEPTION
• Uses simple language
• May be defined in native language

18
Advice model Execution Environment

• Advice can access method arguments
• Advice can access variables defined in the ASL
• Variables may be bound to any object with a CORBA
  interface
• Remote object reference and the return value are
  also variables

19
Advice model ASL example
20
Example Application

• Document server IDL

21
Example Application - Scenario

• Server can be queried for document or image
• Network and CPU load can affect the QoS
• Strategy monitor CPU and Network
• Operate normally
• Enable compression
• If CPU is available

22
Example Application - Contract
23
Example Application Contract(2)

• Defined in Contract Definition Language
• Sysconds reflect the environment
• Regions define the policy
• Callback object sysop invoked upon entering
  CriticalLoad region

24
Example Application Aspect Definition
25
Example Application Aspect Definition

• Qosket object provides services for delegates
• Ivar refers to allow_compression syscond in the
  contract
• Advice is associated with get_image method
• By method signature

26
Example Application Aspect Definition(2)

• Rval references the return value of the server
• Can be controlled
• Inplaceof directive prevents contract evaluation
  before the call
• No need to check the contract on the client side

27
Example Application Aspect Definition(3)

• Before directive used to modify query string by
  qosket object
• Add some compression criteria to the string
• Parameter q is bound to the modified string
• Call to the server is performed with a new string

28
Example Application Aspect Definition(4)

• after METHODENTRY onclient receives the
  compression requirements from qosket object
• Requirements are stored in allow_compression
  syscond
• Will be used by server

29
Example Application Aspect Definition(5)
30
Example Application Aspect Definition(6)

• Regions matching
• If no matching found default behavior is
  executed
• If the contract is in NoCompress the exception
  is thrown
• If the contract is in Compress using qosket to
  compress the return value and returning it

31
Example Application Aspect Definition(7)

• Other aspects can be defined
• Defined in a separate ASL file
• Applied independently
• Using the same contract

32
AO nature of QuO - Weaving

• Weaving
• Aspects into a delegate
• Oblivious
• Order may be defined per delegate
• Statically and dynamically quantified
• Delegates into the basic code
• Statically quantified for objects

33
AO nature of QuO Cross-cutting

• Weaving is crosscutting
• Allows behaviors for multiple classes in a single
  aspect
• Quosket code is distributed to various points
• Cross-cutting

34
AO nature of QuO Composition Filters

• Weaving by wrapping
• Intercepting messages
• Match method by name
• Weaving multiple ASL specifications
• More complex behaviors
• Use specified behaviors

35
AO nature of QuO - AspectJ

• Join Points
• Can advice
• Before, inplaceof (around)..
• 5 static points on each method
• Client/server side
• Each JoinPoint of AspectJ related to method call
  QuO gives 10 join points
• Regions
• Dynamic join points

36
Secure Application through AOP

• Functional and non-functional requirements
• Tangled code
• AOP provides modularization

37
Secure Application through AOP

• Personal Management system

38
Secure Application through AOP

• The owner (i.e., creator) of a PIMUnit can invoke
  all operations on that unit.
• Contacts are only accessible to their owner.
• All other accesses to PIMUnits are restricted to
  just viewing.

39
Secure Application through AOP

• OOP design
• PIMUnit must be associated with the owner
• Authentication mechanism must be added
• Authorization
• Most operations in the four unit classes must be
  modified
• PIMSystem class added

40
Secure Application through AOP

• Redesigned system diagram

41
Secure Application through AOP

• AspectJ design - OwnerManagement
• aspect OwnerManagement perthis(this(PIMUn
  it))
• String owner
• after() execution(Appointment.schedule(..))
  execution(Contact.create(..))
  execution(Task.create(..))
• owner Authentication.getUser()

42
Secure Application through AOP

• AspectJ design OwnerManagement
• Responsible for storage and initialization of
  owners
• An instance of the aspect per PIMUnit object
• Every unit has now owner attribute
• Initialized by the after advice

43
Secure Application through AOP

• AspectJ design Authentication
• aspect Authentication()
• static String currentUser
• static String getUser()
• if(currentUser null)
• currentUser ltlogingt
• return currentUser

44
Secure Application through AOP

• AspectJ design Authentication
• used to authenticate persons
• replaces the login() method
• represents the current user

45
Secure Application through AOP

• AspectJ design Authorization
• aspect Authorization()
• pointcut restrictedAccess()
• execution( Appointment.move(..))
  execution( Contact.view(..)) execution(
  Task.setProgress(..)) execution(
  Task.setPriority(..))

46
Secure Application through AOP

• AspectJ design Authorization
• implements the actual access control
• current user is identified through authentication
  
• restrictedAccess pointcut specifies the places
  for enforcing the verification

47
Secure Application through AOP

• void around() restrictedAccess()
• Object currentUnit thisJoinPoint.getThis()
• String unitOwner OwnerManagement.aspectOf(curren
  tUnit).owner
• String user Authentication.getUser()
• if(! unitOwner.equals(user))
  System.out.println("Access Denied !")
• else
• proceed()

48
Secure Application through AOP

• System Evolution - OOP
• secretaries, managers, workers..
• original design needs to be changed
• sub classing Person with several classes
• secretaries may require full access to all
  information of their managers
• operations are dispersed among several classes
• PIMUnit, Appointment, Task, and Contact

49
Secure Application through AOP

• System Evolution AOP
• the only required change is the modification of
  the condition
• if-statement within the Authorization advice
• changes are more localized
• flexibility, advanced modularization capabilities
  

50
Secure Application through AOP

• ACL based security model with AOP
• allow the owner to define rules for the access
  rights of each person
• different information confidentiality levels
• public, confidential, and top-secret
• Capability-based model with AOP
• one can delegate access privileges to others
• Systems can be supported without requiring
  invasive changes in the core application
• No unwarranted changes in the aspect
  implementation.

51
References

• Developing Secure Applications Through
  Aspect-Oriented Programming
• By Tzilla Elrad, Mehmet Aksit, Siobhan Clarke,
  Robert Filman.
• http//www.informit.com/articles/article.asp?p340
  869seqNum3

52
References

• Building adaptive distributed applications with
  middleware and aspects
• Gary Duzan  BBN Technologies, Cambridge, MA
• Joseph Loyall  BBN Technologies, Cambridge, MA
• Richard Schantz  BBN Technologies, Cambridge, MA
• Richard Shapiro  BBN Technologies, Cambridge, MA
• John Zinky  BBN Technologies, Cambridge, MA
• http//portal.acm.org/citation.cfm?id976280