There has been allot of talk about AOP lately, about how it's dead (at least in the MS world). Craig Andera, Tim Ewald and especially Clemens Vaster (who actually build an AOP framework), these are the guys you don't want to argue with, if you don't know what your are talking about. They all come to the conclusion that AOP is dead, because bottom line it's complex. na na na there is more to it, I know, but at the end it's the complexity that killed the cat, not curiosity.
[Craig Andera]
"The basic problem here is that services are not generally orthogonal. What that means is that it’s impossible to simply slap a new behavior onto code without understanding all the other behaviors that are already there"
[Tim Ewald]
"COM+ (at the time) was an entirely closed system with a fixed set of services that could be used in conjunction with one another. Even in that very finite universe, the interplay between the services is quite complex. Making that universe infinitely large by allowing third parties to mix in additional interceptors with arbitrary behaviors‚ is a mistake. The complexity goes through the roof, because, as Craig noted, the services typically are not orthogonal."
[Clemens Vaster]
#¤"%"#"# :-)
COM+ is about declarative, attribute-Based Programming if you will, a great way of adding behavior on to existing code.
I think the COM+ programming model is very powerful and it works. period. Fact is also that the COM+ model is a "closed system" e.g. no new external services can be added to this model. This makes the model stronger and holds water, but this has more to-do with the nature of the services in that model, they work in conjunction with one another, they "naturally" belong to each other. The internals of the COM+ model is complex, look for your self, dig into the mono implementation and you will get a sense of what's going on beneath them attributes.
I am not going to enter this area here without having some thoughts my self. A couple of month ago (before the announcement of AOP's dead:-)), I was digging into context programming in the .NET framework. It became clear to me that the implementation e.g. IsContextOK and the logic build around this function was weak. You have to ask all the involved services if they agree with your service.
This "asking around" involves a 2 step process: asking, then "Freeze" then asking again, to confirm "we are compatible or we are not compatible". I had my doubts about this 2 pass step, it became clear to me that, some services could change after they had been contacted by the IsContextOK logic, perhaps because the "asking around" suddenly found a service last in line that was incompatible with my services, although I just agreed that I was compatible with the rest of the services. The scheme here requires that you change your "vote" depending on the other services outcome/vote.
The end result is of course you will execute a method with say 10 services that really works against each other instead of helping you finishing your job, they complicate or even stops you from doing your job. That sux ;) agree.
So here is the deal, in order to satisfy this complex logic involved in this scheme, especially if adding new external services to your system, you have to build an enormous amount of code/logic that will handle all "unknown" factors. That's impossible.....at least that is what Tim, Craig and Clemens agree upon. I agree, it will be complex and that is why people get off this AOP train.
But wait a minute, if you look at the tools/programming languages we are building these AOP frameworks with ....
I say that's where the Cat can have 9 lives.
Step back:
C++,Java,C#,Pascal they all fit the category Procedural Programming (please ignore OO for awhile, it still belongs to the category PP, it's subdivided into OO and imperative language allright). Look further, then we have the Declarative language :-) like Prolog, Lisp, Miranda (subdivided again etc).
Now I am sure I just said "Declarative" language, what if the tools we are using, building these AOP frameworks are all wrong.
It is my belief that languages like C++/C#/Java are not cut out for AOP.
PROLOG is about declaring facts and then map rules onto them facts, sound familiar:-), you're not going to believe how complex problems Prolog can handle for you. I say the AOP can be "saved" if you switch tool/language.
I hope we move towards rule based programming, simply because it really solves complex matters based on our rules.
If you put up an AOP framework and each services would be declared as the facts of life and then map the facts onto the rules in your universe, it will be less complex by the end of the day.
The CLR doesn't care about VB,C++ code anymore, it's IL code in the end now, so it doesn't matter what language you pick up by the end of the day. I have been messing around with P# for awhile, it's appealing to me, because I can write complex business logic in P#, much more complex logic than with C++ or C# for that matter...with less code:-).
AOP is not dead, nor is it dead in the "real world", it's all round you, take your car for instance, it has ABS designed to help you brake the right way, a service that takes over control when you overbrake on a wet street, nice I don't have to think about that part, I can concentrate on driving. Mercedes has the passive safety concept which bottom line is your AOP framework (I could potentially write business logic while driving because of this passive safety contept:-)).
AOP,ESP,ABS,SBC,SRS bomb :-)
IMO AOP is not Dead, just bring the right tools and God I hate all them them abbreviation.
"If you were going to shoot a mine, would you use a silencer?"
;-)
