I published a new video over on Subscribe about the "Internet of Things". Check it out.

We're talking a lot about "Mobile" solutions in the industry, but the umbrella that this moniker casts has become far too big to be useful and doesn't represent any particular scenario subset that's useful for planning services for "mobile" devices. Nearly every personal computing scenario that consumers encounter today is "mobile".

This post is a personal perspective on "mobile" applications and how applications that run on devices labeled under this umbrella really enable a range of very different scenarios, and do require a different set of backend services, depending on the core scenario.

From this perspective, I present a taxonomy for these experiences that may be helpful with regards to their relationship to cloud services: Mobile, Outside, Inside, and Attached.

• Mobile only applies to all scenarios where I am literally mobile. I'm moving.
• Outside applies to all scenarios where I'm away from my office or my house, but at rest.
• Inside applies to all scenarios where I'm at the office or at the house, but potentially roaming.
• Attached applied to all scenarios where the experience is immovably attached to a physical location or device, appliance, or other machinery.

Mobile

As soon as I get into my car and drive, my $700 phone is not really all that useful. Things will beep and ring and try to catch my attention, but they do that without respecting my physical world situation where I probably shouldn't pay much if any attention.

That said – the phone does integrate with my car's entertainment system, so that I can listen to music, podcasts, and Internet streams and the phone functionality also integrates for a hands-free experience. It also reads text message to me out loud as they arrived when the phone is paired with my car. That all happens because the OS supports these core functions directly.

