- [Developing a Feature of a Service](#section11510542164514)
- [Developing an External API for Intra-Process Communication](#section1685211117463)
- [Invoking a Service in the Same Process](#section3690162916462)
- [Developing an External API for IPC](#section9220246194615)
- [Invoking a Service in Another Process](#section114372711475)
- [Developing a Client Proxy for Inter-Process Service Invocation](#section09341923114710)
- [Repositories Involved](#section10365113863719)
## Introduction<a name="section11660541593"></a>
Due to limited platform resources, a unified system ability \(SA\) framework is provided to harmonize differences of hardware architectures \(for example, RISC-V, Cortex-M, and Cortex-A\), resources, and running modes. Two types of hardware platforms \(M- and A-core\) are defined.
- M-core: hardware platforms with Cortex-M or equivalent processing capabilities. The system memory is generally less than 512 KB. There is only a lightweight file system that can be used in limited scenarios, or no file system at all. M-core platforms comply with the Cortex Microcontroller Software Interface Standard \(CMSIS\).
- A-core: hardware platforms with Cortex-A or equivalent processing capabilities. The system memory is greater than 512 KB. There is a comprehensive file system for storing a large amount of data. A-core platforms comply with the Portable Operating System Interface \(POSIX\) specifications.
This service-oriented SA framework enables you to develop services, features, and external APIs, and implement multi-service process sharing and service invoking for inter-process communication \(IPC\). Wherein:
- M core provides services, features, external APIs, and multi-service process sharing development.
- In addition to the capabilities provided by M-core, A-core provides capabilities such as IPC service invoking, permission control for IPC service invoking, and IPC service API development.
Service-oriented architecture
![](figures/en-us_image_0000001128146921.png)
- Provider: a service provider that provides capabilities \(external APIs\) for the system
- Consumer: a service consumer that invokes the features \(external APIs\) provided by the service
- Samgr: an agency that manages capabilities provided by providers and helps consumers discover providers' capabilities
Main objects of the SA framework:
![](figures/en-us_image_0000001081285004.png)
- SamgrLite: provides service registration and discovery.
- Service: implements lifecycle APIs of the service during service development.
- Feature: implements lifecycle APIs of the feature during feature development.
- IUnknown: implements external APIs for services or features based on **IUnknown**.
- IClientProxy: implements the consumer's proxy to send messages during IPC invoking.
- IServerProxy: implements the provider's proxy during IPC invoking, which needs to be implemented by developers.
<tdclass="cellrowborder"valign="top"width="68.7%"headers="mcps1.2.3.1.2 "><pid="p879375920132"><aname="p879375920132"></a><aname="p879375920132"></a>External APIs of the M- and A-core SA frameworks</p>
<tdclass="cellrowborder"valign="top"width="68.7%"headers="mcps1.2.3.1.2 "><pid="p6793059171318"><aname="p6793059171318"></a><aname="p6793059171318"></a>External APIs for service invocation between A-core processes</p>
<tdclass="cellrowborder"valign="top"width="68.7%"headers="mcps1.2.3.1.2 "><pid="p0793185971316"><aname="p0793185971316"></a><aname="p0793185971316"></a>External APIs of the event broadcast service within M- and A-core processes</p>
<tdclass="cellrowborder"valign="top"width="68.7%"headers="mcps1.2.3.1.2 "><pid="p2424318203914"><aname="p2424318203914"></a><aname="p2424318203914"></a>POSIX and CMSIS interface adaptation layer, which is used to harmonize the differences between the APIs of M- and A-core</p>
<tdclass="cellrowborder"valign="top"width="68.7%"headers="mcps1.2.3.1.2 "><pid="p14349257184012"><aname="p14349257184012"></a><aname="p14349257184012"></a>Stub functions for M-core service registration and discovery</p>
<tdclass="cellrowborder"valign="top"width="68.7%"headers="mcps1.2.3.1.2 "><pid="p085522751319"><aname="p085522751319"></a><aname="p085522751319"></a>Basic code for the M- and A-core SA frameworks</p>
<tdclass="cellrowborder"valign="top"width="68.7%"headers="mcps1.2.3.1.2 "><pid="p169681051873"><aname="p169681051873"></a><aname="p169681051873"></a>Registration and discovery for service invocation between A-core processes</p>
<tdclass="cellrowborder"valign="top"width="68.7%"headers="mcps1.2.3.1.2 "><pid="p7839893352"><aname="p7839893352"></a><aname="p7839893352"></a>IPC address management and access control for service invocation between A-core processes</p>
<tdclass="cellrowborder"valign="top"width="68.7%"headers="mcps1.2.3.1.2 "><pid="p16312169179"><aname="p16312169179"></a><aname="p16312169179"></a>Event broadcast service for M- and A-core processes</p>
</td>
</tr>
</tbody>
</table>
## Constraints<a name="section1718733212019"></a>
- The SA framework is developed using the C programming language.
- Services in the same process use **IUnknown** for invoking. Messages are passed to the service through **IUnknown**.
- The service name and feature name must be constant character strings and the length must be less than 16 bytes.
- More-core depends on the Bootstrap service and calls the **OHOS\_SystemInit\(\)** function in the system startup function.
- A-core depends on the Samgr library and calls the **SAMGR\_Bootstrap\(\)** function in the **main** function.
## Developing a Service<a name="section159991817144514"></a>
- Inherit and redefine a service.
```
typedef struct ExampleService {
INHERIT_SERVICE;
INHERIT_IUNKNOWNENTRY(DefaultFeatureApi);
Identity identity;
} ExampleService;
```
- Implement the lifecycle function of the service.