Distributed service system based on distributed services

Abstract

The application relates to a distributed service system based on a distributed service, which comprises a local device and a remote device, wherein the local device and the remote device are respectively arranged with a distributed application, a distributed service software development kit, a distributed service management platform and an interconnection service module; the distributed application is used for providing front-end capability components and background atomic capabilities and for issuing a service management request; the distributed service software development kit is used for forwarding the service management request from the distributed application to the distributed service management platform; the distributed service management platform authenticates the service management request from the distributed application and sends the service management request to the remote device through the interconnection service module; and the interconnection service module is used for providing communication capability between devices and supporting near-field short-distance connection and interconnection and intercommunication cloud.

Description

Technical Field

[0001] This invention relates to computer technology, and more specifically to a distributed service system based on distributed services. Background Technology

[0002] The Internet of Things is a future development trend. For example, with the mobile phone as the center, the devices around the user, such as watches, TVs, glasses and mobile phones, are deeply integrated, so that the services and applications running on various devices can flow seamlessly between the user's multiple devices. Summary of the Invention

[0003] The embodiments disclosed herein aim to provide a more stable distributed service system based on distributed services.

[0004] Furthermore, embodiments of this disclosure are also intended to provide a distributed service system based on distributed services that can be used across platforms.

[0005] Furthermore, the embodiments of this disclosure are also intended to provide a distributed service system based on distributed services that supports dynamic service management. Attached Figure Description

[0006] Figure 1 This is a schematic diagram of the overall framework of a distributed service system based on distributed services, according to an embodiment of this disclosure.

[0007] Figure 2 This is a schematic diagram illustrating the construction of a distributed service system based on distributed services, according to an embodiment of this disclosure.

[0008] Figure 3 This is a schematic diagram of the distributed service registration process according to an embodiment of this disclosure.

[0009] Figure 4 This is a schematic diagram of the distributed service discovery process according to an embodiment of this disclosure.

[0010] Figure 5 This is a schematic diagram of the distributed service startup process according to an embodiment of this disclosure.

[0011] Figure 6 This is a schematic diagram of the distributed service connection process according to an embodiment of this disclosure.

[0012] Figure 7 This is a schematic diagram of the distributed service invocation process according to an embodiment of this disclosure.

[0013] Figure 8 This is a schematic diagram of the distributed service migration process according to an embodiment of this disclosure. Detailed Implementation

[0014] The following are some embodiments of the present invention, intended to provide a basic understanding of the invention. They are not intended to identify key or decisive elements of the invention or to limit the scope of protection sought.

[0015] For purposes of brevity and illustrativeness, the principles of the invention are described herein primarily with reference to exemplary embodiments thereof. However, those skilled in the art will readily recognize that the same principles are equivalently applicable to all types of distributed service-based systems and that these same principles can be implemented therein, and that any such variations do not depart from the true spirit and scope of this patent application.

[0016] Furthermore, reference is made in the following description to the accompanying drawings, which illustrate specific exemplary embodiments. Electrical, mechanical, logical, and structural modifications may be made to these embodiments without departing from the spirit and scope of the invention. Moreover, while features of the invention are disclosed in conjunction with only one of several embodiments, this feature may be combined with one or more other features of other embodiments if desired and / or advantageous for any given or identifiable function. Therefore, the following description should not be considered limiting in any sense, and the scope of the invention is defined by the appended claims and their equivalents.

[0017] Terms such as “possessing” and “comprising” indicate that, in addition to having units (modules) and steps that are directly and explicitly stated in the specification and claims, the technical solution of the present invention does not exclude the presence of other units (modules) and steps that are not directly or explicitly stated.

[0018] Terms like "local" and "remote" are used to describe the relationship between electronic devices. Local and remote devices are physically different devices that need to communicate via wired or wireless means. The term "different devices" here only indicates that they need to establish communication to connect, not that they are the same type of device. For example, they can be of the same type, such as both being mobile phones; or they can be of different types, such as a mobile phone being the local device and a tablet computer being the remote device.

