WEBVTT

00:00:00.200 --> 00:00:07.200
[La seguente traduzione è fornita da Bing Translator]


00:00:09.000 --> 00:00:10.900
Alta. Mi Abhishek Lal.

00:00:11.400 --> 00:00:15.360
Sono Program Manager per Windows
Azure e oggi si desidera

00:00:15.460 --> 00:00:17.670
parlare di Windows
Bus di servizio Azure.

00:00:18.530 --> 00:00:23.350
Bus di servizio consente di creare applicazioni
e connettere diversi

00:00:23.400 --> 00:00:25.990
regole tra livelli web e il lavoratore.

00:00:26.620 --> 00:00:31.190
È possibile utilizzare per il livellamento in basso
o per la separazione dove il

00:00:31.240 --> 00:00:34.780
livello Web invia i messaggi in una coda
tira il livello di lavoro e

00:00:34.830 --> 00:00:36.040
messaggi da loro.

00:00:36.620 --> 00:00:41.350
Supportiamo anche alcune molto avanzate
scenari secondari pub dove autori

00:00:41.400 --> 00:00:46.100
può inviare messaggi agli argomenti e quindi
è possibile avere più server di sottoscrizione

00:00:46.450 --> 00:00:50.130
con i messaggi. Oggi verranno esaminate
esaminati alcuni dei nuovi strumenti di applicativi

00:00:50.180 --> 00:00:54.920
in Visual Studio 2013 che supporta
sviluppo con Bus di servizio Azure.

00:00:56.000 --> 00:00:59.980
Con Azure è sapere che è possibile
creazione di applicazioni su cloud

00:01:00.370 --> 00:01:01.470
per l'azienda.

00:01:02.240 --> 00:01:07.320
Uno dei principali aspetti di e uno
i servizi principali in Azure

00:01:07.370 --> 00:01:09.190
è il Bus di servizio Windows Azure.

00:01:10.090 --> 00:01:14.650
Ciò consente di messaggistica e inoltro
servizi che aiuta davvero

00:01:14.700 --> 00:01:19.070
Per sbloccare i dati aziendali è
Oltre a regole di business.

00:01:22.580 --> 00:01:27.040
Con Bus di servizio Azure oggi ci sarà
concentrarsi sulla protezione dei messaggi

00:01:27.090 --> 00:01:33.330
funzionalità e come queste consentono di
Per creare soluzioni con accoppiamento ridotto.

00:01:37.680 --> 00:01:41.330
Inoltre, non abbiamo intenzione di vedere
come è possibile ottenere alcune RTF

00:01:41.380 --> 00:01:45.060
pubblicare gli scenari di sottoscrizione
utilizzo di Azure Bus di servizio.

00:01:48.700 --> 00:01:52.570
Quando si parla strettamente accoppiati
nel caso di applicazioni

00:01:52.620 --> 00:01:57.020
Qualora un archivio di front-end può essere
parlando di spedizione

00:01:57.070 --> 00:02:01.790
servizio che comunica direttamente di quindi
per forse la spedizione o la

00:02:01.840 --> 00:02:03.090
servizi di magazzino.

00:02:04.400 --> 00:02:09.600
Questo tipo di un sistema diretto
un difetto che quando una determinata

00:02:09.650 --> 00:02:14.290
componente non è disponibile, pronunciare il
invio di uno, gli errori sono

00:02:14.340 --> 00:02:18.560
propagate completamente quanto
non vi è alcun intermediate

00:02:18.830 --> 00:02:22.030
separazione per proteggere
Questi errori.

00:02:22.080 --> 00:02:28.470
In un sistema più accoppiamento
Vediamo che gli errori sono

00:02:29.710 --> 00:02:32.950
separate da front-end e
back-end mediante l'inserimento di una coda

00:02:33.000 --> 00:02:33.980
nella parte centrale.

00:02:35.450 --> 00:02:40.340
In questo caso tutte le richieste vengono inviate
come messaggi in una coda di ordine.

00:02:41.280 --> 00:02:44.580
Il sistema di rilevamento può quindi richiedere
Questi messaggi e inviarli

00:02:44.630 --> 00:02:45.890
in consegna per il recapito.

00:02:48.000 --> 00:02:52.090
Se il sistema di rilevamento per qualsiasi motivo
non è disponibile, non - impercettibile -

00:02:52.140 --> 00:02:55.910
continuano i messaggi provenienti da front-end
Passare alla coda dell'ordine

00:02:56.540 --> 00:02:59.080
e in tal modo il sistema
continua a funzionare.

00:02:59.640 --> 00:03:02.840
Questi ordini non verranno elaborati.
fino a quando il sistema di rilevamento

00:03:02.890 --> 00:03:07.210
è in linea, ma a quel punto
è possibile recuperare

00:03:07.260 --> 00:03:10.120
questi ordini e il processo
tali informazioni per la consegna.

00:03:11.430 --> 00:03:14.990
Tutto questo tempo, come si è visto con separati
insieme di applicazioni, il

