Extending NServiceBus

NServicecBus is a very popular enterprise service bus (ESB) for the .NET framework. In this article I will analyze the extensibility facility of NSB, what you can do with it and what you can’t.

Suppose for now we have the a very simple application that sends messages from one endpoint to another. We want to extend the NSB framework to do the following:

  • Outgoing message should be checked for confidential information – like credit card numbers – and censored if necessary.
  • Messages of some specific kind should be augmented with copy right notices.
  • Some messages should be prevented from being send. As an alternative, a simple notice message should be sent instead.
  • The outgoing bytes should be compressed and encrypted.
  • The incoming bytes should be decrypted and decompress before dispatching to the message handlers.

To achieve those requirements I started analyzing the UnicastBus class, which is responsible to taking the message processing them before sending them using the configured transport.

The first extensible point I found was the IMessageModule interface. Classes that implement this interfaces should implement three functions that represents the three different points in the lifecycle of a message handler. Those functions are executed before processing a message, afterwards and afterwards if a problem happened. The biggest short come of this approach  is that the functions take no parameters. You don’t know which messages are being processed, you don’t have access to the bus to send messages on your own. If you know the Alexandria application you will be very disappointed.  Cool things like caching responses and sending them when a matched request is sent is not possible. I’m not sure when to use IMessageHanlder interface. The only usage I’m aware of is managing NHibernate sessions.  The plus side of this interfaces is its easy to use. Just inject all implementations in your IoC Container of choice I you’re cool. NServiceBus will retrieve and call them for you. As I figured out, almost all extensibility points works in same way. Just implement an interface, inject the implementation in the container and you’re done.

The second interface that could be used to grant you access to  message processing pipeline is the interface pair IMutateIncomingMessages and IMutateOutgoingMessages.

The IMutateOutgoingMessages interface has only one method:

IMessage MutateOutgoing(IMessage message);

As you see you don’t just have write access to the message, you have to return the modified you. This can be used to return a wholly different message.

The following snippet shows how to watch sent messages and censor all messages containing the word “Visa”.

public IMessage MutateOutgoing(IMessage message)
{
    var msg = (message as EventMessage);
    if (msg == null)
        return message;

    if (msg.Text.ToLower().Contains("visa"))
    {
        return new CensoredMessage
                   {
                       Text = "Message has been censored!"
                   };
    }
    return msg;
}

Even though you couldn’t prevent sending the message, you can send a replacement message that do pretty nothing. If you have multiple mutators and you would like to execute them in defined order, just introduce them to the container in the same order. IoC containers usually return items in the same order they we configured in.

Accordingly  IMutateIncopmingMessage do the same to the received messages.

 

What we could not do with those interfaces is compressing the outgoing bytes to spare bandwidth.

To do this you have to use the IMapOutgoingTransportMessages interface. Having single method

void MapOutgoing(IMessage[] messages, TransportMessage transportMessage)

it grants you access to original logic messages as well to the serialized bytes.TansportMessage give also an access to the message headers. Those headers could be used to set meta data that can be useful when decompressing the messages.

Using this method we could implement the following compression service

 

void MapOutgoing(IMessage[] messages, TransportMessage transportMessage)
{

    if (!ShouldCompressMessage(transportMessage))
        return;

    transportMessage.Headers["zipped"] = "1";

    byte[] output;
    var inputData = transportMessage.Body;

    using (var inMemoryStream = new MemoryStream(inputData))
    using (var outMemoryStream = new MemoryStream())
    {
        using (var zipStream = new DeflateStream(outMemoryStream, CompressionMode.Compress,leaveOpen: true))
        {
            inMemoryStream.WriteTo(zipStream);
            zipStream.Flush();
        }
        output = outMemoryStream.ToArray();
    }
    transportMessage.Body = output;
}

private bool ShouldCompressMessage(TransportMessage transportMessage)
{
    return transportMessage.Body.Length > 300;
}