In the case of my particular car, a 2013 Audi A6 with MMI Touch and Audi Connect services (I'm not at all meaning to be boasting here), the phone/entertainment system has even its own phone SIM, so all my phone gets to contribute is its address book and the music/audio link for playing songs from the phone. Text messages and phone communication and the car's built-in navigation features including getting live traffic data is all natively supported by the vehicle without needing the phone's help.

To help making sure that the traffic data is accurate, the vehicle sends – today; this isn't science fiction – anonymous motion information, so-called "floating car data" telemetry into a data pool where it gets analyzed and yields real-time information about slowdowns and traffic jams complementing stationary systems.

If you need to catch my attention while I am mobile in the sense of 'in motion' you either have to call me and hope that I choose to pick up and am not talking to someone else already, leave me a voice mail, send me a text message and hope I'll call back or, otherwise, wait. A text message will reach me right in the central dashboard display of my car.

If you send me a Twitter message or send me something on Facebook or send me an Email I most certainly won't see it until it's safe for me to take my eyes off the street – because it is much less targeted and not integrated in the experience that my personal safety depends on in that situation.

When I'm walking on the Microsoft campus or I'm at an airport in line to board a plane, it's very similar. You can try to reach me via any of these channels, but it's not too unlikely that I'll make you wait when the immediate circumstances demand my attention. Boarding that plane or getting to the next building in time for a meeting with 20 people while it's raining outside is likely of higher urgency than your message – I'm sorry.

A 'mobile' experience is one that supports my mobility and the fact that my primary focus is and must be elsewhere. It can augment that experience but it must not attempt to take center stage because that ought not to be its role. The "My Trips" app for TripIt.com on Windows Phone is a near perfect example of an experience that is truly tailored to mobility. The app doesn't make me ask questions. It knows my itinerary and anticipates what info I will need the next time I look at the live tile.

When I'm arriving at an airport, it will have looked up my connecting flight and will have sent a notification or repeatedly try to send one to fill the Live Tile with information about the connecting flight status and gate information. I don't even have to open the app. If there are critical disruptions it will send me a Toast notification that comes with an audible alarm and vibration to help getting my attention.

Avis, the rental car company, does the same thing via email and also their app for me since I'm a "Preferred" customer. Just before the scheduled pick-up time, which they can also adjust since I give them my flight info, I get a timely email with all the information I need to proceed straight to the stall where my rental car is parked and will find that within the last handful of emails as my plane lands. I proceed to the rental care facility, get into the vehicle, and I get the rental agreement slip as I exit the facility presenting my driver's license. No need to ask for anything; the system anticipates what I'll need and it excels at that.

The phone's calendar is obviously similar. It will show me the next relevant appointment including the location info so that's available at a glance when I just look at the phone while I'm walking to another building; and it will provide the most recent updates so if the meeting gets moved between rooms as I'm on my way then I'll see that reflected on the lock screen.

All these mobile experiences that I'm using today as I'm traveling, share that they are decoupled, asynchronous, often time-driven, and message based. I don't ask for things. I answer to and react to what needs my urgent attention and otherwise I will observe and then "get to it" as I truly have time to focus on something other than getting from A to B and being mobile. Mobilility is driven by messaging, not by request/response.

Outside

Being on the road, doesn't literally mean to be driving all the time, of course. Once I sit down and indeed start interacting with a device in order to read email, go through my other messages, read/watch news, or get some work done, I am still outside of the office or the house, but I am yet not on the move. I am at rest in relatively safety and can pay closer attention to the interaction with my information device.

The shape of that interaction differs from the pure mobile experience in that I commonly ask questions and interact with the device, with focus on the device experience. That includes everything from browsing the news, to researching with Wikipedia, watching training videos, to enjoying a movie. Listening to podcasts and/or radio is also one of those experiences even if we're often doing so while being on the move, i.e. walking or driving, as we're instantly able to turn our attention to more important matters as needed – like a nearing ambulance – if we're managing the audio volume as appropriate for the situation.

The outside experience is one where I can indeed get at most of my data assets, as much of it is readily accessible from anywhere since it's stored on the cloud or networked and accessible via VPN. Whether the device I am using to access that data is connected via 3G, LTE, WLAN, or wired Ethernet, and whether the screen is 5" or 27" is largely a question of what sort of an experience I'm looking for, and how big of a device I want to carry to where I'm going.

For many, if not most consumers, this outside experience is often the preferred interaction mode with their devices – and when they own only a single device it's largely indistinguishable from the Inside experience that I'll expand on in the next section. They sit in a cafe or elsewhere comfortable with connectivity, make notes, write email, hatch plans, capture snippets of their life in photos or videos and share them with friends through Instagram, Twitter, or Facebook.

For me, the Outside experience is however quite different from the Inside experience because it's constrained in two key ways: First, while and when connectivity is available, it's commonly either metered or it's provided on someone else's terms, for free or even paid, and that means I don't get a say on the bandwidth and quality and the bandwidth may be seriously constrained as it is, for instance, in most hotels.

What Outside also often means is that connectivity is sparse or non-existent. If I'm traveling and outside the country where I have my primary data contract, I will pay a platinum-coated-bits premium for data. Therefore I find myself Hotspot-hopping quite a bit. Outside may also mean that I'm going away from the core coverage zones of wireless networks, which means that I might quite well end up with no reliable access to network services because I'm either in a remote valley or inside the Faraday-Cage hull of a ship. It might also mean that I am in a stadium with 52,000 other people who are trying to use the same set of cell towers – which is the case about every two weeks for me.

Second, what I am connecting to is a shared network that I cannot trust, which is not well suited for easy discovery and sharing scenarios that rely on UPnP/SSDP and similar protocols.

From an infrastructure perspective, apps that focus on Outside experiences work best if they can deal with varying quality and availability of connectivity, and if they are built to hold and/or access data in a way that is independent – for better and worse – of the scope and sandboxing provided by the local network that I'm connecting to. Thus, Outside experiences are best suited for using cloud-based services.

Inside

The Inside experience is much like the Outside one but with the key difference that I either directly own the environment that I'm connecting into or that I at least have reason to trust the owners and anyone else they allow to connect to the environment. That's true for my home network and it's also true, even though with a few caveats, for the office network.

The Outside/Inside split and a further differentiation of Inside into work and home environments is also what the Windows Firewall uses to categorize networks. The public, outside networks are on the lowest trust level, domain networks are a notch higher, and private networks are most trusted.

The experiences that I use on my Inside network at home are indeed different from the experiences I use when Outside. Xbox Smart Glass is a pure inside experience that pairs my mobile device with my Xbox as a companion experience. Xbox connects to my Windows Media Center to make my DVB-S2 SmartCard tuner available to in the guest room, I have a remote control on my phone for my Onkyo A/V receiver, I have IPTV apps with which I can tune into HDTV streams available on my Internet service, I use file sharing to access my multi-TB local photo archive.

A great Inside-experience needs services that are very similar to those of Outside experiences, including state-roaming between devices, and even more so support for seamless multi-device "continuous client" experiences – but they are not necessarily cloud-bound.

Attached

Some of the latter Inside experiences, especially the photo archive, are on the brink towards being Attached scenarios. Since I'm shooting photos in RAW and video in 1080p/50, I easily bring home 30GB+ or more from a day out at a museum or air show, and I tend to keep everything. That much data develops quite a bit of gravitational pull, meaning to say that it's not easily moved around.

What's not easily moved around, at all, are experiences that depend on a particular physical asset that is located at a particular place. The satellite dish at my house is something I need to be close to or go to (in the network sense) in order to get at content that is exclusively delivered via that channel. It also, has to be decoded with that one precious smart card that I rent from the Pay-TV provider.

If I had surveillance cameras and motion sensors around the house (I'll let you speculate on whether I really do), those cameras and sensors are location locked and I need to go to them. I can conceivably take a WLAN hub and my Xbox when I go on a vacation trip (and some people do) to make an Inside experience at a hotel room, but I can hardly take the satellite dish and the cameras.

In the business world, even when interacting with consumers, there are plenty of these immobile experiences. An ATM is a big and heavy money safe designed to be as immobile as possible that is equipped with a computer that controls how much cash I can take from that safe. A check-in terminal at an airport makes sense there as a shared experience because it gives me a printout of a document – the boarding pass – that I can use to document my authorization to travel on a particular flight. That's convenient, since paper doesn't run out of battery.

What's particularly noteworthy is that some attached experiences, such as the huge center screen in Tesla Motors' Model S, are attached and inseparable from the larger context, and yet fulfill a mobility role at times – and at other times they function like an outside appliance.

We encounter "attached" experiences while we are mobile, but they're stationary in their own context. That context may, however, be mobile if the attached experience is an in-flight entertainment system or an information terminal on a train.

Conclusion

The Mobile, Inside, Outside, Attached terminology may be a tad bit factual and dry, but I believe it's a useful taxonomy nevertheless. If you have a set of catchier monikers I'm all ears. Let me know whether you find this useful.

"Internet of Things" (IoT) is the grand catchphrase for network-enabling everyday objects and leveraging the new connectivity to collect information from the devices, allowing network-side control, and supplying information to those objects that allows them to do new tricks – like telling a toaster about the day's weather forecast so that it can burn a sun or a cloud into your morning slice of bread.

The opportunities and the use-cases in this space are almost limitless. Network-enabled, commercial vehicles or even subsystems like engines or brake systems can leverage the connectivity for conveying servicing information and predictive failure analysis, for route optimization, and driver-safety programs. Devices attached to power grid components can provide deeper insight into the health even of decades old equipment, and they can help with managing capacity now that consumers turn producers with wind-power generators and the flow of electricity has become a two-way flow. Smart devices will also help consumers to closely track their own energy consumption and, obviously, automate aspects of their households.

The "Internet of Things" wave will span many more industries and I could easily go on for many pages with more examples of which none are science-fiction. They're real and either already deployed in small scale or on the drawing boards of engineers under active development.

What's decidedly different about this new Internet wave is that it is driven by an entirely different class of people and companies as the wave of the consumer Web. The "Internet of Things" is (surprise!) about "Things" and the drivers are the makers of such things. Everyday devices and machines that consumers and businesses are buying today and that the manufacturers are looking to make better for tomorrow.

The Web is the grand success that it is because it was built for and on people-centric, general-purpose computing devices. It's also largely focused on people's interaction with information stores and sources, meaning that the impulse for interaction is usually coming from the end-user. Where user-initiated requests and the subsequent, hypertext-driven requests rooting from the same impulse are the overwhelming traffic motivation, the dominant HTTP protocol with its focus on request/response exchanges initiated by the client is a logical best fit.

Web technology also provides for an enormously low barrier of entry for new commercial providers of software-based services, as those are running on commodity hardware and solution builders can pick from a great choice of commoditized software platforms.

The Internet of Things is not the Web

There are some good reasons to believe that the Internet of Things will be different from the Web.

To play in this space, companies typically start with a set of existing physical products, a set of use-cases around these products, and very often an established and loyal customer base that's looking for new capabilities in the things they already use for their business or personal lives. There are a good number of startups operating in this space, but disrupting and displacing incumbents in the maritime industries, commercial vehicles, specialized production machinery, or high-speed train manufacturing may quite well happen at the component supplier level, but is harder to see coming at the product level.

If you are operating fleets of seagoing vessels, taxis, or trucks, or you run an electricity grid or manage street-lamps, there's a clear set of primary use-cases, like shipping things from A to B, along with well-established industries supplying machinery for these use-cases, and the digital component is a value add, not a purpose in itself.

While a 40,000 feet view onto the topology of a network of devices may look very similar to the topology of the network of the Web, with an interconnected core of services and a peripheral cloud of clients. As you get closer, the similarities start waning, though. While the Web is geared towards a primary interaction pattern where the clients initiate all activities and interaction is typically some form of information exchange – may that be a query being traded for a result list or a data-set update traded for a receipt – the interaction patterns are more differentiated for special-purpose devices where direct, human interaction is not in focus.

I generally classify the interaction patterns for 'things' into four major categories: Telemetry, Inquiries, Commands, and Notifications.

• Telemetry is the flow of information about the current or temporally aggregated state of the device or the state of its environment (e.g. readings from its sensors) from the device to some other party. The information flow is unidirectional and away from the device.
• Inquiries are questions that the device has about the state of the outside world based on its current circumstances; an inquiry can be a singular query akin to a database lookup, but it might also ask a service to supply a steady flow of information. For instance, the aforementioned toaster will ask for the weather and get a singular response, but a vehicle might supply a set of geo-coordinates for a route and ask for continuous traffic alert updates about particular route until it arrives at the destination. Only the former of these cases is the regular request/response case that HTTP is geared towards.
• Commands are service-initiated instructions sent to the device. Commands can tell a device to send information about its state – either as a point-in-time observation or over continuously some period – or to change the state of the device, including performing activities with effects in the physical world. That includes, for instance, sending a command from a smartphone app to unlock the doors of your vehicle, whereby the command first flows to an intermediating service and from there it's routed to the vehicle's onboard control system.
• Notifications are one-way, service-initiated messages that inform a device or a group of devices about some environment state they're otherwise not aware of. Cities may broadcast information about air pollution alerts suggesting fossil-fueled systems to throttle CO2 output – or, more simply, a car may want to show weather or news alerts or text messages to the driver.

For all four interaction categories it is, except for that one request-response sub-scenario, a clear requirement to have bi-directional information flow that can be client-initiated or server-initiated, depending on the particular function's need.

A requirement that indirectly grows out of the need for server-initiated flow (like telling your vehicle to toot a tune on its horn using a smartphone app when you've forgotten in what corner of which level of the structure you've parked at the airport a week ago) is that there must be a continuously maintained traffic route towards the client, which may only have to route a few messages per week, but if whenever a message is sent, the expectation is that the latency is in the order of a few seconds.

Because the scenarios around 'things' are quite different from those of the Web, where the focus is on people and their interactions, there's quite a bit of a risk that its well-known technologies turn into false friends. Are they a fit because they're ubiquitous?

VPN to the Rescue?

The standard Web interaction model where the client initiates and a service response is just one out of a several different patterns that are required for connected and non-interactive 'things', and this presents quite a bit of a challenge. How would I send a service-originated command or a notification to a connected device?

One option would indeed be HTTP long-polling or Web Sockets. The client could establish such a connection and the service would hold on to it and subsequently route all service-originated messages for the client through the established channel. That's a reasonable strategy, even if that introduces a solvable, but tricky service-side routing challenge of how the service will route to that ephemeral socket or pending request across a multi-node fabric.

But because that's tricky, many people in the devices space seem to go down a different route today: They're turning the devices into servers – and suddenly that routing problem is magically solved. If I can send a notification or command to a device by ways of issuing an HTTP request to it, I could use off-the-shelf components and HTTP to implement both the client-to-service Telemetry/Inquiry path and the service-to-client Command/Notification. Or even if I'm not into HTTP, I could just use whatever standard or proprietary protocol I like, and yet just treat either party as a server from the respective other party's perspective.

That's enormously attractive. It also poses a new challenge. How do I turn a truck or an off-shore wind-turbine into an addressable server endpoint? The answer to that question is, across many industries and companies, in unison, "VPN".

Virtual Private Networks (VPN) provide a link layer integration model between network participants. Expressed in a more pedestrian fashion, a VPN is akin to hooking everyone connected to the VPN onto the same Ethernet hub, whereby secured public Internet connections act as the network cables. Because the VPN illusion is created down at the link level and largely equivalent to having a network adapter on that network, participants on the VPN can speak practically any protocol, including but not limited to IPv4 and IPv6, and all protocols that ride on top of those two.

The steps for making a field-deployed device network addressable – assuming it supports VPN – are fairly straightforward: The device first establishes an external network identity that allows it to connect either to the public Internet or, as it is sometimes done for GPRS/3G/LTE devices, a carrier-provided closed network by ways of a dedicated in-network access point. Then it establishes the VPN tunnel by connecting to the VPN gateway's endpoint, which either resides on the Internet or on the closed network. Once the tunnel is established, the device is now connected to a separate, second network: the VPN.

Assuming that network is an IP network, the device either already has a pre-assigned address or requests an address lease from the network's DHCP service and is then a fully addressable network participant within the private address space of the VPN. If we further assume that the service who wants to address the device has direct or routed access to the VPN's address space, the service can now directly address the device and talk to any endpoints the device may be listening on. And because all of the tunnels into the VPN are secure, all the traffic exchanged between any of the parties is automatically secure without taking any extra precautions. Perfect solution. Is it?

Where's the Catch?

The biggest issue with the VPN approach for field-deployed devices lies where many people would expect it least: Security. That might be a surprise as VPN is often seen as being seen as almost synonymous with a "secure network space", which is not a proper way to look at it.

VPN provides a virtualized and private (isolated) network space. The secure tunnels are a mechanism to achieve an appropriately protected path into that space, but the space per-se is not secured, at all. It is indeed a feature that the established VPN space is fully transparent to all protocol and traffic above the link layer.

In the two predominant use-cases for VPN technology, its transparency is clearly desirable: The first use-case is the integration of corporate satellite assets like notebooks into secure networks. The second key use-case are inter-datacenter links fusing datacenter or application-scope networks over the public Internet. In the latter case, the connected parties are presumably following datacenter best-practices for physical and network access control. In the former case, the client is commonly in the possession of an authorized employee or vendor, requires individual user credentials for access, is often protected with a smartcard, is subject to device-level encryption, and often allows some degree of remote control including remote wipe if the asset becomes compromised. In both cases, the assets connecting into the VPN are either under immediate control of personnel authorized by the VPN owner, or there are several layers of safeguards in place to prevent access to the VPN should the assets become compromised.

The security of a virtual network space solely depends on controlling and securing all assets that connect into it, which obviously includes physical access security.

Now imagine you're an energy utility company planting a farm of wind-turbines into a field on a remote hill. Or imagine you're a city planting environmental sensors for pollution, humidity, barometric pressure, and temperature onto rooftops. Or imagine you're a manufacturer selling network-attachable kitchen appliances to the general public.

And now imagine that the way you're creating bi-directional connectivity to these devices and to make them addressable is by mapping them into a VPN, together with your services and any other such device – at the link layer.

How much can you trust or control that these devices don't get physically hijacked and compromised? What's the attack surface area of your services and the neighboring devices in case that were to happen?

It's one of the key principles of security that whoever has physical possession of a device owns ("pwns") the device from a security perspective. If you're handing complete strangers networked devices that can log themselves into your VPN based on secrets present on the device, you should expect that you'll eventually have unauthorized link-level visitors in the private network that you will have to be prepared to defend against – and you'll have to defend the device's neighbors as much as the services you map into the same private network space.

The security measures you'll have to put in place for this eventuality are largely equivalent to securing the services and devices as if they were directly attached to the public Internet. If you get uninvited visitors who exploit a device, you will have to assume malicious intent; these intruders will not show up by accident. Therefore, you'll have to firewall all devices, and you have to put authentication and access control measures on all exposed service endpoints. You'll also have to ensure that whatever service software stack is running on the device is "Internet hardened" and that you have an appropriate avenue to promptly distribute security updates, should that become necessary.

In addition to the security challenges, only some advanced VPN protocols over IPSec/IKEv2 (RFC 4555) allow for seamless handling of connection failure scenarios, client network roaming, and reconnect. With devices on unreliable or highly congested networks, or devices that are used in mobility scenarios where connections may be interrupted because of signal interruptions, a VPN client without this support will incur the cost of having to reestablish the tunnel and the VPN session whenever the connection drops. That, in turn, can lead to routing confusion when a client drops and reconnects and shows up on different VPN load balanced router while some service-side component wants to send data to the device.

Lastly, VPN is very resource hungry for establishing data tunnels to hundreds of thousands or more small devices that send and receive relatively few and usually fairly small messages each. It's demanding on the client in terms of the required stack and the processing needs, which may be a problem for small embedded devices. It's also enormously resource consuming on the service-side. Current, dedicated hardware for managing 10,000 simultaneous VPN tunnels can easily cost over $100,000 USD with single redundancy for one site.

As you contemplate the complexity consequences, it is possible you'll come to the conclusion that creating a VPN for the connected devices scenario may not be the obvious best choice that it seemed to be at first.

Alternatives

Even with the laid out constraints, VPN might be a viable model to enable two-way connectivity, if you're willing to make the right security investments on top, and if the devices are capable enough.

If a VPN solution and its consequential complexities were indeed turning out to be too heavyweight for you, you'll again have the problem of how to make the devices individually addressable in order to send a service-originated command or a notification to a connected device.

As mentioned, one possible alternative would be a long-polling Web Sockets based gateway, where the client establishes a connection that the service holds on to, and subsequently routes service-originated messages through the established channel back up to the client.

The advantage of this model is that the client will not have to be directly addressable. If the gateway is hosted on a public-facing Internet address, the client can establish a connection coming through any layers of NATs and/or Proxies and/or Firewalls and the service can route information back over that established link through these intermediary infrastructures.

What this model still wouldn't solve well is the case of clients that get occasionally disconnected due to weak wireless signals or congested networks. The client can park one of these sockets on the gateway and make itself known, but if the connection collapses and the device is out of reach for a little while and a message arrives for it, where does that message go?

Also, once the client comes back it may connect to a different gateway machine by ways of a load balancer, so if you're retaining that message on the original gateway node, you'd now have to route it to the current gateway node. Because the 'current' node may shift if the device repeatedly connects and disconnect when it is, for instance, at the edge of the wireless coverage area, chasing the client gets fairly complicated. And that's something you'd have to build.

Messaging

A very practical and fairly straightforward solution to the entirely problem space is to use a scalable and Internet-facing messaging system using a bi-directional and multiplexing protocol like AMQP to facilitate the outbound as well as the inbound device traffic.

If each device is assigned an exclusive queue or a filtered subscription on a pub/sub topic for messages to it, the addressing problem is moved from the edge where the device (VPN) or its connection (Web Sockets) must be identified to one where messages for a device get routed to a well-known and stable location in the system and from which the device can pick them up as it can, depending on connectivity state. When a message is sent and the device is connected and waiting for a message, the message can be delivered in a matter of a few milliseconds. If the device is temporarily offline, it can pick up messages whenever it regains network access – unless the message expire, which is an option in most common messaging systems so that a command like "unlock door" isn't executed to everyone's surprise a day later if the device was disconnected for that long.

Since the devices will pull messages from the messaging system and send messages on the same path and with AMQP also over the very same multiplexed connection, the communication path – likely enveloped with SSL/TLS – is as secure as a VPN tunnel and an HTTPS-wrapped Web Socket, and have the same advantages as the Web Socket path in terms of not exposing the client to unwanted traffic because all traffic is outbound and coming from behind existing protection layers.

From a scalability perspective, a scalable pub/sub system with addressable entities and well-known scale characteristics also provides a good structure to allow for cleanly partitioning devices and device-groups across as many queues and topics as needed to accommodate a large device population.

Conclusion

Using VPNs for device connectivity is a viable if the solution addresses the inherent security issues. Using a VPN doesn't equate creating a secure network space. It creates a virtual network space with full fidelity at the link layer with protected paths into that network space. That's a big difference. The tax that needs to be paid for VPN support on the client is not insignificant, and securing the virtualized network doesn't pose a smaller challenge than securing Internet-exposed devices, especially when those devices are outside the manufacturer's or operator's immediate physical control.

After weighing these costs, a solution that builds purely on simple, client-originated connectivity with overlaid transport layer security is not only much simpler, but doesn't carry the same security risks or infrastructure tax.

Using a messaging system as the gateway technology for these client-originated connections where each client has a designated 'mailbox' in form of a queue or topic also elegantly solves the addressability issue with the added benefit of being resilient against occasional connection loss – while not causing significant extra latency cost or overhead.

For a walkthrough on how to architect a system of this kind, I'll recommend taking a look at my June 2012 MSDN Magazine article (which may have been published a year before its time) and you can expect more on this topic here in the upcoming months.

Service Bus Notification Hubs are a brand new 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 span (too long; didn't watch), here's the whole extent of the code added to the stock Windows Store Grid template to enable Service Bus Notifications and that includes re-registering existing registrations at App startup. 5 lines without cosmetic wrapping and some massaging of XML for the template:

public App()
{
    var cn = ConnectionString.CreateUsingSharedAccessSecretWithListenAccess(
            "sb://clemensv1.servicebus.windows.net",
            "{{secret-key}}");
    this.notificationHub = new NotificationHub("myhub", cn);

    ...
}

async Task InitNotificationsAsync()
{
    await notificationHub.RefreshRegistrationsAsync();

    if (!await notificationHub.RegistrationExistsForApplicationAsync("myToast"))
    {
        await notificationHub.CreateTemplateRegistrationForApplicationAsync(
            CreateTemplate(), "myToast");
    }
}
        
XmlDocument CreateTemplate()
{
    var t = ToastNotificationManager.GetTemplateContent(ToastTemplateType.ToastText01);
    var n = t.SelectSingleNode("//text[@id='1']") as XmlElement;
    if (n != null)
    {
        n.InnerText = "$(msg)";
    }
    return t;
}

The event-source code is similarly terse:

var cn = ServiceBusConnectionStringBuilder.CreateUsingSharedAccessSecretWithFullAccess(
    "clemensv1", "{{{secret key}}");

var hubClient = NotificationHubClient.
    CreateClientFromConnectionString(cn, "myhub");

hubClient.SendTemplateNotification(new Dictionary<string, string>{
    { "msg", TextBox1.Text }});

3 lines. Three lines. No management of device ids. No public endpoint for the phone to talk to. Service Bus does all that. It really is worth playing with.

And here are all the key links ....

• Feature guide (Windows Store Apps) - http://go.microsoft.com/fwlink/?LinkID=275828
• Feature guide (iOS) -  http://go.microsoft.com/fwlink/?LinkId=275829
• Fundamentals - http://go.microsoft.com/fwlink/?LinkId=277072
• Tutorial (Windows Store Apps) - http://go.microsoft.com/fwlink/?LinkId=277073
• Tutorial (iOS) - http://go.microsoft.com/fwlink/?LinkId=277074

SDKs:

• Windows 8 Managed Client Library - http://go.microsoft.com/fwlink/?LinkID=277160
• iOS Client Library - http://go.microsoft.com/fwlink/?LinkID=277161
• Preview client NuGet - http://nuget.org/packages/ServiceBus.Preview

The basic idea of the Enterprise Service Bus paints a wonderful picture of a harmonious coexistence, integration, and collaboration of software services. Services for a particular general cause are built or procured once and reused across the Enterprise by ways of publishing them and their capabilities in a corporate services repository from where they can be discovered. The repository holds contracts and policy that allows dynamically generating functional adapters to integrate with services. Collaboration and communication is virtualized through an intermediary layer that knows how to translate messages from and to any other service hooked into the ESB like a babel fish in the Hitchhiker’s Guide to the Galaxy. The ESB is a bus, meaning it aspires to be a smart, virtualizing, mediating, orchestrating messaging substrate permeating the Enterprise, providing uniform and mediated access anytime and anywhere throughout today’s global Enterprise. That idea is so beautiful, it rivals My Little Pony. Sadly, it’s also about as realistic. We tried regardless.

As with many utopian ideas, before we can get to the pure ideal of an ESB, there’s some less ideal and usually fairly ugly phase involved where non-conformant services are made conformant. Until they are turned into WS-* services, any CICS transaction and SAP BAPI is fronted with a translator and as that skinning renovation takes place, there’s also some optimization around message flow, meaning messages get batched or de-batched, enriched or reduced. In that phase, there was also learning of the value and lure of the benefits of central control. SOA Governance is an interesting idea to get customers drunk on. That ultimately led to cheating on the ‘B’. When you look around and look at products proudly carrying the moniker ‘Enterprise Service Bus’ you will see hubs. In practice, the B in ESB is mostly just a lie. Some vendors sell ESB servers, some even sell ESB appliances. If you need to walk to a central place to talk to anyone, it’s a hub. Not a bus.

Yet, the bus does exist. The IP network is the bus. It turns out to suit us well on the Internet. Mind that I’m explicitly talking about “IP network” and not “Web” as I do believe that there are very many useful protocols beyond HTTP. The Web is obviously the banner example for a successful implementation of services on the IP network that does just fine without any form of centralized services other than the highly redundant domain name system.

Centralized control over services does not scale in any dimension. Intentionally creating a bottleneck through a centrally controlling committee of ESB machines, however far scaled out, is not a winning proposition in a time where every potential or actual customer carries a powerful computer in their pockets allowing to initiate ad-hoc transactions at any time and from anywhere and where we see vehicles, machines and devices increasingly spew out telemetry and accept remote control commands. Central control and policy driven governance over all services in an Enterprise also kills all agility and reduces the ability to adapt services to changing needs because governance invariably implies process and certification. Five-year plan, anyone?

If the ESB architecture ideal weren’t a failure already, the competitive pressure to adopt direct digital interaction with customers via Web and Apps, and therefore scale up not to the scale of the enterprise, but to scale up to the scale of the enterprise’s customer base will seal its collapse.

Service Orientation

While the ESB as a concept permeating the entire Enterprise is dead, the related notion of Service Orientation is thriving even though the four tenets of SOA are rarely mentioned anymore. HTTP-based services on the Web embrace explicit message passing. They mostly do so over the baseline application contract and negotiated payloads that the HTTP specification provides for. In the case of SOAP or XML-RPC, they are using abstractions on top that have their own application protocol semantics. Services are clearly understood as units of management, deployment, and versioning and that understanding is codified in most platform-as-a-service offerings.

That said, while explicit boundaries, autonomy, and contract sharing have been clearly established, the notion of policy-driven compatibility – arguably a political addition to the list to motivate WS-Policy as the time – has generally been replaced by something even more powerful: Code. JavaScript code to be more precise. Instead of trying to tell a generic client how to adapt to service settings by ways of giving it a complex document explaining what switches to turn, clients now get code that turns the switches outright. The successful alternative is to simply provide no choice. There’s one way to gain access authorization for a service, period. The “policy” is in the docs.

The REST architecture model is service oriented – and I am not meaning to imply that it is so because of any particular influence. The foundational principles were becoming common sense around the time when these terms were coined and as the notion of broadly interoperable programmable services started to gain traction in the late 1990s – the subsequent grand dissent that arose was around whether pure HTTP was sufficient to build these services, or whether the ambitious multi-protocol abstraction for WS-* would be needed. I think it’s fairly easy to declare the winner there.

Federated Autonomous Services

Windows Azure, to name a system that would surely be one to fit the kind of solution complexity that ESBs were aimed at, is a very large distributed system with a significant number of independent multi-tenant services and deployments that are spread across many data centers. In addition to the publicly exposed capabilities, there are quite a number of “invisible” services for provisioning, usage tracking and analysis, billing, diagnostics, deployment, and other purposes.  Some components of these internal services integrate with external providers. Windows Azure doesn’t use an ESB. Windows Azure is a federation of autonomous services.

The basic shape of each of these services is effectively identical and that’s not owing, at least not to my knowledge, to any central architectural directive even though the services that shipped after the initial wave certainly took a good look at the patterns that emerged. Practically all services have a gateway whose purpose it is to handle and dispatch and sometimes preprocess incoming network requests or sessions and a backend that ultimately fulfills the requests. The services interact through public IP space, meaning that if Service Bus wants to talk to its SQL Database backend it is using a public IP address and not some private IP. The Internet is the bus. The backend and its structure is entirely a private implementation matter.  It could be a single role or many roles.

Any gateway’s job is to provide network request management, which includes establishing and maintaining sessions, session security and authorization, API versioning where multiple variants of the same API are often provided in parallel, usage tracking, defense mechanisms, and diagnostics for its areas of responsibility. This functionality is specific and inherent to the service. And it’s not all HTTP. SQL database has a gateway that speaks the Tabular Data Stream protocol (TDS) over TCP, for instance, and Service Bus has a gateway that speaks AMQP and the binary proprietary Relay and Messaging protocols.

Governance and diagnostics doesn’t work by putting a man in the middle and watching the traffic coming by, which is akin to trying the tell whether a business is healthy by counting the trucks going to their warehouse. Instead we are integrating the data feeds that come out of the respective services and are generated fully knowing the internal state, and concentrate these data streams, like the billing stream, in yet other services that are also autonomous and have their own gateways. All these services interact and integrate even though they’re built by a composite team far exceeding the scale of most Enterprise’s largest projects, and while teams run on separate schedules where deployments into the overall system happen multiple times daily. It works because each service owns its gateway, is explicit about its versioning strategy, and has a very clear mandate to honor published contracts, which includes explicit regression testing. It would be unfathomable to maintain a system of this scale through a centrally governed switchboard service like an ESB.

Well, where does that leave “ESB technologies” like BizTalk Server? The answer is simply that they’re being used for what they’re commonly used for in practice. As a gateway technology. Once a service in such a federation would have to adhere to a particular industry standard for commerce, for instance if it would have to understand EDIFACT or X.12 messages sent to it, the Gateway would employ an appropriate and proven implementation and thus likely rely on BizTalk if implemented on the Microsoft stack. If a service would have to speak to an external service for which it would have to build EDI exchanges, it would likely be very cost effective to also use BizTalk as the appropriate tool for that outbound integration. Likewise, if data would have to be extracted from backend-internal message traffic for tracking purposes and BizTalk’s BAM capabilities would be a fit, it might be a reasonable component to use for that. If there’s a long running process around exchanging electronic documents, BizTalk Orchestration might be appropriate, if there’s a document exchange involving humans then SharePoint and/or Workflow would be a good candidate from the toolset.

For most services, the key gateway technology of choice is HTTP using frameworks like ASP.NET, Web API, probably paired with IIS features like application request routing and the gateway is largely stateless.

In this context, Windows Azure Service Bus is, in fact, a technology choice to implement application gateways. A Service Bus namespace thus forms a message bus for “a service” and not for “all services”. It’s as scoped to a service or a set of related services as an IIS site is usually scoped to one or a few related services. The Relay is a way to place a gateway into the cloud for services where the backend resides outside of the cloud environment and it also allows for multiple systems, e.g. branch systems, to be federated into a single gateway to be addressed from other systems and thus form a gateway of gateways. The messaging capabilities with Queues and Pub/Sub Topics provide a way for inbound traffic to be authorized and queued up on behalf of the service, with Service Bus acting as the mediator and first line of defense and where a service will never get a message from the outside world unless it explicitly fetches it from Service Bus. The service can’t be overstressed and it can’t be accessed except through sending it a message.

The next logical step on that journey is to provide federation capabilities with reliable handoff of message between services, meaning that you can safely enqueue a message within a service and then have Service Bus replicate that message (or one copy in the case of pub/sub) over to another service’s Gateway – across namespaces and across datacenters or your own sites, and using the open AMQP protocol. You can do that today with a few lines of code, but this will become inherent to the system later this year.

Head over to my Subscribe! blog on Channel 9 for the latest episode on Transactions.

A suggestion was made on mygreatwindowsazureidea.com for Windows Azure Service Bus to support distributed transactions. The item isn’t very popular on the site with 7 votes, but I know that that’s a topic near and dear to the heart of many folks writing business solutions. We in the Service Bus team owning MSMQ and the Workflow team next door owns DTC and we’re getting enough requests now that we’ll start working on better guidance around transactions in the coming months, some of which will come in form of clips on my Subscribe blog on Channel 9.

What’s not likely going to happen is that we will provide a magic “it just works” solution that brings DTC and the 2PC model to the cloud. Why? Because 2PC isn’t doing well in that world. Here is my reply to the post on mygreatwindowsazureidea.com for better linking:

Here’s from my Channel 9 Subscribe blog, an ad-hoc, single-take whiteboard discussion on "push" and "pull" communication patterns. There's a lot of talk in the industry on push (see push notifications) and pulling/polling (long polling vs. web sockets and messaging), so I'm dissecting that space a bit and explore push vs. pull and various pattern nuances from UDP upwards.

Over on my new Channel 9 blog I've started a series that will (hopefully) help novices with getting started developing applications that leverage Windows Azure Service Bus (and, in coming episodes also Service Bus for Windows Server)

The first two episodes are up:

• Getting Started with Service Bus. Part 1: The Portal
• Getting Started with Service Bus. Part 2: .NET SDK and Visual Studio 

There's much more to come, and the best way to get at it as it comes out is to subscribe to the RSS feed or bookmark the landing page.

I have a new (additional) blog. It's not a "write" blog, it's a "speak" blog. Over on Microsoft's Channel 9 I started the "Subscribe!" blog last Friday night.

The goal for it is to be a way to talk about middleware and specifically about my team's product Service Bus on Channel 9. Service Bus and the other middleware products and features tend to require quite a bit of guidance and explanation because they help solving complex problems. I'm trying to help providing a forum for that, not only in the form of monologues, but also having our customers and my coworkers speak.

Here's the link http://channel9.msdn.com/blogs/subscribe/