JP6866307B2 - Systems and methods for multi-tenant execution of OS programs called from multi-tenant middleware applications - Google Patents

Description

Copyright Notice Some of the disclosures in this patent document include material subject to copyright protection. The copyright owner has no objection to the fact that anyone can copy the patent document or disclosure of patent information as it appears in the packaging or record of the Patent and Trademark Office, but otherwise all copyrights. Also owns.

Field of Invention:
Embodiments of the invention generally relate to application servers and cloud environments, and in particular to systems and methods for supporting applications called from multitenant middleware platforms.

background:
Software application servers include, for example, Oracle WebLogic Server (WLS) and Glassfish, which generally provide a controlled environment for running enterprise software applications. In recent years, technologies for use in cloud environments have also been developed, allowing users or tenants to develop and run their applications in cloud environments, and distributed resources provided by the environment. It is possible to utilize.

Overview:
According to one embodiment, systems and methods for supporting multi-tenant execution of tenant-unaware programs called from multi-tenant middleware applications are described herein. An exemplary method can provide multiple partitions and multiple tenant-aware programs. Each of the multiple tenant-aware programs is associated with a partition. The method can associate each of a plurality of partitions and a plurality of tenant-aware programs with one of the plurality of tenants. This method can call a tenant-unrecognized process from a calling partition among a plurality of partitions. A calling partition is associated with a calling tenant among multiple tenants. The method can collect tenancy information about calling tenants. In addition, based on the collected tenancy information, the method can range the execution of tenant-unaware processes to calling tenants by setting the process execution environment and resources.

According to one embodiment, when using a containerized application, it is possible to support the separation of the execution time of the tenant unrecognized process from other tenants in the multi-tenant middleware environment by the scoped execution. As a result, multi-tenant operation of the OS application program is performed.

It is a figure which shows the system for supporting multi-tenancy in the application server, the cloud or other environment according to one Embodiment. FIG. 5 further illustrates a system for supporting multi-tenancy in an application server, cloud or other environment according to one embodiment. FIG. 5 further illustrates a system for supporting multi-tenancy in an application server, cloud or other environment according to one embodiment. It is a figure which shows the domain structure used in the example multi-tenant environment according to one Embodiment. It is a figure further showing an exemplary multi-tenant environment according to one embodiment. It is a figure which shows the system for execution which specified the tenant range of the tenant non-recognition type process according to one Embodiment. It is a figure which shows the system for execution which specified the tenant range of the tenant non-recognition type process according to one Embodiment. It is a figure which shows the system for execution which specified the tenant range of the tenant non-recognition type process according to one Embodiment. It is a flowchart which shows the example method for creating the environment and the resource for the tenant range specified execution of the tenant unrecognized process according to one Embodiment. FIG. 5 is a flow chart illustrating an exemplary method for creating and configuring a process builder according to an embodiment. It is a flowchart which shows the exemplary method for multi-tenant execution of the tenant non-recognition type OS application from MT middleware application (for example, JEE application) according to one Embodiment. It is a flowchart which shows the example method for supporting the tenant range specified execution of the tenant unrecognized process called from the multitenant middleware application.

Detailed explanation:
According to one embodiment, a tenant-scoped execution of a tenant-unrecognized (also referred to as "tenant-unrecognized" in this specification) process called from a multi-tenant middleware application. Systems and methods for supporting (also referred to herein as "multi-tenant execution") are described herein. An exemplary method can provide multiple partitions and multiple tenant-aware programs (also referred to differently in the specification as "tenant-aware"). Each of the multiple tenant-aware programs is associated with a partition. The method can associate each of a plurality of partitions and a plurality of tenant-aware programs with one of the plurality of tenants. This method can call a tenant-unrecognized process from a calling partition among a plurality of partitions. A calling partition is associated with a calling tenant among multiple tenants. The method can collect tenancy information about calling tenants. In addition, based on the collected tenancy information, the method can range the execution of tenant-unaware processes to calling tenants by setting the process execution environment and resources.

By using the systems and methods described herein, a tenant-aware JEE application (eg, for example) that includes a non-Software as a Service component that runs as a unique program / process on an operating system according to one embodiment. , SaaS application) can recognize and separate a complete application (end-to-end) multi-tenant by allowing the tenant to function in a scoped manner. That is, multi-tenancy support provided within a multi-tenant application server environment can be supported outside the MT application server environment on a unique OS, but is performed within the MT application server environment (eg, WebLogic MT). It cannot be limited to the components / programs.

Application Server (For example, MultiTenant (MT) Environment) Figure 1 shows a system for supporting multi-tenancy in an application server, cloud or other environment according to one embodiment.

As shown in FIG. 1, according to one embodiment, an application server (eg, multi-tenant (MT)) environment 100 or other computing environment enables the deployment and execution of software applications. It includes the configuration of the domain 102 used at runtime to define the application server domain and can be configured to operate according to the configuration of the domain 102.

According to one embodiment, the application server may include one or more partitions 104 defined to be used at run time. Each partition can be associated with a global unique partition identifier (ID) and partition configuration, and one or more resource groups 124, along with resource group template references 126 and / or partition-specific applications or resources 128. May include. Domain-level resource groups, applications and / or resource 140 can also be defined at the domain level, optionally with reference to the resource group template.

Each resource group template 160 can define one or more applications A162, B164, resources A166, B168 and / or other deployable applications or resources 170 and can be referenced by resource groups. For example, as illustrated in FIG. 1, resource group 124 in partition 104 can refer to resource group template 160 (190).

In general, system administrators can define partitions, domain-level resource groups and resource group templates, and areas of security, while partition administrators can, for example, create partition-level resource groups or deploy applications to partitions. You can define the aspect of their own partitions by doing so or by referencing specific areas about the partitions.

FIG. 2 further shows a system for supporting multi-tenancy in an application server, cloud or other environment according to one embodiment.

As shown in FIG. 2, according to one embodiment, the partition 202 is, for example, a resource group 205 including a reference 206 of the resource group template 210, virtual target (eg, virtual host) information 207, and a pluggable database. It may include (pluggable database: PDB) information 208. The resource group template (eg 210) may be, for example, a Java Message Server (JMS) server 213, a store-and-forward (SAF) agent 215, a mail session component 216 or Multiple applications A211 and B212 can be defined along with resources such as Java Database Connectivity (JDBC) resource 217.

The resource group template illustrated in FIG. 2 is provided as an example. According to other embodiments, different types of resource group templates and elements can be provided.

According to one embodiment, when a resource group within a partition (eg 202) references a particular resource group template (eg 210) (220), it indicates partition-specific information 230 (eg, partition-specific PDB information). Therefore, the information associated with a particular partition can be used in combination with the referenced resource group template. The partition-specific information is then available to the application server to configure the resources used by the partition (eg, PDB resources). For example, partition-specific PDB information associated with partition 202 can be used by an application server to configure container database (CDB) 236 with the appropriate PDB238 to be used by that partition (232). Is.

