AppFabric Apps (June 2011 CTP)–Only 1 SQL Azure Instance at a time

September 10, 2011 1 comment

I must have missed it in the release notes but when you have access to the AppFabric Apps CTP, you are only allowed on SQL Azure instance within this Labs environment.  When you first log into the Portal you will see a SQL Azure DB that has a name of LabsSqlDatabase.  The problem is that you can’t actually create another one here and if you do try to access this database you will not be able to connect to it using the Database Name LabsSqlDatabase.

image

What is a little confusing is when you are working within your Local Dev Fabric that you can specify any name you want in your SQL Azure cofig for your DatabaseName.  The problem is this name will not exist in the cloud if you want to access it after you have published your AppFabric Application.

image

The error message that you will receive will resemble the following:

image

So due to this current limitation (it is CTP  – I am ok with it), you need to use the database that was provisioned for you when you were granted access to the CTP Labs enviornment.  To do this you will need to get your connection string from the Labs Portal by clicking on LabsSqlDatabase then click on the View button below the Connection String label.  A dialog box will appear and you can copy your connection string by clicking the Copy to Clipboard button.

image

If we paste this value in notepad we will discover the following connection string.  The Data Source represents the name of the server (s) that our database will be running on.  Next we have an Initial Catalog value which is the actual name of our database that has been provisioned for us….not LabsSqlDatabase.  In my case, and I would imagine others, my Initial Catalog value is the same as my user id.  If have blacked out portions of these values for privacy reasons.image

If I now try to connect to this database either through SQL Management Studio or Database Manager Portal, using this initial catalog value for my Database Name,  I will have success.

image

At this point we are free to run any of our SQL scripts to generate tables, stored procedures or load data.

Conclusion

I hope this post will save some others some time as it did create some confusion for me.  Admittedly I sometimes dive right into things instead of thoroughly reviewing the documentation (what fun is that).  From what I gather, it is possible to hook up an AppFabric Application to an existing SQL Azure database that exists in the NON-LABS environment.  So if you really need to create multiple SQL Azure databases that is also an option.  Since I am just playing around with this stuff having a single SQL Azure instance works for me now that I understand the limitations of the Labs environment.

Categories: AppFabric, Azure, SQL Azure

AppFabric Apps (June 2011 CTP) Accessing AppFabric Queue via REST

August 13, 2011 1 comment

I recently watched an episode of AppFabric TV where they were discussing the REST API for Azure AppFabric.  I thought the ability to access the AppFabric Service Bus, and therefore other Azure AppFabric services like Queues, Topics and Subscriptions via REST was a pretty compelling scenario.  For example, if we take a look at the “Power Outage” scenario that I have been using to demonstrate some of the features of AppFabric Applications, it means that we can create a Windows Phone 7 (or Windows Phone 7.1/Mango Beta) application and dump messages into an AppFabric Queue securely via the AppFabric Service Bus.  Currently, the Windows Phone SDK does not allow for the managed, Service Bus bindings to be loaded on the phone so using the REST based API over HTTP is a viable option.

Below is a diagram that illustrates the solution that we are about to build.  We will have a Windows Phone 7.1 app that will push messages to an Azure AppFabric Queue.  (You will soon discover that I am not a Windows Phone developer.  If you were expecting to see some whiz bang new Mango features then this post is not for you.) 

The purpose of the mobile is to submit power outage information to an AppFabric Queue.  But before we can do this we need to retrieve a token from the Access Control Service and include this token in our AppFabric Queue message Header.  Once the message is in the Queue,  we will once again use a Code Service to retrieve messages that we will then insert into a SQL Azure table.

image

 

Building our Mobile Solution

One of the benefits of using AppFabric queues is the loose coupling between publishers and subscribers.  With this in mind, we can proceed with building a Windows Phone 7 application in its own solution.  For the purpose of this blog post I am going to use the latest mango beta sdk bits which are available here.

image

Since I have downloaded the latest 7.1 bits, I am going to target this phone version.

image

 

On our WP7 Canvas we are going to add a few controls:

  • TextBlock called lblAddress that has a Text property of Address
  • TextBox called txtAddress that has an empty Text Property
  • Button called btnSubmit that has a Content property of Submit
  • TextBlock called lblStatus that has an empty Text Property

image

 

Within the btnSubmit_Click event we are going to place our code that will communicate with the Access Control Service.

private void btnSubmit_Click(object sender, RoutedEventArgs e)
     {

         //Build ACS and Service Bus Addresses
         string acsAddress = https + serviceNameSpace + acsSuffix ;
         string relyingPartyAddress = http + serviceNameSpace + serviceBusSuffix;
         string serviceAddress = https + serviceNameSpace + serviceBusSuffix;

         //Formulate Query String
         string postData = "wrap_scope=" + Uri.EscapeDataString(relyingPartyAddress) +
             "&wrap_name=" + Uri.EscapeDataString(issuerName) +
             "&wrap_password=" + Uri.EscapeDataString(issuerKey);
        
     
         WebClient acsWebClient = new WebClient();
        
         //Since Web/Http calls are all async in WP7, we need to register and event handler
         acsWebClient.UploadStringCompleted += new UploadStringCompletedEventHandler(acsWebClient_UploadStringCompleted);

         //instantiate Uri object with our acs URL so that we can provide in remote method call
         Uri acsUri = new Uri(acsAddress);
        
         acsWebClient.UploadStringAsync(acsUri,"POST",postData); 

}

 

