Distributed Transactions versus Compensation – Part 1 the planning

This week is a very important week for me. I have my first presentation at GASP. A group of architects from Portugal. I’m really excited about it and working real hard to leave a good impression :).

I’m not really an expert on transactions and not that good at database planning and designing. So this plays a really big challenge on me. Which is really great!

I’ve seen a couple of presentations advocating that compensation is a much better approach to dealing with concurrency in SOA than distributed transactions. It is really easy to visualize why, locks across machine boundaries and maybe even organization boundaries smell bad even if I don’t try it. It would be really great if you could base your opinion’s on how much an idea makes you uncomfortable!

In the real world people prefer numbers to emotions when it comes to technology or science. It might be the case that some ISV is trying to sell us a couple of products that will make our life much easier. Maybe it is not really that bad. Maybe we can pay the performance price by gaining in the development costs.

So what I am working on is on a way to measure how much is a compensation based solution better than a distributed transaction solution. One of this days I’m going to put a large enough team developing business code based on this difference and I better get a clear picture of the benefits because this will really hurt $ the company I work for :).

I’ve been working in IT for some years and this is the first time I can remember that I am actually using something coming from college. I’m using science methods and planning and experiment to get some data out. Remember? Built an hypotheses, plan an experiment, collect date, compare it against expect theoretical values and extract conclusions. This is the closest I can get from the excitement of accelerating particles at 7 TeV at LHC :).

I have divided my experiment in several areas:

First I need a data model that exposes the problem of concurrent accesses and a service oriented solution that manages that data model.

If the data model is too small it will affect the experiment because SQL optimizations will work better. The smaller each data row is the better they fit in a single page in SQL.

Than I need a deployment model for that SOA solution:

• Single machine.
• Intra Network.
• Internet

I need hardware to conduct the experiment. And at this moment I am stuck with this problem. I can only get two laptops… The IO capability of SQL server will be greatly influenced by this in the experiment. The goods news is that it will affect evenly (because the hardware is similar) all the services and therefore the numbers will be scaled down compared to real servers (hopefully).

Then I need a way to simulate simultaneous concurrent accesses from a service consumer perspective. This is not easy when you have limits on hardware. Real world solutions are accessed by millions of different client machines and there is no way you can simulate that with threads. You have hardware and software constraints (such as number of connections per socket). But there is not much to think there. The only way I can think of is using different threads.

After this I need to think on the Isolation levels I want to test. I have decided to limit these to:

• Read Uncommitted.
• Read Committed.
• Serializable.
• Snapshot.

Finally I need to decide how I will collect and organize data to extract conclusions. I will have a single table that will record each operation time. I will divide testing into phases so that I can correlate different types of concurrent accesses. For instance there will be a phase where only a master/detail table relation will be accessed. There will be times where all possible scenarios will be accessed simultaneously. With this I can extract different averages and compare then. Enterprise library can really help here.

In the next posts I will post my data models, data collection models and source code for the experiment. Stay close.

Dependency Containers and Design by Contract

Design by contract used to bring an idea of complexity to me before I could really understand the idea and get my hands dirty on it.

The main idea I try to follow is that major system components should be represented by what they do and not by what they are. Let’s pick up a simple idea, a collection. A collection is something that is able to return an enumerator to transverse its elements, it can add an element to it and it can return how many elements it is holding. These are some of the things a collection is able to do.

A collection can be a list, it can be a tree, it can be a stack, as long as it can behave as a collection it is a collection. If you search for Duck Typing you will get a lot of funny stories about this idea.

When possible we should encourage replacing concrete objects by their abstractions because the code written against abstractions obviously promotes more reusability.

In most cases designing by contract is writing the interface first and implementing the classes that realize then after. This was what I did on this really dummy invoicing system:

#region contracts

   /// <summary>
   /// Manages aspects related with user authorization.
   /// </summary>
   public interface IAuthorizationManager
   {
       bool Authenticate(string user, string password);
   }

   /// <summary>
   /// Traces who did what, when.
   /// </summary>
   public interface IAuditingManager
   {
       bool WriteAuditInformation(string operation, string who, DateTime when, object what);
   }

   /// <summary>
   /// Manages invoicing operations.
   /// </summary>
   public interface IInvoicingManager
   {
       void CreateInvoice(string salesPerson, string customerCode, string[] products, decimal[] unitPrices, decimal[] quantities);
   }

#endregion

Then I created a concrete class that uses this components ( I could have been a purist and write a contract for it :) ):

public class SalesSystem
{
   public IAuditingManager AuditingSystem
   {
       get;
       private set;
   }

   public IAuthorizationManager AuthorizationSystem
   {
       get;
       private set;
   }

   public IInvoicingManager InvoicingSystem
   {
       get;
       private set;
   }

   public SalesSystem(IAuditingManager auditingSystem, IAuthorizationManager authorizationSystem, IInvoicingManager invocingSystem)
   {
       this.AuditingSystem = auditingSystem;
       this.AuthorizationSystem = authorizationSystem;
       this.InvoicingSystem = invocingSystem;
   }
}

Note how I pass in all the objects in the constructor. It is good to read my post on the "Law of Demeter”.

These are my really dummy realizations of these classes (do note the really bullet proof the security code :)!)

#region really dummy realizations

internal class MyAuthorizationManager : IAuthorizationManager
{
    #region IAuthorizationManager Members