Similarly, according to one embodiment, using the virtual target information associated with a particular partition, a partition-specific virtual target 240 (eg, a uniform resource locator: URL) that should be used by that partition. ) (For example, baylandurgentcare.com which can be made accessible by http://baylandurgentcare.com) can be defined (239).

FIG. 3 further shows a system for supporting multi-tenancy in an application server, cloud or other environment according to one embodiment.

According to one embodiment, a partition is defined using a system configuration such as a config.xml configuration file. The partition contains configuration elements and / or other partition properties for the resource group associated with that partition. The value can be specified for each partition using the property name / value pair.

According to one embodiment, multiple partitions can be run within a managed server / cluster 242 or in a similar environment where the CDB243 is accessible and accessible through the web tier 244. it can. This allows, for example, a domain or partition to be associated with one or more PDBs (of a CDB).

According to one embodiment, each of the plurality of partitions, in this example partition A250 and partition B260, can be configured to include a plurality of resources associated with the partition. For example, partition A can be configured to include a resource group 251 that includes application A1 252, application A2 254, JMS A 256, and even data source A257 associated with PDB A 259. .. In this case, the partition is accessible via the virtual target A258. Similarly, partition B260 may be configured to include resource group 261 including application B1 262, application B2 264, JMS B 266, and further data source B 267 associated with PDB B 269. it can. In this case, the partition is accessible via virtual target B268.

Although some of the above examples illustrate the use of CDBs and PDBs, other embodiments may support other types of multi-tenant or non-multi-tenant databases. In this case, a particular configuration can be provided for each partition, for example by using a schema or by using different databases.

Resources According to one embodiment, a resource is a system resource, application, or other resource or object that can be deployed in the domain of the environment. For example, according to one embodiment, the resource can be an application, JMS, JDBC, JavaMail, WLDF or data source, or another system resource or other system resource that can be deployed to a server, cluster or other application server target. It can be another type of object.

Partition According to one embodiment, a partition can include applications and / or, as well as a subdivision or slice of execution time and management of domains that can be associated with a partition identifier (ID) and configuration. Resources can be referenced throughout the domain by using resource groups and resource group templates.

In general, a partition may include its own application, reference the application across the domain through a resource group template, and have its own configuration. Partitionable entities can include resources such as JMS, JDBC, JavaMail, and WLDF resources and other components such as JNDI namespaces, network traffic, work managers, security policies and areas. In the context of a multi-tenant environment, the system can be configured to provide the tenant with access to the management and execution time aspects of the partitions associated with the tenant.

According to one embodiment, each resource group in the partition can optionally reference a resource group template. A partition can have multiple resource groups, each of which can reference a resource group template. Each partition can define properties for configuration data that are not specified in the resource group template referenced by the partition's resource group. This allows a partition to act as a bind to the deployable resources defined in the resource group template to specific values that should be used by that partition. In some cases, the partition can invalidate the configuration information specified by the resource group template.

According to one embodiment, the partition configuration may include multiple configuration elements, for example, as defined by the config.xml configuration file. Multiple component elements are, for example, a "partition" (including the attributes and child elements that define that partition); a "resource-group" (including applications and resources deployed in the partition). "Resource-group-template" (including applications and resources defined by that template); "jdbc system resource-override" (database) Includes unique service name, username and password); and includes "partition-properties" (including property key values available for macro replacement in resource group templates).

After startup, the system can use the information provided by the configuration file to generate partition-specific configuration elements for each resource from the resource group template.

Resource Group According to one embodiment, a resource group is a named, fully qualified set of deployable resources that can be defined at the domain or partition level and references a resource group template. be able to. Resources in a resource group are considered fully qualified. This is because the administrator has all the information needed to start or connect to those resources, such as the credentials or application to connect to the data source. This is because it provides target information about.

System administrators can publish resource groups at the domain level or at the partition level. At the domain level, resource groups provide a convenient way to group related resources. The system can manage exposed resources in the same domain-level resource groups as ungrouped resources. Therefore, the resource can be started during system startup or stopped during system shutdown. Administrators can also stop, start, or delete resources in a group individually, and by running on the group can implicitly work on all resources in the group. For example, stopping a resource group stops all resources in a group that has not yet been stopped; starting a resource group starts any resource in a group that has not yet started, causing the resource group to start. By deleting, all resources included in the group are deleted.

At the partition level, the system or partition administrator can configure zero or more resource groups on a partition under any security restrictions. For example, in SaaS use cases, various partition-level resource groups can reference domain-level resource group templates. In a PaaS use case, you can create partition-level resource groups that do not refer to resource group templates but instead represent applications that should be made available only within that partition and their associated resources.

According to one embodiment, resource grouping can be used to group both applications and the resources they use as separate management units within the domain. For example, in the medical record (MedRec) application described below, the MedRec application and its resources are defined by resource grouping. Multiple partitions can each run the same MedRec resource group with partition-specific configuration information, which makes the applications that are part of each MedRec instance unique to each partition. To.

Resource Group Template According to one embodiment, a resource group template is a set of deployable resources that can be referenced from a resource group and is defined at the domain level, and some of the information needed to launch that resource. May not be remembered as part of the template itself to support partition-level configuration specifications. A domain may include any number of resource group templates, each of which may include, for example, one or more related Java applications and the resources on which they depend. Some of the information about such resources may be the same across all partitions, and other information may be different from partition to partition. Not all configurations need to be specified at the domain level, instead partition-level configurations can be specified in the resource group template by using macros or property name / value pairs.

According to one embodiment, a particular resource group template can be referenced by one or more resource groups. In general, within any given partition, a resource group template can only be referenced by one resource group at a time. That is, it cannot be referenced by multiple resource groups at the same time within the same partition. However, it can be referenced simultaneously by different resource groups in different partitions. Objects containing resource groups, such as domains or partitions, can be set with the value of any token in the resource group template using property name / value assignments. When the system invokes a resource group template with a referenced resource group, it can replace those tokens with the values set in the objects it contains. In some cases, the system can also use statically configured resource group templates and partitions to generate a run-time configuration for each partition / template combination.

For example, in the SaaS use case, the system can launch the same applications and resources multiple times, one of which can be launched for each partition that will use them. Once the administrator has defined resource group templates, they can use tokens to represent information that may be provided elsewhere. For example, the username used to connect to a CRM-related data resource can be shown as \ $ {CRMdataUsername} in the resource group template.

Tenants According to one embodiment, in a multi-tenant environment such as a multi-tenant (MT) application server environment, a tenant is an entity that can be represented by one or more partitions and / or one or more tenant-aware applications, or An entity that can be associated with one or more partitions and / or one or more tenant-aware applications.

For example, a tenant can represent a separate user organization, such as different external companies, different departments within a particular company (eg, HR and Treasury), each of which can be associated with a different partition. A tenant's global unique identity (tenant ID) associates a particular user with a particular tenant at a particular point in time. The system can derive from which tenant a particular user belongs, for example, by referring to a record of user identities. User identity allows the system to perform actions that the user is authorized to perform. User identity includes, but is not limited to, which tenant the user may belong to.

According to one embodiment, the system allows the management and execution times of different tenants to be separated. For example, tenants can configure some behavior of their applications and the resources they can access. The system ensures that a particular tenant cannot manage artifacts that belong to another tenant, and at run time, applications that act on behalf of that particular tenant only see resources associated with that tenant. Can ensure that does not reference resources associated with other tenants.

According to one embodiment, the tenant-unaware application explicitly addresses the tenant so that it has access to any resource used by the application, regardless of which user presents the request the application is responding to. It does not include the logic to do. In contrast, tenant-aware applications include logic that explicitly addresses tenants. For example, based on the user's identity, the application can derive the tenant to which the user belongs and can use that information to access tenant-specific resources.

According to one embodiment, the system allows the user to deploy an application explicitly written to be tenant-aware, which allows the application developer to obtain the tenant ID of the current tenant. be able to. The tenant-aware application can then use this tenant ID to process multiple tenants using a single instance of the application.

For example, a MedRec application that supports a single office or hospital can be exposed to two different partitions or tenants (eg Bayland Urgent Care tenant and Valley Health tenant), each of which is the underlying application. You can access separate tenant-specific resources such as separate PDBs without changing the code.

An exemplary domain configuration and multi-tenant environment According to one embodiment, an application can be deployed to a resource group template at the domain level, or is a partitioned or domain-scoped resource. Can be deployed in groups. Application configurations can be disabled using a deployment plan specified per application or per partition.

FIG. 4 shows a domain configuration used in an exemplary multitenant environment according to one embodiment.

According to one embodiment, when a system starts a partition, the system will have one virtual target (eg, virtual host) and connection pool for each partition for each database instance, according to the configuration provided. To create.

Typically, each resource group template may contain one or more related applications and the resources they depend on. Each partition can provide configuration data that is not specified in the resource group template it references, but this sometimes invalidates some of the configuration information specified by the resource group template. This can be done by binding the deployable resources in the resource group template to the specific values associated with the partition, including that. This allows the system to launch applications that are variously represented by resource group templates for each partition, using the property values defined by each partition.

In some instances, the resource groups that a partition can contain either do not refer to the resource group template or directly define their own partition-ranged deployable resources. Applications and data sources defined within a partition are generally only available for that partition. Resources can be deployed to be accessible from within a partition using partition: <partitionName> / <resource JNDI name> or domain: <resource JNDI name>.

For example, a MedRec application may include multiple Java applications, data sources, JMS servers and mail sessions. To run MedRec applications for multiple tenants, system administrators can define a single MedRec resource group template 286 that exposes their deployable resources in the template.

In contrast to domain-level deployable resources, deployable resources exposed in a resource group template may not be fully configured in the template or lack some configuration information. Therefore, it cannot be started as it is.

For example, the MedRec resource group template may expose the data source used by the application, but may not specify a URL to connect to the database. Partitions associated with various tenants, such as partition BUC-A290 (Bayland Urgent Care: BUC) and partition VH-A292 (Valley Health: VH), each reference a MedRec resource group template (296,297) MedRec. By including resource groups 293 and 294, one or more resource group templates can be referenced. Then, using that reference, the virtual host baylandurgentcare.com 304 associated with the BUC-A partition used by the Bayland Urgent Care tenant and the virtual host valley health.com 304 associated with the VHA partition used by the Valley Health tenant. Virtual targets / virtual hosts can be created for each tenant, including com308 (302,306).

FIG. 5 further shows an exemplary multi-tenant environment according to one embodiment. Continuing from the above example where the two partitions refer to the MedRec resource group template, as shown in FIG. 5, according to one embodiment, the Servlet Engine 310 in this example is the Bayland Urgent Care physician tenant. It can be used to support multiple tenant environments, such as Environment 320 and Valley Health's Physician Tenant Environment 330.

According to one embodiment, each partition 321 and 331 can define different virtual targets for accepting incoming traffic for its tenant environment and different URLs 322,332. The different URLs 322,332 are for connecting to the partition and its respective resources 324, 334, including the Bayland Urgent Care database or valley health database in this example. Database instances can use compatible schemas because the same application code can be executed against both databases. When a system starts a partition, it can create connection pools and virtual targets for each database instance.

Tenant Scope of OS Programs According to a specified execution embodiment, according to the methods and systems described herein, OS (ie, tenant-unaware) programs, applications and processes (in this specification). Tenants of "OS program", "OS application", "OS process", "non-tenant recognition program", "non-tenant recognition application", and "non-tenant recognition process") Can support ranged execution.

Typically, when an application is run in an MT environment, the application is tenant ranged. This means that libraries and resources accessed by tenant-aware programs are isolated from, for example, other tenants in the MT environment.

However, when a tenant-recognized program running in the MT environment calls a tenant-unrecognized application (for example, C, C ++, Perl, etc.) running on a unique OS, most of these programs running on the OS are separated from each other. Or there may be a problem that it is not separated at all. That is, the general-purpose operating system does not have the concept of tenancy and therefore does not recognize the tenancy associated with the MT application (ie, the JEE application) (ie, the tenancy information associated with the outgoing call from the MT application). This makes it possible to execute OS programs using shared OS resources (eg files, processes, databases) within a common environment, and further, separate tenant applications can be external OS applications (eg tenants). When calling an unrecognized application), the tenant context may be lost and execution time may be separated / separated.

FIG. 6 shows a system for tenant-scoped execution of a tenant-unaware process according to one embodiment. As shown in FIG. 6, the multi-tenant application server environment 600 (eg, WebLogic multi-tenant) may include several tenant partitions such as tenant 1 partition 601 and tenant 2 partition 605. Tenant 1 and tenant 2 partitions can be associated with applications such as JEE application 602 and JEE application 606, respectively, and JEE application 602 and JEE application 606 are associated with data source 603 and data source 607, respectively. Source 603 and data source 607 allow access to the respective databases 604 and 608 of each tenant.

According to one embodiment, an application such as a JEE application associated with tenant 2 can call, for example, an OS program located outside the multi-tenant application server in the unique OS 610 (calling a process). This may happen, for example, if there are components of the MT application that are not limited to the MT application server (eg Perl scripts, C programs, etc.). Such an application (ie, an MT application that also relies on an external OS component that runs outside the MT application server to be executed) can be referred to as a composite application. The JEE application associated with tenant 2 runs in the MT environment and has a tenant context associated with the execution time.

According to one embodiment, when an MT application (eg, a JEE application) calls an OS program / application (ie, process 620), the MT application has several to extend / propagate the tenant context available to the JEE application. Variable 625 (ie, environment variable) can be set. These variables are tenant ID, tenant name, tenant filesystem (TFS) root; process working directory under TFS with input / output subdirectories; tenant DB connection string, and tenant lightweight directory access protocol (TFS). lightweight directory access protocol: LDAP) may include a directory URL.

According to one embodiment, the MT application server can manage the virtual tenant file system 630 for each tenant implemented in the MT application server environment 600. This virtual tenant file system can be created / configured as part of application server management once the tenant is implemented. The virtual tenant file system is part of the OS 610, and one virtual tenant file system for each tenant is generally active in the MT application server environment.

According to one embodiment, when an MT application (eg, a JEE application) calls an OS process (ie, a tenant-unaware process), the MT application additionally creates a temporary process working directory under the tenant's virtual file system. Can be created. When two or more OS processes are called by the MT application, the MT application can create one temporary working directory for each called OS process. When the MT application creates a temporary working directory under the virtual file system, it additionally under the temporary working directory for the input directory, output directory, error directory and database directory (each called OS). You can create subdirectories (for each process). These subdirectories can accept redirected stdin (input stream), stdout (output stream) and stderr (error stream) of the called OS processes. Each input subdirectory can be set in the process input file. Each output subdirectory can serve to populate process output files. Each error subdirectory can serve to capture process error (eg, stderr) messages. A file system specific to a virtual tenant can be associated with a unique storage such as OS storage 640.

According to one embodiment, the process builder may include an API (eg, Java Process Builder API). The API specifies the command line for the OS program / application to be executed by the client, configures environment variables to be set in the process environment, configures the process working directory, and processes process inputs, outputs and error streams. Allows you to redirect to a file on the file system. The process builder is configured or configured with specific process characteristics before processes (ie, OS processes) such as process environment, process work directory, and process input / output stream / error stream redirection are started. Can be made possible.

According to one embodiment, when an MT application calls an OS process, the MT application can create and use a process builder (eg, a process builder instance). The tenancy context from the MT application can be propagated as part of the Process Builder API call, including setting environment variables and creating and configuring the process working directory. Configure the process builder to allocate resources (environment variables, process working directory, redirected input / output files, database connection descriptor, LEAP directory, wallet) by using environment variables with the process working directory. Allows the execution of tenant-unaware processes (eg OS processes) to be scoped / restricted within the tenancy context. In this way, the tenant unrecognized process (for example, the OS process) obtains a working directory specific to the tenant call. This working directory is under the virtual file system to which the tenant is designated and is isolated from the files and resources created or owned by other tenants in the MT application server environment 600.

According to one embodiment, the tenant-unrecognized process is assigned a tenant-specific folder under the OS file system for the redirected process I / O stream, and the tenant-unrecognized process is tenant-specific. Use the tenant LDAP directory to connect to the database associated with the tenant using the access credentials of. Tenant-specific database connection strings / descriptors may allow the program to function transparently with the tenant database. Tenant-specific credentials can be configured in a wallet set under the database subdirectory of the process working directory in the tenant's virtual file system.

According to one embodiment, a virtual tenant file system (often referred to as a "calling tenant" and associated with a tenant) was created for a calling MT application from a calling partition and then associated with a tenant-unaware process. Streams (eg, input stream, output stream, error stream) can be redirected to their respective input subdirectories, output subdirectories, and error subdirectories under the process working directory in the tenant's virtual file system.

In this way, the tenancy context, environment and data associated with the separate tenants that call the OS program can be kept discretely separated from each other, thereby from within the MT container (eg, for example). It may be possible to specify a range and process an OS application (tenant unrecognized type) executed based on a call (from a JEE program executed instead of a partition in the MT container).

According to one embodiment, when the tenant unrecognized process completes execution, the MT application executed in the MT application server environment can search the process output and clean up the process working directory.

According to one embodiment, the MT application can obtain the process exitValue status code (eg, from the Java process object exitValue () method) to know if the program execution was successful. The MT application can also search the redirected stdout and stderr files under the output and error subfolders to see if the process execution was successful. When the tenant unaware process execution is complete, the updated results in the tenant database can be accessed directly from the database by the MT application running on the partition.

According to one embodiment, the MT application can also delete the process working directory and its subfolders, which cleans up output files such as wallets and db files.

According to one embodiment, the environment variables configured in the MT application that calls the OS program are the tenant ID, tenant name; tenant file system (TFS) root; input subdirectory, output subdirectory, and error subdirectory under TFS. It may include a process working directory with a directory; a tenant DB connection string, and a tenant LDAC (lightweight directory access protocol) directory URL;

According to one embodiment, using the process builder configuration, resources (environment variables, process working directory, redirected) whose execution in the tenant context is scoped / restricted for the tenant unrecognized OS program. Input / output files, DB connection descriptors, LEAP directories, and wallets) can be assigned.

Multi-tenant Execution of OS Programs-Contained Applications According to one embodiment, the methods and systems described herein are tenants by using containerized applications to separate tenants at run time. It can support multi-tenant execution of unrecognized processes (ie OS processes).

According to one embodiment, the present disclosure can utilize a containerized application to isolate tenants during the execution time of a tenant-unaware process.

According to one embodiment, a containerized application or process is an application packaged as a container and contains information necessary to execute an application such as an OS-based image, an application executable file, and a library. The containerized application may be a portable application that can be shared between Linux distributions using the same Linux kernel, such as the Linux® kernel 750. A containerized application is a system shared by a containerized application, assuming that the developer creates a portable application / containerized application and shares an image with the same Linux kernel. Can be created so that a containerized application image can be downloaded from the container image registry or repository and the container can be spun off to run the containerized application. In this regard, the application may be available on a destination host separate from other containers and OS, and still requires the required libraries (eg, the same version intended by the application / process developer). Can be made available using the library). There may then be another containerized application instance that uses the same version of the library, but this will be done separately. Docker is an example of such a container framework / infrastructure.

FIG. 7 shows a system for multi-tenant execution for a tenant-unrecognized process according to one embodiment. FIG. 7 shows multi-tenant execution of an OS program called from an MT application using a containerized OS application that is executed in an OS that supports a software container.

As shown in FIG. 7, the MT application server environment 600 (eg, WebLogic multi-tenant) may include several tenant partitions such as tenant 1 partition 601 and tenant 2 partition 605. Tenant 1 and tenant 2 partitions can be associated with applications such as JEE application 602 and JEE application 606, respectively, and JEE application 602 and JEE application 606 are associated with data source 603 and data source 607, respectively. , Each tenant can access its own database 604 and database 608.

According to one embodiment, when an MT application (eg, a JEE application) calls a tenant-unaware application (eg, as a containerized application), the MT application extends / propagates the tenant context available to the JEE application. Some variables (ie environment variables) can be set to make it work. These variables are tenant ID, tenant name; tenant file system (TFS) root; process working directory with input subdirectory, output subdirectory and error subdirectory under TFS; tenant DB connection string, and tenant LDAP. (Lightweight Directory Access Protocol) Directory URL; may be included.

