Previously I’ve introduced the architecture of the video on-demand service, and the Windows Phone app that consumes the service through a REST interface.
In this blog post I’ll discuss the Content Management System (CMS) created for the Building an On-Demand Video Service with Microsoft Azure Media Services project.
Designing the CMS
A video CMS enables you to upload, store, process, and publish media, and generally store data in a database that allows for metadata tagging and searching.
The requirements for our CMS were:
- Ability to store details of videos that can be consumed by client apps.
- Ability to store video metadata.
- Ability to store a thumbnail image for each video.
- Ability to store details of video encoding jobs.
We decided to store this information in a series of database tables that were optimized for many of the common queries performed by our client apps. The following diagram shows the database table structure.
The table structure was implemented as an Azure SQL relational database as they offer elasticity that enables a system to quickly and easily scale as the number of requests and volume of work increases. An additional advantage is that Azure SQL databases maintain multiple copies of the database on different servers. Therefore, if the primary server fails, all requests are transparently switched to another server.
Accessing the CMS
A relational database stores data as a collection of tables. However, the Windows Phone app processes 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 Windows Phone app the business logic that manipulates objects is independent of the format of the data for the object in the database. This offers the advantages that you can modify and optimize the database table structure without affecting the code in the Windows Phone app, and vice versa.
This approach requires the use of an object-relational mapping (ORM) layer. The purpose of the ORM is to act as an abstraction of the underlying database. The Windows Phone app creates and uses objects, and the ORM exposes methods that can take those objects and use them to generate relational 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.
We used the Entity Framework as the ORM, and 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. This 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 the Windows Phone app and the tables defined in the database.
The Windows Phone app sends REST requests to the video on-demand service, which validates the 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 Windows Phone app specifies. The controllers indirectly use the Entity Framework to connect to the CMS database and perform CRUD operations. We implemented the Repository pattern in order to minimize the dependencies that the controllers have on the Entity Framework.
The purpose of the Repository pattern is to act as an intermediary between the ORM layer and the data mapping layer that provides the objects for the controller classes. In the video on-demand service, each repository classes provides a set of APIs that enable a service 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 we chose to switch to a different data store we could provide alternative implementations of the repository classes that expose the same APIs to the service classes.
For more information about the video on-demand service and its use of the Repository pattern see Appendix A – The Contoso Web Service.
This blog post has discussed why we chose to store the CMS database in the cloud as an Azure SQL database. It has explained how the web service connects 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 video on-demand service. For more information see Building an On-Demand Video Service with Microsoft Azure Media Services.
In my next blog post I’ll discuss how the Windows Phone app uploads video to the video on-demand service.