Subscribe! (MP4) - Channel 9

This talk, which I recorded this week here at Microsoft campus in Redmond, is a slightly shortened version of a talk I did a few weeks ago at a conference, and which is a follow up to a blog post I wrote in January titled "Utopia ESB". You can find the slide deck on SkyDrive. The motivation for doing this talk is fairly straightforward. We see the "ESB" term and the architectural notion behind the ESB showing up in many customer engagements and also in RFPs. And we see them showing up in contexts where the goal is scale and availability. The reality is that you can't have both a central control model that the ESB theory promises and yet run a scalable and robust federation of services. The goal of this talk is to highlight the paradox and to present an alternative that's proven in the architecture of large distributed systems. This talk is obviously another controversial one, so I'm looking forward to comments here or on Twitter under @clemensv  [Sorry for the somewhat dim light and the ambient A/C noise in the background. That's a daylight conference room in Redmond under Northwest Spring skies and our humming building 24]

This is a looooooong (112 minutes, feature film length, bring popcorn) comprehensive feature and pattern overview talk specifically about the Windows Azure Service Bus and Service Bus for Windows Server brokered messaging capabilities. Since 1h 52m may be a tad bit long to watch in one go, here are some time markers that you can jump to for hearing about particular feature areas you may be interested in: 0h 00m 00s Service Bus Intro 0:05:55 - Queues and Topics - Basics 0:15:15 - Programming Model Options and Protocols 0:23:05 - Message Model, Dimensions, and Mappings 0:33:37 - Message Delivery Options and Receive Operation Styles 0:39:20 - Service Pricing Model 0:42:52 - Brokered Messaging Patterns 0:51:18 - Select Composite Patterns 0:55:20 - Correlation Patterns 1:03:05 - Messaging Features - Send/Receive 1:11:24 - Topic Filters and Actions 1:18:11 - Sessions 1:28:49 - Transaction Support 1:34:25 - Time-To-Live  and Scheduling 1:37:15 - Deadlettering 1:38:50 - Duplicate Detection 1:40:41 - Prefetching 1:42:12 - Auto Forwarding 1:46:00 - General Guidance - Resiliency and Async Operations 1:51:38 - Closing Feedback and questions are welcome as always. The slide deck can be viewed/downloaded from here; feel free to use the slide-deck for your own Service Bus presentations at conferences, or user-group events or within your team.

This whiteboard talk was largely inspired by a series of Twitter conversations around whether and when it's a good idea to share types (i.e. .NET classes compiled into assemblies) as a way to express contracts in a messaging system. I don't think it is. In fact, it's the exact opposite of loose coupling and negates a lot of the advantages of opting for a messaging middleware system and mostly all advantages of opting into open standard protocols like HTTP and AMQP. That said, it's difficult to blame the folks in the .NET developer community who've arrived at that practice, ultimately having been led down that path by -- as I am meanwhile convinced -- the late 1990s industry choice of picking XML Schema (XSD) to describe the content of messages. XML Schema, with all of its complexity, is a reasonably good way to describe the syntax of XML-based markup languages of which there are many and where aspects like element order and attribute substitution many other complexities of XSDs might make some sense. XSD's type system, which allows for restrictions that fairly directly map to inheritance on OO languages led developers to think of messages as objects - and serialization frameworks that allow for mapping the XSD type model into class hierarchy helped with that impression. Messages are not objects. Messages don't care about the version control history. Messages don't care about whether a subset of the data they carry also similarly appears in some other message. Messages are flat. Maps of keys to values. The values are simple-typed or, again, maps or arrays or values or maps. JSON embodies that model. If you ignore XSD and allow for the same simple constraints as JSON, XML also embodies that model. If you take a look, you'll start noticing that we and a lot of others in the industry have moved to document messages in simpler ways than schemas. Service Bus Queue: http://msdn.microsoft.com/en-us/library/windowsazure/hh780773.aspx Twitter Tweet: h