According to one embodiment, the MT application server can manage the virtual tenant file system 735 for each tenant implemented in the MT application server environment 600. This virtual tenant file system can be created / configured as part of application server administration once the tenant is implemented. The virtual tenant file system is a part of OS610, and generally one virtual tenant file system is active in the MT application server environment for each tenant.

According to one embodiment, when an MT application (eg, a JEE application) calls a tenant unrecognized application, the MT application additionally under the tenant's virtual file system (in this specification, the "process working directory"). You can create a temporary process working directory (also known as). When two or more tenant-unrecognized applications are called by the MT application, the MT application can create one process working directory for each called tenant-unrecognized application. When the MT application creates a process working directory under the virtual file system, it additionally under the process working directory for the input directory, output directory, error directory and database directory (each called tenant is unrecognized). You can create subdirectories (for each type application). These subdirectories can accept redirected stdin (input stream), stdout (output stream) and stderr (error stream) of the called OS processes. Each input subdirectory can be set in the process input file. Each output subdirectory can serve to populate process output files. Each error subdirectory can serve to capture process error (eg, stderr) messages. A file system specific to a virtual tenant can be associated with a unique storage such as OS storage 736.

According to one embodiment, the process builder is available by the MT application and may include APIs (eg, Java Process Builder API). The API specifies the command line for tenant-unaware applications that clients should run, configures environment variables to set in the process environment, configures the process working directory, and processes process inputs, outputs, and error streams. Allows you to redirect to a file on the file system. The process builder sets or configures certain process features before processes such as process environment, process working directory, and process input / output stream / error stream redirects (ie, tenant-unaware applications) are started. Can be made possible.

According to one embodiment, when an MT application calls a tenant-unaware application, the MT application can create and use a process builder (eg, a process builder instance). The tenancy context from the MT application can be propagated as part of the Process Builder API call, including setting environment variables and creating a temporary process working directory. The process builder to allocate resources (environment variables, process working directory, redirected input / output / error stream, database connection descriptor, LEAP directory, wallet) by using environment variables with the temporary process working directory. Can be configured to allow the execution of tenant-unaware applications to be scoped / restricted within the tenancy context. In this way, the tenant-unaware application gets a working directory specific to the tenant call. This working directory is under the virtual file system designated by the tenant and is separated from the files created or owned by other tenants in the MT application server environment 600.

According to one embodiment, the tenant unrecognized application is assigned a tenant-specific folder under the OS file system for the redirected process I / O stream, and the tenant unrecognized application is a tenant. Use unique access credentials to connect to the database associated with the tenant and use the tenant-specific LDAP directory. Tenant-specific database connection strings / descriptors may allow the program to function transparently with the tenant database. Tenant-specific credentials can be configured in the wallet set under the database subdirectory under the process working directory in the tenant's virtual file system.

According to one embodiment, a virtual tenant file system is created for a calling MT application from a calling partition (associated with a tenant and often referred to as a "calling tenant") and then a tenant-unaware application. Streams associated with (for example, containerized applications) (eg, input stream, output stream, error stream) are under the process working directory in the tenant's virtual file system, respectively, in the input subdirectory, output subdirectory, and You can redirect to the error subdirectory.

According to one embodiment, the tenant unrecognized application (called from the MT application, such as JEE application calling from the partition of tenant 2) can be packaged as a containerized application. In an exemplary process, the MT application can call an OS program. In such cases, the process builder (eg Java ProcessBuilder) can call the containerized application. The container framework provides lightweight container virtualization technology. One such container framework is Docker.

According to one embodiment, the execution time of a container such as docker defines the format for packaging the application and all of the application's dependencies on a single image. This image can be transferred to any docker-enabled machine, which can be done with the guarantee that the execution environment exposed to the application will be the same.

Using an OS with a container framework such as a docker, the system will have an application container image containing the base OS (eg Ubuntu), along with a layered file system containing the application binaries and the required libraries and components. Can be created. Images can be self-contained as well as portable, allowing a host-independent application to run when a containerized application is started.

According to one embodiment, the MT application (ie, JEE application 606) can call a tenant-unaware application by initiating a container process (eg, docker or rocket). A container client 720, such as a docket client, is called by an MT application using a process builder (eg, a JEE application 606 running on partition 605 of tenant 2) from the originator of the request (ie, the JEE application). OS (tenant unrecognized) applications can be started using the tenancy context. The container client can call the container daemon 725, such as the docker daemon. The container daemon can then download and start the application image 740 of the requested containerized application from the JEE application. The application image 740 may include a base OS (eg, Ubuntu), along with a layered file system containing application binaries and required libraries and components. Images can be both self-contained and portable, allowing the application to run independently of the host. In addition, containerized applications can be run as separate instances. Containerized applications run on the same OS, but are executed separately. This means that two or more tenants can run different instances of the same application, separated as separate containers.

According to one embodiment, when a container is created (by a container daemon), an application image is loaded into the container, and the containerized application 730 is executed, the application is run independently of the host. be able to.

According to one embodiment, the containerized application 730 can communicate with the tenant's virtual tenant file system 735 (based on the tenant context, eg, the partition of tenant 2 that can communicate with the OS storage 736). I / O).

According to one embodiment, a containerized application acting on behalf of the tenant (eg, tenant 2) can access the tenant's database 608 with the required credentials.

According to one embodiment, the MT application can obtain the process exitValue status code (eg, from the Java process object exitValue () method) to know if the program execution was successful. The MT application can also search the redirected stdout and stderr files under the output and error subfolders to see if the process execution was successful. When the execution of the tenant-unaware containerized application is completed, the updated results in the tenant database can be accessed directly from the database by the MT application running in the partition.

According to one embodiment, the MT application can also delete the process working directory and its subfolders, which cleans up output files such as wallets and db files.

FIG. 8 shows a system for multi-tenant execution for a tenant-unrecognized process according to one embodiment. FIG. 8 shows the multi-tenant execution of the OS program called from the MT application by using the containerized OS application executed in the container.

As shown in FIG. 8, the MT application server environment 600 (eg, WebLogic multi-tenant) may include several tenant partitions such as tenant 1 partition 601 and tenant 2 partition 605. Tenant 1 and tenant 2 partitions can be associated with applications such as JEE application 602 and JEE application 606, respectively, and JEE application 602 and JEE application 606 are associated with data source 603 and data source 607, respectively. , It will be possible to access the respective databases 604 and 608 of each tenant.

According to one embodiment, when an MT application (eg, a JEE application) calls a tenant-unaware application (eg, as a containerized application), the MT application extends the tenant context available to the JEE application / Several variables (ie environment variables) can be set for propagation. These variables are tenant ID, tenant name; tenant file system (TFS) root; process working directory with input and output subdirectories under TFS; tenant DB connection string, and tenant LDAP (lightweight directory access). Protocol) directory URL; may be included.

According to one embodiment, the MT application server can manage the virtual tenant file system 735 for each tenant implemented in the MT application server environment 600. This virtual tenant file system can be created / configured as part of application server administration once the tenant is implemented. The virtual tenant file system is a part of OS610, and generally one virtual tenant file system is active in the MT application server environment for each tenant.

