Dru Sellers

dropkick - an idea for deployments

drusellers — Fri, 29 May 2009 12:01:46 GMT

Still very rough, but I have the DSL compiling and looking at making file copy work. This is more than anything an exercise in building a framework that uses the same structure as the MassTransit Sagas.

    public class TestDeployment :
        Deployment<TestDeployment>
    {
        public static Part Web { get; set; }
        public static Part Db { get; set; }
        public static Part Service { get; set; }

        //dropkick r:role(web,db,service | full)
        static TestDeployment()
        {
            Define(() =>
                {
                    During(Web, (p) =>
                        {
                            p.OnServer("WebServer")
                                .IisSite("Apps")
                                .VirtualDirectory("dashboard")
                                .Verify()
                                .CreateIfItDoesntExist();

                            p.OnServer("SrvTopeka19")
                                .Msmq()
                                .PrivateQueueNamed("mt_subscriptions")
                                .CreateIfItDoesntExist();

                            p.CopyFrom(@".\code_drop\dashboard\**\*.*").To(@"\\webserver\apps\dashboard\")
                                .And((f) =>
                                    {
                                        f.WebConfig
                                            .ReplaceIdentityTokensWithPrompt()
                                            .EncryptIdentity();
                                    });
                        });

                    During(Db, (p) =>
                        {
                            p.OnServer("sql")
                                .SqlInstance(".")
                                .Database("dashboard")
                                .Verify()
                                .BackupWithLightspeedTo(@"\\sql\\backsups\")
                                .RunTarantinoOn(@".\code_drop\dashboard\sql");
                        });

                    During(Service, (p) =>
                        {
                            p.OnServer("WebServer")
                                .WinService("dashboard service")
                                .Verify()
                                .Do(() =>   //auto-stop
                                    {
                                        p.CopyFrom(@".\code_drop\dashboard").To(@"\\webserver\apps\dashboard-service")
                                            .And((f) =>
                                                {
                                                    f.AppConfig
                                                        .ReplaceIdentityTokensWithPrompt()
                                                        .EncryptIdentity();
                                                });
                                    });        //auto-start
                        });

                });
        }
    }

Why messaging #5 - Bus vs Broker

drusellers — Fri, 29 May 2009 11:53:38 GMT

I have in the past gotten in a tizzy about message brokers and message busses. I pretty much say, busses rule and brokers drool. This stems from the fact that I view them as filling the same role, the intermediary between applications. Because of this view point, I see the broker as being a central point of failure and I see the bus as being a distributed equivalent, that overcomes much of the problems of centralization. I often dismiss the simplicity of centralization in this area from an academic snobbery vibe, which is just not the right way to go about it. So I decided to do something about it.

It was while rereading EIP for this series I realized that the authors actually classified the two patterns into two different categories (they do not fill the same role!). The bus is a channel for message sending and the broker is a message routing mechanism (well crap, I have to abandon my old assumptions). With this realization, what does that mean for my previous assumptions?

So, just how does the EIP define these two patterns?

Message Broker - a means to decouple the destination of a message from the sender and maintain central control over the flow of messages (inside cover of EIP).

Message Bus - enables separate application to work together but in a decoupled fashion such that applications can be easily added or removed without affecting others. (inside cover of EIP).

Well, hmmmm? Could it be that its possible for a software package to be both? It seems like it. Lets review. While working on MassTransit I feel that I have successfully accomplished the message bus pattern, but the broker pattern? Decouple the destination of a message from the sender and maintain central control over the flow. Well we have decoupled the sender from the receiver by following the publish / subscribe model, but the central control of flow? Well no, but do I want that? ... Centralization == single point of failure. hmmmm.... "the message broker pattern only tells us to develop a single entity that performs routing. It does not prescribe how many instances of this entity we deploy in a system at deployment time." (EIP, pg 324) So does mean that the MassTransit SubscriptionService and Client are a broker pattern built for a more distributed system? It certainly seems possible. The Subscription Service lets you control in one point where messages go (the flow). Ok, well slap my biscuits looks like I am a fan of the broker model. That's what I get for basing my snobbery on a one time read. ;)

-d

Why Messaging #4 - So hows it going?

drusellers — Thu, 14 May 2009 14:40:27 GMT

Its been over a year since I went down the messaging path and how has it been? What have a learned? What has sucked? The following are some thoughts on my experiences with deploying MassTransit

Although explaining the benefits of a messaging based system has been easy, trying to apply some of the new paradigms that Udi and Greg Young have been trying to pound into my skull has not been so easy. This includes a slew of things like message idempotence, worrying about message timeout (and elevating its importance in the whole system), what to do when a message doesn't get where its supposed to go, figuring out how to rerun a messaging system, and others has been a bit of a mind warp. And figuring out how to test a messaging system...that took a while too. My team has pushed pretty hard in these areas and although it took a little while I think we are starting to see the seeds of our effort. I guess the take away here is that its just going to take time

I know that I am still in the early stages of use for this pattern / style of development and further more as a developer of the framework I can get a bit excited about using it, but at times I think I am treating the tool a bit like a 'hammer and that everything is a nail' but its hard to know when it makes sense and when it doesn't. My hope is that I continue to experience more and more use, that I can find that line sooner rather than later. Its like, oh that could be a useful event that the accounting system is closed. Then we build it up as an event and broadcast the account totals out to our systems that are interested. Right now we have just one system and my coworkers and I kinda stand back and say "Really?" that could have just been a file transfer. I know though as soon as we get that second system we will be very happy.

Another thing that seems to be happening is that I am writing an awful lot of windows services. One to broadcast the message and one to receive the message. Not really sure if this is good or bad or anything, but it did allow me to sit back and create Topshelf an OSS library for writing windows services (imagine that), and from what I have heard it seems to be working out quite well for people. But its something that is new to me, and I just don't have the experience writing that kind of code. But it seems to be going well, it just adds a lot of stuff that I am not used to watching. Thankfully log4net is quickly becoming a very near and dear friend.

As I imagine writing all of these services, so that I can integrate all of my organization I am also starting to wonder about how in the heck I am going to manage this multitude of services. Documentation will help alot, but I am lazy and don't want to write documentation. So how can I expose information about our systems with out having to keep it in sync with the word docs? This is where I have started to look into the concept of metadata. Basically, i want an MT service to tell me something about itself. Where is it installed, how many messages is it handling per minute, error count, etc. I feel that if I can get this baked into MT and exposed to us in some sort of dashboard, managing this beast will get a lot easier.

Well, I hope this was helpful. I will try to write another one when it seems to make sense.

-d

Why Messaging #3 - What did I read?

drusellers — Sat, 02 May 2009 16:03:00 GMT

I just finished presenting at the Iowa Code Camp and one of the little change ups that I did in this presentation was talk about the various books that I have read. So, if you have decided to pursue messaging as an architectural style to use, here are some reads for your next steps. These sources are also usually going to be the source of information for the following posts. Please leave additional resources you like in the comments. :)

-d

Books

People

Udi Dahan
- His Best Hits
- There is no IDog2
Arnon
- Blog
Ayende
- on Rhino.ServiceBus
- on Rhino.DHT

Why Messaging #2 - What is a message

drusellers — Fri, 01 May 2009 03:07:11 GMT

So what is a message?

A message is an atomic unit of work. It should contain all of the data needed for the receiver to do its job. Ok, well that's great but what is it? Its really pretty simple:

XML

<order>
	<item no="22" />
	<name>billy</name>
<order>

or JSON

{ order: { no:22; name:"billy"; } }

or Binary

10111000110100111011100010101001101101101

It is state that is defined much in the same way a feed file would be prepared, and it has the intent of being sent to another party. Not including key values (database keys) (thereby assuming the source system can just look up the values associated) is also an important point. With messaging, unlike text files, it tends to be one item per message because one of the goals again of the message over file transfer is speed of delivery. Rather than wait for a bunch to accumulate you send them when the occur. Of course, as Udi would tell me, it all depends on the actual system need. :)