00:03:15.040 --> 00:03:18.590
front-end è rimasto disponibile durante
il sistema di rilevamento Impossibile

00:03:18.640 --> 00:03:21.040
modalità non in linea per gli aggiornamenti.

00:03:24.680 --> 00:03:28.550
Si consideri lo scenario in cui è stato
diverse istanze di vetrina fine.

00:03:29.590 --> 00:03:33.400
Potrebbe essere di carichi di picco generazione
Se esistono molti messaggi

00:03:33.450 --> 00:03:36.950
e gli ordini di essere generato che
non è possibile mantenere il sistema di rilevamento

00:03:37.000 --> 00:03:41.140
le attività e quel punto, facendo in modo che
una coda di ordine al centro,

00:03:41.190 --> 00:03:43.220
è possibile ottenere un bilanciamento carico.

00:03:44.630 --> 00:03:48.900
Si tratta di cui si dispone di più istanze
del sistema di rilevamento

00:03:48.950 --> 00:03:50.740
estrarre dalla stessa coda di ordine.

00:03:51.680 --> 00:03:56.290
Qui la differenza principale è che
si dispone di più ricevitori

00:03:56.340 --> 00:04:01.230
nella stessa coda e sono risultati
competizione per i messaggi in modo che il

00:04:01.280 --> 00:04:05.930
stesso messaggio non viene mai viste dai due
istanze del sistema di rilevamento,

00:04:07.180 --> 00:04:10.830
ma è in grado di ottenere alcuni
bilanciamento del carico aumentando

00:04:10.880 --> 00:04:14.830
il numero di regole di lavoro che è necessario
per il servizio di spedizione.

00:04:14.880 --> 00:04:20.900
Con questo, Consenti all'utente di passare a
Visual Studio e illustrano alcuni

00:04:20.950 --> 00:04:25.320
gli strumenti di sviluppo è necessario attivare
sviluppo con questo scenario.

00:04:26.740 --> 00:04:30.480
È ciò che è stato installato il
Strumenti Cloud Windows Azure,

00:04:31.080 --> 00:04:34.880
e qui a sinistra in
Argento Explorer sono in grado di

00:04:34.930 --> 00:04:38.550
Per sapere che ho il servizio
Bus spazi dei nomi elencati.

00:04:39.350 --> 00:04:43.530
Se l'accesso e non sono disponibili
spazio dei nomi disponibili qui, head

00:04:43.580 --> 00:04:48.540
nel Windows Azure Portal
in WindowsAzure.com e da

00:04:48.590 --> 00:04:53.160
non vi sarà possibile creare facilmente
un nuovo spazio dei nomi selezionando

00:04:53.210 --> 00:04:55.290
quale area si trova in.

00:04:58.510 --> 00:05:02.460
Con mio spazi dei nomi elencati di seguito
È possibile enumerare facilmente

00:05:02.510 --> 00:05:05.800
le code e gli argomenti
che ho creato.

00:05:07.570 --> 00:05:11.330
Consentiamo di alcune ulteriori
pertanto le informazioni di debug

00:05:11.380 --> 00:05:14.380
è possibile passare a un particolare
coda e visualizzarne le proprietà.

00:05:18.170 --> 00:05:21.730
Si noti come sono in grado di sapere che ho
molti messaggi attivi in questo

00:05:21.780 --> 00:05:26.340
coda, quando la coda era
creazione, nonché

00:05:27.860 --> 00:05:32.940
valori importanti, come il valore massimo
conteggio di consegna e max

00:05:32.990 --> 00:05:34.090
dimensione della coda.

00:05:34.780 --> 00:05:38.240
Per visualizzare tutti i diversi
proprietà che sono necessari

00:05:38.290 --> 00:05:39.200
per questa coda.

00:05:40.050 --> 00:05:44.720
Direttamente da Visual Studio è necessario il
possibilità di creare nuovi oggetti

00:05:49.960 --> 00:05:53.800
nonché come modificare tutte le
proprietà per tale chiave.

00:05:57.790 --> 00:06:02.020
Una volta che è disponibile la nuova coda
Posso vedere non dispone di alcun messaggio è

00:06:02.070 --> 00:06:07.210
inviare un messaggio di prova
e si nota che

00:06:07.260 --> 00:06:11.150
le proprietà vengono aggiornate e si
sono in grado di visualizzare tutti i più recenti

00:06:11.200 --> 00:06:14.640
proprietà sulla coda con il
Numero di messaggi attivi è aumentato

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

00:06:16.610 --> 00:06:19.910
Si noti inoltre che si mostra quando
è stata l'ultima volta che la coda

00:06:19.960 --> 00:06:24.710
è stato eseguito. È possibile attivare la ricezione
un messaggio da qui

00:06:26.020 --> 00:06:30.080
e che verrà visualizzata nuovamente attivo
Eseguire il conteggio dei messaggi verso il basso

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

00:06:33.320 --> 00:06:38.990
Questi strumenti consentono effettivamente di eseguire il debug
e un ricco molto informazioni

00:06:39.040 --> 00:06:42.290
in tutte le entità attive
con Bus di servizio.

00:06:44.120 --> 00:06:47.570
Per utilizzare questa opzione si esamineranno ora
Per creare un nuovo progetto

00:06:50.260 --> 00:06:55.410
in cui devo scegliere Windows
Progetto di servizio Cloud Azure.

00:06:57.630 --> 00:07:01.160
Dei diversi modelli che sono
per me, uno di essi

00:07:01.210 --> 00:07:04.380
è una regola di lavoro con la coda di Bus.

00:07:07.740 --> 00:07:10.600
Che verranno aggiunte al progetto
e scegliere Crea.

00:07:14.450 --> 00:07:19.170
Che cosa si ottiene così è tutto il codice
necessità per l'utente corrente visualizzare l'elenco

00:07:19.220 --> 00:07:23.850
in una specifica coda di messaggi e quindi
elaborare i messaggi particolari.

00:07:23.900 --> 00:07:28.250
Viene visualizzato il codice caricato qui.
Consenti all'utente vengono analizzate alcune

00:07:28.300 --> 00:07:30.700
di seguito le sezioni diverse.

00:07:31.990 --> 00:07:36.120
All'inizio è possibile creare un particolare
nome della coda, pronunciare l'elaborazione

00:07:36.170 --> 00:07:36.690
coda, e

00:07:37.920 --> 00:07:43.410
a questo punto ci sarà, nell'esecuzione del
metodo, chiamato un metodo singolo

00:07:43.460 --> 00:07:45.340
del messaggio client.on.

00:07:46.060 --> 00:07:50.890
Client coda viene inizializzato
nel metodo start su

00:07:52.910 --> 00:07:56.880
e utilizza la coda particolare
nome specificato in precedenza.

00:07:58.370 --> 00:08:02.000
Verrà modificato
la coda di elaborazione.

00:08:03.390 --> 00:08:08.520
Quando si effettua un messaggio via chiamati eventuali
messaggi diventano disponibili

00:08:08.570 --> 00:08:13.780
su tale endpoint vengono quindi inviati
per la funzione di elaborazione.

00:08:15.820 --> 00:08:21.120
Si noti qui che dispone di una traccia semplice
di scrittura che il messaggio

00:08:21.170 --> 00:08:22.120
è stato ricevuto.

00:08:23.050 --> 00:08:26.520
In modo che nella demo si è visto come può
creare facilmente una regola di lavoro

00:08:26.570 --> 00:08:30.190
progetto e visualizzato in
messaggi da una coda.

00:08:31.590 --> 00:08:34.870
Il concetto di ulteriore uno desiderato
per mostrarvi è quello di un argomento.

00:08:35.890 --> 00:08:39.550
In questo caso inviano gli archivi
messaggi a un singolo argomento

00:08:40.200 --> 00:08:44.190
ma potrebbe essere più sottoscrizioni
ricezione di cui

00:08:44.240 --> 00:08:45.820
tali messaggi.

00:08:46.440 --> 00:08:49.570
Essere considerato un caso in cui è stato
uno script nel sistema - impercettibile-

00:08:49.620 --> 00:08:54.660
e un sistema di rilevamento separato.
Qui si desidera che il messaggio stesso

00:08:55.030 --> 00:08:59.710
per essere inviato a entrambi e che è esattamente
Ciò che accade in questo

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

00:09:02.730 --> 00:09:06.190
Quando si creano le sottoscrizioni è
possibile aggiungere filtri ai loro che

00:09:06.240 --> 00:09:08.840
decidere quali messaggi Vai
a quale abbonamento

00:09:10.130 --> 00:09:14.310
e tali messaggi possono essere duplicati.
tra le sottoscrizioni o

00:09:14.360 --> 00:09:18.040
è possibile si escludono a vicenda
Filtra dove un singolo messaggio

00:09:18.090 --> 00:09:19.620
fino a una singola sottoscrizione.

00:09:20.720 --> 00:09:25.420
Questi scenari di tipo di rich pub sub
Consente di compilare effettivamente

00:09:25.470 --> 00:09:29.780
sistemi connessi da separazione
il server front-end, nonché il

00:09:29.830 --> 00:09:36.370
livelli di lavoro, ottenendo così molto, molto
servizi scalabili e connessi.

00:09:36.420 --> 00:09:41.360
Con Bus di servizio Azure abbiamo visto oggi
come è facile da compilare

00:09:41.410 --> 00:09:46.420
applicazioni a più livelli con web
corso di livello e livelli di lavoro

00:09:46.470 --> 00:09:51.020
connesso tramite code o utilizzo
pubblicare modelli di sottoscrizione

00:09:51.070 --> 00:09:53.060
con gli argomenti e le sottoscrizioni.

00:09:53.730 --> 00:09:58.940
Azure utensile all'interno di Visual Studio
2013 è davvero semplice

00:09:58.990 --> 00:10:01.210
Consente di raddoppiare il backup di questi
applicazioni separate.