namespace <SI-Namespace>::skeleton::triggers

Namespace <SI-Namespace>::skeleton::triggers provides specific classes for service skeletons in communication module com of the AUTOSAR Adaptive Platform to address triggers defined in ServiceInterface on the server side. For each declared trigger in role trigger, an instance of class <Trigger> is provided, via which service providers can fire event signals to connected clients. Presumably, the lifetime of these trigger classes is firmly tied to the parent skeleton object, which is why their use requires prior initialization and offering of the respective service. Question (open) Service providers must also consider that concurrent trigger invocations from multiple threads are likely to require application-side synchronization.

more ›

Context

Namespace <SI-Namespace>::skeleton::triggers is a specialized namespace of communication module com of the AUTOSAR Adaptive Platform (Release R25-11). Within the service-oriented architecture (SOA), the ServiceInterface forms the formal interface specification that defines the functional scope and communication patterns between service providers (skeletons) and service consumers (proxies). In addition to methods for synchronous or asynchronous function calls, events for data transmission, and fields for stateful properties, service interfaces can also contain triggers. For each trigger declared in a ServiceInterface in the role trigger, namespace <SI-Namespace>::skeleton::triggers provides a dedicated service skeleton trigger class <Trigger>.

The central role of these classes is to provide the server application with a dedicated abstraction for signaling control or notification impulses. In contrast to classic events, which primarily serve continuous or event-driven data transport, a trigger typically signals the occurrence of a defined event or state change. The central interaction partners of the trigger classes include the providing application logic, the aggregating service skeleton, and the communication middleware of com, which handles forwarding the signals via the respective transport binding.

Lifecycle

The lifecycle of the trigger classes in namespace <SI-Namespace>::skeleton::triggers is directly linked to the parent service skeleton. Presumably, exactly one instance of class <Trigger> is instantiated upon creation of the service skeleton and managed by it for each trigger defined in ServiceInterface. Question Q-a0d69b49748aa8c4 (open) Isolated creation or destruction by the service application does typically not take place.

In the operational phase, usage is divided into three characteristic phases: the initialization phase, the active sending phase, and the termination phase. During initialization, the communication layer sets up the required bindings and resources for the trigger. As soon as the service provider officially offers the service in the system via the skeleton, the trigger transitions to the operational state. In this phase, the application logic can repeatedly initiate triggering operations. If the service offering ends or the skeleton is released, the associated trigger resources are also cleaned up. Regarding concurrency, concurrent trigger actuation from multiple threads is likely to require application-side synchronization unless the underlying communication framework guarantees inherent thread safety for concurrent trigger calls. Question Q-eb23aad9119e9a8f (open)

Usage Path

The typical usage path for the classes from <SI-Namespace>::skeleton::triggers covers the entire sequence from interface definition to deactivation of the service:

• Interface design and code generation: A ServiceInterface containing at least one trigger in the role trigger is defined in the software model. The platform code generator generates the namespace <SI-Namespace>::skeleton::triggers and the associated class <Trigger> from it.
• Instantiation of the skeleton: The server application instantiates the concrete implementation of the service skeleton. Interpretation: Access to the instance of <Trigger> is exposed to the service provider via the member interface of the skeleton. Question Q-f287180a040cea33 (open)
• Service offering: The service skeleton initiates the service offering on the network so that client proxies can find the service and register for trigger notifications.
• Trigger activation: As soon as a trigger condition is met in the application logic, the server software calls the trigger method on the <Trigger> object. The platform transmits the signal to all registered consumers.
• Decommissioning: The server application withdraws the service offering and destroys the skeleton instance, whereby the trigger objects are also deterministically deallocated.