David Boike's Blog

All About NServiceBus Host Profiles and Roles

Posted by David Boike on February 8, 2013 None comments

The NServiceBus Host process is a pretty amazing piece of software that hosts your message handlers, can be run from the command line or installed as a Windows service, and is supremely extensible. This is a great strength for NServiceBus but it can also be a little overwhelming for the developer just starting to wade into the great pool of service bus logistics.

Much of how an endpoint will configure itself is based on Profiles and Roles:

Profile – controls the environment and features the endpoint is supposed to run with. These are set at the command line by passing the class name (or names) of the desired profile (or profiles) like “NServiceBus.Host.exe NServiceBus.Integration”. Because this is set at run-time, this allows the same collection of code to run in different configurations depending on environment.
Role – controls what services the endpoint will need based on how it will interact with other services. There are 3 defined roles: AsA_Client, AsA_Server, and AsA_Publisher, and these are set in code, so these are static for an endpoint.

In this blog post I will try to spell out everything that these profiles and roles do, based on my experience and source code snooping with Reflector. Use this as a quick reference so you don’t have to go hunting through reflected source yourself.

Note that all of this information is based on NServiceBus 3.3.4. I’m positive that things will change as new versions are released.

Misbehaving Web.config transforms

Posted by David Boike on February 7, 2013 None comments

Visual Studio 2010 added the ability to add transform files to web.config files so that you could have one combination of settings during development, and then another set when deploying to different environments with the Publish Website tool.

This is immensely powerful, allowing obvious things such as turning off debug mode for production builds, and changing database connection strings, but also more subtle ones like ensuring that QA people banging against new code don’t unknowingly send a bunch of test emails to people who will not be interested in non-production data.

This means that there is really ZERO excuse for saying something like "So how you deploy this app is you build it locally and then you copy over everything except the Web.config file." No, that is not OK. That will definitely result in a bad build at some point in the future. But unfortunately, I worked on a project where I heard exactly that sentence.

RavenDB vs RDBMS: Searching

Posted by David Boike on February 6, 2013 None comments

This entry is part 5 of 5 in the series Raven vs. RDBMS

Recently Charlie Barker (@Porkstone on Twitter) asked me what I felt were pros and cons of using RavenDB over a standard relational database. In this series of posts I highlight the differences between RavenDB and a RDBMS that I have experienced after completing three projects that incorporate Raven in some capacity.

Originally I wrote this series as 4 posts, after which my boss read the series and asked me a bunch of pointed and very interesting questions. These made me realize I forgot this very important advantage that Raven has over pretty much any relational database out there – searching!

Why did I forget about it? Because I was approaching the blog series from the perspective of things both Raven and a relational database do, and how they did them. But relational databases really don’t do searching, at least, not with the same level of basic competence that they store data. My last experience was with Microsoft SQL Server Full Text Search and it wasn’t fun. If you’ve tried, you probably know what I’m talking about. If not, you don’t have to take my word for it – take it from these guys instead.

Because of these problems, most people who need to do some sort of search turn to a search index product, such as Lucene and SOLR. I’ve developed search solutions with SOLR myself. It’s a Java service you run in Tomcat that provides search services via a REST API, and it can be harder to set up than it sounds, unless you’re proficient in DisMax index tuning. I was not. We were eventually forced to bring in a SOLR consultant in order to get the sort of relevance matching in our search results that our business stakeholders expected. It turns out that Google is your enemy here – they make searching look too easy and then your users start to assume that it actually is.

RavenDB vs RDBMS: Polymorphism

Posted by David Boike on January 24, 2013 None comments

This entry is part 4 of 5 in the series Raven vs. RDBMS

SQL Server is generally poor at doing any sort of polymorphism because normalized rows and columns are just not really good at representing that.

Here’s just a small sampling of (all bad, in my opinion) ways I can think of to handle polymorphism in SQL Server:
Read more »

RavenDB vs RDBMS: Duplication

Posted by David Boike on January 23, 2013 None comments

This entry is part 3 of 5 in the series Raven vs. RDBMS

Once I was asked how difficult it would be to duplicate a nontrivial data structure that was stored in SQL Server. I shuddered, knowing that this particular data structure included hierarchical data represented as rows where children pointed to the ID of their parent, and all those parent-child relationships in the duplicated data would need to be preserved.

Luckily in that case, some careful application of the 5 Whys technique made actual duplication unnecessary, and that’s a good thing, because it would have proven to be nearly impossible.

