2 - The Microsoft Azure Media Services Video-on-Demand Scenario

Contoso is a startup ISV company of approximately 20 employees that specializes in developing solutions using Microsoft technologies. The developers at Contoso are knowledgeable about various Microsoft products and technologies, including the .NET Framework, Microsoft Azure, the Windows Runtime, and Windows Phone.

Contoso has been contracted to develop a video-on-demand service as an end-to-end solution. The service must work with multiple devices and platforms, with the client application for the Windows Runtime expecting the highest usage. While the primary purpose of the client applications is to consume videos whose details are stored in a Content Management System (CMS), the applications are also required to be able to capture and upload new videos for encoding by Azure Media Services, which can then be consumed from the CMS once encoding has completed. Access to the CMS and Media Services is through the Contoso web service.

This chapter describes the business requirements of the Contoso Video applications, and summarizes the architecture of their solution.

Using the Contoso Azure Media Services video application

The purpose of the Contoso video application is to enable users to consume video-on-demand, stored in the cloud, from a CMS. The customer's experience is paramount, so the designers at Contoso chose to implement the applications as a series of easy to use, mobile applications. The Contoso video application is available for the Windows Runtime, Windows Phone 8, iOS, Android, and the web.

The video application implements the features typical of many video-on-demand services. It enables users to browse videos, and control the playback of selected videos. When viewing videos the application also suggests other related items that the user may want to view.

Contoso expects that the Windows Store video application will gain the highest usage among their clients' customers. Therefore, this guide focuses on the Contoso Windows Store video application, and its interaction with the Contoso web service.

The following sections describe the primary business use cases of the Windows Store Contoso video application in more detail.

Browsing videos

When the user starts the application the first page displays thumbnails for each video that can be viewed, as shown by the following screenshot.

Thumbnails for each video that can be viewed

Users can use pointing devices or touch gestures to browse these thumbnails. Clicking on a thumbnail navigates to a new page from where the video can be viewed. Alternatively users can use the bottom app bar to capture a new video or upload an existing video.

Christine says:
	Users prefer an application that fits well with the device's design and theme. You will also have to comply with certain UI design guidelines if you want to distribute your application through the Windows Store.

For information on how the browsing video use case is implemented, see "Chapter 5 – Delivering and Consuming Video."

Playing videos from Azure Media Services

To play videos users must have selected a video on the initial page of the application. Users can then control the playback of videos using pointing devices or touch gestures, as shown in the following figure.

Video playback

As well as controlling the playback of the video, basic information is also displayed to users, including the duration of the video, a description of it, and a list of related videos.

Capturing videos

The video application also allows users to capture video, which they can then choose to upload to Media Services for encoding, prior to making it available for consumption for other users, as shown in the following figure.

Capturing video

Users can configure their camera options, set a timed recording, and configure the recording mode of the camera.

Christine says:
	You should always be aware of how your application consumes the resources on a device, such as bandwidth, memory, and battery power. These factors are far more significant on mobile devices than on the desktop.

Uploading videos into Azure Media Services

User can choose to upload media stored on their device to Media Services for encoding, prior to making it available for consumption by all users. Videos can be stored anywhere in the file system, and can either have been captured on the device, or downloaded to the device from other locations. The following figure shows the page that allows users to choose a video to upload for encoding.

Choosing a video to upload to Media Services

When the user selects a video, using either a pointing device or a touch gesture, the Open button should be selected to begin the upload process. The first step in the upload process is to enter basic video details, as shown in the following figure.

The video details that must be provided prior to upload

The user must enter a title, description (optional), and select the resolution they'd like the video to be encoded to. When the Create button is selected the upload process begins, as shown in the following figure.

A video uploading for processing by Media Services

The user can choose to cancel the upload at any point, or allow the upload to proceed until it completes. A failure message is displayed to the user if the upload process fails.

When a video has been successfully uploaded the video details are saved to the CMS, and the encoding process begins. The Contoso has opted to always encode videos to adaptive bitrate MP4s, and then uses dynamic packaging to convert the adaptive bitrate MP4s to smooth streaming, HLS, or MPEG DASH, on demand. For more information about dynamic packaging see "Dynamic packaging."

Once a video has been successfully encoded it can be selected for viewing from the initial page of the application.

For information on how the uploading video use case is implemented, see "Chapter 3 – Uploading Video."

Understanding the Contoso Azure Media Services application architecture

The developers at Contoso are knowledgeable about various Microsoft products and technologies, including the .NET Framework, the Entity Framework, Azure, and the Windows Runtime, so they decided to implement the solution using these technologies.

