Azure Service Bus – Intro to Eventing in the App Fabric – Project Weather Cloud

This blog post is connected to others that are currently being written. I’ve talked about the Service Bus previously this month and now I want to build an application from the ground up.

See my previous entry at:

• http://blogs.msdn.com/brunoterkaly/archive/2009/12/26/the-holy-grail-of-connecting-applications-net-services-bus-in-windows-azure.aspx

The goal of this post is to teach you about eventing with the AppFabric Service Bus. Eventing is important because there are many engineering where you need:

1. Geographically disbursed publishers of data as well as listeners for new data
2. The ability to expose an arbitrary and scalable amount of services in the cloud
3. Many-to-many scenarios of publishers and listeners
4. Authorization and Authentication built it

I tried to think of what would be interesting to implement using the eventing pattern.

In order to implement binding in the AppFabric Service Bus, you need to use NetTcpRelayBinding. There are a variety of bindings listed below, but we will focus on NetTcpRelay Binding.

Interesting Facts about NetTcpRelayBinding

• It is secure, reliable binding suitable for cross-machine communication
• By default it uses transport security, TCP for message delivery
• It uses binary message encoding which reduces bandwidth between 20-30%
• It is the choice for communication across the Intranet (limited to Service Bus to Service Bus)
• Used only with Service Bus to Service Bus communication
• You have to opt in for additional features
• The additional features include WS-* specifications
• Faster than typical HTTP Bindings
• Services that use NetTcpRelayBinding register their endpoints on the AppFabric Service Bus  using the "sb" URI scheme

There is a big list of bindings to choose from.

• BasicHttpRelayBinding
• WebHttpRelayBinding
• WSHttpRelayBinding
• WS2007HttpRelayBinding
• WSHttpRelayContextBinding
• WS2007HttpRelayFederationBinding
• NetTcpRelayBinding
• NetTcpRelayContextBinding
• NetOnewayRelayBinding
• NetEventRelayBinding (the one we are now doing)

We are not going to worry about all the options right now. We’ll focus on NetEventRelayBinding.

Contract Based Programming

Any time you program with the AppFabric Service Bus (AFSB), you think in terms of contracts, or more specifically, Interface-based programming. Interfaces frees consumes of APIs worrying about how code is implemented. You don’t really think in terms of objects but more in terms of abstract services.

What this blog entry will cover

• Step 1 – Creating the starting structure
• Step 2 – Going to the Azure Portal and configuring your services

Step 1 – Creating the starting structure

The next big task is to worry about the building the starting structure. This will help us just start thinking about architecture a bit.

Step 2 – Go to the Azure Service Bus Portal and Setup some endpoints to code against

We will now connect to the portal and access AppFabric Service Bus configuration screens.

Video Link for Step 1 – Starting Folder Structures

As we move forward the purpose of each folder will become apparent.

Figure 1 – Finished Product

Figure 2 – Adding a blank solution

Figure 3 – Choosing the right project type

Figure 4 – The final folders

Figure 1 : What the finished project should look like Figure 2 : How to add a blank solution   Figure 3 : How to add Solution Folders   Figure 4 : Folders are in place within the solution

Adding Contracts

Contracts, also known as Interfaces, will be needed to implement our solution. They allow clients to communicate with services using an agreed up list of methods. We will add two interfaces. IReportWeatherContract will be used by WeatherStations to report weather. You will also need to add IWeatherCentralContract so that WeatherCentral can bubble up new weather events from the WeatherStations to the WeatherBillboards.

Figure 5: Adding Interfaces (aka Contracts)

Two Interfaces have been added

Our solution has a folder named “Contracts.” It is this folder to which we will add a couple of interfaces. The two interfaces are:

• IReportWeatherContract
• IWeatherCentralContract

Figure 6: What the two interface files look like 

Before we add code to these contracts, we need to add a reference. We will add System.ServiceModel as the reference.

Figure 7 : Add a reference to System.ServiceModel

IReportWeatherContract.cs includes two interfaces: (1) IReportWeatherContract; (2)IClientChannel.

Figure 8 : The two key interfaces used by weatherstations to report weather

Why do we need IClientChannel?

It is useful because it defines the behavior of outbound request and request/reply channels used by client applications.

The IClientChannel type exposes a number of member functions that you would expect. Here are some of the capability of the methods:

• The ability to asynchronously open a communication object
  • There are many communication objects:
    • Channels and Channel Managers
    • Factories
    • Listeners
    • Dispatchers
    • Service Hosts
• The ability to asynchronously get credential information
• Some properties include:
  • Input session
  • Local address of the channel
  • Timeout before exceptions are thrown
  • SessionId (useful for message logging)
    • This is just a unique id that represents a client. Similar to ASP.NET.
    • Sessions begin when a client opens a new session-aware channel. It ends when the client closes the channel.
    • Session aware interfaces have the line:
      • [ServiceContract(SessionMode=SessionMode.required)]
  • Via is the URI that has the transport address to which messages are sent on the client channel
• Some Events include:
  • Closed, Closing, Opened, Opening

Who will use IReportWeatherContract?

The contract will be used by Weather Stations to report the weather.

Figure 9 : What a client weather station will use to report the weather 

Weather Stations in the field using the IReportWeatherContract

The code below demonstrates the use of the IReportWeatherChannel object, which we defined in figure 8. We don’t need to worry about the code below yet. We haven’t built the weather station code yet. Coming soon, however.

Figure 10 : How a weather station will use IReportWeatherChannel

Figure 11 : How WeatherStations connect to the cloud

Note: More explained in the next blog entry

Let’s Summarize the Code

The end of this blog is about finishing the contracts. The code for both of these contracts can be found below.

Figure 12 : The two contracts you should have done 

Figure 13 : The code for IReportWeatherContract.cs

Figure 14 : The code for IWeatherCentralContract.cs

The ServiceContractAttribute Class indicates that an interface or a class defines a service contract in a Windows Communication Foundation (WCF) application. It is an important part of exposing endpoints to client applications.

A service contract is used on the service side to specify what the service’s endpoint exposes to callers. It is also used on the client side to specify the contract of the endpoint with which the client communicates and, in the case of duplex contracts, to specify the callback contract (using the CallbackContract property) that the client must implement in order to participate in a duplex conversation.

The OperationContract attribute declares that a method is an operation in a service contract. Only methods attributed with the OperationContractAttribute are exposed as service operations. A service contract without any methods marked with the OperationContractAttribute exposes no operations.

Finally, here is the Source Code for Project Weather Cloud for the whole project, to this point.