Connected Clients and Continuous Services with - PowerPoint Presentation

463 views
Uploaded On 2015-11-22

Connected Clients and Continuous Services with - PPT Presentation

Azure Service Bus Abhishek Lal AbhishekRLal Senior Program Manager Windows Azure WADB336 Connected clients amp continuous services Line of Business Application Event Aggregator ID: 201750

notification service windows bus service notification bus windows messaging app microsoft hubs platform clients scale message namespace http connected

Link:

Copy

Embed:

<iframe width="560" height="315" src="https://www.docslides.com/embed/201750" frameborder="0" allowfullscreen></iframe>

Download Presentation from below link

Download Presentation The PPT/PDF document "Connected Clients and Continuous Service..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.

Presentation Transcript

Slide1
Slide2

Connected Clients and Continuous Services with Azure Service Bus

Abhishek Lal (@AbhishekRLal)Senior Program ManagerWindows Azure

WAD-B336Slide3

Connected clients & continuous services

Line of Business Application

Event Aggregator

Team

Sharepoint

Site

…

Household Appliance

Phone, Tablet, PC

Point of Sale Kiosk

SaaS

Cloud Service Solution

Queues

Topics

Relays

Notification Hubs

Slide4

ROLE 1

ROLE 2

Q/T

Durable

1:1 – 1:n – Filtered

Sessions

w/State

De-duplication

Transactions

Batching

Scheduling & TTL

Auto-forwarding

Dead-lettering

Features:

And Many More…Service Bus: core messaging1-1 Queues1-n Topics & SubscriptionsScale

outResiliencyMessaging patternsSlide5

Cloud-Hosted Service

Service

On-Premises

Resources

Relay

Service Bus: hybrid

olutions

Relays / Queues / Topics

Location transparency

Scale

out

Turnkey

cloud

onnect

Resiliency

Messaging

patternsSlide6

What about connected clients?

Increasingly mobile workforceUse mobile devices (phones, tablets, laptops)BYOD means multi-platform devicesMachine-to-machine (M2M) sensor networks

Messaging challenges

Modern and engaging applications

Location transparency (

access to information/applications from corp n/w)

Heterogeneous clientsAddressabilityConnectivitySecurityResilienceSlide7

Messaging challenges

Modern and engaging applicationsLocation transparencyHeterogeneous clientsAddressability

onnectivity

Security

Resilience

Modern and engaging applications Slide8

Cloud-Hosted Service

Notification Hub

Connected Clients: engaging applications

Push Notifications

Notify

the user of some

event:

Updating a tile on a Windows Store

app

Alerting

a user with a

toast

Displaying a

badge

Support Heterogeneous Platforms

Windows

Store,

iOS

, Android, Windows

Phone, Blackberry

Different capabilities and protocols

Solve back-end challenges

Store and keep up to date the device information

Implement platform-specific protocolsSlide9

Notification HubsSlide10

Push notification lifecycle

Registration at app launchClient app contacts Platform Notification Service, to retrieve current device/channel handle (e.g. ChannelURIs, device tokens)

App updates handle in back-end

Sending Notification

App back-end send notification to the PNS

PNS pushes the notification to the app on the device

MaintenanceDelete expired handles when PNS rejects themPlatform

NotificationService

App back-end

Client appSlide11

Challenges of push notifications

Platform dependencyDifferent communication protocols to PNS’ (e.g. HTTP vs TCP, xml payload vs json payload)

Different presentation formats and capabilities (tiles

toasts

vs badges)RoutingPNS’ provide a way to send a message to a device/channelUsually notifications are targeted at users or interest groups (e.g. employees assigned to a customer account)

App back-end has to maintain a registry that associates device handles to interest groups and usersScaleApp back-end has to store current handles for each deviceAt high scale (millions of devices) results in high storage and computation costsBroadcast to millions of devices with low latency requires extensive parallelization (both DBs ad VMs)Slide12

