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,
<Exec Condition="Exists('$(ProjectDir)packages.config')" Command=""$(SolutionDir)..\Tools\nuget.exe" install "$(ProjectDir)packages.config" -o "$(SolutionDir)Packages"" />
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).
<add name="db.connectionString" connectionString="mongodb://appharbor:XXXXXXXX" />
<add key="baseAddress" value="http://XXXXXXXXXX.apphb.com" />
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.
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.