Building and hosting a video-on-demand service is a major undertaking and can require a significant investment in hardware, management, and other infrastructure resources. Connectivity and security are also major concerns because users require timely and responsive access, and at the same time the system must maintain the integrity of the data and the privacy of users' information. To support a potentially large number of concurrent users against an ever-expanding collection of videos, the staff at Contoso chose to implement the video-on-demand service by using Azure Media Services. Media Services allows you to build scalable, cost effective, end-to-end media distribution solutions that can upload, encode, package, and stream media to a variety of devices and platforms. In addition, the Azure environment provides the necessary scalability, reliability, security, and performance necessary for supporting a large number of concurrent, distributed users.

The following figure shows a high-level overview of the solution.

A high-level overview of the Contoso Media Services solution

Client applications communicate with the video-on-demand service through a REST web interface. This interface allows applications to retrieve, upload, and publish videos. When a video is uploaded for processing by Media Services it is stored in Azure Storage, with the video details being stored in the CMS. It's then encoded to a set of adaptive bitrate MP4s, which can be converted by dynamic packaging to smooth streaming, HLS, or MPEG-DASH, on demand. For more information about dynamic packaging see "Dynamic packaging."

When a video is consumed by applications, its URL is retrieved from the CMS and returned to the application. The application then requests the URL content from the Media Services Origin Service, which processes the outbound stream from storage to client app. For more information about the Origin Service, see "Origin Service."

The solution comprises three main components:

• The user facing client applications, implemented for the Windows Runtime, Windows Phone, Web, iOS, and Android. These applications allow users to browse videos, and control the playback of videos. In addition the applications allow users to capture and upload new videos for encoding by Media Services, which can then be consumed from the CMS once encoding has completed.

The Contoso Windows Store application is used to demonstrate the Media Services functionality, which is consumed through a REST interface. However, several other apps are also provided for different devices and platforms, which all formulate the appropriate REST requests and consume REST responses.

• The business logic, implemented as a web service. The Contoso web service exposes the data and operations that it supports through a REST (Representational State Transfer) interface. Separating the business logic in this way decouples it from the client applications, minimizing the impact that any changes to the implementation of the applications will have on this business logic.

Christine says:
	Using REST enables you to invoke operations and consume the responses by using any web-enabled system that can formulate REST queries, providing great flexibility in building similar apps for different devices and platforms.

• Data storage, provided by an Azure SQL database, and by Azure Storage. The CMS, which stores details of videos and encoding jobs, is implemented as a Azure SQL database. However, uploaded videos and encoded videos output by Media Services are stored in Azure Storage.

Bharath says:
	Using Media Services minimizes the hardware and support investment that needs to be made when providing a video-on-demand service. You can monitor the volume of traffic to the web service, and if necessary simply scale the solution to use additional resources.

For more information about building and deploying applications to the cloud by using Azure, see the patterns & practices guide "Developing Multi-tenant Applications for the Cloud, 3rdEdition" available from MSDN.

Understanding the Windows Store application architecture

Developers of Windows Store applications face several challenges. Application requirements can change over time. New business opportunities and challenges may present themselves. Ongoing customer feedback during development may significantly affect the requirements of the application. Therefore it's important to build an application that has a flexible architecture and can be easily modified or extended over time.

The Contoso developers used a modified version of Prism for the Windows Runtime to accelerate the development of their Windows Store application. Prism includes components that provide support for MVVM and the core services required in Windows Store applications. This allowed the Contoso developers to focus on developing the user experiences for their video application. For more information about Prism for the Windows Runtime, see "Developing a Windows Store business app using C#, XAML, and Prism for the Windows Runtime."

The following figure shows the architecture of the Contoso Windows Store video application and web service in more detail. Grey items are provided by the modified version of Prism for the Windows Runtime, with blue items being created by the Contoso development team. For clarity, the diagram does not show all the class names.

The architecture of the Contoso Windows Store video application and web service

The advantage of this architecture is that it helps to produce flexible, maintainable, and testable code, by addressing common Windows Store application development scenarios, and by separating the concerns of presentation, presentation logic, and entities through support for MVVM.

For information on how to bootstrap a Windows Store application that uses Prism for the Windows Runtime, see "Bootstrapping an MVVM Windows Store app Quickstart using C#, XAML, and Prism."

Using a dependency injection container

The Contoso developers use a dependency injection container to manage the instantiation of many of the classes.

Markus says:
	Dependency injection enables decoupling of concrete types from the code that depends on these types. It uses a container that holds a list of registrations and mappings between interfaces and abstract types and the concrete types that implement or extend these types.

