August 2006 - Posts

After writing my previous post on a modeling-language for exception-management logic I ended up in a fair amount of discussions about the sense (and nonsense) of describing parts of a program in a model *and* treating the model itself as part of the sourcecode.

Aspect orientation and limitations to Object orientation
The dsl-model is nothing more than an aspect oriented programming language. Aspect oriented languages allow for expressing parts of a program in a fashion that does not mix concepts like 'exception handling', 'caching', 'thread synchronization', etc. with the parts that make your program do its work.

In object oriented languages (like c#) it is often hard to write programs that contain the concepts above without cluttering your sourcecode -which referred to as tangling in aop terminology.

Since most applications we write need good exception handling this usually means that we end up mixin our programs code with exception handling logic (which makes the code itself more complex) -or failing to do so consistently (which lowers the quality of a program).

How do Aspect oriented languages solve this problem?
Aspect oriented languages have the concept of a joinpoint. A joinpoint is a descriptor of a point within your program ("before any method prefixed 'Get' is called", "when an unhandled exception occurs within methods x, y, z", "before a exception will be thrown", etc..). These joinpoints allow an aspect oriented language to express all tangling parts of your code to be written down in 1 place, instead of mixing this with the rest of your code with it.

To break it down
The exception management language knows about 
* 1 joinpoint: "when an unhandled exception occurs in method x, y, z"
* How to insert this 1 line of code in a .net assembly ( if ExceptionPolicy.HandleException(e, "xyz") throw; )
* The model in which all the variables are expressed.

Added value:
* It allows you to define all your exception management code in 1 place (and keeping your program code clean)
* It never forgets to enforce best practices (that you might forget yourself using c# as an implementation language -the same way a compiler hides all the pushing and popping of registers when you write c++ code)

Why a modeling language?
Modeling language are straightforward to understand and since Microsoft is putting a lot of effort into having a dsl-toolkit to support the authoring of modelling languages hosted in visual studio, this seemed a neat approach. really, it could be any sort of notation.

Software factories?
Since I think software factories are about working with more appropriate levels of abstraction than 3rd level programming languages provide, I think the exception management languages serves that cause.

No "drag-cows-and-pigs-around-the-screen-diagram", 'just' a simple solution to solve 1 aspect of what makes writing applications an increasingly complex task.

Loss of flexibility?
When working with higher levels of abstraction comes loss of flexibility -right?, right!

To illustrate: When programming c++, you have less control over your memory than when you are writing x86 assembly instructions. But… is this a bad thing? Well it might if you want to squeeze every little drop of performance out of your code, for most scenarios it eases development and increases productivity.

With the flexibility Enterprise Libraries ExceptionHadling block provides from its configuration (yes - this includes adding context to thrown exceptions, replacing exceptions, hiding exceptions and ..whatever) would automatically inserting this code at predefined places in your program be a bad thing? -Well it might if you want some custom tailored exception handling scenario within your code, in most cases it eases development. Does it make having a custom solution in place harder or impossible? No it doesn't (as long as the rest of your program is written in c#).

On a side note: I believe flexibility will be increasingly gained by configuration, not sourcecode - the same way Enterprise Library does.

Next steps with in developing these sorts of models
Yes I would love to release the exception management language asap, though first I would like to solve some practical problems in its current implementation, naming:
1) The classes you drag on the designer surface currently come from the toolbox, which is impractical and should be fixed.
2) References to the classes in your sourcecode are not tracked, which could be solved by annotating them using a code comment similar to "//do not remove the following guid: {xxxxx-xxxxxx-xxxxxx-xxxxx}"

I also figured that having these 2 problems solved in a framework layer, would lower cost of writing new similar dsl's. I could think of a couple, such as:
* Caching, in which you define whether the outcode of a method call should be stored in a (configurable) cache.
* Security, in which you define which methods can be executed by whom, based on roles.
* Tracing/logging, should the execution of this method (and possibly its parameters passed to this method) be logged?
* Instrumentation, should performance counters be incremented every time a method is called? Should wmi events be fired if a certain condition is met?

The above are all examples of aspects that can be mixed into a program without having developers to know about it - they do not mess with the state of a class or alter program flow.

If there are people truly eager to contribute, please let me know.

Modeling the base language
With base language I mean the language your program is written in, all of the above assumes c#.

Big question is: would it be possible to eventually express the way your program behaves in a more specialized language? -I'd say it might. Pragmatic as I am I’d go with first defining models for patterns we currently identify and iteratively discover new patterns in whatever is left.

In the Aspect oriented programming community there are people that believe in something called "Symmetric AOP" - an approach to aspect orientation in which everything is expressed as being an aspect (also the base implementation). Somehow people actually managed to make implementations of such languages, such as HyperJ.

Amen -

Since I am currently experimenting with both the dsl-toolkit and PostSharp (which is a .net postcompiler) I thought of the following:

 

An ELExceptionManagementLanguage.

 

This 'language' allows you to draw a diagram defining your exception policies and drop classes from your project in them (meaning that exceptions thrown in these classes should be handled according to that exception policy).

 

It currently looks like the following:



1) In the toolbox you can see a list of classes currently in your project (organized by namespace).
2) On the drawing surface you can see 2 Exception policies “DataAccessExceptionPolicy” and “BusinessLogicExceptionPolicy”, they contain the classes “QouteDAL” and “GetQouteAction”

 

 

Drawing is fun, but what to do with this view?

Well, using PostSharp I’ve created a little program that:

1)     Loads the dsl-file you created

2)     Opens up the assembly the classes are part of

3)     Modifies the assembly and inserts all the exceptionhandling code you never wrote a line of c# for!

 

The code for “GetQuoteAction” in this project looks like this:

 

namespace BusinessLogic

{

    public class GetQuoteAction

    {

        public Quote Execute(string qoute)

        {

            double value = QouteDAL.GetQouteFromDB(qoute);

            return new Quote(value);

        }

    }

}

Though, after compiling (and having the program run as a post-build step), the actual IL in it the output-assembly would look like the following in C#:



 

In case you where wondering:

yes – I’ll put the solution on my weblog as soon as I got my mind around howto deploy it
no – I haven’t tested it on complex scenario’s. The mangling of assembly instructions is done by postsharp, and I know Gael is eager on receiving feedback.
yes – Writing dsl’s is hard, but after writing a couple of diagram’s you sort-of get the hang of it
no – Loading classes from your project into your dsl’s toolbox isn’t a smart thing to do, the toolbox items are loaded when visual studio is started – which means you will have to restart VS after adding classes to your project in order to add them to the model
yes – The days of writing exception management code are over! :-)

The first of august has passed and the winner of the 'help me find issues'-contest  (and the US$ 100) is... Dfriedel.

Dfriedel has some good suggestions from a sys-admins viewpoint including:
    1) Automatically backing up the configuration file before saving it
    and 2) Having the tool remember which configuration files were opened last time.

Also thanks to all the others that contibuted issues to the CoMan project!

Dfriedel please contact me in order for me to get you your price.

As soon as time permits I'll schedule the next release of CoMan, so stay in tuned...