clase ara::com::InstanceIdentifier

La clase ara::com::InstanceIdentifier representa el identificador técnico unívoco de una instancia concreta de servicio en la AUTOSAR Adaptive Platform y permite el direccionamiento a través de bindings de comunicación específicos (AUTOSAR_AP_EXP_ARAComAPI p. 22 §4.1 «InstanceIdentifier class»). Como tipo por valor serializable, se puede crear a partir de cadenas de caracteres, comparar y gestionar en contenedores ([SWS_CM_11520], [SWS_CM_11523]). Mientras que las aplicaciones estándar utilizan predominantemente identificadores de modelo abstractos, el uso directo de este identificador técnico sirve para casos especiales como el multi-binding y las soluciones de fail-over (AUTOSAR_AP_EXP_ARAComAPI p. 25 «InstanceIdentifier Usage»).

más ›

Contexto

La clase ara::com::InstanceIdentifier sirve para la identificación unívoca de una instancia concreta de servicio en la Adaptive Platform (AdaptivePlatformServiceInstance), con el fin de distinguir entre sí diferentes instancias exactamente del mismo servicio. Encapsula el direccionamiento específico de la tecnología del binding de comunicación seleccionado, pero omite deliberadamente un nombre completamente calificado con información de tipo de servicio. Para el desarrollador de software habitual, la interacción directa con ara::com::InstanceIdentifier suele estar abstraída: mientras que en el modelo de componentes de software se emplean predominantemente nombres lógicos mediante ara::core::InstanceSpecifier (AUTOSAR_AP_EXP_ARAComAPI p. 23 §4.2 «InstanceSpecifier class»), el integrador los asocia a través de archivos de manifiesto con los bindings técnicos y sus respectivos identificadores de instancia (AUTOSAR_AP_EXP_ARAComAPI p. 23 §4.2 «InstanceSpecifier class»).

En el marco del denominado multi-binding, un único identificador abstracto puede mapearse a múltiples bindings técnicos. Por ello, la resolución a través de ResolveInstanceIDs() devuelve un ara::com::InstanceIdentifierContainer que agrupa varios ara::com::InstanceIdentifier (ARAComAPI p. 1 «Figure 6.6: InstanceIdentifier Resolution», AUTOSAR_AP_EXP_ARAComAPI p. 24 §4.3 «InstanceSpecifier Resolution»). Esto permite a los servidores (skeletons) atender a clientes mediante distintas tecnologías de transporte, o a los clientes (proxies) implementar rutas de fail-over (ARAComAPI p. 1 «Figure 6.6: InstanceIdentifier Resolution»).

Diagrama de contexto: Interacción entre la aplicación, el manifiesto de despliegue, la resolución de instancias y las interfaces de servicio. Fuentes: ARAComAPI p. 103 «Figure 6.5: Service Discovery», AUTOSAR_AP_EXP_ARAComAPI p. 23 §4.2 «InstanceSpecifier class», AUTOSAR_AP_EXP_ARAComAPI p. 24 §4.3 «InstanceSpecifier Resolution»

Ciclo de vida

Las instancias de ara::com::InstanceIdentifier disponen de semántica por valor completa. Cumplen los requisitos equalitycomparable, lessthancomparable y copyassignable según ISO/IEC 14882:2014, lo que permite gestionarlas en contenedores estándar, ordenarlas y registrarlas. La clase proporciona los siguientes constructores y funciones de ciclo de vida:

• Creación libre de excepciones mediante el método de factoría estático Create ([SWS_CM_11520]) con noexcept.
• Constructor explícito basado en una representación de cadena ([SWS_CM_11521]), el cual expresamente no es seguro frente a excepciones (not exception safe).
• Constructor de copia ([SWS_CM_00056]) y constructor de movimiento ([SWS_CM_00053]), ambos especificados como noexcept.
• Operador de asignación por copia ([SWS_CM_11525]) y operador de asignación por movimiento ([SWS_CM_00054]), cada uno con noexcept.
• Operadores de comparación operator== ([SWS_CM_11523]) y operator< ([SWS_CM_11524]) para la comprobación de igualdad y orden.
• Destructor ~InstanceIdentifier() ([SWS_CM_00055]) con noexcept.

