The Distributed Scheduler sets up a distributed service platform in OpenHarmony by using a proxy between the primary and secondary devices. With the distributed scheduler, the primary device \(OpenHarmony-powered smart TV\) can start a Feature Ability \(FA\) deployed on the secondary device \(a memory-constrained OpenHarmony device such as a lite wearable\). The following figure shows the components of the Distributed Scheduler.
The Distributed Scheduler is used for cross-device component management. It allows the local device to access or control remote components, and enables application collaboration in distributed scenarios. The following figure shows the modules in the Distributed Scheduler.
<tdclass="cellrowborder"valign="top"width="50%"headers="mcps1.1.3.1.2 "><pid="p541645611177"><aname="p541645611177"></a><aname="p541645611177"></a>Implementation logic of the Distributed Scheduler</p>
<tdclass="cellrowborder"valign="top"width="50%"headers="mcps1.1.3.1.2 "><pid="p541645611177"><aname="p541645611177"></a><aname="p541645611177"></a>Implementation of the Distributed Scheduler</p>
<tdclass="cellrowborder"valign="top"width="50%"headers="mcps1.1.3.1.2 "><pid="p04163569170"><aname="p04163569170"></a><aname="p04163569170"></a>Implementation logic of system service processes</p>
<tdclass="cellrowborder"valign="top"width="50%"headers="mcps1.1.3.1.2 "><pid="p13417125611175"><aname="p13417125611175"></a><aname="p13417125611175"></a>Implementation logic of local service management</p>
<tdclass="cellrowborder"valign="top"width="50%"headers="mcps1.1.3.1.2 "><pid="p04163569170"><aname="p04163569170"></a><aname="p04163569170"></a>Implementation of the foundation process</p>
</td>
</tr>
</tbody>
...
...
@@ -45,13 +40,13 @@ The source code directory structure of the Distributed Scheduler is as follows:
│ ├── distributed_schedule_service.h # Header file for the open APIs provided by the Distributed Scheduler
│ ├── dmslite_check_remote_permission.h # Header file for the permission management module of the Distributed Scheduler
│ ├── dmslite_famgr.h # Header file for the FA management module of the Distributed Scheduler
│ ├── dmslite_inner_common.h # Header file for the service files of the Distributed Scheduler
│ ├── dmslite.h # Header file for the implementation of the Distributed Scheduler
│ ├── dmslite_inner_common.h # Internal common file for the Distributed Scheduler
│ ├── dmslite.h # Header file for the implementation of the Distributed Scheduler Service
│ ├── dmslite_log.h # Header file for the log module
│ ├── dmslite_msg_parser.h # Header file for communication data deserialization
│ ├── dmslite_msg_parser.h # Header file for the distributed message parsing module
│ ├── dmslite_tlv_common.h # Header file for the TLV data parsing module
│ └── dmslite_session.h # Header file for enabling cross-device communication
├── README.md
│ └── dmslite_session.h # Header file for the inter-device communication module
├── readme.md
├── LICENSE
├── source
├── distributed_schedule_service.c
...
...
@@ -65,69 +60,59 @@ The source code directory structure of the Distributed Scheduler is as follows:
## Constraints<a name="section1718733212019"></a>
- Language: C
- Networking: Devices must be on the same LAN.
- Operating system: OpenHarmony
**Language**: C or C++
**Networking environment**: The primary and secondary devices must be on the same LAN and can ping each other.
**Operating system**: OpenHarmony
**Limitations and constraints on remote startup**:
- Only FAs can be started remotely. Remote startup is unavailable to abilities using the Service template.
- Before the remote startup, ensure that the primary and secondary devices are on the same network segment and can ping each other. Otherwise, the remote startup fails.
- Before the remote startup, ensure that the distributed networking between the primary and secondary devices is successful. Otherwise, the remote startup fails.
## Usage<a name="section10729231131110"></a>
**Compiling the Distributed Scheduler**
-**Compiling the Distributed Scheduler**
The distributed scheduler uses some feature macros to customize the function code to be compiled on different platforms. The function code is stored in **build\\lite\\config\\subsystem\\distributedschedule\\**. The directory structure is as follows:
The code of the Distributed Scheduler is stored in the following directory:
Modify the **BUILD.gn** file when compiling code for different platforms. The following code snippet uses code compilation for the Hi3518EV300 and Hi3516DV300 development boards as an example:
When compiling the code for a specific platform, you need to specify the target platform. The following code snippet uses code compilation for the Hi3516DV300 platform as an example:
"//foundation/distributedschedule/services/dtbschedmgr_lite:dtbschedmgr", // Configure the distributed scheduler.
]
}
}
python build.py ipcamera -p hi3516dv300_liteos_a
```
**\* Primary device development**\(taking FA startup as an example\)
-**Primary device development**\(taking FA startup as an example\)
Create a **Want** instance. You should first create an **ElementName** object with **deviceId**, **bundleName**, and **abilityName** specified and add this object to the **Want** instance. Then, set the multi-device startup flag **Want.FLAG\_ABILITYSLICE\_MULTI\_DEVICE** to the **Want** instance to enable remote FA startup.
Create a **Want** instance to set the remote device ID, bundle name, and ability class name of the target FA and set the **Want.FLAG\_ABILITYSLICE\_MULTI\_DEVICE** flag to enable distributed startup.
```
// Import related header files.
import ohos.aafwk.ability.Ability;
import ohos.aafwk.content.Want;
import ohos.bundle.ElementName;
// Start the remote FA on the secondary device.
Want want = new Want(); // Create a Want instance that encapsulates information about the remote FA to start.
ElementName name = new ElementName("remote_device_id", "com.huawei.remote_package_name", "remote_class_name");
// Create a Want instance that will be passed to the startAbility method.
Want want = new Want();
ElementName name = new ElementName(remote_device_id, "com.huawei.remote_bundle_name", "remote_ability_name");
want.setElement(name); // Add information about the target FA for startup to the Want instance.
want.setFlags(Want.FLAG_ABILITYSLICE_MULTI_DEVICE); // Set the multi-device startup flag. If this flag is not set, remote FA startup will be unavailable.
// Start the remote FA on the secondary device.
startAbility(want); // Start the specified FA based on the want parameter. If the name and type of the want parameter are different from those used in the IDE, use the parameter name and type in the IDE.
```
**\* Prerequisites**
**Networking between the primary and secondary devices**: Before the remote startup, ensure that the two devices are on the same network segment and can ping each other. Otherwise, the remote startup fails.
-**Prerequisites**
**FA installation on the secondary device**: Before the remote startup, ensure that the target FA has been installed on the secondary device.
The target FA with the specified bundle name must have been installed on the secondary device.
**\* Execution**\(taking FA startup as an example\)
-**Execution**\(taking FA startup as an example\)
Call **startAbility** on the primary device \(smart TV\) to start the FA of the secondary device \(memory-constrained device such as a lite wearable\).
Call the **startAbility** method on the primary device to start the target FA on the secondary device.
