WEBVTT

00:00:00.200 --> 00:00:07.200
[Music]

00:00:09.000 --> 00:00:10.900
Hi. I'm Abhishek Lal.

00:00:11.400 --> 00:00:15.360
I'm a Program Manager with Windows
Azure, and today I want to

00:00:15.460 --> 00:00:17.670
talk about Windows
Azure Service Bus.

00:00:18.530 --> 00:00:23.350
Service Bus allows you to build applications
and connect different

00:00:23.400 --> 00:00:25.990
rules between web and worker tiers.

00:00:26.620 --> 00:00:31.190
You can use this for low-leveling
or for decoupling where your

00:00:31.240 --> 00:00:34.780
web tier sends messages into a queue
and your worker tier pulls

00:00:34.830 --> 00:00:36.040
messages off them.

00:00:36.620 --> 00:00:41.350
We also support some very advanced
pub sub scenarios where publishers

00:00:41.400 --> 00:00:46.100
can send messages to topics and then
you can have several subscribers

00:00:46.450 --> 00:00:50.130
with messages. Today we will go
look at some of the new tooling

00:00:50.180 --> 00:00:54.920
in Visual Studio 2013 which supports
development with Azure Service Bus.

00:00:56.000 --> 00:00:59.980
With Azure you know that you can
build cloud scale applications

00:01:00.370 --> 00:01:01.470
for the enterprise.

00:01:02.240 --> 00:01:07.320
One of the key aspects of, and one
of the key services in Azure

00:01:07.370 --> 00:01:09.190
is the Windows Azure Service Bus.

00:01:10.090 --> 00:01:14.650
This provides you messaging and relay
services which really helps

00:01:14.700 --> 00:01:19.070
you unlock enterprise data
as well as business logic.

00:01:22.580 --> 00:01:27.040
With Azure Service Bus today we will
focus on the secure messaging

00:01:27.090 --> 00:01:33.330
capabilities and how these enable you
to build loosely coupled solutions.

00:01:37.680 --> 00:01:41.330
In addition, we are going to see
how you can achieve some rich

00:01:41.380 --> 00:01:45.060
publish subscribe scenarios
using Azure Service Bus.

00:01:48.700 --> 00:01:52.570
When we talk about tightly coupled
applications it's the case

00:01:52.620 --> 00:01:57.020
where a store front end may be
talking directly to a shipping

00:01:57.070 --> 00:02:01.790
service which directly then talks
to maybe the dispatch or the

00:02:01.840 --> 00:02:03.090
inventory services.

00:02:04.400 --> 00:02:09.600
This kind of a direct system has
a flaw that when one particular

00:02:09.650 --> 00:02:14.290
component is unavailable, say the
dispatch one, the errors are

00:02:14.340 --> 00:02:18.560
propagated all the way back because
there is no intermediate

00:02:18.830 --> 00:02:22.030
decoupling to protect
from these errors.

00:02:22.080 --> 00:02:28.470
In a more loosely coupled system
we see that errors are

00:02:29.710 --> 00:02:32.950
decoupled from the front end and
back end by putting a queue

00:02:33.000 --> 00:02:33.980
in the middle.

00:02:35.450 --> 00:02:40.340
In this case all the requests are sent
as messages into an order queue.

00:02:41.280 --> 00:02:44.580
The tracking system can then pull
these messages and send them

00:02:44.630 --> 00:02:45.890
over for delivery.

00:02:48.000 --> 00:02:52.090
If the tracking system for any reason
is unavailable, no -inaudible-

00:02:52.140 --> 00:02:55.910
messages from the front end continue
to go into the order's queue

00:02:56.540 --> 00:02:59.080
and thereby the system
continues to work.

00:02:59.640 --> 00:03:02.840
These orders will not be processed
until the tracking system

00:03:02.890 --> 00:03:07.210
is back online, but at that point
you'll be able to retrieve

00:03:07.260 --> 00:03:10.120
these orders and process
them for delivery.

00:03:11.430 --> 00:03:14.990
All this time, as you saw with loose
coupled applications, the

