I do a Google search a year later & I find my own post and I don’t like it.
There are several issues with this post:

Firstly sending objects over the wire was always a bad idea, this post was trying to dodge that as the team did not want to move to DTOs, which i maintain would have saved us time in the end. The real fix is to map the entities to DTO’s and send those over the wire specific to the service calls needs.
Secondly MANY-MANY joins are not cool. There are very few places where Many-Many actually exists. Hiding the join in the Entity should have been done, not eliminating the mapping and the joining classes. Redoing this i would have kept the joining class and mapping as a one-many many-one relationship.

eg to expose a customers favourite restaurants

public class Customer
{
//stuff
public IEnummerable GetFavouriteRestaurants()
{
    foreach(var customerRestaurant in CustomerRestaurants)
    {
        if(customerRestaurant.IsValid())//some check if required
            yield return customerRestaurant.Restaurant; 
    }
}

This now hides the notion of a CustomerRestaurant entity from the outside world as it can be contained with the realms of the domain entity classes (that being Customer and Restaurant)

Well, i guess its good to review ones work, I’m not happy that this was a decision I made, however acknowledging ones mistake is an opportunity for growth

In a time were TDD and Continuous Integration is becoming common place Gallio is a great tool to have in the tool belt. I have been a fan of the related MbUnit for several years but only in the last 6 months have I really seen the light in the separation of the Gallio project and why it is such a good thing.

Lets back the truck up a bit and shed some light on what exactly (in my mind) Gallio really is then we can talk about why you would want to use it.

Gallio is basically an interop facility that act act as a generic test runner. Sure it can be much more than that but at the end of the day 99.99% of people that would be using it  will be using it as a  means to execute tests. Gallio actually is a project that has broken away from the MbUnit project to provide an neutral test runner for other test frameworks.

So what the hell is a test runner? Firstly we would need to look at how we would normally run a (unit) test. Firstly we would typically choose a test framework to write tests in; the common API’s that fall in to this category are NUnit, MbUnit, XUnit.Net and MSTest. These allow us to write classes and methods with attributes that describe what and how we wish to test the system under test (SUT). Writing these test does not run the tests, we still need something to kick the process off. This is where our test runners come in to play. TestDriven.Net, ReSharper, Visual Studio test window and the various separate GUI that come with the frameworks (e.g. Nunit GUI Runner and Icarus for MbUnit) allow us to select what tests we wish to execute. Unfortunately there is some degree of coupling present here, i.e. the Visual studio test runner may or may not run your given test framework, NUnit GUI surely doesn’t run XUnit tests. There is also the very large issue of being able to run these from the command line or a script; this is pretty important for continuous integration. This is where Gallio fits.

Gallio provide a neutral system that provides a “neutral system for .NET that provides a common object model, runtime services and tools (such as test runners) that may be leveraged by any number of test frameworks.” What this means is Gallio can sneak in between your chosen test runner and the test API, providing an abstraction between the two. When I first understood this is was underwhelmed… who cares? Well apparently I do!

You see at my current place of work we, like many .Net teams, use MSTest as our test framework. Being the good kids we are we were keen to get CI up and running and with out TFS properly installed (at the time) we decide to use TeamCity as  our build server. Its a great tool and I have no regrets in using it. Unfortunately trying to get MSTest test to run from a script is a little fiddly and requires an install of a version of visual studio that has MSTest on it on the machine that want to run the test script. Obviously we want or build server to run the test for the solution too, so now we had to install Visual Studio onto our build server… this is not cool.

1. It takes up a lot of space, we had to fight to get a VM created for us to have a build server and  installing VS took up most of the space we were given
2. We had just used up one of our licences of Visual Studio. VS is not cheap. Sure, I work for a huge company that haemorrhages cash, but wasting money is still wasting money.

Enter Gallio. With a minor adjustment* of our build script I can now use Gallio to run my MSTest tests from my MSBuild script. This is pretty cool. What this means is now I have a test framework agnostic build script. If we converted all of our tests to MbUnit I would not have to change my build scripts; MbUnit is supported by Gallio so I am covered. This also means I have nice reports generated for me without crazy MSTest stuff spewing all over my hard drive. The reports are very clean, configurable and human readable. I can show my department manager (who may or may not be technical) the test reports for all of our projects and he can see what state they are in. Having a clean readable report seriously helps in promoting our good work, something an MSBuild log file or nasty MSTest XML would not do so well.

OK so who should be interested in Gallio?

People who “do” CI: Having a free test runner on the build server may be saving you cash and is a big benefit, I would say however having a neutral runner means easier maintenance and is the biggest win here. The build scripts will all use the same syntax. Gallio works with the above mention test frameworks but also integrates with MSBuild, NAnt, NCover, PowerShell, CC.Net and TeamCity.

People who use (or potentially may use) more than one test framework: Having Gallio in the mix means running NUnit from visual studio is very simple. Pick your poison; TD.Net, ReSharper and VS can all now run that or any other Gallio supported framework.

People who want good consistent Test Reports: This is certainly my opinion, but I really like the Gallio reports. They are clear, easy to navigate and if you are using multiple frameworks you can now have a consistent format to display your reports.

Something to get you started – an MSBuild template for using the Gallio.MSbuildTasks assembly:

    
    
    
    
        
        
    
    
