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

En el módulo com de Adaptive Platform, el namespace <SI-Namespace>::proxy::fields encapsula las clases proxy generadas <Field> para cada campo de datos definido en un ServiceInterface. Las aplicaciones cliente acceden a estas clases de campo a través del proxy de servicio de nivel superior para consultar valores de campo remotos, establecerlos o procesar notificaciones sobre cambios de valor. Las llamadas sobre campos suelen gestionarse de forma asíncrona a través de la infraestructura de comunicación para garantizar interacciones sin bloqueo. Pregunta (abierta) La vida útil de las instancias de campo individuales está probablemente ligada de forma fija al ciclo de vida del objeto proxy de nivel superior y no puede gestionarse de forma independiente de este.

más ›

Contexto

En el módulo com de AUTOSAR Adaptive Platform, el namespace de C++ <SI-Namespace>::proxy::fields asume una función estructuradora claramente delimitada para interfaces orientadas a servicios. Además de métodos y eventos, las interfaces de servicio (ServiceInterfaces) definen frecuentemente campos de datos que representan un estado actual. Para proporcionar estos campos en el lado del cliente a los consumidores de servicios de forma segura para tipos y semánticamente unívoca, el generador de código ubica las clases de campo específicas en este sub-namespace dedicado. Para cada campo modelado en el ServiceInterface correspondiente se genera exactamente una clase proxy de campo <Field>. Este encapsulamiento estructural evita conflictos de nombres con métodos o eventos homónimos dentro del namespace de proxy de nivel superior. Interpretación: las clases de campo generadas <Field> proporcionan típicamente funciones de interfaz especializadas para funcionalidades Get, Set y de notificación con el fin de consultar, modificar o recibir cambios suscritos de forma selectiva. Pregunta Q-f088d0c5052459d3 (abierta) El interlocutor directo de las clases de campo es la lógica de aplicación del consumidor del servicio por un lado y el middleware de comunicación subyacente por el otro.

Ciclo de vida

La instanciación y gestión de los objetos de <SI-Namespace>::proxy::fields está intrínsecamente ligada a la arquitectura del proxy de servicio. Por regla general, los desarrolladores de aplicaciones no crean instancias de la clase generada <Field> manualmente como variables independientes en el heap o en la pila. En su lugar, es probable que la vida útil de una instancia de <Field> esté completamente ligada al ciclo de vida del proxy de servicio de nivel superior que contiene estos campos como miembros. Pregunta Q-4da7e86f88f269b1 (abierta) Con la construcción satisfactoria de la instancia de proxy tras la localización de un endpoint de servicio adecuado, los objetos de campo se inicializan y se sitúan en un estado operativo. Durante la fase activa, el objeto de campo gestiona recursos internos de comunicación así como eventuales registros para actualizaciones de estado. Si la aplicación destruye la instancia de proxy o esta abandona su ámbito de validez, consecuentemente también se destruyen de forma adecuada las instancias de campo asociadas, liberando así los recursos vinculados del middleware.

Ruta de uso

La secuencia de uso típica de las clases en el namespace <SI-Namespace>::proxy::fields se divide en un orden fijo de pasos de interacción. En primer lugar, la aplicación cliente determina la instancia del servicio deseado a través de los mecanismos de búsqueda de Adaptive Platform e instancia el proxy de servicio correspondiente. En el segundo paso, la aplicación accede a través del proxy a la instancia de miembro correspondiente de la clase generada <Field>. En función de las propiedades del campo definidas en el modelo de interfaz, la aplicación inicia a continuación un acceso de lectura, un acceso de escritura o registra un callback para notificaciones sobre cambios de valor. Las llamadas sobre campos suelen gestionarse de forma asíncrona mediante ara::core::Future o mecanismos de callback de la infraestructura de comunicación para evitar llamadas bloqueantes en el hilo llamante. Pregunta Q-33586a48d8777f7f (abierta) Tras la llegada de la respuesta o notificación, el llamante evalúa el resultado entregado y reacciona al estado del campo remoto.