Ron Bodkin's Blog

AOSD 2005 Industry Track: Fri Mar. 18

The industry track concluded with Olaf Spinczyk's presentation on Aspect C++. It's been over ten years since I've done any real C++ development, so I attended mostly to get a sense of how adoption of the technology is going. I sometimes get asked about using AOP for C++ when people attend classes and tutorials I give, so it's nice to know more about this implementation.

AspectC++ has had 500 downloads since they did a release on Feb. 10. Nokia has used it to weave into production Symbian OS code (cool). Siemens and Samsung are trying it out too. There are still some limitations (C++ is a beast of complexity, so adding AOP is taking time): they are focused on source-code weaving (cf. to cfront).

Sam Pullara was our "closer" and he did a great job presenting on VM-level AOP. He compared different stages of weaving and analyzed how they work.

Some interesting problems in load-time weaving he identified include:

• serialization of woven classes might break (due to incompatible formats if not woven on both client & server)
• reflection in woven classes might break (e.g., if the application iterates over all methods or fields, even synthetic ones)
• there are possible incompatibilities when there's more than one agent/weaver (e.g., will AspectJ aspects weave into Hibernate's dynamically generated proxies?)
• the presence of shared system class caches could cause problems for scoping aspects to affect specific classes (I need to learn more about this)
• stack traces can have synthetic frames (minor inconvenience)
• increased amount of memory required for analysis
• increased classload time

Sam also argued for more expressive pointcuts, e.g., exposing BeanInfo information (which would be a better way to match getters and setters and events too).

Adrian has blogged a much more exhaustive summary.

Toplink Persistence Aspects

The next industry track session on Thursday was Object Persistence Aspects by Jim Clark of the Oracle TopLink team. Their first use of aspects was to policy proper application development, notably ensuring that developers didn't modify objects in the shared read-only cache.

They next developed a way to generate AspectJ aspects from their XML mapping files to support lazy loading and also to replace snapshot-based differences with active dirty tracking while operating on persistent objects for "read mostly" applications.

They subsequently built a custom weaver/bytecode instrumentation engine using BCEL to implement this requirement since it could understand their XML (not require a separate step in the build process), and because they optimized the performance significantly compared to the memory and time required for general-purpose AspectJ weaving. I think this is an interesting case of thinking in aspects being a benefit: at least they could prototype the right implementation quickly, even though they ended up hand-tuning an optimization.

They still require a build-time option for deployment to "non-managed" environments (e.g., 2-tier deployments for testing or unusual app servers) where they can't weave at load time.

They are interested in leveraging general-purpose AOP in future, rather than maintaining their own, and see opportunities to provide higher level aspects like session management, query prefetching, and transaction demarcation. The initial feedback has been positive to the new "aspect-based" persistence option. They see aspects as the right answer, and preferably provided by the creator of a persistence framework.

NearInfinity: AOP for Auditing J2EE