        <Gallio 
            Assemblies="@(TestAssemblies)">
            IgnoreFailures="true" 
            ReportDirectory="%(ReportDirectory)"
            ReportTypes="html"
            ShowReports="true"> 
            <!-- This tells MSBuild to store the output value of the task's ExitCode property
                 into the project's ExitCode property -->
            
        
        
    

Hopefully this helps shed some light on the Gallio project and how it may fit into your build and test process.

*The minor adjustment is actually cleaning up the script which is also a good thing. It is much clearer what is happening. The MSTest hacks involve small amounts of wand waving.

[Intro]

The glue that ties all of MassTransit’s moving pieces has to be done  on starting you application. We need configure the service to know what to start up, how to find it and in what context to run it.

MassTransit has split the host service into a separate project, namely TopShelf. you will see TopShelf being used to set up our MassTransit programs in the entry points of our application, typically with the Program.Main(string[] args) method.

The basic set up steps for creating a runner configuration are:

• Describe the Service
• Instruct how the service will be run
• Configure the the service

Once you have done this, the TopShelf Runner can host the service.

Describing the Service means give the service a name, a display name and a description. The display name and description are visible from the Service Control Manager while the service name is intend for console line interactions

Instructing how the service will be run: Define any known dependencies (MSMQ, IIS, SqlServer etc), any actions that should be performed prior to running the service/host and also how the service is to be run: i.e what credentials will the service run under. We can also use the UseWinFormHost where we can supply the name of the WinForm that is the host. This is great for demos, but I am not sure if it is intended for production use… Chris and Dru may care to comment on this; either way its handy when getting to terms with the stack.

Next we need to configure the service(s) we are hosting. In here we can define some delegate for certain event in service life (WhenStarted, WhenStopped etc) and we can also weave some of our IoC voodoo majic by defining our service locator. Again the authors have decided to use Castle Windsor for the sample, however I believe you can use any of the CommonServiceLocator Containers. As this method need to returns something that implements IServiceLocator, using the DefaultMassTransitContainer type makes life a little easier as it does a fair bit of the plumbing for you including setting the current service locator to itself.

[STAThread]
private static void Main(string[] args)
{
//from Starbucks.Barista.Program.Main(string[] args) - Modified for readability
var cfg = RunnerConfigurator.New(configurator =>
    {
        //Describe the Service        
        configurator.SetServiceName("StarbucksBarista");
        configurator.SetDisplayName("Starbucks Barista");
        configurator.SetDescription("A Mass Transit sample service for making orders of coffee.");

        //Instruct How the service will be run        
        configurator.DependencyOnMsmq();
        configurator.RunAsFromInteractive();
        configurator.BeforeStart(a => { });

        //Configure the service(s)        
        configurator.ConfigureService(serviceConfigurator =>
            {
                serviceConfigurator.CreateServiceLocator(() =>
                    {
                         //Use MassTransit's built in Container (Castle Windsor specific), described earlier                        
                        IWindsorContainer container = new DefaultMassTransitContainer("Starbucks.Barista.Castle.xml");

                        //Add the components to the container                        
                        container.AddComponent("sagaRepository", typeof(ISagaRepository), typeof(InMemorySagaRepository));
                        container.AddComponent();
                        container.AddComponent();

                        //Tracing - not super important in this context                       
                        Trace.Listeners.Add(new TextWriterTraceListener(Console.Out));
                        StateMachineInspector.Trace(new DrinkPreparationSaga(CombGuid.Generate()));

                        //Return the Current ServiceLocator, which has been assigned in the DefaultMassTransitContainer ctor
                        return ServiceLocator.Current;
                    });
                //Define delegates (specifically service methods) to fire on given ServiceConfigurator events
                serviceConfigurator.WhenStarted(baristaService => baristaService.Start());
                serviceConfigurator.WhenStopped(baristaService => baristaService.Stop());
            });
    });
Runner.Host(cfg, args);
}

[Intro]

Many people will be familiar with the notion of an “End Point” especially those who use WCF or other web service frameworks. An end point is “the entry point to a service, a process, or a queue or topic destination”. My WCF background has had the ABC drilled into me (Address, Binding and Contract) as the 3 things that basically define an end point. MT is pretty much the same. Also like WCF, the endpoints are a configuration aspects of the solution so it seems valid to put this information in a config file. The MT boys are clearly Castle fans (although other IoC frameworks can be used) and they have chosen in most of the samples to use Castle Windsor to configure the endpoints.

SIDE NOTE: For those unaware of Castle Windsor (an IoC implementation) it allows you to write loosely coupled code and specify the concrete implementation detail via config, a little bit like the example of the Asp.Net Membership Provider which is a plug in pattern. Using MT without understanding IoC may prove to be difficult… in fact I would say you are almost certainly biting off more than you can chew. Look in to the Castle stack, it really is great OSS framework to help pick up good habits.

Moving on…

The defining of the endpoints should not be confused with the Castle implementation. It is just as easy to do this in code. Anyway Lets walk through a typical castle config file for MT:

From the Starbucks Sample:

  
    