The Contoso Windows Store video application uses the Unity dependency injection container to manage the instantiation of the view model and service classes in the application. The App class instantiates the UnityContainer object and is the only class that holds a reference to this object. Types are then registered in the OnInitialize method in the App class.

Markus says:
	You should consider carefully which objects you should cache and which you should instantiate on demand. Caching objects improves the application's performance at the expense of memory utilization.

For more information about using Unity, see "Unity Container."

Understanding the Visual Studio solution

The Visual Studio solution organizes the source code and other resources into projects. All of the projects use Visual Studio solution folders to organize the source code and other resources into categories. The following table outlines the projects that make up the Contoso web service and Contoso video applications.

Project	Description
Contoso.Infrastructure.ReusableComponents	This project contains classes and interfaces from Prism for the Windows Runtime, which are used by the Contoso.Infrastructure.WindowsPhone and Contoso.Infrastructure.WindowsStore projects.
Contoso.Infrastructure.WIndowsPhone	This project contains Windows Phone specific classes and interfaces from Prism for the Windows Runtime.
Contoso.Infrastructure.WindowsStore	This project contains Windows Store specific classes and interfaces from Prism for the Windows Runtime.
Contoso.Api.Test	This project contains unit tests for the Contoso.Api project.
Contoso.Services.Test	This project contains unit tests for the Contoso.Domain.Services.Imply project.
Contoso.Test.Shared	This project contains unit test helper methods used by the Contoso.Api.Test and Contoso.Services.Test projects.
Contoso.UILogic.Tests	This project contains unit tests for the Contoso.UILogic project.
Contoso.UILogic.Tests.Mocks	This project contains mocks used by the Contoso.UILogic.Tests project.
Contoso.WindowsStore.Tests	This project contains unit tests for the Contoso.WindowsStore project.
Contoso.Api	This project contains the code for the Contoso web service.
Contoso.Azure	This project defines the roles for deploying the application to Azure, along with the service configuration. The Contoso.Api and Contoso.WebClient projects are deployed as web roles, with the Contoso.EncodingWorker being deployed as a worker role.
Contoso.Azure.Shared	This project defines the CloudConfiguration and TraceHelper classes. The CloudConfiguration class is used to retrieve Media Services account credentials from configuration.
Contoso.Azure.Stores	This project defines classes used to manage the video encoding process through Azure Storage Queues.
Contoso.Domain	This project defines the domain entity objects that remove the dependencies that controller classes in the Contoso.Api project might otherwise have on the way that data is stored.
Contoso.Domain.Services	This project defines the interfaces for the domain services that are implemented by the Contoso.Domain.Services.Impl project.
Contoso.Domain.Services.Impl	This project contains the classes that implement the domain services that perform encoding and interact with the repository classes.
Contoso.EncodingWorker	This project contains the worker role code that interacts with Azure Storage Queues in order to manage the encoding process.
Contoso.Repositories	This project defines the interfaces for the repository classes that retrieve and modify data in the Contoso Content Management System (CMS).
Contoso.Repositories.Impl.Sql	This project contains the repository classes and the data types that the repository classes use to retrieve and modify data from the Contoso CMS.
Contoso.Shared	This project defines the ContosoEventSource class which creates events for Event Tracing for Windows (ETW). This class is used by the Contoso.Api and Contoso.Services.Test projects.
Contoso.UILogic	The project contains the shared business logic for the Contoso video Windows Store and Windows Phone implementations.
Contoso.WebClient	This project contains the web client implementation of the Contoso video application.
Contoso.WindowsPhone	This project contains the Windows Phone specific code for the Windows Phone client implementation of the Contoso video application.
Contoso.WindowsStore	This project contains the Windows Runtime specific code for the Windows Store client implementation of the Contoso video application.

For information about the structure of the projects that implement the Contoso video applications see "Appendix C – Understanding the Contoso Video Applications."

Developing the content management system

A video CMS enables you to upload, store, process, and publish media. They generally store files in a database and allow for metadata tagging and searching.

Bharath says:
	Media Services is not a CMS but it does enable you to implement a video processing workflow. You can upload and store your content in Azure Storage, encode and package media into a variety of popular formats, and stream your videos online.

The requirements for the Contoso CMS were as follows:

• Ability to store details of videos that can be consumed by client applications.
• Ability to store video metadata.
• Ability to store thumbnail images that represent each video.
• Ability to store details of encoding jobs.

The developers at Contoso decided to store this information in a series of tables in third normal form. This structure helps to reduce the probability of duplicate information, while optimizing many of the common queries performed by the client applications. The following figure shows the table structure of the database.

The table structure of the CMS