[0019] In this disclosure, the terms "device" and "electronic device" refer to any device having a memory and a processor coupled to the memory. The memory stores applications that perform various functions, and the processor can execute the applications stored in the memory to perform these functions. For example, an electronic device can be a mobile phone, tablet computer, desktop computer, laptop computer, smart glasses, smart headphones, smart TV, smartwatch, smart bracelet, smart ring, smart car, etc.

[0020] To the inventor's knowledge, the OpenHarmony system is an implementation scheme for the Internet of Things. OpenHarmony includes distributed task scheduling, distributed data management, and a distributed soft bus. The OpenHarmony distributed task scheduling system has the following drawbacks:

[0021] (1) Completely dependent on near-field connectivity: Service interconnection between OpenHarmony devices relies on underlying Wi-Fi and BT / BLE connections. The quality of cross-device service calls depends on the stability of the underlying connections. When the underlying connections are unstable, the quality of service calls is also unstable. When the near-field connections between underlying devices are broken, services between devices cannot reach each other.

[0022] (2) Service calls between systems are not supported: OpenHarmony devices can only access devices running the OpenHarmony system in the near field. Services between different devices cannot access each other. For example, a mobile phone running Android cannot access the glasses service running OpenHarmony.

[0023] (3) Does not support dynamic service management: OpenHarmony distributed task scheduling services only support static registration, that is, the service is pre-installed in the device as a system application throughout the entire operation, and the service cannot be installed, run, stopped and deleted as needed.

[0024] Before describing the distributed service system based on distributed services in the embodiments of this disclosure, a brief explanation will be given of the abbreviations of related technical terms used in the text.

[0025] (1) WLAN (Wireless Local Area Network): Wireless Local Area Network.

[0026] (2) RPC (Remote Procedure Call): Remote procedure call.

[0027] (3) BT (Bluetooth): Bluetooth.

[0028] (4) BLE (Bluetooth Low Energy): Low power Bluetooth.

[0029] (5) FA (Front Ability): Front-end capability component, which provides a user interface that can interact with users and can connect to BPA located locally or remotely.

[0030] (6)BPA (Background Particle Ability): Background atomic capability, providing atomic functions to the local or remote FA.

[0031] (7) SDK (Software Development Kits): Software development toolkits.

[0032] (8) API (Application Programming Interface): Software programming interface.

[0033] (9) DARS (Distributed Ability Register Service): Distributed registration service.

[0034] (10) DASS (Distributed Ability Start Service): Distributed Ability Start Service.

[0035] (11) ATMS / AMS (Application Task Manager Service): Application Task Manager / Application Task Management Module.

[0036] (12) Binder: A method of inter-process communication in Android system.

[0037] (13) Ability includes two types: FA (Feature Ability) and PA (Particle Ability). FA represents a user interface capability, used to provide the ability to interact with the user. PA refers to atomic services, which are indivisible atomic services, representing a user interface capability, used to provide the ability to run tasks in the background.

[0038] Figure 1 This is a schematic diagram of the overall framework of a distributed service system based on distributed services, according to an embodiment of this disclosure.

[0039] like Figure 1 As shown, the overall framework of the distributed service in the embodiments of this disclosure can be divided into a distributed application 100, a distributed service SDK (i.e., a distributed service software development kit) 200, a distributed service management platform 300, and an interconnection service 400 (also referred to as a "distributed soft bus").

[0040] Distributed Application 100 provides two types of distributed components: FA (Feature Ability): front-end capability components, and BPA (Background Particle Ability): back-end atomic capabilities. FA provides an interactive user interface, similar to a mini-program on Android. BPA connects to a local or remote device and provides specific functions to the user via Remote Procedure Call (RPC). For example, a navigation FA runs on glasses, connects to a mobile phone navigation BPA, obtains the navigation path via RPC, and finally displays the navigation route on the glasses.

[0041] The Distributed Services SDK 200 provides a distributed services API, which allows system applications or third-party applications to quickly and easily provide and access distributed services in a low-code manner.

[0042] The distributed service management platform 300 (e.g., mobile phone, glasses) is a system service of the underlying operating system, running on all devices that need to provide or access distributed services. The distributed service SDK 200 connects to the distributed service management platform 300 via inter-process communication (IPC) and forwards all service management requests from the distributed application 100, including but not limited to capability registration, capability discovery, capability migration, capability invocation, and capability lifecycle management. The distributed service management platform authenticates the applications and sends service requests to remote devices via the interconnect service module 400 (also known as the "distributed soft bus").

[0043] The Interconnection Service Module 400 provides communication capabilities between user devices, including: support for near-field short-range connections, such as BT, BLE, Wi-Fi, NFC, UWB, Zigbee, etc.; and the ability to enable communication between devices through the Interconnection Cloud when connections between devices are unavailable.

[0044] Next, the detailed architecture and process of the distributed service system based on distributed services according to the embodiments of this disclosure will be described.

[0045] The following explanation uses the Android system as an example. This architecture is also applicable to other operating systems, such as Windows and iOS.

[0046] First, the detailed architecture of the distributed service system based on distributed services according to the embodiments of this disclosure will be described.

[0047] Figure 2 This is a schematic diagram illustrating the construction of a distributed service system based on distributed services, according to an embodiment of this disclosure.

[0048] like Figure 2 As shown, the Distributed Service SDK 200 provides the Distributed Ability Manager API Suite 201. The Distributed Ability Manager API Suite 201 provides the basic class front-end capability component (FA) and back-end atomic capability (BPA). Applications inherit from this class and implement its extension interface. It also provides Intent and Operation interfaces to express the remote services that need to be started. It also provides IAbilityConnection and IremoteObject to handle service connections and RPC calls with remote devices.

[0049] In some embodiments, the distributed service SDK200 further includes:

[0050] (1) AbilitySearch module 202: Implements distributed service search function by calling the Distributed Ability Registration Service Management module 208;

[0051] (2) AbilityInsallerObserver 203: Dynamically monitors the distributed service installation function by listening to the Distributed Ability Registration Service Management Module (DARS Manager) 208;

[0052] (3) FeatureAbilityStarter 204: Starts the distributed service through the Distributed Discovery Service Manager 208;

[0053] (4) PA Connection Module (ParticleAbilityConnector) 205: Connects to remote distributed services through the Distributed Discovery Service Management Module (DASS Manager);

[0054] (5) AbilityContinuationManager 206: Implements distributed service continuity management through the Distributed Discovery Service Manager 209;

[0055] (6) AbilityLifecycleObserver 207: Implements distributed service lifecycle management through the Distributed Discovery Service Manager 209;

[0056] (7) Distributed Capability Registration Service Management Module (DARS Manager) 208: Accesses the Distributed Service Registration Service (DARS) via IPC; it is the proxy object of DARS in the Distributed Service SDK; and

[0057] (8) Distributed Service Discovery Management Module (DASS Manager) 209: Accesses the Distributed Service Discovery Service (DASS) via IPC and is the proxy object of DASS in the Distributed Service SDK.

[0058] The Distributed Service Management Platform 300 includes: Distributed Capability Registration Service (DARS) and Distributed Capability Launch Service (DASS).

[0059] The Distributed Capability Registration Service (DARS) implements local distributed service registration and discovery functions. By interacting with the system's PMS (Package Manager Service) 301, it filters distributed services from PMS 301 based on the tags of distributed services in AndroidManifext.xml and stores them in the Ability Database (AbilityDB) 302. PMS 301 is used to record the metadata of all applications on the device.

[0060] The Distributed Capability Registration Service (DARS) includes the following modules:

[0061] (1) Ability Registration Module (AbilityRegister) 303: Responsible for distributed service registration and discovery logic processing;

[0062] (2) AbilityValidator Module 304: Responsible for business logic processing such as integrity verification and permission verification of distributed services;

[0063] (3) AbilityUpdator Module 305: Responsible for handling distributed service update business logic; and

[0064] (4) Ability Status Management Module (AbilityStatusManager) 306: Responsible for handling the business logic of updating the status of distributed services.

[0065] The Distributed Capability Startup Service (DASS) utilizes the operating system's application management functions. In the Android system, this is achieved through the application task management module 307 (i.e., ATMS / AMS, where ATMS refers to ActivityTaskManagerService and AMS refers to ActivityManagerService). The Distributed Capability Startup Service (DASS) includes the following modules:

[0066] (1) Distributed capability lifecycle management module (FeatureAbilityLifecycleMgr) 308: Through interaction with the application task management module 307, it realizes the lifecycle management of distributed capabilities;

[0067] (2) AbilityContinuationSchedule 309: Save the local distributed service context parameters, and transmit the context service parameters, as well as the application and name of the distributed service, to the remote device through the interconnect service. After the distributed service on the remote device starts successfully, the local distributed service stops.

[0068] (3) PA Binding Management Module (ParticleAbilityBindingMgr) 310: Reverses the connection to the distributed services registered by the application, proxies remote distributed service consumers, calls local distributed services, and sends the call results to remote devices through interconnection services; and

[0069] (4) AbilityLifecycleMonitor 311: Used to monitor the lifecycle of a capability.

[0070] Figure 3 This is a schematic diagram of the distributed service registration process according to an embodiment of this disclosure.

[0071] like Figure 3 As shown, the distributed service registration process of this disclosure includes:

[0072] Step S1: After the DARS capability registration module 303 is initialized, it listens for changes in the installation package. When a new application is installed, the capability registration module 303 will receive a notification and obtain the distributed component metadata (if any) of the newly installed application from the PMS 301.

[0073] Step S2: Obtain the distributed component metadata for the newly installed application from PMS 301, specifically based on the component's...<action android:name="com.upuphone.action.DISTRIBUTE" / > Filter and parse the metadata to obtain information such as description, and store it in the capability database 302;

[0074] Step S3: The distributed component information is notified to the capability registration module 303 on the device within the network via the interconnect service proxy module 321 and the interconnect service module 400 (see reference). Figure 3 (Right side of the middle);

[0075] Step S4: The capability registration module 303 on the device within the network checks if any application is interested in this distributed capability (see reference). Figure 3 (middle right side); and

[0076] Step S5: Install the observation module 203 on the network device to send the distributed capability information to the distributed capability application (see reference). Figure 3 (Right side of the middle)

[0077] Figure 4 This is a schematic diagram of the distributed service discovery process according to an embodiment of this disclosure.

[0078] like Figure 4 As shown, the distributed service discovery in embodiments of this disclosure includes the following process:

[0079] Step S1: Distributed capability consumers, such as the card-based lightweight application for glasses, initiate capability search requests through the capability search module 202 of the distributed service SDK. The request may include parameters such as device identifier (if not included, all devices in the network will be polled in turn to initiate capability search requests), capability type, etc.

[0080] Step S2: The capability search module 202 pushes the capability search request of the distributed capability application to the capability registration module 303 of DARS through the binder interface. The capability registration module 303 verifies whether the search application has the corresponding permissions through the capability verification module 304.

[0081] Step S3: Send the data to the corresponding Internet service proxy module 321 via the Internet service module 400;

[0082] Step S4: The remote capability registration module 303 receives the search request, performs integrity verification, and further verifies permissions through the capability verification module 304; and

[0083] Step S5: Retrieve the distributed services of the current device from the capability database 302 and return them to the distributed capability applications of the original device along the path.

[0084] Figure 5 This is a schematic diagram illustrating the process of starting a distributed service according to an embodiment of this disclosure. Figure 5 As shown, the distributed service startup of an embodiment of this disclosure includes the following steps:

[0085] Step S1: The distributed application finds the distributed capability through the capability search module, or notifies the user through the capability installation observation module 203 that a certain distributed capability has been installed. According to the user's intent, the distributed capability needs to be started remotely. The startup parameters include device id, package name, Ability name, Parcel parameters, etc. These parameters will be encapsulated into the Intent / Operation interface.

[0086] Step S2: The distributed capability startup module 204 in the distributed service SDK pushes the request to the distributed capability lifecycle management module 308 of DASS. After receiving the request, the distributed capability lifecycle management module 308 verifies the permissions of the application through the capability verification module 304 and then serializes the startup parameters.

[0087] Step S3: The distributed capability lifecycle management module 308 sends the serialized startup parameters to the remote DASS distributed capability lifecycle management module 308 through the interconnect service module 400.

[0088] Step S4: The distributed capability lifecycle management module 308 of the remote DASS further verifies the existence of the distributed capability on the device through the capability verification module 304 of DARS to prevent impersonation attacks;

[0089] Step S5: The remote distributed capability lifecycle management module 308 starts the distributed capability through the application task management module 307, and at the same time, puts the parameters into the bundle data in the startup Intent.

[0090] Step S6: The application task management module 307 starts the distributed capability and monitors the FA lifecycle management.

[0091] Figure 6 This is a schematic diagram of the distributed service connection process according to an embodiment of this disclosure.

[0092] like Figure 6 As shown, the distributed service connection process of the disclosed embodiment includes the following steps:

[0093] Step S1: Call the distributed capability management API component 201 to implement distributed capability: public FeatureAbility{...} calls the base class connectAbility(DistributeIntent intent,IAbilityConnection connection) method, the intent contains device id, packageName and Abilityname, new IAbilityConnection and implements the onAbilityConnectDone() and onAbilityDisConnectDone() methods;

[0094] Step S2: The PA connection module 205 pushes the connection capability call parameters to the DASS PA binding management module 310 for processing;

[0095] Step S3: PA binding management module 310 records: 1) source ability packagename / abilityname, 2) starting time, 3) target ability packagename / ability, and transmits a connection request (packageName, Abilityname, deviceid, originalpackageName, originalAbilityname) to the destination device through interconnect service module 400;

[0096] Step S4: The remote PA binding management module 310 parses the connection request and uses the application task management module 307 to remotely call the remote atomic service, namely PA (ParticalAbility). The PA base class is also a standard Android service that implements onBind(){}.

[0097] Step S5: The application returns onBind(){} and calls onConnect() to return the implementation of RemoteObject.stub, IRemoteObject BRemoteObject;

[0098] Step S6: The remote PA binding management module 310 records the reference record of BnRemoteObject (BpRemoteObject), (packageName, Abilityname, deviceid, originalpackageName, originalAbilityname), and generates a unique ID (i.e., address).

[0099] Step S7: The triple (address, originalpackageName, originalAbilityname, i.e., address, original package name, original capability name) is transmitted back to the original DASS PA binding management module 310 through the interconnect service module 400. The PA binding management module 310 finds the original application based on the originalpackageName and originalAbilityname, and transmits the address to the original application's PA connection module 205.

[0100] Step S8: PA connection module 205 generates a remote object, puts the address into the remote object, and calls back onAbilityConnectDone (when the remote capability connection is completed) to complete the connection.

[0101] Figure 7 This is a schematic diagram of the distributed service invocation process according to an embodiment of this disclosure.

[0102] like Figure 7 As shown, the distributed service invocation process of this disclosure includes the following steps:

[0103] Step S1: The distributed application generates Parcel data, serializes the input parameters into the data using the data.write*() method, and initiates an RPC call by calling the send request (int command, Parcel data, ReplyListener listener) of the remote object (returned by connectionAblity).

[0104] Step S2: Obtain (1) the address (Note: the address is injected from step S8 of the service connection), (2) the serialized result byte[] parameter (2) from the data, and (3) the original capability information (originalPackage / originalAbilityName) from the RemoteObject.

[0105] Step S3: Transmit the information in (1), (2), and (3) to the PA binding management module 310 of the remote DASS through the interconnection service module 400;

[0106] Step S4: The PA binding management module 310 of the remote DASS obtains (1) address, (2) command, byte[] parameters, and (3) originalPackage / originalAbilityName. Through deviceid, originalPackage, originalAbilityName, address, packageName, and packageAbility, it obtains BpRemoteObject and generates Parcel data and Parcel reply through byte[] parameters. It then calls BpRemoteObject.OnRemoteRequest(command, data, reply, options).

[0107] Step S5: The application performs business logic processing based on the command and data, puts the processing results into the Parcel reply, and sends the command, reply, and options to the PA binding management module 310 of DASS.