      <bus id="customer"
                 endpoint="msmq://localhost/mt_client">
        
        
      
      
        MassTransit.Transports.Msmq.MsmqEndpoint, MassTransit.Transports.Msmq
      
    
  

First and foremost this is a castle config. The name of the file “Starbucks.Customer.Castle.xml” is a pretty good hint and I know “facilities” is a castle concept. MassTransit have embraced the concept of facilities which you can investigate here. MassTransit have their own Facility, namely the MassTransit.WindsorIntegration.MassTransitFacility which helps us get up and running with out having to know about all the plumbing. In this MassTransit specific facility we define the Bus and the Transports. The transports child node is equivalent to our “Binding”; it is essential so we know what transport mechanism to use. You will see standard .Net notation for expressing a type in XML, i.e: “Fully.Qualified.Namspace.TypeName, Assembly.Name”. This type must implement the interface MassTransit.IEndpoint. Currently there are adapters for MSMQ, NMS, Amazon SQS and WCF.

The other child node in the facility defines the Bus. Here we give the Bus a identifier and its end point. These are both mandatory. The end point will be the URI the bus will receive communication from, when the application publishes a message. The Id indicates that there can be multiple buses configured, which there can. The bus also can have several child nodes specifically:

• controlBus
• dispatcher
• subscriptionService
• managementService

The Control Bus is involved in managing the disparate system. For example the Starbucks example uses a control bus to manage the interaction amongst the server side consumers: the Cashier and the Barrister. For more info on a Control bus see page 540 in Enterprise Integration Patterns.

The Dispatcher is a means to control the use of threads. High volume message interaction can be handled using multithreading specifically with the attributes maxThreads and readThreads, both of which are self explanatory integer values.

The Subscription Service is the common service that provides an endpoint for subscriptions. The only value required is the end point attribute.

The Management Service allows for specifying a heartbeat monitor for checking the health of your services queue. The samples use the SubscriptionManagerGUI to show the queues  that are being listened to and the health of the subscriptions.

I do not believe any of these bus child nodes are mandatory, from looking into the code the only requirements are that the bus has must have an id & end point and the facility has a defined transport.

There are a couple of notes for new comers to Castle and MassTransit. Like most config files the XML file that is shown above should have its build action as “Content, Copy Always”. The Queues that each service uses also need to be set up (e.g. in MSMQ) before they can be used. Luckily the exception handling in MassTransit is pretty good and will let you know that and endpoint is not set up if it is required, just be sure to read the queue name correctly. I spent a about 15 minutes trying to figure out why a sample subscription was failing when the exception was saying I had  not set up “mt_server1”. I thought it was saying “mt_server”. If in doubt read the exception! We will cover how the castle config is tied up in the Host And End points post.

End points  and their configuration may be a bit tricky for new comers, but if you break each piece down it becomes more manageable.

[Intro]

So we feel we have something that the world needs to know about, we have messages to publish. This is what kicks off the events that make up the Pub/Sub system. The IT division have told you they are sick of modifying the HR application to call a growing number of web service to let those services know about  new or updated employee information. You decide this may be a good candidate for some Pub/Sub love. We will start with New Employees, firstly we would need to create a suitable message to publish, say “NewEmployeeNotificationMessage”. This has all the relevant info in the message. As part of the creation process all we need to do is create a message of the given type and publish it.

var message = CreateNewEmployeeMessage();
_serviceBus.Publish(message);

That is it. Well…. its not, but as far as the publishing code goes that all there is too it, there is a little bit of infrastructure set up that goes on at start up, but to publish a message is really that simple.

There are times where you may want to know of a response if a subscriber sends one, this can be done by setting a response address in a delegate as part of the publish eg:

_bus.Publish(message, x=> x.SetResponseAddress(_bus.Endpoint.Uri));

If a response is expected then the service publishing the message should also be a consumer of the response message type, see the consumers post

The bus is a MassTransit.IServiceBus that is injected in to the service. We will cover setting up the bus later on in the series.

*this may be a bit over the top example. If you a re building enterprise wide service and integrating system perhaps MT is a little too light weight, judge for yourself. Personally I am angling at using for intra component messaging.

[Intro]

A messaging system does make a lot of sense if no one or nothing is listening, consuming or subscribing to those sent messages. If you are interested in a particular event that a message represents then you subscribe to that event.

Continuing on with the idea of a new employee at a company, lets assume that head office have decided that all staff members must do a new online intranet based safety course and any new employees must do the safety course as part of the induction. We can create this online application, send out the notifications to all existing staff, but how do we ensure all new staff do the course? well we know that HR publish a New Employee Notification when an employee joins the company so we decide to subscribe to the message so our application notifies the new employee and his supervisor that this course must be completed as part of their induction.

Ok, so how do we do this in MassTransit?

Well one option is to create a consumer, a service that subscribes to the message and acts on it when it happens.

public class NewEmployeeService : Consumes.All
{
    private IServiceBus _serviceBus;
    private UnsubscribeAction _unsubscribeToken;
    public void Consume(NewEmployeeNotificationMessage message)
    {
        //Notify user and supervisor of course requirement
    }
    public void Dispose()
    {
        _serviceBus.Dispose();
    }
    public void Start(IServiceBus bus)
    {
        _serviceBus = bus;
        _unsubscribeToken = _serviceBus.Subscribe(this);
    }
    public void Stop()
    {
        _unsubscribeToken();
    }        
}

A couple of things to note here:

The NewEmployeeService implements the “Consumes.All” interface. This means we are subscribing to any message published of type T, in this case NewEmployeeNotificationMessage. By doing so we must implement Consume(T message), this is the method that will be called when the message arrives.  Start and stop are methods we have defined that get call when the host starts up the hosting service (we will cover this is later posts). More importantly and something that may not be obvious is the unsubscribeToken. When subscribing to the bus the subscribe method returns an UnsubscribeAction delegate that can be called when the subscription is no longer required. Therefore calling this delegate on the stopping of the service would be a good idea 🙂

A service can subscribe to many  messages by specifying and implementing more of the consume interfaces, as it is not a base class you are not limited to a single inheritance. So you may want to define the class as :

public class NewEmployeeService : 
    Consumes.All,
    Consumes.All
{
    //...etc

It is also worth while to note that the message can be responded to:

CurrentMessage.Respond(responseMessage);

This will send the message back to the response address specified by the client, see the Starbucks example: CashierSaga.ProcessNewOrder(..) and OrderDrinkForm. NB: The OrderDrinkForm also implements the consume interface for the response message, otherwise it will not know what to do with the message