CN111538492A

CN111538492A - Policy implementation calling method and device, electronic equipment and storage medium

Info

Publication number: CN111538492A
Application number: CN202010334043.9A
Authority: CN
Inventors: 黄勇; 屠振贤
Original assignee: Zhejiang Dasou Vehicle Software Technology Co Ltd
Current assignee: Zhejiang Dasou Vehicle Software Technology Co Ltd
Priority date: 2020-04-24
Filing date: 2020-04-24
Publication date: 2020-08-14
Anticipated expiration: 2040-04-24
Also published as: CN111538492B

Abstract

The application provides a policy-implemented calling method and device, electronic equipment and a storage medium; the method is applied to a policy implementation caller, and comprises the following steps: when detecting a calling operation of a user for a target policy implementation, determining a policy implementation type of the target policy implementation; wherein, the logic of the target policy implementation is matched with the extension interface specified by the policy implementation caller, and the mapping relation between any policy implementation and the provider of any policy implementation is recorded in the statistical center corresponding to the policy implementation type of any policy implementation; acquiring a provider for realizing the target strategy inquired by a target statistical center according to the recorded mapping relation, wherein the target statistical center is a statistical center corresponding to the determined strategy realization type; initiating a call to a provider of the target policy implementation for the target policy implementation to execute the target policy implementation through the extended interface.

Description

Policy implementation calling method and device, electronic equipment and storage medium

Technical Field

The present application relates to the field of software development, and in particular, to a policy implementation invoking method and apparatus, an electronic device, and a storage medium.

Background

With the more and more extensive requirements of users on application software, developers pay more and more attention to the problem of how to reduce the difficulty of software development.

The Java language is an object-oriented programming language that is favored by developers due to its powerful and simple features. In order to improve the efficiency of software development through the Java language, a Spring framework based on the Java language has been developed. The Spring framework enables developers to pay attention to the general codes in the programming in the software development process, and only to the codes related to the business, so that the difficulty of software development is reduced, and the efficiency is improved.

Disclosure of Invention

In view of this, the present application provides a policy implementation calling method and apparatus, an electronic device, and a storage medium, so that when implementing a calling policy, a developer does not need to compile a corresponding extension interface for implementing the policy to be called, and only needs to directly call the extension interface carried by the developer.

In order to achieve the above purpose, the present application provides the following technical solutions:

according to a first aspect of the present application, a policy implementation invoking method is provided, which is applied to a policy implementation caller, and the method includes:

when detecting a calling operation of a user for a target policy implementation, determining a policy implementation type of the target policy implementation; wherein, the logic of the target policy implementation is matched with the extension interface specified by the policy implementation caller, and the mapping relation between any policy implementation and the provider of any policy implementation is recorded in the statistical center corresponding to the policy implementation type of any policy implementation;

acquiring a provider for realizing the target strategy inquired by a target statistical center according to the recorded mapping relation, wherein the target statistical center is a statistical center corresponding to the determined strategy realization type;

initiating a call to a provider of the target policy implementation for the target policy implementation to execute the target policy implementation through the extended interface.

According to a second aspect of the present application, a policy implementation invoking device is provided, which is applied to a policy implementation caller, and the device includes:

the device comprises a determining unit, a judging unit and a judging unit, wherein the determining unit is used for determining the strategy implementation type of the target strategy implementation when detecting the calling operation of a user for the target strategy implementation; wherein, the logic of the target policy implementation is matched with the extension interface specified by the policy implementation caller, and the mapping relation between any policy implementation and the provider of any policy implementation is recorded in the statistical center corresponding to the policy implementation type of any policy implementation;

the acquisition unit is used for acquiring a provider for realizing the target strategy inquired by a target statistical center according to the recorded mapping relation, wherein the target statistical center is a statistical center corresponding to the determined strategy realization type;

and the calling unit initiates the calling aiming at the target policy realization to the provider of the target policy realization so as to execute the target policy realization through the expansion interface.

According to a third aspect of the present application, there is provided an electronic device comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method as in any of the above embodiments by executing the executable instructions.

According to a fourth aspect of embodiments of the present disclosure, there is provided a computer-readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the steps of the method as in any one of the above-mentioned embodiments.

According to the technical scheme, the policy implementation provided by each provider is registered in the statistical center corresponding to the policy implementation type of the provider in advance, so that the policy implementation caller can inquire the provider needing to call the policy implementation from the corresponding statistical center under the condition that the policy implementation is required, and further, the policy implementation can be called from the inquired policy implementation provider.