Using Notification Hubs

One-time set upCreate a Notification Hub in Service BusIt contains the credentials required by the Platform Notification Service (PNS)

The client app retrieves its current handle from the PNS

Client app creates (or updates) a registration on the Notification Hub with the current handle

Send Notification

The app back-end sends a message to the Notification HubNotification Hub pushes it to the PNS’APNs

WNS

Service Bus

Notification Hub

App back-end

iOS app

Windows Store

appSlide13

Notification Hubs DemoSlide14

Advantages of using Notification Hubs

No platform-specific protocolsApp back-end just communicates with the Notification Hub.Avoid storing device information in the app back-endNotification Hub maintains the registry of devices and the associations to users/interest groupsBroadcastPush notifications to millions of devices (across platforms) with a single callSlide15

Using tags to route messages

Tags as interest groupsClient app can register with a set of tagsTags are simple strings (no pre-provisioning is required)App back-end can target all clients with the same tagYou can use tags also forMultiple type of interest groups, e.g.

ollow bands: tag “

followband:Beatles

”Follow users: tag “followuser:Alice”Tag devices with a user id

Service Bus

Notification Hub

App back-end

Tag:”Beatles

”

Tag:”Wailers

”

Tag:”Beatles

”Slide16

Using templates for multi-platform push

RegistrationClient apps can register with a platform specific template, e.g. Alice’s Surface registers with Windows Store ToastText01 templateBob’s iPhone with the Apple JSON template:{ aps: {alert: “

$(message)

”}}

Send notification

App back-end sends a platform independent message: {message: “Hello!”}Support for nativeNotification Hubs also supports platform payloads sent by the back-end(but no multi-platform broadcast)

Service Bus

Notification Hub

App back-end

<toast

visual

<binding template

=\"ToastText01

\">

text id=\"1

\">

$(message)

text

binding

visual

toast>

{

aps

{

alert

: “

$(message

)

”

}

{ message: “Hello!” }

Hello!

Hello

!Slide17

Use Notification Hubs at scale

Number of registrationsIn preview Notification Hubs are limited to 10.000 registrations.Contact us if you need more than 10,000 registrations before GA.Notification Hubs will scale up to millions of registrations

Do not shard

registrations across Notification Hubs for any scale less than a million.

Throughput/latency considerationsNotification Hubs have a fully scaled out architecture.Do not create multiple notification hubs to increase throughput and/or decrease latency.Slide18

Messaging challenges

Modern and engaging applicationsLocation transparencyHeterogeneous clientsAddressability

Connectivity

Security

Resilience

Location transparencySlide19

Connected Clients: location transparency

Service Bus RelaySecure access to local services from anywhere (a.k.a. “location transparency”)Cloud-projected endpoint acts as a proxy for the local service and relays messages (NAT traversal)

“Turnkey”

remoting

experience for services written in WCF – fast time to

marketBrokered MessagingDecoupling for apps, provides access from anywhere

Support for all common pub/sub patternsAdvanced messaging features like delivery guarantees, sessions, schedulingOptimized for hybrid apps (NAT traversal, WCF – NetMessagingBinding) Broad platform reach (.NET APP, Http API (wrapped for Azure-supported 4GL’s), AMQP 1.0 protocol)Slide20

Messaging challenges

Modern and engaging applicationsLocation transparencyHeterogeneous clientsC

onnectivity

Addressability

Security

Resilience

Heterogeneous clientsSlide21

Connected Clients: heterogeneous clients

Clients / Applications

NetMessagingBinding

.NET Service Bus Messaging API

.NET WCF Service Model

SB Messaging Protocol

(

net.tcp

, proprietary) AMQP 1.0

Service Bus

C/C++(incl Embedded)

Apache Proton-C

Windows (.NET)

Others (incl. non .NET Windows)

HTTP(S)

PHP

client

Node.js client

Pythonclient

Java/JMSApache Qpid JMS AMQP 1.0

Any HTTPclientSlide22

Messaging with Windows Store apps demoSlide23

Messaging challenges

Modern and engaging applicationsLocation transparencyHeterogeneous clientsAddressability

Connectivity

Security

Resilience

AddressabilitySlide24

Connected Clients: Addressability

Direct1-1 addressing between producer / consumerCommand & ControlPub-SubFew-Few addressing between producers and consumersInterest Based Filtering and Correlated Request/ResponseFan-out / Broadcast

1-Many between few producers and lots of consumers

Alerts and Notifications

Fan-in / Telemetry

Many-1 from lots of producers to one or few consumers Consumer scale apps and large scale ingress of sensor dataSlide25

Addressability - Direct

Using QueuesSingle queue provides for throughput (1000+messages/second) and buffering (upto 5Gb)Up to 10,000 queues per namespaceMultiplex and Correlate over a single Queue with Sessions

Shard across several Queues for throughput and scale

Using Topics

Topic with a single Subscription

Topic with many Subscriptions (mutually exclusive Filters on individual Subscriptions)Easily add an Audit/Debug tapSupport single producer and dynamic consumer scenarios

Using Notification HubsTags for identifying individual users or application instancesSingle Hub supports millions of user registrations Slide26

Addressability – Pub-Sub

Using Topics/SubscriptionsSingle Topic can support up to 2000 SubscriptionsEach Subscription can have Rules (Filters and Actions)Filters include SQL as well as Correlation (name/value)Up to 2000 SQL filters per Topic

Up to 100,000 Correlation filters per Topic (instance filtering)

Up to 100 concurrent connections per topic

Up to 100 concurrent competing consumers per Subscription

Using Notification HubsTarget particular groups of users with TagsMultiple tags supported – 60 Tags per registrationSlide27

Addressability – Fan-out / Broadcast

Using TopicsChain Topics/Subscriptions to achieve large number of SubscribersShard across Topics to achieve throughput and availabilityUsing Notification HubsBroadcast to all registrationsBroadcast to particular platformSlide28

Addressability – Fan-in / Telemetry

Using QueuesCan have one Queue per clientEasily fan-in messages to a single Queue using ForwardToBatching/Nagling of messages to reduce

round-trips

Using Topics

Shard across several Topics (may be geo-distributed)

Batching/Nagling of messages to reduce round-tripsConsumers have a Subscription per topicSlide29

Messaging challenges

Modern and engaging applicationsLocation transparencyHeterogeneous clients

Addressability

Security

Resilience

onnectivitySlide30

Connectivity: considerations

Brokered / Relay / PushBrokered messaging is when you create a addressable entity (Queue/Topic/Subscription)You can send directly to this entity or receive directly from this entityRelayed service endpoint allows you to achieve request/response between sender/receiverNo buffering of the messages in a Relay, sender/receiver need to both be available

Push messaging is when you use the socket provided by a Push Notification Service (Microsoft, Apple..)

Delivery is best effort and your are limited to each platform for features (Tiles vs. Badges)

Protocol support

TCP based persistent connections (AMQP, SBMP) are more efficient (supported by Brokered/Relay)These lower

cost and offer more features, but do not have the universal reach of HTTPDurable / VolatileBrokered messaging offers durable message storage (use TTL for message expiry)Relay offers no request/response bufferingPush notification is best-effort delivery from PNS providersSlide31

Connectivity: options

Durable message scenariosDurable data (Orders)Activity StreamsChatMulti-player games (Poker)Dashboards

Volatile message scenarios

In-app notifications (ticker/scores/news)

Collaboration

apps (second screen)Multi-player games (pong)Real-time monitoring

(stats)Interactive status change events (presence)Client platformsSmartphonesTablets / LaptopsSensors / Devices (M2M)BrowsersPopular Frameworks

SignalRSocket.ioFeatures supportedVolatile messaging Transport negotiation (WebSockets, HTTP)Simple APIsBroad platform reach (Browsers, IOS etc.)Slide32

Connectivity: scale out

Service Bus as scale-out backplane Scale out solutionsSignalR - http://github.com/signalr

Socket.io

http://

github.com/WindowsAzure/socket.io-servicebus

Devices

Browsers

Basic Devices

IIS (Node.js) Server

Service Bus TopicSlide33

Service Bus as scale out backplane DemoSlide34

Messaging challenges

Modern and engaging applicationsLocation transparencyHeterogeneous clientsAddressability

Connectivity

Security

Resilience

SecuritySlide35

Connected Clients: Security

Access Control Service (WAAD) Integrated AuthSTS service to enable federation with identity providers ACS issues SWT with specific claims, i.e., Send, Listen, ManageThese are specific to the Relying Party,

i.e., Service Bus Resource

Service

Bus Resource is a defined by a URI

Shared Access SignatureNew “Shared Access Signature” (SAS) authentication modelAbility to configure Authorization Rules at the Service Bus

namespace or entity levelAuthorization rules configured at namespace root grant rights to all entities in the namespaceEach Topic or Queue can have up to 12 rulesEach rule has an associated keyClients authenticate to Service Bus by signing the URI of accessed resource and an expiry with the keySlide36

Messaging challenges

Modern and engaging applicationsLocation transparencyHeterogeneous clientsAddressability

Connectivity

Security

Resilience

ResilienceSlide37

Connected Clients: Resilience

Cloud principlesSoftware will have bugsPeople will make mistakesHardware will failService Bus protects againstHardware: node crashes/disk

failures

Hardware: Network outages within datacenter

Software: Scaled out roles with active failover

Features to improve resilienceRelay - load-balancingMessaging - client retry

Messaging - Paired NamespacesSlide38

Relay load-balancing DemoSlide39

Resilience: Relay load-balancing

Connect Listeners to single EndpointServers/Services can be geo-distributedSessions load-balanced across listenersUp to 25 concurrent Listeners on an EndpointSlide40

Resilience: Messaging – client retry

MessagingFactory mf = MessagingFactory.Create

();

mf.RetryPolicy

= RetryExponential.Default

; // retry on transient errors until the OperationTimeout is reached mf.RetryPolicy

= RetryPolicy.NoRetry; // disables retry for transient errorsSlide41

Resilience: Messaging – send availability

Service

Bus

Namespace

Web / Frontend

Roles

Worker / Backend

RolesSlide42

Service

BusNamespace

Web / Frontend

Roles

Paired namespace – send behavior

Service

Bus

Paired NamespaceSlide43

Paired namespace – syphon

Service

Bus

Namespace

Web / Frontend

Roles

Service

Bus

Paired Namespace

Syphon enabled

Worker / Backend

RolesSlide44

Service

BusNamespace

Web / Gateway

Roles

Worker / Backend

Roles

Paired Namespace - receive scenario

Service

Bus

Paired NamespaceSlide45

API Shape

factory =

MessagingFactory

.Create

(

SB_Primary_NS_Address

);

factory.PairNamespace(new

SendAvailabilityPairedNamespaceOptions

{

EnableSyphon = true

TransferQueueCount = 10,

MessagingFactory =

paired-NS_factory,

NamespaceManager

= paired-NS_manager

});

factory.Open();Slide46

Paired Namespace - key considerations

Sessions and scheduled messages workOrdering is lostEnd-to-end receive latency will varyFixed set of transfer queues (limits size)Syphon can be selectively startedUser provisions secondary NamespaceB

illing implication – regular message operations applySlide47

Connected clients & continuous services

Line of Business Application

Event Aggregator

Team

Sharepoint

Site

…

Household Appliance

Phone, Tablet, PC

Point of Sale Kiosk

SaaS