Watch videos with subtitles in your language, upload your videos, create your own subtitles! Click here to learn more on "how to Dotsub"


0 (0 Likes / 0 Dislikes)
>> In this video, we'll discuss communication strategies and Azure APIs. Let's suppose for a moment that you're planning the architecture of a music sharing application. Before you can choose the right Azure technology, you must understand each individual communication exchange between the components of the application. This is important because for each type of communication exchange, you would potentially need to choose a different Azure technology to facilitate the exchange. With that said, there are two parties at any given communication between distributed applications, the receiver and the sender. The sender can either send messages or raise events. Some Azure technologies target messages, while others target events. It's a subtle but very important distinction, so let's talk about the differences. A message contains raw data produced by one component that will be consumed by another component. It contains the data itself, not just a reference to that data. Also, the sending component expects the message content to be processed in a certain way by the destination component. Suppose a user uploads a new song by using the mobile music sharing app, the mobile app must sent that song to the web API that runs it in Azure. The song media file itself must be sent as well, not just the alert indicating that a new song was added. The mobile app expects that the web API will store that new song in the database and make it available to other users. An event, however, is different. First, it's a lightweight notification that indicates that something has happened. Second, it does not include the data that triggered the event, although it might include a location to where the data is actually stored. Finally, the publisher of the event has no expectation about the action that the receiving component will take. Some events are discreet units and unrelated to other events, while some events are part of a related and ordered series. Now, let's suppose that music file upload has been completed and the new song has been added to the database. In order to inform users of the new file, the web API must inform the web front-end and mobile app, both users of this new file. Now note that the users can choose whether to listen to the new song, so the initial notification does not include the music file, but only notifies users that the song exists. Okay, let's bring this back to communication strategies and Azure APIs. A single application is likely to use events for some purposes and messages for others. To help you choose which one, ask yourself these two questions. One, does the sending component expect the communication to be processed in a particular way by the destination component? And two, does the communication include the data or payload that provoked it? If the answer is, to either of these two questions, a yes, then use a message. If the answer to both of these questions is a no, then you would use an event. Finally, once you understand why your components communicate and whether they use events or messages, you can then proceed to choose whichever is the right technology designed for the purposes that you need. It's either going to be Azure Storage Queues, Event Hubs, Event Grids, or Service Bus.  

Video Details

Duration: 3 minutes and 20 seconds
Language: English
License: Dotsub - Standard License
Genre: None
Views: 6
Posted by: csintl on Aug 29, 2018


Caption and Translate

    Sign In/Register for Dotsub above to caption this video.