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

El espacio de nombres encapsula las clases de campo del lado del servidor para cada campo declarado en una ServiceInterface dentro de la arquitectura de esqueletos del módulo com. Los proveedores de servicio utilizan estas clases generadas para gestionar el valor de campo actual y transmitirlo a los clientes conectados cuando se producen cambios de valor. La instanciación y la vida útil de los objetos de campo deberían estar vinculadas directamente a la instancia de esqueleto de nivel superior. Pregunta Q-bd1d4d2cab97eada (abierta) Al actualizar y proporcionar los datos, debe prestarse atención a la sincronización conforme al modelo de subprocesos del esqueleto de servicio.

más ›

Contexto

El espacio de nombres <SI-Namespace>::skeleton::fields forma parte de la arquitectura de comunicación (módulo com) de la AUTOSAR Adaptive Platform en la versión R25-11. Contiene las clases generadas del lado del servidor para todos los campos modelados en una ServiceInterface en el rol field. Para cada campo definido en la interfaz existe aquí una clase de campo de esqueleto de servicio correspondiente que sigue el esquema de nombres genérico <Field>. Estas clases constituyen el vínculo entre la implementación específica de la aplicación de un servicio y la capa de comunicación subyacente para ofrecer estructuras de datos relativas a campos de manera estructurada.

En arquitecturas orientadas a servicios, los campos representan propiedades de un servicio que típicamente pueden componerse de una combinación de accesos de lectura (getters), accesos de escritura (setters) y notificaciones basadas en eventos (notifiers). Mientras que en el lado del cliente, en el espacio de nombres del proxy, se generan interfaces correspondientes para el acceso consumidor, skeleton::fields proporciona las clases con las que el proveedor de servicio (servidor) gestiona el estado interno y lo expone hacia el exterior. Las clases en el espacio de nombres <SI-Namespace>::skeleton::fields encapsulan la comunicación y la transmisión específica del protocolo, permitiendo que el desarrollador de la aplicación se concentre en la lógica funcional del servicio.

Ciclo de vida

En cuanto a la creación y las relaciones de propiedad, la vida útil de una clase de campo en el espacio de nombres skeleton::fields debería estar directamente vinculada a la clase de esqueleto de nivel superior de la interfaz de servicio. Pregunta Q-375f07429819a937 (abierta) En implementaciones basadas en C++ de la Adaptive Platform, las instancias de campo se instancian típicamente como objetos miembro directos dentro del esqueleto generado. En consecuencia, el ciclo de vida de los objetos de campo comienza con la llamada al constructor del esqueleto de servicio y finaliza automáticamente con su destrucción.

Durante la fase de operación, el objeto de campo permanece en la memoria del proveedor de servicio. Antes o durante la oferta del servicio en la red (por ejemplo, antes del registro del servicio o inmediatamente después), la instancia de campo se inicializa con un valor inicial válido. Dado que el esqueleto está disponible para consultas y actualizaciones a lo largo de toda su vida útil, la instancia de campo también permanece persistentemente disponible.

Respecto a la concurrencia y la gestión de hilos, el manejo de los accesos a campos debería depender en gran medida del modelo de procesamiento seleccionado para el esqueleto. Pregunta Q-d3456f67c7a4ba8d (abierta) Siempre que la clase de campo proporcione mecanismos de callback para solicitudes entrantes de lectura o escritura, u ofrezca métodos para actualizar el valor del campo, los accesos concurrentes por parte de la implementación del servicio que la utiliza deben sincronizarse para evitar condiciones de carrera durante la ejecución concurrente.

Ruta de uso

La ruta de uso típica para las clases de <SI-Namespace>::skeleton::fields comienza en el marco de la inicialización del proveedor de servicio. Al construir la instancia de esqueleto, se crea el objeto de campo correspondiente para cada campo configurado. La implementación del servicio asigna típicamente de forma inicial un valor de inicio válido a la clase de campo para que los clientes solicitantes encuentren datos consistentes desde el principio.

En funcionamiento continuo, la interacción se realiza principalmente a través de actualizaciones de valor. Tan pronto como cambian los estados internos, los valores de sensores o los datos de cálculo en la aplicación de servicio, el esqueleto invoca el método de actualización correspondiente de la instancia de campo. La clase de campo asume a continuación la distribución de los nuevos datos al framework de comunicación, el cual envía los valores como mensajes de notificación a todos los service proxies interesados y suscritos en la red.

Siempre que el campo esté configurado para accesos de escritura por parte de clientes, la clase de campo procesa las solicitudes de actualización entrantes (operaciones set). La implementación del servicio recibe los valores modificados, los valida y actualiza el estado interno. Mediante este flujo orientado a un propósito de inicialización, transmisión periódica o basada en eventos de valores y finalización controlada con el final de la vida útil del esqueleto, las clases de campo se integran a la perfección en el patrón de interacción del nivel de servicios de AUTOSAR Adaptive.