Now to the other side of communication. All we have to do to decompress the messages is implementing IMapIncomingTransportMessages, isn’t it? I was very surprised to discover that there is no such an interface. I can’t imagine why there is an IMapOutgoingTransportMessages  interface but no IMapIncomingTransportMessages. I guess it must be on the way. Nevertheless NSB is open source and you can add this interface by your self. Simply by adding the interface and calling its implementations using the container in the right place I could undo the compressing and continue process the message, as if there were no compression at all.

void MapIncoming(TransportMessage transportMessage)
{
    if (!transportMessage.Headers.ContainsKey("zipped"))
        return;

    byte[] output;
    using (var inMemoryStream = new MemoryStream(transportMessage.Body))
    using (var zipStream = new DeflateStream(inMemoryStream, CompressionMode.Decompress,leaveOpen: true))
    {
        using (var strea = new MemoryStream())
        {
            zipStream.CopyTo(strea);
            output = strea.ToArray();
        }
    }
    transportMessage.Body = output;
    transportMessage.Headers.Remove("zipped");
}

That’s all, folks.  Using those techniques you can hook your own processing pipeline to the default pipeline of NSB without (big) modifications to the NSB source code.

Pro .NET 4 Parallel Programming in C#. Book Review.

Disclaimer: This is my first book review and I am definitely not a book critic.  I don’t know which criteria should a good book satisfy or what makes a book better than another, at least from a formal point of view. All what I can tell you is how useful it was for me.

 

The Pro .NET 4 Parallel Programming book is written by Adam Freeman and published by APress.

 

The book is divided by into 8 chapters:

The first chapter is, what a surprise, the introduction. It answers such questions like why should you care about concurrency and parallel programming.

The second chapter introduces the Task class of the Task Parallel Library (TPL) and handles almost all aspects of using it; like staring , cancellation, coordination and handling exceptions of tasks. This chapter makes you love tasks and wish you have never worked with threads.

The third and fourth chapters are about sharing data and coordinating tasks in more details. Those two chapters are what make this book a book about real world problems. You see in this chapter how solve real problems with shared data and control flow. You don’t do solve just embarrassingly parallel problems. Free lunch is over! The subjects in those chapters include locking primitives, signaling other tasks /thread to do work. All of that in great details.

The second two chapters are about parallel loops and parallel Linq. It handles the specialties of those aspects like breaking from a parallel loop or managing order while using parallel Linq.

 

The seventh chapter is about testing and debugging. It shows the new capabilities in Visual Studio 2010, its strengths and weaknesses and how to make use of them.

The last chapter is a great prologue. It shows how to use the TPL to implement well known algorithms like quick sort and MapReduce.

 

After this small summary of the book I will show the things I liked and things I didn’t.

Lets start with the positive side of this parallel coin.

Pros:

  1. All mentioned aspects are handled in great details. If its tasks coordination, you will know how to wait for tasks, how to start a new task after another task finished successfully or with an exception and how to cancel scheduled tasks. Synchronization Primitives are handled in all details. How to use them, when to use the slim version of them, etc.
  2. At the end of each chapter there is a section about common problems and their causes.  You learn which conditions produce such pitfalls and how to avoid them. Actually I have never heard about some of them. I found this chapter to be invaluable.
  3. The practical last chapter helps you solving the jigsaw and orchestrating the small parts of the previous chapters to build real world solutions.

Cons

  1. I’m not sure if this behavior is intended, but this book is merely about the TPL. All introduces techniques, with exception of the Synchronization Primitives maybe, are from the TPL. Threads are mentioned only sparely as way to manage tasks scheduling. Did threads become useless (at least to work directly with)? Are ThreadPools obsolete?  I don’t know.  I wish the book mentioned that explicitly.
  2. The Monitor class has only been mentioned in conjuction with locking objects, but you could use it for other things, like wait and pulsing. I’m not sure if you could simulate this behavior with [(a Manual)|(an Auto)]-ResetEvent. But this should have been mentioned.
  3. The book has its own convention in naming namespaces, classes and private methods.  The namespace Speculative_Cache and class name  Use_Speculative_Cache do not conform to the established conventions. Starting private methods with small letter is also not very common in the .Net world.

