Exploring M2M Information Exchange Patterns using Azure Service Bus

1. Exploring M2M Information Exchange Patterns using Azure Service Bus Abhishek Lal | Senior Program Manager, Azure Service Bus Miranda Luna | Product Manager, Windows Azure Mobile

2. Agenda

3. Join the MVA Community! • Microsoft Virtual Academy—Free online training! • Ask questions in the Born to Learn MVA Forum! • Visit http://aka.ms/MVAForum • Earn while you learn! • 50 MVA Points for this event! • Visit http://aka.ms/MVA-Voucher • Code: BldgBlks3

4. 01 | Introduction to M2M

5. What are devices? • Special purpose devices (not general purpose computers) • Small footprint – sensors, controllers, wearable • Diverse processor architectures • Non-standard Operating Systems • Specialized development environments • Some hobbyist platforms – • .NET Gadgeteer • Arduino

6. Connectivity considerations Types Metering Directionality Styles • Device to Network • Device to Device to Network • Device to Gateway to Network • One Way Up • One Way Down • Bi-directional • None • Wired • WiFi • NFC • Metered connection • Always • Occasionally • Non-metered connection • Bluetooth • GSM • GPRS • More Protocols Approach Location Power • HTTP/S • AMQP/S • MQTT • Custom Protocols • CoAP • Fixed location indoor • Fixed location outdoors • Occasionally mobile • Wired Power • Rechargeable Battery • Disposable Battery • IPV6 • VPN • Service Assisted

7. Patterns of communication 1:N 1:N Telemetry Information flowing from a device to other systems for conveying status of device and environment Inquiries Requests from devices looking to gather required information or asking to initiate activities Commands Commands from other systems to a device or a group of devices to perform specific activities Notifications Information flowing from other systems to a device (-group) for conveying status changes in the rest of the world

8. 02 | Key concepts

9. Windows Azure Service Bus 101 • Queues • brokered messaging communication model • components of an application don’t communicate directly, but rather exchange messages via an intermediary queue • One-to-one, asynchronous, follows FIFO • Topics & Subscriptions • pub/sub messaging communication model • components of an application don’t communicate directly, but rather exchange messages via an intermediary topic • one-to-many, can register multiple subscriptions to a topic, each message sent to a topic is available for each subscription to handle independently

10. Queues Decouple sender and receiver One or many senders. One or many (competing) receivers. Sender Receiver Sender Receiver Sender Receiver Sender Load leveling Receiver is never overloaded, process at its own pace. Temporal decoupling Allows taking the receiver offline for servicing. Load balancing Multiple receivers compete for messages.

11. Topics & Subscriptions Senders send to a topic Receivers receive from subscription Each subscription has one copy of the message. Filters, Rules and Actions F1 Receiver Sender Sender Receiver Sender F2 Receiver Message distribution Deliver the same message to more than one client. Subscribers can filter by interest. Message partitioning Receiver get mutually exclusive slices of the message stream.

12. Filters • Filters act on message properties. • Up to 2000 rules per subscription. • SQL ‘92 expressions over message properties. • Filter action allows to add/remove/change message properties. • Partition by filtering on mutually exclusive ranges.

13. Service Assisted Communication (aka.ms/iot5) DNS+ Device Mapped via Mplx Protocol or Port Connections are device-initiated and outbound (like VPN) NAT/FW Device (Router) Service Gateway Client Device does not actively listen for unsolicited traffic (unlike VPN) Port Mapping is automatic, outbound (like VPN) Public address, full and well defendable server platform No inbound ports open, attack surface is minimized IPv4 NAT

14. Service Bus a Polyglot Messaging Service “SBMP” high perf. .NET only HTTP high reach lower perf. AMQP 1.0 high perf high reach App ( .NET ) App ( any language ) App ( any language ) SB .NET Lib SB Wrappers Community Libs “SBMP” HTTP AMQP 1.0 Windows Any OS Any OS

15. SBMP/AMQP Binary Protocols Matter with Messaging • HTTP HTTP 1 Entity per Socket 1 Pending Operation per Socket 60s operation timeout (NAT/Prx) Client Client Socket Socket SBMP/AMQP Unlimited Multiplexed Entities and Unlimited Pending Ops per Socket No fixed operation timeout Session Support (coming in AMQP) Q S N Q S N T T

16. AMQP 1.0 Standardization OASIS Standard since October 2012 The culmination of several years effort by more than 20 companies Technology vendors: Axway Software, Huawei Technologies, IIT Software, INETCO Systems, Kaazing, Microsoft, Mitre Corporation, Primeton Technologies, Progress Software, Red Hat, SITA, Software AG, Solace Systems, VMware, WSO2, Zenika. User firms: Bank of America, Credit Suisse, Deutsche Boerse, Goldman Sachs, JPMorgan Chase Next is standardization via ISO/IEC JTC1

17. Platforms, Protocols and Client libraries Service Bus Queues & Topics Windows Other platforms SBMP(net.tcp, proprietary) AMQP 1.0 AMQP 1.0 https://github.com/windowsAzure/ HTTP(S) /azure-sdk-for-java/ /azure-sdk-for-node/ /azure-sdk-for-php/ Samples / Prototypes /azure-sdk-for-ruby/ HTTP(S) /azure-sdk-for-python/

18. 03 | Telemetry

