Dean Wampler's Mind: Tag AOP

ANN: OOPSLA Tutorial on "Principles of Aspect-Oriented Design in Java and AspectJ"

Dean Wampler — Tue, 04 Sep 2007 10:51:00 -0500

I’m doing a tutorial on aspect-oriented design principles with examples in Java and AspectJ at OOPSLA this year. You can find a description here

Contract4J5 v0.6.0 Is Now Available

Dean Wampler — Thu, 21 Sep 2006 21:07:00 -0500

After a longer-than-expected effort, I’m pleased to announce the v0.6.0 release of Contract4J5.

The API for writing contract tests has not changed, but the internals have been restructured considerably to improve the code quality and make it easier to configure Contract4J5 using property files and Spring Framework Dependency Injection.

The release also provides examples of using Contract4J5 with binary weaving or load-time weaving. The latter is now the preferred way to introduce Contract4J5 into a “pure-Java” environment.

For more details, see the Release Notes in the README or browse to http://www.contract4j.org.

RailsConf 2006

Dean Wampler — Sun, 02 Jul 2006 23:13:00 -0500

I attended the first annual Ruby on Rails RailsConf in Chicago last weekend and I’ve finally found the time to blog about it ;)

About 500-550 people attended, from novices to Rails experts, including 8 out of 11 of the Rails “core” team. The atmosphere was collegial and somewhat cozy. Everyone realized that future Rails conferences will be a lot bigger and probably more commercial too, given the growing interest in Rails.

Dave Thomas’ Keynote

Dave’s was the first keynote of the conference. He described the top-3 unsolved problems on his list of TODO’S for Rails. The list contains somewhat conventional items that you might expect, but what was interesting about the keynote was how the list anticipated some spirited philosophical discussions throughout the weekend.

Data Integration Improvements

Dave would like ActiveRecord to extract more information from the schema into the models, such as constraints and associations. He would like better foreign key and compound key support. He would like non-database back-ends supported, like JMS/MQ systems and he would like support for distributed transactions with two-phased commits, etc.

These are all reasonable requests from someone familiar with the typical challenges of “enterprise” (more on that word below…) applications, especially legacy systems. However, this surfaced an on-going debate between the two Daves; Dave Thomas and David Heinemeier Hansson (DHH). DHH has made clear his preference for keeping all domain logic in the application and using the database as a relatively simple-minded storage vehicle.

As subsequent presentations and discussions indicated, the Rails “core” will get smaller in the future and plugins will provide added support for things not considered “core”. No doubt people will implement plugins for all the things Dave (Thomas) wants, but they won’t be part of the Rails core. But this is okay, as it will satisfy various needs, yet keep Rails lean, mean, and architecturally clean (you can quote me…;) ).

CRUD and Scaffolding

Create, Read, Update, Delete (CRUD) operations are the core of typical database-based applications. Dave argued that the Rails scaffolding, which is used to generate stubs for functionality, etc. could be improved to better reflect the growing capabilities of Rails. He would like scaffolding that supports table relationships, in-browser validation JavaScript, AJAX, etc., etc.

Who could argue with that? Well, some people feel that scaffolding is too much of a crutch that discourages neophytes from understanding Rails and adapting it to their needs. Others feel that the scaffolding command-line tools are too primitive and should be more sophisticated. For a promising example of the latter, see the forth-coming Streamlined.

Perhaps most interesting was DHH’s own keynote, where he discussed his thoughts on more fully realizing the “vision” of CRUD in rails, but more on that later.

Deployment

Dave’s third item was deployment of applications. While Capistrano is a widely-praised tool for automating deployments, it does have some limitations. For example, out of the box, it really assumes that the developer does the deploying. This may be true for many small shops, but larger enterprises typically have system administrators who handle deployments. The Developers know what to deploy and administrators know the where, when, how, etc. for the deployments. So, Dave advocated enhancements that logically-separate application and deployment configurations. He sighted one example where J2EE got it right (at least in theory); packaging applications as “archives”, WARs, EARs, etc., which can be deployed to any standard server.