Cloud-based databases are increasingly popular because they remove the need for an organization to maintain its own infrastructure for hosting a database. They offer elasticity that enables a system to quickly and easily scale as the number of requests and hence the volume of work increases. An additional advantage is that Azure SQL databases maintain multiple copies of the database, running on different server. Therefore, if the primary server fails, all requests are transparently switched to another server. Therefore, the developers at Contoso chose to implement the database as a Azure SQL database.

Poe says:
	A complete list of features available in a Azure SQL database is available at "General Guidelines and Limitations (Windows Azure SQL Database)" on MSDN.

For best practices about designing and developing a relational database, see the patterns & practices guide "Data Access for Highly-Scalable Solutions: Using SQL, NoSQL, and Polyglot Persistence" available from MSDN.

Accessing the content management system

A relational database stores data as a collection of tables. However, the Contoso video applications process data in the form of entity objects. The data for an entity object might be constructed from one or more rows in one or more tables. In the Contoso video applications, the business logic that manipulates objects is independent of the format of the data for that object in the database. This offers the advantage that you can modify and optimize the database structure without affecting the code in the applications, and vice versa.

This approach requires the use of an object-relational mapping layer (ORM). The purpose of an ORM is to act as an abstraction of the underlying database. The Contoso video applications create and use objects, and the ORM exposes methods that can take objects and use them to generate relational create, retrieve, update, and delete (CRUD) operations, which it then sends to the database server. Tabular data is then returned from the database and converted into a set of objects by the ORM.

The Contoso developers chose to use the Microsoft Entity Framework as the ORM, and also used the Fluent API to decouple the classes in the object model from the Entity Framework. In the Entity Framework the database is interacted with through a context object. The context object provides the connection to the database and implements the logic performing CRUD operations on the data in the database. The context object also performs the mapping between the object model of your application and the tables defined in the database.

The Contoso video apps send REST requests to the Contoso web service that validates these requests and converts them into the corresponding CRUD operations against the CMS. All incoming REST requests are routed to a controller based on the URL that the client application specifies. The controllers indirectly use the Microsoft Entity Framework to connect to the CMS database and retrieve, create, update, and delete data. The developers implemented the Repository pattern to minimize dependencies that the controllers have on the Entity Framework.

The purpose of the Repository pattern is to act as an intermediary between the object-relational mapping layer (implemented by the Entity Framework) and the data mapping layer that provides the objects for the controller classes. In the Contoso web service, each repository class provides a set of APIs that enable a service class (invoked by a controller class) to retrieve a database-neutral object from the repository, modify it, and store it back in the repository. The repository class has the responsibility for converting all the requests made by a service class into commands that it can pass to the Entity Framework. As well as removing any database-specific dependencies from the business logic of the controller and service classes, this approach provides flexibility. If the developers decided to switch to a different data store, they can provide an alternative implementation of the repository classes that expose the same APIs to the service classes.

Markus says:
	Avoid building dependencies on a specific data access technology into the business logic of an application. Using the Repository pattern can help reduce the chances of this happening.

For more information about the Contoso web service and its use of the Repository pattern, see "Appendix A – The Contoso Web Service."

Summary

This chapter has introduced the video application and web service built by Contoso. The Windows Store video application is built using XAML and C#, and consumes a web service that provides a REST interface to the CMS and Media Services. Media Services is used to encode and package video into the required formats for consumption across a variety of platforms and devices.

This chapter also discussed why Contoso chose to store the database in the cloud by using a Azure SQL database. It summarized how the client applications connect to the database by using the Entity Framework, and how the Repository pattern is used to abstract the details of the Entity Framework from the business logic of the system.

In the following chapters you will see how the developers at Contoso designed and implemented the end-to-end solution that uploads, encodes, delivers, and consumes media.

More information

• You can find the "General Guidelines and Limitations (Windows Azure SQL Database)" page on MSDN.
• The patterns & practices guide "Data Access for Highly-Scalable Solutions: Using SQL, NoSQL, and Polyglot Persistence" is available from MSDN.
• You can find information about the Entity Framework in the Data Developer Center, available on MSDN.
• The Repository pattern is described on MSDN.
• The patterns & practices guide "Developing Multi-tenant Applications for the Cloud, 3rd Edition" is available on MSDN.
• For information about Prism for the Windows Runtime, see "Developing a Windows Store business app using C#, XAML, and Prism for the Windows Runtime."
• For information about using Unity, see "Unity Container."
• For information on how to bootstrap a Windows Store application that uses Prism for the Windows Runtime, see "Bootstrapping an MVVM Windows Store app Quickstart using C#, XAML, and Prism."

Next Topic | Previous Topic | Home | Community