Methodology: The AOP Refactoring Process

1. Step 1: Identify locations – “Aspect Mining” • Used AspectJ to define a compiler warning in order to identify locations in Cocoon that implement the CacheableProcessingComponent abstract interface. • publicaspectExploreCaching{ • declarewarning:staticinitialization(org.apache.cocoon.caching.CacheableProcessingComponent+) • &&!within(org.apache.cocoon.caching..*):"Class implements cacheable"; • } Step 2: Write Caching Aspects privilegedpublicaspectCachingAspect{ /* Ascii art generator */ declareparents: org.apache.cocoon.generation.asciiart.AsciiArtSVGGenerator implements CacheableProcessingComponent; public Serializable org.apache.cocoon.generation.asciiart.AsciiArtSVGGenerator.generateKey() { returnthis.inputSource.getURI(); } public SourceValidity org.apache.cocoon.generation.asciiart.AsciiArtSVGGenerator.generateValidity(){ returnthis.inputSource.getValidity(); } .... ‘Mixin’ it up: Use AOP design patterns to condense reusable code publicinterfaceSharedCacherextendsCacheableProcessingComponent { publicSourceValiditygenerateValidity(); publicjava.io.SerializablegenerateKey(); } publicaspect SharedCacherAspect { declareparents: (org.apache.cocoon.serialization.FOPSerializer|| org.apache.cocoon.serialization.iTextSerializer|| org.apache.cocoon.transformation.FragmentExtractorTransformer|| org.apache.cocoon.serialization.SVGSerializer|| org.apache.cocoon.serialization.AbstractTextSerializer ) implements SharedCacher; public Serializable SharedCacher.generateKey() { return"1"; } public SourceValidity SharedCacher.generateValidity() { return NOPValidity.SHARED_INSTANCE; } } Introduce Interface Introduce Methods Specialized reusable class Classes with same caching behavior • Background: Apache Cocoon • A dynamic multi-channel web publishing platform • “Apache Cocoon is a web development framework built around the concepts of separation of concerns and component-based web development.” • – CocoonGoal: • The separation of content, style, logic and management functions in an XML content based web site (and web services). • Usage example: • Take data from a database and publish the content onto a web portal in HTML, PDF, and WHTML formats simultaneously. Aspect-Oriented Refactoring of the Apache Cocoon Shared-Object Resource Allocation System Jeff Dalton Advisor: David G. Hannay, Union College Client: Robert Berry, IBM Java Technology Centre, Hursley, UK Abstract Aspect-oriented programming  (AOP) enables developers to develop and manage 'cross-cutting concerns' unrelated to the primary function of the system component.  Using AOP, these concerns can then be introduced to the base component easily and in a structured manner.  Other benefits of using AOP include the creation of software that is easier to understand and modify.  Caching, a common and effective technique to improve the performance of applications and middleware, is such a cross-cutting concern.  We explore this by refactoring a complex web application, Apache Cocoon, using AOP to introduce a caching mechanism.  The goal is to retain the original external behavior, while removing complexity and adding flexibility in the caching system.  The development of the AspectJ language and compiler allows the application of this methodology on the existing base of Java-based web applications without requiring new infrastructure. This project takes the next step by using AspectJ to simplify and extend the caching system in a large and complex XML-based website publishing system; it explores the potential difficulties associated with using AspectJ to accomplish this task and considers the effect that the application architecture has on the aspect-oriented refactoring process.    • Methodology: The AOP Refactoring Process • Analysis & Observations • Question:How should you structure your application to simplify AO extendibility? • Good coding practice makes AO adoption easier • Standard variable naming • Disparate names: LexicalSource, GrammarSource, etc. needed to be refactored to “InputSource” before they could be used to remove code via AOP. • Standard accessor methods are required to reduce introductions through Mixins. - Example: One case needed getInputSource() • But how are we supposed to know we need these when writing the software? - We can’t know. • The lesson: In some cases you need to perform Object-Oriented refactoring in order to allow AOP to reduce code duplication. • Open Questions • In a component architecture, do we define crosscutting concerns? • Do we examine each block individually or the system as a whole? • What do you do if it is a crosscutting concern in the system but not within the block? • This points to a larger problem • How should aspects be viewed on a design level? • Background: aspectj. & AOP • AspectJ is a small and well-integrated extension to Java that weaves java byte code and outputs .class files compatible with any JVM. • What is Aspect Oriented Programming? • Concern – “a specific requirement or consideration that must be addressed in order to satisfy the overall system goal.”AOP is a programming language mechanism that extends Object-Oriented Programming in order to achieve modularity and the ‘separation of concerns’. • AOP introduces a new unit of modularization, an aspect, that captures behaviors that affect multiple classes (a crosscutting concern) into reusable modules. • What are aspects?Aspects are: • concerns that crosscut [design level] • a programming construct [implementation level] • Aspects = pointcut + advice + inter-type declarations • Joinpoint: a principle point in the execution of the software system • Pointcut: predicate matching on joinpoints (where) • Advice: behavior that should be triggered at joinpoints, selected using a pointcut (what) • Inter-type Declarations: Fields and methods that the aspect manages on behalf of other types • AspectJ’s goal is to support the programmer in cleanly separating components and aspects from each other by providing mechanisms that make it possible to abstract and compose them to produce the overall system • Future Work • Integrate the AspectJ Compiler into the Cocoon build process so that the AO caching solution can be deployed on a Tomcat web server. • Use AOP to refactor the internal object store within Cocoon. This is an ‘internal cache’ where classes can store objects for later retrieval. This is a very closely related to this project since the caching system is just a thin wrapper around this store. • An event-driven ‘inverted’ AOP caching system Build a caching system that uses AOP to handle ‘Avalon’ events and perform the proper cache invalidations. AOP solves the design problem of where to define the caching strategy. • Conclusions • Many more opportunities for AOP in Cocoon! • Modifications to the AspectJ language and implementation would make the process easier, but it is still viable today. • Summary: • Abstracted 39 implementations of CacheableProcessingComponent • Used AOP to condense and remove 24 methods from the base implementation. • Removed all of the caching code into a single AOP package. • Example: Duplicate code: • publicSerializableorg.apache.cocoon.transformation.LexicalTransformer.generateKey(){ • returnthis.lexiconSource.getURI(); • } • publicSerializableorg.apache.cocoon.transformation.ParserTransformer.generateKey(){ • returnthis.grammarSource.getURI(); • } • AOP is another tool, it not a ‘silver bullet’ and conventional refactoring methodologies and tools are still necessary. Step 3: Remove References and Compile • References & Resources • Apache Cocoon Project http://cocoon.apache.org/ • AspectJ Project - http://www.aspectj.com/ • Project website – http://cs.union.edu/~daltonj/ • Thanks to the AspectJ team at Hursley for their valuable assistance and for providing some background information on AOP. • Step 4: Testing & Verification • In Progress • Integrating AspectJ into Cocoon Ant build process Background: Refactoring Refactoring – a change made to the internal structure of the software to make it easier to understand and cheaper to modify without changing its observable behavior