Pablo M. Cibraro (aka Cibrax)

If you are using SQL Azure nowadays, you probably know that there are only a few alternatives for making backups of your existing data.

• You can use SQL Azure Data Sync, which provides bi-directional data synchronization and data management capabilities allowing data to be easily shared across SQL Azure databases within multiple data centers. This implies you need at least one additional database for backing up your data, and SQL Azure databases are not necessarily cheap to keep them around without any functional use.
• You can use third party tools like the ones offered by Cerebrata or RedGate to synchronize SQL Azure databases with On-Premises databases or dump your data to files

Or you can use Hgdbackup, an OS alternative started by Bertrand Le Roy that uses the SQL BCP command line tool to persist your database data into text-based files.  As this was exactly what I was needing for an Azure project, I decided to contribute some code to that tool for storing the backup files to the Blob Storage in Azure. Therefore, you can now specify in the tool the Azure storage account you want to use to store your backup files, or restore your database from. 

The tool uses the raw REST API for the Blob Storage service so the Azure SDK or the binaries included on it are not required. This means the tool is very simple to distribute or run in a server with minimal requisites.

The following examples illustrates how you can run the tool for making a new backup or restore an existing database.

Backup Example

Hgdbackup.exe /S:tcp:YOUR_Server.database.windows.net /D:YOUR_DB /U:YOUR_USER /P:YOUR_PASSWORD /A:YOUR_BLOB_ACCOUNT /K:YOUR_BLOB_KEY /T:"Server={0},1433;Database={1};User Id={2};Password={3};Trusted_Connection=False;Encrypt=True;"

Restore Example

Hgdrestore.exe /S:.\SQLExpress /D:YOUR_DB  /C:YOUR_BLOB_CONTAINER /A:YOUR_BLOB_ACCOUNT /K:YOUR_BLOB_KEY

The backup tool supports an additional argument “C:” for passing the container where you want to store the text files with the data. If you don’t provide a container name, the tool will generate a new container for you.

The good thing about this tool is that it is an open source initiative so you are free to contribute, give feedback or improve it as I did with this support for the blob storage.

We have been working a lot lately with PowerShell as part of our star product at Tellago Studios, “Moesion”. One of the main features we provide in Moesion is the ability to execute PowerShell commands remotely in a given server using a web mobile interface (You can read more in my previous post about Moesion).

One of the things we realized in all this time is that PowerShell lacks of a central repository where IT guys or we, the developers, can easily grab and reuse commands.  All the commands or modules are basically spread across multiple places or websites, like personal blogs, TechNet or CodePlex projects to name a few making the search of them very hard. You are usually limited to use your favorite search engine and copy what you find. In addition, there is not an easy way to reuse, extend or version these commands, which also limits any contribution that you could make to the community. 

My friend Jose wrote a great post the other day about the importance of reusing PowerShell modules, and what is the mechanism to reuse them. Jose, however, based his post in a custom implementation using a GIT repository for storing the modules.

We have NuGet in the .NET platform for sharing and reusing existing libraries or code, so why can’t just leverage it for reusing PowerShell modules as well ?. Some teams in Microsoft are using NuGet for distributing libraries and binaries so it would be a great thing for all of us if they also distribute the scripting interfaces in PowerShell using NuGet. This applies to the .NET OS community as well.

In fact, it looks like Andrew Nurse had the same idea and implemented a project for this in BitBucket, PsGet.

Deployment is considered today as one of the major pain points in the Windows Azure platform.  A simple application deployment today can take around 20 or 30 minutes to complete, and to make the things even worse, there is not support for partial updates meaning that a simple change requires a complete upgrade or deployment.  The Windows Azure team has recently introduced the support for web deploy in the platform to deal with this issue. Using Web Deploy, you can deploy a complete application or part of it in an existing web role instance in a matter of seconds, which is a huge improvement to what we had so far. 