And that is how I think of a message.

-d

Why Messaging #1 - Intro

drusellers — Tue, 28 Apr 2009 02:36:00 GMT

So, why messaging?

For me it started when I was tasked with integrating several systems at my current employer. Our goal was to build a data warehousing solution that would take the stress of historical analysis off of our transactional systems. With that goal in mind I set about asking several of my friends how I should go about doing this. The overwhelming response at the time was to read Enterprise Integration Patterns (EIP), and it was there that I discovered messaging as a solution to my problems.

So, again, why messaging? Well I had some goals: integration of bank systems, provide a means that would not turn the overall system into what Arnon calls a Knot (actually so does EIP pg 52), and it should be easy to use. Ophhhhhda! It is my hope that this series of posts will help you to understand the use of messaging and whether its a fit for you or not.

To begin with lets summarize the four basic types of integration according to EIP: file transfer, shared databases, remote procedure invocation, and messaging.

First we have file transfers, the worlds workhorse of integration. We write some data out to a file and then put it someplace the other application can get to. Everything can read them and everything can write them. This makes them simple and effective. However as you environment gets more complex you can start to run into issues around enforcing data standards, when to produce them, archiving them, which applications need them? Thankfully though .Net at least makes it easy to read/write XML (well sort of) and we have the wonderful FileHelpers project for other formats.

