Infosys | Microsoft

Ubik.com Application Architecture

Ubik.com(Presentation)

With Ubik.com users are able to create personalized mobile enabled web sites. The sites created by the users primarily contain information on the site structure and content both in textual format as well as binary images. The site structure and definitions of the sites created are contained in a standard publishing format known as Xdime. The site definitions and content along with the images selected by the users are published to the newly build web services.

Ubik.com Services:

The Ubik.com services are RESTful web services primarily responsible for managing the Xdime content and Images which are stored in the Azure Blob Storage. The web services run on the Azure operating system and communicate with the Ubik.com application over http.  The REST services provide interfaces to not only publish the contents and images into the Blob storage but also enable accessing the site content directly over the mobile devices.  Let look into the design of these service interfaces and with them being RESTful
There are two distinct set of services created:
1. Manage XDIME content
2. Manage Images for site
Each of these services support standard http GET, POST, PUT and Delete operations. 
1. The GET operation is used to create new site content or images into the Ubik Blob storage.
2. POST/PUT operations can be used interchangeably to update content/images into the Ubik Blob Storage.
3. DELETE operation is used to delete the content/images from Ubik Blob storage. 
Additionally the application also supported the capability to store data in different Blob containers based on the deployment region that the application operated in. Like any product release management, an application could be in different stages of a release say test, staging etc.., undergoing several round of tests against different versions of data sources and by different user groups (say business, devs, testers etc..) before being finally “Released to Market”. Ubik.com had a similar requirement wherein the application needed to be tested across several regions before it is released. And it was required that a single instance of the new service running be able to handle data for the different regions without having to host separate Azure instances for each region.
Based on the service URL “environment” value (env) ,as shown in the URL below, the services were able to dynamically identify  and store data in separate regions.

A standard service URL to call UBIK.com services would look like
http://[Host]/[doc|img]/[env]/[docname|imagename]

Note:  The URL’s shown here are only for representative purposes to explain my point and are not the live ones used in the application
Where ,
• Host:  DNS host name
• [doc/img]:
o doc: an url path for indicating that a content file is being handled
o img: an url path for indicating that a image is being handled
• [env] : Is the environment from which the data is being managed eg: dev , test, prod.
• [docname|imagename]: is the name of the content which is being handled from blob storage
As you can observe, the URLs are pretty intuitive and using the appropriate http URL’s with the corresponding http verbs will provide access to the required information from the Ubik storage
The error notification from these services are communicated to the client are over standard HTTP response formats containing the standard response codes such as 400,404, 500 etc, and status descriptions.

Data Storage:

The site content and images are persisted in the Azure Blob Storage. In the initial phase, primarily two separate containers were created to persist Ubik.com data, one container for site content (Xdime) and the other for storing images.
From a security aspect, the BLOB storage containers are marked as “Private” and access to the content is restricted. The Blob access is available only through the services by using the Authorization key which is available from the Azure portal as a part your storage account.
In this way I have demonstrated how we have helped one of our ISV customers adopt Azure in their application scenario. In case you have more interesting scenarios you are working on or have seen and would like to share, then do post in your comments.