According to one embodiment, when an MT application (eg, a JEE application) calls a tenant-unaware application, the MT application can additionally create a temporary process working directory under the tenant's virtual file system. .. When two or more tenant-unrecognized applications are called by the MT application, the MT application can create one process working directory for each called tenant-unrecognized application. When the MT application creates a process working directory under the virtual file system, it additionally under the process working directory for the input directory, output directory, error directory and database directory (each called tenant is unrecognized). You can create subdirectories (for each type application). These subdirectories can accept redirected (stdin) input stream, (stdout) output stream and (stderr) error stream. Each input subdirectory can serve as a setting in the process input file. Each output subdirectory can serve to populate process output files. Each error subdirectory can serve to capture process error (eg, stderr) messages. A file system specific to a virtual tenant can be associated with a unique storage such as OS storage 736.

According to one embodiment, the process builder may include an API (eg, Java Process Builder API). The API specifies the command line for tenant-unaware applications that clients should run, configures environment variables to set in the process environment, configures the process working directory, and processes process inputs, outputs, and error streams. Allows you to redirect to a file on the file system. The process builder sets or configures certain process features before processes such as process environment, process working directory, and process input / output stream / error stream redirects (ie, tenant-unaware applications) are started. Can be made possible.

According to one embodiment, when an MT application calls a tenant-unaware application, the MT application can create and use a process builder (eg, a process builder instance). The tenancy context from the MT application can be propagated as part of the process builder API call, including setting environment variables. MT applications can create process working directories and subdirectories (inputs, outputs, errors and databases) under VTFS (Virtual Tenant File System). The MT application can then use the Process Builder API to configure a process working directory with environment variables, a temporary process working directory path, and a redirected stream. Configure the process builder to allocate resources (environment variables, process working directories, redirected input / output files, database connection descriptors, LEAP directories, wallets) by using environment variables with the process working directory. Allows the execution of tenant-unaware applications to be scoped / restricted within the tenancy context. In this way, the tenant-unaware application gets a working directory specific to the tenant call. This working directory is under the virtual file system designated by the tenant and is separated from the files created or owned by other tenants in the MT application server environment 600.

According to one embodiment, the tenant-unrecognized application uses a tenant-specific folder under the OS file system for I / O operation and connects to the tenant-associated database using tenant-specific access credentials. In addition, the tenant LDAP directory is used. Tenant-specific database connection strings / descriptors may allow the program to function transparently with the tenant database. Tenant-specific credentials can be configured in the wallet set under the database subdirectory in the process working directory in the tenant's virtual file system.

According to one embodiment, a virtual tenant file system is created for a calling MT application from a calling partition (associated with a tenant and often referred to as a "calling tenant") and then a tenant-unaware application. Streams associated with (eg, containerized applications) (eg, input streams, output streams, error streams) can be redirected to their respective subfolders under the process work directory in the tenant's virtual file system.

According to one embodiment, the tenant unrecognized application (called from the MT application, such as JEE application calling from the partition of tenant 2) can be packaged as a containerized application. In an exemplary process, the MT application can call an OS program. In such cases, the process builder API is configured by the MT application to call the container process. One such container framework / infrastructure is a docker.

According to one embodiment, a container framework / infrastructure such as a docker can define a format for packaging an application and all its dependencies on a single image. This image can be uploaded to a docker hub / repository, and this image can be downloaded and run from the docker hub / repository with the guarantee that the execution environment exposed to the application will be the same. it can.

According to one embodiment, using a container framework such as a docker, the system can download a pre-created container image 815 from the application image library 810. The application image 815 may include a base OS (eg, Ubuntu), along with a layered file system containing application binaries and required libraries and components. Images can be both self-contained and portable, allowing a host-independent application to run when a container is created and the application is started inside it.

According to one embodiment, the application image library 815 can be configured on the host local file system and for some desired programs and applications that can be called from an application running within the MT application server. It can contain containerized application images (eg .tar files). Such application images may include, for example, commonly required OS programs and applications.

According to one embodiment, the MT application (ie, JEE application 606) can call a tenant unrecognized application by initiating a container process (eg, docker or rocket). A container client 720, such as a docket client, is called by an MT application using a process builder (eg, a JEE application 606 running on partition 605 of tenant 2) from the originator of the request (ie, the JEE application). OS (tenant unrecognized) applications can be started using the tenancy context. The container client can call the container daemon 725, such as the docker daemon. The container daemon can then download and start the application image 740 of the requested containerized application from the JEE application. The application image 740 may include a base OS (eg, Ubuntu), along with a layered file system containing application binaries and required libraries and components. Images can be both self-contained and portable, allowing the application to run independently of the host. In addition, containerized applications can be run as separate instances. Containerized applications run on the same OS, but are executed separately. This means that two or more tenants can run different instances of the same application, separated as separate containers.

According to one embodiment, several application images 815 may be populated in the container repository 810. These application images can be prepopulated in the application image library or stored in the application image library after the container process of FIG. 8 creates the application images.

According to one embodiment, when a container is created (by a container daemon), an application image is loaded into the container, and the containerized application 730 is executed, the application is run independently of the host. Can be done.

According to one embodiment, the containerized application 730 can communicate with the tenant's virtual tenant file system 735 (based on the tenant context, eg, the partition of tenant 2 that can communicate with the OS storage 736). I / O).

According to one embodiment, a containerized application acting on behalf of the tenant (eg, tenant 2) can access the tenant's database 608 with the required credentials.

According to one embodiment, the MT application can obtain the process exitValue status code (eg, from the Java process object exitValue () method) to know if the program execution was successful. The MT application can also search the redirected stdout and stderr files under the output and error subfolders to see if the process execution was successful. When the execution of the tenant-unaware containerized application is completed, the updated results in the tenant database can be accessed directly from the database by the MT application running in the partition.

According to one embodiment, the MT application can also delete the process working directory and its subfolders, which cleans up output files such as wallets and db files.

FIG. 9 is a flow chart illustrating an exemplary method for creating an environment and resources for tenant-scoped execution of a tenant-unaware process according to one embodiment. In step 910, the process working directory can be created under the tenant file system (eg, virtual tenant file system). In step 920, subdirectories under the process working directory can be created for input folders, output folders, error folders and database folders. In step 930, the input folder can be set using the data file. In step 940, the database folder can be set using the tenant database configuration file and credentials (eg, wallet). In step 950, an environment for tenant unrecognized applications (eg, OS applications / processes) can be completed for execution based on the tenant context.

FIG. 10 is a flow chart illustrating an exemplary method for creating and configuring a process builder to launch a containerized application according to one embodiment. In step 1010, a process builder instance (eg, Java Process Builder API) can be created. In step 1020, the process environment can be configured (eg, using the tenant context). In step 1030, the process working directory may be configured. In step 1040, the method allows an executable command line to be configured to start a containerized application. At step 1050, streams from containerized applications, such as input streams, output streams, and error streams, can be redirected to the input, output, and error subdirectories of the process working directory.