Summary

A great book about the TPL. If you are a .NET programmer  then you should read it.  If you think you don’t have to because you will not be needing parallel programming in your daily job then you are the most suitable audience for this book. Your programs will perform better if you learned how make independent small chunks  run independently.

Happy reading!

Harmful Abstractions

Abstraction is a key concept in computer science and math. Abstraction in computer science is the art of hiding details. It could be as simple as the getc() C function that return a single char from some source. That is, the user key strokes, a text file, etc, or a very complicated abstraction like the 7 layers of the ISO TCP protocol. When using the getc() function you are ignoring where the retrieved char come from. It also means that you have, usually, no way of knowing where it comes from. Hence, abstractions are not only ignoring and hiding details.

Modern software is build as a pyramid of abstraction layers. When writing a an application in C#, for instance, you are using an abstraction layer above  the intermediate language (IL). The IL is an abstraction layer  above the the native environment, which, in turn, is  an abstraction layer above the von Neumann computation model. The von Neumann computation model, is an abstraction layer above the electronic gates, which hide the details of current and electrons.  It your software uses the Internet you are very likely to use a framework that abstract the whole abstraction layers of TCP protocol (technically your application resides in the 7th layer – the application layer – of TCP layer. Nevertheless, you have multiple abstraction layer inside it).

It is safe to claim that, without those abstraction layer, writing modern software will be kind of self torturing.

Anyway, this article is not about how useful  are abstractions. It’s about how harmful then can be, when used wrongly. The reason why abstracts could be dangerous lies in the fact, that they may hide important details. Such details could cause the system to stop behaving as expected.  When ignoring details, you are saying “I don’t care about the details because my system will work the same, regardless of the actual detail. Actually this is a very important principle of the S.O.L.I.D priciples: the “Liskov substitution principle”.  This principle states “Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.”

In this definition T is an abstraction over S.  Assuming S´is another subtype of T, this principle doesn’t say that q(x) <=> q(x’), for all instances x from S and s´from S´. To use other words, when defining an abstract you are defining the properties you want to have in all subtypes. Mixing defined with assumed common behavior leads to serious problems. A funny Poster about the LSP states: If it looks like a duck, quacks like a duck, but have batteries – you have properly the wrong abstraction.

Is the rest of this post I will show some harmful abstraction that led/ could lead to dangerous behavior.

 

Databases are memory collections

This abstract has been usually pushed by the raise of the Domain Driven Design (DDD) which encourage persistence  ignorance (PI).  The famous pattern of the PI is the repository pattern which hides the database access details behind a slick interface with few simple methods like : GettAll(), GetById(), etc. This pattern is really great for unit testing. Abstracting the data access layer enables  to replace the database with an in-memory collection of the entities which results in a huge performance hit compared to the accessing the database and, more important, to predictable behavior.

 

Performance problems

The problems start to appear usually after you have established the infra structure of you architecture, usually too late.The problem with this abstraction is that databases don’t work like memory. Navigation from an object to another in the database is not nearly the same as in memory. Round trips to database are far more time consuming than in memory.  Getting too much object from the database is too expensive. All serious  ORM provide lazy loading to load dependencies of some object on demand. To be mainstream conform I will demonstrate this behavior using the blog post with comments example. Loading the blog post from the database doesn’t mean you want to have all comments. This could be worst if the post has attachments in the database. Loading them  is not only slow but could also  be memory exhaustive. Such sub objects could be lazy loaded, i.e. on demand. Now assume you want show the blog post with all its comments. Lazy loading them is known as the select N+1 Problem. The ORM has to query the database N times, that is one time for each comment, and the first time to retrieve the blog post.