Mediante la interacción del constructor de cadena con el método toString() ([SWS_CM_11522]), la clase es serializable (AUTOSAR_AP_EXP_ARAComAPI p. 22 §4.1 «InstanceIdentifier class»). Esto permite persistir, transferir y reutilizar posteriormente un identificador. No se contempla una interpretación del contenido (introspección) de la cadena serializada por parte de la lógica de aplicación, ya que su estructura depende por completo del producto de middleware y del binding (AUTOSAR_AP_EXP_ARAComAPI p. 22 §4.1 «InstanceIdentifier class»).

Ruta de uso

Dado que ara::com ofrece sobrecargas para métodos comunes que aceptan directamente ara::core::InstanceSpecifier, el manejo manual de ara::com::InstanceIdentifier está orientado principalmente a casos de uso avanzados, tales como bindings especializados o failover selectivo (AUTOSAR_AP_EXP_ARAComAPI p. 25 «InstanceIdentifier Usage»). La secuencia típica se divide en los siguientes pasos:

1. Resolución: la aplicación traduce el identificador de modelo abstracto mediante ResolveInstanceIDs() a los identificadores de instancia técnicos asignados (AUTOSAR_AP_EXP_ARAComAPI p. 24 §4.3 «InstanceSpecifier Resolution»).
2. Selección: a partir del ara::com::InstanceIdentifierContainer resultante, la aplicación selecciona el ara::com::InstanceIdentifier deseado (ARAComAPI p. 1 «Figure 6.6: InstanceIdentifier Resolution»).
3. Búsqueda de servicios: el identificador se pasa al método estático FindService(ara::com::InstanceIdentifier instance) de la clase proxy (ARAComAPI p. 103 «Figure 6.5: Service Discovery»).
4. Procesamiento: la búsqueda de servicios devuelve un ServiceHandleContainer a partir del cual se instancian proxies (ARAComAPI p. 103 «Figure 6.5: Service Discovery»). Mediante GetInstanceId() se puede consultar el identificador de instancia (AUTOSAR_AP_EXP_ARAComAPI p. 30 «GetInstanceId»).

Diagrama de secuencia: resolución del identificador y búsqueda de servicio selectiva mediante el InstanceIdentifier técnico. Fuentes: ARAComAPI p. 103 «Figure 6.5: Service Discovery», AUTOSAR_AP_EXP_ARAComAPI p. 24 §4.3 «InstanceSpecifier Resolution»

Escenarios de error

Al manipular ara::com::InstanceIdentifier, deben tenerse en cuenta especialmente dos situaciones de error:

• Formato de cadena no válido (InvalidInstanceIdentifierStringViolation): si se pasa a Create ([SWS_CM_11520]) o al constructor ([SWS_CM_11521]) un identificador serializado que está dañado, no conforme o duplicado, se produce esta infracción. Interpretación: mientras que previsiblemente el método de fábrica sin excepciones Create notifica esto a través de un objeto de error, es probable que el constructor sin seguridad frente a excepciones lance una excepción en caso de error. Pregunta Q-45a6fdd0859218bd (abierta)
• Falta de asignación en la resolución: si el integrador no ha definido una asignación para un ara::core::InstanceSpecifier en el manifiesto de despliegue, la llamada a ResolveInstanceIDs() devuelve una lista vacía (ARAComAPI p. 1 «Figure 6.6: InstanceIdentifier Resolution», AUTOSAR_AP_EXP_ARAComAPI p. 24 §4.3 «InstanceSpecifier Resolution»). Por lo general, esto representa un error de configuración.
• Falta de instancia de servicio: si no se ha ejecutado un OfferService() correspondiente en el lado del skeleton para el identificador especificado, el FindService devuelto por ServiceHandleContainer permanece vacío (ARAComAPI p. 103 «Figure 6.5: Service Discovery»).