On Time, On Point, On Budget!

How We Developed Web Application on MS Azure

Today the Internet has a significant number of live web cameras available for everyone. Web cameras allow users to view video streaming in a real time or get specific frames upon request. However, the cameras can’t store video for some time period. This is obvious as calculating resources (disk space on server and processor time allotted for request serving) are needed for video storing or photo collections storing. We decided to implement this functionality in our project Enterra WebCam Viewer.

Enterra WebCam Viewer – is a web application with the following features:

  • When user opens the application he/she should see a list of public cameras served by the application (that is cameras for which video is archived);
  • When user goes to a certain camera, he/she should have an option to view video (or separate frames) for a specified time period.

The features described above are features for a user with “Guest” rights. Cameras can’t appear in the application by themselves. Someone should add them. Let users add them. For these purposes we have features for users registered in the system:

  • New user registration, simple user account management (password change);
  • User cameras management: camera creation, camera deletion, camera edit.

Video archive for a camera is formed from the frames taken from the camera with a certain interval. For example an ordinary video is a sequence of frames with frequency of 24-25 frames per second. Full value video record with such frequency requires very substantial consumption of processor time and disk space. Besides unlikely there is a practical necessity to record video with such frequency from web cameras. Thus, user should have an option of specifying own frame frequency, the frequency should not be set any lower than 1 frame per second. Besides user should have an option to stop camera record without its deletion.

System Requirements

From the features description one can conclude that we need substantial calculating resources. First of all, the cameras should constantly be served, frames should be taken from them and frames should be stored. Secondly, clients will constantly request videos and it means that server should make frame selections and send them to clients. The server platform should be scalable. That is why the choice of the MS Azure platform was clear and undoubted.

