Sunday, December 18, 2011
There are a lot of reasons why the 2011 holiday season is a great time to take a look at Azure development. There are a number of offers and releases that allow you to start to explore cloud-based development on the Microsoft platform, best of all; they are all pretty much free to take advantage of.
$0 Spending Limit on Azure Trial & MSDN Accounts
Ever since the introduction of billing for Windows Azure it has always been an issue for many developers wanting to learn Azure that, if you are not careful, you can easily run up charges on the trial accounts when going above the free quotas.
With the “$0 spending limit” available on 90 day trial and MSDN accounts Azure development developers can start to explore the Azure platform without fear of an unexpected bill at the end of the month. You will, however, have to enter credit-card details.
It is great to see this option available, I know it is something that developers have been clamoring for ever since billing was introduced on the platform. Hopefully this will be extended to a fixed-price limit on Azure billing at some point in the future.
Details of the trail offers are
here
.
No Charge for Azure Service Bus until April 2012
The Azure Service bus provides brokered and relayed messaging capabilities hosted in Windows Azure datacenters. Launched in CTP in 2007 under the name of “BizTalk Services”, then re-branded to “.NET Services”, “AppFabric Service Bus”, and now “Azure Service Bus” the messaging services are a great way to explore the capabilities of Azure when creating hybrid (part cloud, part on-premise) applications.
I’ve spent a lot of time exploring the brokered messaging capabilities of the service bus and am very impressed with the functionality provided. With four months of being above to use the services for free (data transfer charges still apply), now is a perfect time to gain some experience of using the technologies, or even create a small proof-of-concept application in your organization.
You may like to check out my free e-book on the brokered messaging capabilities of the service bus “The Developer’s Guide to AppFabric”. It’s available
here
.
As “AppFabric” has been dropped from these branding of the service bus I’ll be re-branding the title of the book in the next release.
Details of the offer are
here
.
CTP of Azure Service Bus Integration Services
If, like me, you have been following the long and winding roadmap of BizTalk Server, and want to get an early insight into what “BizTalk vNext” will look like, now is your chance.
The first CTP of Microsoft’s cloud-based integration capabilities has been released and is available to use in the AppFabric Labs environment. As the technology is in developer-preview mode, it’s free to use, no credit card required!
Details of the CTP are
here
.
Tuesday, November 29, 2011
Sweden Windows Azure Group (SWAG) and Sweden .NET User Group (SweNUG) will be hosting a “Security in the Cloud” and Christmas event this Thursday. Sergio Molaro and Robert Folkesson will be presenting on different aspects of cloud security, there will be good food, good drinks and prizes in a great location. If you are in Stockholm it’s free to register to attend
here
.
Tuesday, November 08, 2011
The November 2011 release expands on the Service Bus brokered messaging content to provide more details of the features. Deadlettering and message expiration are covered, along with message deferral, duplicate message detection, message correlation and sessions.
Get it here.
Friday, October 21, 2011
The article will be included in the next release of “The Developer’s Guide to AppFabric”, a free e-book on Azure AppFabric development. The latest edition of the e-book is available for download
here.
Monday, October 17, 2011
I’ll be presenting a session on “Extending to the Cloud” at the Sweden Windows Azure User Group next week.
Extending to the Cloud
Extending to the cloud involves developing hybrid applications that leverage the capabilities of cloud based platforms. Many of the Windows Azure solutions developed today involve extending the capabilities of existing applications and infrastructure to leverage the capabilities of Azure.
These hybrid applications allow developers to combine the best of both worlds. Existing IT infrastructure can be utilized and the capabilities of cloud platforms used to extend the applications, providing enhanced functionality at minimal cost.
This demo centric session will highlight how the hosting, compute and storage capabilities in the Window Azure platform can be used to extend on premise applications to the cloud. The rendering of 3D animations and cloud based source control will be used as case studies.
Free registration is
here.
Wednesday, October 12, 2011
I’ve just published the official release version of “The Developer’s Guide to AppFabric”. After receiving some great feedback from people I’ve corrected some errors and typos. There’s no new content since the CTP, but I’m busy working on that and there will be a lot more coverage of brokered messaging in the November release. If you want notification of new releases, follow me on Twitter @alansmith.
You can download the October 2011 release
here.
Monday, October 03, 2011
I’ve just published a CTP version of “The Developers Guide to AppFabric”. Any feedback on the content would be great, and I will include it in the full release next week.
“The Developer’s Guide to AppFabric” is a free e-book for developers who are exploring and leveraging the capabilities of the Azure AppFabric platform.
The goal is to create a resource that will evolve and mature in parallel with the Azure AppFabric technologies. The use of an electronic format will allow sections to be added as new technologies are released and improved as the knowledge and experience of using the technologies grows within the developer community.
The CTP version, published on the 3th October 2011, marks seven years to the day since the first version of “The Blogger’s Guide to BizTalk” was published.
The first section will provide an introduction to the brokered messaging capabilities available in the Azure AppFabric September 2011 release. The next section will go into a lot more depth and explore the brokered messaging feature set. Future sections will cover the Access Control Service, relayed messaging, and cache. Features like the application model and integration services will be covered as they emerge and are released.
The book will always be free to download and available in CHM and PDF format, as well as a web based browsable version. The planned release schedule for the remainder of 2011 is to update the guide with new content monthly, around the start of each month. Updates will be made available on the website and announced through my blog and twitter.
Twitter: @alansmith
The feedback form is
here.
Friday, September 23, 2011
If you want to get up to speed on Azure AppFabric brokered messaging there are a couple of resources you should check out.
This is a 30 page word document put together by the AppFabric dev team. It’s a great read to get an introduction to Queues, Topics and Subscriptions. If you are working in the AppFabric Labs environment using the May or June CTP the code will work fine. There have been significant changes in the API in the September 2011 release, so don’t expect any of the code to compile in that release, but the theory section is still very much valid.
This is a 10 page blog post from the Windows Azure CAT team that provides some great tips for developers who have some familiarity with brokered messaging. The level is pretty advanced, and it’s impressive to see how much experience the CAT team has accumulated on brokered messaging. All the code here is on the September 2011 release. It’s a must-read if you plan to develop anything using service bus brokered messaging.
Thursday, September 22, 2011
Windows Azure Storage med Björn Eriksen.
Thursday, September 29, 2011 from 5:30 PM to 9:00 PM
Windows Azure Storage är en tjänst i Windows Azure som rör olika typer av lagring. Blobs, Queues, Tables och är begrepp som många garanterat känner till, och säkert har en uppfattning om hur de ska bete sig, men finns det mer än det som syns på ytan? Utvecklare är vana att jobba med filsystem, databaser och köhanterare så varför skapa en ny modell? Skalbarhet och pålitlighet är det korta svaret!
Register here.
Join Sweden Windows Azure Group (SWAG) here.
I’ve added a third walkthrough to the AppFabric Walkthrough series.
“The following walkthrough will show how topics and subscriptions can be used to implement a simple publish-subscribe messaging channel. The next walkthrough will build on this sample and explore the use of filters on subscriptions.”
The other two walkthroughs are here.
At present there are no charges for using the new brokered messaging capabilities in AppFabric, so I have been taking advantage of this to explore the new functionality. This free offer will not last forever, so now is a great time to take a look at the new capabilities.
Monday, September 19, 2011
I’ve added a second AppFabric Walkthrough based on the Azure AppFabric Service Bus September 2011 release. The second one looks at using the NamespaceManager class to create, list, get and delete queues in an AppFabric service bus namespace using a simple C# console application. Feel free to expand on this scenario to create more sophisticated management consoles.
As with the first walkthrough there have been a lot of changes in the classes used to interact with the service bus, so don’t expect this code to work against the May or June CTP releases.
The two walkthroughs are here.
Friday, September 16, 2011
I’ve published a basic walkthrough of using the new brokered messaging capabilities in the Azure AppFabric service bus September 2011 release. If you have not used queues in AppFabric before this will get you started with a basic application that you can build upon. If you have used queues in the May or June CTP releases then this walkthrough will be useful to highlight the changes in the management portal and service bus API. (Quite a lot has changed, for the better, but I have a lot of rework to update all my demos and samples.)
Thursday, September 15, 2011
The Azure AppFabric Service Bus Brokered Messaging functionality has shipped to production, and is available in Azure data centers across the world. This means that we now have point-to-point queuing and publish-subscribe messaging available in the cloud in the form of Queues, Topics and Subscriptions. Be aware that there are substantial changes in the classes in the Microsoft.ServiceBus.Messaging namespace, which means I will have to re-record webcasts and repost blog posts.
I’ve spent quite a bit of time looking into the functionality of the new messaging capabilities and am very impressed with what I have seen in the CTP. IT’s great to see this make it to production.
If you want to download the SDK, it’s
here. For an overview of the capabilities using the CTP bits I have some webcasts
here.
If you have an AppFabric account you can log into the Service Bus section of your portal. There is some basic management functionality in the portal that allows you to create and delete queues, topics and subscriptions.
Queues can be created with various options for timeouts, queue size and options for duplicate detection, dead-lettering and sessions.
In the current release queues, topics and subscriptions are immutable, so once created it’s not possible to modify the properties. If you do need to change anything on a queue you will have to either delete and re-create the queue, or create a new queue with a different name.
As for the messaging API changes, after a quick glance I like the changes that have been made between the CTP and release versions, even though I’ve got to re-code all my demos for the release bits. Be aware that some of the sample documentation and code comments have not been updated to reflect the changes (I noticed this in the DeferredMessages sample) , so trust the code not the docs.
Tuesday, September 13, 2011
Wednesday, August 17, 2011
There are more webcasts on the AppFabric June CTP
here.
This article will take a look at the code used in the duplicate detection webcast and explain the concepts involved.
Bear in mind that this code is based on the AppFabric June CTP, things may change when the production version is released.
AppFabric Duplicate Message Detection
When developing message processing systems there can be scenarios where an identical message can be sent by an application more than once. In computer science if an operation is able to handle multiple instances of the same input without changing the result we say that it is idempotent. In AppFabric service bus messaging we are able to create idempotent messaging channels by leveraging the duplicate deletion functionality that is built into queues and topics.
The Enterprise Integration Patterns website provides a description of the Idempotent Receiver pattern here. |
Duplicate Message Detection
Duplicate message detection in queues and topics is based on the MessageId property of the messages that are sent by the sending application. When a message is created using one of the static CreateMessage methods the string value of a new GUID will be assigned to the MessageId property.
The following code will create 10 new messages and output their MessageID values.
|
for (int i = 0; i <= 9; i++)
{
// Create a test message.
BrokeredMessage testMsg = BrokeredMessage.CreateMessage("Test");
// Output the message ID
Console.WriteLine("Message {0} has MessageId {1}", i, testMsg.MessageId);
}
|
The output from the code is shown below.
Detecting duplicate messages based on the default message ID can be useful in scenarios where an application sending messages to a queue or topic needs to ensure that exactly one message is delivered.
Consider the following code.
|
try
{
// Send a message to a queue.
sender.Send(msg);
}
catch (TimeoutException ex)
{
// Has the message been sent?
}
|
If the message is sent to the queue and a timeout exception is thrown there is no way for the sending application to know that the message has been sent successfully. If the sending application chooses to resend the message it can ensure at-least-once delivery. If the sending application chooses not to resend the message it can ensure at-most-once delivery.
If the queue or topic that the message is being sent to is configured to detect duplicate messages the client can retry sending the message and the queue or topic will ignore any duplicates. This will ensure exactly-once delivery of the message.
In some scenarios message duplication may occur before the application places the message on the queue or topic. If a web service is called by a client places a message on the queue there is a chance that the client may make two calls to the service if a timeout exception occurs. As the two messages created in the service will have different message IDs the duplicate detection logic will not detect the second message as a duplicate. In order for duplicate detection to work in these scenarios we must replace the default message ID with an identifier that is linked to the content of the messages we are sending. The next scenario will explore how this can be implemented.
Duplicate Messaging Scenario
Consider a scenario where Radio Frequency Identification (RFID) tags are used for tracking goods passing an RFID reader on a store checkout. It is very easy for some of the RFID tags to be read more than once as a basket of goods is moved past the RFID reader. If the application processing the tag reads is not able to detect and remove these duplicate tag read messages it will result in the customer being billed too much for the transaction, and also cause chaos in the inventory and other systems that are dependent on this data.
A simple console application has been created to simulate this scenario. The RFID tag reads are represented using a data contract. When an instance of the RfidTag class is created it is assigned a unique tag id, and the price and product can be set.
|
[DataContract]
class RfidTag
{
[DataMember]
public string TagId { get; set; }
[DataMember]
public string Product { get; set; }
[DataMember]
public double Price { get; set; }
public RfidTag()
{
TagId = Guid.NewGuid().ToString();
}
}
|
In the Main method of the console application an order batch is created as an array of RfidTag objects using the following code. The order is for equipment for two children to play a ball game. The number of items in the order and the total value for the order are calculated and displayed.
|
// Create a sample order
RfidTag[] orderItems = new RfidTag[]
{
new RfidTag() { Product = "Ball", Price = 4.99 },
new RfidTag() { Product = "Whistle", Price = 1.95 },
new RfidTag() { Product = "Bat", Price = 12.99 },
new RfidTag() { Product = "Bat", Price = 12.99 },
new RfidTag() { Product = "Gloves", Price = 7.99 },
new RfidTag() { Product = "Gloves", Price = 7.99 },
new RfidTag() { Product = "Cap", Price = 9.99 },
new RfidTag() { Product = "Cap", Price = 9.99 },
new RfidTag() { Product = "Shirt", Price = 14.99 },
new RfidTag() { Product = "Shirt", Price = 14.99 },
};
// Display the order data.
Console.ForegroundColor = ConsoleColor.Green;
Console.WriteLine("Order contains {0} items.", orderItems.Length);
Console.ForegroundColor = ConsoleColor.Yellow;
double orderTotal = 0.0;
foreach (RfidTag tag in orderItems)
{
Console.WriteLine("{0} - £{1}", tag.Product, tag.Price);
orderTotal += tag.Price;
}
Console.ForegroundColor = ConsoleColor.Green;
Console.WriteLine("Order value = £{0}.", orderTotal);
Console.WriteLine();
Console.ResetColor();
|
The reading of the order tags is then simulated using a random number generator to create duplicate tag reads. The while loop will send messages containing the RfidTag objects to the queue. The random number generator is used to decide whether or not to advance the position in the array, and generate duplicate tag reads 40% of the time. During the sending process a count of messages is maintained and displayed in the console when the message have been sent.
|
// Send the order with random duplicate tag reads
int sentCount = 0;
int position = 0;
Random random = new Random(DateTime.Now.Millisecond);
Console.WriteLine("Reading tags...");
Console.WriteLine();
Console.ForegroundColor = ConsoleColor.Cyan;
while (position < 10)
{
// Create a new brokered message from the order item RFID tag.
BrokeredMessage tagRead =
BrokeredMessage.CreateMessage(orderItems[position]);
// Send the message
sender.Send(tagRead);
Console.WriteLine("Sent: {0}", orderItems[position].Product);
// Randomly cause a duplicate message to be sent.
if (random.NextDouble() > 0.4) position++;
sentCount++;
}
Console.ForegroundColor = ConsoleColor.Green;
Console.WriteLine("{0} total tag reads.", sentCount);
Console.WriteLine();
Console.ResetColor();
|
Once the tag read messages have been sent they can be received by the point of sale application and the customer billed. The code shown below will receive messages from the queue and display the product names. It will also count the number of items in the invoice and the invoice total, and display this information in the console.
|
Console.WriteLine("Receiving tag read messages...");
Console.WriteLine();
double billTotal = 0.0;
// Receive the order batch tag read messages.
Console.ForegroundColor = ConsoleColor.Magenta;
while (receiver.TryReceive(TimeSpan.FromSeconds(1), out receivedTagRead))
{
RfidTag tag = receivedTagRead.GetBody<RfidTag>();
Console.WriteLine("Bill for {0}", tag.Product);
receivedCount++;
billTotal += tag.Price;
}
// Bill the customer.
Console.ForegroundColor = ConsoleColor.Green;
Console.WriteLine("Bill customer £{0} for {1} items.", billTotal, receivedCount);
Console.WriteLine();
Console.ResetColor();
|
When the application is run the output is as follows.
The duplicate RFID tag reads meant that the unlucky customer was billed for 13 items instead of 10, and overcharged £44.97. In order to generate an invoice for the correct amount the application will have to be modified to handle the duplicate RFID tag read messages.
Enabling Duplicate Detection
AppFabric queues and topics are able to suppress duplicate messages by setting the RequiresDuplicateDetection property of the relevant description class to true when creating the queue or topic. The default value of RequiresDuplicateDetection is false. The description classes also contain a DuplicateDetectionHistoryTimeWindow property that specifies the time window for the detection of duplicate messages, the default value is 10 minutes.
In the RFID messaging scenario the code used to create the queue is modified as follows. This will create a queue which will suppress any messages that are sent to the queue that have the same message ID as a message that was sent during the past minute.
|
// Create a QueueDescription that will suppress duplicate messages
// with a detection history window of one minute.
QueueDescription rfidCheckOutQueueDescription = new QueueDescription()
{
RequiresDuplicateDetection = true,
DuplicateDetectionHistoryTimeWindow = new TimeSpan(0, 1, 0)
};
// Create an order queue using QueueDescription
Queue rfidCheckoutQueue = serviceBusNamespaceClient.CreateQueue
("rfidcheckout", rfidCheckOutQueueDescription);
|
With this modification the application will still be susceptible to duplicate messages as the MessageId property for the messages that are created will have the default values. This means the message id will be unique even for duplicate RFID tag reads. In order for duplicate messages to be detected the message ID is set to the tag ID property of the RFID tag, which will be unique for that RFID tag. This will ensure that the messages for duplicate RFID tag reads will have the same message ID and duplicate messages will be detected by the queue.
|
while (position < 10)
{
// Create a new brokered message from the order item RFID tag.
BrokeredMessage tagRead =
BrokeredMessage.CreateMessage(orderItems[position]);
// Set the MessageId of the message to the TagId of the RFID tag.
tagRead.MessageId = orderItems[position].TagId;
// Send the message
sender.Send(tagRead);
Console.WriteLine("Sent: {0}", orderItems[position].Product);
// Randomly cause a duplicate message to be sent.
if (random.NextDouble() > 0.4) position++;
sentCount++;
}
|
When running the modified application the output is as follows.
The queue now successfully suppresses duplicate messages and the amount billed to the customer is correct.