Inter-device service calling method and device, equipment, medium and computer program

Abstract

The embodiment of the application discloses a service calling method and device between devices, a terminal and a storage medium, and belongs to the field of multi-device cooperation. The application can discover a first service in a registration center at a local end, learn a first service protocol supported by a called party according to definition information of the service after the discovery, and then correspondingly process service parameters of the first service protocol based on the condition that the local end supports the first service protocol, to obtain cross-end parameters, so that the application can not only transmit the cross-end parameters, but also enable the called party to analyze service parameters in the first service protocol supported by the application according to the cross-end parameters, the effect that the calling party can freely call the corresponding service is realized in different scenes of protocols supported by the calling party and the called party, the technical problem that services cannot be called due to differences in operating systems and supported communication protocols between devices is broken through, and the cooperation capability between devices is improved.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the field of multi-device cooperation, and in particular, to a service calling method and device between devices, a terminal and a storage medium. BACKGROUND

[0002] The service calling between devices is used to indicate that different devices can be linked through a specified strategy.

[0003] In the related art, when a first device with a target operating system needs to call a service in a second device, the target operating system also needs to be installed in the second device. Moreover, the target operating system has the function of a soft bus. In this case, the first device can inquire whether the specified service exists in the second device through a network connection between the first device and the second device. When the specified service exists in the second device, the first device calls the specified service in the second device. SUMMARY

[0004] Embodiments of the present application provide a service calling method and device between devices, a terminal and a storage medium, which can improve the cooperation capability between devices. The technical solution is as follows:

[0005] According to an aspect of the present application, a service calling method between devices is provided, which is applied to a calling party, and the method comprises the following steps.

[0006] Discovering a first service from a service registration center in the calling party, the service registration center being used to store registered services in the calling party and registered services in a called party, and the first service being a registered service in the called party;

[0007] Analyzing definition information of the first service to obtain a first service protocol supported by the called party;

[0008] In response to the calling party not supporting the first service protocol, converting the service parameters according to a specification of a second service protocol to obtain cross-terminal parameters, the service parameters being used to provide the first service to obtain a corresponding service result, and the cross-terminal parameters being parameters in the second service protocol supported by the calling party;

[0009] Calling the first service based on the cross-terminal parameters.

[0010] According to another aspect of the present application, a service calling method between devices is provided, which is applied to a called party, and the method comprises the following steps.

[0011] Receiving cross-terminal parameters from a calling party, the cross-terminal parameters being parameters in a second service protocol supported by the calling party;

[0012] transform the service parameter to obtain a cross-terminal parameter in a first service agreement supported by the callee;

[0013] run the first service based on the service parameter to obtain a service result;

[0014] feed back the service result to the caller.

[0015] According to another aspect of the present application, a service calling device between devices is provided, which is applied to a caller and includes:

[0016] a service discovery module, configured to discover a first service from a service registry center local to the caller, the service registry center being configured to store registered services in the caller and registered services in a callee, the first service being a registered service in the callee;

[0017] a protocol obtaining module, configured to parse definition information of the first service to obtain a first service agreement supported by the callee;

[0018] a first transforming module, configured to, in response to the caller not supporting the first service agreement, transform the service parameter according to a specification of a second service agreement to obtain a cross-terminal parameter, the service parameter being used to provide the first service to obtain a corresponding service result, the cross-terminal parameter being a parameter in the second service agreement supported by the caller;

[0019] a service calling module, configured to call the first service based on the cross-terminal parameter.

[0020] According to another aspect of the present application, a service calling device between devices is provided, which is applied to a callee and includes:

[0021] a parameter receiving module, configured to receive a cross-terminal parameter from a caller, the cross-terminal parameter being a parameter in a second service agreement supported by the caller;

[0022] a second transforming module, configured to transform the cross-terminal parameter to obtain a service parameter in a first service agreement supported by the callee;

[0023] a service running module, configured to run the first service based on the service parameter to obtain a service result;

[0024] a result feeding back module, configured to feed back the service result to the caller.

[0025] According to another aspect of the present application, a calling device is provided, which comprises a processor and a memory, the memory storing at least one instruction, the instruction being loaded and executed by the processor to implement the service invocation method between devices as provided in various aspects of the present application.

[0026] According to another aspect of the present application, a called device is provided, which comprises a processor and a memory, the memory storing at least one instruction, the instruction being loaded and executed by the processor to implement the service invocation method between devices as provided in various aspects of the present application.

[0027] According to another aspect of the present application, a computer readable storage medium is provided, which stores at least one instruction, the instruction being loaded and executed by a processor to implement the service invocation method between devices as provided in various aspects of the present application.

[0028] According to another aspect of the present application, a computer readable storage medium is provided, which stores at least one instruction, the instruction being loaded and executed by a processor to implement the service invocation method between devices as provided in various aspects of the present application.

[0029] According to an aspect of the present application, a computer program product is provided, which comprises computer instructions stored in a computer readable storage medium. A processor of a computer device reads the computer instructions from the computer readable storage medium, and the processor executes the computer instructions, so that the computer device executes the service invocation method between devices as provided in various optional implementation manners by a calling device.

[0030] According to an aspect of the present application, a computer program product is provided, which comprises computer instructions stored in a computer readable storage medium. A processor of a computer device reads the computer instructions from the computer readable storage medium, and the processor executes the computer instructions, so that the computer device executes the service invocation method between devices as provided in various optional implementation manners by a called device.

[0031] The technical scheme provided by the embodiments of the present application can bring the following beneficial effects:

[0032] Since the embodiment of the present application can discover the first service in the registration center at the local end, after the discovery, the first service protocol supported by the called party is known according to the definition information of the service, and then the service parameters of the first service protocol are processed according to the fact that the local end supports the first service protocol, and the cross-end parameters are obtained, so that the cross-end parameters can be transmitted and the called party can also parse the service parameters in the first service protocol supported by the local end according to the cross-end parameters, the effect that the calling party can freely call the corresponding service in the scenario that the calling party and the called party support different protocols is achieved, the technical problem that the services cannot be called due to the difference between the operating systems and the supported communication protocols between devices is broken through, and the collaboration capability between devices is improved. BRIEF DESCRIPTION OF DRAWINGS

[0033] In order to more clearly introduce the technical solutions in the embodiments of the present application, the drawings needed to be used in the description of the embodiments of the present application will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can also be obtained by those skilled in the art without any creative effort on the basis of these drawings.

[0034] Figure 1 is a system architecture schematic diagram provided by an H system;

[0035] Figure 2 is an architecture diagram of a core subsystem of a distributed soft bus provided by the H system;

[0036] Figure 3 is an architecture diagram of distributed task scheduling provided by the H system;

[0037] Figure 4 is a structural block diagram of a calling party provided by an exemplary embodiment of the present application;

[0038] Figure 5 is a structural block diagram of a called party provided by an exemplary embodiment of the present application;

[0039] Figure 6 is an implementation environment diagram applied by a service calling method between devices provided by an exemplary embodiment of the present application;

[0040] Figure 7 is an implementation environment diagram applied by another service calling method between devices provided by an exemplary embodiment of the present application;

[0041] Figure 8 is an implementation environment diagram applied by another service calling method between devices provided by an exemplary embodiment of the present application;

[0042] Figure 9is a flow chart of a service calling method between devices provided by an example embodiment of the present application;

[0043] Figure 10 is a flow chart of a service calling method between devices provided by an example embodiment of the present application;

[0044] Figure 11 is a flow chart of a service calling method between devices provided by another example embodiment of the present application;

[0045] Figure 12 is a system architecture diagram of a service calling between devices provided by an example embodiment of the present application;

[0046] Figure 13 is a flow diagram of service registration provided by an example embodiment of the present application;

[0047] Figure 14 is a flow diagram of service synchronization between devices provided by an example embodiment of the present application;

[0048] Figure 15 is a diagram of service discovery provided by an example embodiment of the present application;

[0049] Figure 16 is a flow diagram of service calling provided by an example embodiment of the present application;

[0050] Figure 17 is a structural block diagram of a service calling device between devices provided by an example embodiment of the present application;

[0051] Figure 18 is a structural block diagram of another service calling device between devices provided by an example embodiment of the present application. DETAILED DESCRIPTION

[0052] In order to make the objects, technical solutions and advantages of the present application clearer, the following will further describe the embodiments of the present application in conjunction with the accompanying drawings.

[0053] The following description refers to the accompanying drawings. Unless otherwise noted, like numbers in different drawings represent the same or similar elements. The following example embodiments described in the example embodiments do not represent all embodiments consistent with the present application. Instead, they are merely examples of apparatuses and methods consistent with some aspects of the present application as detailed in the appended claims.

[0054] In the description of this application, it should be understood that the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. In the description of this application, it should be noted that, unless otherwise explicitly specified and limited, the terms "connected" and "linked" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances. Furthermore, in the description of this application, unless otherwise stated, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship.

[0055] As used herein, the term “if” may optionally be interpreted, depending on the context, as “when,” “in the event of,” “in response to determination,” or “in response to detection.” Similarly, depending on the context, the phrases “if it is determined that…” or “if (the stated condition or event) is detected” or “in response to the detection of (the stated condition or event).”