FIG. 11 is a flowchart showing an exemplary method for multi-tenant execution of a tenant-unrecognized OS application from an MT middleware application (eg, a JEE application) according to one embodiment. As a prerequisite to this exemplary method, an OS application (ie, an OS application intended to be called from an MT application server environment) is packaged as a containerized application (eg, a containerized application image). be able to. In step 1110, the process environment and resources for tenant ranged execution can be created as identified by the flowchart in FIG. In step 1120, a process builder (eg, a Java Process Builder API instance) can be created and configured as identified by the flowchart in FIG. In step 1130, according to the method, the containerized OS application process can be called using the process builder start method. This step creates the configured tenant-specific execution environment and starts the container process. The containerized application can be executed in the tenant-specific environment and resources in a state where the execution time is separated from other container & OS processes executed by the container execution time. At step 1140, the method may wait for the containerized application process execution to complete. In step 1150, the process output from the stdout file in the process working directory and the process output from the tenant database are searched, one of the necessary post-processings is executed, and the result is reflected to create a tenant-specific database. Update. At step 1160, the method may delete and clean up the process working directory and its contents.

FIG. 12 is a flow chart illustrating an exemplary method for supporting tenant-scoped execution of a tenant-unaware process called from a multi-tenant middleware application. In step 1210, the method provides a plurality of partitions and a plurality of tenant-aware programs, each of which has domain management and execution time subdivisions, on one or more computers running an application server environment. , Each of the plurality of tenant-aware programs is associated with one of the plurality of partitions.

In step 1220, the method can associate each of the plurality of partitions and the plurality of tenant-aware programs with the one tenant for use by one of the plurality of tenants.

At step 1230, the method can call a tenant-unaware process from a calling partition out of a plurality of partitions. A calling partition is associated with a calling tenant among multiple tenants.

At step 1240, the method can collect tenancy information about calling tenants.

At step 1250, the method can scope the execution of tenant-unaware processes to calling tenants based on the collected tenancy information. By specifying the execution range, it is possible to separate the execution of the tenant unrecognized process specified in the calling tenant from other tenants in the multi-tenant middleware environment.

The present invention comprises one or more conventional general purpose or specialized digital computers, computing devices, machines, including one or more processors, memories and / or computer readable storage media programmed according to the teachings of this disclosure. Alternatively, it may be conveniently implemented using a microprocessor. Appropriate software coding can be easily prepared by a skilled programmer based on the teachings of this disclosure, as will be apparent to those skilled in the art of software technology.

In some embodiments, the invention is a non-temporary recording medium or computer (s) that contains instructions that can be used to program a computer to perform any of the processes of the invention. Includes computer program products that are readable media. This recording medium includes any type of disk, ROM, RAM, EPROM, EEPROM, DRAM, VRAM, flash memory, including floppy (registered trademark) disks, optical disks, DVDs, CD-ROMs, microdrives, and magneto-optical disks. It may include, but is not limited to, devices, magnetic or optical cards, nanosystems (including molecular memory ICs), or any type of medium or device suitable for storing instructions and / or data.

Previous descriptions of the present invention are provided for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the disclosed form itself. Numerous changes and variations will be apparent to those skilled in the art. Modifications and modifications may include any suitable combination of disclosed features. The embodiments best explain the principles of the invention and its practical application so that other skilled arts can understand the various embodiments and the various variations suitable for the particular application intended. To be selected and described. The scope of the present invention is intended to be defined by the appended claims and their equivalents.

Claims (30)

A method for supporting tenant-scoped execution of tenant-unaware processes called from multi-tenant middleware applications.
On one or more computers running the application server environment
Multiple partitions, each providing a reference to the resources used when running the application server environment,
Each of the plurality of tenant-aware programs includes a step of providing a plurality of tenant-aware programs, and each of the plurality of tenant-aware programs is associated with one of the plurality of partitions.
A step of associating each of the plurality of partitions and each of the plurality of tenant-aware programs with the one tenant so as to be used by one of the plurality of tenants.
The calling partition comprises a step of calling the tenant unrecognized process from the calling partition of the plurality of partitions, the calling partition is associated with the calling tenant of the plurality of tenants, and the method further comprises.
Steps to collect tenancy information about the calling tenant,
Steps to create a tenant-specific virtual file system based on the tenancy information collected for the calling tenant, and
The execution of the tenant unrecognized process includes the step of specifying the execution of the tenant unrecognized process to the calling tenant by setting the process execution environment and resources based on the collected tenancy information. The step of specifying the range to the calling tenant is
The tenant-unaware process stream includes a step of redirecting the tenant-unaware process stream to the tenant-specific virtual file system, and the tenant-unaware process stream includes at least one of an input stream, an output stream, and an error stream.
A method that allows the execution-scoped step to separate the execution of the tenant-unaware process scoped to the calling tenant from other tenants in a multi-tenant middleware environment. The multi-tenant middleware application is associated with the calling partition among the plurality of partitions, and the multi-tenant middleware application passes the tenancy information in association with calling the tenant-unaware process. , The method according to claim 1. The step of creating a process working directory under the tenant-specific virtual file system is further included, and the process working directory includes an input subdirectory, an output subdirectory, a database subdirectory, and an error subdirectory, according to claim 1 or 2. The method described. Steps to set the input subdirectory with at least one data file,
The method according to the steps including, in claim 3 for setting the wallet containing the configuration files and credentials associated with the calling tenant under the database subdirectory. After the completion of the tenant unaware process, the tenant unaware process further includes the step of accessing the tenant-specific database, the access being granted through the wallet, and further.
The tenant-specific virtual file system includes a step of cleaning up the tenant-specific virtual file system after the tenant-unrecognized process is completed and the tenant-unrecognized process accesses the tenant-specific database. 4. The method of claim 4, wherein the step of cleaning up includes the step of deleting the process working directory. The method according to any one of claims 3 to 5, wherein the stream of the tenant-unaware process is redirected to the input subdirectory, the output subdirectory, and the error subdirectory of the process working directory, respectively. .. The tenant-unaware process called from the calling partition of the plurality of partitions is part of a composite application, which further runs in the context of the calling partition of the plurality of partitions. The method according to any one of claims 1 to 6, which includes a tenant-aware application. Tenant range of unrecognized processes called from multi-tenant middleware applications A system to support specified execution.
With one or more computers running the application server environment
Multiple partitions, each providing a reference to the resources used when running the application server environment,
Each tenant-aware program includes a plurality of tenant-aware programs, and each tenant-aware program is associated with one of the plurality of partitions.
Each of the plurality of partitions and each of the plurality of tenant-aware programs are associated with the one tenant so as to be used by one of the plurality of tenants.
The calling partition among the plurality of partitions calls the tenant-unaware process, and the calling partition is associated with the calling tenant among the plurality of tenants.
Tenancy information about the calling tenant is collected
The tenant-specific virtual file system is created based on the tenancy information collected for the calling tenant.
Based on the collected tenancy information, the execution of the tenant unrecognized process is scoped to the one tenant by setting the process execution environment and resources, and the execution of the tenant unrecognized process is executed by the calling tenant. The step to specify the range is
The tenant-unaware process stream includes a step of redirecting the tenant-unaware process stream to the tenant-specific virtual file system, and the tenant-unaware process stream includes at least one of an input stream, an output stream, and an error stream.
The step of scoped execution of the tenant unrecognized process makes it possible to separate the execution of the tenant unrecognized process scoped to the calling tenant from other tenants in the multitenant middleware environment. system. The multi-tenant middleware application is associated with the calling partition among the plurality of partitions, and the multi-tenant middleware application passes the tenancy information in association with calling the tenant-unaware process. , The system according to claim 8. The system according to claim 8 or 9, wherein the process working directory is created under the tenant-specific virtual file system, and the process working directory includes an input subdirectory, an output subdirectory, a database subdirectory, and an error subdirectory. .. It said input sub-directory is set at least one data file, the under database subdirectory, the wallet containing the configuration file and credentials associated with the calling tenant Ru is set, the system according to claim 10. After the tenant unrecognized process is completed, the tenant unrecognized process uses the wallet to access the tenant-specific database, and the tenant-specific virtual file system is cleaned after the tenant unrecognized process is completed. The system according to claim 11, wherein cleaning up the tenant-specific virtual file system is including deleting the process working directory. The system according to any one of claims 10 to 12, wherein the stream of the tenant-unaware process is redirected to the input subdirectory, the output subdirectory, and the error subdirectory of the process working directory, respectively. .. The tenant unrecognized process called from the calling partition among the plurality of partitions is a part of a composite application, and the composite application is further executed in the context of the calling partition among the plurality of partitions. The system according to any one of claims 8 to 13, including a recognition type application. A method for supporting tenant-scoped execution of tenant-unaware processes called from multi-tenant middleware applications.
On one or more computers running the application server environment
Each partition has multiple partitions that provide references to the resources used when running the application server environment.
Each of the plurality of tenant-aware programs includes a step of providing a plurality of tenant-aware programs, and each of the plurality of tenant-aware programs is associated with one of the plurality of partitions.
A step of associating each of the plurality of partitions and each of the plurality of tenant-aware programs with the one tenant so as to be used by one of the plurality of tenants.
The calling partition includes a step of calling the tenant unrecognized process from the calling partition among the plurality of partitions, the calling partition is associated with the calling tenant among the plurality of tenants, and the method further comprises.
Steps to collect tenancy information about the calling tenant,
The execution of the tenant unrecognized process includes the step of specifying the execution of the tenant unrecognized process to the calling tenant by setting the process execution environment and resources based on the collected tenancy information. The step of specifying the range to the calling tenant is
The containerized process includes a library and an executable associated with the tenant unrecognized process and includes a step of initiating the tenant unrecognized process as a containerized process.
A method, wherein the containerized process is a stand-alone process that can separate the execution of the tenant-unaware process for the calling tenant from other tenants in a multi-tenant middleware environment. Further including the step of creating a tenant-specific virtual file system based on the tenancy information collected for the calling tenant, the tenant-specific virtual file system includes an input subdirectory, an output subdirectory, a database subdirectory and 15. The method of claim 15, which includes an error subdirectory. After the completion of the tenant unaware process, the tenant unaware process further includes the step of accessing the tenant-specific database.
15. The method of claim 15 or 16, wherein the tenant-unaware process uses a wallet containing configuration files and credentials associated with the calling tenant to access the tenant-specific database. The step of starting the tenant unrecognized process as a containerized process is
Including the step of accessing the application image by the container daemon, the application image is associated with the tenant unrecognized process, and further.
Steps to create a container associated with the tenant,
The method of any one of claims 15-17, comprising the step of initiating the application image in the container. The method of claim 18, wherein the accessed application image is stored in an application image repository. The method of claim 18 or 19, wherein the stream of application images is redirected to the tenant-specific virtual file system, and the stream of application images comprises at least one of an input stream, an output stream and an error stream. .. The tenant-unaware process called from the calling partition of the plurality of partitions is part of a composite application, which further runs in the context of the calling partition of the plurality of partitions. The method of any one of claims 15 to 20, comprising a tenant-aware application. Tenant range of unrecognized processes called from multi-tenant middleware applications A system to support specified execution.
With one or more computers running the application server environment
Multiple partitions, each providing a reference to the resources used when running the application server environment,
Each tenant-aware program includes a plurality of tenant-aware programs, and each tenant-aware program is associated with one of the plurality of partitions.
Each of the plurality of partitions and each of the plurality of tenant-aware programs are associated with the one tenant so as to be used by one of the plurality of tenants.
Of the plurality of partitions, the calling partition calls the tenant-unaware process, and the calling partition is associated with the calling tenant among the plurality of tenants.
Tenancy information about the calling tenant is collected
By setting the process execution environment and resources based on the collected tenancy information, the execution of the tenant unrecognized process is scoped to the one tenant.
Specifying the execution of the tenant unrecognized process to the calling tenant is not possible.
Including starting the tenant unrecognized process as a containerized process, the containerized process contains libraries and executables associated with the tenant unrecognized process.
The containerized process is a stand-alone process that can separate the execution of the tenant-unaware process for the calling tenant from other tenants in a multi-tenant middleware environment. Based on the tenancy information collected for the calling tenant, a tenant-specific virtual file system is created, and the tenant-specific virtual file system has input subdirectories, output subdirectories, database subdirectories, and error subdirectories. 22. The system according to claim 22. According to claim 22 or 23, after the tenant unrecognized process is completed, the tenant unrecognized process accesses the tenant-specific database using the wallet containing the configuration file and credentials associated with the calling tenant. Described system. Starting the tenant unrecognized process as a containerized process
Including accessing the application image from the container daemon, the application image is associated with the tenant unrecognized process, and further.
Creating a container associated with the tenant
The system according to any one of claims 22 to 24, comprising initiating the application image in the container. 25. The system of claim 25, wherein the accessed application image is stored in an application image repository. 25 or 26. The system of claim 25 or 26, wherein the stream of application images is redirected to a tenant-specific virtual file system, the stream of application images comprising at least one of an input stream, an output stream and an error stream. The tenant unrecognized process called from the calling partition among the plurality of partitions is a part of a composite application, and the composite application is further executed in the context of the calling partition among the plurality of partitions. The system according to any one of claims 22 to 27, which includes a tenant-aware application. A computer program comprising a program instruction, wherein the program instruction is executed by one or more computers, according to any one of claims 1 to 7 and 15 to 21 to the one or more computers. A computer program that runs the method. A system configured to perform the method according to any one of claims 1-7 and 15-21.

Images