00:03:15.040 --> 00:03:18.590
front end remained available while
the tracking system could

00:03:18.640 --> 00:03:21.040
be taken off-line for upgrades.

00:03:24.680 --> 00:03:28.550
Consider the scenario where you have
several storefront end instances.

00:03:29.590 --> 00:03:33.400
They could be generating peak loads
where there are lots of messages

00:03:33.450 --> 00:03:36.950
and orders being generated which
the tracking system cannot keep

00:03:37.000 --> 00:03:41.140
up with and that point, by having
an order queue in the middle,

00:03:41.190 --> 00:03:43.220
you can achieve some load-balancing.

00:03:44.630 --> 00:03:48.900
This is where you have multiple instances
of the tracking system

00:03:48.950 --> 00:03:50.740
pulling from the same order queue.

00:03:51.680 --> 00:03:56.290
The key distinction here is that
you have multiple receivers

00:03:56.340 --> 00:04:01.230
on the same queue and they are
competing for messages so the

00:04:01.280 --> 00:04:05.930
same message is never seen by two
instances of the tracking system,

00:04:07.180 --> 00:04:10.830
but you are able to achieve some
load-balancing by increasing

00:04:10.880 --> 00:04:14.830
the number of worker rules you have
for your shipping service.

00:04:14.880 --> 00:04:20.900
With this, let me switch over to
Visual Studio and show you some

00:04:20.950 --> 00:04:25.320
of the developer tools we have to enable
development with this scenario.

00:04:26.740 --> 00:04:30.480
What I have installed here is the
Windows Azure Cloud Tools,

00:04:31.080 --> 00:04:34.880
and here on the left-hand side in
Silver Explorer you are able

00:04:34.930 --> 00:04:38.550
to see that I have my Service
Bus Name Spaces listed.

00:04:39.350 --> 00:04:43.530
If you log in and do not see any
namespace available here, head

00:04:43.580 --> 00:04:48.540
over to the Windows Azure Portal
at WindowsAzure.com, and from

00:04:48.590 --> 00:04:53.160
there you'll be able to easily create
a new namespace by selecting

00:04:53.210 --> 00:04:55.290
which region it is located in.

00:04:58.510 --> 00:05:02.460
With my name spaces listed here
I can easily enumerate through

00:05:02.510 --> 00:05:05.800
the queues and the topics
which I have created.

00:05:07.570 --> 00:05:11.330
We provide you with some additional
debugging information so

00:05:11.380 --> 00:05:14.380
you can go over to a particular
queue and view its properties.

00:05:18.170 --> 00:05:21.730
Note how I am able to see I have
lots of active messages in this

00:05:21.780 --> 00:05:26.340
queue, when the queue was
created, as well as

00:05:27.860 --> 00:05:32.940
important values like the maximum
delivery count and the max

00:05:32.990 --> 00:05:34.090
size of the queue.

00:05:34.780 --> 00:05:38.240
So we can see all the different
properties that are necessary

00:05:38.290 --> 00:05:39.200
for this queue.

00:05:40.050 --> 00:05:44.720
Right from Visual Studio I have the
ability to create new objects

00:05:49.960 --> 00:05:53.800
as well as modify all the
key properties for that.

00:05:57.790 --> 00:06:02.020
Once my new queue is available
I can see it has no messages I

00:06:02.070 --> 00:06:07.210
can actually send a test message
to it, and you will notice that

00:06:07.260 --> 00:06:11.150
the properties are updated and you
are able to see all the latest

00:06:11.200 --> 00:06:14.640
properties on the queue with the
Active Message Count increased

00:06:14.690 --> 00:06:15.160
to 1.

00:06:16.610 --> 00:06:19.910
Also note that it shows you when
was the last time the queue

00:06:19.960 --> 00:06:24.710
was accessed. I can go receive
a message from here

00:06:26.020 --> 00:06:30.080
and that again will bring the Active
Message Count back down

00:06:30.130 --> 00:06:30.780
to zero.

00:06:33.320 --> 00:06:38.990
These tools really help you debug
and get a very, very rich insight

