Aspect Weaving DyMAC middleware. by Tonje Klykken, INF5360 May 6th 2008

Transcription

1 Aspect Weaving DyMAC middleware by Tonje Klykken, INF5360 May 6th 2008

2 Agenda Brief AOP/AOSD motivation and concepts Problem description and refinement DyMAC component model DyMAC architecture model Analysis and results Conclusion

3 Presented paper B. Lagaisse and W. Joosen. True and Transparent Distributed Composition of Aspect-Components. In Proceedings Middleware'06, volume 4290 of Lecture Notes in Computer Science, 2006.

4 Aspect-oriented programming Security and logging are examples of functionality that represent cross-cutting concerns. Scattered code Basic functionality is cluttered Modifying and customizing the code is more difficult AOP aids the programmer by making it possible to modularize the cross-cutting concerns Example from Wikipedia [2]: a security module can include advice that performs a security check before accessing a bank account before() : loginbankacc() { checksecurity(); }

5 AO concepts (I) An aspect encapsulates: a behaviour advice (typed before, after and around ) instructions as to where, when and how to invoke the behaviour. A join point : defines when the advice can run A point cut: specifies of a set of join points When execution reaches a joinpoint, the associated advice is executed.

6 AO concepts (II) Joinpoints represent dynamic runtime conditions that arise during program execution The set of joinpoints can be specified in a pointcut designator where the kind and context of the joinpoint is described Example from Wikipedia: pointcut set() : execution(* set*(*) ) && this(point) && within(com.company.*); Context of a joinpoint may be the message signature, the identity of the caller/callee etc

7 Banking example Banking example

8 Problem (I) In state-of-the-art AOP, context information is limited to local information Distributed joinpoints are more advanced and will transparently distribute the basic concept of a joinpoint The context information must refer to components that are not local and on a distributed infrastructure To express these runtime conditions and express compositions, we need support for aspects with 3 key features

9 Problem (II) 3 key features: Remote pointcuts Evaluate on calls and executions of remote method invocation Evaluate on distributed context Remote advice Transparently executed in a remote enviroment Component semantics Clearly defined interfaces Supporting third party composition and interaction with other aspects

10 Problem refinement Advanced remote pointcuts Transparent remote advice with full semantics Unified aspect-component model

11 Advanced remote pointcuts Remote pointcuts that are able to refer to joinpoints before and after calling and executing remote method invocations in a distrbuted system can evaluate over contextual properties of the components involved allows to evaluate over contextual properties about the distributed location of sending and receiving component

12 Transparent remote advice with full semantics Transparent remote execution of advices based on deployment specification of an advising component Remote before, after and around advice with full remote semantics

13 Unified aspect-component model Unification of the entities Components are aspects, aspects are components Reusability (third party) Unification of interactions Advices and methods Considered normal remote method invocations Subject to aspect-oriented composition

14 State-of-the-art AO middleware Does not meet the challenges above, for instance: Contextual information for pointcut expressions is too limited Remote around advice with full remote semantics is not supported

15 Claim None of the initiatives in the domain of AO-middleware have defined a complete solution to the challenges above The paper claims that DyMAC offers a true and transparent distributed composition of aspect-components. it s component and composition model offers a solution for the three challenges

16 DyMAC middleware Basic concepts of the component model How the middleware supports aspect-oriented composition in a distributed environment and the concepts of the component and composition model Basic architecture model

17 DyMAC basic component model Each DyMAC component has 2 interfaces Implementation of a component Descriptors

18 Each DyMAC component has 2 interfaces Create-interface Specifies how to instantiate the component Can contain several create methods Instance-interface Specifies the methods the component-instance offers From BasicBanking example:

19 Implementation For each create-method a constructor is implemented in the create-interface Implements the instance-interface From BasicBanking example:

20 Descriptors Component descriptor Application descriptor Deployment descriptor

21 Component descriptor Defines: The component name The provided interfaces Create Instance The dependencies The required interfaces Defined by: Dependency name Expected interfaces The implementation file Note: Example is taken from another article [1] by the same authors

22 Application descriptor Defines: Application name Set of components used By referral to their descriptor Composition of components Can be both normal compositions and aspect-oriented compositions

23 Deployment descriptor (I) The components are deployed across a distributed infrastructure Hostgroup Host Host Framework instance Application domain Application

24 Deployment descriptor (II) Defines: The deployment location of the components: For remote components Location is unique and is defined by: The host Framework instance Application domain For local components: Deployed in every application domain