Second, we have the good ol' shared database. Its faster than File Transfers, and it has schema around the data that helps to conform the data. The updates are instant versus the File Transfers batch orientation which is a plus as well. Another boon, like file transfers is that they are pretty simple as well and your application is probably already using SQL anyways. Of course we start to get issues as applications abuse the schema (multiple applications want to use the schema in different ways), or start to put load on the database itself (maybe on a contentious table). But I think the biggest thing is that we have broken encapsulation at a pretty low level. Application A now knows about the internal state of Application B. I think my feelings about this though are best summerized by Jeremy Miller.

I mean, it's like drug addicts sharing needles. It's the most insidious form of coupling you can possibly come up with

Third, we have remote procedure invocation. This includes things like REST, WS-*, .Net Remoting, WCF and more. This method allows us to share behavior and state something don't have with files and databases, it better encapsulates the data and for most programmers is easy to grok. The key issue for me though is that the network isn't reliable. It also opens us up to Arnon's Knot mentioned earlier. Think of a system where you have a web service calling a web services calling a .... and you will get the picture. So how can we share some state, and some behavior with out getting all tangled up?

Enter messaging. Its data format is really as simple as the file transfer, in fact EIP refers to it as like micro file transfers, with the behavior aspect of RPI but you gain the offline async nature of the messaging systems. Both systems don't have to be up (like file transfers or shored database), there are ways to intercept and transform messages that you don't get with RPI (but you can with File Transfers), and most importantly it starts to make you think about non-optimal scenarios. So this is great and all but what am I sacrificing? You lose the call stack, debugging across multiple services / machines is a pain (welcome back to the world of logging), and well, it warps your brain...

This concludes my very short, very contrived overview of the integration options.

Next time, we will discuss what a message is.

-d

MassTransit Routing

drusellers — Sat, 18 Apr 2009 23:27:00 GMT

From time to time, I get requests for routing in MassTransit. We want to identify and configure, at design time, where a given message is going to be sent. "I want all BuyWidget messages to go to msmq://localhost/widget_buyer". While this really isn't the way that I like to think about things from a SOA / EDA perspective, I felt this was a valid feature request and decided to go ahead and add it today. This is what it looks like.

IServiceBus bus = ServiceBusConfigurator.New(b =>
{
  b.ReceiveFrom("msmq://localhost/mt_client");
  b.ConfigureService<RoutingConfigurator>(rs =>
  {
    rs.Route<BuyWidget>().To("msmq://localhost/widget_buyer");
  });
});

You should now be able to use the pub/sub semantic without actually having the subscription service installed and running. If you find you need to configure the routing more dynamically, like if you start thinking about driving this process from a database, I would recommend you take another look at the subscription service.

