Clemens Vasters

Football. Cloud. Tech. Politics. Pictures. Principal Architect for Messaging/Eventing at Microsoft.

In my PDC talk I’m showing a few little samples that are not in the SDK for the CTP release.  I’ve bundled them up and they’re attached to this post.

The solution contains three samples:

  1. SBMT is the ‘Service Bus Management Tool’, a small command line utility to create/view/delete ConnectionPoints and MessageBuffers using the new management model for Service Bus. I’ll explain the options of the tool below and will drill into the inner workings of the tool and the ideas behind the new management interface in the next post of this series.
  2. EchoService/EchoClient are versions of the meanwhile probably familiar ‘Echo’ sample for Service Bus that illustrates the new load balancing capability with session affinity.
  3. DurableMessageBufferSample is a variation of the SDK sample for the new durable message buffer that sends a sequence of 200 messages and fetches them back.

The SBMT project/tool is the probably most interesting one, because we’re looking to change the way how connection points are managed on Service Bus and that requires a tiny bit of tooling.

In the current version of Service Bus, creating a listener is an implicit operation. The service (listener) picks a name (or address) in the namespace, binds that name to an endpoint, and opens the ServiceHost holding the endpoint. That’s extremely convenient, but what we’ve found is that this kind of implicit management makes it hard for us to create consistent behavior for eventing (NetEventRelayBinding) and for one of our most-requested ‘missing’ features, which is load balancing and/or failover. For eventing, the majority of customers that we’ve heard feedback from is expecting the the fabric will absorb sent events with no error message even if no event subscribers are present. For the new load balancing capability we’d like to appropriately return an error message in the case that no listener is connected, but differentiate that from the case where the connection point isn’t known, at all.

The implicit model causes no connection point to exist when there are no listeners, so we can’t solve either of these puzzles without making a change. The good thing is that we’ve got a model that works quite well and we’re building on that: Our message buffers already need to be created using an explicit AtomPub operation on the namespace, so what we’re doing is to make connection points explicit by requiring that you create them beforehand just as you create message buffers. We believe that’s the right model long-term, especially also because the <MessageBuffer/> and <ConnectionPoint/> descriptions are going to have more siblings over time and we’d like to have a consistent model. If you take a deeper look at the slides for the PDC talk, you can already infer a few of the siblings.

In the talk I also give a few reasons for why we’re splitting off the management and runtime namespaces as we’re doing this. It turns out that our longer term plans for how to enable rich monitoring and control for connection points and message buffers and other messaging artifacts on Service Bus will require quite a bit space in terms of protocol surface and that’s difficult to create in a single namespace. If I have a connection point at sb://clemens.servicebus.appfabriclabs.com/foo, any right-side extensions of that URI belong to the listener. If we were  now looking to give you a protocol surface to enumerate the current sessions that are active and suspend/terminate the individually or summarily, for instance, it’s difficult to get that slotted into the same place without resorting to stunts like special escape characters in URIs. Instead, we’d like to provide a straightforward mechanism where you can get at the session connection with https://clemens-mgmt.servicebus.appfabriclabs.com/Resources/ConnectionPoints(foo)/Sessions/.

If that begs the question how those two addresses are related – I explain it in the talk. The resource has a projection into the runtime namespace. Resources are organized by their type (there will be other taxonomy pivots in the future) and you can project them into the runtime address space as you see it fit.

The SBMT tool allows interacting with the management namespace to create connection points and message buffers. The call structure is:

sbmt.exe –n <namespace> –a <account-name>–s <account-secret> <type> <command> <resource-name> <uri> [<args> ..]</

  • -n <namespace>  - the Service Bus namespace created via http://portal.appfabriclabs.com
  • -a <account-name>– the service account name that’s set up in Access Control (defaults to ‘owner’)
  • -s <account-secret>– the service account key set up in Access Control (the key you find on the portal)
  • <type>– ‘cp’ for connection points, ‘mb’ for message buffers
  • <command>– ‘create’, ‘get’, or ‘delete’ (see below)
  • <resource-name>– a unique, friendly name for the resource (eg. ‘crm-leads’)
  • <uri>– the URI projection into the runtime namespace (e.g. ‘sb://<NAMESPACE>.servicebus.appfabriclabs.com/crm/leads/’)
  • <args>– further arguments (see below)

Examples:

  1. Create a connection point. ‘cp create’ requires a trailing argument after the URI that indicates the number of concurrent listeners (max. 20):
    sbmt.exe –n clemens –a owner –s […] cp create crm-leads sb://clemens.servicebus.appfabriclabs.com/crm/leads/  10
  2. Delete a connection point:
    sbmt.exe –n clemens –a owner –s […] cp delete crm-leads
  3. Show a connection point:
    sbmt.exe –n clemens –a owner –s […] cp get crm-leads
  4. Enumerate all connection points:
    sbmt.exe –n clemens –a owner –s […] cp get
  5. Create a message buffer:
    sbmt.exe –n clemens –a owner –s […] mb create jobs https://clemens.servicebus.appfabriclabs.com/jobs/  10
  6. Delete a message buffer:
    sbmt.exe –n clemens –a owner –s […] mb delete jobs
  7. Show a message buffer:
    sbmt.exe –n clemens –a owner –s […] mb get jobs
  8. Enumerate all message buffers:
    sbmt.exe –n clemens –a owner –s […] mb get

The Echo sample requires that you create a connection point in your namespace like this:

  • sbmt.exe –n –a owner –s […] cp create cp1 sb://<namespace>.servicebus.appfabriclabs.com/services/echo/  10

The Message Buffer sample requires this setup, whereby the friendly name is asked for by the sample itself (‘mb1’, so you can choose that freely)

  • sbmt.exe –n –a owner –s […] mb create mb1 https://<namespace>.servicebus.appfabriclabs.com/mybuf/ 

The good news here is that you do this exactly once for your namespace. There is no renewal. A connection point that’s created sticks around like an object in the file system.

In the next post I’ll drill into what happens at the protocol level.

Since this is a CTP, we’re keenly interested in your feedback on all the things we’re doing here – making connection points explicit, splitting the namespace, what’s the tooling experience you’d like. This tool here is obviously just something I wrote to get going on demos; you can probably see that having a  durable namespace is begging for tooling and it’s one of the reasons we do it.

pdc10-servicebus-oct10-ctp.zip (24.65 KB)

Updated: