Cloud Services¶

In this section we are going to provide a brief overview of the cloud services –sample projects that are included in the MAGES SDK version 3.2. moving forward.

Further, we will be discussing the overall architecture, the connection and exchange of information between the services, and how we can efficiently enable you to securely authenticate and manage your users’ licenses.

Subsequently, for each service we will provide a separate section that covers at least the following points:

Configuration & runtime behavior

Customization

Build & deploy!

Note

At the time being, ORamaVR web services strongly depend on Microsoft Azure to operate.

Migration to other Cloud providers is feasible but requires extra work and customization on your behalf. Support for other providers is not in place yet.

Preliminary¶

Now let’s assume you have built a high-quality VR application with Unity based on MAGES SDK that you have released for the whole world to see.

And now assume that random-bob is your typical end-user, your teensy tiny happy user.

But the thing is you don’t really know bob, do you? At least not before he authenticates and presents himself.

In addition, you wish to grant access and present to bob his analytic insights that you have been gathering all this time with so much zealous and sweat.

But putting in place every small bit of this functionality, let alone making analytics look cool, takes time, resources, and highly-payed engineering work.

Besides, you don’t really find it an interesting investment, and you wish there was a way to skip all this boilerplate and dive right into the creative part, the part you love the most. Developing VR content, placing all your mojo-juice exactly right where it matters the most.

Appealling, huh?

We got you covered! Keep reading.

Architectural Overview¶

Before jumping to the details, let us first outline a deployment viewpoint of a VR application built with the MAGES SDK alongside with provided ORamaVR web services to get a clear picture.

Take a good look in the figure below.

User Perspective¶

On the left-side we depict a common deployment scenario from the perspective of the user w.r.t. your applications & services. Basically, this boils down to two things:

An HMD through which users access your VR applications

A typical web browser for access to user analytics

On the right-side we exhibit how web-services are deployed and exchange information on the Cloud. Namely, we present the following:

Web Portal

Login service

Analytics API

Combining these perspectives at a high-level overview there are two flows of information we are concerned with.

User authentication through the VR module and streaming of data (i.e., analytics) to the Cloud for further use.

Enable user to view the collection of gathered analytics at the online portal.

For 1., the VR module connects to the Login service which acts as a central authority and access controller (notice how every information flow goes through Login) that is responsible for user authentication and authorization based on the selected flow (e.g., resource owner password, SSO, etc.).

Additionally, the VR module connects to the Analytics API and uploads analytics at the end of the user session.

Regarding 2., the user gains access to the Web Portal through a regular browser and by authenticating via the Login service. Through the Web Portal, the user is able to view the analytics collected from each product and on a per session-basis.

From the scenario above we can deduce the following information regarding the web services:

Service	Description
Web Portal	Single Page Application (SPA) accessible through the browser. Responsible for displaying user analytics.
Login Service	Central identity management. Responsible for user authentication and authorization.
Analytics API	RESTful API. Responsible for processing, storing, and delivery of streaming data regarding user analytics.

Administrator Perspective¶

From an administrators perspective, there is a lot more going on.

For instance, admins need a way to let users register, or register them on-demand.

Another example is that admins need to be able to create product entities and associate these products with a group of users. In other words, hand-out licenses to users (e.g., userA is licensed to use productA, productB, etc.).

For these scenarios and more, the provided web services are able to cover your use-cases.

In detail and complementary to the table above:

Service	Description
Web Portal	Responsible for displaying user and product/license management.
Login Service	REST API, responsible for user management, authentication, and authorization.

Supervisor Perspective¶

Now lets assume that a group of users belong to the same organization, e.g., ORamaVR.

Lets say for example that we want a supervisor that belongs to the organization to be able to track user’s progress, or even examine their analytics and conduct statistical evaluations.

You guessed it right, this is also part of the provided web services, with the following scheme:

Service	Description
Web Portal	Responsible for user management within a particular organization. Track user progress.
Login Service	REST API, responsible for user management within an organization.
Analytics API	REST API, responsible for granting access to supervisors.

What about the storage?¶

Now that you have a firm idea of what does what and how everything is connected, you might be wondering about what happens with all the data.

As presented in the figure above, you can see there are two types of storage systems our web services utilize:

Relational Databases (SQL)

Azure Storage Blobs

Both Login and Analytics API maintain a distinct Azure SQL database each for keeping relational data (e.g., Users, Products, SessionSummary, etc.).

Analytics API on the other hand, utilizes Azure Blob Storage for storing and processing streaming data from user sessions (i.e., analytics data).

While keeping relational data on a SQL database sounds reasonal, Azure Blob Storage is also a sound design decision for streaming data and large blob files.

Quoting from Microsoft Azure documentation:

Azure Blobs Allows unstructured data to be stored and accessed at a massive scale in block blobs.

Also supports Azure Data Lake Storage Gen2 for enterprise big data analytics solutions.

You want your application to support streaming and random access scenarios.

You want to be able to access application data from anywhere.

You want to build an enterprise data lake on Azure and perform big data analytics.

Connecting the Dots¶

Communication between the services and VR modules takes place in an asynchronous HTTPS manner.

No information is exchanged in any other way. The same principle holds for the storage systems.

For instance, the Analytics API often requests user information for functioning properly, but it never directly gains access to the Identity database to retrieve this information.

By doing so, you might be wondering that we have added an unecessary communication overhead but in fact what we have done is beneficial to the overal architecture.

In detail, we have reduced the complexity of our system by providing single-points of responsibility amongst our services or in other words, seperation of concerns.