estructura ara::com::FindServiceHandle

La estructura ara::com::FindServiceHandle sirve como un token de control unívoco para dirigir la monitorización de servicios en ejecución en segundo plano (AUTOSAR_AP_EXP_ARAComAPI p. 34). Dado que el constructor predeterminado está eliminado ([SWS_CM_00353]), el identificador es generado exclusivamente por StartFindService y permite, tras recibir callbacks de estado asíncronos, la finalización selectiva de la búsqueda a través de StopFindService (AUTOSAR_AP_EXP_ARAComAPI p. 30). Los operadores de comparación admitidos garantizan, además, la gestión almacenable de múltiples solicitudes de búsqueda en contenedores estándar ([SWS_CM_11526], [SWS_CM_11527]).

más ›

Contexto

La estructura ara::com::FindServiceHandle actúa en el módulo com de la Adaptive Platform como un identificador unívoco y token de control para una búsqueda de servicios continua y asíncrona. Mientras que una consulta síncrona a través de FindService determina por única vez las instancias de servicio coincidentes y devuelve directamente contenedores de identificadores, StartFindService inicia una monitorización permanente de la disponibilidad del servicio en segundo plano (AUTOSAR_AP_EXP_ARAComAPI p. 34). En este proceso intervienen típicamente la instancia de la aplicación, la clase proxy específica del tipo (por ejemplo, RadarServiceProxy) y una función de callback definida por el usuario de tipo FindServiceHandler (AUTOSAR_AP_EXP_ARAComAPI p. 30). La representación interna concreta de ara::com::FindServiceHandle está diseñada de forma específica para la implementación del Communication Management correspondiente, pero proporciona interfaces de C++ estandarizadas para su manejo.

Ciclo de vida

El ciclo de vida de un ara::com::FindServiceHandle está estrictamente vinculado al proceso de búsqueda activo en el Communication Management:

• Creación: El constructor predeterminado está explícitamente eliminado ([SWS_CM_00353]). Por lo tanto, una aplicación no puede crear instancias de identificadores sin inicializar o de forma autónoma. En su lugar, la llamada estática al método StartFindService genera un identificador válido exclusivamente como carga útil de un ara::core::Result (AUTOSAR_AP_EXP_ARAComAPI p. 30).
• Gestión y propiedad: Un identificador admite la asignación a través del operador de asignación por copia [SWS_CM_11528]. Para permitir que la aplicación almacene y organice múltiples solicitudes de búsqueda en contenedores estándar (como conjuntos ordenados o memorias asociativas), el tipo cumple con los conceptos de C++ [equalitycomparable] y [lessthancomparable] mediante los operadores operator== ([SWS_CM_11526]) y operator< ([SWS_CM_11527]).
• Finalización y destrucción: El identificador conserva su validez mientras la monitorización en segundo plano esté activa. La finalización de la búsqueda se realiza pasando el identificador a StopFindService (AUTOSAR_AP_EXP_ARAComAPI p. 30, AUTOSAR_AP_EXP_ARAComAPI p. 34). Después de esta llamada, el identificador ya no representa ningún proceso de búsqueda en ejecución.

Ruta de uso

El flujo regular comprende el registro de la solicitud de búsqueda, la recepción continua de actualizaciones de disponibilidad y la detención ordenada del proceso de monitorización:

1. Inicio de la búsqueda: La aplicación registra un FindServiceHandler mediante StartFindService para ser informada sobre instancias de servicio recién disponibles o que dejan de estarlo (AUTOSAR_AP_EXP_ARAComAPI p. 30, AUTOSAR_AP_EXP_ARAComAPI p. 34).
2. Obtención del identificador: En caso de un inicio correcto, la llamada devuelve un ara::core::Result con el FindServiceHandle (AUTOSAR_AP_EXP_ARAComAPI p. 30), que la aplicación conserva para posteriores llamadas de control.
3. Notificación asíncrona: El Communication Management ejecuta la búsqueda en segundo plano y llama al gestor provisto ante cambios de estado (AUTOSAR_AP_EXP_ARAComAPI p. 34).
4. Detención de la búsqueda: Tan pronto como se han encontrado las instancias o la monitorización ya no es necesaria, la aplicación pasa el identificador a StopFindService (AUTOSAR_AP_EXP_ARAComAPI p. 30, AUTOSAR_AP_EXP_ARAComAPI p. 34).

Diagrama de secuencia: Flujo típico de la búsqueda asíncrona de servicios, desde el registro y las notificaciones hasta la finalización mediante FindServiceHandle. Fuentes: AUTOSAR_AP_EXP_ARAComAPI p. 30, AUTOSAR_AP_EXP_ARAComAPI p. 34.

Escenarios de error

Al utilizar ara::com::FindServiceHandle, se deben tener en cuenta las siguientes condiciones de contorno específicas del sistema:

• Inicio de búsqueda fallido: Si los enlaces técnicos no están disponibles o la configuración de despliegue del servicio es errónea (AUTOSAR_AP_EXP_ARAComAPI p. 34), StartFindService falla. En este caso, el ara::core::Result devuelto no contiene un identificador válido, sino un código de error (AUTOSAR_AP_EXP_ARAComAPI p. 30).
• Seguridad frente a excepciones: Los operadores de comparación y asignación implementados operator== ([SWS_CM_11526]), operator< ([SWS_CM_11527]) y operator= ([SWS_CM_11528]) están declarados explícitamente en la especificación como no seguros frente a excepciones (not exception safe).
• Detención múltiple: Presumiblemente, una llamada repetida a StopFindService con el mismo identificador no tendría efecto o provocaría un error en tiempo de ejecución, ya que la actividad de monitorización subyacente ya se ha eliminado. Pregunta Q-f44130c33fa1caea (abierta)