Not in applicative code anyway.

This follows up on Ayende’s post about the AOP way.

Now, I have nothing against AOP but some developers are leery of it.

In broader terms, all logging goes in framework-level code. For smart clients, one really good place to put logging is in your Command infrastructure – every time a command is invoked, log it and the args. For data access, well, any decent O/R Mapper has a lot of logging already, just use it. For communication, ditto. Funny that just last week this was one of the major bits of feedback I gave in a code review.

The Important Part

Logging is useful for developers to find out why a system isn’t working correctly.

It is terrible for knowing that a system isn’t working correctly.

If you’re entire exception management strategy is “write it to the log”, how will an admin know that something’s wrong? Did you remember to configure your logging library that errors (and maybe warnings too) should be pushed out to a monitoring system? Do you have a monitoring system?

And if the admins don’t know anything’s wrong, they won’t know they need to increase the fidelity of the logs, will they? Are you planning on providing training for your admins telling them this (and all the other things they need to know)? Or maybe this will all be set up as an automatic script?

An Agile Digression

I hope all that’s on your agile (”we can ship at the end of every 2 week iteration”) product backlog (pardon my cynicism). I hope it’s at least something that you’re looking at per release and feeding the relevant features into your iterations. Yes, there’s project work to do (writing training manuals) that isn’t “development” that needs to be handled; if you don’t timebox it into the same iterations, it won’t get done.

Now, back to you’re regularly schedule logging…

Things Logging Doesn’t Address

Logging is a mildly useless tool for pinpointing where in the system the source of a problem is.

“I know the entity isn’t in the database. I can see that. I want to know why it isn’t there.”

Sure, if you had every SQL statement logged you could figure these sorts of things out out. Of course, performance-wise, you wouldn’t put the system into production like that. In which case, the delete statement wouldn’t have been logged leaving you with precious little information to solve the root cause.

Also consider that the more logging you do, the more crap you’ll have to sift through to find the proverbial needle. Developers often don’t think twice about increasing the amount of crap logs they generate…

The Real Problem

The real problem is that developers think too much about logging and not at all nearly enough about designing the system in ways that it’ll be easy possible to answer questions like those above without having to know exactly how the system is built. One of the reasons that developers should care about this is that it’ll decrease the number of times they need to get up at 3:00 am to answer those questions.

A Path to the Solution

Now, if you had some kind of business activity monitoring (BAM) capability in your system, an admin could do a simple search/query [WHEN entity DELETED] and find out answers to the questions above, find out the time that the relevant activities occurred, figure out what the problem is on their own, and maybe even fix it – especially if it has to do with some esoteric configuration variable.Regardless of whether you buy a BAM tool or roll what you need yourself, you need to understand what about the system needs to be monitored. That’s a very different thought-process to go through than “should we log this? Yeah, sure, why not.”

It’s called “Design for Operations”.

Take a holistic perspective on exception management, logging, monitoring, etc. Think about questions like those above and then analyse your use of the relevant tools in that context. Think about all the different kinds of users of the information that’s going to be generated and how quickly their going to need to act on that information. Admins in the data-center in the middle of a crisis are going to have different needs than developers analysing logs on their machine. Think about:

• How will the administrator know that a server has been configured properly?
• If the system is feeling slow, how can the administrator know which server/process is to blame?
• So that maybe they can scale out that part of the system.

In Closing

It’s a mindset.

It takes time to make the shift.

It takes more time to bring the development process to this kind of maturity (god, I hate that word).

Writing exceptions to the log is not a strategy.

At the very best, its a tactic.

What’s your strategy?

You see, the main problem that I hadn’t been able to solve was that in order for the code to be thread-safe, you had to make sure that no code in the views would/could change entity data. One solution is not to use data-binding, which sucks, but isn’t enough to be sure. Another solution is to have all supervising-controllers clone an entity before they give it to a view. Even if you could possibly code review every line of those classes, the new guy (or old guy who forgot) will, by accident, write one new line of code that could pass an entity to a view without cloning it first. That’s not a very sustainable solution.

This thing has been bothering me for a couple of months now and I hadn’t found a way around it. Until yesterday, like I said. I was talking to somebody about threading stuff, and somehow my unconscience lobbed me this thought about AOP. Now I’m not the sharpest pencil in the pack, but I know to listen when my unconscience “speaks”.

So I set about going over what I knew about AOP – interceptors, advisors, advice, introductions, etc, etc. And then it dawned on me. I could intercept all calls to any object that implemented IView, check the parameters of those calls, and if they implemented IEntity, to clone them before passing them through.

<Homer-style WOOHOO />

The great thing is that developers don’t need to remember to clone entities – it happens automatically. The even greater thing is that this will lead developers to writing the correct kind of interaction between their views and supervising controllers.

Together with nServiceBus, this is going to make the extremely difficult problem of writing thread-safe smart clients possible.

I’ve never made use of AOP in a framework before so I’d like to get the broader community’s feedback on this before incorporating this in production. I’ve spoken with some serious AOP folks who have allayed most of my uncertainties, but I’d like to hear more. Anyway, here’s the proof of concept (that makes use of Spring).

If this turns out to be a viable solution, I think we’ll have a solid environment for building a software factory on top of. That is something that I’m really excited about. In this multi-core future (present) that is upon us, multi-threading on the client is pretty much a necessity. We need a way to get things safe and stable by default without requiring a member of the CLR team to hold our hand.

Anybody who’s interested in helping, drop a comment below.

First of all, I would like both developers and managers to read the previous entry because of its profound meaning. We CAN and should separate different parts of the system having differing levels of risk. Once again, “3-tier architectures” don’t address these issues. So, if we are dividing the architecture along risk lines as well, then obviously the UI would be the riskiest – having the highest probability to change – over the life of the project.

However, business rules are often considered quite stable. Why ? Because their time-line of change is often stretched out over many project life-times – rather obvious really, business rules deal with the business, not the project. During development of the project we are often given the requirements in such a way that it is difficult to know what is domain knowledge and what is a business rule. It takes effort to separate out what are the business rules – what has changed in the past, and what will change in the future.

For example, in an academic project I performed some time ago, I was given a set of requirements including: 1. A student can register to a given course once in a semester. 2. A student can register to a project in a semester. Which is the business rule, which is the domain ? In this case (1) is the domain, and (2) is the rule – “a project” meaning “only one project” as I later found out. This rule changed sometime after my second alpha to “A student can register to only one project alone in a semester, but several projects in the same semester as long as they have a partner for each of those projects.”

As it is apparent, I, as a developer, have to take into account these risk/change factors and change my architecture accordingly. Ever since that project I have always created a business rules layer separate from the infamous “BL” ( Business Logic ).

Now, getting to the issue of implemeting using aspects. I am a big proponent of AOP, however I often find alternative implementations to be more desirable. Most of the examples given for the use of AOP including logging, transactions, security and others that can be made part of a framework, as .Net has done in many cases. Many have pushed Java’s superiority because of AspectJ, and although .Net doesn’t have an Aspect.Net yet ( although various developments are under way ), I have yet to miss it. Clemens Vasters has done some truly incredible stuff in the use of attributes in .Net for implementing AOP stuff. I’ve always thought that attributes should be used that way. I find that there is one basic flaw in the conclusion to using aspects for connecting business rules to systems. The entire white paper is here. ( Yes, its a pdf unfortunately – only good for print really, Jakob Nielsen thinks so too. ) The basic premise is that I’m building an entire system in an OO manner, which I’ve stopped doing some time ago for these reasons. Clemens has great insights on this as well, see them here.

When using an SOA, your UI, or any other system needing services for that matter, will be sending messages to the guts of your system – the “BL” for you hardcore 3-tier-guys. Let’s call the thing receiving messages in this case the Gateway. All the gateway does is receive messages ( like “Register student number 12 to course number 15 in semester 21″ ) and pass them on to the appropriate handler. The word “handler” hear is used like in the term “event handler” for a reason: The receipt of a message is an event. In the white-paper the authors refer to these events as a problem that has to be dealt with. Why ? Because when working in an object oriented fashion, you would have to intercept the call to: new Student(12).RegisterToProject(93); in order to handle the event, ie check/activate a business rule. Aspects are great for this sort of thing. However, when working in a service-oriented fashion, you would send a message of type “RegisterStudentToProject” with the parameters StudentID and ProjectID as above. No need to intercept any call since it has to first go through the gateway. The gateway would then pass the message to the business rules engine which would then find and activate the appropriate rules before and after the actual call to register the student.

The rules engine does something like this:

If ( ActivateBusinessRulesForMessageAndReturnTrueIfCanMakeCall(myMessage) )
{
MakeCallForMessage(myMessage);
ActivateBusinessRulesAfterMessage(myMessage);
}

The business rules themeselves are implemented in a separate layer than the engine. The mapping between rules and messages is also done in a layer separate from both the engine and the rules. Once we have a layer for each of these, we have architecturally separated the parts that change more often in the system from the rest of it. One can also move to a more dynamic model. One in which you define a language for defining rules, and the mapping to messages as well. Thus, changes could be made by changing a configuration file instead of recompiling any part of the system.

Note that when you have lots of rules and the order for activating them matters, you should move to a commercial rule engine instead of implementing your own. You’ll see that performance becomes an issue as the number of rules increases.

I hope that I’ve managed to introduce yet another strength of the SOA over the pure OO paradigm. Tell me what you think ! Where does the SOA fall short ? Where does the OOA beat the SOA ? Am I full of it ?