Browse Prior Art Database

A System and Method for Cloud Tenant Modelling with Multi-Dimensional Similarity Matching

IP.com Disclosure Number: IPCOM000199992D
Publication Date: 2010-Sep-23
Document File: 7 page(s) / 2M

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a User Interface - Selector - Customizer model, which in the field of multi-tenant systems, enables systematic modelling and provisioning of (service) tenant requirements as multi-dimensional variants of existing tenants in the cloud. A client looks for a service provider, which can satisfy its requirements by provisioning a new tenant. In multi-tenant systems, when a client addresses a service provider with a new set of requirements, the provider tries to create a new tenant by re-building the functionalities required by the client. This would prove to be wasteful if the provider's existing tenants' functionalities could be reused to produce the client's required functionalities. This involves identification of similarities and differences between a client and an existing tenant's functionalities. Therein arises the need for a common tenant structure to help carry out these comparison operations smoothly.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 33% of the total text.

Page 01 of 7

A System and Method for Cloud Tenant Modelling with Multi -Dimensional Similarity Matching

The proposed technique involves identification of a single (set of) existing tenant(s), whose functionalities when taken together can help meet the client's requirements. The suggested User Interface - Selector - Customizer model constructs a tenant for a new client with the help of functionalities from an existing set of tenants. Fig. 1 shows the User Interface - Selector - Customizer model. The User interface - Closest tenant selector - Customizer is modeled based on the Model View Controller (MVC)

pattern.

(This page contains 00 pictures or other non-text object)

Figure 1: User interface - Selector - Customizer model that constructs a new tenant by identifying a single or a set of tenants that together satisfy the client's requirements.

1

Page 02 of 7

    The User Interface receives client's requirements and constraints through a user interface (front-end) and assembles it in a form suitable for comparison with the set of tenants provisioned by the service provider. Closest-Tenant Selector uses a matching algorithm to identify a single or a combination of existing tenants that satisfy the new client's requirements. The amount of similarity a client requirement has to a functionality of an existing tenant is determined by a numerical value referred to as the degree of match. Degree of match can be either exact or partial. The tenant selector's matching algorithm aims at identifying a minimal set of existing tenants that match the new client's requirements by trying to maximize the degree of match.

    At times a provider may be unable to identify a single (set of) tenant(s) that can completely satisfy a client's requirements or may only be able to identify tenant functionalities with which the client has a partial degree of match between. The tenants' functionalities that

p

 rovide a partial match can be customized to meet the client's requirements. The Customizer tries to alter the tenant's functionality either positively - by adding the required characteristics, or negatively - by deleting excess characteristics in order to find an exact match. The Customizer could also probe existing tenants to identify a combination of tenant functionalities that exactly matches the client's requirements.

    We also introduce unique representations for a tenant and provider also referred to as Tenant Requirements Model (TRM) and Tenant Provider Model (TPM) respectively. A tenant contains the following - attributes, constraints, behavior and state information. Here, behavior contains a list of functionalities required by the tenant. Attributes can be classified into simple and complex attributes, where simple attributes are built on primitive data-types, while complex attributes are built on non-primitive data-types. An attribute is of the form: bankName = "ABC". Constraints contain a list of conditions set by a tenant. They can be of two kinds - inter-tenant cons...