Since we are making an Asynchronous call to the ACS service, we need to implement  the   handling of the response from the ACS Service.

private void acsWebClient_UploadStringCompleted(object sender, UploadStringCompletedEventArgs e)
    {
        if (e.Error != null)
        {
            lblStatus.Text = "Error communicating with ACS";
        }
        else
        {
            //store response since we will need to pull ACS token from it
            string response = e.Result;

            //update WP7 UI with status update
            lblStatus.Text = "Received positive response from ACS";
           
            //Sleep just for visual purposes
            System.Threading.Thread.Sleep(250);

            //parsing the ACS token from response
            string[] tokenVariables = response.Split(‘&’);
            string[] tokenVariable = tokenVariables[0].Split(‘=’);
            string authorizationToken = Uri.UnescapeDataString(tokenVariable[1]);

          
           //Creating our Web client that will use to populate the Queue
            WebClient queueClient = new WebClient();

            //add our authorization token to our header
            queueClient.Headers["Authorization"] = "WRAP access_token=\"" + authorizationToken +"\"";
            queueClient.Headers[HttpRequestHeader.ContentType] = "text/plain";

            //capture textbox data
            string messageBody = txtAddress.Text;
          
            //assemble our queue address
            //For example: "
https://MyNameSpace.servicebus.appfabriclabs.com/MyQueueName/Messages"
            string sendAddress = https + serviceNameSpace + serviceBusSuffix + queueName + messages;

            //Register event handler
            queueClient.UploadStringCompleted += new UploadStringCompletedEventHandler(queueClient_UploadStringCompleted);

            Uri queueUri = new Uri(sendAddress);
            //Call method to populate queue
            queueClient.UploadStringAsync(queueUri, "POST", messageBody);
        }

       

    }

So at this point we have made a successful request to ACS and received a response that included our token.  We then registered an event handler as we will call the AppFabric Service Bus Queue using an Asynchronous call.  Finally we made a call to our Service Bus Queue.

We now need to process the response coming back from the AppFabric Service Bus Queue.

private void queueClient_UploadStringCompleted(object sender, UploadStringCompletedEventArgs e)
{
    //Update status to user.
    if (e.Error != null)
    {
        lblStatus.Text = "Error sending message to Queue";
    }
    else
    {
         lblStatus.Text = "Message successfully sent to Queue";
    }
}

 

That concludes the code that is required to submit a message securely to the AppFabric Service Bus Queue using the Access Control Service to authenticate our request.

Building our Azure AppFabric Application

The first artifact that we are going to build is the AppFabric Service Bus Queue called QueueMobile.

image_thumb2[1]

Much like we have done in previous posts we need to provide an IssuerKey, IssuerName and Uri.

image_thumb4

The next artifact that we need add is a SQL Azure Database.

image26_thumb

Adding this artifact is only the beginning.  We still need to create our local database in our SQL Express instance.  So what I have done is manually created a Database called PowerOutage and a Table called Outages.

image_thumb6

Within this table I have two very simple columns: ID and Address.

image_thumb10

So the next question is how do I connect to this database.  If you navigate to the AppFabric Applications Manager which is found within the AppFabric Labs portal, we will see that a SQL Azure DB has been provisioned for us.

image_thumb12

Part of this configuration includes our connection string for this Database.  We can access this connection string by clicking on the View button that is part of the Connection String panel.

image_thumb13

I have covered up some of the core credential details that are part of my connection string for security reasons.  What I have decided to do though to make things a little more consistent is created a SQL Server account that has these same credentials in my local SQL Express.  This way when I provision to the cloud I only need to change my Data Source.

image_thumb17

For the time being I am only interested my local development fabric so I need to update my connections string to use my local SQL Express version of the database.

 

image_thumb19

With our Queue and Database now created and configured, we need to focus on our Code Service.  The purpose of this Code Service is to retrieve messages from our AppFabric Queue and insert them into our SQL Azure table.  We will call this Code Service CodeMobileQueue and then will click the OK button to proceed.

image17_thumb

We now need to add references from our Code Service to both our AppFabric Queue and our SQL Azure Instance.  I always like to rename my references so that they have meaningful names.

image_thumb5

Inside our Code Service, It is now time to start focusing on the plumbing of our solutions We need to be able to retrieve messages from the AppFabric Queue and insert them into our SQL Azure table.