Matt Wizeman and Jeff Kunkle of NearInfinity presented a practitioner report describing how they used AspectJ to build a product for enterprise compliance auditing. They note that most projects add auditing as an afterthought and it shows in the poor quality results. One key benefit of separating out the auditing implementation is it allows consistent policy implementation (it takes audit decisions out of the developers' hands).

NearInfinity uses AspectWerkz aspects to collect data, which then gets fed into a pipeline:

collect -> transport -> filter -> transform -> alert -> store

The data is collected into an in-memory database, and the architecture allows filtering data in an XML form at several places.

The system uses load-time weaving with AspectWerkz. They were initially using AspectJ with the Weblogic Aspect System, but converted when the latter wasn't updated for AspectJ 1.2. The AspectJ 1.1 version took 4 minutes on system start up. The AspectWerkz 2.0 version took 50-60 seconds. They are planning to use AspectJ 5 when it picks up comparable LTW support. This lets them weave into several interesting places:

• generated code (e.g., entity beans)
• JSPs
• 3rd party libraries

They also have thin aspects, moving as much code as possible into helper classes. One key thing they emphasized is the importance of aspect robustness: e.g., they hit a bug when beta testing because they were trying to log a null argument to a JNDI lookup in a customer system. The customer system was swallowing the resulting NPE so it was hard to track down. They key lesson is to be paranoid.

As a side note, aspects can also help with this problem. You can write after throwing advice to catch any exceptions thrown out of advice you write, to prevent it from poisioning the underlying system (e.g., log it and swallow it). This is very appropriate for auxiliary aspects, or any part of the system that isn't essential for core operation. Note that you can't quite make this work for around advice: if there's an exception in around advice you don't know if it preempted the proceed call... This is a great candidate for a reusable aspect too.

One key part of their system is tracking SQL data: they have gone through 4 different approaches:

1. wrapper pattern (on construction)
2. per instance aspects (but the Weblogic EJB deployer choked on this)
3. storing a TheadLocal HashMap of statement to state (I believe Nick pointed out that this is probably better done with an InheritableThreadLocal, as Wes has suggested in past).
4. generating a dynamic proxy to wrap a statement on creation

I had previously discussed with them how one might weave into the JDBC driver code to address this problem, while still allowing per-application data (e.g., tracking information by application). I am optimistic about this approach for situations where it's reasonable to have your aspect affect all the applications in a container. In many cases, it's quite reasonable to deploy some applications to different containers, too.

Another interesting implementation issue is how to audit requests that don't reach user servlets and how to map to the right application (e.g., 404 errors or static resources). This is very important for auditing (e.g., to monitor sql injection attempts).

So they use a Servlet filter, which has the right hooks defined portably. Sam Pullara suggested advising an empty filter. It's an interesting question if one can portably add a filter at runtime, or achieve the equivalent affect with just advice (i.e., avoiding the need to configure applications' web.xml files).

In future, they plan to expand coverage to include system commands, socket I/O, file manipulation, exception handling and 3rd party search engine APIs, Web frameworks and persistence frameworks.

JBoss: Implementing Middleware Using AOP

Bill Burke presented how JBoss is using AOP to provide transparent middleware. It was interesting to hear JBoss's new message that most of their users want to use aspects but not program them. They are promoting the message of annotations for ease of use and aspects for ease of extension. At the same time, JBoss is making extensive use of aspects: it's the basis of their EJB3 container (log, security, transactions, locks, remoting, etc.). It's great to have the fastest growing J2EE container build the core of their new platform on AOP!

Their transparent replicated JBoss Cache is a very cool application of aspects. Interestingly, they are using aspects to build it for product line variation. It lets them provide pluggable eviction, persistence, replication, and transactionality support without tangling the core cache code. They've also been able to use "advice stacks" to provide common elements for different J2EE components (SSB, SLSB, MDB, ...), while capture the variations. The advice stack concept in JBoss AOP is a kind of composite pattern; it would be interesting to better understand how it compares to AspectJ-style aspects.

They are also going to provide a capability to use XML to define or override programmatic @Annotations, and they allow changing annotations on a per instance basis. JBoss AOP lets one configure metadata per invocation, thread, class, vm, or cluster.

They see it as important to be able to hot deploy aspects (binding or unbinding at runtime, e.g., to add metrics at runtime). They also support per-instance advice. Bill told me that the weaver adds if tests, so this should be performant even for call join points.

Futures for JBoss AOP include a DI/IoC container in the manager environemnt and potentially being able to defer initialization until all dependencies are available.

Application Security Aspects

I then presented a session on Application Security Aspects. I showed examples of how AOP can implement non-trivial application security requirements like Web application authentication, role-based and data-driven authorization, enable defense in depth (checking rules at each tier) and ensuring proper audit trails for any security decisions. A nice property of the AOP solution is it provides traceability from the design to the implementation and more understandability to end users.