[0056] It should be noted that the use of personally identifiable information should comply with privacy policies and practices that are generally recognized as meeting or exceeding industry or government requirements for protecting user privacy. Specifically, the nature of authorized use of personally identifiable information should be clearly explained to users during its management and processing to minimize the risk of unintentional or unauthorized access or use.

[0057] In some implementations, there exists an H system capable of providing a core subsystem for a distributed soft bus and a core subsystem for distributed task scheduling. The H system can discover and schedule corresponding services across different endpoints. For further details, please refer to [link to relevant documentation]. Figure 1 , Figure 1 This is a schematic diagram of a system architecture provided by the H system.

[0058] exist Figure 1In the H system, the H system includes an application layer 110, a framework layer 120, a system service layer 130, and a kernel layer 140. The application layer 110 includes desktop applications, control bar applications, settings applications, phone applications, and other system applications, and the application layer 110 further includes extension applications and third-party applications. The framework layer 120 includes a UI (User Interface) framework, a user program framework, and an Ability framework. The system service layer 130 includes a distributed task scheduling core subsystem, a distributed data management core subsystem, a distributed software bus core subsystem, an Ark multi-language runtime subsystem, and a common foundation library subsystem.

[0059] It should be noted that the H system also provides a plurality of subsystem sets, each of which is supported by the framework layer and the system service layer. The subsystem sets in the H system include a system basic ability subsystem set, a basic software service subsystem set, an enhanced software service subsystem set, and a hardware service subsystem set. The system basic ability subsystem set includes a multi-mode input subsystem 151, a graphics subsystem 152, a security subsystem 153, and an AI (Artificial Intelligence) subsystem 154. The basic software service subsystem set includes an event notification subsystem 161, a phone subsystem 162, a multimedia subsystem 163, a DFX (Design For X) subsystem 164, and an MSDP & DP subsystem 165. The enhanced software service subsystem set includes a smart screen dedicated service subsystem 171, a wearable dedicated service subsystem 172, and an IOT dedicated service subsystem 173. The hardware service subsystem set includes a location service subsystem 181, a biometric identification subsystem 182, a wearable dedicated hardware service subsystem 183, and an IOT dedicated hardware service subsystem 184.

[0060] The kernel layer 140 can include a kernel subsystem and a driver subsystem. The kernel subsystem can be a Linux Kernel or a LiteOS. The driver subsystem can be an HDF (Hardware Driver Framework).

[0061] The capability of cross-end scheduling service of H system is introduced as follows. The distributed soft bus in H system realizes the unified distributed communication management capability among near field devices, provides the connection, networking and transmission capability among devices without distinguishing the link, and the main functions are as follows: (1) discovery connection, provides the device discovery connection capability based on the communication mode of WiFi (Wireless Fidelity), Bluetooth, etc. (2) device networking: provides the unified device networking and topology management capability, and provides the networked device information for data transmission. (3) data transmission: provides the data transmission channel, and supports the message, byte data transmission capability, etc. The business party realizes the high-speed communication among devices by using the API (Application Programming Interface) provided by the distributed soft bus, does not need to care about the communication details, and then realizes the efficient deployment and running capability of the business platform, and the structure diagram can be referred to Figure 2 .

[0062] Please refer to Figure 2 , Figure 2 is the architecture diagram of a core subsystem of a distributed soft bus provided by H system. In Figure 2 , the core subsystem 2A of the distributed soft bus includes a networking and topology management module 211, a discovery module 212, a connection module 213, a transmission module 214, an RPC module 215 and a WLAN service module 216.

[0063] Connected with the core subsystem 2A of the distributed soft bus, there are a scenario capability set 2B, an application layer 2C, a soft and hard collaborative subsystem 2D and a Kernel layer 2E. Among them, the soft and hard collaborative subsystem 2D includes a WLAN module and a Bluetooth module.

[0064] Please refer to Figure 3 , Figure 3 is the architecture diagram of distributed task scheduling provided by H system. In Figure 3 , the architecture shown includes an application layer 310, a framework layer 320, a system service layer 330 and a Kernel layer 340. Among them, the application layer 310 includes a distributed music 311, a distributed computer 312, a distributed camera 313 and a distributed navigation 314. The framework layer 320 includes an Application 321, a TaskDispatcher 322, a Context 323 and an App Manager Service Proxy 324. The system service layer 330 includes a distributed task scheduling 3A, a system service management 3B, an application management service 3C, a distributed database 3D, a package management service 3E, a system service 3F, a security subsystem 3G and a distributed soft bus 3H.

[0065] In the system service layer 330, the distributed task scheduling includes a distributed framework 3A and a system service management 3B. The distributed framework 3A includes remote start 3A1, remote unbinding 3A2, component migration 3A3, remote binding and calling 3A4, binding relationship management 3A5 and distributed authority control 3A6. The system service management 3B includes service registration and discovery function 3B1, SA start framework 3B2, service remote calling function 3B3. The application management service 3C includes application management function. The distributed database 3D includes data synchronization function. The package management service 3E includes FA / PA management, FA / PA information synchronization, FA / PA information query. The system service 3F includes multimedia subsystem and graphics subsystem. The security subsystem 3G includes authority control, binding authentication and group verification. The distributed soft bus 3H includes discovery function, connection function and transmission function.

[0066] In the kernel layer 340, HAL (unified multi-form service calling interface) and Kernel (kernel and driver supporting multi-form devices) are included.

[0067] According to Figures 1 to 3 As shown in the technical architecture, the H system does not support service discovery and calling of heterogeneous systems. Specifically, the distributed soft bus and the distributed task scheduling subsystem of the H system provide the upper-layer distributed application with relatively convenient cross-terminal service discovery and calling capability. However, the distributed soft bus and the distributed task scheduling subsystem can only provide the service discovery and calling capability for the application based on the H system, and cannot provide the cross-system or cross-protocol service discovery and calling capability. The client of the H system cannot discover and call the service running in the user's other system. The client of the H system cannot discover and call the service running on the user's W system device or A system device.

[0068] In addition, the H system does not support service discovery and calling outside the local area network. The near-field service registration and discovery of the soft bus and the distributed task scheduling of the H system are based on the COAP protocol, and the service discovery is realized by the technology of sending broadcast messages in the local area network. Therefore, the distributed soft bus and the distributed task scheduling of the H system can only be used within the local area network, and cannot support cross-local area network services.

[0069] In addition, the H system also does not support block protocol calling services. Specifically, the distributed capability application of the H system is based on the Ability distributed calling SDK of the H system, and cannot call the services of other systems, such as the Android component service of the A system.

[0070] In order to facilitate the understanding of the schemes shown in the embodiments of the present application, the following introduces several terms appearing in the embodiments of the present application.

[0071] COAP (Constrained Application Protocol): a web-like protocol in the world of Internet of Things, the detailed specification of COAP is defined in RFC 725 document.

[0072] IOT (Internet Of Things): also known as Internet of Everything, is an extension and expansion of the Internet, which combines various information sensing devices and networks to form a network for realizing the interconnection and intercommunication of people, machines and things in space-time dimension at any place and at any time.

[0073] OS (Operate System): a computer program installed in a terminal device or a cloud server, which is used to manage computer hardware and software resources. The operating system needs to handle some basic transactions in the terminal device or the cloud server, such as managing and configuring memory, determining the priority of system resource supply and demand, controlling input and output devices, operating network and managing file system, etc. In addition, the operating system can provide an operation interface for user interaction with the operating system.

[0074] RPC (Remote Procedure Call): an idea of requesting services from a remote computer program through a network without parsing the underlying network technology.

[0075] SDK (Software Development Kit): SDK is a collection of development tools built by software engineers for specific software packages, software frameworks, hardware platforms, operating systems, etc. when developing application software.

[0076] RTOS (Real Time Operate System): refers to an operating system that can accept and process external events or data at a fast enough speed, and the results of processing can control the production process or make a quick response to the processing system within a specified time, schedule all available resources to complete real-time tasks, and control all real-time tasks to run in coordination.

[0077] Caller: used to indicate a device or terminal, the caller can be a device that a user carries with him / her in daily life, or a device that is strongly related to an individual in daily life. The caller can call the first service registered in the callee, and the caller does not need to register the first service locally. Thus, the caller can call the first service without installing the first service in the caller to achieve the effect of realizing the corresponding function.

[0078] The callee is used to indicate a device or terminal, which can be a device that a user carries daily or a device that is strongly related to a person in daily life. The callee can register a first service. The first service can be called by the caller through cross-device.

[0079] The caller and the callee can communicate through a local area network or the Internet, which is not limited in the embodiments of the application. In order to ensure the respective solutions of the caller and the callee, the caller and the callee can be connected through an authentication process, and the authentication process can be encrypted through a key.

[0080] With the increasing degree of social informatization, the number of devices per capita is increasing. According to the prediction of a relevant research institution, the number of devices per capita will increase to 8. How to integrate the devices used by the same person into "one device", that is, the services running on each device can seamlessly access each other, is a problem that the application focuses on solving.

[0081] Next, the hardware environment to which the application is applied is introduced.

[0082] Exemplarily, the service calling method between devices shown in the embodiments of the application can be applied in the caller, which has a service calling function between devices. It should be noted that the caller can be a user's portable device or a scene-specific device. The user's portable device is an electronic device that the user can carry, which can communicate with other electronic devices through a network. The scene-specific device can be a device specific to a specified scene, for example, a car machine is a device specific to a car-riding scene.

[0083] On this basis, when the caller is a user's portable device, the caller can include a mobile phone, a tablet computer, a laptop computer, a Bluetooth headset, smart glasses, a smart watch, a digital camera, an MP4 player terminal, an MP5 player terminal, a learning machine, a point-reading machine, an electronic paper book, an electronic dictionary, a virtual reality (VR) player terminal or an augmented reality (AR) player terminal, etc. When the caller is a scene-specific device, the caller can be a desktop computer, an all-in-one computer, a television, a car machine, a Bluetooth speaker, a Bluetooth mouse, a Bluetooth keyboard or a car machine.

[0084] It should be noted that the form of the terminal or device to which the callee can be landed is similar to the caller, which is not described here.

[0085] Please refer to Figure 4 , Figure 4 is a structural block diagram of a caller provided by an exemplary embodiment of the application, as Figure 4As shown, the invoker includes a processor 420 and a memory 440, the memory 440 stores at least one instruction, the instruction is loaded and executed by the processor 420 to implement the service calling method between devices as described in various method embodiments of the present application.

[0086] In the present application, the invoker 400 is an electronic device with a service calling function. The invoker 400 discovers a first service from a service registry center local to the invoker, the service registry center is used to store registered services in the invoker and registered services in the callee, the first service is a registered service in the callee; parses definition information of the first service to obtain a first service protocol supported by the callee; in response to the invoker not supporting the first service protocol, converts the service parameters according to a specification of a second service protocol to obtain cross-end parameters, the service parameters are used to provide the first service to obtain corresponding service results, the cross-end parameters are parameters in the second service protocol supported by the invoker; and calls the first service based on the cross-end parameters.

[0087] The processor 420 can include one or more processing cores. The processor 420 connects various parts within the entire invoker 400 through various interfaces and lines, and performs various functions of the invoker 400 and processes data by running or executing instructions, programs, code sets or instruction sets stored in the memory 440, and calling data stored in the memory 440. Optionally, the processor 420 can be implemented in at least one of a hardware form of a digital signal processing (DSP), a field-programmable gate array (FPGA), and a programmable logic array (PLA). The processor 420 can integrate a combination of one or more of a central processing unit (CPU), a graphics processor (GPU), and a modem. Among them, the CPU is mainly used to process operating systems, user interfaces, and application programs; the GPU is used to render and draw the content required to be displayed on the display screen; and the modem is used to process wireless communication. It can be understood that the above-mentioned modem can also not be integrated into the processor 420, but can be realized by a separate chip.

[0088] The memory 440 can include a random access memory (RAM) and can also include a read-only memory (ROM). Optionally, the memory 440 includes a non-transitory computer-readable storage medium. The memory 440 can be used to store instructions, programs, codes, code sets, or instruction sets. The memory 440 can include a program storage area and a data storage area, where the program storage area can 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 each of the method embodiments described below, etc., and the data storage area can store data related to each of the method embodiments described below, etc.

[0089] Please refer to Figure 5 , Figure 5 is a structural block diagram of a called party provided by an example embodiment of the present application, as shown in Figure 5 , the called party includes a processor 520 and a memory 540, the memory 540 stores at least one instruction, the instruction is loaded and executed by the processor 520 to implement the service calling method between devices as described in each method embodiment of the present application.

[0090] In the present application, the called party 500 is an electronic device with a service calling function. The called party 500 receives a cross-end parameter from a calling party, the cross-end parameter is a parameter in a second service protocol supported by the calling party; converts the cross-end parameter to obtain a service parameter in a first service protocol supported by the called party; runs the first service based on the service parameter to obtain a service result; and feeds back the service result to the calling party.

[0091] The processor 520 can include one or more processing cores. The processor 520 connects various parts within the callee 500 by various interfaces and lines, performs various functions of the callee 500 and processes data by running or executing instructions, programs, code sets or instruction sets stored in the memory 540 and calling data stored in the memory 540. Optionally, the processor 520 can be implemented in at least one of a hardware form of a digital signal processing (DSP), a field-programmable gate array (FPGA), and a programmable logic array (PLA). The processor 520 can be integrated with a combination of one or more of a central processing unit (CPU), a graphics processing unit (GPU), and a modem. Among them, the CPU is mainly used to process operating systems, user interfaces, and application programs; the GPU is used to render and draw the content required to be displayed on the display screen; and the modem is used to process wireless communication. It can be understood that the above-mentioned modem can also not be integrated into the processor 520, but can be realized by a separate chip.

[0092] The memory 540 can include a random access memory (RAM) and can also include a read-only memory (ROM). Optionally, the memory 540 includes a non-transitory computer-readable storage medium. The memory 540 can be used to store instructions, programs, codes, code sets or instruction sets. The memory 540 can include a program storage area and a data storage area, wherein the program storage area can 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 each of the following method embodiments, etc.; and the data storage area can store data related to each of the following method embodiments, etc.

[0093] Please refer to Figure 6 , Figure 6 is an implementation environment diagram applied by a service calling method between devices provided by an exemplary embodiment of the present application. In the implementation environment diagram, the callee 500 can be a device, such as a mobile phone, a tablet computer, a wearable device, a smart home device, a smart car, etc. Figure 6In the scenario, there are a mobile phone 610, a TV 620, a kitchen large-screen device 630 and a smart wash mirror 640. The scenario is used to indicate a scenario in which a user gets up in the morning. The mobile phone 610, the TV 620, the kitchen large-screen device 630 and the smart wash mirror 640 can be bound to a device group that can communicate with each other. When the devices are all in a local area network, the devices can communicate through short-range wireless transmission. When some of the devices are far away from the other devices, the devices can communicate through the Internet.

[0094] In the scenario, Figure 6 In the scenario, a personal account of the user can be logged in the mobile phone 610. Each device can log in the same personal account of the user. Each device authenticates with each other through the same logged-in account, and thus joins the same device group.

[0095] In a possible application scenario, when the user gets up in the morning, the user can take the mobile phone 610 to wash in front of a wash basin. When the smart wash mirror 640 detects that the distance between the mobile phone 610 and the smart wash mirror 640 is within a first distance, and a video playing service in the mobile phone 610 is running, the smart wash mirror 640 invokes the video playing service in the mobile phone 610, so that the video is no longer played in the mobile phone 610, but is continued to be played in the smart wash mirror 640. It should be noted that the smart wash mirror 640 has the function of an ordinary mirror, and the display screen is integrated in the mirror. The smart wash mirror 640 can communicate with other devices through short-range wireless communication.

[0096] When the user finishes washing, and takes the mobile phone 610 to the kitchen to make breakfast, the video is transferred back to the mobile phone 610 to continue playing. When the user holds the mobile phone 610 to the kitchen, the kitchen large-screen device 630 can detect that the distance between the mobile phone 610 and the kitchen large-screen device 630 is within a second distance, and the video playing service in the mobile phone 610 is running. The kitchen large-screen device 630 invokes the video playing service in the mobile phone 610, so that the video is no longer played in the mobile phone 610, but is continued to be played in the kitchen large-screen device 630. It should be noted that if the kitchen large-screen device 630 has a loudspeaker, the sound of the video is output from the kitchen large-screen device 630. If the kitchen large-screen device 630 does not have a loudspeaker, the sound of the video can continue to be played through the loudspeaker of the mobile phone 610, or can be played through a Bluetooth earphone worn by the user or a Bluetooth speaker in the home.

[0097] When the user is ready to finish the breakfast and carries the mobile phone 610 from the kitchen to the dining room, the automatic relay playing of the video on the TV can not appear because the user is far away from the TV at the dining table. However, in this scenario, the mobile phone 610 can provide a video playing card in the negative one screen or the notification bar. The video playing card can be "the currently playing ABC video can be played in the TV 620, do you want to change the screen to play". When the user manually selects to continue playing the video in the TV 620, the video will continue to play in the TV 620 and stop playing in the mobile phone 610.

[0098] Please refer to Figure 7 , Figure 7 is another device-to-device service calling method provided by an exemplary embodiment of the present application. In Figure 7 , the mobile phone 710, the car machine 720 and the car audio 730 are included. This scenario is used to indicate the scenario in which the user is in a car or drives a car. The mobile phone 710, the car machine 720 and the car audio 730 can be bound to a device group that can communicate with each other. It should be noted that, based on the particularity of the car-riding scenario, the above-mentioned devices communicate with each other through short-range wireless transmission, or the devices are connected through a USB cable.

[0099] In Figure 7 , the user's personal account can be logged in the mobile phone 710. Each device can log in the same user's personal account. Each device authenticates with each other through the same logged account, so as to join the same device group.

[0100] In a possible application scenario, when the user enters the vehicle and starts the vehicle, the mobile phone 710 can establish a communication connection with the car machine 720 and the car audio 730 through a Bluetooth connection, or can establish a communication connection with the car machine 720 and the car audio 730 through a USB cable. After the mobile phone 710 establishes a connection with the above-mentioned devices, the car machine 720 can automatically call the first service in the mobile phone 710. For example, the first service is a video playing service, and the car machine 720 can directly call the first service in the mobile phone 710 to continue playing the video being played in the video playing service in the mobile phone 710. From the user experience, the video can be automatically changed from the mobile phone 710 to the car machine 720 after the user enters the car, and continue to play in the screen of the car machine 720. Similarly, the car audio can be used as the audio output of the mobile phone 710 to continue to provide the audio output service. The audio output can include music audio output, audio output in a video and audio output in a voice call, which are not limited by the embodiments of the present application.

[0101] In another possible scenario, the first service can also be an interactive learning service, and the user can automatically switch from using the mobile phone 710 for interactive learning to using the car machine 720 for interactive learning. For example, the user uses the mobile phone 710 for an online meeting, and the mobile phone 710 provides a front camera and a microphone. When the user enters the vehicle, the car machine 720 will call the online meeting service in the mobile phone 710, and provide the front camera and the microphone, and continue to use the online meeting service so that the user can continue to participate in the online meeting during driving or riding. It should be noted that if the vehicle is not equipped with a camera for shooting the user, the online meeting service no longer collects the user's influence but does not affect the car machine 720 calling the online meeting service.

[0102] Please refer to Figure 8 , Figure 8 is an example embodiment provided by an embodiment environment diagram applied by another service calling method between devices provided by the embodiment of the present application. In Figure 8 , the mobile phone 810 and the personal computer 820 are included. The personal computer 820 can be equipped with input and output components such as a mouse, a keyboard, a camera, and a microphone, so as to be operated by the user.

[0103] In Figure 8 , the user's personal account can be logged in the mobile phone 810. Each device can log in the same user's personal account. Each device authenticates each other through the same logged account, so as to join the same device group.

[0104] In a possible application scenario, the personal computer 820 can be a desktop computer or a notebook computer, and the embodiment of the present application does not limit this. When the distance between the user carrying the mobile phone 810 and the personal computer 820 is less than a third distance, or the user searches the mobile phone 810 in the vicinity of the personal computer 820 through the personal computer 820, the user can manually operate the personal computer 820 to call the first service in the mobile phone 810. When the distance between the personal computer 820 and the mobile phone 810 is less than the third distance, the personal computer 820 is considered to be in the vicinity of the mobile phone 810.

[0105] For example, the mobile phone 810 stores a work file, and the first service is used to process the work file. When the personal computer 820 calls the first service in the mobile phone 810, the personal computer 820 can simultaneously read the work file, and directly display the work file in an editing mode, thereby improving the problem of reduced work efficiency caused by switching work devices.

[0106] For example, a game service (first service) is running in the mobile phone 810, and a user account of the user is logged in the game service. When the personal computer 820 invokes the first service in the mobile phone 810, the personal computer 820 can read the information of the game account, and based on the game application in the mobile phone 810, redirect the input to the keyboard and mouse of the personal computer 820, redirect the output to the computer screen, and redirect the sound to the speaker, so that the user can quickly play the game on the computer.

[0107] In the embodiments of the present application, based on the implementation environment shown in Figures 6 to 8 The present application can provide a cross-device service invocation service for a user throughout the day, and the corresponding scene information is shown in Table 1.

[0108]

[0109] Table 1

[0110] Based on the service invocation method between devices provided by the present application, ubiquitous services can be provided for the user. The multiple devices involved in the present application will be able to operate uniformly. The multiple terminals or the terminal cloud are seamlessly integrated into a whole system operation. Specifically, the service resources running on multiple devices are uniformly scheduled, and according to the user scene, the most suitable scene resource is used to cooperatively provide a good service experience. Technically, the following four technology stacks can be relied on:

[0111] 1) Seamless connection: efficient and low-power consumption full-scene network with no user awareness, self-adaptation, high quality, wide connection, and multiple channels.

[0112] 2) Resource integration: data terminal cloud integration, service cross-terminal invocation, user efficient management of multiple terminal devices, developer flexible integration of multiple device capabilities, and double-speed innovation of business.

[0113] 3) Ecological openness: maximum interconnection of devices and maximum mutual empowerment.

[0114] 4) Interactive intelligence: taking advantage of multiple devices and multiple modal perception interaction capabilities to achieve natural and accurate services.

[0115] Among them, resource integration is the service of the system resources, and single-terminal devices need to have the ability to discover services in the user's multiple devices. All service must be defined in a unified format to effectively invoke across terminals. The purpose of the present application is to solve this problem. In detail, in a heterogeneous environment, multiple devices of a user run different operating systems, such as an Android system of a mobile phone and a Windows system of a computer. How to cross-terminal service registration, discovery, and invocation.

[0116] Please refer to Figure 9 , Figure 9is a flowchart of a method for service invocation between devices provided by an example embodiment of the present application. The method for service invocation between devices can be applied in the invoker shown in the above. In Figure 9 The method for service invocation between devices includes the following steps.

[0117] In step 910, a first service is discovered from a service registry center local to the invoker, the service registry center is used to store registered services in the invoker and registered services in the callee, and the first service is a registered service in the callee.

[0118] In an embodiment of the present application, there is a service registry center in the local of the invoker. In actual implementation, the service registry center can be a database. The invoker can access the database in the local at a high speed. Illustratively, the service registry center in the local of the invoker can synchronize registered services in the callee and other devices connected to the invoker in real time. Therefore, the invoker can know the services that can be invoked from other devices by accessing the service registry center in the local.

[0119] In step 920, definition information of the first service is parsed to obtain a first service protocol supported by the callee.

[0120] In an embodiment of the present application, the invoker can obtain the definition information of the first service after discovering the first service. In a possible way, the definition information of the first service is stored in a specified file. The invoker can parse the file to obtain the first service protocol supported by the callee.

[0121] Optionally, after the invoker knows the first service protocol, the invoker can know specifications and parameter requirements related to the first service protocol at the same time.

[0122] In step 930, in response to the invoker not supporting the first service protocol, service parameters are converted according to specifications of a second service protocol to obtain cross-terminal parameters, the service parameters are used to provide the first service to obtain corresponding service results, and the cross-terminal parameters are parameters in the second service protocol supported by the invoker.

[0123] In an embodiment of the present application, when the invoker does not support the first service protocol, the invoker converts the service parameters according to the specifications of the second service protocol to obtain the cross-terminal parameters. Since the cross-terminal parameters can be supported by the invoker, the invoker can successfully send the cross-terminal parameters to the callee.

[0124] In step 940, the first service is invoked based on the cross-terminal parameters.

[0125] In an embodiment of the present application, after the invoker sends the cross-terminal parameters to the callee, the invoker can obtain invocation results fed back by the callee to successfully complete the invocation of the first service.

[0126] To sum up, the device inter-service calling method provided by the embodiment can discover the first service in the local registration center, learn the first service protocol supported by the callee according to the definition information of the service after the discovery, and then process the service parameters of the first service protocol based on the fact that the local device supports the first service protocol, so as to obtain the cross-end parameters. As a result, the device can not only transmit the cross-end parameters, but also enable the callee to parse the service parameters in the first service protocol supported by the device according to the cross-end parameters. The device can freely call the corresponding service in the scenario where the calling device and the callee support different protocols, thereby breaking through the technical difficulty that the devices cannot call services due to different operating systems and supported communication protocols, and improving the collaboration capability between devices.

[0127] Please refer to Figure 10 , Figure 10 is a flowchart of a device inter-service calling method provided by an example embodiment of the present application. The device inter-service calling method can be applied in the callee shown in the above. Figure 10 The device inter-service calling method includes the following steps.

[0128] Step 1010, receiving the cross-end parameters from the calling device, where the cross-end parameters are parameters in the second service protocol supported by the calling device.

[0129] In the embodiment of the present application, the callee can receive the cross-end parameters from the calling device. The cross-end parameters are parameters in the second service protocol supported by the calling device.

[0130] Step 1020, converting the cross-end parameters to obtain the service parameters in the first service protocol supported by the callee.

[0131] In the embodiment of the present application, the callee needs to convert the cross-end parameters to the service parameters in the first service protocol supported by the callee, because the callee cannot directly use the cross-end parameters.

[0132] Step 1030, running the first service based on the service parameters to obtain the service result.

[0133] In the embodiment of the present application, the first service is run based on the service parameters to obtain the service result, because the service parameters can be directly used in the callee. The service result will be different for different services.

[0134] Step 1040, feeding back the service result to the calling device.

[0135] In the embodiment of the present application, the callee feeds back the service result to the calling device in order to realize the correct calling of the first service.

[0136] To sum up, the service calling method between devices provided in the application can enable the callee to receive the cross-terminal parameter sent by the caller, and then convert the cross-terminal parameter into a service parameter supported by the local terminal, so as to run a corresponding first service based on the service parameter, and feed back the service result to the caller, thereby realizing the effect that the caller can freely call the corresponding service in the scenario that the caller and the callee support different protocols, breaking through the technical difficulty that the services cannot be called due to the differences in operating systems and supported communication protocols between devices, and improving the collaboration capability between devices.

[0137] Based on the scheme disclosed in the previous embodiment, the method for calling the service between devices can be cooperatively implemented between the caller and the callee. Please refer to the following embodiments.

[0138] Please refer to Figure 11 , Figure 11 is a flowchart of a service calling method between devices provided in another exemplary embodiment of the application. The service calling method between devices can be applied in the caller and the callee shown in the above embodiments. In the Figure 11 , the service calling method between devices includes:

[0139] Step 1101, in response to a first registration service request, calling a first unified service governance module.

[0140] Step 1102, based on the registration function of the first unified service governance module, registering a second service corresponding to the first registration service request in a service registry center in the local terminal of the caller.

[0141] Step 1103, based on the synchronization function of the first unified service governance module, synchronizing the second service to the callee.

[0142] Step 1104, the caller discovers the first service from the service registry center in the local terminal of the caller.

[0143] In the embodiment of the application, the execution process of step 1104 is the same as that of step 910, and will not be repeated here.

[0144] As an alternative implementation, step 1104 can be replaced by the following steps a1) and step a2) to realize the function of discovering the first service.

[0145] Step a1), the caller calls the first unified service governance module through a service gateway interface in the caller.

[0146] Step a2), based on the first unified service governance module, the caller searches for the first service from the service registry center in the local terminal of the caller.

[0147] At step 1105, the invoker parses the definition information of the first service to obtain a first service protocol supported by the callee.

[0148] In the embodiments of the present application, the execution process of step 1105 is the same as that of step 920, and thus is not described here again.

[0149] At step 1106, in response to the invoker not supporting the first service protocol, the invoker converts the service parameters according to the specification of a second service protocol to obtain cross-end parameters.

[0150] In the embodiments of the present application, the execution process of step 1106 is the same as that of step 930, and thus is not described here again.

[0151] At step 1107, the invoker sends the cross-end parameters to the callee.

[0152] As an alternative implementation, step 1107 can be replaced by the following steps b1) and b2) to achieve the function of obtaining the cross-end parameters.

[0153] At step b1), the cross-end parameters are serialized through a first cross-end protocol to obtain serialized cross-end parameters.

[0154] At step b2), the serialized cross-end parameters are sent to the callee, and the serialized cross-end parameters are used to be deserialized by the callee based on a second cross-end protocol to obtain the cross-end parameters.

[0155] Illustratively, the first unified service governance module includes an application layer part and a domain layer part, the application part includes at least one of a service registration function, a service discovery function, a service scheduling function, a service update function, a service removal function and a service synchronization function; and the domain layer part includes at least one of a service definition management, a service protocol management and a service authorization management.

[0156] Illustratively, the definition information is stored in a service package of the first service in the form of a target file format, and the target file format is used to provide text information across platforms.

[0157] The target file format can be an xml format or other formats capable of storing text.

[0158] Illustratively, the definition information includes at least one of a service name, a service type, a service protocol and input / output parameters of the service.

[0159] Illustratively, the service protocol includes at least one of a protocol type, a service unique identifier and protocol attributes; and the input / output parameters of the service include at least one of input parameters and output parameters.

[0160] The input parameter includes at least one of a first parameter name, a first data type, a first default value and a first necessary mark, and the first necessary mark is used to indicate whether the input parameter is necessary.

[0161] Correspondingly, the callee receives the cross-terminal parameter from the caller.

[0162] Before the callee receives the cross-terminal parameter from the caller, the callee can pre-register the first service and synchronize the service to the caller.

[0163] Correspondingly, the callee can invoke the second unified service management module in response to the second registration service request; based on the registration function of the second unified service management module, the first service corresponding to the second registration service request is registered in the local terminal of the callee; and based on the synchronization function of the second unified service management module, the first service is synchronized to the caller.

[0164] At step 1108, the callee converts the cross-terminal parameter to obtain a service parameter in a first service protocol supported by the callee.

[0165] At step 1109, the callee runs the first service based on the service parameter to obtain a service result.

[0166] At step 1110, the callee feeds back the service result to the caller.

[0167] It should be noted that the execution process of steps 1108 to 1110 can refer to the execution process of steps 1020 to 1040, which will not be repeated here.

[0168] Correspondingly, the caller receives the service result fed back by the callee.

[0169] The service result is data obtained by the first service in the callee after running based on the cross-terminal parameter.

[0170] In summary, the embodiment can discover the first service in the registration center in the local terminal, and after the discovery, the first service protocol supported by the callee is known according to the definition information of the service. Then, based on the fact that the local terminal supports the first service protocol, the service parameter of the first service protocol is processed accordingly, the cross-terminal parameter is obtained, so that the cross-terminal parameter can be transmitted, and the callee can also parse the service parameter in the first service protocol supported by the local terminal according to the cross-terminal parameter. The effect of freely calling the corresponding service by the caller in the different scenarios of the protocols supported by the caller and the callee is achieved, the technical problem that the services cannot be called due to the differences in operating systems and supported communication protocols between devices is broken through, and the collaboration ability between devices is improved.

[0171] The following describes the technical underlying scheme involved in the method for calling services between devices provided by the present application. The technical underlying scheme will be introduced according to technical points.

[0172] Unified service definition

[0173] Through analysis of typical service types (HTTP, TCP, RPC, Android component service, etc.), a service definition satisfying all service types is abstracted. The abstraction is mainly in two aspects:

[0174] First, the protocol definition is abstracted. Based on the fact that each cross-terminal service protocol has different service attributes, an enumeration value of Protocol is defined for each protocol, and the specific attributes of Protocol are placed in ProtocolAttrbute. For example, the definition of TCP is as follows:

[0175] "protocol":"tcp" / / The keyword is protocol, and the enumeration value is tcp

[0176] "protocolAttribute":{"IP":"192.168.0.2","port:8080"} / / The keyword is protocolAttribute, which is used to indicate the attributes of protocol. IP indicates the attribute name, and "192.168.0.2" is the value of the IP attribute. Port indicates another attribute name, and "8080" indicates the value of the port attribute. ....

[0178] Second, the input and output parameters of the service are defined according to the standard method. The Schema (schema) definition is as follows:

[0179]

[0180]

[0181] Please refer to the unified service definition format shown in Table 2. The unified definition shown in Table 2 needs to be referred to by the personnel who writes the service definition.

[0182]

[0183] Table 2

[0184] The following will introduce the definition of several services. Standard service definition.

[0185] (1) Screen projection service definition

[0186]

[0187] (2) Video play service definition

[0188]

[0189]

[0190] Please refer to Figure 12 , Figure 12 is a system architecture diagram of service invocation between devices provided by an embodiment of the present application. In Figure 12 , a terminal side system 1210 and a cloud side system 1220 are included.

[0191] In the terminal side system 1210, a gateway layer 1211, an application layer 1212 and a domain layer 1213 are included. The gateway layer 1211 includes a service gateway; the application layer 1212 includes an ICDF protocol invocation subsystem, an HTTP protocol service invocation subsystem and an Android service invocation subsystem; and the domain layer 1213 includes service definition management, service protocol management and service authorization management. The application layer 1212 further includes an API interface (Content Provider), device communication, service registration, service discovery, service scheduling, service updating, service removal and service synchronization. The device communication includes a cloud access module and a near field communication interface module. In the terminal side system 1210, the application layer and the domain layer are integrated into unified service governance.

[0192] In the cloud side system 1220, a gateway layer 1221, an application layer 1222 and a domain layer 1223 are included. The gateway layer 1221 includes an API gateway; the application layer 1222 includes unified service governance, which further includes service registration, service discovery, service scheduling, service updating, service removal and service synchronization; and the domain layer 1223 includes a unified service governance domain, which further includes service definition management, service protocol management and service authorization management.

[0193] The domain layer is configured to provide unified service governance. The service definition provides services for the entire life cycle of service definition; the service protocol provides protocol-related protocol rule management; and the service authorization provides services for a service authorization system model. The application layer is combined based on the services of the domain layer, and unifiedly provides service registration, service discovery, service updating and service scheduling and other capabilities to the outside.

[0194] Please refer to Figure 13 , Figure 13 is a flowchart of service registration provided by an embodiment of the present application. In Figure 13 , a cloud side 1310, a first terminal side 1320 and a second terminal side 1330 are included.

[0195] The service registration process can be initiated by two initiators. The first initiator is the service provider in the first terminal side 1320, which initiates a first registration service request 1341. After the service gateway in the first terminal side 1320 receives the first registration service request 1341, the service registration request will be initiated to the "unified service management". The "unified service management" will complete the registration of the service in the first terminal side 1320. The structure of the "unified service management" can be referred to Figure 12 The application is not limited in this regard.

[0196] On the other hand, the other initiator of the service registration process is the subsystem in the first terminal side 1320. The subsystem can be an ICDF protocol calling subsystem, an HTTP protocol service calling subsystem, and an Android service calling subsystem. It should be noted that other subsystems for calling services can also be included in the application. Each calling subsystem can initiate a service registration process. Each calling subsystem can initiate a service registration request to the "unified service management". The "unified service management" will complete the registration of the service in the first terminal side 1320.

[0197] After the "unified service management" completes the registration of the service, the "unified service management" can synchronize the service registered in the first terminal side 1320 to other devices connected to the first terminal side 1320. In the example shown in Figure 13 The "unified service management" synchronizes the service registered in the first terminal side 1320 to the cloud side 1310 and the second terminal side 1330. The synchronization request is sent to the gateway of the corresponding side, and then forwarded to the corresponding "unified service management" by the gateway. Since the synchronization process involves the cloud side 1310, the cloud side 1310 can further synchronize the service registered in the first terminal side 1320 to other terminal sides connected to the cloud side 1310, so that the terminal sides connected to the first terminal side 1320 can know that the service has been registered in the first terminal side 1320.

[0198] In other words, the registered service is a service provider calling a service management SDK service registration interface. The service definition provided by the service provider needs to follow the standard of the unified service definition. The unified service instruction module stores the service definition in the local database of the device.

[0199] Please refer to Figure 14 , Figure 14 is a flow diagram of a service synchronization between devices according to an embodiment of the application. In Figure 14 , the cloud side 1310, the first terminal side 1320, and the second terminal side 1330 are included.

[0200] The service synchronization can be performed in multiple scenarios or triggering conditions. In this application, the scenarios that can trigger the service synchronization include the scenario of registering a service, the scenario of changing the definition of a service, and the scenario of removing a service. It should be noted that other scenarios related to the change of the state of a service can also trigger the service synchronization, and the embodiments of this application do not limit the scenarios.

[0201] The condition of triggering the service synchronization is taken as an example to introduce the first terminal side 1320. In response to any one of the scenarios of registering a service, the scenario of changing the definition of a service, and the scenario of removing a service, the service gateway in the first terminal side 1320 can learn the message and send a service synchronization request to the unified service management. The unified service management first changes the service state in the database in the local, and then synchronizes the related messages of the changed service to the cloud side 1310 and the second terminal side 1330. When the second terminal side 1330 and the first terminal side 1320 can be directly connected, the unified service management in the first terminal side 1320 can directly perform the service synchronization process. When the second terminal side 1330 and the first terminal side 1320 cannot be directly connected, the service synchronization can be performed through the cloud side 1310.

[0202] In other words, the unified service management module saves the services in the local service registration center (i.e., the database). Meanwhile, the unified service management module synchronizes the service information to other devices of the user in the near field through near field connection or cloud service. On the other hand, the synchronization process of modifying and removing the service information is the same as the service registration process, which can be referred to the process shown in Figure 14 .

[0203] Please refer to Figure 15 , Figure 15 is a schematic diagram of service discovery provided by an embodiment of the application. In Figure 15 , the first terminal side 1320 is taken as an example to introduce. When the first terminal side 1320 needs to discover a specified service, for example, the first terminal side 1320 needs to discover the first service, the service manager, the specified application, or the specified service in the first terminal side 1320 can initiate a service discovery instruction, and the service discovery instruction is sent to the service gateway. The service gateway in the first terminal side 1320 sends the service discovery instruction to the unified service management. The unified service management searches for the first service from the local database 1510 according to the service discovery instruction. If the unified service management finds the first service in the local database 1510, the specific information of the first service can be returned. If the unified service management does not find the first service in the local database 1510, the result information of the search failure can be returned.

[0204] In other words, the first service in the first terminal side 1320 registers to the local database (i.e. the service registry center), and synchronizes the information of the corresponding service to other devices of the user through near field connection or cloud. Therefore, the service discovery process of the scheme only needs to search the data from the local database, avoiding the need to search the corresponding service across terminals in the related art, and reducing the time delay of searching the service.

[0205] Please refer to Figure 16 , Figure 16 is a flowchart of service invocation provided by the embodiment of the present application. In Figure 16 , the calling party 16A and the called party 16B are included. First, the service is the inter-device invocation between the calling party 16A and the called party 16B. The corresponding processes are performed by the two devices respectively to complete the normal invocation of the service.

[0206] First, the invocation of the service starts the process on the calling party 16A side.

[0207] Step (C1), when the service consumption device in the calling party 16A needs to invoke the first service, the calling party 16A will first search the first service in the local database.

[0208] Step (C2), when the calling party 16A searches the first service in the local database, the calling party 16A obtains the service definition from the local database.

[0209] Step (C3), the calling party 16A parses the service definition of the first service.

[0210] Step (C4), the calling party 16A obtains the service invocation parameters from the service definition of the first service.

[0211] Step (C5), the calling party 16A obtains the cross-terminal protocol and attributes from the service definition of the first service.

[0212] In the present application, the calling party 16A obtains the service definition of the first service by performing the service discovery process. The calling party 16A can parse the service definition according to the unified service definition format. The content of the service definition is shown in Table 2.

[0213] After parsing, the calling party 16A can at least obtain the service invocation parameters and the cross-terminal protocol and attributes.

[0214] Step (C6), it is judged whether the calling party 16A supports the cross-terminal protocol.

[0215] Step (C7), when the calling party 16A does not support the cross-terminal protocol, the protocol conversion process is performed.

[0216] Step (C8), when the invoker 16A supports the cross-end protocol, determine the final cross-end protocol and service invocation parameters.

[0217] In the present application, the invoker 16A will query the service consumption device through the system interface whether it directly supports the cross-end protocol invocation. If the invoker 16A does not support the cross-end protocol invocation, the service invocation parameters and the cross-end protocol and attributes will be protocol-converted into cross-end parameters supported by the service consumption device. Subsequently, the invoker 16A will output the final cross-end protocol and service invocation parameters.

[0218] Step (C9), based on the final cross-end protocol and service invocation parameters, the invoker 16A generates and applies the cross-end protocol Proxy to transmit the corresponding service parameters.

[0219] It should be noted that in one possible way, during the process performed in step 1619, the invoker 16A can perform an authentication process with the callee 16B. The authentication process can assist the invoker 16A to identify the identity of the callee 16B, and can also assist the callee 16B to identify the identity of the invoker 16A. The present application does not limit the specific authentication process.

[0220] It should be noted that the cross-end protocol Proxy is used to serialize the corresponding service parameters and transmit them to the callee 16B through the network.

[0221] Step (C10), the callee 16B receives the service parameters transmitted by the invoker 16A based on the cross-end protocol Stub.

[0222] Step (C11), the callee 16B transmits the service parameters to the service provider in the callee 16B.

[0223] Step (C12), the callee 16B executes the first service based on the service parameters and feeds back the service result.

[0224] In step (C12), the callee 16B can execute the first service that has been locally registered based on the service parameters, and then feed back the service result to the invoker 16A.

[0225] Step (C13), the callee 16B feeds back the service result based on the cross-end protocol Stub.

[0226] Step (C14), the invoker 16A receives the service result based on the cross-end protocol Proxy, and feeds back the service result to the service consumption device.

[0227] A method for inter-device service invocation provided by the present application will be introduced below in a video relay scenario. Scenario description: a mobile phone is playing a video. When the mobile phone is close to a TV, the video continues to play on the TV from the current progress of the mobile phone, and the video in the mobile phone exits. Precondition: both the mobile phone and the TV are installed with a video playing service. It should be noted that the existence of a service of type video playing in the mobile phone means that the mobile phone is installed with the video playing service, and the existence of a service of type video playing in the TV means that the TV is installed with the video playing service.

[0228] Service definition related to video relay: the service implementation is in the com.oplus.pantanal.example application, and the corresponding service definition is in AndroidManifest.xml. It should be noted that the installation package name of the foregoing application and the xml file in which the service definition is placed can be changed as needed. Illustratively, the video relay related application settings can be set according to the following pseudo code:

[0229]

[0230]

[0231] Illustratively, the definition information of the service involved in the video relay can be stored in an xml file, and the specific information can be referred to as follows:

[0232]

[0233] In the present scenario, the service registration process is introduced. After the TV is turned on, the local applications are scanned according to the process shown in Figure 13 , and the xml file of the service definition above is obtained. Thus, the definition information of the service is obtained from the xml file of the service definition, stored in the local service registration center (i.e., the database locally of the TV), and synchronized to the service registration center (i.e., the database locally of the mobile phone) of the mobile phone through the near field WIFI connection.

[0234] In the present scenario, the service discovery process is introduced. The mobile phone is playing a video, and when the mobile phone is close to the TV, the system will prompt the user that there is a large screen TV nearby, which is more suitable for playing the video. Then, the system in the mobile phone will ask the user whether to switch to the TV for playing. After the user selects to switch, the video playing client calls the "service discovery" interface of the "uniform service management" system, and the service type transmitted is Video Player, and the service description above is obtained. The specific process is referred to the process shown in FIG. DK.

[0235] In this scenario, the process of service invocation is introduced. The video playing client invokes the service according to the flow shown in FIG. ED. Since the mobile phone and the television are both Android systems, no protocol conversion step is needed. The mobile phone can directly obtain the cross-terminal protocol and the service parameters from the service definition.

[0236] (1) Cross-terminal protocol: "Android distributed component service", protocol parameters

[0237] "deviceId"=2,

[0238] "PackageName"="com.oplus.pantanal.example",

[0239] "service"=".VideoService"

[0240] "intent"="com.oplus.pantanal.example.call"

[0241] (2) Service parameters:

[0242] Fill the current playing progress and the video source url into the service parameters

[0243]

[0244] In this scenario, the cross-terminal protocol stub accepts a byte stream from the network, obtains the above parameters of the cross-terminal protocol after deserialization, starts the VideoService service through the Android application manager, and inputs the progress and url parameters. Through the process, the television can continue to play the video from the progress position, and the mobile phone closes the video in the mobile phone after obtaining the service invocation result, thereby completing the video relay.

[0245] A related scheme of applying the service invocation method between devices provided in the application to a remote photographing scenario will be introduced below. Scenario description: a user writes in the office software in the computer, needs to take a picture as an illustration in the office software, but it is inconvenient to use the camera of the computer. In this case, the user starts the mobile phone photographing service, and automatically inserts the picture obtained through the mobile phone photographing service into the document. Precondition: the photographing service on the mobile phone has supported "uniform service definition".

[0246] Service definition related to the mobile phone photographing service: the service implementation is in the com.oplus.pantanal.example application, and the corresponding implementation service definition is in the AndroidManifest.xml. It should be noted that the installation package name of the foregoing application and the xml file in which the service definition is placed can be changed as needed. Illustratively, the application settings related to the mobile phone photographing service can be set according to the following pseudo code:

[0247]

[0248] Illustratively, the definition information of the service involved in the remote photographing scenario can be stored in an xml format file, and specific information can be referred to as follows:

[0249]

[0250]

[0251] In the present scenario, the process of service registration is introduced. After the mobile phone is started, the mobile phone scans the local application according to the flow Figure 13 , obtains the xml of the service definition above, stores the xml in the local service registration center, and synchronizes to the service registration center of the computer through the near field WIFI connection.

[0252] In the present scenario, the process of service discovery is introduced. When the user edits a document using the office software in the computer, the user needs to take a photograph as an illustration, and the user clicks the remote photographing service. The remote photographing service calls the "unified service management" system "service discovery" interface, and the service type Capture-photo is input, and the service description above is obtained. The specific flow is referred to the process shown in FIG. DK.

[0253] In the present scenario, the process of service calling is introduced. The remote photographing service calls the service according to the flow of FIG. ED. Because the computer is a Windows system, it does not support the Android service type, but supports the HTTP protocol type, and the Android service parameter is converted into the HTTP protocol by calling the protocol conversion module. The HTTP protocol is a cross-end protocol and the service parameter:

[0254] (1) HTTP cross-end protocol: this is the post content of http, which is transmitted between devices.

[0255] "deviceId"=1,

[0256] "PackageName"="com.oplus.pantanal.example",

[0257] "service" = ".CaptureService"

[0258] "intent" = "com.oplus.pantanal.example.capture"

[0259] "OriginalProtocol" = "Android"

[0260] According to the service definition above, the current defined photo capture service has no input parameters. There is a special parameter, OriginalProtocol, which indicates the protocol type before conversion.

[0261] In this scenario, the cross-end protocol stub accepts a byte stream from the network, deserializes it, and parses it through the http protocol to obtain the parameters above the cross-end protocol. Because "OriginalProtocol" = "Android", the Android application manager is used to start the CaptureService by passing in "intent" = "com.oplus.pantanal.example.capture" and "PackageName" = "com.oplus.pantanal.example". The CaptureService starts the phone camera and takes a photo under the user's guidance. The binary file service result is transmitted to the computer through the network and returned to the office software in the computer. The binary file is returned through the following output parameters.

[0262] <param_out>

[0263] <param id＝"1"name＝"photo"type＝"blob"required＝"true">

[0264] < / param_out>

[0265] Since the application can be user-centered ubiquitous service, it requires multi-device unified operation. Based on multi-device, it is inevitable to be heterogeneous. For example, some are Windows system, some are Android system, and some resource limited devices are RTOS system, so the service running on multi-device is also heterogeneous. In addition, the network connection is also diverse, some devices have the ability to connect to the Internet directly, and some devices only have the connection ability of BLE. Therefore, the method of realizing the deep integration of services on multi-device, supporting heterogeneous service cross-end calling, and supporting end-end / cloud service synchronization is one of the key technologies. Based on the application, the developer of the cross-end scene only needs to focus on the development of the business itself, and the cross-end heterogeneous service discovery, synchronization and calling are completed by the "unified service management" system, which greatly improves the development efficiency. In a quantifiable way, the development efficiency is improved by more than 90%.

[0266] It should be noted that in addition to being able to call the services registered in the called party, the application can also call instant services. Among them, the instant service can be at least one of the small program, the fast application or the micro program. The instant service is a service that does not need to be registered for use. In addition, the application also supports cloud range calling, and has strong expansibility and universality.

[0267] In summary, the service calling method between devices provided by the application has the characteristics of unified service definition. Among them, the application provides a unified service definition method, which can meet the existing and future cross-end heterogeneous services. In a possible way, the service definition is an xml text file, which can be deployed not only in Windows, Android and other systems, but also in resource limited systems such as RTOS.

[0268] Optionally, the service calling method between devices provided by the application has the characteristics of end-cloud integration. Among them, the current mainstream system has realized the end-end synchronization of local area network, and its method cannot cross the local area network. The application breaks through this limitation, and the service not only synchronizes between local area network near field devices, but also can be synchronized through the cloud.

[0269] Optionally, the service calling method between devices provided by the application has the characteristics of decentralization. Among them, the service synchronization method of the application does not have a service registration center, and the failure of any device will not affect the work of other devices, improving the robustness of the system.

[0270] Optionally, the service calling method between devices provided by the application has the characteristics of cross-protocol calling. Among them, the application supports cross-protocol calling of heterogeneous services, such as HTTP calling Android service. Android service can also call HTTP service, which expands the ability of intercommunication between devices.

[0271] The following is an apparatus embodiment of the present application, which can be used to perform the method embodiments of the present application. For details not disclosed in the apparatus embodiments of the present application, refer to the method embodiments of the present application.

[0272] Please refer to Figure 17 , Figure 17 is a structural block diagram of an inter-device service calling apparatus provided by an example embodiment of the present application. The inter-device service calling apparatus can be implemented by software, hardware or a combination of both to become all or part of a calling party. The apparatus comprises:

[0273] a service discovery module 1710, configured to discover a first service from a service registry center local to the calling party, the service registry center being configured to store registered services in the calling party and registered services in a called party, the first service being a registered service in the called party.

[0274] a protocol acquisition module 1720, configured to parse definition information of the first service to obtain a first service protocol supported by the called party.

[0275] a first conversion module 1730, configured to, in response to the calling party not supporting the first service protocol, convert the service parameters according to a specification of a second service protocol to obtain cross-end parameters, the service parameters being used to provide the first service to obtain a corresponding service result, the cross-end parameters being parameters in the second service protocol supported by the calling party.

[0276] a service calling module 1740, configured to call the first service based on the cross-end parameters.

[0277] In an optional embodiment, the service calling module 1740 is configured to send the cross-end parameters to the called party, and receive service results fed back by the called party, the service results being data obtained by the first service in the called party after running based on the cross-end parameters.

[0278] In an optional embodiment, the service calling module 1740 is configured to serialize the cross-end parameters through a first cross-end protocol to obtain serialized cross-end parameters, and send the serialized cross-end parameters to the called party, the serialized cross-end parameters being used to be deserialized based on a second cross-end protocol in the called party to obtain the cross-end parameters.

[0279] In an optional embodiment, the service discovery module 1710 is configured to call a first unified service governance module through a service gateway interface in the calling party, and find the first service from the service registry center local to the calling party based on the first unified service governance module.

[0280] In an optional embodiment, the apparatus further comprises a first registration module configured to, in response to a first registration service request, invoke a first unified service governance module; register, based on a registration function of the first unified service governance module, a second service corresponding to the first registration service request in the service registry center local to the invoker; and synchronize, based on a synchronization function of the first unified service governance module, the second service to the callee.

[0281] In an optional embodiment, the first unified service governance module involved in the apparatus comprises an application layer part and a domain layer part, the application part comprises at least one of a service registration function, a service discovery function, a service scheduling function, a service update function, a service removal function and a service synchronization function; and the domain layer part comprises at least one of a service definition management, a service protocol management and a service authorization management.

[0282] In an optional embodiment, the definition information involved in the apparatus is stored in a service package of the first service in a form of a target file format, and the target file format is used to provide text information across platforms.

[0283] In an optional embodiment, the definition information involved in the apparatus comprises at least one of a service name, a service type, a service protocol and input / output parameters of the service.