With RavenDB, however, it’s trivial to take a document and save its contents with a different ID, or to take a chunk of one document and include it within another. The hierarchical data would, for instance, be stored in Raven as nested lists, or in other words exactly how you’d represent it in code. In Raven it just works, and there are no ParentIds to maintain, so you can easily duplicate the entire structure. Read more »

RavenDB vs. RDBMS: Data Aggregation

Posted by David Boike on January 21, 2013 None comments

This entry is part 2 of 5 in the series Raven vs. RDBMS

The power of Map Reduce is phenomenal. I think the analogy that Ayende used at the RavenDB training I attended was the most apt.

Imagine you were trying to count up all the people in a skyscraper. How would you go about it? If you were SQL Server, you would send someone to every single room counting each person in turn. It would take forever, and then you’d throw that information away, so that the next person who wanted to know how many people were in the building would require the same effort of running floor to floor counting every single person.

RavenDB vs. RDBMS: Quick Data Storage

Posted by David Boike on January 17, 2013 2 comments

This entry is part 1 of 5 in the series Raven vs. RDBMS

RavenDB was built for quick data storage. It promises zero-friction data storage and it definitely delivers. SQL Server, on the other hand, promises that you’re probably going to need some form of object-relational mapping software.

One of the projects in which I used Raven began its life backed by SQL Server 2008. The problem was that it was always my lowest priority, getting just a few hours of attention each week before some bigger fish raised its head and had to be fried. In that short time each week in which I worked on the SQL version of the project, usually I would spend my time banging my head against SQL Server trying to just deal with the data access. There was very little forward progress on the actual business logic of the application.

Two subtle but powerful client-side UI tricks

Posted by David Boike on December 18, 2012 None comments

I thought I would two little tricks that are recent favorites of mine.

I’ve been doing a lot of client-side development with Backbone.js, Twitter Bootstrap, and LESS. Together they are powerful tools for creating a lot of beautiful client-side UI with complex interactions.

The two tricks I want to share are a CSS3 fade-in, and Trello-inspired drag-n-drop LESS mix-in.

jQuery.postJSON() method for ASP.NET MVC

Posted by David Boike on November 7, 2012 None comments

Part of the reason I blog is that it serves as a healthy reminder for me of the best ways I’ve found to do things. The Internet is full of information that’s just plain wrong, or only wrong in certain scenarios that don’t always match mine.

So when I have to grapple with the exact same stupid problem for the second time, it’s obviously time to record it, if only for the sanity of Future Me.

Today’s example is posting JSON to an ASP.NET MVC action method. There are a bunch of examples all over the Internet that will tell you to do this:

// THIS IS WRONG!
// Well.....at least for MVC.
$.post('/some/url', data, function(response) {
    // Do something with the request
}, 'json');

This is all well and good and does cause jQuery to submit data encoded as JSON instead of URL-encoded, the problem comes in on the MVC side. This request results in this offending header:

Content-Type: json; charset=UTF-8

Um, that’s not right! “json” is not a valid MIME type! Because of this, even though the payload is JSON, MVC will not deserialize it properly and so any of your action method parameters will be null. Even worse, if you have a non-nullable parameter (an int, for example) then you will get an exception from the model binder.

So this snippet creates the simple postJSON method that jQuery on its own is missing, nicely wrapped within a closure so that it can operate in jQuery’s noConflict mode:

(function ($) {

	$.postJSON = function (url, data) {

		var o = {
			url: url,
			type: "POST",
			dataType: "json",
			contentType: 'application/json; charset=utf-8'
		};

		if (data !== undefined) {
			o.data = JSON.stringify(data);
		}

		return $.ajax(o);
	};

} (jQuery));

This will correctly set the Content-Type header so that MVC can understand it. The function returns a jqXHR object that implements the Promise interface so that you can chain your event handlers on to the end like this:

$.postJSON('/post/url', {param1: "hello", param2: "world"})

	.complete(function () {
		// Optional - fires when the operation completes, regardless of status
	})
	
	.success(function () {
		// Optional - fires when operation completes successfully
	})
	
	.error(function () {
		// Optional - fires when operation completes with error
	});

Enjoy, Future Me!

NServiceBus at Twin Cities Code Camp 13

Posted by David Boike on October 6, 2012 4 comments

Today I had a great time presenting Enterprise Service Bus Development with NServiceBus at the Fall 2012 Twin Cities Code Camp. I wasn’t sure before presenting if we would have enough time to get into sagas, and as it turned out, we ran out of time right in the middle!

So as promised, I finished the saga code and pushed it all to GitHub. Here is the link to my Twin Cities Code Camp 13 NServiceBus Example Code. Please feel free to clone it and explore!