00:06:39.040 --> 00:06:42.290
into all your active entities
with Service Bus.

00:06:44.120 --> 00:06:47.570
Now to use this I'm going
to create a new project

00:06:50.260 --> 00:06:55.410
in which I'm going to choose the Windows
Azure Cloud Service Project.

00:06:57.630 --> 00:07:01.160
Of the several templates that are
available to me, one of them

00:07:01.210 --> 00:07:04.380
is a worker rule with this Bus queue.

00:07:07.740 --> 00:07:10.600
I will add that to my project
and hit Create.

00:07:14.450 --> 00:07:19.170
What this gives me is all the code
needed for me to go list it

00:07:19.220 --> 00:07:23.850
on a particular queue for messages and then
process these particular messages.

00:07:23.900 --> 00:07:28.250
Now I have the code loaded here.
Let me walk you through some

00:07:28.300 --> 00:07:30.700
of the different sections here.

00:07:31.990 --> 00:07:36.120
At the start we create a particular
queue name, say the processing

00:07:36.170 --> 00:07:36.690
queue, and

00:07:37.920 --> 00:07:43.410
at that point we will, in the run
method, called a single method

00:07:43.460 --> 00:07:45.340
of client.on message.

00:07:46.060 --> 00:07:50.890
Queue client is initialized
in the on start method

00:07:52.910 --> 00:07:56.880
and it uses the particular queue
name that you specified earlier.

00:07:58.370 --> 00:08:02.000
I'm going to change this
to my processing queue.

00:08:03.390 --> 00:08:08.520
When you make an on message call, any
messages that become available

00:08:08.570 --> 00:08:13.780
on that endpoint are then sent
to your processing function.

00:08:15.820 --> 00:08:21.120
Note here I have a simple trace
of writing out what the message

00:08:21.170 --> 00:08:22.120
was received.

00:08:23.050 --> 00:08:26.520
So in the demo you saw how you can
easily create a worker rule

00:08:26.570 --> 00:08:30.190
project and receive on
messages from a queue.

00:08:31.590 --> 00:08:34.870
The one additional concept I want
to show you is that of a topic.

00:08:35.890 --> 00:08:39.550
In this case the stores are sending
messages to a single topic

00:08:40.200 --> 00:08:44.190
but they might be multiple subscriptions
which are receiving

00:08:44.240 --> 00:08:45.820
those messages.

00:08:46.440 --> 00:08:49.570
Think of a case where you have
a script in -inaudible- system

00:08:49.620 --> 00:08:54.660
and a separate tracking system.
Here you want the same message

00:08:55.030 --> 00:08:59.710
to be sent to both and that is exactly
what is happening in this

00:08:59.760 --> 00:09:01.820
particular scenario.

00:09:02.730 --> 00:09:06.190
When you create subscriptions you
can add filters to them which

00:09:06.240 --> 00:09:08.840
decide which messages go
to which subscription,

00:09:10.130 --> 00:09:14.310
and those messages can be duplicated
between subscriptions or

00:09:14.360 --> 00:09:18.040
you can have mutually exclusive
filters where a single message

00:09:18.090 --> 00:09:19.620
goes to a single subscription.

00:09:20.720 --> 00:09:25.420
These kind of rich pub sub scenarios
really enables you to build

00:09:25.470 --> 00:09:29.780
connected systems by decoupling
your front ends as well as your

00:09:29.830 --> 00:09:36.370
worker tiers and achieving very, very
scalable and connected services.

00:09:36.420 --> 00:09:41.360
With Azure Service Bus we saw today
how it is so easy to build

00:09:41.410 --> 00:09:46.420
multi-tier applications with web
tier and worker tiers both being

00:09:46.470 --> 00:09:51.020
connected through queues or using
publish subscribe patterns

00:09:51.070 --> 00:09:53.060
with topics and subscriptions.

00:09:53.730 --> 00:09:58.940
The Azure Tooling within Visual Studio
2013 makes it really easy

00:09:58.990 --> 00:10:01.210
for you to double up these
decoupled applications.