AOP can also add value to data access security checks; I showed an example of checking the security context to restrict queries using TopLink APIs (which is much easier than parsing and modifying SQL strings!). It can also add value to filtering out UI entries the user isn't entitled to see (fields or commands/buttons/links). The latter problem is often hard because of difficulty integrating with UI languages like JSP and because it's hard to know what the boundaries of a UI control/section are in typical markup (unless developers use custom tags that define controls or add some kind of XML annotation - marker tags). Overall, AOP is a great way to implement a number of typically scattered security designs, and is a big help on implementing others, though there is more work required to make it easy. All of this is ripe for reusable aspects that do a lot more for you than checking JAAS permissions based on an annotation!

The slides for this presentation are available online at http://www.aosd.net/2005/archive/Security_Aspects.ppt

AOP for Spring

The industry track on Thursday started with Rob Harrop and Adrian Colyer presenting AOP for the Spring framework. Spring integrates coarse-grained proxy-based AOP into the core framework and uses it for transaction management, security, remoting, performance monitoring, tracing and logging, and framework internals. Rob noted that many organizations adopt Spring that aren't aware of AOP. Subsequently it becomes validation, e.g., if a Spring consultant suggests using AOP, they can point out the customer has been using AOP in Spring for 6 months to assuage any fears.

The second part of the talk covered integration of AspectJ with Spring for more advanced uses. Adrian has blogged about this in past: both configuring AspectJ with Spring and extending Spring with fine-grained aspects in AspectJ. Adrian showed how to separate instantiation from configuration for non-singleton aspects. This used an aspect that has Spring configure a bean after instantiation, using an @Bean annotation. This is useful for beans too, that need context-sensitive instantiation (e.g., setting sessions on DAOs).

The next release of Spring will include an <aspect> xml tag (like <bean>) to make them easy to wire up. And there is significant collaboration to integrate Spring and AspectJ.

AOSD 2005 Industry Track: Wed Mar. 16

The track started with Gregor and Adrian's talk on adopting AOP. This was great and well worth drawing from if you are presenting on this topic in your own organization! The presentation had some great examples from internal use at IBM, notably examples of how it allowed system architects to refine the policy for error handling, which was never possible to vary before and the ability to vary features in product lines. Gregor also raised the great ideas of modularizing quality of service and doing clean room system extensions. The slides from the keynotes and the industry track are being posted at https://www.aosd.net/archive/

The basic approach of building up from exploration and enforcement to auxiliary/infrastructure to core/domain-specific is fairly proven. I find managers and architects who are interested often want to "spike" ahead and get help to prototype a compelling production use case too. I am also seeing more interest in analysis, design, and strategy for longer-term use. I also really like the graphics and their emphasis on being modest in claims, since people often want to hear about silver bullets. In particular, they wrap up classes with a slide about "What makes a good aspect," to emphasize that aspects should be used to solve hard problems modularly, i.e., to improve the design & implementation.

Then Adrian and Jonas talked about what's new in AspectJ 5, covering how AspectJ and AspectWerkz came to merge, and showing examples of how it will support annotations, generics, and other Java 5 language features. The use of type erasure with generics eliminates runtime type information, which makes it harder to use pointcuts. I won't even try to recap this material: take a look at the AspectJ 5 developers handbook for more detail.

This talk and Jonas' talk on the road to AspectWerkz 2, also covered the origins and implementation for AspectJ 5 of classloader-aware load time weaving (aka LTW) and @AspectJ syntax.

Classloader-aware LTW means you can deploy an aspect to a classloader and it will weave into only classes loaded from that loader (or below in the hierarchy). It will be using Java 5 agents and JRocket agents. I spoke to Alex and Jonas subsequently and think we'll see options for deployable Java 1.3 and 1.4 LTW support that works with containers, too. The ability to use aop.xml to control weaving and to apply abstract aspects are great too.

Jonas also showed the @AspectJ annotation, which brings the Aspectwerkz annotation-defined syntax to AspectJ (I had suggested this approach to Jonas and it became the more popular syntax for AspectWerkz users). I also expect to benefit from using it on a project for a customer where everyone uses IntelliJ IDEA.