public void Run(CancellationToken cancelToken)
      {
        
           //Create reference to our Queue CLient
            QueueClient qClient = ServiceReferences.CreateQueueMobile();
          
          //Create reference to our SQL Azure Connection
            SqlConnection sConn =  ServiceReferences.CreateSqlQueueMobile();
            MessageReceiver mr = qClient.CreateReceiver();
            BrokeredMessage bm;
            
           Stream qStream;
           StreamReader sReader;
           string address;

            System.Diagnostics.Trace.TraceInformation("Entering Queue Retrieval " + System.DateTime.Now.ToString());

            while (!cancelToken.IsCancellationRequested)
            {
                //Open Connection to the database
                sConn.Open();
              
                while (mr.TryReceive(new TimeSpan(hours: 0, minutes: 30, seconds: 0), out bm))
                {

                    try
                    {
                        //Note: we are using a Stream here instead of a String like in other examples
                        //the reason for this is that did not put the message on the wire using a
                        //BrokeredMessage(Binary Format) like in other examples.  We just put on raw text.
                        //The way to get around this is to use a Stream and then a StreamReader to pull the text out as a String
                        qStream = bm.GetBody<Stream>();
                        sReader = new StreamReader(qStream);
                        address = sReader.ReadToEnd();

                        //remove message from the Queue
                        bm.Complete();

                        System.Diagnostics.Trace.TraceInformation(string.Format("Message received: ID= {0}, Body= {1}", bm.MessageId, address));

                       //Insert Message from Queue and add it to a Database
                        SqlCommand cmd = sConn.CreateCommand();
                        cmd.Parameters.Add(new SqlParameter("@ID", SqlDbType.NVarChar));
                        cmd.Parameters["@ID"].Value = bm.MessageId;
                        cmd.Parameters.Add(new SqlParameter("@Address", SqlDbType.NVarChar));
                        cmd.Parameters["@Address"].Value = address;
                        cmd.CommandText = "Insert into Outages(ID,Address) Values (@ID,@Address)";
                        cmd.CommandType = CommandType.Text;
                        cmd.ExecuteNonQuery();
                        System.Diagnostics.Trace.TraceInformation("Record inserted into Database");
                    }
                    catch (Exception ex)
                    {
                        System.Diagnostics.Trace.TraceError("error occurred " + ex.ToString()); 
                    }
                }

                // Add your code here
                Thread.Sleep(5 * 1000);
            }

            mr.Close();
            qClient.Close();
            sConn.Dispose();

         
      }

Testing Application

We are done with all the coding and configuration for our solution.  Once again I am going to run this application in the local Dev Fabric so I am going to go ahead and type CRTL + F5.  Once my Windows Azure Emulator has been started and our application has been deployed we can start our Windows Phone Project.

For the purpose of this blog post we are going to run our Windows Mobile solution in the provided emulator.  However, I have verified the application can be side-loaded on a WP7 device and the application does work properly.

We are now going to populate our Address text box with a value.  In this case I am going to provide 1 Microsoft Way  and click the Submit button.

image_thumb[1]

Once we click the Submit button we can expect our first status message update indicating that we have received a positive response from ACS.

image_thumb[5]

The next update we will have displayed is one that indicates our message has been successfully sent to our AppFabric Queue.

image_thumb[3]

As outlined previously, our WP7 app will publish message to our AppFabric Queue, from there we will have our Code Service de-queue the message and then insert our record into a SQL Azure table.  So if we check our Outages table we will discover that a record has been added to our Database.

 

image_thumb[7]

 

Conclusion

Overall I am pretty please with how this demo turned out.  I really like the ability to have a loosely coupled interface that a Mobile client can utilize.  What is also nice about using a RESTful interface is that we have a lot of flexibility when porting a solution like this over to other platforms.

Another aspect of this solution that I like is having a durable Queue in the cloud.  In this solution we had a code service de-queuing this message in the cloud.  However, I could also have some code written that is living on-premise that could retrieve these messages from the cloud and then send them to an LOB system like SAP.  Should we have a planned, or unplanned system outage on-premise, I know that all mobile clients can still talk to the Queue in the cloud.

Categories: AppFabric, Azure, Queue Tags: ,

AppFabric Apps (June 2011 CTP) Simple Service Bus Topics–Part 2

July 31, 2011 Leave a comment

(…Continued from Part 1, if you have not read it please do so to understand the context of this post)

Solution

We want customers to be able to submit power outages to our fictitious power company located in the Redmond, Washington area. What is different this time around(from our Queue scenario) is that due to the growth in the Kirkland, Washington area we have subcontracted power line maintenance to another company. So we want our Redmond system to receive messages for the Redmond area and this other company to receive messages for Kirkland. The Redmond company should not see the Kirkland messages and vice versa.

Configuring Core Artifacts

The user interface for this application will once again be an ASP.Net Web Application.  We will add this Web Application by clicking on the Add New Service label which is found on the AppFabric Design View Canvas.

image

Next, we will want to provide an appropriate name for this Web App and click on the OK button.

image

We now need to create a Service Bus Topic and can do this by once again clicking on the Add New Service label which is found on the AppFabric Design View Canvas.

image

Much like we have had to do with other Service Bus artifacts, we need to provide our Service Bus IssuerKey, IssuerName and Uri.  For my URI, I have provided the following value:

sb://<your_namespace>.servicebus.appfabriclabs.com/SimpleServiceBusTopic

image

Note: Notice the RequiresProvisioning property which is set to True.  When we deploy our AppFabric application the provisioning of our Topic will be taken care of without any additional work from our side. When we shutdown the Azure Compute Emulator, this Topic will be removed.

In many of the May AppFabric CTP examples out there people handle provisioning tasks by using the ServiceBusNamespaceClient  class.  No where in this code will we be directly using this class.  I would imagine that under the hood, the provisioning code is using this class.

Next, our Web application we need to add a reference to this newly created Topic.

image

I like to rename my references to provide a more descriptive title than the default Import1 value.

image

 

With our topic now setup we want to add two subscriptions.  The first subscription will be for our Redmond messages and the second subscription will be for our Kirkland subscription.

Redmondimage

 

Kirkland

image

 

For each of these Subscriptions we need to once again provide  IssuerKey, IssuerName and Uri propertiesThe Uri property for subscriptions provides an interesting twist. The actual word “subscriptions” must be included between the name of your Topic and Subscription. The convention for these Uri are:

sb://your_namespace.servicebus.appfabriclabs.com/TopicName/subscriptions/SubscriptionName

 

image

 

Much like in the Queue Blog Post we are going to use a Code Service to retrieve messages from our Topic via a Subscription.  We need once again click on the Add New Service label and select Code.

image

 

This Code Service will represent the Redmond Client and therefore we need to add a reference to the SimpleServiceBusSubscriptionRedmond Subscription.

image

 

The underlying core of our application should be set and we should be able to build our application.  If we look at the AppFabric Design View Canvas we should see the following:

image

Our Diagram View should look like this:

image

 

Update Web Application

At this point we have simply configured all of the artifacts that are required in our solution but we have not written any code so our application will not be very functional.  In the Source view of the Default.aspx  page we want to add a few controls:

  • Text Box for our Address
  • Text Box for our City
  • Button used to submit our form

 

image

In the code behind for Default.aspx we will want to add an event handler for the Button clicked event.

protected void btnSubmit_Click(object sender, EventArgs e)
{     
    TopicClient tc = ServiceReferences.CreateSimpleServiceBusTopic();

    MessageSender ms = tc.CreateSender();

    BrokeredMessage bm = BrokeredMessage.CreateMessage(txtAddress.Text);
    bm.Properties["OutageCity"] = txtCity.Text;

    ms.Send(bm);

    txtAddress.Text = “”;
    txtCity.Text = “”;

}

Some lines of significance include:

TopicClient tc = ServiceReferences.CreateSimpleServiceBusTopic(); where we are creating an instance of our TopicClient.

The BrokeredMessage instantiation line includes our message body which is our address that is coming from our Address text box.

BrokeredMessage bm = BrokeredMessage.CreateMessage(txtAddress.Text);

 

You may also notice where we assign our City value to a property called OutageCity.  This property is kinda like a BizTalk Context property.  We are going to be able to route our message based upon this value.  We will later use this property when creating a Subscription Filter.

bm.Properties["OutageCity"] = txtCity.Text;

Note: this code looks a little different than the May AppFabic CTP code that you have seen.  In the May CTP we had to worry about our Service Bus configuration for our namespace, Issuer owner and key.  We also had to create an instance of  a MessagingFactory object so that we could create a Topic Client.  I like the AppFabric Application approach better.  It is a little cleaner and all of our configuration info is handled in our Application model.

 

Update Code Service

We now need to update our Run method that exists within our Code Service.  As discussed in the Queue blog post, this method will continue to run until a cancellation request is received.  The purpose of this method is to retrieve messages from our Topic via our Redmond Subscription.

For the purpose of this demonstration we are simply going to log messages that have been retrieved  in our Trace viewer.

public void Run(CancellationToken cancelToken)
       {

           System.Diagnostics.Trace.TraceInformation(“Entering Code Service Loop”);

           while (!cancelToken.IsCancellationRequested)
           {

               SubscriptionClient subClient = ServiceReferences.CreateSimpleServiceBusSubscription();
               subClient.MessagingFactory.CreateSubscriptionClient(“SimpleServiceBusTopic”, “SimpleServiceBusSubscriptionRedmond”);

               MessageReceiver mr = subClient.CreateReceiver();
               BrokeredMessage bm;

               while (mr.TryReceive(new TimeSpan(hours: 0, minutes: 0, seconds: 5), out bm))
               {
                   System.Diagnostics.Trace.TraceInformation(string.Format(“Message received: ID=   {0}, Body= {1}”, bm.MessageId, bm.GetBody<string>()));
                   bm.Complete();
               }

               // Add your code here
               Thread.Sleep(5 * 1000);

           }
       }

Some lines of significance include:

Our line where we create a subscription client that will include the name of our Topic and our Subscription.

subClient.MessagingFactory.CreateSubscriptionClient(“SimpleServiceBusTopic”, “SimpleServiceBusSubscriptionRedmond”);

The next line is our while loop that will attempt to retrieve messages from this subscription.  If a message is retrieved it will be stored in a BrokeredMessage.

while (mr.TryReceive(new TimeSpan(hours: 0, minutes: 5, seconds: 0), out bm))

Creating a Kirkland client

Our Kirkland client is going to follow a different path than our Redmond client.  At this point everything that we have built exists in the Azure Cloud.  For our Kirkland client, it is going to reside on-premise.  Since our Topics and Subscriptions are provisioned in the cloud we can access them from within the cloud and on-premise.

For this example we will follow the path that many of the May CTP examples took.  It is a console application that is in a separate solution from this AppFabric Application.  In this application I have added references manually to the ServiceBus CTP assemblies.

 

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.ServiceBus;
using Microsoft.ServiceBus.Messaging;
using Microsoft.ServiceBus.Description;