I'm not sure it's wise to spill the beans, but Cesar and his team are Service Bus' best-kept secret. Until today, that is. Like most teams at Microsoft we have a dedicated test organization. Very early on, when Service Bus was a one-machine open CTP running on a box under someone's desk (literally) and then on two machines in a test lab, we had some overinflated confidence on what it would take to ship a service. Then Cesar showed up with complete team and took the air out of that confidence balloon -- and then helped building confidence back up to the point that we can sleep very well while being on-call with 8 datacenters running key customer workloads on Service Bus.   Test owns checking claims and aspirations against reality, and a lot more. Watch this one.  

In today's episode I'm explaining two key Notification Hub concepts on the whiteboard: Tag-based unicast and groupcast notifications Templates I'm mostly covering the Windows 8 aspects like Tiles as Windows' notification model is richer as that of iOS, but the concepts also apply in the same way to iOS. For info on how to realize these concepts in code go to http://aka.ms/pushtowin8 (Win8) and http://aka.ms/pushtoios (iOS) 

Last week, while in Redmond, I spoke with Muralidhar Krishnaprasad (short: MK) who manages our development team. We talked about the things we ship, the cadence at which we ship, and about team organization, handling of the "Live Site", planning, and what developers on the team get to own. We also talk about owning a service is very different from owning a framework. We also talk about how new members of the team get going and how senior developers help new hires. That said, we have open positions https://careers.microsoft.com/search.aspx#&&p4=US&p0=%22Service+Bus%22&p5=2134&p1=3%2c20&p2=1093&p3=1014    

