CN114756306A

CN114756306A - Service calling method, device, equipment and storage medium

Info

Publication number: CN114756306A
Application number: CN202210334389.8A
Authority: CN
Inventors: 杨俊拯
Original assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd
Current assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd
Priority date: 2022-03-30
Filing date: 2022-03-30
Publication date: 2022-07-15
Also published as: WO2023185166A1

Abstract

The embodiment of the application discloses a service calling method, a service calling device, service calling equipment and a storage medium, and belongs to the technical field of computers. The method comprises the following steps: the first equipment identifies the first input instruction to obtain a first instruction identification result; generating a service calling request based on the first instruction identification result, wherein the service calling request is used for requesting the second equipment to call the target service so as to execute the target action; and sending a service calling request to the second equipment so as to enable the second equipment to deploy the target service based on the target service installation package, and calling the target service to execute the target action, wherein the target service installation package is obtained from the server. By adopting the scheme provided by the embodiment of the application, even if the second equipment does not have the instruction identification function, the instruction-based service calling can be realized, and the second equipment can realize the dynamic deployment of the target service based on the service calling request, so that the memory occupation caused by the pre-deployment of a large number of services is avoided.

Description

Service calling method, device, equipment and storage medium

Technical Field

The embodiment of the application relates to the technical field of computers, in particular to a service calling method, a service calling device, service calling equipment and a storage medium.

Background

The instruction control is a technology for identifying and analyzing a user instruction and controlling equipment to execute corresponding operation according to the identification and analysis result. Common command controls include gesture controls, voice controls, and the like.

In the related art, the computer device needs to have an instruction recognition function, and needs to deploy a corresponding service in advance to realize an instruction control function. For example, when the vehicle-mounted terminal has voice recognition and is deployed with a video playing function, video playing can be performed according to a voice instruction sent by a user.

Disclosure of Invention

The embodiment of the application provides a service calling method, a service calling device, service calling equipment and a storage medium. The technical scheme is as follows:

in one aspect, an embodiment of the present application provides a service invocation method, where the method is executed by a first device, and the method includes:

identifying the first input instruction to obtain a first instruction identification result;

generating a service calling request based on the first instruction identification result, wherein the service calling request is used for requesting a second device to call a target service to execute a target action;

sending the service calling request to the second device to enable the second device to deploy the target service based on a target service installation package and call the target service to execute the target action, wherein the target service installation package is obtained from a server.

In another aspect, an embodiment of the present application provides a service invocation method, where the method is executed by a second device, and the method includes:

receiving a service calling request sent by first equipment, wherein the service calling request is used for requesting to call a target service to execute a target action, and the service calling request is generated by the first equipment based on a first instruction identification result of a first input instruction;

acquiring a target service installation package of the target service from a server based on the service calling request;

deploying the target service based on the target service installation package;

and calling the target service to execute the target action.

On the other hand, an embodiment of the present application provides a service invocation device, where the device includes:

the instruction identification module is used for identifying the first input instruction to obtain a first instruction identification result;

a request generation module, configured to generate a service invocation request based on the first instruction identification result, where the service invocation request is used to request a second device to invoke a target service to execute a target action;

a request sending module, configured to send the service invocation request to the second device, so that the second device deploys the target service based on a target service installation package, and invokes the target service to execute the target action, where the target service installation package is obtained from a server.

the device comprises a request receiving module, a service calling module and a service processing module, wherein the request receiving module is used for receiving a service calling request sent by first equipment, the service calling request is used for requesting to call a target service to execute a target action, and the service calling request is generated by the first equipment based on a first instruction identification result of a first input instruction;

the installation package obtaining module is used for obtaining a target service installation package of the target service from a server based on the service calling request;

a service deployment module for deploying the target service based on the target service installation package;

and the execution module is used for calling the target service to execute the target action.

In another aspect, an embodiment of the present application provides a computer device, which includes a processor and a memory; the memory stores at least one instruction for execution by the processor to implement a service invocation method as described in the preceding aspect.

In another aspect, an embodiment of the present application provides a computer-readable storage medium, in which at least one program code is stored, and the program code is loaded and executed by a processor to implement the service invocation method according to the above aspect.

In another aspect, the present application provides a computer program product or a computer program, which includes computer instructions stored in a computer readable storage medium. The computer instructions are read by a processor of the computer device from a computer-readable storage medium, and the computer instructions are executed by the processor to cause the computer device to perform the service invocation method provided in the various alternative implementations of the above-described aspects.

In the embodiment of the application, the first device with the instruction identification function identifies the input instruction, sends a service calling request to the second device based on the instruction identification result, and instructs the second device to call the target service to execute the target action, so that the second device can obtain the target service installation package from the server based on the service calling request and deploy the target service, and then calls the target service to execute the target action. By adopting the scheme provided by the embodiment of the application, even if the second device does not have the instruction identification function, the instruction-based service calling can be realized, and the second device can realize the dynamic deployment of the target service based on the service calling request, so that the memory occupation caused by the pre-deployment of a large number of services is avoided.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.

FIG. 1 illustrates a system architecture diagram of a service invocation system provided by an exemplary embodiment of the present application;

FIG. 2 illustrates a flow chart of a method for service invocation provided by an exemplary embodiment of the present application;

FIG. 3 is a diagram illustrating an implementation of a service invocation method according to an exemplary embodiment of the present application;

FIG. 4 is a schematic diagram illustrating an implementation of a service definition and installation package uploading process according to an exemplary embodiment of the present application;

FIG. 5 illustrates a flow chart of a method for service invocation provided by another exemplary embodiment of the present application;

FIG. 6 is a flow diagram illustrating a text parsing process in accordance with an exemplary embodiment of the present application;

FIG. 7 is a schematic diagram illustrating an implementation of a dynamic service deployment process according to an exemplary embodiment of the present application;

FIG. 8 is a schematic diagram illustrating an implementation of a service update process according to an exemplary embodiment of the present application;

FIG. 9 is a flow chart illustrating a service offload process according to an exemplary embodiment of the present application;

FIG. 10 is a schematic diagram illustrating an implementation of a service offload process in accordance with an exemplary embodiment of the present application;

fig. 11 is a block diagram illustrating a structure of a service invocation apparatus according to an embodiment of the present application;

fig. 12 is a block diagram illustrating a structure of a service invocation apparatus according to another embodiment of the present application;

fig. 13 is a block diagram illustrating a computer device according to an exemplary embodiment of the present application.

Detailed Description

To make the objects, technical solutions and advantages of the present application more clear, embodiments of the present application will be described in further detail below with reference to the accompanying drawings.

For convenience of understanding, terms referred to in the embodiments of the present application will be described below.

Service: the minimum unit for implementing a specific task. For example, the screen capture service is used for implementing a screen capture function of the device, the video playing service is used for playing video, and the like. Moreover, when the service is called, the device may call the service deployed locally, or call the service deployed on another device (i.e., cross-terminal call). For example, the first device may invoke a local video playing service to play a video, or may invoke a video playing service of the second device, so as to implement video playing on the second device.

Unlike the traditional service that needs to be deployed in advance (if not, the corresponding function cannot be implemented), the service related in the embodiment of the present application supports dynamic deployment. Under the condition of receiving a service calling request, if corresponding service is locally deployed, directly calling; if the corresponding application is not deployed locally, the service installation package can be obtained dynamically, and service deployment is completed based on the service installation package. In addition, unlike the traditional service which needs to be manually installed or uninstalled, the service in the embodiment of the application supports automatic uninstallation, and the operation flow of installing and uninstalling the service is simplified.

In some embodiments, the services may include static services and dynamic services, where the static services refer to services provided by the hosting application and need to be pre-installed in the device, and the dynamic services refer to services supporting dynamic deployment and may be dynamically deployed in the device during the invocation process. Optionally, the service installation package of the dynamic service is stored in a server, and the device may download the service installation package from the server.

Fig. 1 is a system diagram illustrating a system architecture of a service invocation system according to an exemplary embodiment of the present application, where the system architecture includes a first device 110, a second device 120, and a server 130.

The first device 110 is an electronic device having an instruction recognition function. The instruction recognition function may be a voice recognition function, a gesture recognition function, a text recognition function, and the like, and the electronic device may be a smart phone, a tablet computer, a wearable device, a personal computer, a vehicle-mounted terminal, and the like, which is not limited in this embodiment.

In some embodiments, with the help of the voice recognition function, the first device 110 may convert the input voice into a voice text through the voice recognition module 111, and parse the voice text through the text parsing module 112 to obtain a voice recognition result (for representing the intention of the user).

Further, when the voice recognition result indicates that the service of the external device is called so that the external device performs a specific action, the first device 110 determines the external device (i.e., the second device 120 in the drawing) that needs to be called through the device selection module 113, and generates a service calling request based on the voice recognition result, thereby transmitting the service calling request to the external device. Wherein the number of external devices is at least one.

The second device 120 is an electronic device supporting a dynamic deployment service, and the electronic device may be a smartphone, a tablet computer, a wearable device, a personal computer, a vehicle-mounted terminal, or the like, which is not limited in this implementation.

In some embodiments, the second device 120 is provided with a service agent 121, and when receiving the service invocation request sent by the first device 110 through the service agent 121, first, through the service management module 122, it is queried whether the first service indicated by the service invocation request is deployed locally. The service life cycle management module 123 is configured to manage life cycles of the services in the device, and if the target service is deployed, the service life cycle management module 123 controls the service execution module 125 to invoke the target service to execute a specific action. If the target service is not deployed, the service management module 122 downloads a service installation package corresponding to the target service from the server 130 and stores the service installation package locally; the service installation module 124 deploys the target service according to the service installation package under the control of the service lifecycle management module 123. The service life cycle management module 123 is responsible for controlling the service installation and execution, and also controls the service uninstalling module 126 to uninstall the deployed service according to the policy, so as to avoid the device deploying too many services.

The server 130 is a server, a service cluster composed of a plurality of servers, or a cloud computing center. The server 130 includes a service definition management module 131, a service installation package management module 132, a subscription management module 133, a device management module 134, and a service gateway 135, which are divided according to the implemented functions.

The service gateway 135 acts as a portal for external devices to interact with the server for dynamically routing the accessed traffic to the designated management modules.

The service definition management module 131 is configured to manage service definition information of a service developed by a developer, and associate the service definition information with a corresponding service installation package, so as to obtain the corresponding service installation package based on the service definition information in the following.

The service installation package management module 132 is configured to manage the service installation packages of the services developed by the developers and store the service installation packages in the file repository.

The subscription management module 123 is configured to manage a subscription relationship between a device and a service, so as to control the device to perform service update based on the subscription relationship.

The device management module 134 is configured to manage a binding relationship between the account and the device and a device state of each device, and provide a device selection basis for the device selection module 113 on the first device 110 side.

It should be noted that, the foregoing embodiment only illustrates the infrastructure of the service invocation system, and the system may further include other computer devices (such as developer devices) or servers that implement other functions, and this embodiment does not limit this.

Referring to fig. 2, a flowchart of a service invocation method provided in an exemplary embodiment of the present application is shown, where in the embodiment of the present application, taking an example that the method is applied to the service invocation system shown in fig. 1 as an example, the method includes:

step 201, the first device identifies the first input instruction to obtain a first instruction identification result.

Optionally, the first input instruction may be a voice instruction, a gesture instruction, a text instruction, or the like, and the form of the input instruction is not limited in the embodiments of the present application.

In some embodiments, the first device has a voice collecting function, and when the first input voice is collected by a voice collecting device such as a microphone, the first device performs voice recognition on the first input voice to obtain a first voice recognition result, where the first voice recognition result is used to represent the voice control intention. Regarding the process of voice recognition, in one possible implementation, the first device first converts the input voice into a voice text, then parses the voice text, and determines parameters required for generating the service invocation request as a voice recognition result.

In other embodiments, the first device has an image capturing function, and when the first gesture is captured by the image capturing device such as a camera, the first device performs gesture recognition on the first gesture, so that a first gesture recognition result is obtained based on a mapping relationship between the gesture and the control instruction, and the first gesture recognition result is used for representing a control intention represented by the gesture.

In still other embodiments, the first device has a text input function, and when the first input text input by the user is acquired through the text input component, the first device recognizes the first input text to acquire a first text recognition result, where the first text recognition result is used for representing a control intention of the input text.

Optionally, the first instruction identification result includes parameters required for generating the service invocation request.

In step 202, the first device generates a service call request based on the first instruction recognition result.

Wherein the service invocation request is for requesting the second device to invoke the target service to perform the target action.

In a possible implementation manner, the service invocation request may be a service invocation url, and the embodiment of the present application does not limit a specific form of the service invocation request.

Illustratively, as shown in fig. 3, the smartphone 31 generates a service invocation request for requesting the car machine to invoke the video playing service to play the xxx video, based on the voice recognition result of "play the xxx video on the car machine".

Step 203, the first device sends a service invocation request to the second device.

In a possible implementation manner, after determining a second device to be called, the first device obtains a device address of the second device, and sends a service call request to the second device based on the device address.

In some embodiments, when the number of the second devices is at least two, the first device sends a service invocation request to each of the second devices, where different second devices correspond to different service invocation requests (some parameters in the request are different, but all of the parameters are used for invoking the same service to perform the same action).

Schematically, as shown in fig. 3, the smart phone 31 sends a service invocation request to the car machine 32.

Step 204, the second device receives the service call request sent by the first device.

In one possible implementation, the second device receives the service invocation request through a service proxy.

In some embodiments, the second device verifies the service invocation request and further responds to the service invocation request after passing the verification. The verification method includes request integrity verification, call requester verification, parameter compliance verification, and the like, which is not limited in the embodiments of the present application.

Optionally, after receiving the service invocation request, the second device automatically determines whether to accept the request, or determines whether to accept the request based on a user instruction. If the request is accepted, go to step 205; if the request is not accepted, the flow ends (a notification of call rejection may be sent to the first device).

In step 205, the second device obtains a target service installation package of the target service from the server based on the service invocation request.

In one possible implementation, the second device detects whether a target service indicated by the service invocation request is deployed. If the target service is deployed, service calling is carried out; if the target service is not deployed, the target service needs to be dynamically deployed first.

When the target service is dynamically deployed, the second device first obtains a target server installation package of the target service from the server. The server is provided with a file warehouse, and the file warehouse comprises a service installation package which realizes different functions and supports dynamic service of dynamic deployment.

With respect to the origin of the service in the server, in one possible implementation, the service support is developed by a developer and uploaded to the server.

As shown in fig. 4, the developer uploads the service installation package to the server 130 by calling the upload interface of the service installation package management module 132 through the service gateway 135 of the server 130. The successfully uploaded service installation package is stored in the file repository in association with the unique installation package identifier, and the service installation package management module 132 feeds back the installation package identifier to the developer.

Further, the developer associates the service definition information of the service with the installation package identifier, and then calls the upload interface of the service definition management module 131 through the service gateway 135 to store the service definition information in the server 130.

In a possible implementation manner, the second device sends an installation package obtaining request to the server, and after receiving the request, the service gateway of the server routes the request to the service installation package management module, and obtains the target service installation package from the file repository, so as to feed back the target service installation package to the second device.

Illustratively, as shown in fig. 3, when the video playing service is not deployed, the car machine 32 downloads the video playing service installation package from the server 33.

In step 206, the second device deploys the target service based on the target service installation package.

In a possible implementation manner, the second device verifies the acquired target service installation package, and performs dynamic deployment of the target service based on the target service installation package after the verification is passed.

Step 207, the second device invokes the target service to perform the target action.

Further, the second device determines a target action indicated by the service invocation request, thereby invoking the target service to perform the target action.

Illustratively, as shown in fig. 3, the car machine 32 determines the target action as "play xxx video", so as to invoke the video playing service to play xxx video.

As is apparent from the embodiment shown in fig. 3, under the condition that the in-vehicle device does not have a voice control function, a smart phone with a voice recognition function can also be used as a scheduling center to implement voice call of the service in the in-vehicle device; under the condition that the vehicle machine has the voice control function, the influence on other services when the vehicle machine frequently performs voice recognition can be avoided (the performance of the vehicle machine is usually lower than that of a smart phone, and the vehicle machine needs to call important services related to vehicle running in real time). In addition, the car machine can dynamically deploy the service under the condition of receiving the service calling request, and content occupation (especially some services with lower use frequency) caused by service deployment in advance can be avoided.

In summary, in the embodiment of the present application, a first device having an instruction recognition function recognizes an input instruction, and sends a service call request to a second device based on an instruction recognition result, and instructs the second device to call a target service to execute a target action, so that the second device can obtain a target service installation package from a server based on the service call request and deploy the target service, thereby calling the target service to execute the target action. By adopting the scheme provided by the embodiment of the application, even if the second equipment does not have the instruction identification function, the instruction-based service calling can be realized, and the second equipment can realize the dynamic deployment of the target service based on the service calling request, so that the memory occupation caused by the pre-deployment of a large number of services is avoided.

Referring to fig. 5, a flowchart of a service invocation method provided by another exemplary embodiment of the present application is shown, where the embodiment of the present application takes the application of the method to the service invocation system shown in fig. 1 as an example to explain, the method includes:

step 501, the first device identifies a first input instruction to obtain a first instruction identification result.

Optionally, the first instruction identification result includes a name of a target device of the device to be called, a name of a target service of the target service to be called, and a name of a target action of the target action.