25 DyMAC supports aspect-oriented composition AO compositions are defined in the application descriptor They have 2 main parts: The component providing the aspect behaviour and its instantiation scope A set of bindings, where each binding: Defines a pointcut Refers to an advice-method of the advising component Specifies an advice type

26 Pointcut expressions (I) Logical expressions that evaluates on: Kind of joinpoint (call or execution) Contextual properties: Component-related properties (joinpoint model) Message signature Dependancy and interface names Component names Name of distributed application Infrastructure-related properties Host names Host groups Application domains

27 Pointcut expressions (II) All properties have a default value: all Pointcuts can be remote both implicitly and explicitly

28 Advice Supported advice types in DyMAC Before-advice After-advice Around-advice Replaces the invocation it advises Proceed operation

29 Specifying Advice Methods Methods defined in the component interface may be used as advice Advice must then be specified The advice Supports, Requires or Prohibits a kind of joinpoint Kinds of joinpoints: BeforeCall, AfterCall, AroundCall BeforeExecution, AfterExecution, AroundExecution

30 Execution semantics of advice Advice is considered a normal remote method invocation when called from the joinpoint context

31 Defining Distributed Instantiation Scope Aspect scopes define the creation moment and usage scope of the component instance State-of-the-art AOP instantiation scopes: per joinpoint / class / instance etc DyMAC extends them with distributed instantiation scopes: Singleton per hostgroup / host / application domain etc

32 Middleware Architecture Top-level architecture AspectBinder Distributed joinpoint infrastructure Before a remote invocation is called or executed Remote advice coordination infrastructure Instance management Component factory Distributed instance registry

33 Top-level architecture Each DyMAC framework can host multiple application domains for different DyMAC applications

34 Top-level architecture

35 Framework middleware Deployer distributes the application binaries and descriptors to the framework middleware to store them on the ApplicationRepository Framework facade deploys, starts up, stops and undeploys applications on the framework Application descriptor is handled by the ApplicationParser and an ApplicationSpec model is built.

36 Application middleware Framework middleware instantiates an application domain and loads the application middleware into it The application middleware loads and manages the different components deployed in its application domain. After the ApplicationType metamodel is created, we have a list of method definitions with empty advice chains. When the application is running, InterceptionCore processes the remote invocations between components

37 AspectBinder Handles the bindings defined in AO compositions For each binding, the properties of pointcuts known at loadtime are evaluated If ok, an advice thunk is inserted into the advice chain of the method. Advice thunk defines A set of properties to evaluate at runtime Advice method

38 InterceptionCore Two important services: Distributed joinpoint infrastructure Creates and manages the runtime representations of distributed joinpoints Remote advice coordinator Selects and evaluates advice thunks for a joinpoint An advice handler is instantiated when advice needs to be executed for a certain joinpoint A list of advices matching the joinpoint is given to the new instance

39 Chattiness To avoid chattiness there have been made some architectural decisions When a component is intitiated, the component s context properties are stored in its proxy Every remote client of a component receives the component s context properties together with the proxy

40 Component factory The factory instatiantes the components looks up the dependancy name binds a component to it creates an instance of the component

41 Distributed instance registry When receiving a new instantiation request: Checks if it already is registered If so, the registry returnes a proxy to the instance If not, the components are registered in the aspect registry at its deployment location Application middleware has a local cache of the aspect registry Reduces chattiness

42 Evaluation Evaluate the runtime overhead by the middleware platform to support the features of the component model Increased data access Increased network usage Increased usage of computation resources Compared runtime overhead between AO: application using the.net implementation of DyMAC State-of-the-art: application using.net remoting infrastructure

43 Performance analysis Data access Main performance bottleneck Network overhead Number of messages Message size Measured with 4 different messages between two localhost processes and on a 100MBit network If used for single process, single user AOP applications, they say that framework overhead is significant For large-scale distributed enterprise applications, they say the overhead is acceptable As parameters gets larger, the relative overhead gets smaller

44 Result They came to the result that the runtime overhead of DyMAC is acceptable in a distributed application The network/message size overhead is the penalty

45 Conclusion AOSD is a promising technology that can assist in improving expressing complex compositions effectively DyMAC fulfills the three key features/challenges desribed in the beginning of the presentation

46 Other resources used [1] Aspectual Dependencies: Towards Pure Black-Box Aspect-Oriented Composition in Component Models, B. Laigaisse and W. Joosen, WCOP 2007 Components beyond Reuse, URL: [2] Aspect-oriented programming, Wikipedia URL: