KR102559507B1 - System and method for multi-tenant execution of OS programs called from multi-tenant middleware applications - Google Patents

Abstract

According to one embodiment, the present invention discloses a system and method for supporting multi-tenant execution of tenant-unaware programs called from multi-tenant middleware applications. An exemplary method may provide a plurality of partitions and a plurality of tenant-aware programs, each of the plurality of tenant-aware programs associated with a partition. The method may associate each of the plurality of partitions and the plurality of tenant-aware programs with one tenant of the plurality of tenants. The method may invoke a tenant-unaware process from a calling partition of a plurality of partitions, and the calling partition is associated with one calling tenant of the plurality of tenants. The method may collect tenancy information for a calling tenant. Also, based on the collected tenancy information, the method may scope execution of a tenant-unrecognized process to a calling tenant by setting a process execution environment and resources.

Description

System and method for multi-tenant execution of OS programs called from multi-tenant middleware applications

Copyright Notice

A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to anyone's facsimile reproduction of this patent document or the patent disclosure as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights.

Embodiments of the present invention relate generally to application servers and cloud environments, and more particularly to systems and methods for supporting applications invoked from multi-tenant middleware platforms.

Software application servers include, for example, Oracle WebLogic Server (WLS) and Glassfish, and generally provide a managed environment for running enterprise software applications. Recently, technologies for use in a cloud environment have been developed, enabling users or tenants to develop and execute their applications in the cloud environment and utilize distributed resources provided by the corresponding environment.

According to one embodiment of the present invention, the present invention discloses a system and method for supporting multi-tenant execution of a tenant-unaware program called from a multi-tenant middleware application. An exemplary method may provide a plurality of partitions and a plurality of tenant-aware programs, each of the plurality of tenant-aware programs associated with a partition. The method may associate each of the plurality of partitions and the plurality of tenant-aware programs with one tenant of the plurality of tenants. The method may invoke a tenant-unaware process from a calling partition of a plurality of partitions, and the calling partition is associated with one calling tenant of the plurality of tenants. The method may collect tenancy information for a calling tenant. Also, based on the collected tenancy information, the method may scope execution of a tenant-unrecognized process to a calling tenant by setting a process execution environment and resources.

According to an embodiment of the present invention, using containerized applications, the scoped execution supports run-time separation of tenant-unaware processes from other tenants in a multi-tenant middleware environment, resulting in multi-tenant operation of OS application programs.

1 illustrates a system for supporting multi-tenancy in an application server, cloud or other environment, according to one embodiment of the present invention.
2 further illustrates a system for supporting multi-tenancy in an application server, cloud or other environment, according to an embodiment of the present invention.
3 further illustrates a system for supporting multi-tenancy in an application server, cloud or other environment, according to an embodiment of the present invention.
4 illustrates a domain configuration for use with an exemplary multi-tenant environment, in accordance with one embodiment of the present invention.
5 further illustrates an exemplary multi-tenant environment, in accordance with one embodiment of the present invention.
6 illustrates a system for tenant scoped execution of a tenant-unaware process, according to one embodiment of the present invention.
7 illustrates a system for tenant scoped execution of a tenant-unaware process, according to one embodiment of the present invention.
8 illustrates a system for tenant scoped execution of a tenant-unaware process, according to one embodiment of the present invention.
9 is a flow diagram of an exemplary method for creating an environment and resources for tenant-scoped execution of a tenant-unaware process, according to one embodiment of the present invention.
10 is a flow diagram of an exemplary method for creating and configuring a process builder, according to one embodiment of the present invention.
11 is a flow diagram of an exemplary method for multi-tenant execution of a tenant-unaware OS application from an MT middleware application (eg, a JEE application), according to an embodiment of the present invention.
12 is a flow diagram of an exemplary method for supporting tenant scoped execution of tenant-unaware processes invoked from multitenant middleware applications.

According to one embodiment, disclosed herein are systems and methods that support tenant-scoped execution (also variously referred to herein as "multitenant execution") of tenant-unaware (also variously referred to herein as "tenant unaware") processes invoked from multitenant middleware applications. Exemplary methods may provide a plurality of partitions and a plurality of tenant-aware (also variously referred to herein as "tenant aware") programs, each of the plurality of tenant-aware programs associated with a partition. The method may associate each of the plurality of partitions and the plurality of tenant-aware programs with one tenant of the plurality of tenants. The method may call a tenant-unaware process from a calling partition of a plurality of partitions, and the calling partition is associated with a calling tenant of the plurality of tenants. This method can collect tenancy information for the calling tenant. Further, based on the collected tenancy information, the method may set a process execution environment and resources to scope (set a scope) the execution of a tenant-unrecognized process to the calling tenant.

Using the systems and methods described herein, according to one embodiment, a tenant-aware JEE application (e.g., a SaaS application) comprising non-Java components running as native programs/processes on an operating system can operate in a tenant-scoped manner, and be fully application (end-to-end) multi-tenant aware and isolate. That is, multi-tenancy support provided within the multi-tenant application server environment can be supported outside the MT application server environment on the native OS, and is not limited to components/programs executed within the MT application server environment (eg, WebLogic MT).

application Server (e.g. multi-tenant ( Multitenant) , MT ) environment

1 illustrates a system for supporting multi-tenancy in an application server, cloud, or other environment according to an embodiment of the present invention.

1 , according to one embodiment of the present invention, an application server (e.g., multi-tenant, MT) environment 100 or other computing environment that enables the deployment and execution of software applications may be configured to include and operate according to the configuration of the domain 102 used at run-time to define the application server domain.

According to one embodiment of the invention, an application server may include one or more partitions 104 defined for use at runtime. Each partition may be associated with a globally unique partition identifier (ID) and partition configuration, and may further include one or more resource groups 124 with references to resource group templates 126 and/or partition-specific applications or resources 128. Domain-level resource groups, applications and/or resources 140 may also optionally be defined at the domain level with references to resource group templates.

Each resource group template 160 may define one or more applications A 162, B 164, resources A 166, B 168 and/or other deployable applications or resources 170 and may be referenced by a resource group. For example, as shown in FIG. 1 , resource group 124 within partition 104 may reference 190 resource group template 160 .

In general, system administrators can define partitions, domain-level resource groups and resource group templates, and security realms, and partition managers can define aspects of their own partitions, for example, by creating partition-level resource groups, deploying applications to partitions, or referencing specific realms for partitions.

2 further illustrates a system for supporting multi-tenancy in an application server, cloud or other environment according to an embodiment of the present invention.

As shown in FIG. 2 , according to one embodiment, a partition 202 may include, for example, a resource group 205 including a reference 206 of a resource group template 210, virtual target (e.g., virtual host) information 207, and pluggable database (PDB) information 208. A resource group template (e.g., 210) may define multiple applications 2111 and B212 along with resources such as, for example, a Java Message Server (JMS) server 213, a store-and-forward (SAF) agent 215, a mail session component 216, or a Java Database Connectivity (JDBC) resource 217.

The resource group template shown in FIG. 2 is provided as an example, and other types of resource group templates and elements may be provided according to other embodiments.

According to one embodiment of the present invention, if a resource group within a partition (e.g., 202) references (220) a specific resource group template (e.g., 210), information related to the specific partition may be used in conjunction with the referenced resource group template to indicate partition-specific information (230), e.g., partition-specific PDB information. The partition-specific information can then be used by the application server to configure the resources that partition will use, such as PDB resources. For example, partition-specific PDB information associated with a partition 202 can cause an application server to construct 232 a container database (CDB) 236 with an appropriate PDB 238 for use by that partition.