[0108] Step S6: PA binding management module 310 serializes the reply and transmits the address, command, and reply to the original PA binding management module 310 through the interconnect service module 400;

[0109] Step S7: Deserialization of reply in PA binding management module 310; and

[0110] Step S8: The PA binding management module 310 calls back the reply listener in the distributed capability management API component 201 of the client.

[0111] Figure 8 This is a schematic diagram of the distributed service migration process according to an embodiment of this disclosure.

[0112] like Figure 8 The distributed service migration shown in this embodiment of the disclosure includes the following steps:

[0113] Step S1: The distributed capability application FA calls the continueAbility() method of the base class FA;

[0114] Step S2: The capability continuous management module 206 calls back the onStartContinuation() method of FA to ask the user whether to migrate. If the user agrees to migrate, it returns "Yes" and the process continues. If the user refuses to migrate, it returns "No" and the process terminates. The capability continuous management module 206 calls back the onSaveData(Parcel savedata, package storage data) method of FA. The business FA stores the FA interface data into savedata (storage data) through the savedata.write*() method.

[0115] Step S3: Capability Duration Table 309 serializes the savedata (storage data) data into byte[]serailizedsavedata, and pushes it to the remote DASS capability duration table 309 through the interconnect service module 400;

[0116] Step S4: The remote capability duration table 309 deserializes byte[]serailizedsavedata (serialized storage data) into Parcel restoredata (packet restore data), and starts the remote service FA through the application task management module 307, passing Parcel restoredata (packet restore data) as a parameter;

[0117] Step S5: The remote SDK calls back the onRestoeData(ParcelrestoreData) method through the capability continuous management module 206;

[0118] Step S6: The business SDK reads the business parameters using the restore.read*() method and displays them in the remote business FA;

[0119] Step S7: Capability Continuous Management Module 206 notifies the migration result to Capability Duration Table 309;

[0120] Step S8: Capability Duration Table 309 notifies the originating endpoint's Capability Duration Table 309 of the migration results via the Interconnect Service Module 400; and

[0121] Step S9: The original SDK calls back the business FA onCompleteContinuation(int resutl), and the original business FA can choose to exit.

[0122] As described above, the distributed service system based on distributed services in this disclosure can enable services to be invoked across devices, and services can intelligently flow freely between different devices according to different usage scenarios. Compared with existing multi-device interconnection solutions, such as Open Harmony, the distributed service system based on distributed services in this disclosure also brings the following technical effects:

[0123] (1) The connection is more stable

[0124] The distributed service system based on distributed services in this embodiment of the disclosure has a more stable connection. When the near-field connection between devices is lost, service discovery and invocation can continue to be completed through the interconnected cloud.

[0125] (2) Supports cross-platform calls

[0126] The distributed service system based on distributed services in this disclosure can be deployed on different platforms. By utilizing cross-terminal calls between local and remote devices, it is possible to enable mutual calls between services on different platforms. In contrast, existing solutions can only support the interconnection of services running on the same type of operating system.

[0127] (3) Supports dynamic service management, allowing users to use and leave immediately.

[0128] The distributed service system based on distributed services in this disclosure can dynamically install, deploy, start, call, stop, and delete services. In contrast, existing solutions can only start, stop, and call system services, and do not implement dynamic service management functions such as dynamic installation, deployment, and deletion.

[0129] The above examples primarily illustrate the distributed service system based on distributed services of the present invention. Although only some specific embodiments of the invention have been described, those skilled in the art should understand that the invention can be implemented in many other forms without departing from its spirit and scope. Therefore, the examples and embodiments shown are to be considered illustrative rather than restrictive, and the invention may cover various modifications and substitutions without departing from the spirit and scope of the invention as defined by the appended claims.

Claims

1. A distributed service system based on distributed services, characterized in that, The distributed service system can be used to connect local devices and remote devices, wherein the local devices and remote devices are respectively equipped with: a distributed application, a distributed service software development kit, a distributed service management platform, and an interconnection service module. The distributed application is used to provide front-end capability components and back-end atomic capabilities, and to issue service management requests. The distributed service software development kit connects to the distributed service management platform via inter-process communication and forwards the service management requests from the distributed application to the distributed service management platform. The distributed service management platform authenticates service management requests from the distributed applications and sends the service management requests to remote devices through the interconnect service module. The interconnection service module is used to provide communication capabilities between devices. The distributed service software development kit includes: The distributed capability management API component is used to implement service connections and remote procedure calls with remote devices. The distributed capability management API component provides basic front-end capability components and back-end atomic capabilities. The distributed capability management API component provides intents and operation interfaces to express the remote services that need to be started. Furthermore, the distributed capability management API component also provides interface capability connections and interface remote objects to handle service connections and RPC calls with remote devices.

2. The distributed service system based on distributed services as described in claim 1, characterized in that, The distributed service software development kit further includes: The distributed registration service management module is used to manage the distributed registration service; and The Distributed Discovery Service Management Module is used to manage the distributed discovery service.

3. The distributed service system based on distributed services as described in claim 2, characterized in that, The distributed service software development kit further includes: The capability search module implements the distributed service search function by calling the distributed registration service management module. The capability installation observation module dynamically monitors the distributed service installation function by listening to the distributed registration service management module. The distributed capability startup module starts the distributed service by calling the distributed discovery service management module. The PA connection module enables the connection of distributed services of remote devices by calling the distributed discovery service management module. The capability continuous management module implements distributed service continuous management by calling the distributed discovery service management module; and The capability lifecycle observation module realizes distributed service lifecycle observation by calling the distributed discovery service management module.

4. The distributed service system based on distributed services as described in claim 3, characterized in that, The distributed service management platform includes: The distributed capability registration service module is used to implement local distributed service registration and distributed service discovery. The distributed capability startup service module is used to implement local distributed service startup, distributed service connection, distributed service invocation, and distributed service migration. The package management service module is used to record metadata for all applications on local and remote devices; The application task management module is used to start, stop, call, and connect to local distributed services; A capability database is used to store data related to distributed capabilities.

5. The distributed service system based on distributed services as described in claim 4, characterized in that, The distributed capability registration service module includes: The capability registration module is used to implement the logic processing of distributed service registration and distributed service discovery; The capability verification module is used to implement the logic processing for verifying distributed services. The capability update module is used to implement the logic processing of distributed service update business; and The capability status management module is used to implement the logic processing of distributed service status update business.

6. The distributed service system based on distributed services as described in claim 5, characterized in that, The distributed capability startup service module includes: The distributed capability lifecycle management module is used to implement lifecycle management of distributed capabilities. A capability duration table is used to store local distributed service context parameters and to transmit these parameters, along with the application and name of the distributed service, to the remote device via the interconnect service module. The local distributed service stops after the remote device's distributed service starts successfully. The PA binding management module is used to reverse connect to the distributed services registered by the application, call the local distributed services, and send the call results to the remote device through the interconnection service module.

7. The distributed service system based on distributed services as described in claim 1, characterized in that, The interconnection service module includes: Near-field short-range connection module, used to support near-field short-range connections; and Interconnected cloud, supporting cloud connectivity based on cloud services.

8. The distributed service system based on distributed services as described in claim 6, characterized in that, The distributed capability registration service module implements distributed capability registration in the following ways: After the local device's capability registration module is initialized, it listens for changes in the installation package. When a new application is installed, the capability registration module will receive a notification and obtain the distributed component metadata of the newly installed application from the local device's package management service module. The distributed component metadata is filtered and parsed to obtain distributed capability information, which is then stored in the local device's capability database. The distributed capability information is notified to the capability registration module of the remote device through the interconnection service module of the local device and the remote device; The remote device's capability registration module checks if any distributed applications are interested in this distributed capability. as well as The distributed capability information is uploaded to the distributed application on the remote device by installing the observation module.