    public bool Authenticate(string user, string password)
    {
        if (string.Compare(user, "user1", StringComparison.OrdinalIgnoreCase)==0)
        {
            if (string.Compare(password, "123", StringComparison.Ordinal) == 0)
            {
                return true;
            }
        }

        return false;
    }

    #endregion
}

internal class MyAuditingManager : IAuditingManager
{
    #region IAuditingManager Members

    public bool WriteAuditInformation(string operation, string who,DateTime when, object what)
    {
        Console.WriteLine("{0} by {1} at {2} over {3}", operation, who, when, what.ToString());
        return true;
    }

    #endregion
}

internal class MyInvoicingManager : IInvoicingManager
{
    public MyInvoicingManager(IAuditingManager auditing)
    {
        this.Auditing = auditing;
    }

    public IAuditingManager Auditing
    {
        get;
        private set;
    }

    #region IInvoicingManager Members

    public void CreateInvoice(string salesPerson, string customerCode, string[] products, decimal[] unitPrices, decimal[] quantities)
    {
        Console.WriteLine("Invoice created for {0}", customerCode);
        this.Auditing.WriteAuditInformation("CreateInvoice", salesPerson, DateTime.Now, "Invoice");
    }

    #endregion
}

#endregion

Now comes the time to introduce the idea of a dependency container. It is really a component to help lazy guys like me. I don’t want to write code to create an authorization manager, a audit manager and an invoicing manager just to create my sales system. I still have to work for the next 30 years and I need to save my fingers.

Without the jokes what I don’t want to do is call the constructors on those components because as the system evolves they will change, when they change things will get broken and I will be in trouble. What I want is a system that is really smart and does all those boring news by me. This system is Unity.

Unity is a dependency container and it can resolve dependencies by me. It I tell him what classes realize my contracts we can the create instances of other classes that required these contracts to be built:

class Program
{
    static void Main(string[] args)
    {
        UnityContainer unityContainer = new UnityContainer();

        unityContainer.RegisterType(typeof(IAuditingManager), typeof(MyAuditingManager));
        unityContainer.RegisterType(typeof(IAuthorizationManager), typeof(MyAuthorizationManager));
        unityContainer.RegisterType(typeof(IInvoicingManager), typeof(MyInvoicingManager));

        SalesSystem system = unityContainer.Resolve<SalesSystem>();

        if (system.AuthorizationSystem.Authenticate("User1", "123"))
        {
            system.InvoicingSystem.CreateInvoice("User1", "Customer1", new string[] { "Product1" }, new decimal[] { 10.0M }, new decimal[] { 1.2M });
        }

    }
}

Try to write the code to replace these by Mock objects :). If you are a fan of TDD you will love this.

Law of Demeter’s, or please count your dots.

The “Law of Demeter” says that a method “M” should only invoke the methods of the following kinds of objects:

· Itself;

· Its parameters;

· Any object it creates;

· Its direct component objects.

When programming C# if more than two dots (excluding the this.) are typed then this law is broken. The study that gave birth to this law arguments that complying to it enhances the maintainability of the system being developed.

It is easy to empirically understand why, the more dots we enter the more details about how an object is built are we revealing and therefore increasing the possibility of breaking something when we change something of that implementation.

I read a lot of code and most people just ignore this problem, I used to as well. Now I break the rule a couple of times a day but I always do it after thinking a couple of seconds about what could I do to respect it. Most of the times it starts by increasing by one the number of arguments of a class constructor and replacing the class by a contract (abstract class or interface).

Why? Well if you can use this.a.b.c then you have set a reference to a contract that represents what c does in your current class. Imagine you do this all the time. Now imagine you replace you c’s contract by a Mock object. Its really easy to test… ;)

If once adding arguments to a constructor was putting effort into the guy that is going to create instances of it, today with the latest enhancements in dependency inversion and dependency containers it is not that bad.

Most containers also support injection in the instance properties and so there is a lot to win on following this simple principle and it is really not that hard. Please read on the article on containers to get your hands dirty.

Subtleties in C# Anonymous methods

Last Friday I had a really bad time figuring out a bug in an anonymous method. The bug was related with the way anonymous methods are implemented in C# and variable scoping. Being the scenes the compiler is generating a class to hold the delegate and references to the variables that are grabbed in the scope of the block holding the delegate. The reference will be hold in memory for the all lifecycle of the delegate object.

The original code was:

foreach (PropertyInfo property in allProperties)
{
    object propertyValue = GetTypePropertyValue(this, property);

    MyObject1 myObject1Value = propertyValue as INotifyPropertyChanged;
    if (myObject1Value != null)
    {
        myObject1Value.PropertyChanged += delegate(object sender, PropertyChangedEventArgs ev)
        {
            this.NotifyPropertyChanged(property.Name);
        };
    }
}

The code fixed code is something like this:

foreach (PropertyInfo property in allProperties)
{
    object propertyValue = GetTypePropertyValue(this, property);

    MyObject1 myObject1Value = propertyValue as INotifyPropertyChanged;
    if (myObject1Value != null)
    {
        string propertyName = property.Name;
        myObject1Value.PropertyChanged += delegate(object sender, PropertyChangedEventArgs ev)
        {
            this.NotifyPropertyChanged(propertyName);
        };
    }
}

The difference is declaring a string variable outside the anonymous method and copying the property’s name into it. Being the scene the compiler will grab a reference to the string that is an immutable object and that reference won’t get modified.