Currently you can only do this in code, but it should be easy enough to extend into some xml config if you are so inclined. This the first pass at this functionality so let me know what you think.

-d

What's the difference between a message and an event

drusellers — Tue, 31 Mar 2009 02:26:09 GMT

MassTransit has hit 0.6 RC1

On the Elegant Code Cast, I was asked what the difference was between a message and an event, and I really wasn't happy with my answer. Well as luck would have it I recently started reading 'The Power of Events' in which the author gives a very good explanation (Below is a brief summation).

A message is just a structure. This structure could be as simple as the string 'BUY' or 'SELL' or it could be a complex structure like an object graph serialized to JSON. This is the message.

An event adds the components of 'significance' and 'relativity'. Significance in this case is that the 'message' signifies some activity. The event's form (again the message part) should contain data describing the event it signifies. Relativity is that it is related to other activities by time, causality and aggregation. Ok, so that introduces some other concepts. Time is easy, it happened on 12/31/2008. Causality is asking what caused this message. In MassTransit (MT), I am thinking of implementing this by placing the name of the message that is currently active in the message headers if you published any messages. Lastly, we have aggregation, if event A signifies the activity of the set of events B1, B2, B3... then A is an aggregation of the events Bi.

I look forward to finding ways to apply the thoughts and patterns in the book to MT in the near future. As for now though, 0.6 has hit RC status, and we are looking for feedback. So please pull the code down and run the samples. Let me know what you find and/or think.

-d

Whew, pile of productivity this weekend.

drusellers — Mon, 23 Mar 2009 02:54:42 GMT

Well we are getting closer and closer to MassTransit 0.6 release.

Features to look forward to include:

Improved Saga support (now using Magnum StateMachine)
auto consumer for sagas as well
New outbound pipeline increases performance
A concept of BusServices
Now sitting on the Topshelf
- topshelf to get appdomain isolated services (well its there but untested)
- no longer using ServiceLocator.Current
- will soon have a new command line RunAs
Removed the XML configuration for this release to allow the configuration DSL to flurish

Played with git, did my first branch, work, pull (to merge) and push back to origin. I really like the .gitignore file, simple concept, super helpful. I am also enjoying the branch merge stuff, need to try it out with two people on one project but think its going to be good. Also need to hook Beyond Compare up to it.

Started to build a small application 'biblioteca' to see how fubumvc works. I am liking what I see, but its a bit of a pain to set up. Hopefully they will get something to help out in this area, but I am looking forward to using FubuMVC on the project now that I have it up and running.

watched Ze Frank 'bust your cycle' via Tim

dinked with:

FluentNHibernate, i really want to bring some of that convention love to MT
FubuMVC, want to bring some of the policy/convention thoughts to MT
Ninject, watching to see where nate takes his extensibility model.

read http://bradfordcross.blogspot.com/2009/03/dsls-in-trading-domain.html yup. need to be able to evolve in production.

and I got a haircut.

-d

PhatBoyG and me on Elegant Code

drusellers — Fri, 20 Mar 2009 01:27:03 GMT

Just over a week ago, Chris Patterson and I recorded a podcast with Elegant Coders Jarod Ferguson and David Starr. We spent a couple of hours discussing event driven architecture (EDA), messaging, and MassTransit. Through the magic of editing, they managed to end up with a coherent eighty minutes (not sure how that happen as the G and I were wired to the hilt with caffiene).

Check it out on their web site (where you can listen, or subscribe via iTunes/PodCastRSS).

-d

Topshelf Isolated Services

drusellers — Wed, 18 Mar 2009 10:42:12 GMT

As I mentioned in the previous post, I have a need for Topshelf services to run in separate application domains. This is a feature I have wanted for a little while, but had no idea how to do it. Thanks to some help from Oren I now have a first pass at an 'Isolated Service'. You can try them out your self by configuring your service like:

