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

El espacio de nombres <SI-Namespace>::skeleton::triggers pone a disposición clases específicas para esqueletos de servicio en el módulo de comunicación com de la AUTOSAR Adaptive Platform con el fin de abordar en el lado del servidor triggers definidos en ServiceInterface. Para cada trigger declarado en el rol trigger, se proporciona una instancia de la clase <Trigger> mediante la cual los proveedores de servicio pueden activar señales de evento hacia clientes conectados. Presumiblemente, la vida útil de estas clases trigger está estrechamente ligada al objeto esqueleto de nivel superior, por lo que su uso presupone la previa inicialización y oferta del servicio correspondiente. Pregunta (abierta) Asimismo, los proveedores de servicio deben tener en cuenta que las invocaciones simultáneas a triggers desde múltiples hilos requerirían presumiblemente una sincronización en el ámbito de la aplicación.

más ›

Contexto

El namespace <SI-Namespace>::skeleton::triggers es un espacio de nombres especializado del módulo de comunicación com de AUTOSAR Adaptive Platform (Release R25-11). Dentro de la arquitectura orientada a servicios (SOA), ServiceInterface constituye la especificación formal de interfaz que define el alcance funcional y los patrones de comunicación entre proveedores de servicios (skeletons) y consumidores de servicios (proxies). Además de métodos para llamadas a funciones síncronas o asíncronas, eventos para la transmisión de datos y fields para propiedades con estado, las interfaces de servicio también pueden contener triggers. Para cada trigger declarado en un ServiceInterface en el rol trigger, el namespace <SI-Namespace>::skeleton::triggers proporciona una clase de trigger de skeleton de servicio <Trigger> propia.

El rol central de estas clases consiste en proporcionar a la aplicación de servidor una abstracción dedicada para la señalización de impulsos de control o notificación. A diferencia de los eventos clásicos, que sirven principalmente para el transporte continuo o controlado por eventos de datos, un trigger señaliza típicamente la ocurrencia de un evento definido o de un cambio de estado. Entre los interlocutores centrales de interacción de las clases de trigger se encuentran la lógica de aplicación proveedora, el skeleton de servicio agregador y el middleware de comunicación de com, el cual asume el reenvío de las señales a través del binding de transporte correspondiente.

Ciclo de vida

El ciclo de vida de las clases de trigger en el namespace <SI-Namespace>::skeleton::triggers está directamente acoplado al skeleton de servicio de nivel superior. Presumiblemente, para cada trigger definido en ServiceInterface se instancia exactamente una instancia de la clase <Trigger> durante la creación del skeleton de servicio y este la gestiona. Pregunta Q-a0d69b49748aa8c4 (abierta) Habitualmente no tiene lugar una creación o destrucción aislada por parte de la aplicación de servicio.

En la fase operativa, el uso se divide en tres fases características: la fase de inicialización, la fase de envío activa y la fase de terminación. Durante la inicialización, la capa de comunicación configura los bindings y recursos necesarios para el trigger. Tan pronto como el proveedor de servicios ofrece oficialmente el servicio en el sistema a través del skeleton, el trigger pasa al estado operativo. En esta fase, la lógica de aplicación puede iniciar repetidamente procesos de activación. Si finaliza la oferta del servicio o se libera el skeleton, también se limpian los recursos de trigger asignados. En lo relativo a la concurrencia, en caso de accionamiento simultáneo del trigger desde varios subprocesos, es probable que se requiera una sincronización del lado de la aplicación, siempre que el framework de comunicación subyacente no garantice una seguridad de subprocesos inherente para llamadas simultáneas a triggers. Pregunta Q-eb23aad9119e9a8f (abierta)

Ruta de uso

La ruta de uso típica para las clases de <SI-Namespace>::skeleton::triggers abarca el flujo completo desde la definición de la interfaz hasta la desactivación del servicio:

• Diseño de interfaz y generación de código: en el modelo de software se define un ServiceInterface que contiene al menos un trigger en el rol trigger. A partir de ello, el generador de código de la plataforma genera el namespace <SI-Namespace>::skeleton::triggers y la clase correspondiente <Trigger>.
• Instanciación del skeleton: la aplicación de servidor instancia la implementación concreta del skeleton de servicio. Interpretación: el acceso a la instancia de <Trigger> se expone al proveedor de servicios a través de la interfaz de miembros del skeleton. Pregunta Q-f287180a040cea33 (abierta)
• Provisión del servicio: el skeleton de servicio inicia la oferta del servicio en la red, de modo que los proxies de cliente puedan encontrar el servicio y registrarse para recibir notificaciones de trigger.
• Disparo del trigger: tan pronto como se cumple una condición de trigger en la lógica de aplicación, el software de servidor invoca el método de disparo en el objeto <Trigger>. La plataforma transmite la señal a todos los consumidores registrados.
• Puesta fuera de servicio: la aplicación de servidor retira la oferta del servicio y destruye la instancia del skeleton, con lo que los objetos de trigger también se desasignan de forma determinista.