Let’s list other technologies used:

  • Client part– Silverlight 3.0 (C#).
  • Server – MS Azure , Web Service, SQL Azure

We used Silverlight considering interactive nature of the application itself. It is known that MS Azure has several ways of data storing. We used SQL Azure for two reasons:

  1. We would like to develop application without Azure, that is to develop simple Silverlight-based client-server application and use MS SQL to store data and in the last development stage adapt the application to MS Azure.
  2. We are going to use our own ORM component which showed advantages in working with MS SQL. We also hope that the component will also show advantageous result working with SQL Azure.

Below is a final list of software requirements to start the work:

  • Supported Operating Systems: Windows 7; Windows Server 2008; Windows Server 2008 R2; Windows Vista Service Pack 1; Windows Vista Service Pack 2
  • IIS 7.0 (with ASP.NET, WCF HTTP Activation and optionally CGI)
  • Microsoft Visual Studio 2008 SP1, Microsoft Visual Studio 2010 Beta 2 or Microsoft Visual Web Developer 2008 Express Edition with SP1
  • Windows Azure Tools for Microsoft Visual Studio (November 2009) including Windows Azure SDK (http://www.microsoft.com/downloads/details.aspx?FamilyID=6967ff37-813e-47c7-b987-889124b43abd&displaylang=en)
  • Windows Azure Account
  • SQL Azure Account

Architecture

Enterra WebCam Viewer – is a client-server application, which has the following division of layers:

  • Data Provider Layer – data access level. Data base is a data source on server, server interface is a data source on client. Thus, we would use IDataProvider – unified interface of data access both on client and on server.
  • Business Objects Layer – business objects level. Business objects is the most convenient way of getting and changing data, which is abstracted from the way of data storing and data transfer. Server and client have business objects.
  • Business Logic – level of business logic on server. Business logic is processing of events changes or data gathering.

The architecture described above is implemented with the help of our Enterra.Data component, which is used both on client and server sides. That is why we had to port Enterra.Data to Silverlight. It didn’t arise any problem or difficulty for us.

From Enterra WebCam Viewer functionality described above, the following object application model is formed:

  • User – business object for storing user properties (login, password, e-mail);
  • Image Source – business object corresponding to the image entity. Image source is web camera abstraction. Properties of image source are web camera address, web camera state (stop, record), link to user-owner, access level to web camera (available to all users or only to owner).
  • Image Data – business object for storing imagers taken from the web camera. Properties of Image Data are binary data of the image itself, creation date, link to the image source.

Data base scheme corresponds to object model and is given in the picture 1.


Picture. 1. Database scheme for Enterra WebCam Viewer.

Interaction With Server

As it has been already said in the architecture description, client interacts with server by using IDataProvider interface. It means that our server is an implementation of IDataProvider. Let’s show examples of the most significant IDataProvider methods:

//getting identificator for a new object of the specified type.
object GetNewId(Type type)

//load of object properties with specified identificator and type.
NameValueDictionary LoadData(Type type, object id)

//load of properties massive for objects of the specified type.
//Objects selection on server is done using a specified filter
//with specified sorting means.
NameValueDictionary[] LoadData(Type type, Filter filter, Order order)

//saving changes in objects
void Save(ChangedData[] changes)

It is clear that IDataProvider implementation on client should transfer request by web service methods. Instead of creation of several methods on the web service, our web service publishes one method. Call for all the methods of the server is done using this method. Its signature is below:

object InvokeAny(string methodName, object[] args)

There is a number of advantages in creation of only one web service method:

  • There is a central location of request processing on client and on server. For example, this is convinient for exclusions processing and logging.
  • Problems with transfer of arguments of different types are focused in only one method (but not spread on the whole service).
  • Having set only one method, we abstract away from web service technology. If we decide, for example, to use WCF, it will be easier for us to go to WCF by refactoring of only one method.

We came across one more big problem. Enterra.Data component and our experience in development client-server applications using the component suppose synchronous request model of server methods. That is when request to any IDataProvider method on the outcome we always get result (or exclusion). Synchronous requests are impossible in Silverlight. That is why a problem of using client-server components with synchronous request paradigm is a problem that should be solved. It is inadmissible to redevelop a component with synchronous paradigm into a component with asynchronous requests.

We solved this problem the following way:

  • For use of Enterra.Data we implemented IDataProvider by asynchronous requests to server. Synchronism of IDataProvider requests is reached due to insert of code with reply standby loop.
  • As getting results from server on Silverlight is done in the main stream, than one can’t request to server in UI events handler. To solve this we created SyncInvoker class which receives two delegates: the 1st delegate has code with requests to server, the 2nd delegate is requested when the 1st one is finished. SyncInvoker launches the 1st delegate in the separate stream and finishes, the 2nd delegate launches.

We conclude that we used component with synchronous request model in the asynchronous environment.

Video Record from Cameras

The main task of server is to constantly get images from web cameras with the “record” states and store them in the data base. Process which initializes new event of camera processing, should be constantly working on server. For example, in Windows Server 2003 it can be windows service which requires method of camera processing with a certain interval. In MS Azure the task is solved by writing a cycle with request of the processing method with a certain interval. Further the code should be launched under worker role.
The general algorithm of camera processing in terms of our object model can be written as follows:

  1. Request all ImageSource objects with the “Record” state and objects which require record of the next frame;
  2. Get an image for each requested ImageSource;
  3. Create new ImageData object with received image;
  4. Save in ImageSource date and time of the last received frame and a link to the created ImageData (LastImageId field stores a link to the last frame).

Let’s comment on “require record of the next frame” words from the 1st item above. Each ImageSource has a frame frequency and stores date and time of the last frame taken. Based on these properties and current time one can easily get a necessity condition of taking a frame in a certain time period.

Let’s note that when creation ImageData with main image we also save it’s scaled-down copy. This is necessary to allow a client request for several images without substantial load on communication channel.

Deployment at MS Azure

Thus, we developed web application, tested it and debugged it in “warm house conditions” and now it’s time to deploy it on MS Azure.

We create data base using SQL Azure tab on the personal page (Pic. 2)


There it is necessary to make rules for Firewall. In this situation the «Enterra Inc.» rule allows access to SQL Azure from our IP address. Also Microsoft recommends installing “Allow Microsoft Services access to this server”.

To create tables, indexes it is necessary to use SQLСMD. SQLCMD is a part of Microsoft SQL Server and can be found in the SQL Server folder. For example, in «Microsoft Sql Server 2008» this utility can be found in the «C:Program FilesMicrosoft SQL Server100ToolsBinn» folder.

Command line examples for connecting to SQL Azure, are given below.

SQLCMD.EXE -U [email protected]_name -P password -S server_name.database.windows.net -d db_name

To create data base structure using the script, it is enough to do the following command:
SQLCMD.EXE -U [email protected]_name -P password -S server_name.database.windows.net -d db_name -i filename

Work in MS Visual Studio one should begin with C#/Cloud Service/Windows Azure Cloud Service project creation. Our Azure project will consist of ASP.NET Web Role project and Worker Role project. We will host Web Services and Silverlight applications on ASP.NET Web Role.

Do you like the article and want us to develop your project? Feel free to contact us here!

This entry was posted on Monday, February 15th, 2010 at 9:28 am and is filed under Azure.