Microsoft recently released a beta version of their Service Bus for Windows messaging technology, and the Iron Foundry team has now added this as an available service in Iron Foundry. The Service Bus for Windows is a scaled down version of the Service Bus product included in their Windows Azure cloud offering. The Service Bus for Windows, which supports brokered message through both traditional Queues and multi-subscriber Topics, provides Iron Foundry developers yet another option when building distributed applications.
Our awesome dev team followed the standard steps for adding new application services to a Cloud Foundry / Iron Foundry environment and also used a previous write-up of mine to guide the software installation. We’ve already updated the vcap-services source code into Github and you can clone the mssb (Microsoft Service Bus) directory today. There were also changes to the .NET DEA to account for this new service and handing credentials back to the user. The Service Bus for Windows uses Microsoft SQL Server for its persistence tier, so we’ve tied the service to the instance of SQL Server that runs in Iron Foundry. Our hosted ironFoundry.me environment is running this today, and we’ve provisioned a shared Service Bus farm and host that holds each consumer’s individual namespace. Let’s see a demonstration of this in action!
To make life easier, we’ve built a sample web application that interacts with Service Bus Queues. We’ll start by looking at that application, and then deploy the application to Iron Foundry. The application contains a few ASP.NET Web Forms and a helper class. The helper class (QueueManager.cs) contains a singleton that upon startup, parses Iron Foundry-provided URLs and credentials encoded as JSON in the application’s web.config file and uses those parameters to instantiate the core objects in the Windows Service Bus SDK.
Then we have some static operations for both sending to and receiving from the Service Bus Queue.
These operations are used in the pair of core ASP.NET pages to send and receive messages. Let’s now deploy this application to Iron Foundry and see how it works. Using vmc, I targeted the api.ironfoundry.me environment.
I can confirm that the Service Bus for Windows is an available service by issuing a vmc services command.
Great. Now let’s push this web application and provision an instance of this new service type. After publishing the ASP.NET web application to a file directory, I issued the vmc push command to start the deployment process.
At this stage, I’m asked if I want to create a new service instance to bind to, or if I had already provisioned one, which instance I’d like to associate with. In this case, I have no existing services, so I’ll choose to create a new service.
Within a matter of moments, my application is deployed and a new service instance is provisioned in the shared environment. This environment is not currently part of a Windows domain, so during service provisioning, a new local user is created and assigned to the developer’s own Service Bus namespace. All the URLs and credentials for the application are injected into the application’s web.config file. We can see this through vmc by viewing the file with the vmc files <application name> app/web.config command.
These JSON-encoded values are then read by our application and used when authenticating the caller during Queue operations. Upon visiting the URL of the Iron Foundry application, we can see the option to send a message to a Queue.
When we submit the message, it is added to a Queue, which means that it is persisted in a database. I then switch over to the “Receive” web form and choose to pull all of the messages from the Queue.
The Service Bus for Windows is still in Beta, but we thought it would be fun to add this as an Iron Foundry service. You can download the source code for this sample application from here. Messaging is a core part of many modern web applications and the Service Bus for Windows gives Iron Foundry developers another way to link systems together.