namespace SimpleTopicOnPrem
{
    class Program
    {
        static void Main(string[] args)
        {

            Uri sbURI = ServiceBusEnvironment.CreateServiceUri(“sb”, “<your_namespace>”, string.Empty);
            string name = “owner”;
            string key = “<your_key>”;

          

            MessagingFactory factory = MessagingFactory.Create(sbURI, TransportClientCredentialBase.CreateSharedSecretCredential(name, key));

            SubscriptionClient subClient = factory.CreateSubscriptionClient(“SimpleServiceBusTopic”, “SimpleServiceBusSubscriptionKirkland”);

            //Next we create the MessageReceiver and receive a message.

            MessageReceiver mr = subClient.CreateReceiver();

            BrokeredMessage bm;

            while (mr.TryReceive(new TimeSpan(hours: 0, minutes: 5, seconds: 0), out bm))
            {
                Console.WriteLine(string.Format(“Message received: ID= {0}, Body= {1}”, bm.MessageId, bm.GetBody<string>()));
                bm.Complete();
            }

            Console.WriteLine(“Done Reading From Queue”);
            Console.Read();
        }
    }
}

 

This code looks pretty similar to our Code Service with the exception of how we create a SubscriptionClient and that we need to deal with our credentials and URI in the application.

 

Testing the application

For the purpose of this blog post we are going to keep our AppFabric application in our Development Fabric.  We can provision and deploy our application by typing CRTL + F5.  We should see our web application launch.

Next we will want to start an instance of our Kirkland On Premise client by typing F5.  This means that both of our applications are up and running and ready to receive messages.

Since we have not added any filters on our Subscriptions both applications should receive a copy of any message that we submit. 

 

The first message that we will send will have an Address of Space Needle and a City of Seattle.

image

 

In our Trace logs and in our Console application we will discover that our message has been received by both clients.

image

 

At this point we have proved that our initial deployment has been successful and that we can broadcast this message to multiple clients.  But, this is not the end state that we desire.  Remember we want the Redmond client to only receive the Redmond messages and the Kirkland client to only receive the Kirkland messages.  In order to accomplish this behavior we need to add Subscription rules.

Unless I have missed something(and please let me know if I have), there is no way to specify our filter when we create our Subscription through the AppFabric Design Canvas.  The only way that I have seen how to do this is through code by using the ServiceBusNamespaceClient class.  So I could have written this code but opted for a different option.  The AppFabric Cat team recently released a tool called the Service Bus Explorer.  Within this tool, you can provide your credentials and then interrogate your Queues, Topics and Subscriptions.  You can read all about this tool and some more detailed information on their blog post.

Once I have connected to my namespace using the Service Bus Explorer, I want to navigate to my Redmond subscription and then delete the existing rule.  Basically this rule is saying that any messages should be retrieved using this subscription.

image

I then want to right mouse click on the Redmond Subscription and Add Rule.  I now need to provide a name for this rule (it can be anything) and a SQL Filter Expression.  In this case I am providing OutageCity=’Redmond’.

image

With my Subscription rule established for my Redmond Subscription lets submit another message.  This time we will provide an Address of 1 Microsoft Way and a City of Redmond.

image

 

So notice that both clients received this message.  The reason for this is that this message did match the Subscription rule (filter) for the Redmond Client.  Since we have not configured a Subscription rule (filter) for our Kirkland client it is still configured to receive all messages.

image

To prove that the Redmond Subscription is working, lets send in a message that will not match the Redmond rule.  This time only the Kirkland application should receive it if we make the city equal to Bellevue.

image

 

We will discover that the Subscription rule is working.  Our Redmond client did not receive this Bellevue message but our Kirkland client did since its Subscription rule is wide open.

image

So let’s create a Subscription rule for our Kirkland client.  We will head back to the Service Bus Explorer tool to do this.

Once again we will delete the Default Rule, this time for the Kirkland Subscription.  We will add a new Rule by right mouse clicking on the Kirkland Subscription and selecting Add Rule.  We will provide this rule with a Name of Kirkland and a SQL Filter Expression of OutageCity=’Kirkland’.

image

With our Subscription rule now in place, lets send in a message that only our Kirkland client will receive. 

 

image

Sure enough, our Redmond client did not receive a copy of this message since its Subscription rule didn’t match.  Our Kirkland client did receive this message since it did match our Subscription rule

image

 

Closing Notes:

  • You will lose any of these Subscription rules between deployments.  When you shutdown the Dev Fabric emulator, your Topic and Subscriptions will be removed.  When you deploy your application to the Local Dev fabric your Topic and Subscriptions will be deployed but your rules/filters will not return unless you configure them again.
  • Topics will push messages to Subscriptions no matter the Rule that you have in place.  But, clients will only retrieve messages that match the Subscription rule(s).
  • You can have multiple Subscription rules per Subscription.
  • It would be nice if we can provide our Subscription rules in our AppFabric Design view canvas.  This way they could be deployed with our Topic and Subscription(s).
  • Publishers instantiate TopicClient instances, Consumers instantiate Subscription Client instances.
  • Overall the technology is pretty cool.  Having true pub/sub in the cloud should open up many opportunities for organizations.
Categories: AppFabric, Azure, Queue

AppFabric Apps (June 2011 CTP) Simple Service Bus Topics–Part 1

July 31, 2011 2 comments

In my last post we discussed using Azure AppFabric Queues as part of Azure AppFabric Applications.  In this post, we will discuss a couple of related Queue technologies called Topics and Subscriptions.  The purpose of this post will be to describe the conceptual behavior of Topics and Subscriptions and then in a follow up post actually dive into a detailed example of how we can use this technology. 

What is a Topic?

A Topic is much like a Queue in some ways.  It is a durable storage container that allows consuming clients to retrieve messages from.  Data within a Queue can be consumed by a single client.  Data within a topic can be consumed by multiple clients through an AppFabric Subscription.

What is a Subscription?

A Subscription is probably exactly what you think it is.  It is a client requesting a copy of a particular message that has been published to a Topic.  Subscriptions by default include all messages for a particular subscription but we can also specify a SQL 92 query which essentially allows us to “filter” messages that we are interested in.

Topics + Subscriptions = Pub/Sub

The combination of Topics and Subscriptions really allow for Pub/Sub in the cloud.  It provides the ability for a publisher to put a message in the cloud then have consuming client(s)  retrieve messages that are relevant.  When a publisher sends a message to the cloud, it is really sending it to a Topic and when a consuming client retrieves a message it is doing so through a Subscription.

Why is this important?

In my opinion, I think this is pretty cool technology.  Internet Pub/Sub messaging is something that is a relatively new concept in the Microsoft Stack.  The idea that you can perform this pub/sub in the cloud provides some unique opportunities in both Business to Business and Business to Consumer scenarios.  With Business to Business scenarios dealing with network firewalls to allow for communication to occur(between organizations) is usually not a fun adventure.   Also, providing the ability to scale usually provides challenges as well.  On the Business to Consumer side, our Topic messages are stored in a durable store and therefore support disconnected client scenarios provided we mark messages with a suitable time to live (TTL) parameter.

Example

In the previous Queue post we had an example of a Power Outage application that allows customers with a power outage to report it through a mobile phone browser.  That example works great if we have a single consumer, but what if we have multiple consumers?  Enter Topics and Subscriptions.

This scenario is very similar.  We want customers to be able to submit power outages to our fictitious power company located in the Redmond, Washington area.  What is different this time around is that due to the growth in the Kirkland, Washington area we have subcontracted power line maintenance to another company.  So we want our Redmond system to receive messages for the Redmond area and this other company to receive messages for Kirkland.  The Redmond company should not see the Kirkland messages and vice versa.

To support this solution, we will create 1 Topic.  The Web application will submit messages to this Topic.  We will also register 2 Subscriptions on this topic and provide a filter expression that will ensure that our Redmond client receives messages for Redmond and a filter expression that ensures our Kirkland client receives messages for Kirkland.

image

 

Please see post 2 that will provide a step by step implementation of this solution.

Categories: AppFabric, Azure, Queue Tags: ,

AppFabric Apps (June 2011 CTP) Simple Service Bus Queue App

July 24, 2011 5 comments

In this post we are going to be discussing a simple app and how this app can communicate with a Service Bus Queue.

Service Bus Queues and Topics(will save this for a future post) were introduced in the May 2011 Service Bus CTP.  While Queuing is far from a new topic, the idea of providing a durable Queue in the cloud is a relatively new topic.

Why Queues?

Queues offer a few benefits in the areas of:

  • Throttling messages to downstream systems.  Some downstream applications may not be able to handle load during burst scenarios so we have an intermediary that can basically store this information in the interim while the downstream system can process the messages at their leisure.  Having the elasticity of the cloud, this becomes a compelling solution knowing that the cloud can scale during burst scenarios even if a client application cannot.
  • Disconnected client scenarios.  A producer may be publishing messages based upon specific events occurring in its system.  In a point-to-point integration scenario, the producer is expecting the consumer to be online so that the consumer can process this message.  The problem with this is that you cannot expect consuming systems to always be available. This becomes extremely relevant in mobile scenarios where people may lose Cellular connectivity.  It also becomes relevant when integrating with trading partners.  Since you cannot control what is happening with the 3rd party system, it is nice to know that you can fulfill your responsibilities and deliver a message to a durable store instead of constantly retrying the messages to the client that’s system is not available.
  • Distribution of workload/Load balancing. We can also use a queue as a central point or “collection” for messages and then use multiple clients pulling data from this queue in a round robin type fashion to distribute the load across multiple worker processes.

Now that we have introduced Queues, lets walk through implementing a simple Queue solution using an AppFabric Application.  The premise behind this simple application is we are running a power company and we want our customers to be able to tell us about power outages using their Mobile Phones.  No we are not going to build a Mobile Phone app, but for this fictitious scenario we will have them fill out a simple web page that they can access from their phone.

When creating a new Visual Studio solution, we want to make sure that we have selected an AppFabric Application

 

image

 

Once in our AppFabric Application we are going to have a blank Design View Canvas.  The first service that we want to add is a ASP.Net Web App.  To do this we will click on the Add New Service label.

image

Then we want to select ASP.Net.

image

 

We now want to add our actual Service Bus Queue

image

With our Web App and Service Bus Queue created, we now want to add a reference from our Web App to our Service Bus Queue.  We can do so by clicking on the Service References Dropdown and selecting the default service called Import1.

image

 

Since a reference called Import1 is not very meaningful we can pull this same drop down and select Import1.  With this value selected we should the property page update and we can rename this value to something more appropriate.

image

With our reference being set, we can jump into the Web application and add some controls to the Default.aspx page.  We want to add two text boxes and a button that will be used to submit the page.

 

image

In the code behind for the Default.aspx page we want to add an event handler for this submit button.

 

protected void btnSubmit_Click(object sender, EventArgs e)
{
   //Create a Queue Client
    QueueClient qc =  ServiceReferences.CreateSimpleSBQueue();

    //Create Message Sender
    MessageSender ms = qc.CreateSender();

    //Created BrokeredMessage
    BrokeredMessage bm = BrokeredMessage.CreateMessage(txtAddress.Text + " " + txtCity.Text);
 
    //Send Message
    ms.Send(bm);
   
    //Close Message Sender
    ms.Close();

    //Close Queue Client
    qc.Close();

}

 

