MICROSAR QuickCom employs a service-oriented architecture. This means that software is organized into services that communicate with each other. Each service performs a specific function and can be independently developed, deployed, and maintained.
To understand MICROSAR QuickCom you should know about the following key components of service-oriented architecture:
More information on the general concepts of SOA: Service-oriented architecture (external link)
What is a Service?
A service is a self-contained unit of functionality that performs a specific task or set of tasks. These services are designed to be reusable, interoperable, and loosely coupled, meaning they can operate independently and communicate with other services over a network.
Service Provider and Consumer
Services are offered by the service provider and used by the service consumer. They can be an application, a service or another software component.
For example, an application called MeasurementDisplay that wants to display current data might be asking another application called ControlMonitor for that data. The MeasurementDisplay app would be the service consumer and the ControlMonitor app would be the service provider.
Service Provider and Consumer communicate according to the defined service interfaces.
What is a Service Interface?
The service interface defines how the service can be accessed. It includes the methods and operations that the service exposes to the service consumers.
With MICROSAR QuickCom you define the service interfaces of your executables in the JSON config file. The Proxy/Skeleton API is generated based on the configured service interfaces.
Service Interface Components
MICROSAR QuickCom supports the following service components.
Events | Notifications or occurrences that the service can respond to. A providing application generates an event, which may include a value, when certain conditions are met. A requesting application can subscribe to these events and fetch them. |
Methods | Functions or operations that the service can execute. |
Fields | Data that the service uses or provides. Fields can be considered as status values. Their current value can be retrieved using a get method or changed using a set method. Additionally, an application can receive notifications whenever a Field's value is updated. |
What is the Service Registry?
The service registry is a central directory where services are registered and made discoverable to the service consumers.
The service registry includes:
- Service Registration: Service providers register their services with the registry, including details like service endpoints, interfaces, and metadata.
- Service Discovery: Service consumers query the registry to find available services and obtain the necessary information to interact with them.
- Service Metadata: The registry stores metadata about each service, such as its capabilities, version, and usage policies.
- Access Control: The registry can enforce access rights and policies, ensuring that only authorized consumers can access certain services.
By providing a centralized location for service information, the service registry facilitates efficient communication and integration within an SOA environment.
Service Registration
Applications that provide services register them with the Service Registry as soon as a service is offered.
Service Discovery
Applications that require services query the service registry to locate and utilize these services.