However, Web Deploy only supports deployments to a single instance in a web role.  If your web role is made up of two or more instances, which is the typical configuration instances to be covered by a 100% uptime, web deploy won’t work in that scenario.

This is where the Windows Azure Accelerator for Web Roles enters the scene. This is a project created by the Developer and Platform evangelism team in Microsoft for deploying one or more websites across multiple Web Role instances using Web Deploy.  It basically explores the idea of using a single web role for hosting multiple web sites, simplifying the deployment and minimizing costs.

As part of the project, you will find an MVC application that you can deploy in one hosted service in Azure.  That application provides an visual administrative interface to define and manage the websites or applications you want to host in the web role. 

As you will be managing multiples websites internally hosted in a web role, you will need to assign different http host headers to those web sites and have domains or CName records already set for those. For example, if the address of your hosted service is cibrax.cloudapp.net (The MVC application will be listening on this address), you can later set some CName records in your domain for redirecting users to the hosted service address (www.mydomain.com –> cibrax.cloudapp.net)

Therefore, you won’t able to use this project if you don’t own a public domain in which you can set up some CName records.

Another important aspect of the accelerator is that it replicates your websites across all the instances of the web role breaking that big limitation in Web Deploy. It internally uses the blob storage to perform this replication.

In a traditional web application hosted in Azure, you will want to have some configuration settings as part the hosted service configuration so they can easily be changed without deploying your application completely, which is what it would happen if you have everything in the web.config file for example. This is no longer needed with the accelerator as you can now deploy an application from scratch in a few seconds.

Moving your application to the cloud might not be easy as it sounds. The typical sample we always see in documentation or demos about an ASP.NET application created from the Visual Studio template and deploy it in Azure as a package is definitely very far from reality. There are multiple factors that can affect the response time and availability of your applications in the cloud but you can not easily see until you embark on a real project. Application distribution and deployment is one of those factors, and the one we are going to discuss in this post.

Windows Azure uses the idea of regions to manage the physical distribution of your applications and data. A region in a nutshell represents a Microsoft data center where you can deploy your application or part of it. Nowadays, you can find multiple regions spread across the globe in places such as North America, Europe and Asia.

There is another abstraction layer on top of regions called "Affinity Groups", which simply tells the Fabric controller to do its best to ensure groups of related services are deployed in close proximity whenever possible to ensure optimization for inter-app communication. For example, in a typical web application with a database,  you will want to deploy the web application as close as possible to the database server. 

Finally, another important concept you need to understand in this deployment model is the idea of “hosted service”. A hosted service basically represents an unit of deployment associated to a public DNS in the cloud. You deploy your applications in a hosted service, which is also tied to a region or affinity group. What Azure gives you is a public address for reaching that hosted service in the cloud, which is “[you app name].cloudapp.net” for applications hosted in the production environment and an auto generated guid for applications hosted in the staging environment. You can also think in a hosted service as a load balancer that forwards requests from that public address to one of the instances or VMs associated to it.

Let’s discuss the aspects you need to consider for selecting the right regions for deploying your application.

• Network latency: reducing the network latency is very important as it will impact directly on the response time for your applications. You will want to have your users as close as possible physically from your applications and data. For example, if you have some potential users in the US and Europe, you will want to deploy two exact replicas from your application and data in the US and Europe data centers. As you might guess, this is not as easy as it sounds and there are a lot of challenges you need to address, how you can effectively redirect the users to the right region, or how you can synchronize your data across regions are typical questions or concerns you have to tackle first.
• Availability: you will want to have your applications available all the time. Many things can happen, but you need to understand that a region or data center might become offline and your application should be prepared to handle that scenario. Your applications and data should be replicated across multiple regions to not be affected when things like this occur.   

Microsoft already offers a set of tools or technologies you can use to address these two aspects, so let’s discuss some of them in detail in the next paragraphs.

Windows Azure Traffic Manager

While this technology is still a CTP and not available for all public in general, it will provide several methods for distributing internet traffic among two or more hosted services in different Windows Azure datacenters. It is in essence a distributed DNS service that knows which Windows Azure Services are sitting behind the traffic manager URL and distributes requests based on different policies  or modes you can configure. It will initially support three modes, “Failover”, “Performance” and “Round-Robin”.

In the “Failover” mode,  all the traffic is redirected to a single hosted service, unless it fails. If the redirection fails because the hosted service is not longer available,  it then directs the traffic to the hosted service configured as failover. For example, you can configure the South Central US region as a backup for the North Central US region and vice versa. If any of those regions go offline, the other one will take its place.

In the “Performance” mode, all traffic is mapped to the hosted service “closest” to the client requesting it.  For example, this will direct users from the US to one of the US datacenters and European users will probably end up in one of the European datacenters.

Finally, in the “Round-robin” mode, the traffic is distributed in a round robin fashion across several hosted services configured in the policy.

As you can see, this tool only tackles the two aspects mentioned before from the point of view of traffic redirection. However, you also need to make sure the data is also consistently available in all the regions, and that’s something this tool won’t solve. For example, if the users are redirected from North US to Central US, you need to make sure the data they get access look the same.

Content Delivery Network (CDN)

You can imagine the Windows Azure Content Delivery Network as a huge http cache spread across the globe for content such as images, files, scripts, or static html to name a few. You can either configure CDN for a blob storage account or an http endpoint in your application (and endpoint with an url ending in “cdn”, for example xxx.cloudapp.net/cdn). All that content will be cached in the nodes that are part of the network using standard Http caching. The CDN will serve later the cached copy closest to the user requesting it, improving in this way the response time.

There are today more than 18 locations or nodes globally (United States, Europe, Asia, Australia and South America) and this number keeps growing.

SQL Azure Data Sync

While the Azure Table Service already provides some built-in support for crash recovery based on the idea of partitions that are replicated across different nodes (in different sub regions, for example North US and Central US), a SQL Azure database is not prepared for that scenario.  If you also use something like the Traffic Manager to redirect users to the closest data center, you probably would want to have all the databases in the different regions in sync between them making all this process transparent to the user.

If you want to support that scenario, the SQL Azure Data Sync is the tool that will help you in this matter. In a nutshell, SQL Azure Data Sync is a cloud-based data synchronization service built on the Microsoft Sync Framework technologies. It provides bi-directional data synchronization and data management capabilities allowing data to be easily shared across SQL Azure databases within multiple data centers.

There are a few things you will have to configure in this tool

• The databases you want to keep in sync, and also the tables and columns in those databases
• The schedule or frequency for doing the synchronization.
• How you want to resolve any conflict that might occur during the synchronization.

As you can see, the combination of this tool with the traffic manager will help you to keep applications and data in sync between different region for the most common scenarios.

A hosted service in azure is typically assigned with two public addresses, one for the production environment with a DNS name ending in cloudapp.net such as [your name].cloudapp.net and an auto generated DNS name for the staging environment such as 4969aae4e18f4699aa88223e1e73ba8e.cloudapp.net. There are multiple reasons you might want to map your custom domain name to these public names in Azure, but these are the most common ones I can imagine,

• You don’t want to tie your websites to a single cloud hosting vendor such as Microsoft
• You host multiple websites in a single hosted service in azure, so a single address such as xxx.cloudapp.net  does not make sense anymore. In that scenario, you need to use different port numbers for the websites or use host headers, which is the typical solution. For example, you might want to map [your name].com and [your other name].com to two different websites in the same hosted service (xxx.cloudapp.net).
• You want to map a single domain to multiple hosted services in azure in different regions, and use geographic DNS routing to balance traffic. For example, you might have xxx-us.cloudapp.net for a hosted service in the US and xxx-eu.cloudapp.net for another hosted service in Europe but a single domain [your name].com that automatically routes the traffic according to the source of the http requests.

In the two first cases, the use of CName records in a domain that you own will work for redirecting all the traffic from there to the hosted service in Azure. The last one might require an additional DNS service like the Traffic Manager in Azure or Route53 in Amazon. 

It’s common nowadays for most websites to host two different versions of the same portal for mobile devices and regular browsers, which basically fits in the scenario I described as number #2. We can not use the default addressing schema in Azure anymore because the IIS instance running in hosted service wouldn’t know how to route the traffic to the right portal. However, this can be resolved with a combination of CName records at DNS level and host headers at IIS configuration level.

Configuring different host headers for the websites in IIS is easy to achieve with the use of multiples bindings and endpoints at configuration level.

<Sites>

  <Site name="Mobile" physicalDirectory="..\xxx">

    <Bindings>

      <Binding name="HttpIn" endpointName="HttpIn" hostHeader="m.xxx.com" />

      <Binding name="HttpInStaging" endpointName="HttpIn" hostHeader="stagingm.xxx.com" />          

    </Bindings>

  </Site>

  <Site name="Portal" physicalDirectory="..\xxx">

    <Bindings>

      <Binding name="HttpIn" endpointName="HttpIn" hostHeader="www.xxx.com" />      

      <Binding name="HttpInStaging" endpointName="HttpIn" hostHeader="staging.xxx.com" />

    </Bindings>

  </Site>

</Sites>

The snippet above illustrates how the Service Definition should look for supporting two different web sites for the mobile site and regular web site. An important thing to notice in the configuration is that I also included the host headers for staging, so you can test staging as well before making the switch to production. This means will require a different set of CName records for staging and production,

• The “www” and “m” records will point to the production website in azure, xxx.cloudapp.net
• The “staging” and “stagingm” records will point to the auto generated address for staging in azure

A CName record for the auto generated address in staging is not a good thing as it gets generated every time you create a new staging deployment. However, there is no other good way to fix in the meantime unless you actually do not include this definition for staging and you test everything local by pointing your windows host file to the IP address in staging (For instance, www.xxx.com [Staging IP Address] and m.xxx.com [Staging IP Address]).

The service definition can not be changed or updated once the deployment has been completed so make sure to get it right in the first place.

In the recent “Build” event, Microsoft introduced a new feature Windows Server 8 known as “Windows Powershell Web Access” for exposing a the server powershell console through a web interface. Although this feature looks very promising in first place, I only think it is convenient for intranet scenarios. I don’t initially see an organization exposing their servers directly to internet for using this feature from a phone as it represents a high risk.

As I discussed a time ago in this post “Pub/Sub in the cloud ..”, technologies like Windows Azure Service Bus, PubNub or Fanout  (implemented in Node.JS) can act as intermediaries in the cloud for passing messages between clients and servers that are not publically addressable or can talk each other directly in the same network. All these technologies relies on outbound http connections for talking to the cloud, which are not typically blocked by firewalls.

What happens if you decide to extend this idea of passing messages from clients to servers to the IT Management world, and those messages actually represent actions you want to perform on your servers like restarting a web server or getting a list of active process. You would be able to control any of the servers in your organization from any device connected to the internet right ?. Do you think it’s too risky too ?.  Ok, let’s add an additional layer on the cloud, which can act as firewall and control access about who can do what on the different servers. This additional layer on the cloud can also have a very nice HTML 5 visual interface that any IT guy in your organization can easily understand and use from any browser or device connected to the internet. At that point, you have everything you need to be in control of your servers from anywhere, even when you are driving back from work.

That’s the main idea of project where I have been working for the last few months in Tellago Studios and it was announced to the world today as Moesion.com. Take a look and subscribe to the beta program today, there will be a free personal edition that you could use for managing your servers.

One of the hidden gems that you can get today from the WCF Web Api source code in codeplex (wcf.codeplex.com) is the support for the task-based asynchronous model introduced in .NET 4.0. The new model simplifies a lot the way you do asynchronous stuff in .NET, and it’s going to get even better with the async support in C# 5.

The idea here is that you represent an asynchronous operation with a Task<T> class, where T is the resulting type. There is no need to call an End operation to retrieve the result anymore, as the result can be obtained from the task itself. You also get some of other cool features for free like support for cancellations, exception handling and operation composition.

With the recent addition of this new model to WCF, making async operations in a service is just a matter of returning a Task<T> class, and WCF will take care of the rest for us . The following code illustrates how an async operation looks like

[WebGet(UriTemplate = "contacts")]

public Task<HttpResponseMessage> Contacts()

{

    // Create an HttpClient (we could also reuse an existing one)

    HttpClient client = new HttpClient();

    // Submit GET requests for contacts and return task directly

    return client.GetAsync(backendAddress + "/contacts");

}

That’s pretty cool, isn’t it ?. What about invoking a query against a database and returns the results asynchronously in a service operation ?. ADO.NET supports an asynchronous model already, but Entity Framework still does not. Nothing that can not be resolved easily with an extension method in IQueryable,

public static class AsyncExtensions

{    

    public static Task<IEnumerable<T>> AsAsync<T>(this IQueryable<T> source) where T : EntityObject

    {

        var query = (ObjectQuery<T>)source;        

        var cmd = new SqlCommand();

        cmd.Connection = (SqlConnection)((EntityConnection)query.Context.Connection).StoreConnection;

        cmd.CommandText = query.ToTraceString(); 

        cmd.Parameters.AddRange(query.Parameters.Select(x => new SqlParameter(x.Name, x.Value ?? DBNull.Value)).ToArray());        

        cmd.Connection.ConnectionString = new SqlConnectionStringBuilder(cmd.Connection.ConnectionString)

        {            

            AsynchronousProcessing = true        

        }.ToString();        

        cmd.Connection.Open();

        var tcs = new TaskCompletionSource<IEnumerable<T>>();

        Task.Factory.FromAsync<SqlDataReader>(cmd.BeginExecuteReader(), cmd.EndExecuteReader).ContinueWith(task =>

            {

                if (task.IsFaulted) tcs.TrySetException(task.Exception.InnerExceptions);

                else if (task.IsCanceled) tcs.TrySetCanceled();

                else tcs.TrySetResult(query.Context.Translate<T>(task.Result).Cast<T>());

            });

        return tcs.Task;

    }

}

This extension method allows to do things like context.Customers.Where(c => c.Id == 1).AsAsync() to execute an async query against EF to return a customer with ID equals to 1.

Ok, so far we have an extension method that executes a query asynchronously, so now, it’s a matter of returning that resulting task in our operation.

[ServiceContract]

public class CustomerResource

{

    [WebGet]

    public Task<IEnumerable<CustomerDTO>> GetAllCustomers()

    {

        var model = new NorthwindEntities();

        return model.Customers.AsAsync()

            .ToApm(t => t.Result.Select(c => new CustomerDTO { Id = c.CustomerID, Name = c.ContactName }));

    }

}

Two things to notice in the code above.

1. I am doing a projection to return a dto and not the original entity, which I might not want to serialize completely on the wire
2. I am doing a task continuation or composition through the “ToApm” extension method. For illustrative purposes, that code means I want to do a projection right after the query execution is completed and return that.

The code for the “ToApm” extension method is quite simple as well.

public static class TaskExtensions

{

    public static Task<TResult> ToApm<TResult, TSource>(this Task<TSource> task, Func<Task<TSource>, TResult> action)

    {

        var tcs = new TaskCompletionSource<TResult>();

        task.ContinueWith(delegate

        {

            if (task.IsFaulted) tcs.TrySetException(task.Exception.InnerExceptions);

            else if (task.IsCanceled) tcs.TrySetCanceled();

            else tcs.TrySetResult(action(task));

        }, CancellationToken.None, TaskContinuationOptions.ExecuteSynchronously, TaskScheduler.Default);

        return tcs.Task;

    }

}

It does a continuation on the original task passed as argument and also verifies whether the task was cancelled or some exception occurred before returning the result.

Go and grab the WCF source in codeplex to start playing with these cool features today

As some of you might know, with the release of Node version 0.5.2, there is now support for Windows. It’s a single executable “node.exe” that you need to start using node on your machine, and you can get it from this location.

Express is a Sinatra inspired web development framework for Node. You can find more information about this framework here.

Once you download node in your system, you need to setup an optional environment variable “NODE_PATH”, which points to the root path or location that Node will use to resolve the external module references. A module in Node represents an unit of code reuse, pretty similar to a library or an assembly in .NET, but it’s not something binary, it is just JavaScript code. You can also optionally set the node executable path in the “PATH” environmental variable to run the exe from any location.

In my case, I created the following structure on my disk for running Node.

d:>

----> NodeJs

------> Node.exe

------> Applications

“NODE_PATH” and “PATH” both points to the folder “NodeJS” on my “d:” drive. All the applications or samples will be deployed in the “Applications” folder.

In the Linux world, Node also comes with a very useful package manager “NPM” that automatically resolves external module dependencies for you.  As analogy with other platforms like Ruby or .NET, “NPM” would be equivalent to Ruby GEMS or NuGet.

Unfortunately, “NPM” is still not ready for being used on Windows, there are some technical details that need to be addressed to migrate the current implementation to windows. Good news is that Jeroen Janssen has created a similar implementation in Python so you can run it in windows. The name of this implementation is “ryppi” and you can get it from this github repository. It’s a single Phyton script “ryppi.py” that currently works with Python 2.X only. If you have Python 2.x already installed on your system, you can run the script as follow to resolve an external dependency “python ryppi install <PACKAGE_NAME>”.

In the case of “Express”, you can run  “python ryppi install Express” from the location where you set the “NODE_PATH” variable. After running the command, you should be able to see a new folder “node_modules” in that location, and an “express” folder inside of it. That’s the only package you need to run the “Express” core, but you also might want to download “jade” and “saas” for using the Jade View Engine and the SAAS engine respectively.

In addition to the “Express” core library, there is an node application you can use to setup the initial folder structure for your web applications. The “Express” application is available under “node_modules/express/bin/express”, and you can run it with node itself. Bad news is that this application does not run on windows because it uses the “child_process” module, which is not currently supported on windows. I modified that application to get rid of the “child_process” module and use all the functionality available in windows. This updated version is available to download from here.

If you replace the version in “node_modules/express/bin/express” by the one I updated, you should able to run it with node as follow “node.exe ./node_modules/express/bin/express –help”. That will show the help instructions to setup a new web application. A new web application with all the defaults can be created by just passing a name to that “express” application, “node.exe ./node_modules/express/bin/express mywebapp”. One thing to have in mind is that the application will be created as a new folder in the current location, so you might want to run it from “NodeJs/Applications” if you are planning to have the web application in there.

The command will generate a new folder “mywebapp” with all the boilerplate structure you need to run a web application from scratch.  The folder structure looks like this,

- public (contains all the JavaScript, images and stylesheets that make up your site)

- views (contains all the views)

- app.js (the root application)

You can start the web application by running “node app”, and that’s it, you have your first “express” application running on windows .

As you might read in my latest post, Hermes is one our new pet projects in Tellago for doing Pub/Sub over http. The idea is simple, but still very useful for integration scenarios in the enterprise. The fact that Hermes is all based on Http and uses one of the most famous open source initiatives for NoSQL databases like MongoDB, makes this project very appealing for the cloud as well. Many of the cloud platforms already provide MongoDB as a service that you can use in your applications hosted in the cloud.

AppHarbor is probably one of the best “PaaS” solutions for running .NET applications in the cloud. The marketing slogan for this platform is “Azure done right”, so you can take your own conclusions . AppHabor not only let us running any regular .NET application in the cloud, but also offers MongoDB as an addon that you can configure in your deployment, so it makes a good use case for running Hermes in the cloud.

The Hermes’s source code that you get from the GitHub repository uses by default NuGet for resolving all the external dependencies, which is not something currently supported in AppHarbor, so the first thing you need to do is to prepare the visual studio solution and all the projects to reference the binaries from a local folder (let’s say “libs”). The only project that you should deploy to the cloud is RestService, which represents the host for the REST services that you might want to use for publishing or subscribing messages to/from Hermes.

The line you need to comment out in the RestService project file for not using NuGet to resolve the external dependencies,

<Target Name="BeforeBuild">
    <Exec Condition="Exists('$(ProjectDir)packages.config')" Command="&quot;$(SolutionDir)..\Tools\nuget.exe&quot; install &quot;$(ProjectDir)packages.config&quot; -o &quot;$(SolutionDir)Packages&quot;" />
</Target>

Once you have that project running and using local references, you are ready to deploy it to the cloud. You might want to create a new project in AppHabor or use an existing one for doing this.

Every project in AppHarbor is basically mapped to a Git repository that you can use. Every time you make a push to that repository, they take care of building the solution, running the unit tests on it and publish it in a public address in their platform. The instructions for deploying the solution to their Git repository is all available in the project’s home page, and I can say it is pretty straightforward.

The public URL will be available in the home page as well once you make the first deployment as you can see in the image above. You can also associate a MongoDB instance to the project through the Add-ons option.

You will have to configure two additional things in the configuration file (web.config) of the RestService, the public URL in AppHarbor and the MondoDB connection string (available through a configuration variable).

<connectionStrings>

    <add name="db.connectionString" connectionString="mongodb://appharbor:XXXXXXXX" />

  </connectionStrings>

  <appSettings>

    <add key="baseAddress" value="http://XXXXXXXXXX.apphb.com" />

    ............

  </appSettings>

And that’s all, once you have configured that in the web.config file and pushed those changes to AppHarbor, you should be able to start using Hermes in the cloud. You can try the Publisher and Subscriber sample applications in the source code for testing your deployment in the cloud.

Enjoy

After a few months of collaborative work across several members in our Tellago crew, Hermes is finally here. Hermes, also known as the great messenger of god in the Greek mythology, was the name we gave to this new open source alternative for doing durable pub/sub messaging over http.

There is no doubt that MSMQ has been the predominant technology for doing Pub/Sub within the Microsoft stack given the reliability it provides as a temporary storage for messages. However, the main problem of using a queue technology like that is that you sacrifice interoperability for better reliability, and interoperability usually matters a lot in the enterprise. How many times you have heard stories of people doing crazy things in the enterprise with queue connectors or similar technologies for decoupling systems implemented in different platform stacks.

Http is something universal accepted in all the existing platforms and makes the things really simple in that sense. Almost all the existing programming languages in the world provide libraries for consuming Http endpoints or Web Apis with a few lines of code.

There are some Pub/Sub alternatives using Http and RESTful services in the cloud like the AppFabric Service Bus or PubNub, but Hermes is also suited to be used within the boundaries of a single organization.  Every time you want to decouple two systems or provide valuable business events to other systems you don't know upfront, Hermes becomes a great candidate for implementing that kind of scenario.

As I said before, you might sacrifice reliability in the sense that you are using Http for publishing the events into the Hermes repository, and a http channel must be available at that time, but that’s an issue on the publisher side only. The subscription side is implemented through simple http polling with Atom, so the subscriber can read the messages when an Http channel is available. Also, all the transformation responsibilities are moved to the subscriber side simplifying a lot the core messaging engine in Hermes.

Hermes uses MongoDB as the backend storage for the messages, making extremely easy to store, partition and index high volumes of messages for a large number of topics and subscriptions.

You can read more details about the underline architecture in the announcement made by Jesus.

Enjoy!!.