However, the first time I laid eyes on the RabbitMQ guidance for Distribution, High Availability, and Clustering I started thinking that maybe this wasn’t such a good idea..

Anyway, a few days ago I finally spent a couple of hours together with our Ops guys building a lab environment. Turns out that setting up a RabbitMQ cluster on Windows Server isn’t that hard after all, but we did run into a few gotchas along the way. Thought I’d share the experience with you!

High Level overview of the setup

We decided to use dedicated virtual machines for running the Rabbit cluster. The alternative would have been to run it on the same boxes that run our application services, but somehow it feels better to have it separated. I’m sure you can argue pros and cons here, but I’m going to leave that to someone else.

The RabbitMQ boxes have a load balancer in front so that the application services don’t need to know which physical machine(s) to connect to. The load balancer is currently configured with a simple round robin algorithm and will automatically remove non-responsive machines from the rotation.

Installing

First thing to do is to install Erlang and RabbitMQ. Just get the latest stable versions from erlang.org and rabbitmq.com. By default, RabbitMQ installs its database in the %APPDATA% folder of whoever installs the service, something that seems far from ideal when in a server environment. So before running the installation we made sure to set the %RABBITMQ_BASE% environment variable to a more appropriate location (for us it’s d:\RabbitMQ). Other than that the installation is just a matter of doing the Next->Next->Next->Confirm dance.

Next we want to enable the management web interface. This is done by first enabling the plugin:

rabbitmq-plugins enable rabbitmq_management

Next, the changes has to be properly applied by reinstalling the service:

rabbitmq-service stop
rabbitmq-service install
rabbitmq-service start

You can make sure that the management interface is working by pointing a web browser to http://localhost:15672

Erlang Cookie

The documentation for RabbitMQ mentions that in order to connect a RabbitMQ cluster, all instances must share the same Erlang cookie. The cookie is a simple text file called .erlang.cookie that resides in your user folder (i.e. c:\Users\[UserName]). In order for the RabbitMQ Service to work, the same cookie-file must also be copied to your %WINDIR% (usually c:\Windows). All this is usually handled automatically by the installer and command line tools. However, there is one important gotcha. If you log on to the box with a new account, it will get a new Erlang cookie that doesn’t match the one that the RabbitMQ Service is running which means it won’t be able to administer the service. The easy solution is to copy the one in c:\Windows to the user directory for everyone who may want to use the RabbitMQ command line tools. We are probably going to set this up by pushing a login scripts to all users of the box.

(Windows) Firewall settings

This information is somewhat scattered in the RabbitMQ documentation, so here goes. You need the following things opened up:

Finally, you also need to allow the Erlang runtime (erl.exe) to communicate between the nodes. You can either set a port range yourself in rabbitmq.config (inet_dist_listen_min and inet_dist_listen_max) and open up that range in the firewall, or you can do what we did and allow erl.exe to communicate freely. Note that the Erlang runtime installs two bin folders that both contain erl.exe. The one that seems to be used by the service is in the subdirectory named something like C:\Program Files\erl5.9.3.1\erts-5.9.3.1\bin

Joining a cluster

Creating and/or joining a cluster is actually the easiest bit. You just log on to one of the machines and issue these commands (if joining a cluster on RABBIT01):

rabbitmqctl stop_app
rabbitmqctl join_cluster rabbit@RABBIT01
rabbitmqctl start_app

NOTE that the host name of the server (RABBIT01 in this case) should be in UPPER CASE when working with Windows instances.
We decided to go with only disc nodes. Mostly because it doesn’t seem like using RAM nodes would be much of a performance gain anyway. But I may be completely off here..

Mirroring your queues

When the cluster is up and running, queues and exchanges can be created the same way you usually do. However, the queues will still be localized to a single box, and if that box fails the queue is gone. This is likely not what you want if the reason for clustering was to make things Highly Available.

In previous versions of RabbitMQ, a queue was mirrored by setting the “x-ha-policy” as an attribute when creating the queue. As of version 3.0, you now set the policies either using the management web interface or the command line tool:

rabbitmqctl set_policy ha-all "^ha\." "{""ha-mode"":""all""}"

The above line will create a new policy called “ha-all” (what you call it is not important), it matches all queues with a name starting with “ha.” (using a regular expression) and sets the ha-mode policy to all (which will mirror the queue to all nodes in the cluster).

Profit!

After getting everything up and running we started trying to break things. Mostly everything worked just as expected. When stopping the service on one machine (or completely shutting down the machine), the cluster recovered as expected. It is important to realize that messages that arrived in the cluster while a node is down won’t be mirrored to that node when it comes back up. So in a scenario where you need to restart all machines in a cluster, you should follow a procedure such as this:

1. Restart node 1.
2. Bring node 1 back to the cluster (usually does this automatically)
3. Monitor your queues and wait until all unmirrored messages have been processed.
4. Restart node 2.
5. Etc, etc.

Please let me know if I’ve missed something crucial or if there are things you’d like to know more about!

1. Intro
2. Commands
3. Events
4. Authoritative Events
5. New Views

We finally have a reasonably flexible architecture to play with. We’ve separated our Commands, we’re storing our Events and we’re using them to build our domain model. Let’s see what else we can do, shall we?

What if we would like to show a history of the last 20 changes made to the system on the front page? Prior to our refactoring that would have introduced quite a lot of problems. In fact, if you run the demo system (or come see me the next time I do this talk) you’ll see that we’ve had the service layer and UI ready for it, but since there was no nice way of implementing it, it’s been left as a hard-coded dummy.

Use those Events

But in our new model, this is actually a piece of cake! We just introduce a new Event Handler that subscribes to all events that are considered as “changes we’d like to show on the front page”, and use it to update a HistoryItem table in the database:

Any change from now on will also be passed on to the new view and will show up on the front page. Pretty sweet, isn’t it?

Drop it like it’s hot

Yes. Sweet. But we can do one better.

You know that database of yours? Drop it. Yes. You heard me. DROP it! (But let’s keep the Event Store, ok?)

Remember that we are now Event Sourced? And what is it that you do in an Event Sourced system when your view model changes? You reset it and you replay your events, and that is exactly what we’re going to do too:

And Hey Presto! We have our old database back, now with a complete set of HistoryItems since the day we started logging. Now THAT is sweet..!

Summary

I cannot stress this enough. This is NOT the way you do CQRS on .NET. It is most likely not even a good idea for you to even think about doing this. But, given the right circumstances and a similar set of problems that we faced. Well, I’ve certainly enjoyed it and the system is proving to be fairly flexible.

If you want to hear more, let me know! I’m happy to share and I would be MORE than happy to hear your thoughts on this! Either pop a comment on one of the posts, or engage me on Twitter (@CodingInsomnia as usual).

1. Intro
2. Commands
3. Events
4. Authoritative Events
5. New Views

I left you in the previous post with a bit of a cliff-hanger, didn’t I? So what is the “rather major flaw” in our nice Event publishing system?

Well, the big problem is that it may be hard for us, and for the business, to really trust our Events. Let’s have a quick look back into the code where a Command Handler publishes an event:

What if we made a mistake here? I mean, not that I would ever consider using Copy&Paste for any kind of coding, but.. Let’s say that we accidentally set the Description property in the event to message.Name instead of message.Description. Then imagine this conversation, three years from now:

PM: We have a customer complaining that the hotel she stayed at didn’t have AC even though the description clearly stated that it would. She claims we changed the text the day after she got home.

Me: Yes! We finally get to use our Event Log! I’ll get right on it!

PM: I was hoping you’d say something like that.

Me: Ehh.. Uhm.. Hang on.. Ouch.. What if I told you we never actually saved the Description field…?

PM: You’re FIRED!

What we need is a way to really be able to trust that the data we store in our Event Log contains *all* the data that we may need in the future.

Event Sourcing

Usually, Event Sourcing is used together with DDD to replay state into aggregates. But taking the term literally, it just means that our Events are used as the source for all changes in our system. And that is exactly what we’ll do next.

Instead of letting the Command Handler update the database, all that logic is moved into one or more corresponding Event Handlers. The Command Handler will now validate the Command to make sure it makes sense given the state of the system, then publish an Event:

The Event will be picked up by the Event Handler which will perform any updates:

How you divide your Event Handlers is pretty much up to you. We decided to have one class per Aggregate-thingy (They are not true DDD-style aggregates, but in my mind that’s still how I prefer to think about them..)

Testing

Testing now becomes even cleaner. We can separate the Command Handler tests from the Event Handlers. When testing the Command Handler we make sure that the correct Event is published (if validation is ok):

And testing the Event Handler we just have to make sure that given a specific Event, the correct changes are persisted:

Benefits

A rather simple refactoring that makes ALL the difference. Our Events are now Authoritative. Since we base all changes to the system on them, we can be pretty sure that any change that our users see will also be stored for good in the Event Log.

Well, enough with the architectural changes. Let’s see if we can use this for something cool! Oh.. Right.. That’ll have to wait until the next, and final post of the series.

1. Intro
2. Commands
3. Events
4. Authoritative Events
5. New Views

In my last post, the system was introduced to Commands in order to structure the code a bit and make sure to separate the updates from the reads. Now it’s time to actually bring in some business value!

Remember, the two new requirements we had was to 1) Log all changes, and 2) Pass change information to other systems in near real-time. And what better to handle this than Events?

Our events are simple DTOs, usually mapping more or less exactly to a Command:

Now, usually in a “proper” DDD-ES-CQRS system (D-DDD or whatever you’d like to call it) we would let the domain objects publish these events whenever an interesting action has occurred. Unfortunately, we are not blessed with a nice DDD model, instead we have our Command Handlers that use the very Anemic Domain Model (curtsey of Entity Framework) to push updates to the database. Instead, we’ll simply let the Command Handlers publish events themselves.

Events are published to an event store (which happens to be EventStore in this case). The event store is responsible for, well, storing the events and also sending them off to anyone else who might be interested (represented as Event Handlers in the diagram). For integrating with downstream system, something like a Service Bus would probably be a good thing to put in here.

Testing

Testing with this scenario looks very much the same as testing in the last one, but now we also make sure that the published Events are looking good.

Benefits

Well, we now have our complete log of all changes in the system (the Event Store). We also have a quite extensible mechanism for doing real-time integration (using a Service Bus, EventHandlers etc..)! So, we’re done, right?

Nope. I’m afraid not. Because there is one, quite major, flaw in this system. And that will be the topic for the next post!

1. Intro
2. Commands
3. Events
4. Authoritative Events
5. New Views

This is post #2 in the series. I very much recommend you to read them in order, otherwise I’m pretty sure confusion will arise.. All the code for this step is found on the commands branch:

https://github.com/andlju/hotel-admin/tree/commands

Commands and Command Handlers

Anyway, this is when we actually do something useful. Let’s introduce Commands!

A Command is simply a DTO-type of object that contains the data necessary for the service to make one specific change to the state of the system. As an example, the AddHotelCommand looks like this:

The commands are pushed to a simple Dispatcher who passes them on to an appropriate Command Handler:

No we need to make sure that the old Transaction Script methods are updated to publish commands instead of using repositories themselves. This is when we run into the first issue.

Have a look at the signature of the Remote Façade:

Spot the problem? Yes, it is supposed to return the id of the newly created Hotel, otherwise the UI will be in trouble. But we have already stated that Commands are not allowed to return stuff, so what to do?

Identities

The common answer to that problem when it arises in a CQRS system is to use Guids as identifiers. That way the client (or whoever sends the Command) can be the one creating the identifier and does not have to wait for the server to respond before continuing to work on the object.

We pretty much have two options here. Remodel the database to use Guids instead of auto-incremented Ids, or introduce some kind of mapping between the two. Since we’ve said from the start that the DB should remain as intact as possible, mapping had to be the solution of choice for us.

If you look at the end of the AddHotelCommandHandler above, you’ll see that the last thing that happens is a call to _identityMapper.Map. This will insert the mapping in a simple lookup table. The AddHotel method in the service can now use this map in order to return the Id:

If you’re paying attention, this will be the place where you say something like: “But, but. This means that all Command Handlers must be synchronous. And maybe even inside a.. a.. a Transaction??”. And you’ll be completely correct. But notice how “improved performance/scalability” was never one of the goals for this refactoring. I may revisit this though, so hang tight through the next couple of posts..

Testing

Testing the Commands are pretty similar to testing the old Service. We can put a little bit more thought into the base fixture though, since we know that the “When” will always be a Command, and the “Given” will be a Command Handler:

Benefits

Now I did promise that we would gain at least something in each step, didn’t I? Well, this may be a bit of a long-shot, but at least we have introduced a bit of Single Responsibility/Separation of Concerns to our architecture. The Command Handlers only have to inject the dependencies they actually need (as opposed to the old Service which is likely to become quite bloated). On the other hand, things did get a little more complex by introducing the Dispatcher, not to mention the Identity Map thingy…

You’d better keep reading the next post. Things may make a little bit more sense after that one.

1. Intro
2. Commands
3. Events
4. Authoritative Events
5. New Views

A couple of days ago I held a presentation at DevSum 2012 in Stockholm. The topic was “A Trip to CQRS” and is basically me talking about a project that we’ve been working on for the past year or so. We basically found ourselves refactoring a system from a traditional nTier, CRUD, Entity Framework-solution to something that could be called Event Sourced CQRS (but without the nice DDD-part..) The talk was fairly well-received so I thought I’d take some time to blog about it too.

In this first post I will introduce the sample system and the reasoning behind the refactoring. I have pushed the entire sample system to my github. The code in its “before”-state is in the master branch:

https://github.com/andlju/hotel-admin/tree/master

Based on a true story…

The talk (and this article) will not show the actual system since it’s an internal system in a domain that isn’t really well-known by people outside of our company. Instead, I’ve created a mock system that should be easy enough to grasp quickly, but complex enough to show most of the difficulties we faced. The infrastructure code is more or less exactly the same though.

The domain I’ve chosen for the mock system is Hotel Information.

We have a Hotel object that has some basic information about a hotel. The Hotel can have one or more Facts (i.e DistanceToVillage = 500m) and the Fact is of a specific FactType.

The reason why we decided to move to CQRS was the two new requirements that we were handed:

• Several “downstream” systems needs to be integrated in more or less real-time.
• We need to keep a complete log of every change that happens in the system for auditing purposes.

Both of these seemed like a pretty good reason to introduce Events of some sort, and since I had recently listened a lot to Greg Young. Well.. I simply couldn’t help myself..

Architecture (Before)

First, let’s examine the state of the system pre-refactoring. As I mentioned, it’s pretty standard nTier/CRUD. A simplified diagram would look something like this:

The client connects to a façade (in the real case it’s a WebService, in the sample code I’m calling the “service layer” directly but that really doesn’t change a lot..). The façade uses DTOs so no domain objects travel across boundaries.

Below the façade sits some kind of business logic (the Application Service layer in this diagram). There is no true DDD-style Domain Model however, so all logic is contained in Transaction Scripts.

Accessing data is done via a quite simple Repository-pattern framework I’ve done (Petite.Repository, available on NuGet) that sits on top of Entity Framework.

Let’s just show you some code. Here are a few snippets from the HotelService. The first one is the method that returns a single Hotel:

Next are the Add and Update methods from the same file.

Nothing fancy and not very exciting.

While I have your attention though, I might as well show you one of the test classes. I’m fairly happy with these actually and they get even better as we move to a more CQRSy model.

CQRS – The Silver Bullet?

This is not going to be a “Introduction to CQRS” article. If you don’t have a clue of what I’m talking about I very much recommend you to visit the CQRS Info site.

Anyway, as you know, the main point of CQRS is to separate your stuff into Commands and Queries, where Commands are used to change the state of your system (but without returning said state to you) and Queries are used to, you guessed it, return the state of your system (but without changing it).

Keeping compatible with UI and DB

The following conversation never actually happened since I played it up in my head quite a few times, and the result was always the same:

Me: You know the system we’ve been working on for the past 6 months? I’d like to make a few changes.