Further, the logic of the policy implementation that can be called in the present application is matched with the extension interface specified by the policy implementation caller, for example, a developer writes the policy implementation by using the extension interface as a unified standard when developing each policy implementation. Therefore, when the developer calls the strategy, the developer does not need to create an extension interface for calling the target strategy implementation aiming at the target strategy implementation, and can call the target strategy implementation only through the existing extension interface, so that the working efficiency of the developer is improved.

Drawings

FIG. 1 is a flow chart illustrating a policy-implemented invocation method according to an exemplary embodiment of the present application.

FIG. 2 is a flowchart illustrating another policy-implemented invocation method according to an exemplary embodiment of the present application

Fig. 3 is a flow chart illustrating a method for invoking a local call class policy implementation according to an exemplary embodiment of the present application.

FIG. 4 is an interaction diagram illustrating an implementation of invoking a remote invocation class policy according to an exemplary embodiment of the present application.

Fig. 5 is a schematic structural diagram of an electronic device according to an exemplary embodiment of the present application.

FIG. 6 is a block diagram illustrating an invoking device for one policy implementation according to an exemplary embodiment of the present application.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in this application and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

It is to be understood that although the terms first, second, third, etc. may be used herein to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of the present application. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.

In the process of programming by using Java language, developers propose a Spring framework based on the Java language in order to solve the problems of repeated writing of the Java language and the like. A large amount of general codes used for programming are reserved in the Spring framework, so that developers do not need to pay attention to the general codes used in the programming but only to the codes related to the service to which the programming is aimed, namely the service codes, in the software development process.

In the general Spring frame, a single Spring container is contained. In order to avoid repeated writing of the service codes, a developer usually writes corresponding service codes in advance for each service, that is, the policy implementation described in the present application, and records the correspondence between the written identifier of the policy implementation and the location thereof in the Spring container. In this way, when a certain policy implementation needs to be invoked, the location of the policy implementation can be queried in the Spring container and invoked.

However, in the related art, invoking policy implementation is still a rather complicated process. When a developer searches a position of a policy implementation to be called in a Spring container and calls the policy implementation from a corresponding position, the developer needs to judge a service type to which the policy implementation belongs first, and then creates an extension interface (also called an extension point) for calling the policy implementation based on the determined service type, and the policy implementation can be called only after the creation of the extension interface is completed. Secondly, the existing policy implementation calling method can only call the policy implementation stored locally, and cannot call the non-local policy implementation.

For the above reasons, in the engineering practice of software, the calling of the policy implementation requires that a developer is very familiar with the called policy implementation and can write a corresponding extension interface based on the service type of the policy implementation. Under the condition that a large number of providers provide policy implementation, software codes in a policy implementation caller generally need to be adjusted for multiple times to adapt to policy implementation provided by different providers, so that the workload of software development is increased, and further the development efficiency is reduced.

In order to solve the above problem, the present application provides a policy implementation calling method. Referring to fig. 1, fig. 1 illustrates a policy-implemented calling method according to an exemplary embodiment of the present application. As shown in fig. 1, the method is applied to a policy implementation caller, and may include the following steps:

step 102, when detecting a calling operation of a user for a target policy implementation, determining a policy implementation type of the target policy implementation; wherein, the logic of the target policy implementation is matched with the extension interface specified by the policy implementation caller, and the mapping relation between any policy implementation and the provider of any policy implementation is recorded in the statistical center corresponding to the policy implementation type of any policy implementation.

In the related art, the policy implementation is only able to invoke the policy implementation stored locally on the policy implementation invoking party due to the limitation of the extension interface (also called extension point), and usually, a corresponding extension interface is written for the policy type to invoke the corresponding policy implementation under the condition of determining the policy type of the policy implementation. The calling process is tedious and cannot call the policy implementation which is not stored locally.

The policy implementation caller in the present application refers to: the body of policy implementation needs to be invoked during software development. For convenience, the policy implementation caller is hereinafter referred to simply as the "caller". In different scenarios, the caller may be a different subject, for example, a programming device (e.g., a PC, a mobile terminal, etc.), or a JVM (Java virtual machine). The specific form of the caller can be determined according to actual conditions, and is not limited herein.

