Unity in DevDash

February 21, 2012

I got a comment asking if I’ve used Unity. Oh yes. I do.

IServiceLocator, which is an abstraction of IOC so that you can use any container you want with a common interface, is the heart of DevDash. Each node, and the hub, is an instance of an application server. The application server is populated by unity. Unity may provide to the app server startup tasks, shutdown tasks, scheduled tasks, services, and the event-driven bus. If you want to add any functionality to DevDash, you can do so by implementing a task or a service and plugging it in to the container.

It provides two standard configurations: StandardNode and StandardHub. Each requires a different set of required settings for basic configuration information, but the unity containers are wired up and ready to go automatically. If you want to tweak it, you can do so in initialization code, or you can change it to use the configuration file rather than code. There is a lot of configuration, so I will provide the StandardNode and StandardHub configuraton as well.

Here is the configuration section:


If you are driving from configuration 100%, then you need to specify the MODE attribute. That tells it whether to start the standard node, standard hub, or whatever is specified in the unity container called “whatever”.

If you do it via code:

host = Host.CreateStandardHub();

host = Host.CreateStandardNode();

Then it ignores the MODE attribute and just goes to the appropriate section.

I will also reveal the methods that construct the container… just have to juggle a little bit of code. Then, you can get the standard hub or node as a container, modify it or add to it, then pass it to the host when you’re ready to go.

So, you have options. You can either use it out of the box, you can start from scratch, or anything in between.

The windows service that hosts the hub and node is based on the configuration section and the MODE attribute. If you want to change the container, then you’ll have to switch the mode to UNITY and modify the xml.

Here is the unity populate code that fires up the hub and node:



You may notice a couple extension methods in there. I plan to add more to simplify the process of populating the container via code. You’ll see that I started at the top of the registration list, then quickly got bored.

Also, the Wcf services are constructed by unity. There is a custom service host (per an earlier blog post) that swaps out the Wcf instance provider with an IServiceLocator aware instance provider. The IServiceLocator is stored as a property of a subclass of the service host.


DevDash–Update and Diagrams

February 21, 2012

Anyone who knows me, or reads my blog, knows that I start a lot of projects and never finish them. Usually, I take them far enough to prove that I can do what I wanted to do. Then I get bored and moved on to something else. I’ve been doing that for 15 years. While all of the projects have potential to be good, I am but one person, and there are aspects to projects that I just don’t care to do. For instance, GUIs. They kill me. I can spend hours working on some stupid thing to get it to look and behave the best I can; but it’s still crap when I’m done.

Dev Dash is no different. I’ve probably been working on this for 8 months off and on (that’s just a guess though). I’ve put it down a couple times so that I could come back recharged. But, unlike other things, I have always come back to it.

Early on, I was trying to keep it simple. I figured the simpler I kept it the more likely I would be to finish it. But, I over-did it. It was too simple. After stepping away for a couple weeks, I came back and gutted it. I kept a good portion of the objects, but had to completely reverse the architecture. Instead of the hub keeping track of the nodes, the nodes update the hub.

Also, I spent a lot of time in MVC. I started by hosting the hub services in the MVC client application. That worked fine, but I ended up with these obnoxious base classes. When I did it, I settled for them, but then later couldn’t tolerate it anymore. I could’ve resolved it a different way, but instead, I removed the services from the MVC app altogether.

For months I’ve been saying that I’m almost done. And I am. I’ve never liked or been wrong about that. But it’s a moving target. I keep thinking certain things can wait until later, but then I end up doing them anyway. I’ve ended up doing big things I wasn’t planning on doing now. (There are 500 other big things I would like to do, but I think I actually can wait on most of those).

At long last, I am closing in on being “done”. In this case, “done” means that I will demo it, and we can use it how I want to use it. But, there will always be a million more things to add, and a million things in there already that I want to do better.

The architecture is good. The implementation is good, with a few ethical shortcuts. The website is weak but functional, particularly the admin screens. The admin screens work, but I wouldn’t try to break them because I know I would succeed. They’re minimal. I’m making many things that are functional rather than a few things that are completely done. That way we can use it faster.

There are a few things left

  • Edit Commands. Being able to execute remote commands is a key feature, but it’s useless if you can’t add and edit them. I will take the same shortcut on this page that I took with the deployments: it will allow you to edit the relevant xml element rather than provide a gui that ultimately builds the xml for you. Sure, the gui would be immeasurably better, but I can it working much faster with a direct edit.
  • Save setup changes. DevDash is based on a configuration hierarchy. Right now, that hierarchy can be edited, but it’s not persisted. Not persisting it makes it easier for me to reset; just restart the hub and the changes are gone. Clearly, that’s not a feature real users would appreciate.
  • Bug in a plug in – DevDash consists of widgets that you plug into it. The widgets do whatever you want it to do; you wrote it, after all. One of my widgets revealed what I think to be a problem in one of our services. Under some condition, a TextWriter issue is introduced. That’s not a DevDash problem, but I need to solve it anyway so that the widget works.
  • Node Variables – The node variables seem to be getting deleted. I have to look at that.

This is the diagram I use to keep track of all of the objects per container.

  • image

This is how the stupid bus is used.


The main page, with some custom plug-ins


The admin menu


The installer page. If you have the proper access to a remote machine, it will install a node on that machine automatically.


The contents of the WS-DISCOVERY server.


The NodeStatus dialog – not too exciting with just entry.


Edit A Deployment


Execute a Deployment



Sample Command Execution. This is just a dumb example, but you can write a command to do whatever you want. (It’s just a windows batch file, essentially. Write it, the service will substitute node specific variables as necessary, then execute it. One anticipated use of this is to build installer for us.)


In conclusion: this is the closest I’ve come to finishing something. Almost there…