PM: OK, that’s cool I guess. You need to change a column in the DB or something?

Me: Eh. No. I’d like to replace the DB with an Event Store and some read models in RavenDB. I’d also like to rethink the UI so that it is more in line with the Task Based model that is preferred in CQRS systems.

PM: Ain’t gonna happen.

Me: Bummer.

Instead, I tried to find a model that would let me keep as much as possible of the work that had already been done while still bringing in some of the nicer attributes of a CQRS system. I wanted to keep the Façade compatible so that the UI wouldn’t have to change. Also, the DB was already used by a few SSIS-packages (and I hate making changes to our dbproj-files) so I wanted to keep as much of that as possible too. That pretty much meant that all the work would have to be done right in the middle!

Step by step to CQRS bliss

In the following series of posts I will take you step by step through the process we took. Each step in itself brings something to the table and I think it will be easier to follow my reasoning if we divide it. That said, if you want to do something like this yourself I would probably recommend to do it all in one swoop..

Queries

OK, this this first one is very easy. At least for now.

The queries, i.e all the Get, List, and Find-methods: Keep ‘em! As we won’t change the database model this should be fine. Later on we will be able to do a lot of fun stuff with queries though, but we won’t go there yet.

Tune in to the next episode where I’ll show you Commands. That should be at least a bit more interesting.

Since being sold on IoC and Dependency Injection around 2008 I’ve been using Unity as the container-of-choice. Why? Well, why does anyone use Unity? Because Microsoft wrote it and it has everything you could possibly ask for in a container. Well, except speed of course. And ease of use. And some way of understanding what the heck is going on behind the scenes. But, those where realizations that kind of crept up on me, and once they did I had gotten so used to them that I didn’t really mind them too much.

Then a few months ago I started setting up yet another web service project and started thinking that maybe I should look around a bit before just doing what I always do. I set up a couple of simple goals I wanted a new container to fulfill:

1. Easy to use and troubleshoot. In Unity whenever someone made a mistake with a registration, more often than not they had to go find me to help them find the problem.
2. Fast. In this project in particular, speed is of the utmost importance. And I really mean that. Every fraction of a millisecond actually counts.
3. Simple. Most often we only use the basics of a DI container, we simply don’t need tons of features.

Quite early I heard about Funq and I immediately fell in love with the idea of specifying a factory method instead of relying on reflection. First of all, it is of course blazingly fast. But more importantly a lot of common errors, such as adding a new parameter to a constructor without telling the registration about it, are all of a sudden found at compile-time instead of at runtime.

So, why didn’t I just use Funq (or Munq, a project with pretty much the same ideas as I had)? Why did I go ahead and write my own version? Well, the most obvious reason is of course – because I felt like it. But also, Funq seemed to be a bit more bloated than I needed (among other things it has a lot of strange code-genned overloads and stuff). Even Munq has quite a bit of code which definitely might make it easier to get started with (such as automatic registration), but it also makes it a little less transparent and a little more tricky to troubleshoot.

What really tipped me over though was that one of the biggest complaints I hear all the time about Unity is that it is impossibly to debug your way through a program when so much of it is put together in an assembly that you cannot easily step into. Sure, the code is available and it is quite possible to set it up on a symbol server or something similar, but having the code right there in your project would make it oh-so-much easier for everyone involved.

Aaanyway.. Petite.Container and Petite.Container.CommonServiceLocator are now found on NuGet (together with Petite.Repository.Domain and Petite.Repository.Data which I’ll try to write a little about some other time). And all the code with some unit tests etc is on github. Feel free to use it, but be aware that these are early bits not yet tried and tested in production (they will be quite soon though).

Today I thought I’d take you through the things you need to know in order to get Entile working with this scenario – sending and using extra information to the server from an MVVM-based phone project. If you are interested in Windows Phone 7 development but have no idea what I’m talking about, start off by having a look at the Entile summary page.

Client side

Let’s begin with your ViewModel. The main entrypoint for all things Entile on the client is, lo and behold, the EntileClient class. This should be a singleton somewhere in your Windows Phone application. It is pretty much up to you where you want to store it – the important thing is that you need to be able to access it whenever you want to change the status of your registration with the Entile Service (such as turning on/off notifications and passing extra information). In this reasonably simple case I only have a single ViewModel called MainViewModel, so I’ll add the Entile client directly to it:

