KR101316902B1 - Extended JAVA virtual machine for supporting multi-tenancy and Method for processing multi-tenancy using the same - Google Patents

Abstract

The present invention relates to a technique for extending the functionality of a Java virtual machine to support multi-tenancy on the Java platform.

According to the present invention, an extended Java virtual machine for supporting multi-tenancy on the Java platform includes a context manager that creates a thread identified by a tenant identifier and a user identifier, and a user thread belonging to the same tenant to one thread group. An extended thread manager having a tenant thread group manager to manage, and a tenant identifier associated with the thread to identify the storage location and the required object identifier where the data related to the tenant is stored and to load the identified object from the tenant data DB. It includes an extended class loader with an object loader.

Java platform, Java virtual machine, multi-tenancy

Description

Extended JAVA virtual machine for supporting multi-tenancy and Method for processing multi-tenancy using the same}

The present invention relates to a soft-as-a-service (SaaS) platform technology that provides a variety of applications online at a low cost to a number of tenants using a single platform. It's about technology that extends the capabilities of Java virtual machines to support tenancy.

SaaS is a distribution form of software that makes available only what the customer needs as a service among the functions of the software. Called service-as-a-software, the software is installed on the server's computer, and the customer pays for it through a web browser and uses the software as a service. Therefore, the SaaS platform must support a multi-tenancy feature that provides services for the needs of multiple customers (or tenants) online using one software code image.

Currently in service Java (JAVA) -based SaaS platform includes additional intermediate module layer that defines multi-tenancy functions or additional middle machine layer, so unnecessary class loading and method calls are required. Increasing code length, which must be executed and executed, increases program complexity and degrades performance.

An object of the present invention is to propose a Java virtual machine and a method of operating the same, which are extended to provide a multi-tenancy support function required for online service of the requirements of multiple tenants with one code image.

According to one embodiment of the present invention, an extended Java virtual machine for supporting multi-tenancy on a Java platform includes a context manager for creating a thread identified by a tenant identifier and a user identifier, and a user thread belonging to the same tenant. An extended thread manager having a tenant thread group manager that maps and manages the group, and a tenant identifier associated with the thread, checks the storage location and the necessary object identifier where data related to the tenant is stored, and checks the above from the tenant data DB. It includes an extended class loader that has an object loader for loading a named object.

According to another embodiment of the present invention, a method for supporting multi-nancy on a Java platform includes: performing user authentication when a tenant user logs in; Creating a thread identified by a tenant identifier and a user identifier to process the tenant user request; Receiving a command from the tenant user; Calling a classloader to load the tenant user's customized tenant object to process the received command; Loading, by the classloader, a tenant object into memory based on the tenant identifier, the user identifier, and the received command; And executing, by the thread, the tenant object.

The present invention is a technology that can extend the functionality of the Java virtual machine to internalize the multi-tenancy function on the Java platform, and can be installed and used in a web server that provides various applications online. According to the present invention, by supporting the multi-tenancy feature directly inside the Java virtual machine rather than the Java API level, the overall system performance is reduced by reducing unnecessary class loading and method call process mapping to actual code, which greatly affects the performance of the Java platform. By reducing the length of the execution code and improving the code size, the development cost can be reduced by providing the simplicity of the code.

Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings so that those skilled in the art can easily carry out the present invention. The present invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. In the drawings, parts irrelevant to the description are omitted in order to clearly describe the present invention, and like reference numerals designate like parts throughout the specification.

Throughout the specification, when a part is said to "include" a certain component, it means that it can further include other components, without excluding other components unless specifically stated otherwise. In addition, the terms “… unit”, “module”, and the like described in the specification mean a unit that processes at least one function or operation, which means that the unit may be implemented by hardware or software or a combination of hardware and software.

1 is a diagram illustrating a basic structure of a Java platform to which the present invention is applied. As shown, the Java platform consists of a Java virtual machine 110 and a Java class file 120 that stores classes that can be Java on the Java virtual machine 110, the Java virtual machine 110, Java byte code Bytecode analysis unit 111 for interpreting the Java class file 110, the Java class loader 112 for loading the necessary classes, the garbage collector 113 for managing the memory, threading and management of Java virtual The thread manager 114, the security manager 115, and the memory area 116 are included. The Java virtual machine 110 uses the class loader 112 to pass through a class java class file byte code interpreting unit 111 class necessary for the bi-program execution to the Java class file 120 through 1112. In addition, threading and management of the thread manager 114 is provided through a Java API. In a Java program, you can use the thread access classes as needed and use the ThreadGroup class to manage the created multiple threads.

In the present invention, in order to embed the multi-tenancy processing function directly into the internal functions of the above-described Java virtual machine 110, the functions of the class loader 112 and the thread manager 114 is extended. 2 and 3, the structure of the class loader and thread manager extended to implement the multi-tenancy processing function according to the present invention.

2 illustrates a structure of an extended thread manager according to an embodiment of the present invention. As shown, the extended thread manager includes a context manager 201 that creates a thread identified by a tenant identifier and a user identifier, and a tenant thread group that manages by mapping threads of users belonging to the same tenant into one thread group. Manager 202 is included. The tenant thread group manager 202 may manage threads belonging to the same tenant as a group or manage the threads in detailed group units based on the role of each thread in the tenant. The tenant thread group manager 202 can consistently apply the service quality and resource management monitoring policy to each tenant or to each group within the tenant through group group thread management.

3 illustrates a structure of an extended class loader according to an embodiment of the present invention. Applications serviced on the SaaS platform can be customized with user interfaces, business logic, and data schemas to meet various tenant requirements through the configurator. Tenant-specific customization information is stored in the metadata DB 304, and when a user enters a command, the tenant metadata is interpreted to execute appropriate business logic and show a user UI.

As shown in FIG. 3, the extended class loader includes a metadata extracting unit 301, a metadata analyzing unit 302, and an object loader 303. Metadata DB 304 stores user interfaces, business logic, data schema information, and the like, customized to meet tenant requirements. The metadata extracting unit 301 receives a tenant identifier, tenant user identifier, and command message from a thread, and extracts metadata associated with the tenant from the metadata DB 304 based on these. The tenant identifier is a unique key that distinguishes tenant information in the tables constituting the metadata DB. The tenant identifier is used to access business logic and related data for performing a user command message.

The metadata analyzing unit 302 analyzes the extracted metadata to check the data location and the related object identifier related to the tenant. The metadata contains information about the user interface (UI), data schema, and business logic set by the tenant. For user command processing, the metadata analyzing unit 302 first constructs a corresponding UI screen by analyzing the metadata of the tenant UI, and analyzes the metadata information about the data schema to fill the necessary data on the UI screen, and thus the tenant data information. Determines the storage location where is stored, and checks the Java object ID that defines the business logic for generating dynamic data.

 The object loader 303 loads the object related to the tenant from the tenant data DB 305 to the memory area 306 storing the Java class using the identified object identifier. The loaded tenant object's class will follow the general behavior of the Java virtual machine.

The functions of the above-described extended class loader and thread manager can be provided by extending ClassLoader, Thread, and ThreadGroup class APIs included in the java.lang package or using the context of the Java execution environment without changing the Java API. That is, the tenant identifier is defined as an environment variable by extending the Java execution environment itself, and the tenant identifier value of the existing application can be applied without extension of the existing API by using a predefined value.

4 is a flowchart illustrating a method for supporting multi-tenancy using an extended Java platform according to an embodiment of the present invention.

When the tenant user logs in in step 410, user authentication is performed and tenant authentication information and session information are registered in the context manager.

In step 420, a thread identified by the tenant identifier and the user identifier is created to process the tenant user request. Register the created user thread in the thread group corresponding to the tenant.

In step 430, a command is received from a user.

In step 440, the thread invokes the extended classloader to load the user's customized tenant object for processing the received command, and passes the tenant identifier, tenant user identifier and command message as parameters to the extended classloader. To pass.

In step 450, the extended class loader loads a customized tenant object based on the passed parameters, and the thread executes the object (code).

Specifically, when a tenant identifier, tenant user identifier, and command message are delivered from a thread, the extended class loader extracts metadata associated with the tenant from the metadata DB 304 using the tenant identifier, interprets the metadata, and then interprets the metadata. The storage location and the required object identifier are stored, and the object related to the tenant is retrieved from the tenant data DB and loaded into the memory area 306 using the identified object identifier. Tenant objects can include user interfaces, workflows, data information, and the like.

After execution by the thread, the tenant object is returned by the extended class loader.

The present invention can also be embodied as computer-readable codes on a computer-readable recording medium. A computer-readable recording medium includes all kinds of recording apparatuses in which data that can be read by a computer system is stored. Examples of the computer-readable recording medium include a ROM, a RAM, a CD ROM, a magnetic tape, a floppy disk, and an optical data storage device, and also include a carrier wave (for example, transmission via the Internet) . The computer readable recording medium may also be distributed over a networked computer system and stored and executed in computer readable code in a distributed manner.

The present invention can also be applied to portable multimedia playback devices (MP3, PMP, etc.), mobile phones and PDAs.

So far I looked at the center of the preferred embodiment for the present invention. It will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims. Therefore, the disclosed embodiments should be considered in an illustrative rather than a restrictive sense. The scope of the present invention is defined by the appended claims rather than by the foregoing description, and all differences within the scope of equivalents thereof should be construed as being included in the present invention.

1 is a diagram illustrating a basic structure of a Java platform to which the present invention is applied.

2 illustrates a structure of an extended thread manager according to an embodiment of the present invention.

3 illustrates a structure of an extended class loader according to an embodiment of the present invention.

4 is a flowchart illustrating a method of supporting multi-tenancy using an extended Java platform according to an embodiment of the present invention.

Claims (8)

An extended Java virtual machine processing apparatus for supporting multi-tenancy on the Java platform, An extended thread manager having a context manager that creates a thread identified by the tenant identifier and the tenant user identifier, and a tenant thread group manager that maps and manages user threads belonging to the same tenant into a single thread group; An extended class loader that includes an object loader that uses a tenant identifier associated with a thread to identify the storage location where the data related to the tenant is stored and the required object identifier and to load the identified object from the tenant data DB. Extended Java virtual machine processing device for multi-tenancy support, including. The method of claim 1, wherein the extended class loader, A metadata extractor configured to extract metadata associated with the tenant from a metadata DB based on the tenant identifier, the tenant user identifier, and the command message when a tenant identifier, tenant user identifier, and command message are transmitted from a thread; A metadata analysis unit for analyzing the extracted metadata to identify a storage location in which data related to the tenant is stored and a necessary object identifier; And An object loader for loading an object related to the tenant from a tenant data DB into a memory area using the identified storage location and object identifier Extended Java virtual machine processing device for multi-tenancy support, including. The apparatus of claim 1, wherein the tenant thread group manager applies the same quality of service and resource management monitoring policies to threads or thread groups belonging to the same tenant. The apparatus of claim 2, wherein the metadata DB stores tenant application customization information. The apparatus of claim 1, wherein the extended class loader receives a tenant identifier, a tenant user identifier, and a command message associated with the thread from a thread. In a method performed by a processor to support multi-needance on the Java platform, Performing user authentication when the tenant user logs in; Creating a thread identified by a tenant identifier and a user identifier to process the tenant user request; Receiving a command from the tenant user; Calling a classloader to load the tenant user's customized tenant object to process the received command; Loading, by the classloader, a tenant object into memory based on the tenant identifier, the user identifier, and the received command; The thread executing the tenant object; Multi-Nancy Support on the Java platform, including. 7. The method of claim 6, further comprising registering the created thread with a thread group corresponding to the tenant. The method of claim 6, wherein the classloader loads the tenant object into memory. Extracting metadata associated with the tenant from the metadata DB using the tenant identifier; Analyzing the extracted metadata to identify a storage location and a necessary object identifier in which data related to the tenant is stored; Retrieving an object related to the tenant from the tenant data DB using the identified storage location and the object identifier and loading the object into the memory area; Multi-Nancy Support on the Java platform, including.

Images