[This is the iOS version of the previously posted Walkthrough. If you've already watched the Windows 8 Edition, skip to 10 minutes 25 seconds where the actual code walkthrough starts] In this clip I'll walk you through the basic principles of the brand-new Windows Azure Service Bus Notification Hubs in a somewhat more formal and serious fashion than in my chat with Elio. Recapping from the other post,Service Bus Notification Hubs are an intrinsic feature of Windows Azure Service Bus and are different from other push notification services in four key areas: Complete client registration management. Your backend application (if you even have one) does not need to worry at all about device-ids or channels or other particulars of push notifications and doesn't need to cooperate in management. It doesn't even have to be a web app that's publicly accessible.   Platform independence. Service Bus Notification Hubs allow cross-platform push notifications so that iOS Alerts and Windows Live Tiles can be targeted with a single event message.  Broadcast and tag-based Multicast - Service Bus Notification Hubs are optimized around automatic notification broadcast to many thousand devices with low latency. One message in, thousands of notifications out. Mass customization - Notification Hub notification templates allow for customization of notification delivery for each individual registration, allowing each instance of a client App to choose how it wants to receive events. In this preview, Notification Hubs are able to push notifications to Windows Store apps and iOS apps from .NET back-ends. Support for Android and Windows Phone, along with additional back-end technologies (including Windows Azure Mobile Services) will be added soon. After the basic intro, I'm showing how to create and provision a iOS application from scratch, how to hook it up to a new Notification Hub, and send it a notifi

In this clip I'll walk you through the basic principles of the brand-new Windows Azure Service Bus Notification Hubs in a somewhat more formal and serious fashion than in my chat with Elio. Recapping from the other post,Service Bus Notification Hubs are an intrinsic feature of Windows Azure Service Bus and are different from other push notification services in four key areas: Complete client registration management. Your backend application (if you even have one) does not need to worry at all about device-ids or channels or other particulars of push notifications and doesn't need to cooperate in management. It doesn't even have to be a web app that's publicly accessible.   Platform independence. Service Bus Notification Hubs allow cross-platform push notifications so that iOS Alerts and Windows Live Tiles can be targeted with a single event message.  Broadcast and tag-based Multicast - Service Bus Notification Hubs are optimized around automatic notification broadcast to many thousand devices with low latency. One message in, thousands of notifications out. Mass customization - Notification Hub notification templates allow for customization of notification delivery for each individual registration, allowing each instance of a client App to choose how it wants to receive events. In this preview, Notification Hubs are able to push notifications to Windows Store apps and iOS apps from .NET back-ends. Support for Android and Windows Phone, along with additional back-end technologies (including Windows Azure Mobile Services) will be added soon. After the basic intro, I'm showing how to create and provision a Windows 8 application from scratch, how to hook it up to a new Notification Hub, and send it a notification "Toast" using the portals and Visual Studio 2012. (The equivalent iOS walkthrough will follow later this week) For those of you with a "TL;DW" attention spa

At the Build 2011 conference I teased a prototype at the very end of my talk. That prototype was called Iguazu and was an attempt at creating a push notification abstraction for Windows, Windows Phone, iOS, and Android that tackles the architecturally hardest challenges for developers building Apps for large web and services properties like news outlets and sports organizations that need to notify users of events at huge scale of many millions and with minimal possible latency. Fast forward to the present day, and Iguazu has become a real thing, thanks to an enormously engaged team who built a brand new service from scratch and plugged it into the Service Bus infrastructure. Today we're taking the wraps off the Service Bus Notification Hubs preview. Service Bus Notification Hubs are an intrinsic feature of Windows Azure Service Bus and are different from other push notification services in four key areas: Complete client registration management. Your backend application does not need to worry at all about device-ids or channels or other particulars of push notifications and doesn't need to cooperate in management. It doesn't even have to be a web app that's publicly accessible.   Platform independence. Service Bus Notification Hubs allow cross-platform push notifications so that iOS Alerts and Windows Live Tiles can be targeted with a single event message.  Broadcast and tag-based Multicast - Service Bus Notification Hubs are optimized around automatic notification broadcast to many thousand devices with low latency. One message in, thousands of notifications out. Mass customization - Notification Hub notification templates allow for customization of notification delivery for each individual registration, allowing each instance of a client App to choose how it wants to receive events. In this preview, Notification Hubs are able to push notifications to Windows Store apps and iOS ap

I sat down with Damian Edwards yesterday to talk about SignalR 1.0 RC2 and he also shows off his pretty sweet Windows 8 quad monitor setup with a 27" 20-point multi-touch panel in the middle.

On the way driving from my hotel to work this morning, I swung by 343 Industries' super-secret hidden space command facility to meet Angus, Caitie, and Hoop from Section 3, the team that creates the services backbone for the Halo game series including Halo Waypoint. We talk about how the Halo 4 game uses Windows Azure Service Bus in various ways, including the flow of all multiplayer game statistics from the console game into Waypoint, and how Service Bus helped the Halo team dealing with the massive traffic peak occurring on and within a few days of the game title's release.    

Yesterday I sat down with my teammate Abhishek and talked about how we build Service Bus - not how we code it, but how we run the process inside the team and how we get from features sitting on the humongous backlog to working features in the service. We also talk about the three different disciplines Program Management, Development, and Test/QA and how the checks and balances between the disciplines helps with getting things out on schedule and at great quality.

Over the holidays, the topic of transactions flared up on Twitter amongst a number of distributed systems .NET luminaries and it turned out that there isn't always clear agreement even about the basic notions around transaction technology as the overall technology stack has evolved and there are now databases that sit entirely in memory, for instance. Can those databases participate in a distributed transaction even if they're not "durable"? What are the challenges around making two or more things work together? Do I even care? To start that discussion, this episode is an introduction to what transactions are and what they're for and I am explaining the "traditional" transaction properties using a few low-tech non-code examples and a little role play with the help of my teammates Will Perry (@willpe) and Abhishek Lal (@AbhishekRLal) For some good depth information on the subject of transaction isolation, you might find the respective Wikipedia article useful that comes with a range of examples.

This is the final part of the six-part series "Getting Started with Service Bus" and this time I'm covering how to build a Service Bus Relay-relayed NAT and Firewall traversing service for both RPC-style interactions and plain HTTP.  

This penultimate episode of the "Getting Started with Service Bus" series introduces how to create Topics and Subscriptions, and how to use them, in the simplest way, with the Service Bus API.