Functional Requirements

The system is built to provide service to perform statistical analysis useful for generating computational results, hence there exists some functional requirements ensured by the system for the user. The following are:

• Possible Statistical functions provided - The functions provided in the SciPy library are available for the user for computation. The input parameters for the function need to be specified by the user in order to enable the calculation.

• Temporal storage of the result - In order to provide results for the calculations beyond a time out limit, the user is provided with a location address in the response so as to be available for accessing it after the calculation is completed. The user needs to request the mentioned resource address to get the computed result.

• Resource sharing - The provided resources in the system are made available to the user for complete or partial sharing if demanded. This is an approach to ensure resource

availability to all the users. Though the sharing is restricted, in a sense that if the user permissions do not include sharing the resources then this is not achievable.

• Result in specific format - The system allows the user to receive the response for the computation to be in a specific format, be it JSON or XML. The expected format has to be proposed as a part of the request to ensure the response is in the specified format.

• Multi-tenant architecture support - The system has to support multi-tenancy that is, the users from various tenant must be able to use the service and store their data in the databuckets. The provision to share the databucket and the result must be provided as well. The requirements based on multi-tenant architecture are discussed in detail in the section 4.1.2.

• Monitoring the data store - The user of the service is provided some data storage for keeping the computed results. The limitation on the resource consumption is maintained by the provisioning of the resource. But to ensure that a user must be well informed about the consumption of the resource before time, suitable monitoring over the data store must be provided. Though this is not in scope of this work but it is a significant factor to maintain stability. The user must be sent out triggers to inform them about the resource utilization.

The other functional requirements specific to the multi-tenant architecture are described in detail in the next section.

4.1.2 Multi-Tenancy

In this section, we detail the multi-tenant requirements the system must fulfil in order to ensure tenant isolation at data storage level. From the user experience, Quality of service (QoS) and administration perspectives, the tenant naturally desires to access and use the service as if there were dedicated ones. Therefore, isolation should be carefully considered in almost all parts of architecture design, from both non-functional and functional level, such as security, performance, availability, administration etc. [GSH⁺07]. Multi-tenancy supports that all the tenants share a single application instance in a single hosting environment. The system must ensure a multi-tenant aware transparent access to data hosted in the Cloud. Compared to the Isolated Tenancy Hosted Applications (ITHA), Multi-tenant enabled application (MTEA) has to ensure not only the stored data to be kept apart between the operators within a single tenant but also between the different tenants. Since, MTEA has to safeguard against intrusion among tenants, tenant authentication is indispensable in MTEA. The storage support in the service for hosting the tenant’s data and also sharing the stored data but only to the authenticated tenant users, is implemented via a multi-tenant storage model. This relates to the significance of authentication and access control at both the tenant and at the tenant user levels. There are two distinct layers of roles participating in the system [Muh12]:

• The system role differentiates between system administrators and tenant users, with each tenant user belonging to one tenant. Both system roles are mutually exclusive and

4.1 Requirements

users of one system role may have a completely separate resource allocation from users of the other system role.

• The tenant role classifies the tenant users into tenant administrators and tenant opera-tors.

User Roles

In the application, there are three actors namely: system administrator, tenant administrator and tenant operator. System administrator has the authority to create tenants and hence provide access to the members for respective tenant. The system administrator has the control over the resources and hence assigns the resource which in our work is databucket to the tenant. The tenant administrator has the privilege to create tenant operator for their own tenant and further more distribute the tenant resources within the group of users. The tenant operator only then can register for the service and use it for computational purpose. The detailed description of each role is the following:

1. System Administrator - This role does not belong to any tenant but is responsible to manage the resources that are to be consumed by the tenants. The right to add a tenant and remove it lies with System Administrator. The tenant is identified in the resource model via a unique identifier called the tenant ID which also is used to identify the member to any tenant. The registration of the tenant is for authentication and control to enable isolation of data among various tenants. As a scope for this thesis, it is allowed to share data within tenant users of the same tenant and also with other tenant, but as per the design model it is required to identify the tenant from which the data is to be requested. A system administrator can also perform the operation of a tenant administrator and a tenant operator which is to access resources. This role has the maximum privileges and permissions compared to other roles. The system administrator has unlimited permissions and consequently is allowed to interfere in the actions of the tenant users [Muh12]. Another important task that handled by the system administrator is to keep the tenant data together.

2. Tenant Administrator - This role belongs to a tenant in particular. As the name suggests, the tenant administrator provides access to the resources sanctioned to the tenant by the system administrator further to the tenant operators. The creation of the tenant operator and also the removal of a tenant is managed by the tenant administrator. This role is obligated to distribute the resources among the members of their tenant and has the permission to increase or decrease the quota of resources for an individual tenant operator. The definition for the role of a tenant administrator and tenant operator and therefore, subsequent assigning of that role to any other tenant operator is also done by the tenant administrator. A tenant can have only one tenant administrator but multiple tenant operators are considered in our work. The tenant administrator can also assign this role to some other tenant operator within the tenant, if wishes to. A tenant administrator has access to all the services available to a tenant operator.

3. Tenant Operator - This role is lowest level in the hierarchy of roles participating in our system. The Tenant Operator as assigned by the Tenant Administrator can register the service so as to start using it. The application as is aimed for performing computational calculations in the Cloud environment, allows the Tenant Operator to request for the result of a computational library function by specifying the function and providing the input parameters for the same. The Tenant Operator can also request to save the computed result for future reference or for sharing with the rest users. Similarly, the Tenant Operator can request an already computed data from other operator from within the same tenant or from another tenant.