AWS News Blog
Amazon Devcon – Greg Kiczales
|
I came into Gregor Kiczales talk a bit late to find that the room was standing room only. I was was standing towards the back, with barely enough room to cradle my laptop on one arm.
Gregor’s a professor at the Software Practices Lab at the University of British Columbia, working on research “directed at enabling programmers to write programs that, as much as possible, look like their design.”.
He came today to the first Amazon Software Developer conference to talk about aspect-oriented programming, which I had heard about — skimmed a developerWorks article or two — but have never done myself.
Gregor was in the middle of showing one of many slides with actual “aspect” code, showing how to express design patterns such as observer in a slightly modified Java language syntax. Although such patterns may be evident in UML or design documents in a concise form, Gregor claimed, all the code that actually implements that pattern or protocol is actually sprinkled throughout the code.
As a concrete example, Gregor told an audience of Amazon developers about IBM’s use of aspect technology for its WebSphere platform. The architects had a long and detailed logging protocol specifying how and when errors would be logged.
Using aspect technology, they were able to express WebSphere’s logging protocol in a relatively simple way, which made explicit a logging design which was only previously documented outside of the code, and scattered implementation-wise across the codebase.
This win, Gregor explained, was enough to sell the WebSphere team and management on aspect technology for production use. But it’s not just the wins of better software quality and TTM (time to market). A bigger win, perhaps, is the “platform play”. It’s why IBM is in.
What’s this “platform play”? From what I can tell, it’s about understanding how “modularity leads to strategy”. Going back to the logging example, the WebSphere architects reportedly didn’t even believe that they got the protocol just right, they just felt that once let loose, they wouldn’t be able to actually <i>change</i> the design once it was widely implemented.
With aspect technology, the architects were able to make use of this “modularity technology” outside of the actual mainline base, which allows a company like IBM to do things like take open source technology and perhaps sell different aspects. They could take an unreliable open source technology, for example, and sell quality aspects: better logging or reliability, concurrency or availability.
Now what about adoption strategies for companies other than IBM? Gregor suggested that Java developers could adapt zero risk features such as constraint/design enforcement and go from there.
He warned, though, that programmers might get “depressed or pissed off” with the use of aspect technology. Architects would get depressed to see how often their design constraints are violated [insert laugh track] and you might lose your friends if you start checking their Java code :).
Gregor went through a number of other examples, short little bits of aspect code that showed us how to enforce design constraints — don’t call this code unless this code was called first — or how to make concurrency easy.
“Does anybody know how to write Swing multithreaded?” Gregor asked.
One developer raised his hand and Gregor gave him a free copy of an aspect-oriented programming book.
Another developer asked why you couldn’t do all these things with
design patterns. Gregor said you just couldn’t, and he’s been doing this for twenty years. You could do it with reflection, and “go get a cup of coffee” — because reflection is notoriously slow — or do it with metaprogramming, which is extremely powerful but not easy to use.
Gregor talked a lot about the idea of “crosscutting“. From what I can tell, this has to do with expressing concepts that cross and cut across large swaths of a system’s design. For example, you might want to express an aspect of a system that gets used in almost every class, but you don’t want to modify each class separately.
With such power comes responsibility, and Gregor feels that only a small number of a large team’s developer will write aspect code. Some of his slides cited the Hanneman OOPSLA ’02 paper and he suggested Baldwin and Clark’s Design Rules, which Gregor called “hard to read” but well worth it.
He also pointed interested developers to sites like eclipse.org/aspectj, or to books like Aspect-Oriented Programming with AspectJ or Jacobson’s book on Aspect-Oriented Software Development with Use Cases. In the latter book, Jacobson apparently tries to make UML simpler — “it can’t possibly get more complex” — by taking advantage of an aspect-orientation.
Gregor feels that no more than half, in the extreme case, of programs will be composed of aspects, but that such modularity technology lets “modularity lead to strategy”. That is, aspect technology won’t replace object technology or UML.
It seems that aspect technology gives you a way to more easily express constraints, whether at compile-time or run-time, that let you — as Gregor would like it — make your code look, as much as possible, like the design itself.