I'm finally back from the AOSD 2008 conference, the principal conference of the Aspect-Oriented Software Development (AOSD) community. This is an academic conference, which means that most people are either academic researchers, either researchers in R&D departments of big companies. So I was a kind of stranger there, but this time I did not suffer too much from that.

I have delivered my speech on Wednesday 2nd April in the industry track. Slides are available for download. Note that the speech was designed for an audience who is comfortable with AspectJ, which I guess is not the case of the majority of readers of this blog. You can also download the paper, the most systematic and complete description of PostSharp Laos so far. It was published in the proceedings of the conference. If you need to convince someone that PostSharp is serious, you can put the paper on his table!

The conference was not only about PostSharp, of course. I mostly attended to the industry track and to some demonstrations. Here are the topics I was most interested in:

  • Daniel Wiese, Software Architect at Siemens Medical Solutions, presented how AOP was used in a huge project (SORIAN, a Hospital Information System) of 400 developers spread in 4 different countries. AOP was used principally to handle the "non-functionals", i.e. logging, auditing and so on. What's interesting with that? Well, the scale of course! It shows that AOP has already grown from its youth phase when it was used only in prototypes. Daniel cited some practical problems they met with AOP, principally the increased build time. The selected solution was to weave the code only for nightly builds, so developers do not loose time waiting for the weaver in local builds. Siemens also wanted to enable/disable aspects after deployment (for instance to enable monitoring in a part of the solution when it is in production). Therefore, they used load-time weaving in WebSphere, a Java application server. Since the built-in weaving solution of WebSphere was not satisfying (it was an old version of AspectJ with bad support of load-time weaving), they developed their own weaver: FastAOP. Thank you Daniel for this great show, and let's hope it will convince companies to adopt this technology!
  • SAP integrated AOP technologies in the new version of ABAP, the SQP programming language. True, it is not AOP in the sense we usually mean, but if SAP is getting interested in AOP, what are all the others waiting for? Another proof that it's useful!
  • ASLM, a producer of semiconductors, developed their own solution to weave hundreds of thousands of lines of code in C.
  • Hitachi developed an AO extension to COBOL. Yes, you read well: the old good COBOL.
  • Siemens team presented a funny show of Aspect Manager 2010, a plug-in to Eclipse allowing easy discovery of aspects and their injection into projects. An excellent source of inspiration for PostSharp! Indeed, it convinced me that we should design a standard packaging for aspect libraries to streamline the installation process.
  • M4JPDD, a tool to express quite graphically complex pointcut. Very interesting, although IMHO not backed by a sufficient demand.

The conclusion for me is that there is real interest for AOP in industry, and AOP has already proved itself in huge projects. Why would the .NET world make exception? Experience shows that people are currently mostly interested in the "easy" aspects like caching, auditing, security, and so on. But it is precisely what PostSharp Laos is good in! So it seems I am on the good track. On the other side, there is a lot more in AOP than what PostSharp is able to do! If you follow the blog and the work of Ruurd Boeke, you will find out that PostSharp does not perform well with complex tasks. Of course, you can do everything you want (which gives an amazing feeling), but it results in much more aspect code than what would be the case with AspectJ.

In other words, the conference was a great opportunity to assess the design choice of PostSharp Laos: make simple things easy, knowing that the market is currently at 80% interested in easy things.

Happy PostSharping!


Comments (2) -

Julián Hidalgo
Julián Hidalgo
5/27/2008 12:44:00 PM #

Nice post. I was surprised by this phrase though:

"If you follow the blog and the work of Ruurd Boeke, you will find out that PostSharp does not perform well with complex tasks"

What kind of tasks for example? Are you thinking of improving that or will you just focus on making "simple things easy"?

Gael Fraiteur
Gael Fraiteur
5/27/2008 12:51:00 PM #

Try for instance to implement the observability pattern (i.e. implement INotifyPropertyChanged). Do it with PostSharp Laos, then with AspectJ.

You will find out that the AspectJ version is much shorter.

So when an aspect cannot be expressed in a single class (i.e. compound aspect), using PostSharp Laos is maybe more difficult than using AspectJ. Conversely, AspectJ is more difficult than PostSharp Laos on simple tasks.

I would like to provide another solution (maybe different than Laos) to make more complex aspects easier, but I dont know when I will have time and/or budget to implement it.

Comments are closed