The policy-implemented provider in this application refers to: a body of policy implementation is maintained that is written and can be invoked by a caller. For convenience of description, the policy implementation provider is hereinafter referred to simply as "provider". Similar to the caller, the provider of policy implementation may also be a different subject, for example, a programming device (e.g., PC, mobile terminal, etc.), a JVM (Java virtual machine), or an application. The specific form of the provider can be determined according to actual conditions, and is not limited herein.

It is to be noted that the target policy implementation in the present application is any one of the policy implementations provided by the policy implementation provider (remote provider or local provider), and these policy implementations are developed by adapting the extended interface provided by the policy implementation caller, which makes it unnecessary to develop the extended interface for the policy implementation that needs to be invoked in the subsequent invocation process.

In the present application, the subjects serving as the caller and the provider may be determined in advance. For example, when there are 3 subjects A, B, C, a may be used as a caller in advance, and A, B, C may be used as a provider. Where A may be considered a local provider and B and C may be considered remote providers.

In the process of calling policy implementation by a caller, a policy implementation type of the policy implementation to be called, that is, a policy implementation type of a target policy implementation, needs to be determined first. The policy implementation type is used for representing a calling mode of policy implementation, such as a local calling class or a remote calling class; the policy implementation type also reflects the identity type of the provider of the policy implementation, and the local invocation class indicates that the policy implementation is provided by the local provider; and the remote provider indicates that the policy implementation is provided by the remote provider.

The policy implementation type for determining policy implementation may be determined by looking up a registry in the caller, where a corresponding relationship between each policy implementation and its respective policy implementation type is stored in the registry. For example, assume that there are 4 policy implementations: A. b, C, D, the registry may be as shown in table 1:

policy implementation	A	B	C	D
					Policy implementation type	Remote invocation class	Native call class	Native call class	Remote invocation class

TABLE 1

As can be seen from Table 1, the policy implementation A and D in this table are remote invocation classes; policy implementations B and C are local call classes. When the caller wants to invoke A, B, C, D any policy implementation, the policy implementation type of any policy implementation can be determined from the registry as described in Table 1. It should be noted that the fact that the registry records the policy implementation and policy implementation type correspondence does not mean that the registry records the source code of the policy implementation, and actually the mapping relationship recorded in the registry usually represents the policy implementation by the identifier of the policy implementation, and the source code of the policy implementation needs to be called from the provider.

The corresponding relation between each policy implementation recorded in the registry of the caller and the policy implementation type of each policy implementation can be obtained by pushing through a predetermined configuration center. For example, the call direction configuration center may subscribe to the push of the correspondence. At this time, when the caller starts, the configuration center can push the corresponding relationship between each policy implementation of the local record and the respective policy implementation type to the caller, and the caller records the corresponding relationship in the registry. The corresponding relation between each policy implementation in the configuration center and the respective policy implementation type can be uploaded by each provider.

After the caller is started, the caller can also monitor the change condition of the corresponding relation between the policy implementation and the policy implementation type of the caller in the configuration center to determine whether the corresponding relation to be updated exists; and updating the registry according to the corresponding relation between the strategy implementation to be updated and the strategy implementation type under the condition that the corresponding relation to be updated exists. If a certain provider uploads the corresponding relationship between the newly uploaded policy implementation and the affiliated policy implementation type to the configuration center after the caller starts, at this time, the caller can obtain the corresponding relationship between the newly uploaded policy implementation and the affiliated policy implementation type and record the corresponding relationship between the newly uploaded policy implementation and the affiliated policy implementation type into the registry.

In the application, the logic of the target policy implementation is matched with the extension interface specified by the caller, so that the caller can execute the target policy implementation based on the existing extension interface when calling the target policy implementation. In one case, the policy-implemented logic provided by each provider may be matched to the caller-specified extended interface. In actual operation, each provider can create a policy implementation according to the extended interface provided by the caller, so that the logic of the policy implementation created by each provider matches with the specified extended interface.

In the present application, the mapping relationship of any policy implementation to its provider is recorded in the statistical center corresponding to the policy implementation type of the any policy implementation. In other words, after determining the policy implementation type of the target policy implementation, a provider of the target policy implementation may be searched at a statistical center corresponding to the policy implementation type, so as to invoke the target policy implementation from the searched provider. Taking table 1 as an example for explanation, if the target policy implementation at this time is policy implementation a, it can be known from table 1 that the policy implementation type corresponding to policy implementation a is a remote invocation type; then, the provider of the policy implementation a may be determined according to a mapping relationship between each policy implementation recorded in the statistics center corresponding to the remote invocation class and the remote provider.

According to the above, by recording the mapping relationship between the provider with different identity types and the policy implementation in different statistical centers, the policy implementation of different policy implementation types can be classified and managed.

And 104, acquiring a provider for realizing the target strategy inquired by a target statistical center according to the recorded mapping relation, wherein the target statistical center is a statistical center corresponding to the determined strategy realization type.

As described above, the callers may be different principals; and the policy implementation type of the policy implementation is related to the identity type of the provider. In one case, the caller may comprise a Java virtual machine and the identity type of the provider may comprise a native application of the Java virtual machine and a remote provider distinct from the native application. The policy implementation provided by the local application program is recorded in a Spring container of the Java virtual machine, and the mapping relationship between each remote provider and the policy implementation provided by each remote provider is recorded in a Dobbu registry. In other words, in this case, the statistical center is a Spring container or a Dobbu registry.

In one case, the provider of the target policy implementation is the native application. In this case, it may be determined whether or not the target policy implementation is recorded in the Spring container, and if so, the local application may be used as a provider of the target policy implementation.

In another case, the provider of the targeted policy implementation is a remote provider. In this case, the mapping relationship between each remote provider recorded by the Dobbu registry and the policy implementation provided by each remote provider may be obtained, and the provider implemented by the target policy may be queried according to the obtained mapping relationship. In one case, a query request for the target policy implementation may be sent to the Dobbu registry in real time, so that the Dobbu registry queries a remote provider providing the target policy implementation according to the recorded mapping relationship, and takes a query result of the Dobbu registry as the provider for the target policy implementation; in another case, mapping relationships between the respective remote providers and the policy implementations respectively provided by the remote providers recorded in the Dobbu registration center may be cached locally in advance, and in a case that the provider of the target policy implementation is determined to be the remote provider, which remote provider the target policy implementation is provided by is determined according to the mapping relationship cached locally.

The mapping relation recorded in the Dobbu registration center is determined by a provider realized by each strategy, and then the provider belongs to a remote provider and is registered in the Dobbu registration center; the identity type of the provider realized by each strategy is determined by the annotation information carried by each strategy realization in the starting process of the corresponding provider.

Step S106, initiating the call aiming at the target policy realization to the provider of the target policy realization so as to execute the target policy realization through the expansion interface.

In the present application, the logic implemented due to the target policy matches the extension interface specified by the caller. Therefore, after the provider with the determined calling direction initiates a calling request, the target policy to be called can be executed through the extended interface.

According to the technical scheme, under the condition that the call request for realizing the target strategy is detected, the provider for realizing the target strategy can be determined from the corresponding statistical center based on the strategy realization type of the target strategy realization, and the target strategy realization can be called from the determined strategy realization provider. The scheme enables a policy implementation caller to accurately position the provider for implementing the policy, and further implements the invocation of the policy implementation provided by different providers.

Furthermore, the logic of the target strategy implementation in the application is matched with the extension interface appointed by the strategy implementation calling party, so that the calling party does not need to establish the extension interface matched with the target strategy implementation in real time based on the logic of the target strategy implementation, and the software development efficiency is improved

Furthermore, a remote registry is introduced, and the logic for realizing the strategy provided by the remote provider is matched with the expansion interface specified by the calling party for realizing the strategy, so that a developer can directly call the strategy of the remote provider to realize the strategy in the process of calling the strategy, and the number of the called strategies is increased.

The functions of the above-mentioned roles in the technical solutions of the present specification are described in detail below with reference to the accompanying drawings. Fig. 2 is a flowchart illustrating another policy-implemented invocation method according to an exemplary embodiment of the present application. Referring to fig. 2, a policy implementation calling method implemented by the Java virtual machine is described as follows.

In this embodiment, the Java virtual machine as the caller may publish its own proprietary extended interface, and then each Java virtual machine as the provider may perform policy implementation creation according to the proprietary extended interface of the caller.

As can be seen from fig. 2, the present solution mainly includes the following steps:

firstly, a policy implementation calling party subscribes a corresponding relation between each policy implementation and a calling mode (namely the policy implementation type) to a configuration center in advance.