What I Read Today–PRISM

February 21, 2012

In DevDash, I have a minimal event object called ILocalBus. It’s an easy way for unconnected objects to stay in touch. Anything can publish an event, and anything else can consume it. The messages are distributed to the subscribers asynchronously.

Today, someone showed a similar piece of code using object provided by PRISM. So, tonight’s topic was PRISM.

I did a search for Microsoft Prism, and I got a few links that were already visited. I did some reading on Prism earlier, and forgot about it. Why? Well, as soon as you click a link, you learn that it’s for WPF and Silverilght developmernt. Yea… I don’t do WPF or Silverlight development. Anything involving a visual component isn’t in my areas of interest or expertise. But, I read it anyway.


I wasn’t going to read all of this: http://msdn.microsoft.com/en-us/library/gg430865(PandP.40).aspx

But, I jumped to the section that I saw in code:


The section of interest is EVENT AGGREGATION.

Clearly, this thing is for WPF and Silverlight. It says it very frequently, but perhaps this one component is worthwhile outside of the gui. Even the event is called CompositePresentationEvent… not appealing, but it might work.

One interesting parameter is the ThreadOption when subscribing.

  • Publisher Thread – The default setting. So, the subscribers will block the publisher.
  • UI Thread – n/a for how I would want to use it.
  • Background Thread – that’s the ticket.

As I’ve mentioned before, my event bus is ILocalBus, and the implementation of it is StupidBus. I called it that to make sure it’s never accidentally over glorified. Yes, it’s really cool and really simple. It lets objects that know not of each other’s existence communicate with one another. But, in the end, it’s done with simple .net constructs. I see how I would like it to evolve, but chances are there’s already an object out there ready to go. Maybe the Prism EventAggregator is that class.

What I Read Yesterday–SignalR

February 17, 2012

When WebSockets make their debug for .NET (Windows 8 and .NET 4.5), you will be able to persist a channel between the browser and the webserver, and the webserver will be able to feed the page live updates, etc.

In the meantime, if you want to update the page, the out-of-the-box way to do it is through polling. In DevDash, the status page checks the server every several seconds for the latest node statuses.

SignalR provides a better way to do this (as do other products that the SignalR links refer to). It achieves live updates by LONG POLLING. The page basically makes a request for a resource on the web server, and that resource blocks until there is something to respond with. As soon as there is something to respond with, the page receives the data and can update automatically.

On the server, you can indicate which javascript method to call on the page.

I don’t have any hands on experience with this, but it reads great. There are several places in DevDash where I can use this.

It works in other client scenarios too, although the Javascript client is the one I’m most interested in at the moment.

It also has built in support for WebSockets if the browser and server supports it. That will allow you to use the same SignalR api via the websocket rather than via long polling.



What I read (and watched) today: Reactive Extensions

February 16, 2012

Reactive extensions have been around for a while now. They exist for .NET languages and, cleverly, in javascript. The idea is that instead of looking for things, things are pushed to you. We talk about this approach in work pretty regularly. It’s the utopian dream of event driven processes. When something happens, you just announce it, and whoever cares will consume it.

Reactive Extensions are in that ballpark. It’s based on observable collections. It let’s you write event handlers in LINQ.

I read a bunch of stuff on it, and watched some videos. So, not quite an expert. I’m going to keep going with this for at least another day. I’m about 1/2 way through the last video.

I’m particularly interested in this topic because of DevDash. It has a bus so rudimentary that I call it “Stupid Bus”. All it is is a class to which you can initiate and consume events. For example: when a node changes, the thing that changes the node says “I changed node X!”. That message is forwarded to anything that subscribed to the NODE UPDATED event. There is a second event to handle process restarts. After the node syncs, the sync task publishes a process restart request. The host catches that event and initiates the appropriate restart mechanism for that host.

NOTE: now that I wrote that, I see an inconsistency. I should be publishing WHAT HAPPENED, not WHAT YOU NEED to do. Instead of saying “Restart the Process”, it needs to say “Synchronization Complete”. Then the subscriber for “Synchronization Complete” may choose to restart. I will correct that.

Anyway, back to my original point: The stupid bus is a potential candidate to be made cooler by Reactive Extensions. I’m going to have to continue to delve into it.


I’m about 1/2 way through the last video.

What I Read Today: .NET Security

February 15, 2012

I’ve had a couple links on my browser bar for a few weeks that I never got to read. So, I read them, read some things they linked to, then GOOGLE’d for some additional details about evidence.


What I Read Today

February 13, 2012

I spend a lot of time programming, both at work and at home (which also happens to be where I work). I’m also married and have 2 kids. And I occasionally require food and sleep. That adds up to a lot of time.

One thing I don’t do as often as I would like is read new things. I blast through a programming book once in a while, and I skim lots of blogs, but I’m not often able to sit down and learn something new just for the sake of learning it.

I’m going to try working on that by programming less. I made a self-commitment to write a book this year, so I have to code less anyway. I’m trying very hard to get DevDash out the door, but I keep adding more stuff to it. That’s the last major initiative I plan to work on on my own for the short term.

I am going to try to take a small part of each day to read up on something or do something with a new technology. Today is the first day of that initiative, and I was successful.

I subscribe to the Elegant Code blog. They’ve been posting little blurbs about various things available via NUGET. DISRUPTOR-NET caught my attention. Instead of just raising one eyebrow quizzically and moving on, I stopped and read it. I opened the github page and read the PDF. Every last dang word.


It’s fascinating. I deal with queue and threading issues quite often, but extreme low latency isn’t usually one of our highest goals. The normal operating speeds of things is fine.

This thing is all about the speed. The PDF is a great read. I’m going to try to play with the .NET version of it.