Deployment was a popular topic at the conference, with several sessions devoted to Capistrano, server topology considerations, etc.

David Heinemeier Hansson’s Keynote

Jumping ahead to DHH’s keynote on Saturday, he replied to some of Dave Thomas’ comments by reaffirming his opinions on topics such as the roll of the database and how far ActiveRecord should go in supporting various database features. For example, he was emphatic that composite keys are a known evil in the database world and ActiveRecord should not support them, at least not as a core feature. Perhaps someone will write a separate plugin, but DHH believes that if you do bad stuff, it should be painful, not easy.

For most of hist talk, however, DHH focused on more fully realizing the “vision” of CRUD in Rails. Create, Read, Update, and Delete are the standard operations in database-backed applications. In forthcoming versions of Rails, DHH wants to make this model more consistently applied throughout Rails.

For example, HTTP actually defines four methods, GET and POST, which we all know an love, but also PUT and DELETE. Roughly, these correspond the Read, Create, Update, and Delete operations in CRUD.

Our current way of organizing models, controls, and the behavior they offer is reflected in URLs of the form

.../model/action/id

For example:

HTTP Method	Example URL	Meaning
POST	`.../person/create/1`	Edit Person with ID 1
GET	`.../person/read/2`	Read Person with ID 2
POST	`.../person/update/3`	Update Person with ID 3
POST	`.../person/delete/4`	Delete Person with ID 4

Instead, we should be writing more “CRUD’y” URLs of the form

.../model/id

and using the HTTP method to indicate the CRUD operation. This would allow Rails to apply more conventions for these typical controller operations, thereby minimizing code. For example:

HTTP Method	Example URL	Meaning
POST	`.../person/1`	Edit Person with ID 1
GET	`.../person/2`	Read Person with ID 2
PUT	`.../person/3`	Update Person with ID 3
DELETE	`.../person/4`	Delete Person with ID 4

Unfortunately, browsers don’t usually support PUT and DELETE, so Rails is adopting a convention that hacks around this limitation. For example, the URL for the update case will look something like

.../model/id;update

where the idea for using the semicolon ”;” is based on some documentation written by Tim Berners-Lee himself (for “Semantic Web” concepts, I think).

But there are more ways to “embrace the CRUD.” Consider a typical example with a Person model and a Group model, where one or more Persons can be a member of one or more Groups. Typically this is handled thusly:

    class Person << ActiveRecord::Base
      belongs_to :group
      ...
      def remove_from_group ...
      def add_to_group ...
      ...
    end

    class Group << ActiveRecord::Base
      has_many :people
      ...
      def remove_person ...
      def add_person ...
    end

Where should those add and remove methods really go? DHH pointed out that if we reify (not his term) the relationship between Person and Group, that is, treat it as an model object in its own right, then we can use CRUD conventions to manage the relationship itself. In this example, a class Membership could encapsulate membership of people in groups. The CRUD creation operation would add a Person to a Group, deletion of memberships would remove the relationship, etc.

Perhaps the most interesting thing about his keynote was how it demonstrated his thorough commitment to pushing design principles to their logically limit in Rails. Where most of us would have been satisfied with the current design, DHH sees that it can be made even more consistent to the CRUD vision, and thereby further increase the use of common (and automated) conventions. No wonder Rails is so good!

Rails Application Optimization Techniques and Tools

Stefan Kaes

Stefan has done an extensive analysis of Rails performance issues. His detailed talk listed some of his findings. He is working on a book that is due next year, published by Wiley, that promises to be valuable for developers concerned about optimizing performance.

In a nutshell, he listed the following as the top performance problems:

slow helper methods,
complicated routes,
associations, especially when loading one object retrieves all associated objects automatically,
retrieving too much data from the database (related to the previous point), and
slow storage of session information.

For more details about his findings and recommendation, see Stefan’s blog and his recent InfoQ article.

MetaRails

There were many more interesting talks, but since I’ve taken over a week to get this blog done, I’ll finish with a comment on the excellent MetaRails talk by Stuart Halloway, with an assist from his Relevance partner, Justin Gehtland.

Stuart discussed some interesting uses of metaprogramming within the Rails core that make Rails the amazing environment that it is. Rails is a treasure trove of patterns and idioms that are well worth learning. As neither Stuart nor Justin are members of the core team, they provided an outsider’s perspective.

Stuart mostly praised the quality of the Rails code, but he pointed out one area where he felt it isn’t DRY enough, the way many ActiveRecord methods are aliased and then replaced with methods that add support for transactions, etc. There are apparently several different areas where the same methods are aliased this way, where each alias provides a different “enhancement.” As these alias statements are not co-located, it would be easy for one such modification to stomp on another. Also, how do you ensure that one alias takes “precedence” (i.e., gets applied first) over another? For example, you might always want authentication and authorization to happen first. (Note that Stuart’s follow-up blog mentions that the DRY problem has been partially solved since he started his analysis.)

In fact, he described a classic case that motivates Aspect-Oriented Programming. Even in dynamic languages like Ruby, where metaprogramming facilities are easy to use, AOP provides a conceptual framework for thinking about certain design issues, like adding transactional behavior to persistent objects or invocation of authentication and authorization challenges before executing otherwise normal-looking methods. Yes, Ruby metaprogramming facilities allow you to implement AOP-like behavior, but you have to “switch paradigms” to do so. I don’t know how Ruby implements Object-Oriented behavior, but you could image that similar metaprogramming approaches are used or could be used if no OO support were provided. So, yes, you could do OOP, in this case, but isn’t it nicer to think in objects when you are writing OO code, rather than have to switch gears mentally and think in meta-object protocols? The same argument can be made about providing AOP facilities in a language, even if those facilities are relatively small additions. For example, AspectR, an AspectJ-like Ruby clone, is only about 200 lines of Ruby code.

I’m going to blog about the role of AOP in dynamic languages like Ruby in the next few days, so please check back. Also, I’ll be doing a talk on AOP in Ruby and Python at the Dr. Dobbs Architecture and Design World in Chicago, July 17-20. I hope to see you there!

RailsConf 2007

Finally, it was announced that next year’s conference will be May 17-20 in Portland, Oregon.

Aspect-Oriented Design: "Humane Pointcut Languages"

Dean Wampler — Fri, 21 Apr 2006 11:25:00 -0500

I started a discussion yesterday on the “aspectj-users” group about humane pointcut languages. The notion of “humane interfaces” in programming has been discussed by Martin Fowler and in the context of user interfaces and product design by Jef Raskin.

This conversation was a spin-off of another thread where I made a mistake that I occasionally make. An AspectJ user wanted to apply some after advice after constructor calls in a class that has an annotation, e.g.,

  @MyAnnotation
  public class Foo {
    public Foo(...) {...}
    ...
  }

He needed help writing the pointcut and advice for this case. Without repeating the whole conversation here, at one point I remarked that

  call( @MyAnnotation * *.new(..) )

matches constructors annotated with @MyAnnotation, while

  call( * (@MyAnnotation *).new(..) )

matches constructors in classes where the class has the annotation. In fact, both are invalid expressions because the first * is for the return type and there is no return type for constructors, so the first * shouldn’t be there. Hence, the correct statement is that

  call( @MyAnnotation *.new(..) )

matches constructors annotated with @MyAnnotation, while

  call( (@MyAnnotation *).new(..) )

matches constructors in classes where the class has the annotation.

This is the sort of mistake I make fairly often and I’m sure beginners really struggle with the pointcut syntax, although it’s generally great for experts because it is both succinct and powerful. However, sometimes a more “human-readable”, that is “humane”, syntax can be a real benefit.

In fact, I’ve been thinking about expressive pointcut languages quite a bit recently, not so much in this context, but more in the context of higher-level AOP abstractions. As I said in the discussion thread, it bothers me that we discuss high-level concerns, say for example security, then turn around and write PCDs using very low-level primitives that tend to reference specific classes, methods, etc.