If you ignore this issue it bite you later. And it will bite hard!  Not wanting ti discard your beautiful repository and the nice unit tests with the memory collections to try to solve this dilemma adding new specialized functions to the repository. For retrieving all post with comments you add:

GetAllWithComments()

The same problems happen again and again and each time you add a new method to the repository.  The beautiful slick is ain’t slick and beautiful any more. It get bloated with many methods like:

GetAllWithCommentsPaged();

GetAllWithCommntsAndAuthorsPaged();

Get ByTag();

GetByTagWithComments();

GetByTagWithCommentsPaged();

You name it.

 

Context problems

Many ORM embed the database context inside persisted object to keep the connection to the database to retrieve sub object and persist updated value. The context provides further context features like  object lifecycle, transactions, etc.  The consequence of this coupling between objects and content causes the persisted object to depend strongly on the the context. It is not enough for a service class to receive a list of blog posts to calculate the average comments count per one post. I has to assume that the comments are all loaded eagerly, or the context is not disposed. It means also that you can not keep the database object in the memory between requests if you wish you modify them later of navigate in the object graph.

 

Remote calls

Remote calls are calls to a resource on a remote process, remote computer on the same network or a call over the internet. Such calls are afflicted  with long latency.  If you wish to avoid slowing down you application you can all them asynchronously, i.e. starting the call and registering a callback to be executed when the call has terminated. Problems start when  you try to hide the distributed nature of your call. If all what you are doing is calling a webservice to get the weather data and show them on you home page your cool. You can hide the webservice call behind an IWeatherIno interface and nevermind how it works. Of course the latency of you site with get at least as big as the called webservice latency, but no problem. It works!

Now imagine a more complicated situation with many distributed processes.  If a communication partner is waiting for few partners to answer its calls the system will get very slow. And that’s not all. It can get even worse. Deadlocks could render the system unusable.  To demonstrate this situation let us consider the starbucks example. This example demonstrate how multiple process could communicate with each other over a long term to accomplish a business transaction.

A transaction at starbuck involves three actors: a customer, a barista and a cashier. The customer starts the transaction by ordering a drink from the barista. The barista starts making the drink an notify the cashier to bill it. The cashier asks the customer to pay for the drink. The customer pays for the drink. After receiving the payment the cashier notify the barista, which deliver the drink to the customer.

Executing this transaction in the same process yield no problems. The execution flows from object to other as method calls until the initial call of the customer to order a drink terminates.  All needed is one thread.

Now trying to hide the distributed nature could will lead to the following deadlock:

The clients orders a drink and the thread blocks waiting for the asynchronous call to return. As described previously the cashier request the customer to pay. The customer cannot reply because its thread is blocked waiting to the ordering call to terminate, which in turn will not terminate until the payment is done. Every one is blocked waiting for some call to return.  Of course you could assign a second thread to the customer. But what he is ordering two drinks simultaneously? This is a fairly simple example. In a real world  distributed application you will have many of such service calling each other. Abstracting the asynchronous calls behind an interface would harm your system.

 

Hiding the stateless nature of the http protocol

The http Protocol used for the  web communication is stateless by nature. That is, each http connection is new connection that contains no information about previous connections. Classical ASP.NET tried to  get rid of this limitation by using an abstraction layer over the protocol that enables stateful web control.  preserving the state of web page by rendering a huge amount of redundant data the get exchanged each timer between the browser and server.

ASP.NET Also tried to abstract the html behind an object oriented, component based model which failed frequently. The hidden details about the true nature of html could not be ignored without losing of control over the feel and look of the rendered pages

 

I’ve tried in this article to demonstrate how abstract could be harmful if used inappropriately. Consider you abstraction carefully and never assume. And remember if it looks like a duck, quacks like a duck, but have batteries – you have properly the wrong abstraction ;)