19. Patterns of communication 1:N 1:N Telemetry Information flowing from a device to other systems for conveying status of device and environment Inquiries Requests from devices looking to gather required information or asking to initiate activities Commands Commands from other systems to a device or a group of devices to perform specific activities Notifications Information flowing from other systems to a device (-group) for conveying status changes in the rest of the world

20. Messages Broker Message • Brokered messaging properties are not SOAP headers • Properties are key/value pairs that may very well carry payloads • It’s not uncommon to have messages with empty message bodies • Message bodies are useful for a single opaque payload not exposed to the broker (e.g. encrypted content) Properties Value Key Value Key Value Key Value Key Body Body

21. Telemetry • Scheduled or event-driven stream of device status information • Physical or logical status or sensor readings. • Records are usually tiny; timestamp plus numbers. • Grand variety in frequencies. Once per week to 10 kHz for each of multiple metering points for factory machines.

22. Telemetry Types • User • Behavior of an individual, targeted user • User behavior, individualized experience • Business • Business activities and KPIs • Volume pumped, number of pump actions • Application • Health, performance & activity of the application layer and dependent services • Data client calls and logins, exceptions, API calls, sessions • Dependent services • Infrastructure • Health of the underlying system infrastructure • CPU, memory, network. • Available capacity, headroom

23. Using device to send telemetry messages

24. 03 | Notifications

25. Patterns of communication 1:N 1:N Telemetry Information flowing from a device to other systems for conveying status of device and environment Inquiries Requests from devices looking to gather required information or asking to initiate activities Commands Commands from other systems to a device or a group of devices to perform specific activities Notifications Information flowing from other systems to a device (-group) for conveying status changes in the rest of the world

26. Notification • Scheduled or event-driven message to device • Informs a device, remotely, about a relevant change or event • “Status of X has changed” • “You have reached your target” • “An update has been released” • Remote: Control service, handheld device, etc. • Latency requirements vary, from “real-time” to occasionally connected • Messages are usually tiny, metadata / data both may be included • Grand variety in frequencies. Once per year to few seconds

27. Broadcast Fan-Out Control System Fan-Out Partition Sub Sub Sub Sub Sub Sub Sub Sub Sub Topic Topic Topic

28. Broadcast Fan-Out Control System Fan-Out Partition Sub Sub Sub Sub Sub Sub Sub Sub Sub Device and Housing Unit based filter for the device subscription Topic Topic Topic DeviceId = 12345 ORHousingUnit = 8821 ORBroadcast = true

29. Create Subscriptions with Rules (Filters) TopicDescriptionmainTopic = namespaceManager.CreateTopic(“topicName"); namespaceManager.CreateSubscription(“topicName", “AuditSubscription"); namespaceManager.CreateSubscription(T“topicName", "FirstSubscription", newSqlFilter("Address LIKE '%First%'")); namespaceManager.CreateSubscription(T“topicName", “SecondSubscription", newSqlFilter("Address LIKE '%Second%'")); BrokeredMessagemyMessage = newBrokeredMessage(); myMessage.Properties.Add(“Address”, “First”); or myMessage.Properties.Add(“Address”, “Second”); or myMessage.Properties.Add(“Address”, “First,Second”);

30. Notifications with Topics

31. 03 | Command/Control/Inquiry

32. Patterns of communication 1:N 1:N Telemetry Information flowing from a device to other systems for conveying status of device and environment Inquiries Requests from devices looking to gather required information or asking to initiate activities Commands Commands from other systems to a device or a group of devices to perform specific activities Notifications Information flowing from other systems to a device (-group) for conveying status changes in the rest of the world

33. Command/Control/Inquiry • Tell a device or service, remotely, to execute a logical or physical activity • “Give me the status of X” • “Roll 2 feet forward” • “Track this object with the camera” • “Fetch firmware update” • Remote: Control service, handheld device, etc. • Latency requirements vary, but often “perceptibly imminent”

34. Request/Response channels • Single ingress and egress endpoint from device perspective • Can reuse Ingress queue across devices (fan-in) • Message payload properties used to capture metadata on device, command, status • Device is always addressable via Queue even if not connected • Ingress Queue provides load balancing/leveling QE QI

35. Request/response correlation

36. 03 | Resources

37. Summary and next steps.. • Covered key concepts and Service Bus basics • Identified patterns of communication and implementation details • Achieved unidirectional and bidirectional communication • Next Steps: Scale to millions of devices and messages

38. M2M at //build • Internet of Things (IoT) with Azure Service Bus • Wednesday 4/2 2:30 – 3:30 PM PST • Todd Holmquiest-Sutherland, Paolo Salvatori • @Skraelinger, @babosbird • Powerful mobile apps with Mobile Services and ASP.NET Web API • Friday 4/4 2:00 – 3:00 PST • Abhishek Lal • @AbhishekRLal • All videos will be available on Channel9

39. Device to Cloud Resources Service Bus Overview Documentation Tutorials AMQP 1.0 support Overview Developer Guide .NET Tutorial Java Tutorial Clemens Vasters Device to Cloud Series on Channel 9 Part 1 Prototyping Platforms Part 2 Pattern Overview and Commands with HTTP Part 3 Safer Commands via a Cloud Gateway Part 4 Intermediated, Service-Assisted Connectivity Part 5 Tunnel in Tunnel in Tunnel Part 6 Why End-to-End Security Matters Part 7 The Pi in the Car Part 8 OBDII to AMQP to Cloud