Of course, I’m not the only person who thinks this way and the recent work on AO interface-based programming is a huge step towards making it possible to express aspects with appropriate levels of abstraction.

I would like to comment on this issue more in future blogs, but for now, let’s return to the original problem and look at some things we might do to make PCDs more humane.

The first thing I suggested in the thread is the addition of special keywords that could be substituted for some of the wild-cards:

Keyword	Maps To:	Context
`$any_return`	`*`	Used for any return type
`$any_arg`	`*`	Used for any one method argument
`$any_arglist`	`..`	Used for zero-many method arguments
`$any_type`	`*`	Used for any type expression (class, interface, ...)

So, our previous PCD that matches calls to the constructors could be written

    call( (@MyAnnotation $any_type).new($any_arglist) )

This is a little more readable, especially for new users, while experts will prefer the more terse form for its brevity.

As an aside, you could use a similar mechanism to support regular expression matching while minimizing the potential for confusion, as discussed here. Something like $re(/(foo|bar)$/) to match names ending in foo or bar, for example.

Let’s combine our new PCD with after advice, to see a little more context. We want to “bind” the newly-created Foo instance to a variable foo. Handling newly-created objects is tricky.

    after() returning(Foo foo): 
      call( (@MyAnnotation $any_type).new($any_arglist) ) {
        ...
    }

Another approach, if we’re using the execution join point, is the following:

    after(Foo foo): 
      execution( (@MyAnnotation $any_type).new($any_arglist) ) && this(foo) {
        ...
    }

However, the keywords are a small improvement. Let me suggest that a real “humane” PCD language should read more like English. Consider this rewriting of the same two expressions, using a made-up pointcut DSL:

    after() returning(Foo foo): 
      call(constructors().takingAnyArgs().inClassesAnnotatedWith(@MyAnnotation)) {
        ...
    }

and

    after(Foo foo): 
  execution(constructors().takingAnyArgs().inClassesAnnotatedWith(@MyAnnotation))
    && bindNewlyConstructedObjectTo(foo) {
    ...
}

This syntax is inspired by the syntax of mocking frameworks like JMock and equivalents in Ruby. Certainly my toy DSL could be improved; I made it up on the fly during the discussion thread yesterday.

However, because it reads like English, it is very self-documenting, making comprehension easier by AspectJ neophytes and even experienced AspectJ users who are new to the application. I think it’s useful to remember that most code is write once, read many. We may not like to type a lot, but a literate style pays dividends over time.

Note that the syntax of this DSL and the standard syntax express essentially the same pointcut language “abstraction” for AspectJ.

So, I think there is a place for a more “humane” form of the AspectJ pointcut DSL. Similarly, I think that we need DSLs appropriate for higher-level AOP abstractions (e.g., at the design level) and ideally AOP DSLs that are domain-specific for non-trivial domains.

Update 4/28/06:

Jonas Bonér wrote an interesting blog on Domain Driven Pointcut Design where he discusses good principles of pointcut design that minimize dependencies on fragile class details and instead rely on metadata annotations, etc. He also makes an excellent argument that the “language” of those annotations should reflect the domain of the annotated class and not mix in other domains, like cross-cutting concerns.

My Contract4J Article on developerWorks

Dean Wampler — Thu, 13 Apr 2006 13:34:00 -0500

This is my inaugural blog hosted on my own web sites. My previous blogs can be found here.

My article on Contract4J went live on Tuesday, April 11 at IBM’s developerWorks.

In the article, I introduce Design by Contract and describe how Contract4J supports DbC in Java, using AspectJ under the hood. I end the article with a discussion of the emerging trends in aspect-oriented design using interfaces. That is, how the familiar interface-based design we’re used to in OOP is being extended to support aspects.

I intend to explore Aspect-Oriented Design in more detail in coming blogs. Please stay tuned!