AOP .... who uses it?
I just got a "decent" handle on AOP, thanks to this page. Intro to AOP. I'm wondering how useful is it? Does it add unneeded complexity? What other ways would use it (aside from separating Logging methods)?
AOP as it relates to Java is an attempt to solve the problem of verbosity by adding another layer of abstraction that increases verbosity to such a degree that one needs advanced abstractions provided by specialized tools to manage.
At fundamental level AOP tries to work around the inherent flaw of common definition of OO as single-parent inheritance. In practice, the impedance mismatch is so great that another, preferably Turing-complete language needs to be invented to describe this additional functionality.
Logging is used as staple example of why AOP is great. Except that logging is not an important problem to solve. It's quite irrelevant and trivial and the goals that loggers are after are not about how to log as many actions as possible with as few lines of code as possible. In JVM, the problem like this is solved without writing additional code simply by instrumenting method invocations and producing full offline trace of application execution.
As for advanced examples, such as bolting transactions to bank accounts. The reality is, no system that wasn't specifically design for each such functionality (and tested for it) will ever be a good match. So one might as well plan for that and build it into original design.
Fundamental reason why cross-cutting isn't widely used is exponential explosion of special cases, same for alternate forms of inheritance. For each cross cut, you get another dimension. In Java, this leads to FactoryFactoryFactoryFactorySingleton. AOP would fix this by adding cross-cuts to Singleton, then adding cross-cuts above those. Not only does it not solve the original problem, it adds completely new dimensions by introducing another layer and language.
Alternate approach which solves similar problems but in a practical way is Dependency Injection and Inversion of control. The benefit of such approaches is that they can be trivially implemented using available language features (any language) and can be automated using language itself, not third-party tools. End result achieves the same, but with considerably less effort. Obviously, if not running crazy with patterns and abstractions, then equivalent result can be achieved using stateless design or free functions (which Java or C# don't allow) or using a dynamic language with support for mixins, class redefinitions or similar (Ruby being probably one of more widely used, JS can do the same).
Overall - no user has ever seen, heard or wants to about AOP. It doesn't add value that matters today. It's a BigName concept from an era of enterprise architects and UMLs, where a lot of talk was needed to produce a single line of code that nobody wanted to be responsible for. But the original problems of complexity remain unsolved, the world just realized that instead of piling layers of abstractions, one is better off simply writing order of magnitude less code in the first place.
At fundamental level AOP tries to work around the inherent flaw of common definition of OO as single-parent inheritance. In practice, the impedance mismatch is so great that another, preferably Turing-complete language needs to be invented to describe this additional functionality.
Logging is used as staple example of why AOP is great. Except that logging is not an important problem to solve. It's quite irrelevant and trivial and the goals that loggers are after are not about how to log as many actions as possible with as few lines of code as possible. In JVM, the problem like this is solved without writing additional code simply by instrumenting method invocations and producing full offline trace of application execution.
As for advanced examples, such as bolting transactions to bank accounts. The reality is, no system that wasn't specifically design for each such functionality (and tested for it) will ever be a good match. So one might as well plan for that and build it into original design.
Fundamental reason why cross-cutting isn't widely used is exponential explosion of special cases, same for alternate forms of inheritance. For each cross cut, you get another dimension. In Java, this leads to FactoryFactoryFactoryFactorySingleton. AOP would fix this by adding cross-cuts to Singleton, then adding cross-cuts above those. Not only does it not solve the original problem, it adds completely new dimensions by introducing another layer and language.
Alternate approach which solves similar problems but in a practical way is Dependency Injection and Inversion of control. The benefit of such approaches is that they can be trivially implemented using available language features (any language) and can be automated using language itself, not third-party tools. End result achieves the same, but with considerably less effort. Obviously, if not running crazy with patterns and abstractions, then equivalent result can be achieved using stateless design or free functions (which Java or C# don't allow) or using a dynamic language with support for mixins, class redefinitions or similar (Ruby being probably one of more widely used, JS can do the same).
Overall - no user has ever seen, heard or wants to about AOP. It doesn't add value that matters today. It's a BigName concept from an era of enterprise architects and UMLs, where a lot of talk was needed to produce a single line of code that nobody wanted to be responsible for. But the original problems of complexity remain unsolved, the world just realized that instead of piling layers of abstractions, one is better off simply writing order of magnitude less code in the first place.
Could you argue that the sort of component-entity systems that people seem to be talking about a lot these days is quite similar to AOP, in terms of semantics if not syntax? Let's take Unity for example; Unity represents its GameObjects as aggregations of "components" that communicate with each other and execute behaviour every frame. Couldn't you argue that each of these "components" represented an "aspect" of their parent objects?
" logging is not an important problem to solve. It's quite irrelevant and trivial and the goals that loggers are after are not about how to log as many actions as possible with as few lines of code as possible."
Logging isn't unimportant. Logging is mindbendingly important, particularly in large service infrastructures such as the sort of place where Java gets used. Finding out where, in hundreds of supposedly co-operating components running on scores of machines in dozens of datacentres, something happened to something inside your process takes up the majority of large systems maintenance. Fixing any single problem is usually relatively trivial compared to the painful, painful weeks of trying to find out why 1 per 10,000 download activations never complete successfully because something somewhere on the network is placing a lock on something that we're not expecting.
Logging is problem that is rarely solved well and yet is VITAL to most infrastructures.
Logging isn't unimportant. Logging is mindbendingly important, particularly in large service infrastructures such as the sort of place where Java gets used. Finding out where, in hundreds of supposedly co-operating components running on scores of machines in dozens of datacentres, something happened to something inside your process takes up the majority of large systems maintenance. Fixing any single problem is usually relatively trivial compared to the painful, painful weeks of trying to find out why 1 per 10,000 download activations never complete successfully because something somewhere on the network is placing a lock on something that we're not expecting.
Logging is problem that is rarely solved well and yet is VITAL to most infrastructures.
Overall - no user has ever seen, heard or wants to about AOP.
[/quote]
No user has ever seen, heard or wants to about X, where X is anything but the UI (Even then they aren't always disposed to seeing or hearing about it). I can only imagine that I'm not aware of all the techniques and tools that are used to build a car, or a computer. It certainly doesn't mean they didn't add value. I wouldn't consider this an interesting argument.
It doesn't add value that matters today.
[/quote]
It adds value if the overall product was better for having used it, or got to market quicker for having used it. Logging, regardless of mechanism, might help the program become more robust and can help quickly fix bugs in the wild by making them easier to reproduce.
In JVM, the problem like this is solved without writing additional code simply by instrumenting method invocations and producing full offline trace of application execution.
[/quote]
This could be considered an aspect oriented solution to the problem, because the problem has been solved without littering the code involved with logging calls. That you can leverage the technology to do it for you, rather than having to manually write it, is great.
[hr]
As an example of what I've seen AOP used for, we had an aspect that was used to help enforce security. It sat between layers in our application, and filters and logs any objects passing between the layers that the user should not have access to. It also logged whenever it needed to filter a large list, indicating work that should be done in the database was being performed at higher layers.
We didn't need any Factory[sup]N[/sup]Singletons to accomplish this.
I'm not aware of any other way to achieve this that would have been reasonable and complete. I believe this added value, as we found some areas where our security was weak, and overally speeded up the application by moving filtering logic to the database, even though we were choosing to incur the more minor hit for the filtering itself.
I believe you are misrepresenting the case agsinst AOP by using the worst examples of what can be done with it. This is a fairly easy straw man to burn. Certainly, like all technologies, one must separate the hype and novelty from the utility and practicality. Like many complex technologies the simple examples often oversimplify or present non-standard use cases (e.g. OO and class Square : public Rectangle).
Logging isn't unimportant. Logging is mindbendingly important, particularly in large service infrastructures such as the sort of place where Java gets used. Finding out where, in hundreds of supposedly co-operating components running on scores of machines in dozens of datacentres, something happened to something inside your process takes up the majority of large systems maintenance. Fixing any single problem is usually relatively trivial compared to the painful, painful weeks of trying to find out why 1 per 10,000 download activations never complete successfully because something somewhere on the network is placing a lock on something that we're not expecting.
As an example of what I've seen AOP used for, we had an aspect that was used to help enforce security. It sat between layers in our application, and filters and logs any objects passing between the layers that the user should not have access to. It also logged whenever it needed to filter a large list, indicating work that should be done in the database was being performed at higher layers.[/quote]
As I said, logging is way overused in AOP so I don't like that example. Instead, here's alternative:
"Backups are important".
But are they? My formulation is: "Timely access to up-to-date information is important" Why?
If system fails, the users won't ask whether there are backups, they'll ask when will I be able to use the service again.
Can a backup be restored at all? Problems happen, there was a notorious example related to StackOverflow IIRC where backups were made, but couldn't be restored.
How fast can backups be restored? It can be days, even weeks.
Now that backups are restored, we have *data*, not *information*. Information requires restoration of all services that handle such data. Just having SQL dump of database isn't enough, one must restore the machines, the configs, import data, serve it to users.
When this is done, how much data was lost and how much information? If backups are made weekly, it can be a lot and if it's billing or tax information, this can hurt.
"But I had Microsoft Backup running..." is not enough. It's just the first and mostly uninteresting part of the process.
Problems being solved above are example of that. It's not logging - it's analytics applied to fine-grained real-time data for either online or off-line analysis. Logging is one way to achieve it. But too many get stuck there. Important parts:
- log rotation, aggregation, backups, persistence, legal issues (IP logging, might be required or forbidden), IO throughput
- analytics services and their throughput. Which can handle many machines in real time at what granularity and with how much footprint on IO
- interpretation - who, how? Which queries are supported, can they be modified, who is responsible for them
- response - if logs indicate a problem, who responds, how, in what time frame
The logging problem is what happened with 9/11 or UK's CCTV and has only gotten worse since then. There was data - but everything beyond that was not solved.
----
IMHO and my main point with regard to IBM's Java AOP concept: It's solving the trivial (code writing) part of the 20% of project that is not critical. It's microoptimizing the wrong thing.
Also, Chronon. Post factum AOP with no code modification. It has exactly same shortcomings and benefits as AOP.
PS: Looky here...
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