Jonas also presented the work they did on runtime weaving with HotSwap, programmable per-instance deployment, the extensible aspect container, including a very high performance pure proxy-based AOP implementation, and on the AW Bench AOP performance benchmark.

Sam Pullara asked a great question about how AspectJ's annotation support will work with apt. Adrian noted that you can run apt first, then weave the result with AspectJ. However, it's a good question, because there won't be support for processing the results of declare annotation with apt. I also wonder how Eclipse will provide good IDE support for apt tools; I see the Pollinate project was discussing how Eclipse should work with apt; hopefully they will lift their consideration from making it work to first-class tools support...

Nicholas Lesiecki presented some great information from his team's experiences adopting AOP at VMS:

They first added support for logging initial exceptions for certain popular Web frameworks that don't do exception chaining (e.g., Apache JSTL). This was quite helpful, although allowing after advice on handler join points would have made it much better. I think AspectJ needs to capture additional bytecode metadata to capture enough information to allow weaving properly in the case that the original source was compiled by an AspectJ compiler.

Nick emphasized the importance of the design pattern whereby aspects uses helper class(es) to do the heavy lifting. This makes it easier to inject alternatives, ease tools use, and aids in testing.

They next implemented a basket repricing aspect for e-commerce. This aspect affects 12 points in 3 classes: they have significantly refactored it 4 times, with a 5th underway at the time (based on a new marketing requirement). This is a key benefit of aspects: they would have never felt free to refactor this way in a tangled implementation.

Nick also presented some great aspects that work with Hibernate. They auto-register hibernate objects with open sessions and most impressively, built a fairly generic aspect to implement relationship management (like CMR) for Hibernate. This affects 93 places in their application. It tok took 2 weeks to write. This prompted Merrick Schincariol of Oracle to question whether it was worth it for a single project: I think it depends on how much time it saved in fixing bugs, although maybe a simple enforcement aspect would help a lot. I think an aspect like this that is tightly coupled to a framework is most valuable when reused and is best supplied by the framework itself.

The team adopted AOP fairly easily and quickly: it took 6 months of project time in which 5-10% of development effort was devoted to learning it. By contrast, the project also converted to Tapestry and Hibernate and both were stop the world adoptions. However, aspects were often suspected as a red herring cause of other problems. My code doesn't work? Blame AOP!

Ramnivas gave a great presentation of annotations and AOP, and Mik gave a great presentation comparing the leading AOP tools. Both of them have written two part articles in the http://www-128.ibm.com/developerworks/views/java/libraryview.jsp?search_by=AOP@work: series on IBM Developerworks. I'd encourage you to read them for more details!

AOSD Keynotes and Panel

There were two great keynotes and a fun panel at AOSD this Year. I won't try to capture all the details (Adrian did a great job for both keynotes)... some things I really liked were:

Grady Booch kicked off the conference with his keynote. It was nice to hear Grady say "I don't think aspects are a fad, I think there's something deep and profound about them," and to exhort us to apply AOP to the architectural level. His handbook on software architecture is a very exciting project: who else could get the access needed to document the real architectures of large-scale projects? He also noted that often the architecture is more about key design patterns than functional decomposition into boxes (he noted this in the case of Eclipse).

Grady emphasized the complexity of software environments (there are so many languages, platforms and tools). I think this is actually one of the best things about AOP: it provides a general-purpose tool to address problems instead of gobs of special-case tools (code generators, tools, plugins, interceptor frameworks, annotation processors, XSLT, code checkers, preprocessors, etc., etc.). I ag

David Thomas (OTI founder, long time object pioneer, and founder of Bedarra) presented some great lessons for the aspect-oriented community. Programmers are suffering from "Too Much Stuff" (TMS), and he is positive about projects like Spring that simplify enterprise Java. He sees innovation happening at the edge, and expects today's J2EE and .NET will become legacy systems in 15 years. Bedarra are focusing on solutions for developing in 2010, with support for high performance teams that pair domain experts with developers. Dave is always a great antidote to hype (e.g., who has time for UML), and encouraged us to get smart teams out there to help organizations refactor today's bloated OOP into clean AOP.