At this point we have all of the code that we need to populate a Service Bus Queue.  Note that we have not written any code to actually create the queue.  The Queue will be provisioned when we publish and deploy our application to the cloud(or local Dev Fabric).  One item that still remains is the Service Bus Queue requires some configuration information in the form of the URI, issuer key and issuer name.

image

 

Having the ability to write to a Queue is great but not very valuable if we cannot retrieve messages from this queue.  We have a few options when it comes to retrieving messages from this queue.  We could write a quick little console application that will pull messages down in an on-premise scenario.  This console could sit within the boundaries of our corporate firewall(s) and make a connection to this Service Bus queue deployed in the cloud.  Since Alan Smith has covered this scenario in one of his web casts I don’t see much of a point in reproducing his steps here.

Instead, we are going to add another “Service Type” to our AppFabric Application.  This service is called a Code Service.  What is a Code Service?  A Code Service is a background worker process that can be used in polling-like scenarios.  You can kind of think of it like as an endless loop that keeps asking it self “do I have any work to do”?  A good example of using a code service may include sending emails out to customers who have just purchased an item off your website.  While sending the email is important to customers it usually does not have to be sent the second that the order has been processed.  Instead you may decide to send out emails every 10 minutes instead of in real time. 

Another good example of using a code service is to pull messages off of a queue.  Perhaps you want to de-queue a message and then update a database or even call a workflow service.  I will leave deciding what to do with this message once it has been de-queued up to the reader but if you followed an earlier post you know that it is not difficult to route messages to a Workflow service. For the purpose of this post, we are simply going to de-queue this message and then write a Trace event that will prove we have retrieved the message from the queue.

To add a Code Service to our project we need to head back to our Design View canvas and click on the Add Service  label.  From the dialog that will appear, we now want to select Code.

image

Since we want to connect to our Service Bus Queue, we need to add a reference to this service much like we had to do from our Web Application.

 

image

 

In our Code Service that was added to our solution we will see a method called Run that will automatically be executed.  This means that we do not need to invoke this code.

By default, a while loop is included that will execute as long as a cancellation request has not been received.  Also, we will find a Sleep statement that will pause for 5 seconds when this line of code is hit. 

image

Within this Run method we will add our own code to retrieve our messages from the queue.

public void Run(CancellationToken cancelToken)
       {
           //Create Queue Client
           QueueClient qc = ServiceReferences.CreateSimpleSBQueue();

           //Create Message Receiver
           MessageReceiver mr = qc.CreateReceiver();

           //Create Brokered Message
           BrokeredMessage br;

           while (!cancelToken.IsCancellationRequested)
           {
               while (mr.TryReceive(new TimeSpan(hours: 0, minutes: 0, seconds: 5), out br))
               {
                   System.Diagnostics.Trace.TraceInformation(string.Format("Message received: ID= {0}, Body= {1}", br.MessageId, br.GetBody<string>()));
                   br.Complete();
               }

               // Add your code here
               Thread.Sleep(5 * 1000);
           }

           mr.Close();
           qc.Close();
       }

The code itself looks a lot like the code to add messages to a Queue.  However there are a few lines worth mentioning. 

mr.TryReceive(new TimeSpan(hours: 0, minutes: 0, seconds: 5), out br))

The TryReceive method will attempt to retrieve a message from the Queue.  The parameters include a TimeSpan that will determine our server wait time and a reference to a Brokered Message where the message will be stored.

The other notable line is br.Complete();  This method confirms the receipt of the message and provides instructions that the message has been processed and can be deleted.

Testing

For the purposes of this post we are going to test our app in our local Dev Fabric.  We can run our app by click on CRTL + F5.  Once our app has been deployed to our local Dev Fabric we will notice a line in our Output window providing a link to our Trace Log.  We will use this log once we have submitted some messages to the queue to validate that we are in fact retrieving them from the Queue.

image

With our application deployed to the Local Dev Fabric, our ASP.Net Web App should appear.  We now need to populate some test data and click the Submit Outage button.

 

image

If we no navigate to our Trace Log, we should see our test message being pulled from the Queue.

image

 

Trace Logs are also available in when running applications in the cloud.  I was using the Dev Fabric for simple convenience reasons.

Categories: AppFabric, Azure, Queue Tags:

Monitoring and Managing a Simple Azure AppFabric Application

July 9, 2011 Leave a comment

In my last post we walked through deploying a simple Azure AppFabric Application that consisted of an ASP.Net Web application and a Workflow Service.  In this post we are going to walk through some of the features that are available within Application Manager that is available in the Azure AppFabric June 2011 CTP.

Application Manager is not something that is included in the Local Dev Fabric so this is something that will require access to the Azure AppFabric lab that is currently in a public, but limited availability, CTP format.  I put in my request on the https://portal.appfabriclabs.com/ site.  It took about 2 weeks to get accepted but mileage may vary.

Since deploying my simple workflow application, I have had the chance to call my application a few times so we can start looking at some of the Health and Performance data that has been collected.

The first stop is on the left hand side where we will discover a summary of the applications we have deployed.  If we want to take a look at some high level Monitoring details we can do so by clicking on the Monitoring link.