[0284] In an optional embodiment, the service protocol involved in the apparatus comprises at least one of a protocol type, a service unique identifier and protocol attributes; and the input / output parameters of the service comprise at least one of input parameters and output parameters.

[0285] In an optional embodiment, the input parameters involved in the apparatus comprise at least one of a first parameter name, a first data type, a first default value and a first necessary flag, the first necessary flag being used to indicate whether the input parameter is necessary; and the output parameters comprise at least one of a second parameter name, a second data type, a second default value and a second necessary flag, the second necessary flag being used to indicate whether the output parameter is necessary.

[0286] Please refer to Figure 18 , Figure 18 is a structural block diagram of another apparatus-to-apparatus service invocation apparatus provided by an exemplary embodiment of the present application. The apparatus-to-apparatus service invocation apparatus can be realized by software, hardware or a combination of both to become all or part of a callee. The apparatus comprises:

[0287] A parameter receiving module 1810 configured to receive cross-end parameters from an invoker, the cross-end parameters being parameters in a second service protocol supported by the invoker.

[0288] The second conversion module 1820 is configured to convert the cross-end parameter to obtain a service parameter in the first service agreement supported by the called party.

[0289] The service running module 1830 is configured to run the first service based on the service parameter to obtain a service result.

[0290] The result feedback module 1840 is configured to feed back the service result to the calling party.

[0291] In an optional embodiment, the apparatus further comprises a second registration module, which is configured to, in response to a second registration service request, invoke a second unified service governance module; based on a registration function of the second unified service governance module, register the first service corresponding to the second registration service request at a local end of the called party; and based on a synchronization function of the second unified service governance module, synchronize the first service to the calling party.

[0292] The embodiments of the present application further provide a computer readable medium, which stores at least one instruction, and the at least one instruction is loaded and executed by the processor to implement the service calling method between devices as described in the above various embodiments.

[0293] It should be noted that the device-to-device service calling apparatus provided in the above embodiments is only used to execute the device-to-device service calling method, and the above-mentioned functions are completed by different functional modules in actual application, that is, the internal structure of the device is divided into different functional modules to complete all or part of the above-described functions. In addition, the device-to-device service calling apparatus and the device-to-device service calling method provided in the above embodiments belong to the same concept, and the specific implementation process is described in the method embodiments, which will not be repeated here.

[0294] The serial numbers of the above embodiments of the present application are only for description, and do not represent the advantages or disadvantages of the embodiments.

[0295] Those skilled in the art can understand that all or part of the above-mentioned steps can be completed by hardware, or by program to instruct related hardware to complete, and the program can be stored in a computer readable storage medium, and the above-mentioned storage medium can be read-only memory, disk or optical disk, etc.

[0296] The above description is only an exemplary embodiment of the present application, and does not limit the present application, and any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A method of service invocation between devices, characterized by, Applied to a calling party, the method comprises: Discovering a first service from a service registry center local to the calling party, the service registry center being configured to store registered services in the calling party and registered services in a called party, the first service being a registered service in the called party; Parsing definition information of the first service to obtain a first service protocol supported by the called party; In response to the calling party not supporting the first service protocol, converting service parameters according to a specification of a second service protocol to obtain cross-end parameters, the service parameters being used to provide the first service to obtain corresponding service results, the cross-end parameters being parameters in the second service protocol supported by the calling party; Sending the cross-end parameters to the called party; Receiving service results fed back by the called party, the service results being data obtained by running the service parameters converted by the first service in the called party based on the cross-end parameters.

2. The method of claim 1, wherein, The sending of the cross-end parameters to the called party comprises: Serializing the cross-end parameters through a first cross-end protocol to obtain serialized cross-end parameters; Sending the serialized cross-end parameters to the called party, the serialized cross-end parameters being used to be deserialized based on a second cross-end protocol in the called party to obtain the cross-end parameters.

3. The method according to claim 1 or 2, characterized in that, The discovering of the first service from the service registry center local to the calling party comprises: Invoking a first unified service governance module through a service gateway interface in the calling party; Based on the first unified service governance module, searching for the first service from the service registry center local to the calling party.

4. The method according to claim 1 or 2, characterized in that, Before the discovering of the first service from the service registry center local to the calling party, the method further comprises: In response to a first registration service request, invoking a first unified service governance module; Based on a registration function of the first unified service governance module, registering a second service corresponding to the first registration service request in the service registry center local to the calling party; Based on a synchronization function of the first unified service governance module, synchronizing the second service to the called party.

5. The method of claim 4, wherein, The first unified service governance module comprises an application layer part and a domain layer part, the application layer part comprising at least one of a service registration function, a service discovery function, a service scheduling function, a service update function, a service removal function and a service synchronization function; the domain layer part comprising at least one of service definition management, service protocol management and service authorization management.

6. The method of claim 1, wherein, The definition information is stored in a service package of the first service in the form of a target file format, the target file format being used to provide text information across platforms.

7. The method of claim 6, wherein, The definition information comprises at least one of a service name, a service type, a service protocol and input / output parameters of the service.

8. The method of claim 7, wherein, The service protocol comprises at least one of a protocol type, a service unique identifier and protocol attributes; the input / output parameters of the service comprise at least one of input parameters and output parameters.

9. The method of claim 8, wherein, The input parameter comprises at least one of a first parameter name, a first data type, a first default value and a first necessary mark used for indicating whether the input parameter is necessary; and the output parameter comprises at least one of a second parameter name, a second data type, a second default value and a second necessary mark used for indicating whether the output parameter is necessary.

10. A method of service invocation between devices, characterized by, Applied to the called party, the method comprises: Receiving a cross-terminal parameter from a calling party, the cross-terminal parameter being a parameter in a second service protocol supported by the calling party; Converting the cross-terminal parameter to obtain a service parameter in a first service protocol supported by the called party, the calling party not supporting the first service protocol; Running the first service based on the service parameter to obtain a service result; Feeding back the service result to the calling party.

11. The method of claim 10, wherein, The method further comprises: In response to a second registration service request, calling a second unified service management module; Based on a registration function of the second unified service management module, registering the first service corresponding to the second registration service request in the local terminal of the called party; Based on a synchronization function of the second unified service management module, synchronizing the first service to the calling party.

12. An apparatus-to-apparatus service invocation device, characterized by: Applied to the calling party, the device comprises: A service discovery module for discovering a first service from a service registration center in the local terminal of the calling party, the service registration center being used for storing registered services in the calling party and registered services in the called party, the first service being a registered service in the called party; A protocol acquisition module for parsing definition information of the first service to obtain a first service protocol supported by the called party; A first conversion module for converting a service parameter into a cross-terminal parameter according to a specification of a second service protocol in response to the calling party not supporting the first service protocol, the service parameter being used for providing the first service to obtain a corresponding service result, the cross-terminal parameter being a parameter in the second service protocol supported by the calling party; A service calling module for sending the cross-terminal parameter to the called party; The service calling module is further used for receiving a service result fed back by the called party, the service result being data obtained by running the service parameter based on the cross-terminal parameter in the first service in the called party.

13. An apparatus-to-apparatus service invocation device, characterized by: Applied to the called party, the device comprises: A parameter receiving module for receiving a cross-terminal parameter from a calling party, the cross-terminal parameter being a parameter in a second service protocol supported by the calling party; A second conversion module for converting the cross-terminal parameter to obtain a service parameter in a first service protocol supported by the called party, the calling party not supporting the first service protocol; A service running module for running the first service based on the service parameter to obtain a service result; A result feeding back module for feeding back the service result to the calling party.

14. A caller device, comprising: The calling device comprises a processor, a memory connected to the processor, and program instructions stored in the memory, and the processor executes the program instructions to implement the service calling method between devices as claimed in any one of claims 1 to 9.

15. A callee device, comprising: The called device comprises a processor, a memory connected to the processor, and program instructions stored in the memory, and the processor executes the program instructions to implement the service calling method between devices as claimed in claim 10 or 11.

16. A computer readable storage medium having program instructions stored therein, the program instructions being executable by a processor to perform operations comprising: The program instructions are executed by the processor to implement the service calling method between devices as claimed in any one of claims 1 to 9.

17. A computer readable storage medium having program instructions stored therein, the program instructions being executable by a processor to perform operations comprising: The program instructions are executed by the processor to implement the service calling method between devices as claimed in claim 10 or 11.

18. A computer program product, characterised in that, The computer program product comprises computer instructions stored in a computer readable storage medium; A processor of a computer device reads the computer instructions from the computer readable storage medium, and the processor executes the computer instructions to enable the computer device to perform the service calling method between devices as claimed in any one of claims 1 to 9.

19. A computer program product, characterised in that, The computer program product comprises computer instructions stored in a computer readable storage medium; A processor of a computer device reads the computer instructions from the computer readable storage medium, and the processor executes the computer instructions to enable the computer device to perform the service calling method between devices as claimed in claim 10 or 11.

20. An inter-device service invocation system, characterized by The system comprises a calling device and a called device, the calling device is configured to perform the service calling method between devices as claimed in any one of claims 1 to 9, and the called device is configured to perform the service calling method between devices as claimed in claim 10 or 11.

Images