In one possible embodiment, as shown in fig. 6, the first device performs text parsing pre-configuration first, so that text parsing is performed based on pre-configured content during application.

The content configured in the text parsing pre-configuration process comprises an intention dictionary, an intention slot, intention corpora and intention replies.

The intention dictionary contains key-value pairs with the main word as the key and a group of synonym lists as the values. For example, three intention dictionaries are configured, the key of the intention dictionary 1 is the device name, and the value is the synonym list of the device name (for example, the key is a car machine, the value is a vehicle-mounted terminal, a traveling computer, etc.); the key of the intention dictionary 2 is the service name of the service to be called, and the value is the synonym list of the service name (for example, the key is the video playing service, the value is opening, showing, etc.); the key of the intention dictionary 3 is the name of the action to be performed, and the value is the list of synonyms corresponding to the name of the action.

The intention slot is a pre-configured placeholder variable and uniquely corresponds to an intention dictionary. For example, three intention slots are configured, the variable of the intention slot 1 is var1, and corresponds to the intention dictionary 1; the variable of the intention slot 2 is var2 and corresponds to an intention dictionary 2; the variable for intent slot 3 is var3, corresponding to intent dictionary 3.

The semantic corpus is typically a semantic prefix + a main word or a synonym + a semantic suffix or a grammatical variation thereof, and may support regular and irregular corpora, for example, a regular corpus and a plurality of irregular corpora are configured:

rule corpus (canonical match):

Irregular corpus:

the XXX video is opened on the car machine.

And opening the XXX video on the vehicle machine.

And (4) opening the XXX video on the vehicle machine, and not running.

The intention reply is an operation executed when the output text matches the intention corpus, which in this embodiment means that the address information of the target device is acquired, and assembled with the variable value of the intention slot into a service call request, and call is initiated.

Optionally, when the text is analyzed, the first device matches the voice text with the intention corpus, and obtains a parameter value on the intention slot position obtained by successful matching.

In an illustrative example, when the voice text is "play xxx video on car machine", the matched parameter values are var1 ═ car machine ", var2 ═ video playing service", and var3 ═ play xxx video.

Step 502, the first device obtains a device address of at least one candidate device from the server based on the name of the target device included in the first instruction identification result, where the candidate device conforms to the name of the target device.

When the first instruction identification result includes the name of the target device, multiple candidate devices that meet the name of the target device may exist at the same time, and the first device acquires the device address of at least one candidate device from the server in order to determine the target device from the target device in the following process.

Alternatively, the device address may be an address of a service agent in each candidate device, such as a gateway address of the service agent.

Optionally, the candidate device is a device that conforms to the name of the target device and has an association relationship with the first device. The association relationship may include at least one of: the method and the device for logging in the same user account are located in the same device group or have a friend relationship, and the like, which is not limited in the embodiment of the present application.

In a possible embodiment, the device management module of the server stores device addresses of devices under a user account (which are reported by the devices at regular time). The equipment selection module of the first equipment acquires equipment addresses of candidate equipment which accord with the name of the target equipment under the current user account by calling an equipment management module of the server.

For example, when the name of the target device is "car machine", and the current user account includes a tablet computer 1, a smart television 1, a car machine 2, and a car machine 3, the server determines the car machine 1, the car machine 2, and the car machine 3 as candidate devices, and sends the device addresses of the car machine 1, the car machine 2, and the car machine 3 to the smart phone.

Step 503, the first device determines the second device from at least one candidate device.

To ensure correct device service scheduling, the first device needs to determine the second device from the at least one candidate device. Wherein the first device may automatically determine the second device or determine the second device based on a user indication (i.e., manually).

In a possible implementation, the second device determines the second device from the at least one candidate device based on a target selection policy.

Optionally, the target selection policy includes at least one of the following: a distance-based selection policy (for example, determining a candidate device closest to the first device as the second device), a priority-based selection policy (for example, determining a candidate device with the highest priority as the second device based on a preset device priority), and a state-based selection policy (for example, determining a candidate device currently in use as the second device).

For example, the server periodically obtains the device status of each device, and feeds back the device status and the device address to the first device, where the first device determines, as the target device, a candidate device in a use state from the candidate devices.

In another possible implementation, the second device displays a candidate device list, where the candidate device list includes the device identifier of at least one candidate device, and the second device is determined based on a selection operation of the device identifiers in the candidate device list.

In order to further improve the accuracy of the determined second device, the first device provides a candidate device list for the user to select, and determines at least one candidate device selected by the user as the target device.

Of course, besides the above two ways of determining the second device, the first device may also determine the second device by using other schemes (such as an automatic and manual combination scheme), which is not limited in this embodiment of the application.

In step 504, the first device generates a service invocation request based on the device address of the second device, the target service name and the target action name included in the first instruction recognition result.

Further, the first device generates a corresponding service call request for each determined second device.

In one possible implementation, the first device combines the device address, the target service name, and the target action as parameters into a service invocation link.

With reference to the example in the above step, the smartphone generates the service call request based on the "car machine 1 address", "video playing service", and "playing xxx video".

Step 505, the first device sends a service invocation request to the second device.

Further, the first device sends a service invocation request to the second device based on the device address of the second device.

Step 506, the second device receives the service invocation request sent by the first device.

In step 507, the second device obtains target service definition information of the target service from the server based on the target service name included in the service invocation request, and the server stores a corresponding relationship between the service definition information and the service installation package.

In order to determine whether dynamic deployment of the service is required, the second device acquires a target service name included in the service invocation request, so as to acquire target service definition information of the target service from the server based on the target service name.

In a possible implementation manner, the service management module of the second device calls the server definition management module to obtain the target service definition information of the target service through the service gateway of the server.

Illustratively, as shown in fig. 7, the service management module 122 of the second device 120 calls the service definition management module 131 of the server 130 through the service gateway 135 to obtain the target service definition information.

And step 508, in the case that it is determined that the target service installation package does not exist locally based on the target service definition information, the second device acquires the target service installation package from the server based on the target service definition information.

In one possible implementation, the service definition information of the service is associated with an installation package identification of the service installation package. And after the second device acquires the target service definition information, detecting whether the local storage contains the target service installation package or not based on the target installation package identification associated with the target service definition information. If the target service installation package exists, the second equipment determines that dynamic deployment is not needed; and if the target service installation package does not exist, the second equipment further acquires the target service installation package from the server based on the target service definition information.

Optionally, the second device invokes a service installation package management module of the server to obtain the target service installation package through a service gateway of the server.

Illustratively, as shown in fig. 7, the service management module 122 of the second device 120 calls the service installation package management module 132 of the server 130 through the service gateway 135 to obtain the target service installation package.

In step 509, the second device deploys the target service based on the target service installation package.

At step 510, the second device invokes the target service to perform the target action.

The implementation of steps 509 to 510 may refer to steps 206 to 207, and details of the embodiments of the present application are not described herein.

Illustratively, as shown in fig. 7, after the target service installation package is obtained, the service lifecycle management module 123 invokes the service installation module 124 to deploy the target service, and further invokes the service execution module 125 to execute the target action indicated by the request.

In step 511, the second device sends a subscription message to the server, and the server is configured to maintain a subscription relationship between the second device and the target service based on the subscription message.

In some possible scenarios, a developer may update a developed service. In order to ensure the availability and timeliness of the services deployed on the equipment side, the server maintains the subscription relationship between each equipment and each service, so that the relevant equipment is timely notified to update the services when the services are updated based on the subscription relationship. Therefore, after the target installation package is acquired, the second device sends a subscription message to the server, and instructs the server to update the service subscription information of the second device, that is, the target service is added to the service subscription information of the second device.

Illustratively, as shown in fig. 7, after acquiring the target service installation package, the second device 120 sends a subscription message to the service gateway 135, and the service gateway 135 invokes the subscription management module 133 to update the subscription relationship of the second device.

Of course, in other possible embodiments, the server may also automatically update the subscription relationship between the device and the service after providing the service installation package, which is not limited in this embodiment.

In step 512, the second device receives a service update message sent by the server, where the service update message is pushed by the server based on the subscription relationship when the target service installation package is updated.

When the service is updated, the server pushes a service update message to each device subscribed to the service based on the subscription relationship between the devices and the service. Optionally, the service update message includes a service name.

In one illustrative example, the subscription relationships maintained in the server are shown in Table one.

Watch 1

Service	Device
		Video playing service	Car machine 1 and intelligent television 1
Screen capture service	Car machine 1, smart mobile phone 1, tablet personal computer 1 and smart watch
		Screen projection service	Car machine 2, intelligent television 1 and tablet personal computer 1

When the video playing service is updated, the server respectively pushes service updating messages to the car machine 1 and the smart television 1 based on the subscription relation shown in the table one.

Illustratively, as shown in fig. 8, a developer calls an upload interface of the service definition management module 131 through the service gateway 135, uploads updated service definition information to the server 130, and calls an upload interface of the service installation package management module 131 through the service gateway 135, uploads an updated service installation package to the server 130. After the service definition information and the service installation package are updated, the subscription management module 133 of the server 130 sends a service update message to the service agent 121 of the second device 120 through the service gateway 135.

In step 513, the second device obtains the updated target service installation package from the server based on the service update message.

Further, the second device obtains the updated target server installation package from the server based on the service name in the service update message, downloads the originally deployed target service, and deletes the originally stored target service installation package.

Illustratively, as shown in fig. 8, the service management module 122 of the second device 120 obtains the updated service installation package from the server 120 and stores the service installation package in the local storage.

Optionally, the second device may further redeploy the target service based on the updated target service installation package, or perform service deployment in real time when a service invocation request is subsequently received, which is not limited in this embodiment.

In this embodiment, the first device determines whether to store the service installation package locally based on the service definition information by acquiring the service definition information, so as to avoid traffic waste caused by repeated downloading when the service installation package is stored.

In addition, in this embodiment, the server maintains the subscription relationship between the device and the service, and pushes a service update message to the relevant device based on the subscription relationship when the service is updated, so as to ensure availability and timeliness of deploying the service on the device side.

In order to avoid that the service occupies a memory for a long time, the second device may automatically offload the service according to a policy, or the user may control the second device to offload the service through an instruction. As shown in fig. 9, a flow chart of a service offload process shown in an exemplary embodiment of the present application is shown.

Step 901, the first device identifies the second input instruction to obtain a second instruction identification result.

Optionally, the second input instruction may be a voice instruction, a gesture instruction, a text instruction, or the like, and the form of the input instruction is not limited in the embodiments of the present application.

In a possible implementation manner, when the input instruction is identified, and the control intention represented by the instruction identification result is to delete the deployed service, the first device obtains a second instruction identification result, where the second instruction identification result includes parameters required for generating a service uninstall request.

Optionally, the second instruction identification result includes a device name of the service to be uninstalled and a service name of the service to be uninstalled.

For a specific manner of performing instruction identification by the first device, reference may be made to the foregoing embodiment, which is not described herein again.

In an illustrative example, the smartphone performs speech recognition on "delete video playing service on car machine", and the obtained speech recognition result includes a device name "car machine" and a service name "video playing service".

In step 902, the first device generates a service offload request based on the second instruction identification result, where the service offload request is used to request the second device to offload a target service.

Under the condition that the second instruction identification result includes the device name, a plurality of candidate devices conforming to the device name may exist at the same time, and in order to ensure accuracy of subsequent service offloading, the first device needs to determine, from the candidate devices, a target device that actually needs to perform service downloading.

In one possible embodiment, this step may include the steps of:

1. and acquiring the equipment address of at least one candidate equipment from the server based on the target equipment name and the target service name contained in the second instruction identification result, wherein the candidate equipment conforms to the target equipment name and is deployed with the target service.

In order to facilitate subsequent determination of the target device therefrom, the first device obtains a device address of at least one candidate device from the server. Alternatively, the device address may be an address of a service agent in each candidate device, such as a gateway address of the service agent.

Optionally, the candidate device is a device that conforms to the name of the target device, has an association relationship with the first device, and is deployed with the target service. The association relationship may include at least one of: the user equipment logs in the same user account, is located in the same device group or has a friend relationship, and the like.

In a possible implementation manner, a device management module of the server stores device addresses of devices under a user account (which are reported by the devices at regular time), and a subscription management module stores subscription relationships between services and the devices, and a device selection module of the first device obtains device addresses of candidate devices, which meet the names of target devices and are deployed with the target services, under the current user account by calling the device management module and the subscription management module of the server.

For example, the name of the target device is "car machine," the current user account includes a tablet computer 1, an intelligent television 1, a car machine 2, and a car machine 3, and a subscription relationship between the car machine 1 and a video playing service is stored, so that the server determines the car machine 1 as a candidate device and sends a device address of the car machine 1 to the smart phone.

2. A second device is determined from the at least one candidate device.

To ensure proper service offloading, the first device needs to determine the second device from at least one candidate device. Wherein the first device may automatically determine the second device or, alternatively, determine the second device based on a user indication (i.e., manually).

In a possible implementation, the second device determines the second device from the at least one candidate device based on the target selection policy.

Optionally, the target selection policy includes at least one of the following: a distance-based selection policy (e.g., determining a candidate device closest to the first device as the second device), a priority-based selection policy (e.g., determining a candidate device with the highest priority as the second device based on a preset device priority), and a state-based selection policy (e.g., determining a candidate device currently in use as the second device).

For example, the server periodically acquires the device state of each device, and feeds back the device state and the device address to the first device, where the first device determines, as the target device, the candidate device in the use state among the candidate devices.

In another possible implementation, the second device displays a candidate device list, where the candidate device list includes the device identifier of at least one candidate device, and thus the second device is determined based on the selection operation of the device identifiers in the candidate device list.

3. A service offload request is generated based on the device address of the second device and the target service name.

Further, the first device generates a corresponding service uninstalling request for each determined second device.

In one possible implementation, the first device combines the device address and the target service name as parameters into a service offload link.

With reference to the example in the above step, the smartphone generates a service uninstalling request based on the "car machine 1 address" and the "video playing service".

Step 903, the first device sends a service offload request to the second device.

In one possible implementation, the first device sends a service offload request to the second device based on the device address of the second device.

Step 904, the second device receives the service offload request sent by the first device.

In one possible implementation, the second device receives the service offload request through a service agent.

In some embodiments, the second device verifies the service offload request and further responds to the service offload request after passing the verification. The verification method includes request integrity verification, uninstall requester verification, parameter compliance verification, and the like, which is not limited in the embodiment of the present application.

Optionally, after receiving the service uninstallation request, the second device automatically determines whether to accept the request, or determines whether to accept the request based on a user instruction. If the request is accepted, go to step 905; if the request is not accepted, the process ends (a notification to reject the offload may be sent to the first device).

Step 905, the second device unloads the target service based on the service offload request.

In order to ensure the accuracy of the service uninstallation, in one possible implementation, the second device first obtains target service definition information of the target service from the server based on a target service name included in the service uninstallation request, so as to uninstall the target service based on the target service definition information, and deletes the locally stored target service installation package.

Furthermore, in order to avoid that the device can still receive the service update message after the service is uninstalled, in one possible embodiment, in a case that the target service is uninstalled (whether instruction control or automatic uninstallation), the second device sends a subscription cancellation message to the server, and instructs the server to update the subscription relationship, and accordingly, the server is configured to delete the subscription relationship between the second device and the target service based on the subscription cancellation message.

Optionally, the subscription cancellation message includes a device identifier of the second device and a target service name of the target service.

Illustratively, as shown in fig. 10, after the second device 120 receives the service uninstalling request through the service agent 121, the service management module 122 calls the service definition management module 131 through the service gateway 135 to obtain the target service definition information corresponding to the target service name, and further calls the service uninstalling module 126 through the service lifecycle management module 123 to uninstall the target service, and deletes the target service installation package. After the service uninstall is completed, the second device 120 further sends a subscription cancellation message to the server 130, so that the subscription management module 133 of the server 130 deletes the subscription relationship between the target service and the second device.

In this embodiment, the user may instruct the second device to perform service offloading by inputting an instruction, and manual offloading by the user is not required, so that a service offloading process is simplified, and the problem that the operation performance of the device is affected by too many services deployed in the second device is avoided.

In another possible implementation, the second device offloads the target service if an automatic offload condition is satisfied, wherein the automatic offload condition includes at least one of: the calling times of the target service reach a time threshold, the target service is not called in the target duration, and the deployment duration of the target service reaches a duration threshold.

Optionally, the automatic uninstalling condition is set in the service lifecycle management module and supports customization.

For example, when the number of calling times of the target service reaches 2, the service life cycle management module in the second device automatically calls the service uninstalling module to uninstall the target service; when the target service is not called within 2 hours, the service life cycle management module in the second equipment automatically calls the service unloading module to unload the target service; and when the deployment time of the target service reaches 24 hours, the service life cycle management module in the second equipment automatically calls the service uninstalling module to uninstall the target service.

In the above embodiments, the interaction process is taken as an example for schematic illustration, where a step taking the first device as an execution subject may be implemented separately as a service invocation method on the first device side, a step taking the second device as an execution subject may be implemented separately as a service invocation method on the second device side, and a step taking the server as an execution subject may be implemented separately as a service invocation method on the server side, which is not described herein in detail in this embodiment of the present application.

The following are embodiments of the apparatus of the present application that may be used to perform embodiments of the method of the present application. For details which are not disclosed in the embodiments of the apparatus of the present application, reference is made to the embodiments of the method of the present application.

Referring to fig. 11, a block diagram of a service invocation device according to an embodiment of the present application is shown. The apparatus may include:

the instruction identification module 1101 is configured to identify a first input instruction to obtain a first instruction identification result;

a request generating module 1102, configured to generate a service call request based on the first instruction identification result, where the service call request is used to request a second device to call a target service to execute a target action;

a request sending module 1103, configured to send the service invocation request to the second device, so that the second device deploys the target service based on a target service installation package, and invokes the target service to execute the target action, where the target service installation package is obtained from a server.

Optionally, the request generating module 1102 is configured to:

acquiring a device address of at least one candidate device from the server based on a target device name contained in the first instruction identification result, wherein the candidate device conforms to the target device name;

determining the second device from at least one of the candidate devices;

generating the service calling request based on the device address of the second device, a target service name and a target action name which are contained in the first instruction identification result;

the request sending module 1103 is configured to:

sending the service invocation request to the second device based on the device address of the second device.

Optionally, in the process of determining the second device from at least one candidate device, the request generating module 1102 is configured to:

determining the second device from at least one candidate device based on a target selection strategy;

or the like, or, alternatively,

displaying a candidate device list, wherein the candidate device list comprises a device identification of at least one candidate device; determining the second device based on a selection operation of a device identification in the candidate device list.

Optionally, the instruction identifying module 1101 is further configured to identify a second input instruction to obtain a second instruction identifying result;

the request generating module 1102 is further configured to generate a service uninstall request based on the second instruction identification result, where the service uninstall request is used to request the second device to uninstall the target service;

the request sending module 1103 is further configured to send the service uninstalling request to the second device, so that the second device uninstalls the target service.

Optionally, in the process of generating a service uninstall request based on the second instruction identification result, the request generating module 1102 is configured to:

acquiring an equipment address of at least one candidate equipment from the server based on a target equipment name and a target service name contained in the second instruction identification result, wherein the candidate equipment conforms to the target equipment name and is deployed with the target service;

determining the second device from at least one of the candidate devices;

generating the service offload request based on the device address of the second device and the target service name;

the request sending module 1103 is configured to:

Sending the service offload request to the second device based on the device address of the second device.

Referring to fig. 12, a block diagram of a service invocation device according to another embodiment of the application is shown. The apparatus may include:

a request receiving module 1201, configured to receive a service invocation request sent by a first device, where the service invocation request is used to request to invoke a target service to execute a target action, and the service invocation request is generated by the first device based on a first instruction identification result of a first input instruction;

an installation package obtaining module 1202, configured to obtain a target service installation package of the target service from a server based on the service invocation request;

a service deployment module 1203, configured to deploy the target service based on the target service installation package;

an executing module 1204, configured to invoke the target service to execute the target action.

Optionally, the installation package obtaining module 1202 is configured to:

acquiring target service definition information of the target service from the server based on a target service name contained in the service calling request;

and under the condition that the target service installation package does not exist locally based on the target service definition information, acquiring the target service installation package from the server based on the target service definition information, wherein the server stores the corresponding relation between the service definition information and the service installation package.

Optionally, the apparatus further comprises:

and the message sending module is used for sending a subscription message to the server, and the server is used for maintaining the subscription relationship between the second equipment and the target service based on the subscription message.

Optionally, the apparatus further comprises:

a message receiving module, configured to receive a service update message sent by the server, where the service update message is pushed by the server based on the subscription relationship when the target service installation package is updated;

and the updating module is used for acquiring the updated target service installation package from the server based on the service updating message.

Optionally, the apparatus further comprises:

a message sending module, configured to send a subscription cancellation message to the server when the target service is offloaded, where the server is configured to delete the subscription relationship based on the subscription cancellation message.

Optionally, the apparatus further comprises:

the request receiving module 1201 is further configured to receive a service offload request sent by the first device, where the service offload request is used to request the second device to offload the target service, and the service offload request is generated by the first device based on a second instruction recognition result of a second input instruction;

An offload module to offload the target service based on the service offload request.

Optionally, the unloading module is configured to:

acquiring the target service definition information of the target service from the server based on a target service name contained in the service unloading request;

and unloading the target service based on the target service definition information, and deleting the locally stored target service installation package.

Optionally, the unloading module is further configured to:

uninstalling the target service in case that an automatic uninstalling condition is satisfied, the automatic uninstalling condition including at least one of: the calling times of the target service reach a time threshold, the target service is not called in a target time length, and the deployment time length of the target service reaches a time threshold.

Referring to fig. 13, a block diagram of a computer device according to an exemplary embodiment of the present application is shown. The computer device 1700 may be implemented as the first device or the second device in the various embodiments described above. Computer device 1700 may include one or more of the following components: a processor 1710 and a memory 1720.

The processor 1710 may include one or more processing cores. The processor 1710 interfaces with various components throughout the computer device 1700 using various interfaces and circuitry to perform various functions of the computer device 1700 and process data by executing or executing instructions, programs, code sets, or instruction sets stored in the memory 1720, as well as invoking data stored in the memory 1720. Alternatively, the processor 1710 may be implemented in hardware using at least one of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), and Programmable Logic Array (PLA). The processor 1710 may integrate one or more of a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), a Neural-Network Processing Unit (NPU), a modem, and the like. Wherein, the CPU mainly processes an operating system, a user interface, an application program and the like; the GPU is used for rendering and drawing contents required to be displayed by the touch display screen; the NPU is used for realizing an Artificial Intelligence (AI) function; the modem is used to handle wireless communications. It is to be understood that the modem may be implemented by a single chip without being integrated into the processor 1710.

Memory 1720 may include a Random Access Memory (RAM) or a Read-Only Memory (ROM). Optionally, the memory 1720 includes a non-transitory computer-readable medium (non-transitory computer-readable storage medium). The memory 1720 may be used to store an instruction, a program, code, a set of codes, or a set of instructions. The memory 1720 may include a stored program area and a stored data area, wherein the stored program area may store instructions for implementing an operating system, instructions for at least one function (such as a touch function, a sound playing function, an image playing function, etc.), instructions for implementing various method embodiments described below, and the like; the storage data area may store data (such as audio data, a phonebook) created according to the use of the computer apparatus 1700, and the like.

In some embodiments, when the computer device 1700 is implemented as a first device, the computer device 1700 is further provided with a speech acquisition component, which may be a built-in microphone or an external microphone.

In addition, those skilled in the art will appreciate that the configuration of computer device 1700 illustrated in the above-described figures does not constitute a limitation of computer devices, which may include more or fewer components than illustrated, or some components may be combined, or a different arrangement of components. For example, the computer device 1700 further includes a display screen, a camera module, a speaker, a radio frequency circuit, an input unit, a sensor (such as an acceleration sensor, an angular velocity sensor, a light sensor, and the like), an audio circuit, a WiFi module, a power supply, a bluetooth module, and the like, which are not described herein again.

An embodiment of the present application further provides a computer-readable storage medium, where at least one program code is stored, and the program code is loaded and executed by a processor to implement the service call method according to the above embodiments.

Embodiments of the present application provide a computer program product or computer program comprising computer instructions stored in a computer readable storage medium. The computer instructions are read by a processor of the computer device from a computer-readable storage medium, and the computer instructions are executed by the processor to cause the computer device to perform the service invocation method provided in the various alternative implementations of the above-described aspects.

It should be understood that reference herein to "a plurality" means two or more. "and/or" describes the association relationship of the associated object, indicating that there may be three relationships, for example, a and/or B, which may indicate: a exists alone, A and B exist simultaneously, and B exists alone. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship. In addition, the step numbers described herein only show an exemplary possible execution sequence among the steps, and in some other embodiments, the steps may also be executed out of the numbering sequence, for example, two steps with different numbers are executed simultaneously, or two steps with different numbers are executed in a reverse order to the illustrated sequence, which is not limited in this application.

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

Claims

1. A service invocation method, characterized in that the method is performed by a first device, the method comprising:

generating a service calling request based on the first instruction identification result, wherein the service calling request is used for requesting the second equipment to call a target service to execute a target action;

2. The method of claim 1, wherein generating a service invocation request based on the first instruction recognition result comprises:

Determining the second device from at least one of the candidate devices;

the sending the service invocation request to the second device includes:

3. The method of claim 2, wherein said determining the second device from the at least one candidate device comprises:

or the like, or a combination thereof,

4. The method of any of claims 1 to 3, further comprising:

identifying the second input instruction to obtain a second instruction identification result;

generating a service unloading request based on the second instruction identification result, wherein the service unloading request is used for requesting the second device to unload the target service;

Sending the service offload request to the second device to cause the second device to offload the target service.

5. The method of claim 4, wherein generating a service offload request based on the second instruction identification result comprises:

acquiring an equipment address of at least one candidate equipment from the server based on a target equipment name and a target service name which are contained in the second instruction identification result, wherein the candidate equipment accords with the target equipment name and is deployed with the target service;

determining the second device from at least one of the candidate devices;

the sending the service offload request to the second device includes:

6. A service invocation method, characterized in that the method is performed by a second device, the method comprising:

deploying the target service based on the target service installation package;

and calling the target service to execute the target action.

7. The method of claim 6, wherein obtaining the target service installation package of the target service from the server based on the service invocation request comprises:

8. The method of claim 6, further comprising:

and sending a subscription message to the server, wherein the server is used for maintaining the subscription relationship between the second device and the target service based on the subscription message.

9. The method of claim 8, further comprising:

receiving a service update message sent by the server, wherein the service update message is pushed by the server based on the subscription relation under the condition that the target service installation package is updated;

and acquiring the updated target service installation package from the server based on the service updating message.

10. The method of claim 8, further comprising:

and sending a subscription cancellation message to the server under the condition that the target service is unloaded, wherein the server is used for deleting the subscription relation based on the subscription cancellation message.

11. The method of any of claims 6 to 10, further comprising:

receiving a service unloading request sent by the first device, wherein the service unloading request is used for requesting the second device to unload the target service, and the service unloading request is generated by the first device based on a second instruction identification result of a second input instruction;

offloading the target service based on the service offload request.

12. The method of claim 11, wherein offloading the target service based on the service offload request comprises:

13. The method of any of claims 6 to 10, further comprising:

uninstalling the target service under the condition that an automatic uninstalling condition is met, wherein the automatic uninstalling condition comprises at least one of the following conditions: the calling times of the target service reach a time threshold, the target service is not called in a target time length, and the deployment time length of the target service reaches a time threshold.

14. An apparatus for invoking a service, the apparatus comprising:

the request generating module is used for generating a service calling request based on the first instruction identification result, and the service calling request is used for requesting the second equipment to call a target service so as to execute a target action;

15. An apparatus for invoking a service, the apparatus comprising:

16. A computer device, wherein the computer device comprises a processor and a memory; the memory stores at least one instruction for execution by the processor to implement a service invocation method according to any one of claims 1 to 5, or to implement a service invocation method according to any one of claims 6 to 13.

17. A computer-readable storage medium having stored therein at least one program code, the program code being loaded and executed by a processor to implement a service invocation method according to any one of claims 1 to 5, or to implement a service invocation method according to any one of claims 6 to 13.

18. A computer program product, characterized in that the computer program product comprises computer instructions, the computer instructions being stored in a computer readable storage medium; a processor of a computer device reads the computer instructions from the computer readable storage medium, the processor executing the computer instructions to cause the computer device to perform the service invocation method of any of claims 1 to 5, or to implement the service invocation method of any of claims 6 to 13.