Similarly, according to one embodiment of the present invention, virtual target information associated with a particular partition may be used to define a partition-specific virtual target 240 for use by the partition, e.g., baylandurgentcare.com accessible via a Uniform Resource Locator (URL) (e.g., http://baylandurgentcare.com).

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

According to one embodiment of the present invention, a system configuration such as a config.xml configuration file is used to define a partition including configuration elements for resource groups and/or other partition attributes associated with that partition. Values can be specified per partition using attribute name/value pairs.

According to one embodiment of the invention, the plurality of partitions may run within the management server/cluster 242 or within a similar environment that may provide access to the CDB 243 and is accessible via a web tier 244. This enables, for example, one domain or partition to be associated with more than one PDB (CDB's).

According to one embodiment of the present invention, each of a plurality of partitions, in this example partition A 250 and partition B 260, may be configured to include a plurality of resources related to that partition. For example, partition A may be configured to include a resource group 251 containing application A1 252, application A2 254, and JMS A 256, with data source A 257 associated with PDB A 259, where the partition is accessible via virtual target A 258. Similarly, partition B 260 can be configured to include a resource group 261 that includes application B1 262, application B2 264, and JMS B 266, along with data source B 267 associated with PDB B 269, where the partition is accessible via virtual target B 268.

While some of the above embodiments illustrate the use of CDBs and PDBs, other types of multitenant or non-multitenant databases may be supported according to other embodiments, where specific configurations may be provided to each partition, for example through the use of schemas or other databases.

resource (Resources)

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

partition ( Partitions )

According to one embodiment of the invention, a partition is a runtime and administrative subdivision or slice of a domain that can be associated with a partition identifier (ID) and configuration, can contain applications, and/or can reference domain-wide resources using resource groups and resource group templates.

In general, a partition can contain its own applications, reference domain-wide applications through resource group templates, and have its own configuration. Partitionable entities may include resources such as JMS, JDBC, JavaMail, WLDF resources, or other components such as JNDI namespaces, network traffic, task managers, security policies and realms, and the like. In the context of a multi-tenant environment, the system can be configured to provide tenants with access to the management and runtime aspects of the partitions associated with the tenants.

According to an embodiment of the present invention, each resource group in a partition may optionally refer to a resource group template. A partition can have multiple resource groups, each of which can reference a resource group template. Each partition can define attributes for configuration data that are not specified in the resource group template referenced by the partition's resource group. This allows partitions to function as binding deployable resources defined by resource group templates to specific values that should be used in that partition. In some cases, a partition can override configuration information specified by a resource group template.

According to one embodiment of the present invention, a partition configuration comprises a plurality of configuration elements, eg partitions (including attributes and child elements defining the partitions), as defined eg by the config.xml configuration file; resource-groups (containing applications and resources deployed on partitions); a resource-group-template (which contains the applications and resources defined by the template); jdbc-system-resource-override (contains database-specific service name, username and password); and partition-properties (including property key values usable for macro substitution in resource group templates).

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

resource group( Resouece Groups )

According to one embodiment of the present invention, a resource group is a collection of fully-qualified deployable resources given a name, which can be defined at the domain or partition level and can refer to a resource group template. A resource in a resource group is considered fully verified in that the administrator has provided all information required to start or access the resource, such as credentials for accessing a data source or target information for an application.

System administrators can declare resource groups at the domain level or partition level. At the domain level, resource groups provide a convenient way to group related resources. The system can manage resources declared in domain-level resource groups the same as ungrouped resources so that the resources can be started during system startup or stopped during system shutdown. Administrators can also individually stop, start, or delete resources within a group, and act on the group to implicitly affect all resources within the group. For example, stop a resource group to stop all resources in the group that have not yet been stopped, start a resource group to start any resource in the group that has not yet been started, and delete a resource group to delete all resources in the group.

At the partition level, the system or partition manager can configure zero or more resource groups in the partition, subject to arbitrary security restrictions. For example, in SaaS use cases, various partition-level resource groups can reference domain-level resource group templates. In contrast, in a PaaS use case, a partition-level resource group can be created that does not reference a resource group template, but instead represents applications and related resources available only within that partition.

According to one embodiment of the present invention, resource grouping may be used to group together applications and resources used by the applications as separate management units within a domain. For example, in the Medical Records (MedRec) application described below, a resource grouping defines the MedRec application and its resources. Multiple partitions can each run the same MedRec resource group using partition-specific configuration information, so applications that are part of each MedRec instance can be specific to each partition.

resource group template ( Resource Group Templates )

According to one embodiment of the present invention, a resource group template is a set of deployable resources that can be referenced from a resource group and defined at the domain level, and some of the information required to activate its resources may not be stored as part of the template itself, to support the specification of partition level configuration. A domain can contain any number of resource group templates, and each of these resource group templates can contain, for example, one or more related Java applications and the resources on which the applications depend. Some of the information about these resources may be the same across all partitions, while other information may change from partition to partition. Not all configurations need to be specified at the domain level, instead partition level configurations can be specified within resource group templates through the use of macros or property name/value pairs.

According to one embodiment of the invention, a particular resource group template may 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, i.e., it cannot be simultaneously referenced by multiple resource groups within the same partition. However, it can be simultaneously referenced by other resource groups in different partitions. An object containing a resource group, eg a domain or partition, may set an arbitrary token value in a resource resource template using a property name/value assignment. When the system activates a resource group template using the resource group it references, the system can replace its token with the value set in the object containing the resource group. In some cases, the system can also use statically configured resource group templates and partitions to create runtime configurations for each partition/template combination.

For example, in a SaaS use case, the system can activate the same applications and resources multiple times, including one activation for each partition that will use them. When administrators define resource group templates, they can use tokens to represent information to be provided elsewhere. For example, the username used when accessing CRM-related data resources could be represented as /${CRMDataUsername} in the resource group template.

tenant (tenants)

According to one embodiment of the invention, 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 may represent an individual user organization, eg, a different external company, or different departments within a particular enterprise (eg, HR and finance departments), each of which may be associated with a different partition. A tenant's universally unique identifier (tenant ID) associates a particular user with a particular tenant at a particular point in time. The system can derive which tenant a particular user belongs to from the user identity, for example by consulting a user identity store. User identity may enable the system to enforce those actions that the user is authorized to perform, including but not limited to which tenants the user may belong to.

According to an embodiment of the present invention, the system can separate management and runtime of different tenants from each other. For example, a tenant can configure some behavior of their applications and the resources they have access to. The system can ensure that a specific tenant does not manage artifacts belonging to another tenant, and at runtime, an application performing work on behalf of a specific tenant can only refer to resources related to that tenant without referring to resources related to other tenants.

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

According to one embodiment of the present invention, the system enables users to deploy applications explicitly written to be tenant aware, whereby application developers can obtain the tenant ID of the current tenant. A tenant-aware application can then use the tenant ID to handle multiple tenants using a single instance of the application.

For example, a MedRec application supporting a single clinic or hospital may expose two different partitions or tenants, e.g., a Bayland Urgent Care tenant and a Valley Health tenant, each of which can access individual tenant-specific resources (e.g., individual PDBs) without changing the underlying application code.

Exemplary Domain Configuration and Multi-Tenant Environment

According to one embodiment of the present invention, an application can be deployed in a resource group template at the domain level, or in a resource group that is scoped to a partition or scoped to a domain. Application configuration can be overridden using a placement plan specified on a per-application or per-partition basis.

4 illustrates a domain configuration used in an exemplary multi-tenant environment according to one embodiment.

According to one embodiment of the present invention, when the system starts a partition, the system creates a virtual target (e.g., virtual host) and connection pool, one for each partition, for each database instance according to the provided configuration.

Each resource group template may typically contain one or more related applications and the resources on which those applications depend. Each partition can provide configuration data not specified in the resource group template it references, which can be done by binding deployable resources in the resource group template to specific values associated with the partition, and in some cases may include overriding some configuration information specified by the resource group template. In this way, the system can activate applications differently expressed by the resource group template for each partition using the characteristic values defined by each partition.

In some instances, a partition may contain resource groups that do not reference resource group templates, or that directly define their own partition-scoped deployable resources. Applications and data sources defined within a partition are usually available only to that partition. Resources can be deployed so that they can be accessed from multiple partitions using <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 a MedRec application for multiple tenants, a system administrator can define a single MedRec Resource Group template and declare these deployable resources in the template.

In contrast to domain-level deployable resources, deployable resources declared in a resource group template may not be fully configured in the template, or cannot be activated as-is because some configuration information is missing.

For example, a MedRec resource group template may declare a data source used by an application, but may not specify a URL to connect to a database. Partitions related to different tenants, e.g., partition BUC-A 290 (Bayland Urgent Care: BUC) and partition VH-A 292 (Valley Health: VH), may reference one or more resource group templates by including MedRec Resource Groups 293 and 294, respectively, which reference (296, 297) MedRec Resource Group templates. These references can then be used to create 302, 306 virtual targets/virtual hosts for each tenant, which may include the virtual host baylandurgentcare.com 304 associated with the BUC-A partition used by Bayland emergency care tenants and the virtual host valleyhealth.com 308 associated with the VH-A partition used by Valley Health tenants.

5 further depicts an exemplary multi-tenant environment in accordance with one embodiment of the present invention. Continuing the example from the foregoing example where two partitions refer to the MedRec resource group template, as shown in FIG. 5 and in accordance with one embodiment of the present invention, servlet engine 310 may be used to support multiple tenant environments, in this example a Bayland emergency physician tenant environment 320 and a Valley Health physician tenant environment 330.

According to one embodiment of the present invention, each partition 321, 331 may define a different virtual target that accepts traffic flowing into the corresponding tenant environment, and may also define different URLs 322, 332 for accessing the partition and its resources 324, 334, which in this example may include the Bayland Emergency Medical Database or the Valley Health Database, respectively. Because the same application code can be run against both databases, database instances can use compatible schemas. When the system initiates partitions, it can create virtual targets and connection pools for each database instance.

OS of the program tenant scoped execution( Tenant Scoped Execution of OS Programs)

According to one embodiment of the present invention, the methods and systems described herein may support tenant scoped execution that supports OS (i.e., tenant-unaware) programs, applications, and processes (hereinafter variously referred to as “OS programs,” “OS applications,” “OS processes,” “non-tenant aware programs,” “non-tenant aware applications,” and “non-tenant aware processes”).

Typically, when an application runs within an MT environment, the application is scoped to the tenant, which means that libraries and resources accessed by tenant aware programs are isolated from other tenants within the MT environment, for example.

However, when a tenant-aware program running in the MT environment calls a tenant-unaware application (e.g., C, C++, Perl, etc.) running on a native OS, problems may arise in that there is little or no separation between these programs running on the OS. That is, the general-purpose operating system does not have a concept of tenancy, and therefore does not know tenancy associated with the MT application (ie, JEE application) (ie, tenancy information related to an outgoing call of the MT application). It can run OS programs within a common environment and use shared OS resources (e.g. files, processes, databases), which can then lose tenant context as well as runtime separation/isolation when separate tenant applications call external OS applications (e.g. tenant unaware applications).

6 illustrates a system for tenant scoped execution of a tenant-unaware process according to one embodiment of the present invention. As shown in FIG. 6 , a multi-tenant application server environment 600 (eg, WebLogic multi-tenant) may include multiple tenant partitions, such as a tenant 1 partition 601 and a tenant 2 partition 605 . Both the Tenant 1 partition and the Tenant 2 partition may be associated with applications, such as JEE applications 602 and 606, respectively, which are associated with data sources 603 and 607 that allow access to the tenant's respective databases 604 and 608, respectively.

According to one embodiment of the present invention, an application such as a JEE application associated with tenant 2 may call an OS program (calling process) located outside the multi-tenant application server within the native OS 610, for example. This situation may arise, for example, when there are components of MT applications that are not limited to MT application servers (eg Perl scripts, C programs, etc.). Such applications (i.e., MT applications that depend on external OS components running outside of the MT application server) may be referred to as composite applications. A JEE application associated with Tenant 2 runs in the MT environment and has a Tenant context associated with it at runtime.

According to one embodiment of the present invention, when an MT application (e.g., JEE application) calls an OS program/application (i.e., process 620), the MT application may set a number of variables 625 (i.e., environment variables) to extend/propagate tenant contexts available to the JEE application. These variables include tenant ID, tenant name, tenant filesystem (TFS) root; process working directory under TFS with input and output subdirectories; It may include the tenant DB connection string and the tenant Lightweight Directory Access Protocol (LDAP) directory URL.

According to an embodiment of the present invention, the MT application server can manage the virtual tenant file system 630 for each tenant installed in the MT application server environment 600. This virtual tenant file system can be created/configured as part of application server management when a tenant is mounted. Virtual tenant file systems are part of the OS 610, and have one virtual tenant file system for each tenant currently active in the MT application server environment.

According to an embodiment of the present invention, when an MT application (eg, JEE application) calls an OS process (ie, a process not recognized by the tenant), the MT application may additionally create a temporary process working directory under the tenant's virtual file system. When more than one OS process is called by an MT application, the MT application can create one temporary working directory for each called OS process. When creating the temporary working directory under the virtual filesystem, the MT application may additionally create subdirectories under the temporary working directory for the input, output, error and database directories (for each OS process invoked). These subdirectories can accept redirected stdin (input stream), stdout (output stream) and stderr (error stream) of the called OS process. Each input subdirectory can be set to a process input file. Each output subdirectory can capture process output files. Each error subdirectory can capture process error (eg stderr) messages. A virtual tenant-specific filesystem may be associated with native storage such as OS storage 640 .

According to one embodiment of the present invention, a process builder may include an API (e.g., a Java ProcessBuilder API) that allows a client to specify and execute a command line for an OS program/application, configure environment variables to set in the process environment, configure process working directories, and redirect process input, output, and error streams to files on the filesystem. A process builder may allow certain process properties to be set or configured before a process (i.e. OS process) starts, such as process environment, process working directory, and redirection of process input streams/output streams/error streams.

According to an embodiment of the present invention, when an MT application calls an OS process, a process builder (eg, a process builder instance) may be created and used. The MT application's tenancy context can be propagated as part of the Process Builder API call, including setting environment variables and creating and configuring process working directories. By using environment variables along with process working directories, process builders can be configured to assign resources (environment variables, process working directories, redirected input/output files, database connection descriptors, LDAP directories, wallets) to which the execution of tenant-unaware processes (e.g., OS processes) are scoped/confined within the tenancy context. In this way, a tenant-unaware process (e.g., an OS process) is specified under the calling tenant and tenant-specified virtual filesystem, and gets a working directory separate from files and resources created or owned by other tenants of the MT application server environment 600.

According to one embodiment of the present invention, a tenant-unaware process is assigned a tenant-specific folder under the OS filesystem for redirected process I/O streams, uses tenant-specific access credentials to access a database associated with the tenant, and uses the tenant LDAP directory. Tenant-specific database connection strings/descriptors allow programs to work transparently with the tenant database. Tenant-specific certificates can be configured in a wallet set in the database subdirectory under the process working directory in the tenant's virtual filesystem.

According to one embodiment of the present invention, after a virtual tenant filesystem is created for a calling MT application from a calling partition (associated with a tenant, often referred to as a calling "tenant"), tenant unaware processes and associated streams (e.g., input streams, output streams, error streams) may be redirected to respective input, output, and error subdirectories under the process working directory in the tenant's virtual filesystem.

In this way, the tenancy context, environment, and data associated with the separate tenant invoking the OS programs can be maintained separately and separated from each other, thereby enabling scoped processing of OS applications (tenant unaware) that run based on calls from inside the MT container (e.g., from a JEE program running on behalf of a partition within the MT container).

According to one embodiment of the present invention, once a tenant unaware process has completed execution, the MT application running in the MT application server environment can retrieve the process output and clean up the process working directory.

According to one embodiment of the present invention, the MT application can obtain a process exitValue status code (eg, Java process object exitValue() method) to confirm whether the program has been successfully executed. You can also inspect whether the process execution was successful by looking for the redirected stdout and stderr files in the Outputs and Errors subfolder. Results updated in the tenant database can be accessed directly from the database by the MT application running in the partition once the tenant unaware process execution is complete.

According to one embodiment of the present invention, the MT application may also delete the process working directory and its subfolders to organize output files such as wallets and db files.

According to one embodiment of the present invention, the environment variables configured in the MT application calling the OS program include a tenant ID, a tenant name; Tenant File System (TFS) root; Process working directory with input, output, and error subdirectories in TFS; Contains the tenant DB connection string and the tenant Lightweight Directory Access Protocol (LDAP) directory URL.

According to one embodiment of the present invention, using process builder constructs, a tenant unaware OS program can be assigned resources (environment variables, process working directories, redirected input/output files, DB connection descriptors, LDAP directories and wallets) whose execution within the tenant context is scoped/confined.

OS Multi-tenant execution of programs - containerized application { Multitenant Execution of OS Programs-Containerized Applications}

According to one embodiment of the present invention, the methods and systems described herein can provide tenant separation at runtime by supporting multitenant execution of tenant unaware processes (ie, OS processes) using containerized applications.

According to one embodiment of the invention, the present disclosure may provide tenant separation during runtime of a tenant unaware process using a containerized application.

According to an embodiment of the present invention, a containerized application or process is an application that is packaged as a container and includes information necessary for application execution, such as an OS-based image, an application execution file, and a library. A 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. For containerized applications, when a developer creates a portable/containerized application, shares an image, and uses the same Linux kernel, the system in which the containerized application is shared can download the containerized application image from an image registry or repository, spin off the container, and create a containerized application to run the containerized application. At this point, the application can be used on the destination host, separate from other containers and OSes, and can continue to be used with the necessary libraries (e.g., the same version of the library as intended by the developer of the application/process). Then there may be other containerized application instances using the same version of the library, but running separately. Docker is an example of such a container framework/infrastructure.

7 illustrates a system for multi-tenant execution of a tenant-unaware process, according to one embodiment. 7 illustrates multi-tenant execution of OS programs called from MT applications and using containerized OS applications running on an OS that supports software containers.

As shown in FIG. 7 , an MT application server environment 600 (eg, WebLogic multi-tenant) may include multiple tenant partitions, such as a Tenant 1 Partition 601 and a Tenant 2 Partition 605 . Both the Tenant 1 partition and the Tenant 2 partition may be associated with applications such as JEE applications 602 and 606 associated with data sources 603 and 607, respectively, allowing access to respective databases 604 and 608 for each tenant.

According to an embodiment of the present invention, when an MT application (e.g., JEE application) calls a tenant-unaware application (e.g., a containerized application), the MT application sets a number of variables (i.e., environment variables) to expand/propagate the tenant context usable by the JEE application. These variables include tenant ID, tenant name, tenant filesystem (TFS) root; Process working directory with input, output, and error subdirectories in TFS; Can include tenant DB connection string and tenant LDAP directory URL. According to an embodiment of the present invention, the MT application server may manage a virtual tenant file system 735 for each tenant installed in the MT application server environment 600. This virtual tenant file system can be created/configured as part of application server management when a tenant is mounted. The virtual tenant file system is a part of the OS 610 having one virtual tenant file system for each tenant currently active in the MT application server environment.

According to one embodiment of the present invention, when an MT application (e.g., a JEE application) calls a tenant-unaware application, the MT application may additionally create a temporary process working directory (also referred to herein as a "process working directory") under the tenant's virtual filesystem. If one or more tenant unrecognized applications are called by the MT application, the MT application may create one process working directory for each called tenant unrecognized application. When creating a process working directory under a virtual filesystem, MT applications may additionally create subdirectories (per exported tenant unaware application) under the process working directory for the input, output, error and database directories. These subdirectories can receive the redirected stdin (input stream), stdout (output stream) and stderr (error stream) of the called OS process. Each input subdirectory can be set to a process input file. Each output subdirectory can capture process output files. Each error subdirectory can capture process error (eg stderr) messages. A virtual tenant-specific filesystem may be associated with native storage such as OS storage 736 .

According to one embodiment of the invention, process builders that may be used by MT applications include APIs (e.g., Java ProcessBuilder APIs) that allow clients to specify command lines to run tenant unaware applications, configure environment variables to set in the process environment, configure process working directories, and redirect process input, output, and error streams to files on the filesystem. Process Builder may allow certain process properties to be set or configured before a process (i.e., tenant-unaware application) is started, such as process environment, process working directory, and redirection of process input streams/output streams/error streams.

According to an embodiment of the present invention, when an MT application calls a tenant unaware application, a process builder (eg, a process builder instance) may be created and used. The MT application's tenancy context can be propagated as part of the Process Builder API call, including setting environment variables and creating temporary process working directories. By using environment variables along with temporary process working directories, process builders can be configured to assign resources (environment variables, process working directories, redirected input/output error streams, database connection descriptors, LDAP directories, wallets) to which tenant-unaware applications are scoped/confined for execution within the tenancy context. In this way, tenant-unaware applications are specific to the calling tenant and under the tenant-specified virtual filesystem, and get working directories separate from files created or owned by other tenants in the MT application server environment 600.

According to one embodiment of the present invention, a tenant-unaware process is assigned a tenant-specific folder under the OS filesystem for redirected process I/O streams, uses tenant-specific access credentials to access a database associated with the tenant, and uses a tenant-specific LDAP directory. Tenant-specific database connection strings/descriptors allow programs to work transparently with the tenant database. Tenant-specific certificates can be configured in a wallet set in the database subdirectory under the process working directory in the tenant's virtual filesystem.

According to one embodiment of the invention, after a virtual tenant filesystem is created for a calling MT application in a calling partition (associated with a tenant, often referred to as a calling “tenant”), streams (e.g., input streams, output streams, error streams) associated with tenant unaware applications (e.g., containerized applications) may be redirected to their respective input, output, and error subdirectories under the process working directory in the tenant's virtual filesystem.

According to an embodiment of the present invention, a tenant unaware application (called from an MT application such as a JEE application calling from tenant 2's partition) can be packaged as a containerized application. In one exemplary process, an MT application may call an OS program. In this case, a process builder (e.g., Java ProcessBuilder) can invoke the containerized application. Container Framework provides a lightweight container virtualization technology. One such container framework is Docker.

According to one embodiment of the present invention, a container runtime such as Docker defines a format for packaging an application and all of its dependencies into a single image. This image can be delivered to any Docker-enabled machine where it can run with the guarantee that the execution environment exposed to the application remains the same.

When using an OS with a container framework such as Docker, the system can create an application container image that includes a base OS (eg Ubuntu) along with a layered file system including application binaries and necessary libraries and components. This image can be self-contained and portable so that when the containerized application is launched, it does not depend on the host to run the application.

According to one embodiment of the present invention, an MT application (ie, JEE application 606) can invoke a tenant unaware application by initiating a container process (eg, Docker or Rocket). A container client 720, such as the Docket Client, is invoked by the MT application using a process builder (e.g., the JEE application 606 running on tenant 2's partition 605) to launch an OS (tenant unaware) application with the tenancy context of the requester (i.e., the JEE application). A container client may call a container daemon 725, such as a Docker daemon. The container daemon may download and launch the application image 740 of the containerized application requested from the JEE application. The application image 740 may include a base OS (eg Ubuntu) along with a layered file system including application binaries and necessary libraries and components. Application images are self-contained and portable, allowing applications to run without host dependencies. Also, containerized applications can run as separate instances. Containerized applications run on the same OS but in isolation, meaning that two or more tenants can run different instances of the same application in separate containers.

According to an embodiment of the present invention, when a container is created (by a container daemon) and an application image is loaded into the container to execute the containerized application 730, the application can be executed without depending on the host.

According to one embodiment of the invention, containerized applications 730 may communicate (I/O) with a tenant's virtual tenant filesystem 735 (which is based on a tenant context, e.g., a partition of tenant 2, which in turn may communicate with OS storage 736).

According to one embodiment of the present invention, a containerized application running on behalf of a tenant, eg Tenant 2, can access the tenant's database 608 with the necessary credentials.

According to one embodiment of the present invention, the MT application can obtain the process exitValue status code (eg, from the Java process object exitValue() method) to confirm whether the program was executed successfully. MT applications can also inspect whether the process execution was successful by looking for the redirected stdout and stderr files under the outputs and errors subfolders. Results updated in the tenant database can be accessed directly from the database by the MT application running in the partition once execution of the tenant-unaware containerized application is complete.

According to one embodiment of the present invention, the MT application may also delete the process working directory and its subfolders to organize output files such as wallets and db files.

8 illustrates a system for multi-tenant execution of a tenant-unaware process, according to one embodiment of the present invention. 8 shows multi-tenant execution of an OS program called from an MT application and using a containerized OS application running in a container.

As shown in FIG. 8 , an MT application server environment 600 (eg, WebLogic multi-tenant) may include multiple tenant partitions, such as a Tenant 1 Partition 601 and a Tenant 2 Partition 605 . Both the Tenant 1 partition and the Tenant 2 partition may be associated with an application, such as a JEE application 602, 606, respectively associated with a data source 603, 607 allowing access of each database 604, 608 for each tenant.

According to an embodiment of the present invention, when an MT application (e.g., JEE application) calls a tenant-unaware application (e.g., a containerized application), the MT application sets a number of variables (i.e., environment variables) to expand/propagate the tenant context usable by the JEE application. These variables include tenant ID, tenant name, tenant filesystem (TFS) root; process working directory under TFS with input and output subdirectories; Tenant DB connection string and tenant LDAP directory URL may be included.

According to an embodiment of the present invention, the MT application server may manage a virtual tenant file system 735 for each tenant installed in the MT application server environment 600. This virtual tenant filesystem can be created or configured as part of application server management when tenants are mounted. The virtual tenant file system is a part of the OS 610 having one virtual tenant file system for each tenant currently active in the MT application server environment.

According to an embodiment of the present invention, when an MT application (eg, a JEE application) calls a tenant-unrecognized application, the MT application may additionally create a temporary process working directory under the tenant's virtual file system. If one or more tenant unaware processes are called by the MT application, the MT application may create one process working directory for each called tenant unaware process. When creating process working directories under the virtual filesystem, MT applications may additionally create subdirectories (for each called tenant unaware application) under the process working directories for the input, output, error and database directories. These subdirectories can accept redirected input streams (stdin), output streams (stdout), and error streams (stderr). Each input subdirectory can be set to a process input file. Each output subdirectory can capture process output files. Each error subdirectory can capture process error (eg stderr) messages. A virtual tenant-specific filesystem may be associated with native storage such as OS storage 736.

According to one embodiment of the invention, Process Builder may include an API (e.g., the Java ProcessBuilder API) that allows a client to specify a command line for a tenant-unaware application to execute, configure environment variables to set in the process environment, configure process working directories, and redirect process input, output, and error streams to the filesystem. Process Builder may allow certain process properties to be set or configured before a process (i.e., tenant-unaware application) is started, such as process environment, process working directory, and redirection of process input streams/output streams/error streams.

According to an embodiment of the present invention, when an MT application calls a tenant unaware application, a process builder (eg, a process builder instance) may be created and used. The MT application's tenancy context can be propagated as part of the Process Builder API call, including setting environment variables. MT applications can create process working directories and subdirectories (input, output, error and database) under VTFS (Virtual Tenant File System). The MT application can then use the process builder API to construct environment variables, the process working directory with the temporary process working directory path, and the redirected stream. By using environment variables along with process working directories, process builders can be configured to allocate resources (environment variables, process working directories, redirected input/output files, database connection descriptors, LDAP directories, wallets) whose execution is scoped/confined to a tenant-unaware application within the tenancy context. In this way, tenant-unaware applications are specific to the calling tenant and under the tenant-specified virtual filesystem, and get working directories separate from files created or owned by other tenants in the MT application server environment 600.

According to one embodiment of the present invention, a tenant unaware application uses a tenant-specific folder under the OS filesystem for I/O operations, uses a tenant-specific access credential to access a database associated with the tenant, and uses tenant LDAP. Tenant-specific database connection strings/descriptors allow programs to work transparently with the tenant database. Tenant-specific certificates can be configured in a wallet set up under a database subdirectory within the process working directory in the tenant's virtual filesystem.

According to one embodiment of the invention, after a virtual tenant filesystem is created for a calling MT application in a calling partition (associated with a tenant, often referred to as a calling “tenant”), streams (e.g., input streams, output streams, error streams) associated with tenant-unaware applications (e.g., containerized applications) may be redirected to their respective subfolders under a process working directory in the tenant's virtual filesystem.

According to one embodiment of the present invention, a tenant unaware application (called from an MT application such as a JEE application calling from tenant 2's partition) can be packaged as a containerized application. In an exemplary process, an MT application may call an OS program. In this case, the process builder API is configured to invoke the container process by the MT application. One such container framework/infrastructure is Docker.

According to one embodiment of the invention, a container framework/infrastructure such as Docker may define a format for packing an application and all its dependencies into a single image. This image can be uploaded to a Docker hub/repository from where it can be downloaded and run with the guarantee that the execution environment exposed to the application will be the same.

According to an embodiment of the present invention, when using a container framework such as Docker, the system may download a previously created container image 815 from an application image library 810 . The application image 815 may include a base OS (eg Ubuntu) along with a layered file system including application binaries and necessary libraries and components. This image can be self-contained and portable, allowing the application to run without depending on the host when the container is created and the application is started.

According to one embodiment of the present invention, the application image library 815 can be set up on the host local filesystem and can contain a number of containerized images (e.g., tar files) for desired programs and applications that can be called from applications running within the MT application server. Such application images may include, for example, generally required OS programs and applications.

According to one embodiment of the present invention, an MT application (ie, JEE application 606) can initiate a container process (eg, Docker or Rocket) to call a tenant unaware application. A container client 720, such as a Docket Client, can be invoked by an MT application using a process builder (e.g., JEE application 606 running in tenant 2's partition 605) to launch an OS (tenant unaware) application with the tenancy context of the requester (i.e., the JEE application). A container client may call a container daemon 725, such as a Docker daemon. Then, the container daemon may download and launch the application image 740 of the containerized application requested from the JEE application. The application image 740 may include a base OS (eg Ubuntu) along with a layered file system including application binaries and necessary libraries and components. The application image is self-contained and portable, allowing the application to run without depending on the host. Additionally, containerized applications can run as separate instances. Containerized applications run on the same OS but in isolation, meaning that two or more tenants can run different instances of the same application in separate containers.

According to one embodiment of the present invention, the container storage 810 may be filled with a plurality of application images 815 . These application images may be pre-populated with the application image library, or may be stored in the application image library after the container process of FIG. 8 creates the application image.

According to an embodiment of the present invention, when a container is created (by a container daemon), an application image is loaded into the container to execute the containerized application 730, so that the application can be executed without depending on the host.

According to one embodiment of the invention, containerized applications 730 may communicate (I/O) with a tenant's virtual tenant filesystem 735 (which is based on a tenant context, e.g., a partition of tenant 2 that may in turn communicate with OS storage 736).

According to one embodiment of the present invention, a containerized application running on behalf of a tenant, eg tenant 2, can access the tenant's database 608 with the necessary credentials.

According to one embodiment of the present invention, the MT application can obtain a process exitValue status code (eg, Java process object exitValue() method) to confirm whether the program has been successfully executed. MT applications can also inspect whether the process execution was successful by looking for the redirected stdout and stderr files under the outputs and errors subfolders. Results updated in the tenant database can be accessed directly from the database by the MT application running in the partition once execution of the tenant-unaware containerized application is complete.

According to one embodiment of the present invention, the MT application may also delete the process working directory and its subfolders to organize output files such as wallets and db files.

9 is a flow diagram of an exemplary method for creating an environment and resources for tenant scoped execution of a tenant unaware process, in accordance with one embodiment of the present invention. At step 910, a process working directory may be created under a tenant filesystem (eg, a virtual tenant filesystem). At step 920, subdirectories under the process working directory may be created for the input, output, error, and database folders. At step 930, the input folder may be set to data files. At step 940, a database folder may be set up with tenant database configuration files and certificates (eg, wallets). At step 950, the environment may be terminated such that a tenant unaware application (eg, OS application/process) is executed based on the tenant context.

10 is a flow diagram of an exemplary method for creating and configuring a process builder for launching a containerized application, according to one embodiment of the present invention. At step 1010, a Process Builder instance (eg, a native ProcessBuilder API) may be created. At step 1020, a process environment may be configured (eg, a tenant context). At step 1030, a process working directory may be configured. At step 1040, the method may construct an executable command line to launch the containerized application. At step 1050, streams from the containerized application, such as input streams, output streams, and error streams, may be redirected to the input, output, and errors subdirectories of the process working directory.

11 is a flow diagram of an exemplary method for multi-tenant execution of a tenant unaware OS application from an MT middleware application (eg, a JEE application), according to an embodiment of the present invention. As a prerequisite of this exemplary method, an OS application (ie, an OS application to be called from an MT application server environment) may be packaged as a containerized application (eg, a containerized application image). At step 1110, as identified by the flow diagram of FIG. 9, a process environment and resources for tenant scoped execution may be created. At step 1120, as identified by the flow diagram of FIG. 10, a process builder (eg, a Java ProcessBuilder API instance) may be created and configured. At step 1130, the method may invoke the containerized OS application process using a process builder start method. This step starts the container process by creating a configured tenant-specific execution environment. Containerized applications can run with tenant-specific execution environments and resources through runtime isolation from other containers & OS processes enforced by the container runtime. At step 1140, the method may wait until containerized application process execution is complete. In step 1150, it retrieves the process output from the tenant database as well as the stdout file in the process working directory, performs any necessary post-processing, and updates the tenant specific database with the results. At step 1160, the method may delete and clean up the process working directory and its contents.

12 is a flow diagram of an exemplary method for supporting tenant scoped execution of tenant-unaware processes invoked from multitenant middleware applications. At step 1210, the method may include one or more computers comprising an application server environment running, a plurality of partitions each partition providing administrative and runtime subdivisions of a domain, and a plurality of tenant-aware programs, each of the plurality of tenant-aware programs associated with one of the plurality of partitions.

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

At step 1230, the method may invoke a tenant-unaware process from a calling partition of the plurality of partitions, the calling partition being associated with one calling tenant of the plurality of tenants.

At step 1240, the method may collect tenancy information about the calling tenant.

At step 1250, the method may scope (confine) the execution of the tenant-unaware process to the calling tenant based on the collected tenancy information, and scoping the execution allows for isolating the execution of the tenant-unaware process scoped to the calling tenant from other tenants in the multi-tenant middleware environment.

The invention may conveniently be implemented using one or more conventional general purpose or special purpose digital computers, computing devices, machines or microprocessors that include one or more processors, memory and/or computer readable storage media programmed in accordance with the teachings of this disclosure. Appropriate software coding can be readily prepared by a skilled programmer based on the teachings of this disclosure, as will be apparent to those skilled in the software arts.

In some embodiments, the present invention includes a computer program product that is a non-transitory storage medium or computer readable medium (media) having stored thereon instructions that can be used to program a computer to perform any of the processes of the present invention. Storage media may include, but are not limited to, floppy disks, optical disks, DVDs, CD-ROMs, disks of any type, including microdrives, and magneto-optical disks, ROM, RAM, EPROM, EEPROM, DRAM, VRAM, flash memory devices, magnetic or optical cards, nanosystems (including molecular memory ICs), or any type of media or device suitable for storing instructions and/or data.

The foregoing description of the present invention has been presented for purposes of illustration and description. The invention is not intended to be exhaustive or limited to the precise forms disclosed. Many modifications and variations will be apparent to those skilled in the art. Modifications and variations include any relevant combination of the disclosed features. The embodiments were selected and described in order to best explain the principles and practical applications of the present invention, thereby enabling those skilled in the art to understand the present invention in its various embodiments and also to understand the present invention through various modifications suitable for the particular intended use. The scope of the invention is intended to be defined by the following claims and equivalents thereof.

Claims (44)

A method for supporting tenant scoped execution of a tenant-unaware process invoked from a multitenant middleware application, the method comprising:
providing a plurality of partitions and a plurality of tenant-aware programs on one or more computers comprising an application server environment on which they are executed;
each of the partitions provides a management and runtime subdivision of the domain; and
each of said plurality of tenant-aware programs is associated with a partition of a plurality of partitions;
associating each of the plurality of partitions and each of the plurality of tenant-aware programs with a tenant of the plurality of tenants for use by the tenant;
invoking a tenant-unaware process from a calling partition of the plurality of partitions, the calling partition being associated with a calling tenant of the plurality of tenants;
collecting tenancy information about the calling tenant;
based on the collected tenancy information about the calling tenant, creating a tenant-specific virtual filesystem; and
scoping the execution of the tenant-unrecognized process to a calling tenant by setting a process execution environment and resources based on the collected tenancy information, wherein scoping the execution of the tenant-unrecognized process to the calling tenant,
redirecting the stream of the tenant-unaware process to a tenant-specific virtual filesystem, the stream of the tenant-unaware process comprising at least one of an input stream, an output stream, and an error stream;
Wherein scoping the execution allows separation of execution of the tenant-unaware process scoped to the calling tenant from other tenants in a multi-tenant middleware environment. According to claim 1,
wherein the multi-tenant middleware application is associated with a calling partition of the plurality of partitions, and the multi-tenant middleware application conveys tenancy information in connection with invoking a tenant-unaware process. According to claim 1,
Further comprising creating a process working directory under the created tenant-specific virtual file system, wherein the process working directory includes an input subdirectory, an output subdirectory, a database subdirectory and an error subdirectory. According to claim 3,
setting an input subdirectory with at least one data file; and
The method of claim 1 further comprising establishing a database subdirectory using a wallet, wherein the wallet contains configuration files and credentials associated with a calling tenant. According to claim 1,
after completion of the tenant-unaware process, accessing, by the tenant-unaware process, a tenant-specific database, the access being granted through a wallet; and
After completion of the tenant-unaware process and access to the tenant-specific database by the tenant-unaware process, cleaning up the tenant-specific virtual file system, wherein cleaning up the tenant-specific virtual file system comprises deleting a process working directory. According to claim 3,
The stream of the tenant-unaware process,
and redirecting to an input subdirectory, an output subdirectory, and an error subdirectory of the process working directory, respectively. According to claim 1,
A tenant-unaware process called from a calling partition of the plurality of partitions is part of a composite application, the composite application further comprising a tenant-aware application running in the context of a calling partition of the plurality of partitions. A system for supporting tenant scoped execution of tenant-unaware processes invoked from multitenant middleware applications, comprising:
one or more computers comprising an application server environment running with a plurality of partitions and a plurality of tenant-aware programs;
each of the partitions provides administrative and runtime granularity of the domain; and
each of the plurality of tenant-aware programs is associated with one of a plurality of partitions;
each of the plurality of partitions and each of the plurality of tenant-aware programs is associated with a tenant of the plurality of tenants for use by the tenant; and
a calling partition of the plurality of partitions invokes a tenant-unaware process, the calling partition being associated with a calling tenant of the plurality of tenants;
tenancy information about the calling tenant is collected;
A tenant-specific virtual file system is created based on the collected tenancy information about the calling tenant;
Based on the collected tenancy information, setting the process execution environment and resources so that the execution of the tenant-unrecognized process is scoped to the calling tenant, and scoping the execution of the tenant-unrecognized process to the calling tenant,
redirecting the stream of the tenant-unrecognized process to a tenant-specific virtual filesystem, wherein the stream of the tenant-unrecognized process includes at least one of an input stream, an output stream, and an error stream; and
scoping the execution of the tenant-unaware process allows isolation of the execution of the tenant-unaware process scoped to the calling tenant from other tenants in a multi-tenant middleware environment. According to claim 8,
the multi-tenant middleware application is associated with a calling partition of a plurality of partitions; and
Wherein the multi-tenant middleware application conveys tenancy information in connection with invoking a tenant-unaware process. According to claim 8,
A process working directory is created under the created tenant-specific virtual file system, and the process working directory includes an input subdirectory, an output subdirectory, a database subdirectory, and an error subdirectory. According to claim 10,
the input subdirectory is established using at least one data file, and
wherein the database subdirectory is established using a wallet, wherein the wallet contains configuration files and certificates associated with a calling tenant. According to claim 11,
After completion of the tenant-unaware process, the tenant-unaware process accesses a tenant specific database using a wallet; and
wherein the tenant-specific virtual filesystem is cleaned up after completion of a tenant-unaware process, wherein cleaning up the tenant-specific virtual filesystem comprises deleting a process working directory. According to claim 10,
The stream of the tenant-unaware process,
Redirected to the input subdirectory, the output subdirectory and the error subdirectory of the process working directory, respectively. According to claim 8,
A tenant-unaware process called from a calling partition of the plurality of partitions is part of a composite application, the composite application further comprising a tenant-aware application running in the context of a calling partition of the plurality of partitions. A non-transitory computer-readable storage medium supporting tenant-scoped execution of a tenant-unaware process invoked from a multi-tenant middleware application, containing stored instructions that when read and executed by one or more computers cause one or more computers to perform steps, the steps comprising:
providing a plurality of partitions and a plurality of tenant-aware programs on one or more computers comprising an application server environment on which they are executed;
each of the partitions provides administrative and runtime granularity of the domain; and
each of said plurality of tenant-aware programs is associated with a partition of a plurality of partitions;
associating each of the plurality of partitions and each of the plurality of tenant-aware programs with a tenant of the plurality of tenants for use by the tenant;
invoking a tenant-unaware process from a calling partition of the plurality of partitions, the calling partition being associated with a calling tenant of the plurality of tenants;
collecting tenancy information about the calling tenant;
based on the collected tenancy information about the calling tenant, creating a tenant-specific virtual filesystem; and
scoping the execution of the tenant-unrecognized process to a calling tenant by setting a process execution environment and resources based on the collected tenancy information, and scoping the execution of the tenant-unrecognized process to the calling tenant,
redirecting a stream of the tenant-unrecognized process to a tenant-specific virtual file system, wherein the stream of the tenant-unrecognized process includes at least one of an input stream, an output stream, and an error stream;
Wherein scoping the execution allows separation of execution of the tenant-unaware process scoped to the calling tenant from other tenants in a multi-tenant middleware environment. According to claim 15,
The multi-tenant middleware application is associated with a calling partition of the plurality of partitions, and the multi-tenant middleware application carries tenancy information in connection with invoking a tenant-unaware process. According to claim 15,
These steps are
Further comprising creating a process working directory under the created tenant-specific virtual file system, wherein the process working directory includes an input subdirectory, an output subdirectory, a database subdirectory, and an error subdirectory. According to claim 17,
These steps are
setting an input subdirectory with at least one data file; and
and setting up a database subdirectory using a wallet, wherein the wallet contains configuration files and certificates associated with a calling tenant. According to claim 15,
These steps are
after completion of the tenant-unaware process, accessing, by the tenant-unaware process, a tenant-specific database, the access being granted through a wallet; and
2. The non-transitory computer-readable storage medium of claim 1 , further comprising cleaning up the tenant-specific virtual file system after completion of the tenant-unaware process and access of the tenant-specific database by the tenant-unaware process, wherein cleaning up the tenant-specific virtual file system comprises deleting a process working directory. According to claim 17,
The stream of the tenant-unrecognized process is redirected to an input subdirectory, an output subdirectory, and an error subdirectory of the process working directory, respectively. According to claim 15,
The tenant-unaware process called from the calling partition of the plurality of partitions is part of a composite application, and the composite application further comprises a tenant-aware application running in the context of the calling partition of the plurality of partitions. A method for supporting tenant scoped execution of tenant-unaware processes invoked from multitenant middleware applications, comprising:
providing a plurality of partitions and a plurality of tenant-aware programs on one or more computers comprising an application server environment on which they are executed;
each of the partitions provides administrative and runtime granularity of the domain; and
each of said plurality of tenant-aware programs is associated with a partition of a plurality of partitions;
associating each of the plurality of partitions and each of the plurality of tenant-aware programs with a tenant of the plurality of tenants for use by the tenant;
invoking a tenant-unaware process from a calling partition of the plurality of partitions, the calling partition being associated with a calling tenant of the plurality of tenants;
collecting tenancy information about the calling tenant; and
scoping the execution of the tenant-unrecognized process to a calling tenant by setting a process execution environment and resources based on the collected tenancy information, wherein scoping the execution of the tenant-unrecognized process to the calling tenant,
launching the tenant-unaware process as a containerized process, the containerized process including libraries and executables associated with the tenant-unaware process;
The method of claim 1 , wherein the containerized process is a standalone process capable of separating execution of a tenant-unaware process for the calling tenant from other tenants in a multi-tenant middleware environment. The method of claim 22,
and generating a tenant-specific virtual filesystem based on the collected tenancy information about the calling tenant prior to the scoping step, wherein the tenant-specific virtual filesystem includes an input subdirectory, an output subdirectory, a database subdirectory, and an error subdirectory. The method of claim 22,
Further comprising: accessing a tenant-specific database by a tenant-unrecognized process after completion of the tenant-unrecognized process;
Wherein the tenant-unaware process accesses a tenant-specific database using a wallet. The method of claim 22,
Launching the tenant-unaware process as a containerized process comprises:
accessing an application image by a container daemon, the application image being associated with the tenant-unaware process;
creating a container associated with the tenant; and
and launching the application image in a container. According to claim 25,
Wherein the accessed application image is stored in an application image storage. According to claim 25,
The method of claim 1 , wherein the stream of the application image is redirected to a tenant-specific virtual file system, and the stream of the application image includes at least one of an input stream, an output stream, and an error stream. The method of claim 22,
The tenant-unaware process called from the calling partition of the plurality of partitions is part of a composite application, the composite application further comprising a tenant-aware application running in the context of a calling partition of the plurality of partitions. A system for supporting tenant scoped execution of tenant-unaware processes invoked from multitenant middleware applications, comprising:
one or more computers comprising an application server environment running with a plurality of partitions and a plurality of tenant-aware programs;
each of the partitions provides administrative and runtime granularity of the domain; and
each of said plurality of tenant-aware programs is associated with one of a plurality of partitions;
each of the plurality of partitions and each of the plurality of tenant-aware programs is associated with a tenant of the plurality of tenants for use by the tenant; and
a calling partition of the plurality of partitions invokes a tenant-unaware process, and the calling partition is associated with a calling tenant of the plurality of tenants;
tenancy information about the calling tenant is collected;
Scoping 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, and scoping the execution of the tenant-unrecognized process to the calling tenant,
launching the tenant-unaware process as a containerized process, the containerized process including libraries and executables associated with the tenant-unaware process;
The system of claim 1 , wherein the containerized process is a standalone process capable of separating execution of a tenant-unaware process for the calling tenant from other tenants in a multi-tenant middleware environment. According to claim 29,
Based on the collected tenancy information about the calling tenant, a tenant-specific virtual filesystem is created, the tenant-specific virtual filesystem comprising an input subdirectory, an output subdirectory, a database subdirectory and an error subdirectory. According to claim 29,
After completion of the tenant-unaware process, the tenant-unaware process accesses a tenant specific database using a wallet. According to claim 29,
Launching the tenant-unaware process as a containerized process:
accessing an application image from a container daemon, the application image being associated with the tenant-unaware process;
creating a container associated with the tenant; and
and launching the application image in a container. 33. The method of claim 32,
The system characterized in that the accessed application image is stored in an application image storage. 33. The method of claim 32,
The system of claim 1 , wherein the stream of the application image is redirected to a tenant-specific virtual file system, and the stream of the application image includes at least one of an input stream, an output stream, and an error stream. According to claim 29,
wherein the tenant-unaware process called from the calling partition of the plurality of partitions is part of a composite application, the composite application further comprising a tenant-aware application running in the context of a calling partition of the plurality of partitions. A non-transitory computer-readable storage medium supporting tenant-scoped execution of a tenant-unaware process invoked from a multi-tenant middleware application, containing stored instructions that when read and executed by one or more computers cause one or more computers to perform steps, the steps comprising:
providing a plurality of partitions and a plurality of tenant-aware programs on one or more computers comprising an application server environment on which they are executed;
each of the partitions provides administrative and runtime granularity of the domain; and
each of said plurality of tenant-aware programs is associated with a partition of a plurality of partitions;
associating each of the plurality of partitions and each of the plurality of tenant-aware programs with a tenant of the plurality of tenants for use by the tenant;
invoking a tenant-unaware process from a calling partition of the plurality of partitions, the calling partition being associated with a calling tenant of the plurality of tenants;
collecting tenancy information about the calling tenant; and
scoping the execution of the tenant-unrecognized process to a calling tenant by setting a process execution environment and resources based on the collected tenancy information, wherein scoping the execution of the tenant-unrecognized process to the calling tenant,
launching the tenant-unaware process as a containerized process, the containerized process including libraries and executables associated with the tenant-unaware process;
The containerized process is a non-transitory computer-readable storage medium, characterized in that it is a stand-alone process capable of separating execution of a tenant-unaware process for the calling tenant from other tenants in a multi-tenant middleware environment. 37. The method of claim 36,
These steps are
generating a tenant-specific virtual file system based on the collected tenancy information about the calling tenant, wherein the tenant-specific virtual file system includes an input subdirectory, an output subdirectory, a database subdirectory, and an error subdirectory. 37. The method of claim 36,
These steps are
Further comprising: accessing a tenant specific database by a tenant-unrecognized process after completion of the tenant-unrecognized process;
wherein the tenant-unaware process accesses a tenant-specific database using a wallet. 37. The method of claim 36,
Launching the tenant-unaware process as a containerized process comprises:
accessing an application image by a container daemon, the application image being associated with the tenant-unaware process;
creating a container associated with the tenant; and
Including; launching the application image in a container,
The accessed application image is stored in an application image storage. The method of claim 39,
The stream of the application image is redirected to a tenant-specific virtual file system, and the stream of the application image includes at least one of an input stream, an output stream, and an error stream. 37. The method of claim 36,
The tenant-unaware process called from the calling partition of the plurality of partitions is part of a composite application, the composite application further comprising a tenant-aware application running in the context of the calling partition of the plurality of partitions. A computer program comprising program instructions stored on a non-transitory computer readable storage medium that, when executed by one or more computer systems, cause the one or more computer systems to perform the method of any one of claims 1-7 and 22-28. A non-transitory computer readable storage medium having the computer program of claim 42 stored thereon. A system configured to perform the method of any one of claims 1 to 7 and the method of any one of claims 22 to 28.