Secondly, in the process of starting the strategy implementation caller, the strategy implementation caller receives the corresponding relation between each strategy implementation and the calling mode pushed by the configuration center and records the corresponding relation in a local registry; when detecting a call request for the target policy implementation, the policy implementation caller may search for a call mode for the target policy implementation in the registry according to the policy implementation identifier included in the call request.

When the target strategy determined in the step (III) is realized as a local calling class, the strategy realization calling party inquires the target strategy realization in the local Spring container, and after receiving the inquiry result of the Spring container in the step (IV), the target strategy realization is called from the local application program in the step (IV). When the target strategy determined in the step (III) is realized as a remote calling class, the strategy realizing caller searches which Java virtual machine provides the target strategy realization in the Dobbu registration center, and after the query result is returned in the step (IV), the target strategy realization is called from the determined Java virtual machine in the step (IV).

For convenience of understanding, the steps three, four and five are introduced for two cases of policy implementation for calling the local call class and policy implementation for calling the remote call class.

1. Policy implementation of invoking local invocation classes

Referring to fig. 3, fig. 3 is a flow chart illustrating a method for invoking a local call class policy implementation according to an exemplary embodiment of the present application. As shown in fig. 3, the method may include the steps of:

step 301, when it is determined that the target policy implementation is the local call class, querying the policy implementation identifier provided by the local application program and recorded in the local Spring container.

In this embodiment, the target policy implementation is determined to be a local invocation class, i.e., the target policy implementation is said to be saved in the local Java virtual machine that is the caller of the policy implementation. In practice, the local policy implementation is typically stored in the local application and thus needs to be invoked from the local application.

In the Spring container, a policy implementation identifier and an extension interface corresponding to the policy implementation identifier are stored. The local Java virtual machine can inquire a strategy implementation identifier corresponding to the target strategy implementation, and then call the target strategy implementation according to the strategy implementation identifier.

It is noted that fig. 2 illustrates the Spring container, although independent from the policy implementation invoker, in actual cases, the Spring container is a part of the policy implementation invoker. Similarly, the local application in FIG. 2 is also part of the caller of the policy implementation.

Step 302, determining the identifier corresponding to the target policy implementation from the Spring query.

Step 303, based on the determined identity, a target policy implementation is invoked from the target local application and executed through the specified extended interface.

In this embodiment, the logic of the policy implementation stored locally matches the extended interface specified by the local Java virtual machine. Thus, after a target policy implementation is invoked from a target application, the target policy implementation can be executed directly through the specified extended interface.

According to the scheme, the policy identifier corresponding to the target policy implementation can be found in the Spring container, and then the policy implementation stored in the local can be called. Furthermore, because the logic of the policy implementation stored in the local application is matched with the Java virtual machine as the caller of the policy implementation, the creation of the extension interface for the policy implementation is not required in the calling process.

2. Policy implementation of invoking remote invocation classes

Referring to fig. 4, fig. 4 is an interaction diagram illustrating an implementation of invoking a remote invocation class policy according to an exemplary embodiment of the present application. As shown in fig. 4, the method may include the steps of:

in step 401, the caller determines that the target policy implementation is a remote policy implementation class.

Step 402, the caller sends a provider query to the Dobbu registry.

In the present embodiment, the Java virtual machines other than the local Java virtual machine as the policy implementation invoker function as remote providers. In the starting process, the remote provider registers the mapping relation between the identification realized by the policy provided by the remote provider and the identity of the remote provider into the Dobbu registry. For example, if the Java virtual machine 2 is a remote provider, the Java virtual machine 2 may implement the policy provided by itself and upload the identity information of itself to the Dobbu registry during the starting process; similarly, the Java virtual machines 3 and 4 as other remote providers perform the same operation. For example, the mapping relationship stored in the Dobbu center may be as shown in table 2:

policy implementation	A	B	C	D
					Remote provider	Java virtual machine 2	Java virtual machine 2	Java virtual machine 3	Java virtual machine 4

TABLE 2

As can be seen from Table 2, policy implementations A and B are provided by Java virtual machine 2; policy implementation C is provided by Java virtual machine 3; policy implementation D is provided by Java virtual machine 4.

Step 403, the Dobbu registration center realizes the corresponding relation between each policy for querying the local record and the provider thereof.

As can be seen from the introduction in step 402, the Dobbu registry records the corresponding relationship between each policy implementation and its provider. And the registry can determine the corresponding remote provider according to the identifier of the target policy implementation in the query request sent by the provider. Continuing to take table 2 as an example, if the target policy to be invoked this time is implemented as policy implementation a, the Dobbu registry may query that policy implementation a is provided by the Java virtual machine 2 according to the identifier a implemented by the policy.

And step 404, after the Dobbu registry inquires the Java virtual machine providing the target policy implementation, returning the result to the caller.

In this embodiment, after receiving a query result returned by the Dobbu registry, the caller may determine a provider providing the target policy implementation, and call the target policy implementation from the provider. Taking the above example in mind, in step 403, policy implementation a is determined to be the target policy implementation, and its provider is Java virtual machine 2. Then this step may send a call request to the Java virtual machine 2 to invoke policy implementation a.

And step 405, the caller receives the query result returned by the Dobbu registration center and sends a policy implementation call request to the target Java virtual machine in the query result.

In this step, the policy implementation invocation request sent to the target Java virtual machine includes an identifier of the target policy implementation.

In step 406, the target Java virtual machine returns the target policy implementation to the caller.

Step 407, the caller receives the target policy implementation returned by the target Java virtual machine, and executes the target policy implementation based on the specified extended interface.

In this embodiment, the logic of policy implementation created by each remote provider is matched with the extension interface specified by the caller, so that after the target policy implementation returned by the received target Java virtual machine is implemented, the received target policy implementation can be executed through the extension interface specified by the caller.

According to the technical scheme, the policy implementation provided by each remote provider is registered in the Dobbu registration center in advance, so that the policy implementation caller can inquire the provider needing to call the policy implementation from the Dobbu registration center under the condition that the remote policy implementation is required to be called, and further can initiate a call request to the inquired policy implementation provider to implement the call of the non-local policy implementation.

Furthermore, because the logic of the policy implementation created by each remote provider is matched with the extension interface specified by the caller, when the non-local policy implementation is called, the corresponding extension interface is not required to be written according to the non-local policy implementation, and the software development efficiency of developers is improved.

FIG. 5 shows a schematic block diagram of an electronic device according to an exemplary embodiment of the present application. Referring to fig. 5, at the hardware level, the electronic device includes a processor 502, an internal bus 504, a network interface 506, a memory 508 and a non-volatile memory 510, but may also include hardware required for other services. The processor 502 reads the corresponding computer program from the non-volatile memory 510 into the memory 508 and runs it, forming a policy-implemented calling device on a logical level. Of course, besides the software implementation, the present application does not exclude other implementations, such as logic devices or a combination of software and hardware, and the like, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.

Referring to fig. 6, in a software implementation, the policy-implemented invoking device may include:

a determining unit 601, configured to determine a policy implementation type of a target policy implementation when a call operation of a user for the target policy implementation is detected; wherein, the logic of the target policy implementation is matched with the extension interface specified by the policy implementation caller, and the mapping relation between any policy implementation and the provider of any policy implementation is recorded in the statistical center corresponding to the policy implementation type of any policy implementation;

an obtaining unit 602, configured to obtain a provider for implementing the target policy, where the provider is queried by a target statistics center according to a recorded mapping relationship, where the target statistics center is a statistics center corresponding to the determined policy implementation type;

a calling unit 603, configured to initiate a call for the target policy implementation to a provider of the target policy implementation, so as to execute the target policy implementation through the extended interface.

Optionally, the determining unit is specifically configured to:

and determining the strategy implementation type of the target strategy implementation according to the registry of the strategy implementation caller, wherein the registry records the corresponding relation between each strategy implementation and the strategy implementation type of each strategy implementation.

Optionally, the corresponding relationship between each policy implementation recorded by the registry and the policy implementation type to which each policy implementation belongs is obtained by pushing from a configuration center; and the corresponding relation between each policy implementation recorded in the configuration center and the respective affiliated policy implementation type is uploaded by a provider for implementing each policy.

Optionally, the method further includes:

an updating unit 604, configured to determine whether a corresponding relationship to be updated exists between policy implementation and a corresponding policy implementation type in the configuration center; and if so, updating the registry according to the corresponding relation to be updated.

Optionally, the policy implementation invoker includes a Java virtual machine, and the policy implementation type of each policy implementation is associated with an identity type of a respective provider, where the identity type includes a local application of the Java virtual machine and a remote provider different from the local application.

