Freigeben über

Service Bus SDK 3.0.x Part 1

  • Artikel

Last week we released our new Service Bus SDK for .NET and we want to publish a series of blogs about it addressing the major changes. This may end up being a fairly long series… but we'll see.

 

First and foremost was the move away from the Asynchronous Programming Model (APM) pattern. This pattern, which dates from the earliest days of .NET, required Begin and End operations for all asynchronous methods. APM was a very useful model and was fairly easy to work with considering what it enabled. All scalable systems are asynchronous in nature and Service Bus has always supported asynchronous programing. It's the only way to get really good performance.

 

The move to the Task-based Asynchronous Pattern (TAP) uses a single method to represent both the initiation and completion of asynchronous operations. TAP, which was introduced in .NET Framework 4 is the recommended approach to asynchronous programming in the .NET Framework. The async and await keywords were added to support TAP within the C# language.

 

This provides several key advantages; performance and ease of use being the most compelling.

 

As a simple example look at the implementation below for Read method implemented first as a synchronous method, then with APM, and finally with TAP.

 

 

 public class MyClass
{
 public int Read(byte [] buffer, int offset, int count);
}

public class MyClass
{
 public IAsyncResult BeginRead(byte [] buffer, int offset, int count, AsyncCallback callback, object state);
 public int EndRead(IAsyncResult asyncResult);
}

public class MyClass
{
 public Task<int> ReadAsync(byte [] buffer, int offset, int count);
}

The TAP approach works much more like a synchronous approach. It is easier to understand and doesn't required tracking of IAsyncResult objects or callbacks. Also the framework can do a lot more optimization with this model.

The easiest way to see these changes is to examine the ClientEntity classes in the SDK - like QueueClient.

Below we can see screenshots of the 2.7.x SDK on the top and 3.0.1 SDK on the bottom. Notice how much smaller the scroll is. All those Begin/End pairs a gone. A simple API is a useable API. Step 1.

If you're a long time user of Service Bus who has implemented as asynchronous implementation good for you! Like I said, this is how all software scales. Now it's time to update your approach to TAP.

 

The TAP approach also enables more sophisticated mechanisms like cancellation tokens, which will be added to future versions of the SDK. We'll talk about these when we introduce them.

 

For more about Asynchronous Programming Patterns.

Comments

  • Anonymous
    August 26, 2015
    When oh when are we going to hear about Service Bus for Windows Server?  Currently languishing on version 1.1 without any hints from MS as to when it is going to be updated (or whether it's just been abandoned entirely).

  • Anonymous
    August 30, 2015
    This isn't really the right forum to ask that question, but I'll address it anyway. First may I ask exactly what features are missing in 1.1 that you're in need of? You can either email me or respond here. Second, there is a new patch / CU coming out for Service Bus for Windows Server 1.1. There are still three years of mainline support for 1.1. and then five years of extended support. If you can tell me exactly what you're looking for I may be able to help you more. Finally - we are working on the long term road map now - but there are larger Azure wide platform alignments we're trying to fit into. Once that is settled we will announce our plans. There will be a new version and it will be worth the wait. We have not abandoned the platform.

    • Anonymous
      June 19, 2016
      Our current problem with Service Bus for Windows is you can not install with Azure Service Fabric on the same machine.This is a bummer.

  • Anonymous
    September 02, 2015
    There are many missing things around Service Bus 1.1 on-premise:

  • a decent administration and monitoring tool (Service Bus Explorer is just sample code that crashes often, not supported by Microsoft)
  • decent API and configuration documentation on MSDN (the existing one is mixed with Azure SB documentation and lacking in many places)
  • Powershell support for creating topics and subscriptions
  • decent error messages that are not cryptic
  • logging support (when something crashes nobody know why, no clear errors in Event Logs)
  • clearly documented AMPQ support (exactly what's supported and what not, for the on-premise version); samples for connectingh using other, non-microsoft AMPQ client libraries, both on Java and .NET; an interoperability story
  • predictable behaviour when quotas are reached (when the subscription quotas are reached, SB 1.1 just crashes without a decent error message)