Sep 042015
 

AMQP 1.0 is “broker model independent” meaning there are no protocol requirements related to the internals of the broker. It complies with the International Standard ISO/IEC 19464. It is the only standard version of AMQP. As of last month, QPid Proton, SwftMQ, RabbitMQ, ActiveMQ, and MQLite are all supporting this relatively new standard.

Microsoft is currently working to retire their .NET-centric proprietary protocol, SBMP, over the next few months/ This will leave only the AMQP protocol when working with Azure Service Bus. The AMQP protocol backs the .NET SDK, which still has support for WCF with NetMessagingBinding. Developers may also choose to use AMQPNet Lite, which is an open source library for .NET and UWP (store apps). It is a lighter library exposing more of the primitives of AMQP. Another alternative is SBLite, which is a wrapper around AMQPNet Lite to abstract the low level details of AMQP.

Download Qpid Proton 0.10
https://qpid.apache.org/releases/qpid-proton-0.10

Download AMQPNet Lite
https://github.com/Azure/amqpnetlite

Download SBLite
https://github.com/ppatierno/azuresblite

image

Sep 152014
 

I had a great time at Jax Code Impact over the weekend. Many thanks to Bayer and Brandy for putting together a free, enjoyable, and educational Saturday conference. As a first year conference, it was impressive to see more than 300 people registered for six tracks of Microsoft-focused presentations. Kevin Wolf was a big hit with his quadcopters, 3-D printer, and oculus rift. I personally enjoyed two separate talks on Redis by Henry Lee and Steve Danielson.

I talked about the Windows Azure Service Bus offerings, and hit on topics such as Relays, Queues, Topics, WCF bindings, Pub/Sub, AMQP, and of course some Cloud Design Patterns. 

Here are the slides and code demos from my talk:

Code Impact Service Bus Presentation – Slides

Code Impact Service Bus Presentation – Demo Code

Jul 032014
 

It feels wrong for a client or server to use the “owner” shared secret credentials in an Azure Service Bus connection string. It’s pure evil with 100s or 1000s of Azure Service Bus queue and topic clients sending messages. So how about I supplement the documentation and show how to easily change from using <sharedSecret> to <sharedAccessSignature>?

Step 1: Create some SAS policies

Log into the Azure management portal, click on your Service Bus queue (or topic), and then click Configure. Add one or more policies, choose their respective permissions, and click Save. After saving, the policy name and keys appear under the “shared access key generator” section below. Copy the primary key and move on to step 2.

image

Step 2: Modify your config file

If you’re like me, you like to keep your WCF hosting code free of configuration. If hosted in a console app, the following code is all I use to start a service.

ServiceHost testHost = new ServiceHost(typeof(TestManager));
testHost.Open();

When adding an additional endpoint for NetMessagingBinding, it’s really simple to just add a new endpoint and behavior configuration. The documentation in place today always shows <sharedSecret> being used. This is not a real-world scenario since every client and service should have their own credentials.

To use your new shared access keys, change this:

    <behaviors>
      <endpointBehaviors>
        <behavior name="ServiceBusTokenProvider">
          <transportClientEndpointBehavior>
            <tokenProvider>
              <sharedSecret issuerName="owner" issuerSecret="blAhblAh+Blah/blaH+BLAhblAhBLaHblAHBlahblaH=" />
            </tokenProvider>
          </transportClientEndpointBehavior>
        </behavior>
      </endpointBehaviors>
    </behaviors>

to something like this, using your newly-generated keys:

    <behaviors>
      <endpointBehaviors>
        <behavior name="SASPolicyTokenProvider">
          <transportClientEndpointBehavior>
            <tokenProvider>
              <sharedAccessSignature keyName="ingest-manager" key="SASkey+sAskEY/SASKeysaSKey+SaskeYsaSKEy/SaS=" />
            </tokenProvider>
          </transportClientEndpointBehavior>
        </behavior>
      </endpointBehaviors>
    </behaviors>

And that’s it.