image

From the Monitoring view we have the opportunity to discover some metrics related to our services that we have deployed to Azure. 

image

 

Currently we have the ability to see metrics for the past 1 hour or 24 hours and can easily toggle between these two values.

image

We also have the ability to drill down (a little bit) by clicking on the arrow where a little graph will be displayed. In this graph we can see the ASP.Net Request latency based upon the time slice.

image

 

So is this enough info to really monitor a production application?  Probably not but do remember it is still in CTP.  Coming from a BizTalk background, I like all of the tracking information that it provides where I can see a break down of the execution across Receive Ports, Orchestration and Send Ports.  Also the ability to replay the execution of an Orchestration, or in this case a Workflow would be really nice.  My expectation around tooling for cloud applications is that it should be the same as on-premise if not better since we may not have as many sources (logs/counters) to look at.  But once again this is CTP so I fully expect to see more detailed monitoring in a production release of AppFabric Applications.

 

The next area we are going to explore is the  Admin Log which will highlight Info, Warning and Error  events.

image

 

Since the application that I have deployed is so robust (err.. Simple) we discover that we have 8 Info events and no Errors or Warnings.

If we click on the Info link we will get a summary of these events.  In this case the information is really related to our last publish, deployment and starting of our application.

image

The last area that we are going to explore in this post is the Scale  feature.

image

Here is where we will discover some of the true benefits of Azure’s elasticity.  Organizations look to scale their applications out across multiple, or redundant, sets of hardware.  It usually servers two purposes: Reliability and Scalability.  In the Reliability area, should one server go down we know that we have at least another server that can pick up the load with the expectation that performance will probably suffer but at least we are not outright down.  The second area; Scalability really deals with performance with the idea that two instances (or servers) are better than one.

Having the ability to scale your application out, by simply selecting a value from a dropdown, to multiple “hosting” instances is extremely  powerful.  Currently, in a typical corporate environment, there is a lot of red tape and procedures that need to take place before provisioning additional server resources.  This isn’t to say that organizations don’t have to deal with some red tape when provisioning in the cloud but if you think about some of things involved in adding a server to a data centre it is significant.  Things like rack space, storage, network configurations, OS installation, joining it to the domain, installing Service Packs and Security updates.  To top it all off, these activities all take place before you can actually install your application.

In the Azure AppFabric world this is as simple selecting the number of instances that you would like to scale out to for a particular container and clicking the Save button.

image

This convenience doesn’t come for free though.  You can expect your credit card to reflect the addition instance(s) that you have just provisioned.  If I think about how long it takes to deploy a new server at my organization, this is truly mind blowing!

Conclusion

To date the Application Manager is fairly simplistic but it is definitely a step in the right direction.  I am still really impressed with what I have seen with Azure AppFabric Applications.  I think it greatly simplifies both building and managing distributed applications for the cloud. I am extremely confident that this technology will only get better.

Categories: AppFabric, Azure Tags: ,

AppFabric Apps (June 2011 CTP) – Deploying Simple Workflow App

July 8, 2011 1 comment

In this post we are going expand upon an earlier post that dealt with building a Simple Workflow App.  In this post we are going to deploy the Simple Workflow app and discover how the Application Manager works in the Azure AppFabric Labs environment.

To deploy our application from Visual Studio we are going to right mouse click on our AppFabric Application and select Publish.

image

 

We will now be prompted to provide an application name and of course provide our Namespace and  credentials.  No my namespace is not called “InsertYourNameSpaceHere”

image

After  a couple minutes we will discover that our application has been published.

image

From the Azure AppFabric Labs Portal (https://portal.appfabriclabs.com/Default.aspx) we can click on AppFabric Services.

image

Next we can click on Applications

image

 

and finally click on your namespace.  At this point, our Application Manager icon will become enabled.

image

Once in the Application Manager we will discover our Summary and Application Dashboard. Within the Dashboard we can see that our SimpleAppFabricAppWithWorkflow app has been  Imported.  The Application contains two containers: An ASP.Net Web app and our Workflow Service.  In this scenario we also have two services both the ASP.Net Web app and our Workflow Service.

image

By default, when we publish an app, it does not mean that it is actually functional.  We still need to deploy it from within the Application Manager.

To deploy this application we need to click on the SimpleAppFabricAppWithWorkflow link and then we can click on the Deploy Application link.

image

We now want to click on the Deploy link to initiate the deploy process.  If we leave the Start this application after deployment completes checkmark enabled we can expect our application to be running when this process completes.

image

After about 5 minutes we will see the state of our application change to Started and we will have a published Address for our public endpoints.

image

We can click on this endpoint URL and will discover that our application is now accessible.

image

Conclusion

All in all this process was pretty simple.  What I like about it is that I didn’t have to dig into a single configuration file to make sure I was pointed at the correct endpoint location of our Workflow service. Even though I only have a single Workflow service it wouldn’t have been too big of a deal.  But if you consider larger distributed applications where you may have many Workflow and WCF services this is a huge timesaver.

If you really think about all of the things that need to happen in the background to deploy an application to a remote server, Microsoft has done an extremely good job of keeping this very simple for us.

There are still many features of the Azure AppFabric Manager that i want to dig into including the Monitoring and Scale out features.  Look for another blog post that includes these features.

Categories: AppFabric, Azure, Workflow Tags:
Follow

Get every new post delivered to your Inbox.