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

El espacio de nombres <SI-Namespace>::proxy::triggers proporciona en el módulo com de la AUTOSAR Adaptive Platform clases de proxy del lado del cliente <Trigger> para cada trigger definido en la ServiceInterface en el rol trigger. La instanciación se produce presumiblemente de forma implícita a través del service proxy, mediante el cual la aplicación direcciona el objeto trigger para transmitir una señal de disparo al proveedor del servicio. Pregunta Q-3f5a464441664c95 (abierta) La vida útil de los triggers está vinculada a la instancia de proxy de nivel superior, requiriéndose una sincronización en la aplicación en caso de acceso concurrente por parte de múltiples hilos de la aplicación.

más ›

Contexto

El espacio de nombres <SI-Namespace>::proxy::triggers forma parte del módulo de comunicación (com) en la AUTOSAR Adaptive Platform para la versión R25-11. Sirve para encapsular clases de proxy del lado del cliente para elementos trigger modelados en una interfaz de servicio. Para cada trigger declarado en una ServiceInterface en el rol trigger, se proporciona en este espacio de nombres una clase de trigger de service proxy específica <Trigger>.

En la interacción de la arquitectura orientada a servicios, este espacio de nombres actúa como un intermediario específico entre la aplicación cliente consumidora y los puntos de interacción del service proxy de nivel superior. Presumiblemente, las instancias de la clase generada <Trigger> se proporcionan como miembros o mediante métodos de acceso del respectivo service proxy y comparten su vinculación a una instancia de servicio resuelta. Pregunta Q-821f73ddacf7a754 (abierta) Mientras que las invocaciones a métodos en com representan típicamente llamadas a funciones síncronas o asíncronas con parámetros y valores de retorno, y los eventos sirven para la recepción continua de datos, un trigger del lado del proxy debería actuar como un mecanismo de disparo ligero para transmitir una señal o una notificación al proveedor del servicio desde el lado del cliente.

Ciclo de vida

Dado que el espacio de nombres <SI-Namespace>::proxy::triggers proporciona principalmente elementos de interfaz generados por tipo para triggers de service proxy, no define fases de inicialización globales independientes ni transiciones de estado a nivel de espacio de nombres. En su lugar, la vida útil y la propiedad de los objetos trigger deberían estar completamente vinculadas al ciclo de vida de la instancia de proxy de nivel superior, de modo que no se requiere una creación separada mediante factorías ni rutinas de liberación manual para la aplicación cliente. Pregunta Q-34d5346fed668f0b (abierta)

La creación de la instancia de trigger se realiza de forma implícita durante la construcción del service proxy, una vez que se ha encontrado una instancia de servicio adecuada a través del service discovery. Mientras el service proxy exista en memoria y siga siendo válido, la clase <Trigger> incrustada también estará disponible para interacciones. Si el service proxy se destruye o se libera, también finaliza la vida útil de los objetos trigger asociados. Con respecto a la concurrencia y la seguridad de hilos, en caso de acceso simultáneo de múltiples hilos de la aplicación al mismo objeto trigger, debe prestarse atención a la sincronización en el lado de la aplicación, ya que la especificación no describe garantías adicionales a nivel de espacio de nombres.

Ruta de uso

El flujo típico para utilizar elementos del espacio de nombres <SI-Namespace>::proxy::triggers sigue el patrón regular de la comunicación orientada a servicios en el lado del proxy y se divide en descubrimiento de servicio, creación del proxy y activación del trigger.

En el primer paso, la aplicación Adaptive busca una instancia disponible del servicio de destino a través de los mecanismos de la plataforma e instancia el service proxy correspondiente. En el segundo paso, la aplicación accede a través del proxy a la instancia de <Trigger> proporcionada en el espacio de nombres, la cual corresponde al trigger modelado en la ServiceInterface. En el tercer paso, la aplicación ejecuta la invocación en el objeto trigger, con lo que se envía la señal de disparo al proveedor del servicio. Tras concluir la comunicación, la instancia del service proxy se desmantela debidamente, finalizando así la ruta de uso de la clase trigger.