He really had some great lessons for AOP providers, based on his experience doing this for objects:

• listen to the customer problem and relate the new technology to how it solves it, using an example that
• address the critic's concerns up front, to sell the importance of productivity
• position yourself between on the "inside" of the change advocate (visionary/early adopter) and the rest of the customer organization

David also lamented the state of computer education today:  not requiring learning functional programming or constraint-based programming, just Java (or just theory with no coding!). He emphasized the importance of good background and an ability to reason abstractly from first principles. He also advocated diverse view points, Brian Smith's ideas, and separation of concerns. And I appreciated Dave's reference to Worse is Better.

The panel discussion discussed a range of adoption issues. It was great to hear from Dion that 33% of TheServerSide Symposium attendees are using or planning to use AOP in production (think of all that arm waving Hani!). Bill Burke raised the question of how to explain AOP in a few sentences to new developers (I like Adrian's buzzword-free explanation...). I think Rob Harrop noted the importance of knowing what's already out there, not replacing existing features (e.g., don't give examples that a Servlet filter can replace). Another interesting point that came up was who should write broadly crosscutting aspects: it's the people who can write frameworks!

Software Development West 2005 Enterprise AOP Tutorial

Ramnivas and I started last week by presenting a full day hands on tutorial on enterprise AOP at Software Development West. We were really impressed by the level of knowledge and smart questions and success that many attendees had! It's a big change from the early days of AOP. We also were impressed that about 30 people came and stayed for a full day of lecture and hands on development. Thanks to all the attendees!

Hieu Nguyen also asked an interesting question: is advice on method-execution of a synchronized method itself included in the synchronized block? I had to think a bit before I guessed the answer would be yes (which I then verified by writing a test case). Of course, if you wrap the method body with a synchronized(this) { ... } block, then the advice is outside the synchronized block.

Given the desire to keep method synchronization attributes in tact, this is really the only way it can be (i.e., you can consider synchronization to occur between call and execution), but it would present an interesting challenge when/if AspectJ gets a sychronized(...) pointcut descriptor.

AOSD 2005 Overview

I have just returned from the 2005 edition of the Aspect-Oriented Software Development conference in Chicago last week. There were 255 registered participants, almost 25% of which were from industry. It was great to see so many people from industry who are using AOP in a serious way, as well as researchers and students who are creating the next wave of aspect innovation.

I flew in on a red eye Tuesday morning and presented a half-day Enterprise AOP Tutorial with Nicholas Lesiecki to kick off AOSD. The audience who came to our tutorial was a microcosm for the AOSD 2005 industry track attendees as a whole: a good mix of forward looking developers and managers and researchers who are interested in real world applications of AOSD.

It was a busy week that featured a great combination of:

• Presentations about new technology developments and information on using AOP on real projects
• Informal conversations with AOP technology developers, leaders in applying AOP, and researchers
• BOFs on AspectJ language design and reusable libraries
• Keynotes, tutorials, demos, exhibitions, and workshops

As an industry chair, I attended all the industry track, so this year I wasn't able to hear the research papers nor the demos, though some sounded very interesting. The following entries will give highlights from some of the events I attended.

Thanks again to all the speakers, industry participants, researchers, and students who came and made AOSD such a great event. Thanks to all the sponsors and to Mira, Tzilla, Ramnivas, Gregor, Brian and the rest of the organizing committee who were instrumental in making the conference go well and making the first industry track go well. Good luck to the organizing comittee for next year, especially the industry chairs: Alex Vasseur and Matt Chapman!

See also Adrian's great blog entries for more in depth coverage (starting at http://www.aspectprogrammer.org/blogs/adrian/2005/03/aosd_2005_confe.html) and Dion's news posting at TheServerSide.

Hello Blog-World

Hi there. I have (finally) started blogging, to share ideas and updates on software development and architecture, especially aspect-oriented programming. You can see more about my work at the New Aspects web site, and learn more about AspectJ too.