CN115658165A

CN115658165A - Method and device for starting tenant plug-in and realizing in-process communication

Info

Publication number: CN115658165A
Application number: CN202211182309.8A
Authority: CN
Inventors: 叶永杰; 肖涵; 田阳; 王发康; 石建伟; 揣立武
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2022-09-27
Filing date: 2022-09-27
Publication date: 2023-01-31

Abstract

Embodiments of the present specification provide a method and apparatus for launching tenant plug-ins and implementing in-process communication. In the method for starting the tenant plug-in, a tenant plug-in starting request from a client device is received, wherein the tenant plug-in starting request comprises a programming language virtual machine type used by the tenant plug-in and storage path information of a dynamic link library corresponding to the tenant plug-in; acquiring a dynamic link library of the tenant plug-in according to the storage path information of the dynamic link library in the tenant plug-in starting request, wherein the dynamic link library comprises a tenant plug-in program instance and a programming language virtual machine; creating a resource control group for the tenant plug-in; loading the acquired dynamic link library to the current system process in an isolated resource environment limited by the resource control group so as to start a corresponding programming language virtual machine and realize instantiation and initialization of the tenant plug-in; and responding to the completion of initialization of the tenant plug-in, and sending a response message for indicating successful start of the tenant plug-in to the client device.

Description

Method and device for starting tenant plug-in and realizing in-process communication

Technical Field

The embodiments of the present specification relate generally to the field of computer technology, and in particular, to a method and apparatus for starting a tenant plug-in and implementing intra-process communication.

Background

With the rapid development of internet technology, in the background of the cloud native (clouduntive) era, it is gradually difficult for an application instance developed based on a single programming language virtual machine to meet the requirements of a multi-tenant mode. Cloud-native is a method for constructing and operating an application program, and is a set of technical system and methodology. Cloud-native technology enables organizations to build and run scalable applications in new dynamic environments (such as public, private, and hybrid clouds). Containers, service grids, microservices, immutable infrastructure and Application Programming Interfaces (API) are examples of such methods.

One of the prior art adopts a method of locating data of different tenants (tenants) in the same programming language virtual machine in a single instance mode. Since the user can directly access the data of other tenants through the code symbol, the isolation and the security of the data material are difficult to ensure. Furthermore, limited by the limitation of the programming language version control system, only one version can exist in one third party dependency (external dependency), and when different tenants depend on different versions of the third party dependency, the latest version can be forced to be used, and the version-dependent conflict problem can cause the code compilation failure of the tenant using the old version. One of the prior art also adopts a method of building based on a multi-process model, that is, a programming language virtual machine of each tenant runs in a different system process. But because the communication between tenants can only adopt a cross-process communication scheme, the performance loss is larger.

Disclosure of Invention

In view of the above, the present specification embodiments provide a method and apparatus for launching tenant plug-ins and implementing in-process communication. By utilizing the method and the device, the safe starting of multiple tenants in the same system process can be realized; and the high performance of in-process communication can be achieved on the premise that the resource isolation is achieved by the multiple tenant plug-ins.

According to an aspect of an embodiment of the present specification, there is provided a method for launching a tenant plug-in, including: receiving a tenant plug-in starting request from client equipment, wherein the tenant plug-in starting request comprises a programming language virtual machine type used by the tenant plug-in and storage path information of a dynamic link library corresponding to the tenant plug-in; acquiring a dynamic link library of the tenant plug-in to be started according to the storage path information of the dynamic link library in the tenant plug-in starting request, wherein the dynamic link library comprises a tenant plug-in program instance and a programming language virtual machine; creating a resource control group for the tenant plug-in; loading the obtained dynamic link library to the current system process in an isolated resource environment limited by the resource control group so as to start a corresponding programming language virtual machine and realize instantiation and initialization of the tenant plug-in; and responding to the initialization completion of the tenant plug-in, and sending a response message for indicating the successful start of the tenant plug-in to the client device.

According to another aspect of embodiments of the present specification, there is provided a method of implementing intra-process communication between tenant plug-ins, comprising: receiving a first in-process communication request of a first tenant plug-in, wherein the first in-process communication request comprises a tenant plug-in identifier of a second tenant plug-in serving as a communication opposite end and communication parameter information of in-process communication, and the communication parameter information comprises a function calling method and a function calling parameter; according to the tenant plug-in identification of the second tenant plug-in, the second tenant plug-in is positioned in a tenant plug-in set started in the same system process; sending a second in-process communication request to the located second tenant plug-in, wherein the second in-process communication request comprises communication parameter information of in-process communication, and the second tenant plug-in calls a target function according to the function call method and the function call parameter to generate a response message of the in-process communication; receiving a response message returned by the second tenant plug-in; and sending the response message to the first tenant plug-in, wherein when each tenant plug-in a tenant plug-in set started in the same system process is started, each dynamic link library is loaded to the same system process in an isolated resource environment limited by each resource control group so as to start each programming language virtual machine and realize instantiation and initialization of each tenant plug-in, and each started tenant plug-in has a tenant plug-in identifier.

According to another aspect of embodiments of the present specification, there is provided an apparatus for launching a tenant plug-in, including: the client device comprises a request receiving unit, a processing unit and a processing unit, wherein the request receiving unit is used for receiving a tenant plug-in starting request from client equipment, and the tenant plug-in starting request comprises a programming language virtual machine type used by a tenant plug-in and storage path information of a dynamic link library corresponding to the tenant plug-in; the library acquisition unit is used for acquiring a dynamic link library of the tenant plug-in to be started according to the storage path information of the dynamic link library in the tenant plug-in starting request, wherein the dynamic link library comprises a tenant plug-in program instance and a programming language virtual machine; the resource control group creating unit is used for creating a resource control group for the tenant plug-in; the library loading unit is used for loading the acquired dynamic link library to the current system process in the isolated resource environment limited by the resource control group so as to start a corresponding programming language virtual machine and realize instantiation and initialization of the tenant plug-in; and the response sending unit is used for responding to the completion of initialization of the tenant plug-in and sending a response message for indicating the successful starting of the tenant plug-in to the client equipment.

According to yet another aspect of embodiments herein, there is provided an apparatus for enabling intra-process communication between tenant plug-ins, the apparatus comprising: the communication request receiving unit is used for receiving a first in-process communication request of a first tenant plug-in, wherein the first in-process communication request comprises a tenant plug-in identifier of a second tenant plug-in serving as a communication opposite end and communication parameter information of in-process communication, and the communication parameter information comprises a function calling method and a function calling parameter; the tenant plug-in positioning unit is used for positioning the second tenant plug-in a tenant plug-in set started in the same system process according to the tenant plug-in identification of the second tenant plug-in; a communication request sending unit, configured to send a second in-process communication request to the located second tenant plugin, where the second in-process communication request includes communication parameter information of the in-process communication, and the second tenant plugin calls a target function according to the function call method and the function call parameter to generate a response message of the in-process communication; the response message receiving unit is used for receiving a response message returned by the second tenant plug-in; and a response message sending unit, configured to send the response message to the first tenant plug-in, where, when each tenant plug-in a tenant plug-in set started in the same system process is started, each dynamic link library is loaded to the same system process in an isolated resource environment limited by each resource control group, so as to start each programming language virtual machine and implement instantiation and initialization of each tenant plug-in, and each started tenant plug-in has a tenant plug-in identifier.

According to another aspect of embodiments of the present specification, there is provided a tenant plug-in management device including: the device for starting the tenant plug-in is described above; and means for implementing intra-process communication between tenant plugins as described above.