9. The distributed service system based on distributed services as described in claim 6, characterized in that, The distributed capability registration service module implements distributed capability discovery in the following ways: The capability search module of the local device initiates a capability search request for the distributed capability application. The capability search module pushes the capability search request to the capability registration module of the local device, and the capability registration module performs permission verification through the capability verification module of the local device. The ability registration module of the remote device can send the search request to the remote device through the interconnection module of the local device and the remote device; The capability registration module receives the search request, and the capability verification module of the remote device performs permission verification. as well as Retrieve the distributed services of the current device from the capability database of the remote device and return them to the distributed capability applications of the local device along the way.

10. The distributed service system based on distributed services as described in claim 6, characterized in that, The distributed capability startup service module implements distributed capability startup in the following ways: The distributed application on the local device finds the distributed capability through the capability search module of the local device, generates a startup request to start the distributed capability remotely, and the startup request includes startup parameters; The startup request is pushed to the local distributed capability lifecycle management module through the local device's distributed capability startup module, and the local device's capability verification module performs permission verification. The local device's distributed capability lifecycle management module sends the startup parameters to the remote device's distributed capability lifecycle management module through the interconnection service module between the local device and the remote device; The distributed capability lifecycle management module of the remote device performs permission verification through the capability verification module of the remote device; The distributed capability lifecycle management module of the remote device initiates the distributed capability through the application task management module of the remote device.

11. The distributed service system based on distributed services as described in claim 6, characterized in that, The distributed capability startup service module implements distributed service connections in the following ways: The connection capability of the distributed capability is initiated by calling the distributed capability management API component of the local device. The connection request is pushed to the PA binding management module of the local device through the PA connection module of the local device, wherein the connection request includes calling parameters; The PA binding management module of the local device records the call parameters and pushes the connection request to the PA binding management module of the remote device through the interconnection service module of the local device and the remote device; The PA binding management module of the remote device parses the connection request and calls the distributed application of the remote device through the application task management module of the remote device; The distributed application of the remote device returns connection information to the PA binding management module of the remote device. The PA binding management module of the remote device generates a unique ID based on the connection information, wherein the unique ID contains the connection address. The connection information and the unique ID are pushed to the PA binding management module of the local device through the interconnection service module of the remote device and the local device. The local device's PA binding management module locates the original application based on the connection information and transmits the connection address to the original application's PA connection module; and The PA connection module completes the connection based on the connection address.

12. The distributed service system based on distributed services as described in claim 6, characterized in that, The distributed capability startup service module implements distributed service invocation in the following ways: Distributed applications on local devices initiate remote procedure call requests through the distributed capability management API component. The PA binding management module of the local device obtains the remote procedure call request and remote procedure call parameter information accordingly. The remote procedure call parameter information is transmitted to the PA binding management module of the remote device through the interconnection service module of the local device and the remote device; The PA binding management module of the remote device calls the distributed capability management API component of the remote device according to the remote procedure call parameter information; The distributed capability management API component of the remote device performs business logic processing based on the remote procedure call parameter information and returns the remote procedure call processing result to the PA binding management module of the remote device. The PA binding management module of the remote device returns the remote procedure call processing result to the PA binding management module of the local device through the interconnection service module between the remote device and the local device; The PA binding management module calls back the distributed capability management API component of the local device based on the result of the remote procedure call.

13. The distributed service system based on distributed services as described in claim 6, characterized in that, The distributed capability startup service module implements distributed service migration in the following ways: The distributed capability application of the local device calls the capability continuous management module of the local device to issue a capability migration request, wherein the capability migration request includes migration parameters; The local device's capability duration table serializes the migration parameters and pushes them to the remote device's capability duration table through the interconnection service module between the local device and the remote device; The remote device's capability duration table deserializes the serialized migration parameters to obtain the migration parameters, and then starts the remote device's distributed capability management API through the remote device's application task management module. The distributed capability management API of the remote device receives migration parameters and migration results through the capability continuous management module of the remote device. The capability persistence management module of the remote device notifies the remote device of the migration results and the capability duration table; The remote device's capability duration table is notified of the migration results to the local device's capability duration table via the interconnect service module between the remote and local devices; and The local device's capability duration table returns the migration results to the local device's distributed capability management API through the local device's capability duration management module, and then performs the migration.

Images