1 / 2

A Distributed Aspect-Oriented System for J2EE Applications

A Distributed Aspect-Oriented System for J2EE Applications. Muga Nishizawa and Shigeru Chiba (Tokyo Institute of Technology, Japan). Background. Proposal DJcutter: A distributed AO system for J2EE. - As benefits of AOP are getting recognized, a few AOP

rasha
Download Presentation

A Distributed Aspect-Oriented System for J2EE Applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. A Distributed Aspect-Oriented System for J2EE Applications Muga Nishizawa and Shigeru Chiba (Tokyo Institute of Technology, Japan) Background Proposal DJcutter: A distributed AO system for J2EE - As benefits of AOP are getting recognized, a few AOP systems for J2EE have been developed before e.g. JBoss AOP, Spring AOP - J2EE is a distributed component framework for Java - However, they don’t provide new mechanisms specially developed for J2EE - DJcutter has a mechanism dedicated only for J2EE * Remote pointcut * Distributed weaving * It is implemented as one of services (MBean) on top of JBoss 4.0.0 RC 1 Problems - These AOP systems don’t support mechanisms for dealing with distributed crosscutting concerns - Concretely * the aspect separating such a concern consists of several distributed sub-components * Delivering software components to participating hosts is a bothersome work Contribution 1: Remote Pointcut - Identifies join points in a program on a remote host - Advice is run on a host different from the host where join points are pointcut - Transparently - Like RMI for distributed OOP - For instance … Authenticator aspect AuthTest implements AspectBean { 1. flag = false 2. calls registerUser() 3. assert flag == true before(): execution(void setUser()) { flag = true; }} Motivating Example: Test code for distributed authentication service class DbAccess implements SessionBean { void setUser() { … … } } Receiving a client request Remote pointcut <<session bean>> Authenticator Register a new user on a DB registerUser() Adding the new user’s information on a DB Client We could write the test program as a single non-distributed module on the client side <<session bean>> DbAccess setUser() Contribution 2: Distributed Weaving - One of the test programs confirms setUser() is actually executed on DbAccess if a client remotely calls registerUser() * The test includes a distributed crosscutting concern Authenticator Load&weave EJB Container AuthTest (AspectBean) DJcutter (MBean) JBoss Deploy Authenticator Deliver pointcut EJB Container DbAccess Load&weave DJcutter (MBean) class DbAccess implements SessionBean { void setUser() { … … } } EJB Container - If the user writes the test program in existing AOP systems, … Deliver pointcut JBoss DJcutter (MBean) JBoss The users of DJcutter do not have to manually deliver the compiled aspects to every host class AuthTest 1. flag = false 2. calls registerUser() 3. assert flag == true aspect Notification { before(): execution(void setUser()) { invoke Callback; } } - Once the user deploys an aspect, DJcutter … 1. acquires the pointcut information of the aspect 2. automatically delivers the information to each DJcutter 3. each DJcutter registers the information itself - Then the user orders DJcutter “weave”, DJcutter … 1. passes the operation to each DJcutter 2. Each DJcutter weave distributed software and aspect Remote Access class Callback Implements EntityBean flag = true The test concern is separated but, Three distributed sub-components

  2. Preplaned Dynamic Weaving Muga Nishizawa and Shigeru Chiba (Tokyo Institute of Technology, Japan) Proposal: Preplaned Dynamic Weaving Background: Dynamic Weaving - Aspects can be composed, updated and removed into application at runtime - Benefits * Is that Aspects can be woven without restarting application * Improves efficiency of software development e.g.) Reduces downtime of web application - Aspects allow dynamically changing the behavior of software - but, those are woven into the rest of application at load-time for efficiency - Weavable aspects must be known before running application (but NOT a problem in practice) Overview of Our Aspects Motivation - Aspects can dynamically define/redefine/undefine fields and methods of other objects (similar to inter-type declarations) - The following aspects redefine method register() defined in CustomerManager - Existing mechanisms for dynamic weaving are not acceptable for industry: low performance, lack of transparency, no-safety(?) e.g. * Using JPDA [Popovici ’03] * JVM’s extension [Bockisch ’04] - We want to use dynamic weaving more easily and simply Each register method Is used in a mock object for testing @Aspect class Aspect1 { @Refine(“CustomerManager”) class A { void register(String name) { return ; }}} @Aspect class Aspect2 { @Refine(“CustomerManager”) class A { void register(String name) { throw new Exception(“existing”); }}} Motivating Example: Unit Test for Client of server-side CustomerManager - By using dynamic weaving, we want to replace real collaborators’ implementations with mock implementations dynamically - By using @Deploy, Aspect is dynamically deployed within the control flow of the execution of method annotated by it @Deploy(“Aspect1”) void testRegisterNewCustomer() { // do something … } @Deploy(“Aspect2”) void testRegisterExistingCustomer() { // do something … } TestDriver Calls the client actually Registers a new customer Within the ctl-flow of testRegNew() execution, Aspect1 is deployed Client CustomerManager +register(String): void Implementation How to test client’s register(..) class Client { CustomerManager mgr; boolean register(String name) { try{ mgr.register(name); return true; } catch(Exception e) { return false; }}} class CustomerManager { // load-time weaving void register(String name) { switch(Weaver.getDeployed()) { // returns a hash code value case Aspect1’s hash : Aspect1_$$_register(name); return; case Aspect2’s hash : Aspect2_$$_register(name); return; default: original_$$_register(name); return; }} void Aspect1_$$_register(String name) { /* method body defined in Aspect1 class */ } void Aspect2_$$_register(String name) { /* method body defined in Aspect2 class */ } void original_$$_register(String name) { /*original method body */ } } - Replaces the real CustomerManager with mock objects - Changes the mock objects with respect to each test-method => dynamic weaving - Traditional test driver’s code for this client void testRegisterNewCustomer() { //register a customer that does not already exist boolean couldRegister = new Client().register(NEW_CUSTOMER); assertTrue(couldRegister); } void testRegisterExistingCustomer() { //register a customer that does exist boolean couldNotRegister = ! new Client().register(EXISTING_CUSTOMER); assertTrue(couldNotRegister); } Contribution - We proposed efficient dynamic weaving by using only bytecode transformation (without using other tools) (Note that, the aspects must be known at load-time) - These inter-type declarations allow us to redefine/extend implementations simply e.g. redefining mock implementations - Future work is to implement the mechanism for pointcut-advice, other inter-type declarations

More Related