RunnerConfigurator.New(x =>
            {
                x.SetDisplayName("chris");
                x.SetServiceName("chris");
                x.SetDescription("chris's pants");

                x.ConfigureServiceInIsolation(c=>
                      {
                          c.WithName("my_service");
                          c.WhenStarted(s => s.Start());
                          c.WhenStopped(s => s.Stop());
                          c.WhenPaused(s => { });
                          c.WhenContinued(s => { });
                      });
            });

Important Note: the 'WithName' which used to be for display purposes has been repurposed to be the services IoC handle. Since this is a required thing I am thinking I will put it up in the method parameter list for ConfigureServiceInIsolation. I had realized that I was using ServiceLocator.GetInstance() which could make it very hard to get the one specific instance you want so I changed it to ServiceLocator.GetInstance(name) to make it easier. I am not super happy with this at the moment and would love some feedback on it.

This is my first time doing AppDomain programming so any thoughts would be very much appreciated (just search for the word 'Isolated' in the code base).

-d

When is one container (IoC) not enough?

drusellers — Wed, 18 Mar 2009 10:38:22 GMT

Recently, Chris and I have been working on the next release of MassTransit (MT) and in the process of getting everything all nice and shiny we ran smack into an issue that neither of us have really had the chance to think about before. At what point does an application need more than one IoC container?

The situation is this. In order to make the samples easy in MT, we have built the MT Gui which hosts the subscription service, health service, and timeout service in one .Net process and is displayed via a Win Form which communicates with these via its own bus. Until recently this hadn't been an issue as they all communicated over the same address. However, that isn't what we would expect to see in production so we started move each service to its own queue address. One queue per service also means one ServiceBus instance per service, At this point we had four service buses for four services in one .net process space (yikes!). In production these would all run in their own win services, with their own containers. Whereas, this one WinForm app has 4 instances of IServiceBus running around in its container. Well this makes it pretty hard to say give me IServiceBus in the constructor of the various sub-components and get the right instance.

Well crap, what are we going to do? We kinda had it figured out with StructureMap by using its lambda support, but that doesn't work with windsor at all (its also not a good answer). After discussing it some more we started ask ourselves questions like "Do you really want one container per bus?", "Should we embed the container in the bus and then just support the one internal one?", ultimately, we decided that having one container per service bus actually made a lot more sense. The fact that we made it easy on ourselves to cram a bunch of stuff in one service process, didn't excuse that we really needed to be configuring one container per service.

We came up with the following next actions:

1. Topshelf services need to be able to run in their own appdomain (and thread for that matter). This should help me to not be lazy as I will have to have one container per appdomain. After all, why should Service A be able to grab a dependency from Service B? By drawing a harder line it should make it easier to not screw up unintentionally, of course we will keep the old mode available for you scissor runners. ;) -done (rev 29) and ready for review

2. Topshelf services need to use the IServiceLocator instead of the ServiceLocator.Current. The use of static ServiceLocator.Current or ObjectFactory type doohickeys are probably not the best idea when you are trying to cram 8,000 completely different services into one hosted process (which is probably not the best idea either).

3. We hope that most people don't run into this issue. I would think that for most applications you would really only need one (maybe two) instances of IServiceBus, one for the control channel and one for the data channel. To make this a bit easier we now have an interface called IControlBus which you can use if you want your component to talk over the control channel and you would use IServiceBus as you data channel.

Although its been frustrating trying to come to this conclusion, I think that this makes the most sense for this case.

-d

Windows 2008 Symbolic Links

drusellers — Tue, 10 Feb 2009 12:54:29 GMT

While doing some research into Capistrano, I stumbled upon a term I hadn't heard before, symbolic links. After doing some research it looks like this is a "new feature" for windows server 2008 (previously there were junction points, which are like symbolic links, but can only point to directories on the local machine).

I am wanting to use this feature to achieve what they do in capistrano (see Deployment Directory Structure).

[deploy here]/releases/20090210064623/(files here)
[deploy here]/current [symlink to 20090210064623]

With this in place it becomes very easy to install new versions of applications with out destroying the old installation, and if there is an error, in order to rollback all you have to do is change the symlink.

So here is how you make a symbolic link (if you know how to do it in the GUI let me know). Note: You have to be an admin to do this.

mklink /d .\fake .\real
symbolic link created for .\fake <<===>> .\real

Here is what it looks like on the command line with 'dir'

02/09/2009  07:28 PM    <DIR>          real
02/09/2009  07:30 PM    <SYMLINKD>     fake [.\real]

and here is what it looks like in the explorer

There is no rmlink, you just rmdir or use explorer and delete it. I like that quite a bit, makes things simple. Now I just need to add this to either nant or nant-contrib.

-d

Topshelf logo

drusellers — Tue, 10 Feb 2009 03:06:30 GMT

So the last post, I was talking about topshelf a simple framework for hosting windows services. I have had a lot of fun working on it, and I wanted to give it a kick ass logo, well I am now happy to say that the logo for the project is complete.

Pretty sweet, huh?

The man behind the madness is Curt Shontz. Although, he usually draws gnarly hotrods and what not, I think he really captured what I had in my head. A really cool follow up was that Curt actually blogged about creating it! If you want to see more of his work take a trip to his site where has some pretty sweet pics of those hotrods I was talking about earlier.

For those paying attention, yes this is the same gentleman that did the rocking MassTransit logo.

-d

Topshelf

drusellers — Sun, 11 Jan 2009 23:27:58 GMT

So this is my quasi-new project. It is essentially the MassTransit.Host ripped out and in its own project. It is also the embodiment of my lessons learned about building services (daemons) on the windows platform.

Sample Code

var cfg = RunnerConfigurator.New(x =>
    {
       x.SetDisplayName("Timeout Service");
       x.SetServiceName("mt_timeout");
       x.SetDescription("Runs the MassTransit Timeout Service");
           
       x.ConfigureService<TestService>(c=>
           {
               c.WithName("my_service"); //this defaults to type name
               c.WhenStarted(s => s.Start());
               c.WhenStopped(s => s.Stop());
               c.WhenPaused(s => { });
               c.WhenContinued(s => { });
           });
       x.ConfigureService<TestService>(); //defaults (still working on this)

       //By default the service is set to start automatically
       x.DoNotStartAutomatically();

       //several different runas options
       x.RunAs("dru", "pass");
       x.RunAsLocalSystem();
       //x.RunAs(AppConfig("username"), AppConfig("password"));
       x.RunAsFromInteractive();

       //set service dependencies
       x.DependsOn("ServiceName");
       x.DependencyOnMsmq();
       x.DependencyOnMsSql();
   });

Runner.Host(cfg, args)

This code would be in a .Net console application and would be executed like:

timeoutservice.exe            #Runs as a console
timeoutservice.exe /install   #installs the service
timeoutservice.exe /uninstall #uninstalls the service
timeoutservice.exe /gui       #runs the default winform (must be in container)

So, here are some of the things it provides: start/stop individually hosted services; run the service in console, service, or winform hosts; self service installing; delayed container setup for faster install/uninstall; POCO and some things it will provide soon: services start/stop won't effect other services, WMI integration.

I don't see this as a game changing project, more than it is a place to harvest my education, and share with others. So if you write winservice code take a look and see if there is anything you can pass along yourself, if you don't write winservice code but need to this can go a long way to helping that out.

Topshelf requires you to use an IoC container, which has made writing this project so much easier as I can focus on the service aspects and less on the object creation. I am using the Common Service Locator so you can use whatever container you want. I am also directly using the log4net framework at the moment and that is about all that their is for dependencies.

The big win for me is that I can now start my app as a console, test it, and then when happy run it as a service knowing its running in exactly the same way.

The project also provides hooks into some of the more esoteric error events so that we can log the more odd errors.

Its hosted at http://topshelf.googlecode.com/

I also want to take a minute to throw out some props to Chris Patterson my partner in crime and Jeremy Miller for the mad FI skills I keep ripping off from StructureMap.

-d