According to another aspect of the embodiments of the present specification, there is provided an apparatus for launching a tenant plug-in, including: at least one processor, and a memory coupled with the at least one processor, and a computer program stored on the memory, the at least one processor executing the computer program to implement the method for launching a tenant plug-in as described above.

According to another aspect of the embodiments of the present specification, there is provided an apparatus for implementing intra-process communication between tenant plug-ins, including: at least one processor, and a memory coupled with the at least one processor, and a computer program stored on the memory, the at least one processor executing the computer program to implement the method for implementing in-process communication between tenant plug-ins as described above.

According to another aspect of embodiments of the present specification, there is provided a computer readable storage medium storing a computer program which, when executed by a processor, implements a method for launching a tenant plug-in and/or a method for implementing intra-process communication between tenant plug-ins as described above.

According to another aspect of embodiments of the present specification, there is provided a computer program product comprising a computer program which is executed by a processor to implement the method for launching tenant plug-ins and/or the method for implementing intra-process communication between tenant plug-ins as described above.

Drawings

A further understanding of the nature and advantages of the present disclosure may be realized by reference to the following drawings. In the drawings, similar components or features may have the same reference numerals.

FIG. 1 illustrates an exemplary architecture of a method and apparatus for launching tenant plug-ins, a method and apparatus for implementing intra-process communication between tenant plug-ins, according to embodiments of the present description.

Figure 2 illustrates a flow diagram of one example of a method for launching a tenant plug-in accordance with embodiments of the present specification.

Fig. 3a and 3b are schematic diagrams respectively illustrating an example of a tenant plug-in initiation request according to an embodiment of the present specification.

FIG. 4 illustrates a flow diagram of one example of a process for loading a dynamically linked library according to embodiments of the present specification.

Figure 5 illustrates a flow diagram of yet another example of a method for launching a tenant plug-in accordance with embodiments of the present specification.

FIG. 6 illustrates a flow diagram of one example of a method for implementing intra-process communication between tenant plug-ins in accordance with embodiments of the present specification.

Fig. 7a and 7b are diagrams respectively illustrating an example of a first in-process communication request according to an embodiment of the present specification.

Fig. 8a and 8b are diagrams each showing an example of a response message according to an embodiment of the present specification.

Figure 9 illustrates an interaction timing diagram of one example of a method for implementing intra-process communication between tenant plug-ins in accordance with embodiments of the present specification.

Figure 10 illustrates a block diagram of one example of an apparatus for launching tenant plug-ins in accordance with embodiments of the present description.

FIG. 11 illustrates a block diagram of one example of a library load unit in an apparatus for launching tenant plug-ins in accordance with embodiments of the present description.

Figure 12 illustrates a block diagram of yet another example of an apparatus for launching tenant plug-ins in accordance with embodiments of the present description.

Figure 13 illustrates a block diagram of one example of an apparatus for implementing intra-process communication between tenant plug-ins in accordance with an embodiment of the present specification.

Figure 14 illustrates a block diagram of one example of a tenant plug-in management device in accordance with embodiments of the present description;

figure 15 illustrates a block diagram of one example of an apparatus for launching a tenant plug-in according to embodiments of the present description.

Figure 16 illustrates a block diagram of one example of an apparatus for implementing intra-process communication between tenant plug-ins in accordance with embodiments of the present description.

Detailed Description

The subject matter described herein will be discussed with reference to example embodiments. It should be understood that these embodiments are discussed only to enable those skilled in the art to better understand and thereby implement the subject matter described herein, and are not intended to limit the scope, applicability, or examples set forth in the claims. Changes may be made in the function and arrangement of elements discussed without departing from the scope of the embodiments of the disclosure. Various examples may omit, substitute, or add various procedures or components as needed. In addition, features described with respect to some examples may also be combined in other examples.

As used herein, the term "include" and its variants mean open-ended terms in the sense of "including, but not limited to. The term "based on" means "based at least in part on". The terms "one embodiment" and "an embodiment" mean "at least one embodiment". The term "another embodiment" means "at least one other embodiment". The terms "first," "second," and the like may refer to different or the same objects. Other definitions, whether explicit or implicit, may be included below. The definition of a term is consistent throughout the specification unless the context clearly dictates otherwise.

In this specification, the term "tenant" may be used to denote a user or a group of users in the context of a cloud service (cloud serving). "multi-tenant" refers to a software architecture that can provide services for multiple different user groups simultaneously in a single software instance and provide a certain data isolation.