public class MainViewModel : INotifyPropertyChanged
{
    private readonly EntileClient _entile;

    public MainViewModel()
    {
        _entile = new EntileClient();
    }

    public EntileClient Entile
    {
        get { return _entile; }
    }

Next, let’s drop the EntileView user control on the MainPage (which is the view that uses the MainViewModel. While we’re at it, let’s also add a simple text box where we can enter some extra information to send to the server:

    <StackPanel>
        <TextBlock Text="Enter tile title"/>
        <TextBox Text="{Binding TileTitle, Mode=TwoWay}"/>
                    
        <TestApp:EntileView DataContext="{Binding Entile}"/>
    </StackPanel>

Last thing to do on the client side is to setup the TileTitle property so that it actually passes the information to Entile. This is done by the UpdateExtraInfo method on the EntileClient object.

    private string _tileTitle;
    public string TileTitle
    {
        get { return _tileTitle; }
        set
        {
            _tileTitle = value;
            NotifyPropertyChanged("TileTitle");
            UpdateRegistrationInfo();
        }
    }

    private void UpdateRegistrationInfo()
    {
        var info = new Dictionary<string, string>();
        info["TileTitle"] = TileTitle;
        _entile.UpdateExtraInfo(info);
    }

Running this without modifying anything on the server side will save that extra info in whatever storage you are using (most likely an Xml-file in the App_Data directory).

Server side

OK, to the server side implementation!

As you may have noticed, for each module on the server you generally have two main classes; the Module and the Service. The Module will be instantiated when your application starts up and will be kept in memory until it shuts down. The Service will be created on demand when one of its endpoints is invoked.

You have access to two important interfaces, INotificationQueue and IRegistrator. They are passed on the constructor of the Service or in the Initialize method of the Module.

IRegistrator has methods to query the registration data store for information about any registered clients. You can also subscribe to events such as ClientRegistered or ClientExtraInfoUpdated.

INotificationQueue is the interface that helps you send Tiles and Toasts. The only method you should use is EnqueueItem which takes either a ToastNotification or a TileNotification (and optionally a DateTime if you want to send the notification at a later point in time).

In this example, I’m going to subscribe to the ClientExtraInfoUpdated event and when that happens, immediately send a TileNotification where the Title has been set to whatever the client passed in as the TileTitle in its extra info.

    private INotificationQueue _notificationQueue;
    private IRegistrator _registrator;

    public void Initialize(INotificationQueue notificationQueue, IRegistrator registrator)
    {
        _registrator = registrator;
        _notificationQueue = notificationQueue;
            
        _registrator.ClientExtraInfoUpdated += (a, e) => SendTile(e.UniqueId);
    }

    private void SendTile(string uniqueId)
    {
        var extraInfo = _registrator.GetExtraInfo(uniqueId);
        string tileTitle;
        if (extraInfo.TryGetValue("TileTitle", out tileTitle))
        {
            var tile = new TileNotification(uniqueId)
                            {
                                Title = tileTitle
                            };
                
            _notificationQueue.EnqueueItem(tile);
        }
    }

OK, I was going to add some nice screenshots of this in action, but for some weird reason my WordPress installation doesn’t want me to do that today…

Conclusion

So, this post introduced you to the concept of Extra Information passed from the Entile client to the server. First I showed how you can store the EntileClient object in your MVVM model. I then showed you the UpdateExtraInfo method and how to call it. Finally, I introduced you to the two main server-side interfaces, INotificationQueue and IRegistrator and one way of putting them to use.

As always I welcome all comments, suggestions and, well.. any life-signs at all actually..!

Prerequisites

You’ll need the following installed on your developer machine:

• Visual Studio 2010 with Windows Phone Developer Tools
• NuGet package manager (installed with ASP.NET MVC3 – can also be installed separately)

Create the Windows Phone 7 App

First of all, let’s create a simple Windows Phone 7 App. I’m using the Pivot template from the Silverlight Toolkit, but any template will do.

Create the Web Application

While we are at it, we’ll create the Server part of the application too. In this case, I’m going for an empty ASP.NET MVC 3 application, but again, more or less any Web Application or WCF Service Application will do.

Add the NuGet packages

Open up the Library Package console (Tools->Library Package Manager->Package Manager Console). Type the following into the console (replace EntileDemo.App with the name of your Windows Phone 7 Project and EntileDemo.Host with the name of your Web Application project):

Install-Package entile-client -Project EntileDemo.App

Install-Package entile-server -Project EntileDemo.Host

This will download and install the client and the server part of Entile into your solution. You should now be able to build everything, but it won’t run properly just yet.

Configuring the client

Now it is time to make sure that the client knows how to talk to the server. By default, all client-side settings are found in the EntileSettings.xaml file. Open it up and change the RegistrationServiceUri and the AllowedTileUris entries to point to the name of your host. Working locally on your dev machine it will look something like this (where 1234 should be replaced by the port number of your Web Application):

<sys:String x:Key="RegistrationServiceUri">http://localhost:1234/Sample/Registration</sys:String>

<sys:String x:Key="AllowedTileUris">http://localhost:1234</sys:String>

You should also set the ChannelName to something that makes sense, perhaps “DemoChannel”?

Then we just need to hook up the settings to make the application aware of them. You do this by adding the following lines to the Application.Resources element in your App.xaml file:

<ResourceDictionary>
    <ResourceDictionary.MergedDictionaries>
        <ResourceDictionary Source="EntileSettings.xaml"/>
    </ResourceDictionary.MergedDictionaries>
</ResourceDictionary>

Configuring the server

Now we need to configure the Sample module found in the server. First of all, in the root of your Web Application you should now have a file called EntileStartup.cs. This is where all modules are registered, all we need to do here is to change the host name:

One more thing, let’s also make sure that we can send a nice Live Tile by, again, changing the host name – this time it’s in the EntileModules\SampleService.cs file:

Add the view

Finally (yes, this is indeed the last setup step) we are going to add the EntileView to your App. First, make sure that you have built the project. Next, open up the MainPage.xaml file and find a nice place for the EntileView user control. I chose to put it on a PivotItem called “settings”. The easiest way to get it there is to find it in the toolbox and drag it onto the xaml:

Let’s run it, shall we?

Both projects need to run at the same time, so if you haven’t done so already, open up the properties window for your solution and set it up so that they are both set to Start:

Now, hit F5 and wait for both the emulator to start up with your phone app, and the web project to show a default page (a 404 in my case since I’m used an empty MVC project). Switch to the screen where you put the EntileView, and hit the checkbox. This will open up a channel and register the application with your server.

So, we got this running, let’s show off the capabilities!

Hit the back button and pin the application to your home screen. Open up your browser and enter the following URL (as usual, substitute the host/port with your own):

http://localhost:1234/Sample/SendSampleTileToAllClients

And then to finish it all off, send a toast as well:

http://localhost:1234/Sample/SendSampleToastToAllClients

The result, hopefully, looks something like this:

Conclusion

I’ve shown how to use the Entile Notification Framework for Windows Phone 7 in order to get a Live Tile and Toast-enabled Windows Phone 7 Application in just a few minutes. Rest assured however that there is more to Entile than this. A few things you haven’t seen yet but that I hopefully will be blogging about soon enough:

• Data stores
• Adding extra information to your registrations
• The notification queue and using a worker.
• Running in the cloud (Azure and/or AppHarbor?)
• … and perhaps something else you’d like to know about?

As always, please please do leave a comment, ping me (@CodingInsomnia) or @entile_fx on Twitter or why not do a blog post of your own experiences with Entile? I would really like to hear from you!

Anyway, rejoice, because Entile Notification Framework for Windows Phone 7 is now on github!

So, from now on please get your downloads from there. No major changes since the preview though, I’ve mostly spent some time getting to know how to use git and github…

Feel free to contribute! I have no idea how to handle pull requests and so on, but I’m sure I’ll be able to figure it out.