Implementing Azure AppFabric Service Bus - Part 2

Tweet

This is a continuation post of Implementing Azure AppFabric Service Bus series. Look at the end of this post for other parts.

In my last post, I had explained about what Azure App Fabric is, the types and how Relaying Messaging works. From this post, we will see a real time example working with Windows Azure App Fabric - Relaying Messaging.

From the Azure training kit provided by Azure Team has lots of great materials to learn about each concepts of Azure. I hope this example also will add valuable learning material for those who starts implementing Azure App Fabric in their applications.

Implementation Requirement:
We are going to take an example of Customer Maintenance entry screen which has CRUD (Create, Read, Update and Delete) operations on customer data. The service will be running in one of the on-premise server and exposed to public using Service Bus. The client Web Application will be running in another/same local system or in the cloud which consume the service to show the list of customers. The user can add a new customer, modify an existing customer by selecting from the customer list or even delete a customer from the list directly. The functionality is simple, but we are looking here how to implement with Service Bus and how the customer data flows from service to cloud and to client.

I am going to use Northwind database configured in my on-premise SQL Server for data storage. So make sure to have Northwind database for implementing this source code. (You can get the database script from here)

Requirements

1. You required to have Azure Subscription with App Fabric enabled.
2. Visual Studio 2010 (for development and compilation)
3. Install Windows Azure SDK for .NET (http://www.windowsazure.com/en-us/develop/net/)

Note: The Service Bus and Caching libraries are included as part of Windows Azure SDK from v1.6. So there is no need of installing additional setup for Azure App Fabric as we have done before.

Creating a Service Bus Namespace

Pls skip this step if you already have namespace created or know how to create.

Step 1: Open Azure Management Portal using https://windows.azure.com and select the Service Bus, Access Control & Caching tab.

The portal will open Service panel in the left hand side.

Step 2: Select the Service Bus node and select the Subscription under which you required to create the Service Bus namespace.

Step 3: Press New menu button in the Service Namespace section. The portal will open Create a New Service Namespace popup window.

Step 4: Make sure Service Bus checkbox selected and provide the input as defined below.

1. Enter the meaningful namespace in the Namespace textbox and verify the namespace availability with Check Availability.
   
   Note:
   
   • The namespace should not contain any special characters such as hyphen (_), dot (.) or any special characters. It can contain any alphanumeric letters and it should starts with only a characters.
   • The Service Namespace name must be greater than 5 and less than 50 characters in length.
   • As the namespace should be unique across all the service bus namespace created around the world, it would be better to follow some basic standard to form the namespace in the organization level.
     
     For Example - Create a unique namespace at application level or business level. So, the namespace should be as defined below
     <DomainExtention><DomainName><ApplicationName>
     For Ex: ComDotNetTwitterSOP
     
     The Service Bus endpoint URI would be
     https://ComDotNetTwitterSOP.servicebus.windows.net
     
     Once the Namespace created at application level, we can add other important names through hierarchies at the end of the service bus URI.
     <protocol>://<DomainExtention><DomainName><ApplicationName>.servicebus.windows.net/<BindingName>/<ServiceName>/<EnvironmentName>/<VersionNo>
     
     There endpoint can be exposed in different protocol such as http, https (for secure http) and sb (for net tcp), based on the binding method we are using for exposing for that endpoint.
     
     - The Binding Name will specify the name of the binding name such as Http, NetTcp.
     - The Service Name will specify the name of the service
     - The Environment Name will specify whether the namespace deployed for Test, Staging and Prod
     - The Version No will specify the version number of the release such as V0100(for Version 1.0), V0102 (for Version 1.2), V01021203 (for V 1.2.1203) etc.,
     
     So the fully qualified namespace URI for Sales Invoice would be
     https://ComDotNetTwitterSOP.servicebus.windows.net/Http/SalesInvoice/Test/V0100
     sb://ComDotNetTwitterSOP.servicebus.windows.net/NetTcp/SalesInvoice/Test/V0100
     
     This is an example of how a service bus service bus endpoint could be. Please decide as per your organization requirements.
     
     
2. Select the Country / Region (Good to select nearby where most of the consumer will reside and make the service also nearby the Country / Region selected).
3. Make sure the Subscription selected is correct or select the correct one from the drop down list.
4. Press the Create Namespace button.

The portal will create the namespace and list under the subscription selected. Initially the namespace status will be Activating… for some time and then will become Active.

Step 5: Select the namespace created, you can see properties panel in the right hand side. Press the View button under the Default Key heading from the properties.

The portal pops up a Default Key window with two values Default Issuer and Default Key. These two values are important to expose our service to cloud. So press the Copy to Clipboard button to copy to clipboard and save somewhere temporarily.

Note: When pressing Copy to Clipboard button, the system might popup Silverlight alert. You can press Yes to copy it to clip board.

Keep in mind

1. Only one on-premise service can listen on a particular service bus endpoint address. (except NetEventRelayBinding, which is designed to listen multiple services)
2. When attempting to use same address for multiple services, the first service only will take place. The remaining services will fail.
3. An endpoint can use part of other endpoint, where as it can’t completely use other endpoint address.
   
   For Ex: When an endpoint defined as https://ComDotnetTwitterSOP.servicebus.windows.net/Http/SalesInvoiceReport/Test/V0100 which can’t used completely by other service bus endpoint.
   
   So defining https://ComDotnetTwitterSOP.servicebus.windows.net/Http/SalesInvoiceReport/Test/V0100/01012012 endpoint is wrong.
   
   But below is accepted. https://ComDotnetTwitterSOP.servicebus.windows.net/Http/SalesInvoiceReport/Test/V0102
   
   So it is clearly indicate that, once we exposed a service with one service bus endpoint we can't expose any other services using the base URI as previously exposed. It means, once I exposed a service with https://ComDotnetTwitterSOP.servicebus.windows.net then I can't expose another service with https://ComDotnetTwitterSOP.servicebus.windows.net/Http/SalesInvoiceReport/Test/V0102. So be careful while deciding service bus endpoints.
   
   For more information, please refer - http://windowsazurecat.com/2011/05/appfabric-service-bus-things-you-should-know-part-1-of-3-naming-your-endpoints/
   

The other links on Implementing Azure AppFabric Service Bus:

1. Implementing Azure AppFabric Service Bus - Part 1
2. Implementing Azure AppFabric Service Bus - Part 2
3. Implementing Azure AppFabric Service Bus - Part 3
4. Implementing Azure AppFabric Service Bus - Part 4
5. Implementing Azure AppFabric Service Bus - Part 5