In this specification, the term "plug-in" may refer to a program written in an application program interface conforming to a certain specification, and is positioned to develop a program that implements a function that an application software platform does not have. The plug-in and the host program can be connected through an interface, and can be deleted, inserted and modified at any time just like a hardware plug-in card, so that the structure is flexible, the modification is easy, and the software is convenient to upgrade and maintain. The term "tenant plug-in" can be regarded as an independent program instance and can also be called as "tenant plug-in instance", which indicates that the cloud service system can provide services which can be dynamically loaded or unloaded to tenants, and have pluggable functions like plug-ins. A "tenant plug-in" may run tenant-specified code logic (e.g., tenant's programs) and the resources it uses may be limited by the cloud service system.

In this specification, the term "Dynamic-Link Library" may refer to a binary program file that allows programs to share code and other resources necessary to perform a particular task, and Library files that allow a host program to be dynamically linked and loaded when needed, such as into an executable file at runtime. In one example, the suffix name of the dynamically linked library on the Windows platform is ". Dll". In one example, the suffix name on the Linux platform is ". So". In one example, the suffix name on the Mac platform is ". Dylib".

In this specification, the term "programming language virtual machine" may refer to a virtual machine dedicated to running a certain language code. "virtual machine" refers to a computer software system with a completely isolated environment, simulated by software. In one example, the programming language virtual machine may include a JVM for running the Java language. In one example, a programming language virtual machine may include a Go Runtime for running the Go language. In one example, a programming language virtual machine may include WebAssembly running in a modern web browser.

The method and the device for starting the tenant plug-in and the method and the device for realizing intra-process communication between the tenant plug-ins according to the embodiment of the specification are described in detail in the following with the accompanying drawings.

Fig. 1 illustrates an exemplary architecture 100 of a method and apparatus for launching tenant plug-ins, a method and apparatus for implementing intra-process communication between tenant plug-ins, according to embodiments of the present description.

In fig. 1, a network 110 is applied to interconnect between a terminal device 120 and a console (console) 130.

Network 110 may be any type of network capable of interconnecting network entities. The network 110 may be a single network or a combination of networks. In terms of coverage, the network 110 may be a Local Area Network (LAN), a Wide Area Network (WAN), or the like. In terms of a carrier medium, the network 110 may be a wired network, a wireless network, or the like. In terms of data switching technology, the network 110 may be a circuit switched network, a packet switched network, or the like.

Terminal device 120 may be any type of electronic computing device capable of connecting to network 110, accessing a server or website on network 110, processing data or signals, and so forth. For example, the terminal device 120 may be a desktop computer, a laptop computer, a tablet computer, a smart phone, and the like. Although only one terminal device is shown in fig. 1, it should be understood that a different number of terminal devices may be connected to network 110.

In one embodiment, terminal device 120 may be used by a user. Terminal device 120 may include an application client (e.g., application client 121) that may provide various services to a user. In one example, the application client may be a program development class application or the like. In some cases, the application client 121 may interact with the console 130. For example, the application client 121 can transmit a message input by the user (e.g., an instruction to launch a tenant plug-in) to the console 130 and receive a response associated with the message from the console 130.

The console 130 may be connected with a cloud server 140. Among other things, the cloud server 140 may provide various cloud services for the application client 121. The cloud server 140 may include a system process 141 and a plug-in management base 142 as a user process. The plug-in management base 142 can be a resident process, and provides pluggable services (e.g., running tenant programs 143, 144, 145, respectively) for tenant plug-ins (e.g., tenant plug-in 1, tenant plug-in 2, tenant plug-in 3) together with the system process 141. Typically, the plug-in management base 142 does not itself run any tenant specific logic, configured to provide support for the start-up of tenant plug-ins, resource management, intra-process communication, etc.

It should be understood that all of the network entities shown in fig. 1 are exemplary, and that any other network entity may be involved in the architecture 100 depending on the particular application requirements.

Figure 2 illustrates a flow diagram of a method 200 for launching a tenant plug-in accordance with embodiments of the present description.

As shown in fig. 2, at 210, a tenant plug-in initiation request is received from a client device.

In this embodiment, a tenant plug-in initiation request may be received from a client device. The tenant plug-in starting request may include a type of a programming language virtual machine used by the tenant plug-in and storage path information of a dynamic link library corresponding to the tenant plug-in. In one example, the client device described above may be a client used by a tenant. The tenant plug-in start request can be directly from a client used by the tenant.

Optionally, the tenant plug-in start request may include a single integrated tenant plug-in start request obtained by integrating (for example, packaging a plurality of requests) at least two tenant plug-in start requests through a console responsible for managing tenants. The at least two tenant plug-in initiation requests may be from clients used by different tenants. Thereby saving communication overhead.

In one example, the tenant plug-in initiation request can be as shown in figure 3 a. Wherein type can be used to represent the type of programming language virtual machine used by the tenant plug-in. Such as the Java language or the Go language. The progPath can be used to represent a storage path of the dynamically linked library corresponding to the tenant plug-in.

Optionally, in an example, the tenant plug-in starting request may further include resource restriction information of the tenant plug-in. The resource restriction information may include, for example, a cpu maximum usage amount, a memory maximum usage amount, and the like.

Optionally, in an example, the tenant plug-in start request may further include a tenant plug-in identification of the tenant plug-in. The tenant plug-in identification can be used for identifying different tenant plug-ins. The created tenant plug-in can also be associated with the tenant plug-in identification of the tenant plug-in to distinguish multiple tenant plug-ins running within the same system process.

In one example, the tenant plug-in initiation request can be as shown in figure 3 b. Wherein, the cpu can be used to represent the maximum cpu usage of the tenant plug-in. mem may be used to represent the maximum memory usage of the tenant plug-in. tenntid can be used to represent a unique identification of a tenant plug-in. the specific meanings of type and progPath can be referred to in the foregoing.

Optionally, in an example, the tenant plug-in initiation request may further include a custom configuration item (for example, may be represented by config), which may be configured to be any corresponding character string according to an actual operation requirement of the user plug-in. For example, some network programs may specify ports to listen to through the configuration items described above, some database programs may specify operating parameters through the configuration items described above, and so on. Thereby the flexibility of the tenant plug-in can be enhanced.

Returning to fig. 2, at 220, the dynamic link library of the tenant plug-in to be started is obtained according to the storage path information of the dynamic link library in the tenant plug-in start request.

In this embodiment, the stored path information of the dynamic link library may be used to indicate the path that is deposited by the dynamic link library and can be acquired by an execution subject (e.g., the plug-in management base 142 shown in fig. 1) of the method for starting the tenant plug-in. The dynamically linked library can include tenant plug-in instances and programming language virtual machines. In one example, a tenant plug-in program instance may be a program instance to be run that is prepared in advance by the tenant. The dynamic link library corresponding to the tenant plug-in can be generated on the basis of a program instance to be run and a programming language virtual machine package compilation required by the program instance to be run, which are prepared in advance by the tenant. The program instance may refer to a program written by a user according to needs.

At 230, a resource control group is created for the tenant plug-in.

In this embodiment, a resource control group can be created for a tenant plug-in. The resource control group is used for realizing the limitation and isolation of resources based on the system process. For example, a corresponding resource control group may be created for each tenant plug-in according to a default set resource quota. In one example, the resource control group may be a Cgroups (control groups) of the Linux operating system, which is used to limit, control and separate resources (e.g., CPU, memory, disk input and output, etc.) of a process group. In another example, similarly, the resource control group may be a Job object (Job Objects) under the windows operating system that allows the process group to be managed as a unit. Job objects are nameable, secure, shareable objects to control the properties of the processes associated therewith.

Optionally, a resource control group may be created for the corresponding tenant plug-in according to the resource restriction information of the tenant plug-in included in the tenant plug-in start request. The resources that can be restricted in the resource control group corresponding to the created tenant plug-in may correspond to the resource restriction information of the tenant plug-in.

Based on the method and the system, the limitation and isolation of the resources required by each tenant can be realized based on the resource control group of the single system process, so that the resource isolation requirements of different tenants in the same process are met.

At 240, the obtained dynamic link library is loaded to the current system process within the isolated resource environment limited by the resource control group to start the corresponding programming language virtual machine and to implement instantiation and initialization of the tenant plug-in.

In one example, the obtained dynamic link library may be loaded to the current system process through dlopen () standard library functions provided by the Linux system within the isolated resource environment bounded by the created resource control group. During loading, the corresponding programming language virtual machine can be started, and the tenant plug-in can be instantiated and initialized. Therefore, all the child threads started by the tenant plugin subsequently can be ensured to be in the resource control group corresponding to the tenant plugin and limited by the resource of the resource control group.

Referring now to FIG. 4, FIG. 4 illustrates a flow diagram of one example of a process 400 for loading a dynamically linked library in accordance with an embodiment of the present specification.

As shown in FIG. 4, at 410, tenant plug-in instantiation is performed by utilizing the tenant plug-in program instance in the acquired dynamic link library to create a corresponding tenant plug-in.

In one example, the process of instantiating the tenant plug-in can be regarded as a process of creating a tenant plug-in instance (instance). The created tenant plug-in instance is used for providing a basis for the running of the tenant plug-in program instance through subsequent initialization.

At 420, a programming language virtual machine corresponding to the tenant plug-in is started.

In this embodiment, the programming language virtual machine corresponding to the tenant plug-in may be started in various manners. In one example, the corresponding programming language virtual machine can be launched in a manner that matches the type of programming language virtual machine used by the tenant plug-in. For example, the start of the programming language virtual machine in the go language may be triggered by a dlopen () standard library function provided by the Linux system. For another example, the programming language virtual machine in the Java language may be started by dlopen () standard library function provided by the Linux system and a JNI interface provided by Java. The programming language virtual machines may correspond to the created resource control groups, that is, each of the programming language virtual machines is limited by the resource quota of the corresponding resource control group.

At 430, according to the obtained dynamic link library, executing corresponding initialization code in the programming language virtual machine to realize initialization of the tenant plug-in.

In this embodiment, since the dynamic link library generally integrates the code to be executed and other resources required for code execution, the initialization code of the program (e.g., the tenant plug-in program instance) of the corresponding tenant may be executed in the corresponding programming language virtual machine according to the obtained dynamic link library, so as to implement initialization of the tenant plug-in.

It will be appreciated that steps 410-430 described above are also typically performed within the isolated resource environment bounded by the corresponding resource control group.

Based on the scheme, each tenant plug-in can be regarded as an independent program example by combining a programming language virtual machine and a dynamic link library corresponding to the tenant plug-in, the dynamic link library can be provided by a user in a dynamic link library mode, so that the compiling process of the program examples is completely controlled by the user, the program examples of different tenants are compiled and packaged separately, and programs running in one virtual machine can only access code instructions and data resources loaded by the current virtual machine based on the natural isolation characteristic of the programming language virtual machine, so that the isolation requirement of multiple tenants can be met. In addition, according to the scheme, the independent programming language virtual machines are provided for the program instances of the tenants, the program instances of different tenants are operated in the different programming language virtual machines, and no dependency relationship exists among the program instances, so that the problem of version-dependent conflict is solved.

Returning to FIG. 2, at 250, in response to the completion of the tenant plug-in initialization, a response message is sent to the client device indicating that the tenant plug-in startup was successful.

In the present embodiment, as an example, it can be known through a system process that the tenant plug-in initialization is complete. Thereafter, a response message indicating that the tenant plug-in launch was successful may be sent to the client device. In one example, the tenant plug-in can correspond to a plurality of tenant plug-in instances, and in response to the completion of the initialization of all of the tenant plug-in instances of the tenant plug-in, a response message indicating that the tenant plug-in startup was successful can be sent to the client device.

With continued reference to figure 5, figure 5 illustrates a flow diagram of yet another example of a method 500 for launching a tenant plug-in according to embodiments of the present description.

At 510, a tenant plug-in initiation request is received from a client device.

At 520, according to the storage path information of the dynamic link library in the tenant plug-in starting request, the dynamic link library of the tenant plug-in to be started is obtained.

In this embodiment, the dynamic link library may include a communication interface definition of a declaration. The communication interface definition is used for indicating the requirements to be met by the in-process communication interface required to be created. The in-process communication interface can provide an in-process communication channel between the tenant plug-in and an execution subject (e.g., plug-in management base 142 in fig. 1) of the method for starting the tenant plug-in.

At 530, a resource control group is created for the tenant plug-in.

At 540, the obtained dynamic link library is loaded to the current system process within the isolated resource environment limited by the resource control group to start the corresponding programming language virtual machine and to implement instantiation and initialization of the tenant plug-in.

At 550, in response to the tenant plug-in initialization completing, a response message indicating that the tenant plug-in startup was successful is sent to the client device.

It should be noted that, the above steps 510 to 550 may refer to the related descriptions of the steps 210 to 250 in the foregoing embodiments, and are not described herein again.

At 560, an in-process communication interface is created for the tenant plug-in according to the communication interface definition declared in the dynamic link library for in-process communication with other tenant plug-ins running within the same system process through the created in-process communication interface.

In this embodiment, an in-process communication interface conforming to the above-mentioned communication interface definition may be created for the tenant plug-in with reference to the related description of step 520, so as to perform in-process communication with other tenant plug-ins running in the same system process through the created in-process communication interface. In one example, an in-process communication interface may be created according to the relevant parameters defined by the communication interface described above.

Based on this, the scheme can use the created in-process communication interface as an in-process communication channel to realize communication with each tenant plug-in, and further provides a technical basis for communication between each tenant plug-in which is relayed by an execution main body (such as the plug-in management base 142 in fig. 1) of the method for starting the tenant plug-in. Optionally, a single system process is combined with a plurality of programming language virtual machines, and the communication channel is used for proxying the in-process communication request between the tenant plug-ins, so that the communication request between the tenant plug-ins can be completed in the same system process, and the performance of the communication between the tenant plug-ins is much higher than that of cross-process communication.

In some optional implementations of this embodiment, step 560 may also refer to the specific operations described in the embodiment of fig. 6 below.

By using the method for starting tenant plug-ins disclosed in fig. 1 to fig. 5, isolation and security of data materials of multi-tenant plug-ins can be ensured by creating a separate tenant plug-in instance for each tenant, and isolating code instructions, data resources and the like of each tenant in combination with a resource control group and a programming language virtual machine based on a system process. And the dynamic link library provided by each tenant is loaded to the system process in the resource control group corresponding to the tenant plug-in, so that the condition that the code compiling of the tenant using the old version is failed when different tenants depend on third parties of different versions is avoided. Therefore, the safe starting of multiple tenants in the same system process is realized.

Referring now to FIG. 6, FIG. 6 illustrates a flow diagram of one example of a method 600 for implementing in-process communication between tenant plug-ins in accordance with an embodiment of the present specification. In this embodiment, when each tenant plug-in a tenant plug-in set that is started in the same system process is started, in an isolated resource environment limited by each resource control group, each dynamic link library is loaded to the same system process, so as to start each programming language virtual machine and implement instantiation and initialization of each tenant plug-in. Each of the above-mentioned launched tenant plug-ins may have a tenant plug-in identification. For the related detailed description, reference may be made to the corresponding description in the foregoing embodiments, which is not repeated herein.

At 610, a first in-process communication request of a first tenant plug-in is received.

In this embodiment, the first in-process communication request may include a tenant plug-in identifier of a second tenant plug-in as a communication peer and communication parameter information of in-process communication. The communication parameter information includes a function call method and a function call parameter.

In one example, the first in-process communication request may be as shown in fig. 7 a. Wherein the targetTennantID can be used to represent a unique identification of a tenant plug-in (e.g., tenant plug-in 2) as a correspondent node. method may be used to represent a function call method. inputs may be used to represent function call parameters (which may be custom parameters, for example).

Optionally, the first in-process communication request may further include a tenant plug-in identifier of the first tenant plug-in as a calling party. Optionally, the communication parameter information may further include a call identifier.

In one example, the first in-process communication request described above may be as shown in FIG. 7 b. Wherein sourceTenantID can be used to represent a unique identification of the tenant plug-in as the caller (e.g., tenant plug-in 1). callID can be used to represent a calling identity, which should generally be unique to the caller for subsequent association with the calling context of the communication request within the process when a corresponding response message is returned. The call context may include attributes associated with a call, such as the address of the call, the name of the calling party, the timeout period, and other attributes, and custom data passed by the user outside of the parameters defined by the interface. For the specific meanings of targetTenantID, method and inputs, reference is made to the above.

Returning to FIG. 6, at 620, a second tenant plug-in is located in the tenant plug-in set started in the same system process according to the tenant plug-in identification of the second tenant plug-in.

In the present embodiment, the "positioning" may be understood as determining and finding the tenant plug-in corresponding to the tenant plug-in identifier. The method is generally applied to a scene that a plurality of tenant plug-ins are started in the same system process.

At 630, a second in-process communication request is sent to the located second tenant plug-in.

In this embodiment, the second intra-process communication request may include communication parameter information of intra-process communication. The communication parameter information of the intra-process communication is generally identical to the communication parameter information of the first intra-process communication request. Accordingly, the second tenant plug-in may call the target function according to the function call method (e.g., the method) and the function call parameter (e.g., the inputs) of the communication parameter information to generate the response message of the intra-process communication. Optionally, the second in-process communication request may also be the same as the first in-process communication request.

At 640, a response message returned by the second tenant plug-in is received.

In this embodiment, the response message may include a call result corresponding to the second intra-process communication request. The call result may be, for example, a return value corresponding to the method called by the function. Optionally, the response message may further include at least one of the following: and the tenant plug-in identification of the first tenant plug-in of the calling party is used as the tenant plug-in identification of the second tenant plug-in of the called party.

In one example, the response message may be as shown in fig. 8 a. outputs may be used to represent the return value for this call. specific meanings of sourceTenantID and targetTenantID can be referred to the foregoing.

Optionally, in an example, the response message may further include a call identifier, so that the first tenant plug-in associates the received response message with a call of the communication request in the process in a context according to the call identifier.

In one example, the response message may be as shown in fig. 8 b. The concrete meanings of sourceTenantID, targetTenantID, callID and outputs can be referred to the above.

It should be noted that, the tenant plug-in identifier of the first tenant plug-in, the tenant plug-in identifier of the second tenant plug-in, and the call identifier in the response message are generally consistent with corresponding fields included in the corresponding in-process communication request.

Returning to figure 6, at 650, a response message is sent to the first tenant plug-in.

In this embodiment, the corresponding tenant plug-in, that is, the first tenant plug-in, may be determined according to the identifier of the first tenant plug-in included in the response message. The response message may then be sent to the first tenant plug-in a manner similar to that described above.

Optionally, the first tenant plug-in may associate the call identifier in the response message with the corresponding sent in-process communication request, so as to complete the communication call of the cross-tenant plug-in.

Optionally, the first tenant plug-in may send the first in-process communication request and receive the response message through the first in-process communication interface. The second tenant plug-in may receive a second in-process communication request and send a response message through the second in-process communication interface. The first in-process communication interface and the second in-process communication interface can be created according to communication interface definitions declared in respective dynamic link libraries during the starting process of the first tenant plug-in and the second tenant plug-in respectively. The first intra-process communication interface and the second intra-process communication interface may refer to corresponding descriptions of the "intra-process communication interface" in the foregoing embodiments, and details are not repeated here.

In one example, an in-process communication interface (e.g., a first in-process communication interface) can be injected into a dynamic link library of a tenant plug-in (e.g., a first tenant plug-in) as an external dependent function symbol when the dynamic link library of the tenant plug-in is loaded by using a Dependency Injection (Dependency Injection) technology, so as to implement function calls within the same process, i.e., communication between an execution subject (e.g., the plug-in management base 142 in fig. 1) of a method for implementing in-process communication between tenant plug-ins and the tenant plug-in (e.g., the first tenant plug-in).

Optionally, in an example, the first tenant plug-in and the second tenant plug-in may be started by the method for starting the tenant plug-in as described in the foregoing embodiments of fig. 1 to 5.

With continued reference to FIG. 9, FIG. 9 illustrates an interaction timing diagram for one example of a method 900 for implementing in-process communication between tenant plug-ins in accordance with an embodiment of the present specification.

At 910, the plug-in management base receives a tenant plug-in initiation request sent by the console.

In this embodiment, the tenant plug-in start request sent by the console may include at least one tenant plug-in start request from a client device.

At 920, the plug-in management base obtains the dynamic link library of the tenant plug-in to be started according to the storage path information of the dynamic link library in the tenant plug-in starting request.

At 930, the plug-in management chassis creates resource control groups for the respective tenant plug-ins.

At 940, the plug-in management base loads the obtained dynamic link library of each tenant plug-in to the current system process within the isolated resource environment limited by each created resource control group.

It should be noted that, since the plug-in management base, the first tenant plug-in and the second tenant plug-in are both used as user processes and depend on the same system process, the above step 940 involves interaction based on the system process.

At 950, in response to the tenant plug-in initialization completing, the plug-in management chassis sends a response message to the console indicating that the tenant plug-in startup was successful.

In an example of this embodiment, the console may further return, to the client used by the corresponding tenant according to the response message, a message indicating that the tenant plugin has successfully started.

At 960, the plug-in management chassis receives a first in-process communication request of a first tenant plug-in.

In this embodiment, the first in-process communication request includes a tenant plug-in identifier of a second tenant plug-in as a communication peer and communication parameter information of in-process communication. The communication parameter information includes a function call method and a function call parameter.

At 970, according to the tenant plug-in identifier of the second tenant plug-in, the plug-in management base centrally locates the second tenant plug-in the tenant plug-in set started in the same system process.

At 980, the plug-in management base sends the second in-process communication request to the located second tenant plug-in.

In this embodiment, the second intra-process communication request includes communication parameter information of intra-process communication. And the second tenant plug-in calls the target function according to the function calling method and the function calling parameter to generate a response message of in-process communication.

At 990, the plug-in management base receives the response message returned by the second tenant plug-in.

In this embodiment, the response message may include a call result corresponding to the first intra-process communication request.

At 9100, the plug-in management base sends the response message to the first tenant plug-in.

It should be noted that, the above steps 910-950 can refer to the method for starting the tenant plug-in described in the foregoing embodiments of fig. 1-5. The above steps 960-9100 may refer to the method for implementing intra-process communication between tenant plugins as described in the foregoing embodiments of fig. 6-8. And will not be described in detail herein.

With the method for implementing intra-process communication between tenant plug-ins disclosed in fig. 6 to fig. 9, by using the method for loading the dynamic link library into the same system process in the isolated resource environment limited by the respective resource control group used by each tenant plug-in during the starting process, a corresponding intra-process communication channel is established with each tenant plug-in, and the intra-process communication request between proxy tenant plug-ins is implemented by using the intra-process communication channel as a relay. Because the communication requests among the tenant plug-ins can be completed in the same system process, the performance of the tenant plug-in communication is far higher than that of cross-process communication. Therefore, on the premise of realizing resource isolation, the multiple tenant plug-ins can also have high performance of in-process communication.

Figure 10 illustrates a block diagram of one example for launching a tenant plug-in device 1000 according to embodiments of the present description. The embodiment of the apparatus may correspond to the embodiment of the method shown in fig. 1 to fig. 5, and the apparatus may be applied to various electronic devices.

As shown in fig. 10, the apparatus 1000 for launching tenant plug-in may include a request receiving unit 1010, a library acquiring unit 1020, a resource control group creating unit 1030, a library loading unit 1040, and a response transmitting unit 1050.

A request receiving unit 1010 configured to receive a tenant plug-in starting request from a client device, where the tenant plug-in starting request includes a type of a programming language virtual machine used by the tenant plug-in and storage path information of a dynamic link library corresponding to the tenant plug-in. The operation of the request receiving unit 1010 may refer to the operation of 210 described above in fig. 2.

In one example, the tenant plug-in initiation request comprises at least two tenant plug-in initiation requests, and the at least two tenant plug-in initiation requests are sent integrated into a single integrated tenant plug-in initiation request.

The library obtaining unit 1020 is configured to obtain a dynamic link library of the tenant plug-in to be started according to the storage path information of the dynamic link library in the tenant plug-in starting request, where the dynamic link library includes a tenant plug-in program instance and a programming language virtual machine. The operation of the library acquisition unit 1020 may refer to the operation of 220 described above in fig. 2.

A resource control group creation unit 1030 configured to create a resource control group for the tenant plug-in. The operation of the resource control group creation unit 1030 may refer to the operation of 230 described above in fig. 2.

In one example, the tenant plug-in initiation request may further include resource restriction information of the tenant plug-in. The resource control group creating unit 1030 may be further configured to create a resource control group for the tenant plug-in according to the resource restriction information.

The library loading unit 1040 is configured to load the obtained dynamic link library into the current system process within the isolated resource environment limited by the resource control group, so as to start the corresponding programming language virtual machine and implement instantiation and initialization of the tenant plug-in. The operation of the library load unit 1040 may refer to the operation of 240 described above in fig. 2.

With further reference to fig. 11, fig. 11 illustrates a block diagram of one example of a library load unit 1100 in an apparatus for launching tenant plug-ins in accordance with an embodiment of the present description.

The library loading unit 1100 may include a tenant plug-in creation module 1110, a virtual machine start-up module 1120, and an initialization module 1130.

And a tenant plug-in creating module 1110 configured to instantiate a tenant plug-in by using the obtained tenant plug-in program instance in the dynamic link library to create a corresponding tenant plug-in. The operation of the tenant plug-in creation module 1110 may refer to the operation of 410 described above with respect to figure 4.

A virtual machine starting module 1120 configured to start the programming language virtual machine corresponding to the tenant plug-in. The operation of the virtual machine startup module 1120 may refer to the operation of 420 described above in fig. 4.

An initialization module 1120 configured to execute corresponding initialization code in the programming language virtual machine according to the obtained dynamic link library to realize initialization of the tenant plug-in. The operations of the initialization module 1130 may refer to the operations of 430 described above in FIG. 4.

Returning to fig. 10, a response sending unit 1050 configured to send a response message indicating that the tenant plug-in startup is successful to the client device in response to the completion of the initialization of the tenant plug-in. The operation of response sending unit 1050 may refer to the operation of 250 described above in fig. 2.

In one example, the tenant plug-in initiation request further includes a tenant plug-in identification of the tenant plug-in. The means for launching the tenant plug-in may further comprise: an identity associating unit (not shown in the figure) configured to associate the created tenant plug-in with the tenant plug-in identity of the tenant plug-in.

With continued reference to fig. 12, fig. 12 illustrates a block diagram of yet another example of an apparatus 1200 for launching tenant plug-ins in accordance with embodiments of the present description.

As shown in fig. 12, the apparatus 1200 for launching tenant plug-ins may include a request receiving unit 1210, a library acquiring unit 1220, a resource control group creating unit 1230, a library loading unit 1240, and a response transmitting unit 1250 and a communication interface creating unit 1260.

A communication interface creating unit 1260, configured to create an in-process communication interface for the tenant plug-in according to the communication interface definition declared in the dynamic link library, so as to perform in-process communication with other tenant plug-ins running in the same system process through the created in-process communication interface. The operation of the communication interface creation unit 1260 may refer to the operation of 560 described above in fig. 5.

The request receiving unit 1210, the library obtaining unit 1220, the resource control group creating unit 1230, the library loading unit 1240 and the response sending unit 1250 may refer to corresponding descriptions of the request receiving unit 1010, the library obtaining unit 1020, the resource control group creating unit 1030, the library loading unit 1040 and the response sending unit 1050 in the embodiment of fig. 10, and are not described herein again.

With continuing reference to figure 13, figure 13 illustrates a block diagram of one example of an apparatus 1300 for implementing in-process communication between tenant plug-ins in accordance with an embodiment of the present specification. The embodiment of the apparatus may correspond to the embodiment of the method shown in fig. 6 to 9, and the apparatus may be applied to various electronic devices.

In this embodiment, when each tenant plug-in a tenant plug-in set started in the same system process is started, in an isolated resource environment limited by a respective resource control group, a respective dynamic link library is loaded to the same system process, so as to start a respective programming language virtual machine and implement instantiation and initialization of the respective tenant plug-in, and each started tenant plug-in has a tenant plug-in identifier.

As shown in fig. 13, an apparatus 1300 for implementing intra-process communication between tenant plug-ins may include a communication request receiving unit 1310, a tenant plug-in locating unit 1320, a communication request transmitting unit 1330, a response message receiving unit 1340, and a response message transmitting unit 1350.

A communication request receiving unit 1310 configured to receive a first in-process communication request of a first tenant plug-in. The first in-process communication request comprises tenant plug-in identification of a second tenant plug-in serving as a communication opposite end and communication parameter information of in-process communication, wherein the communication parameter information comprises a function calling method and a function calling parameter. The operation of the communication request receiving unit 1310 may refer to the operation of 610 described above in fig. 6.

In one example, the communication parameter information further includes a call identification, and the response message is associated with a call context of the in-process communication request in the first tenant plugin.

A tenant plug-in positioning unit 1320, configured to position the second tenant plug-in a tenant plug-in set started in the same system process according to the tenant plug-in identifier of the second tenant plug-in. The operation of the tenant plug-in location unit 1320 may refer to the operation of 620 described above in fig. 6.

A communication request sending unit 1330 configured to send a second in-process communication request to the located second tenant plug-in, the second in-process communication request including communication parameter information of the in-process communication, and the second tenant plug-in calling a target function according to the function call method and the function call parameter to generate a response message of the in-process communication. The operation of the communication request transmitting unit 1330 may refer to the operation of 630 described above in fig. 6.

A response message receiving unit 1340 configured to receive a response message returned by the second tenant plug-in. The operation of the response message receiving unit 1340 may refer to the operation of 640 described above with reference to fig. 6.

A response message sending unit 1350 configured to send the response message to the first tenant plug-in. The operation of the response message sending unit 1350 may refer to the operation of 650 described above with reference to fig. 6.

In one example, the first tenant plug-in sends the first in-process communication request and receives the response message through a first in-process communication interface, the second tenant plug-in receives the second in-process communication request and sends the response message through a second in-process communication interface, and the first in-process communication interface and the second in-process communication interface are respectively created according to communication interface definitions declared in respective dynamic link libraries during the starting process of the first tenant plug-in and the second tenant plug-in.

In one example, the first tenant plug-in and the second tenant plug-in are started by a method for starting the tenant plug-in as described in fig. 1-5.

Embodiments of a method and apparatus for launching tenant plug-ins, and a method and apparatus for implementing intra-process communication between tenant plug-ins according to embodiments of the present specification are described above with reference to fig. 1 through 13.

The device for starting the tenant plug-in and the device for realizing intra-process communication between tenant plug-ins of the embodiments of the present specification may be realized by hardware, software, or a combination of hardware and software. In the case of software implementation, as a logical means, the device is formed by reading corresponding computer program instructions in the memory into the memory for operation through the processor of the device in which the device is located. In the embodiment of the specification, the device for starting the tenant plug-in and the device for realizing intra-process communication between the tenant plug-ins can be realized by utilizing electronic equipment, for example.

Figure 14 illustrates a block diagram 1400 of one example of a tenant plug-in management device according to embodiments of the present description. As shown in fig. 14, according to one embodiment, there is provided a tenant plug-in management apparatus including: means 1410 for launching tenant plug-ins and means 1420 for implementing intra-process communication between tenant plug-ins. The apparatus 1410 for starting the tenant plug-in may refer to corresponding descriptions in the embodiments of fig. 10 to 12. An apparatus 1420 for implementing intra-process communication between tenant plugins can refer to the corresponding description in the embodiment of fig. 13.

Fig. 15 shows a schematic diagram of an apparatus 1500 for launching a tenant plug-in according to an embodiment of the present description.

As shown in fig. 15, the apparatus 1500 for launching a tenant plug-in may include at least one processor 1510, a storage (e.g., a non-volatile storage) 1520, a memory 1530, and a communication interface 1540, and the at least one processor 1510, the storage 1520, the memory 1530, and the communication interface 1540 are connected together via a bus 1550. The at least one processor 1510 executes at least one computer-readable instruction (i.e., the elements described above as being implemented in software) stored or encoded in memory.

In one embodiment, computer-executable instructions are stored in the memory that, when executed, cause the at least one processor 1510 to: receiving a tenant plug-in starting request from client equipment, wherein the tenant plug-in starting request comprises a programming language virtual machine type used by a tenant plug-in and storage path information of a dynamic link library corresponding to the tenant plug-in; acquiring a dynamic link library of the tenant plug-in to be started according to the storage path information of the dynamic link library in the tenant plug-in starting request, wherein the dynamic link library comprises a tenant plug-in program instance and a programming language virtual machine; creating a resource control group for the tenant plug-in; loading the obtained dynamic link library to the current system process in an isolated resource environment limited by the resource control group so as to start a corresponding programming language virtual machine and realize instantiation and initialization of the tenant plug-in; and responding to the initialization completion of the tenant plug-in, and sending a response message for indicating the successful start of the tenant plug-in to the client equipment.

It should be appreciated that the computer-executable instructions stored in the memory, when executed, cause the at least one processor 1510 to perform the various operations and functions described above in connection with fig. 1-5 in the various embodiments of the present description.

Figure 16 illustrates a schematic diagram of an apparatus 1600 for implementing in-process communication between tenant plug-ins of an embodiment of the present specification.

As shown in fig. 16, an apparatus 1600 for enabling in-process communication among tenant plug-ins may include at least one processor 1610, a storage (e.g., non-volatile storage) 1620, a memory 1630, and a communication interface 1640, and the at least one processor 1610, the storage 1620, the memory 1630, and the communication interface 1640 are connected together via a bus 1650. The at least one processor 1610 executes at least one computer-readable instruction (i.e., the above-described elements implemented in software) stored or encoded in memory.

In one embodiment, computer-executable instructions are stored in the memory that, when executed, cause the at least one processor 1610 to: receiving a first in-process communication request of a first tenant plug-in, wherein the first in-process communication request comprises a tenant plug-in identifier of a second tenant plug-in serving as a communication opposite end and communication parameter information of in-process communication, and the communication parameter information comprises a function calling method and a function calling parameter; according to the tenant plug-in identification of the second tenant plug-in, the second tenant plug-in is positioned in a tenant plug-in set started in the same system process; sending a second in-process communication request to the located second tenant plug-in, wherein the second in-process communication request comprises communication parameter information of in-process communication, and the second tenant plug-in calls a target function according to the function calling method and the function calling parameter to generate a response message of the in-process communication; receiving a response message returned by the second tenant plug-in; and sending the response message to the first tenant plug-in, wherein when each tenant plug-in a tenant plug-in set started in the same system process is started, the respective dynamic link library is loaded to the same system process in an isolated resource environment limited by the respective resource control group, so as to start the respective programming language virtual machine and realize instantiation and initialization of the respective tenant plug-in, and each started tenant plug-in has a tenant plug-in identifier.

It should be appreciated that the computer-executable instructions stored in the memory, when executed, cause the at least one processor 1610 to perform the various operations and functions described above in connection with fig. 6-9 in the various embodiments of the present description.

According to one embodiment, a program product, such as a computer-readable medium, is provided. The computer-readable medium may have instructions (i.e., elements described above as being implemented in software) that, when executed by a computer, cause the computer to perform various operations and functions described above in connection with fig. 1-9 in the various embodiments of the present specification.

Specifically, a system or apparatus may be provided which is provided with a readable storage medium on which software program code implementing the functions of any of the above embodiments is stored, and causes a computer or processor of the system or apparatus to read out and execute instructions stored in the readable storage medium.

In this case, the program code itself read from the readable medium can realize the functions of any of the above-described embodiments, and thus the machine-readable code and the readable storage medium storing the machine-readable code constitute a part of the present invention.

Computer program code required for the operation of various portions of the present specification may be written in any one or more of a variety of programming languages, including an object oriented programming language such as Java, scala, smalltalk, eiffel, JADE, emerald, C + +, C #, VB, NET, python, and the like, a conventional programming language such as C, visual Basic 2003, perl, COBOL 2002, PHP, and ABAP, a dynamic programming language such as Python, ruby, and Groovy, or other programming languages, and the like. The program code may execute on the user's computer, or on the user's computer as a stand-alone software package, or in part on the user's computer and in part on a remote computer, or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any form of network, such as a Local Area Network (LAN) or a Wide Area Network (WAN), or to an external computer (for example, through the Internet), or in a cloud computing environment, or as a service, such as software as a service (SaaS).

Examples of the readable storage medium include floppy disks, hard disks, magneto-optical disks, optical disks (e.g., CD-ROMs, CD-Rs, CD-RWs, DVD-ROMs, DVD-RAMs, DVD-RWs), magnetic tapes, nonvolatile memory cards, and ROMs. Alternatively, the program code may be downloaded from a server computer or from the cloud via a communications network.

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

Not all steps and elements in the above flows and system structure diagrams are necessary, and some steps or elements may be omitted according to actual needs. The execution order of the steps is not fixed, and can be determined as required. The apparatus structures described in the above embodiments may be physical structures or logical structures, that is, some units may be implemented by the same physical entity, or some units may be implemented by a plurality of physical entities, or some units may be implemented by some components in a plurality of independent devices.

The term "exemplary" used throughout this specification means "serving as an example, instance, or illustration," and does not mean "preferred" or "advantageous" over other embodiments. The detailed description includes specific details for the purpose of providing an understanding of the described technology. However, the techniques may be practiced without these specific details. In some instances, well-known structures and devices are shown in block diagram form in order to avoid obscuring the concepts of the described embodiments.

Although the embodiments of the present disclosure have been described in detail with reference to the accompanying drawings, the embodiments of the present disclosure are not limited to the specific details of the embodiments, and various simple modifications may be made to the technical solutions of the embodiments of the present disclosure within the technical spirit of the embodiments of the present disclosure, and all of them fall within the scope of the embodiments of the present disclosure.

The previous description of the disclosure is provided to enable any person skilled in the art to make or use the disclosure. Various modifications to the disclosure will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other variations without departing from the scope of the disclosure. Thus, the description is not intended to be limited to the examples and designs described herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for launching a tenant plug-in, comprising:

receiving a tenant plug-in starting request from client equipment, wherein the tenant plug-in starting request comprises a programming language virtual machine type used by the tenant plug-in and storage path information of a dynamic link library corresponding to the tenant plug-in;

acquiring a dynamic link library of the tenant plug-in to be started according to the storage path information of the dynamic link library in the tenant plug-in starting request, wherein the dynamic link library comprises a tenant plug-in program instance and a programming language virtual machine;

creating a resource control group for the tenant plug-in;

loading the obtained dynamic link library to the current system process in an isolated resource environment limited by the resource control group so as to start a corresponding programming language virtual machine and realize instantiation and initialization of the tenant plug-in; and

and responding to the initialization completion of the tenant plug-in, and sending a response message for indicating the successful start of the tenant plug-in to the client device.

2. The method of claim 1, wherein the tenant plug-in initiation request further includes resource restriction information of the tenant plug-in,

the creating a resource control group for the tenant plug-in comprises:

and according to the resource limitation information, creating a resource control group for the tenant plug-in.

3. The method of claim 1, wherein the tenant plug-in initiation request further includes a tenant plug-in identification of the tenant plug-in, the method further comprising:

associating the created tenant plug-in with a tenant plug-in identification of the tenant plug-in.

4. The method as claimed in claim 1, wherein loading the obtained dynamic link library into a current system process to start a corresponding programming language virtual machine and implement instantiation and initialization of the tenant plug-in within the isolated resource environment limited by the resource control group comprises:

utilizing the acquired tenant plug-in program instance in the dynamic link library to instantiate the tenant plug-in so as to create a corresponding tenant plug-in;

starting a programming language virtual machine corresponding to the tenant plug-in; and

and executing corresponding initialization codes in the programming language virtual machine according to the acquired dynamic link library so as to realize the initialization of the tenant plug-in.

5. The method of claim 1, wherein the tenant plug-in initiation request comprises at least two tenant plug-in initiation requests, and the at least two tenant plug-in initiation requests are sent integrated into a single integrated tenant plug-in initiation request.

6. The method of any of claims 1 to 5, further comprising:

and according to the communication interface definition stated in the dynamic link library, establishing an in-process communication interface for the tenant plug-in so as to carry out in-process communication with other tenant plug-ins running in the same system process through the established in-process communication interface.

7. A method for enabling in-process communication between tenant plugins, comprising:

receiving a first in-process communication request of a first tenant plug-in, wherein the first in-process communication request comprises a tenant plug-in identifier of a second tenant plug-in serving as a communication opposite end and communication parameter information of in-process communication, and the communication parameter information comprises a function calling method and a function calling parameter;

according to the tenant plug-in identification of the second tenant plug-in, the second tenant plug-in is positioned in a tenant plug-in set started in the same system process;

sending a second in-process communication request to the located second tenant plug-in, wherein the second in-process communication request comprises communication parameter information of in-process communication, and the second tenant plug-in calls a target function according to the function call method and the function call parameter to generate a response message of the in-process communication;

receiving a response message returned by the second tenant plug-in; and

sending the response message to the first tenant plug-in,

when each tenant plug-in a tenant plug-in set started in the same system process is started, loading respective dynamic link libraries into the same system process in an isolated resource environment limited by respective resource control groups respectively so as to start respective programming language virtual machines and realize instantiation and initialization of respective tenant plug-ins, wherein each started tenant plug-in has a tenant plug-in identifier.

8. The method of claim 7, wherein the communication parameter information further includes a call identification, the response message being associated in the first tenant plug-in with a call context of the in-process communication request.

9. The method of claim 7, wherein the first tenant plug-in sends the first in-process communication request and receives the response message through a first in-process communication interface, the second tenant plug-in receives the second in-process communication request and sends the response message through a second in-process communication interface, and the first in-process communication interface and the second in-process communication interface are created according to communication interface definitions declared in respective dynamic link libraries during a boot-up process of the first tenant plug-in and the second tenant plug-in, respectively.

10. The method according to any one of claims 7 to 9, wherein each tenant plug-in the tenant plug-in set started in the same system process is started according to the method for starting tenant plug-ins according to any one of claims 1 to 6.

11. An apparatus for launching a tenant plug-in, comprising:

the client device comprises a request receiving unit, a processing unit and a processing unit, wherein the request receiving unit receives a tenant plug-in starting request from client equipment, and the tenant plug-in starting request comprises a programming language virtual machine type used by the tenant plug-in and storage path information of a dynamic link library corresponding to the tenant plug-in;

the library acquisition unit is used for acquiring a dynamic link library of the tenant plug-in to be started according to the storage path information of the dynamic link library in the tenant plug-in starting request, wherein the dynamic link library comprises a tenant plug-in program instance and a programming language virtual machine;

the resource control group creating unit is used for creating a resource control group for the tenant plug-in;

the library loading unit is used for loading the acquired dynamic link library to the current system process in the isolated resource environment limited by the resource control group so as to start a corresponding programming language virtual machine and realize instantiation and initialization of the tenant plug-in; and

and the response sending unit is used for responding to the completion of initialization of the tenant plug-in and sending a response message for indicating the successful start of the tenant plug-in to the client device.

12. The apparatus of claim 11, wherein the tenant plug-in initiation request further includes resource restriction information of a tenant plug-in,

and the resource control group creating unit creates a resource control group for the tenant plug-in according to the resource limitation information.

13. The apparatus of claim 11, wherein the tenant plug-in initiation request further comprises a tenant plug-in identification of a tenant plug-in, the apparatus further comprising:

and the identification association unit associates the created tenant plug-in with the tenant plug-in identification of the tenant plug-in.

14. The apparatus of claim 11, wherein the library loading unit comprises:

the tenant plug-in creating module is used for instantiating the tenant plug-in by using the acquired tenant plug-in program instance in the dynamic link library so as to create a corresponding tenant plug-in;

the virtual machine starting module is used for starting the programming language virtual machine corresponding to the tenant plug-in; and

and the initialization module executes corresponding initialization codes in the programming language virtual machine according to the acquired dynamic link library so as to realize the initialization of the tenant plug-in.

15. The apparatus of any of claims 11 to 14, the apparatus further comprising:

and the communication interface creating unit is used for creating an in-process communication interface for the tenant plug-in according to the communication interface definition stated in the dynamic link library so as to carry out in-process communication with other tenant plug-ins running in the same system process through the created in-process communication interface.

16. An apparatus for enabling in-process communication between tenant plugins, comprising:

the communication request receiving unit is used for receiving a first in-process communication request of a first tenant plug-in, wherein the first in-process communication request comprises a tenant plug-in identifier of a second tenant plug-in serving as a communication opposite end and communication parameter information of in-process communication, and the communication parameter information comprises a function calling method and a function calling parameter;

the tenant plug-in positioning unit is used for positioning the second tenant plug-in a tenant plug-in set started in the same system process according to the tenant plug-in identification of the second tenant plug-in;

the communication request sending unit is used for sending a second in-process communication request to the located second tenant plug-in, wherein the second in-process communication request comprises communication parameter information of in-process communication, and the second tenant plug-in calls a target function according to the function calling method and the function calling parameter to generate a response message of the in-process communication;

the response message receiving unit is used for receiving a response message returned by the second tenant plug-in; and

a response message sending unit that sends the response message to the first tenant plug-in,

when each tenant plug-in a tenant plug-in set started in the same system process is started, loading respective dynamic link libraries into the same system process in an isolation resource environment limited by respective resource control groups respectively so as to start respective programming language virtual machines and realize instantiation and initialization of the respective tenant plug-ins, wherein the started tenant plug-ins have tenant plug-in identifiers.

17. A tenant plug-in management apparatus comprising:

the apparatus for launching tenant plug-in as recited in any one of claims 11 to 15; and

the apparatus for enabling in-process communication between tenant plugins as recited in claim 16.

18. An apparatus for launching a tenant plug-in, comprising: at least one processor, a memory coupled with the at least one processor, and a computer program stored on the memory, the at least one processor executing the computer program to implement the method for launching a tenant plug-in as claimed in any one of claims 1 to 6.

19. An apparatus for enabling in-process communication between tenant plugins, comprising: at least one processor, a memory coupled with the at least one processor, and a computer program stored on the memory, the at least one processor executing the computer program to implement the method for implementing in-process communication between tenant plugins as claimed in any one of claims 7 to 10.

20. A computer-readable storage medium storing a computer program which, when executed by a processor, implements the method for launching a tenant plug-in as claimed in any one of claims 1 to 6 or implements the method for enabling in-process communication between tenant plug-ins as claimed in any one of claims 7 to 10.

21. A computer program product comprising a computer program executed by a processor to implement the method for launching a tenant plug-in as claimed in any one of claims 1 to 6 or to implement the method for enabling in-process communication between tenant plug-ins as claimed in any one of claims 7 to 10.