Optionally, mapping relationships between the remote providers and the policy implementations provided by the remote providers are recorded in the Dobbu registry;

when the provider of the target policy implementation is the local application, the obtaining unit 502 is specifically configured to: using the local application as a provider of the target policy implementation;

when the provider that implements the target policy is a remote provider, the obtaining unit 502 is specifically configured to: and acquiring the mapping relation between each remote provider recorded by the Dobbu registration center and each provided policy, and inquiring the provider for realizing the target policy according to the acquired mapping relation.

Optionally, the provider that implements the mapping relationship recorded in the Dobbu registration center by each policy determines that the provider belongs to a remote provider and then registers the mapping relationship in the Dobbu registration center; and the identity type of the provider realized by each strategy is determined by the corresponding provider according to the annotation information carried by each strategy realization in the starting process.

The implementation process of the functions and actions of each unit in the above device is specifically described in the implementation process of the corresponding step in the above method, and is not described herein again.

For the device embodiments, since they substantially correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points. The above-described embodiments of the apparatus are merely illustrative, and the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of the application. One of ordinary skill in the art can understand and implement it without inventive effort.

In an exemplary embodiment, there is also provided a non-transitory computer readable storage medium, e.g. a memory, comprising instructions executable by a processor of a policy-implemented calling device to implement a method as described in any of the above embodiments, such as the method may comprise: when detecting a calling operation of a user for a target policy implementation, determining a policy implementation type of the target policy implementation; wherein, the logic of the target policy implementation is matched with the extension interface specified by the policy implementation caller, and the mapping relation between any policy implementation and the provider of any policy implementation is recorded in the statistical center corresponding to the policy implementation type of any policy implementation; acquiring a provider for realizing the target strategy inquired by a target statistical center according to the recorded mapping relation, wherein the target statistical center is a statistical center corresponding to the determined strategy realization type; initiating a call to a provider of the target policy implementation for the target policy implementation to execute the target policy implementation through the extended interface.

The non-transitory computer readable storage medium may be a ROM, a Random Access Memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc., which is not limited in this application.

The above description is only exemplary of the present application and should not be taken as limiting the present application, as any modification, equivalent replacement, or improvement made within the spirit and principle of the present application should be included in the scope of protection of the present application.

Claims

1. A policy-implemented calling method applied to a policy-implemented caller, the method comprising:

2. The method of claim 1, wherein determining a policy implementation type for a target policy implementation comprises:

3. The method according to claim 2, wherein the correspondence between each policy implementation of the registry record and its respective policy implementation type is pushed by a configuration center; and the corresponding relation between each policy implementation recorded in the configuration center and the respective affiliated policy implementation type is uploaded by a provider for implementing each policy.

4. The method of claim 3, further comprising:

determining whether a corresponding relation to be updated exists between the strategy implementation and the corresponding strategy implementation type in the configuration center;

and if so, updating the registry according to the corresponding relation to be updated.

5. The method of claim 1, wherein the policy implementation invoker comprises a Java virtual machine, and wherein each policy implementation type is associated with an identity type of the respective provider, the identity types including a native application of the Java virtual machine and a remote provider distinct from the native application.

6. The method of claim 5, wherein the mapping relationship between each remote provider and each provided policy implementation is recorded in a Dobbu registry;

when the provider for implementing the target policy is the local application program, the obtaining the provider for implementing the target policy, which is queried by the target statistics center according to the recorded mapping relationship, includes: using the local application as a provider of the target policy implementation;

when the provider for realizing the target policy is a remote provider, the acquiring target statistics center queries the provider for realizing the target policy according to the recorded mapping relationship, and the acquiring target statistics center includes: and acquiring the mapping relation between each remote provider recorded by the Dobbu registration center and each provided policy, and inquiring the provider for realizing the target policy according to the acquired mapping relation.

7. The method of claim 6, wherein the provider implemented by each policy determines that the mapping relationship recorded in the Dobbu registry belongs to a remote provider and registers the mapping relationship in the Dobbu registry; and the identity type of the provider realized by each strategy is determined by the corresponding provider according to the annotation information carried by each strategy realization in the starting process.

8. A policy-implemented invoking device, for application to a policy-implemented caller, the device comprising:

9. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method of any one of claims 1-7 by executing the executable instructions.

10. A computer-readable storage medium having stored thereon computer instructions, which when executed by a processor, perform the steps of the method according to any one of claims 1-7.