clase <SI-Namespace>::skeleton::<SI>Skeleton

El método OfferService() se invoca en una instancia de la clase Skeleton para ofrecer un servicio proporcionado en el sistema y hacerlo localizable para los consumidores a través de Service Discovery [SWS_CM_00101], ARAComAPI §6.5 «Service Discovery». La llamada se realiza sin parámetros y de forma síncrona tan pronto como la implementación del servicio se ha instanciado completamente y se ha colocado en un estado listo para operar AUTOSAR_AP_EXP_ARAComAPI §5.4.4 «Offering Service instance». La función está declarada como noexcept y devuelve un ara::core::Result<void> [SWS_CM_00101].

El ofrecimiento es un requisito indispensable para la comunicación funcional a través de métodos, eventos, campos o disparadores (triggers) AUTOSAR_AP_EXP_ARAComAPI §4.2 «Means of Communication». Si, por ejemplo, se intenta enviar un trigger sin haberlo ofrecido previamente, la operación fallará con ComErrc::kServiceNotOffered [SWS_CM_00721]. En lo relativo a la concurrencia, se aplica lo siguiente: tan pronto como se invoca OfferService(), las llamadas a métodos entrantes ya pueden entregarse a la instancia del servicio, incluso si la llamada a OfferService() aún no ha retornado AUTOSAR_AP_EXP_ARAComAPI §5.4.4 «Offering Service instance».

Si el ofrecimiento falla, el ara::core::Result devuelto contiene el código de error correspondiente de ComErrc [SWS_CM_00101], [SWS_CM_10432]:

• ComErrc::kFieldValueNotInitialized: Al menos un valor de campo configurado aún no se había inicializado antes del ofrecimiento [SWS_CM_00101].
• ComErrc::kFieldSetHandlerNotSet: Para un campo con soporte de setter todavía no se ha registrado ningún manejador mediante RegisterSetHandler() [SWS_CM_00101].
• ComErrc::kCommunicationFailure: La vinculación de red notifica un error de comunicación subsanable o el fallo de la comunicación segura [SWS_CM_00101].

Si se desea finalizar la provisión del servicio, debe invocarse StopOfferService() AUTOSAR_AP_EXP_ARAComAPI §5.4.4 «Offering Service instance».

El método ProcessNextMethodCall() sirve a los proveedores de servicios en el Skeleton para procesar de forma determinista las llamadas a métodos entrantes en modo polling [SWS_CM_00199]. Solo debe utilizarse si la instancia de Skeleton ha sido configurada con el modo ara::com::MethodCallProcessingMode::kPoll EXP ARAComAPI §2 «Polling».

Uso y semántica

La función no toma parámetros y ejecuta una solicitud de llamada a método pendiente de forma síncrona en el contexto del hilo de quien la invoca [SWS_CM_00199], [SWS_CM_00191]. Esto permite en particular a las aplicaciones de tiempo real procesar solicitudes de servicio sin cambios de contexto de hilo incontrolados dentro de su presupuesto de tiempo asignado EXP ARAComAPI §5.4 «ProcessNextMethodCall». El valor de retorno señala el resultado de la consulta:

• true: Al menos una solicitud pendiente se encontraba en la cola y ha sido procesada [SWS_CM_00199].
• false: No había ninguna solicitud pendiente; la cola estaba vacía [SWS_CM_00199]. Una llamada subsiguiente directa tras un false suele ser ineficaz EXP ARAComAPI §5.4 «ProcessNextMethodCall».

Tratamiento de errores y condiciones límite

La función está especificada como noexcept y exception safe [SWS_CM_00199]. Una llamada a un Skeleton que ha sido instanciado con kEvent o kEventSingleThread representa una infracción (WrongMethodCallProcessingModeViolation) [SWS_CM_00199]. Interpretación: dado que las excepciones regulares de C++ quedan descartadas por noexcept, es probable que la plataforma trate dicha infracción como un error grave de tiempo de ejecución. Pregunta Q-61661dbd6cc37bc7 (abierta)

usar

La función SetTransportFaultConditionHandler sirve para registrar un callback del tipo ara::com::e2e::TransportFaultConditionHandler en el espacio de nombres de la clase Skeleton (<SI-Namespace>::skeleton::<SI>) [SWS_CM_00093]. A través de este gestor se notifican errores de transporte para todos los métodos de la respectiva instancia de servicio AUTOSAR_AP_SWS_CommunicationManagement §7.4.1 «End-to-end communication protection for SOMEIP». La función toma el objeto invocable handler y no tiene valor de retorno (void) [SWS_CM_00093].

Manejo de errores

La operación está declarada con noexcept y es segura ante excepciones (exception safe) [SWS_CM_00093]. Si la entidad invocable pasada no existe o es null, se desencadena una InvalidHandlerViolation [SWS_CM_00093]. En caso de error, el gestor configurado notifica anomalías de transporte ocurridas como, por ejemplo, TransportFaultCondition::kSampleRejected, cuando las solicitudes se descartan por falta de recursos o corrupción en la capa de transporte AUTOSAR_AP_SWS_CommunicationManagement §7.4.2.3 «Methods».

Concurrencia y restricciones

Interpretación: Puesto que esta interfaz básica no recibe ningún contexto de ejecución, es de suponer que el callback se invoque de forma síncrona desde el hilo interno de la gestión de comunicaciones. Pregunta Q-e4007fa72de6aa12 (abierta) En caso de que la ejecución del gestor deba realizarse en un grupo de hilos (thread pool) o worker definido, debe utilizarse la sobrecarga con ExecutorT&& executor [SWS_CM_00094].

Interacción

El registro vincula el tratamiento de errores de manera centralizada a todos los métodos de una instancia de Skeleton [SWS_CM_00093]. Este se integra en el tratamiento de errores de nivel superior de ara::com:

• Mientras que los métodos de Skeleton notifican errores de transporte a través de este gestor, los métodos de cliente señalan fallos de transporte de forma asíncrona a través de su ara::core::Future resultante con ComErrc::kCommunicationFailure [SWS_CM_00090].
• Para operaciones de campos (Get/Set) en el nivel de Skeleton existen interfaces separadas [SWS_CM_00096].
• En el nivel de Proxy están disponibles funciones de registro análogas para eventos [SWS_CM_00099], disparadores [SWS_CM_00106] y notificadores [SWS_CM_00109].

La función plantilla SetTransportFaultConditionHandler en el espacio de nombres de la clase skeleton sirve para registrar un manejador de errores ante fallos de transporte de todos los métodos de una instancia de servicio [SWS_CM_00094]. Amplía la función básica sin parámetros [SWS_CM_00093] con un contexto de ejecución:

• Llamada y parámetros: se transfieren un invocable handler de tipo ara::com::e2e::TransportFaultConditionHandler y una referencia universal executor [SWS_CM_00094]. En este objeto ejecutor se deben iniciar todos los cálculos asincrónicos y ejecuciones de callbacks. La función no tiene valor devuelto.
• Tratamiento de errores: la interfaz está declarada como noexcept y especificada como segura frente a excepciones [SWS_CM_00094]. Si el invocable suministrado no existe o es nulo, se produce un InvalidHandlerViolation [SWS_CM_00094].
• Interacción: el ámbito de validez abarca todos los métodos del skeleton [SWS_CM_00094], mientras que para las operaciones Field-Get y Set se dispone de funciones de registro independientes ([SWS_CM_00096], [SWS_CM_00097]). En el enlace de red de DDS, el manejador configurado notifica errores de transporte como TransportFaultCondition::kSampleRejected [SWS_CM_00216]; en el lado del cliente, en cambio, tales errores se señalan mediante ComErrc::kCommunicationFailure en los futuros de resultado [SWS_CM_00090].
• Concurrencia: interpretación: la entrega del ejecutor desacopla el tratamiento de errores del contexto interno de la capa de comunicación; presumiblemente, el registro debería realizarse de forma temprana durante la inicialización del skeleton, antes de la llegada de las primeras llamadas a métodos. Pregunta Q-e56b2a1928cf32ad (abierta)

El constructor [SWS_CM_00130] instancia un skeleton de servicio a partir de un ara::com::InstanceIdentifier concreto. El skeleton conecta la implementación del servicio del lado de la aplicación con la capa de transporte de Communication Management para que los consumidores de servicios distribuidos puedan acceder a él (ARAComAPI §5.1 «Proxy Skeleton Pattern»).

A través del parámetro mode se determina cómo se procesan las llamadas a métodos entrantes. Como valor por defecto se establece el modo basado en eventos ara::com::MethodCallProcessingMode::kEvent [SWS_CM_00130]. Si en su lugar se selecciona un modo basado en sondeo, la ejecución de las llamadas a métodos pendientes se realiza de forma sincrónica en el contexto de llamada de ProcessNextMethodCall() [SWS_CM_00199].

Tratamiento de errores y condiciones límite

La función constructora está declarada con noexcept y no lanza excepciones de C++ [SWS_CM_00130]. Las posibles infracciones se señalan a través del sistema en tiempo de ejecución: si el Grant-Enforcement deniega la creación, se produce una InsufficientPermissionsViolation; si se pasa un modo de procesamiento no válido, resulta una WrongMethodCallProcessingModeViolation [SWS_CM_00130]. Interpretación: la validación del modo de procesamiento presumiblemente tiene lugar inmediatamente durante la ejecución del constructor. Pregunta Q-80e02c0079757082 (abierta)

Las operaciones de copia están explícitamente eliminadas para el skeleton [SWS_CM_00134], mientras que la construcción por movimiento está admitida [SWS_CM_00135]. Para que el servicio se pueda localizar en la red, debe invocarse OfferService() tras la instanciación [SWS_CM_00101] (ARAComAPI §6.5 «Service Discovery»). Antes de la destrucción de la instancia [SWS_CM_11370], la puesta a disposición puede finalizarse de nuevo mediante StopOfferService() [SWS_CM_00111].

El constructor instancia un skeleton de servicio a partir de un identificador de instancia [SWS_CM_00152]. Sirve para conectar una implementación de servicio concreta a la capa de transporte de Communication Management. Como parámetros se transfieren un ara::core::InstanceSpecifier y, opcionalmente, el modo de procesamiento ara::com::MethodCallProcessingMode, el cual está predeterminado por defecto a kEvent [SWS_CM_00152].

En lo relativo al tratamiento de errores y al comportamiento ante excepciones, el constructor está declarado como noexcept y exception safe [SWS_CM_00152]. En caso de configuraciones erróneas o desviaciones de modelado, se especifican las siguientes violations:

• InstanceSpecifierMappingIntegrityViolation, en caso de que el identificador no pueda resolverse en el contexto de ejecución o no haga referencia a un PortPrototype [SWS_CM_00152].
• PortInterfaceMappingViolation y ProcessMappingViolation, si el tipo de mapeo y el tipo de interfaz no coinciden [SWS_CM_00152].
• InstanceSpecifierAlreadyInUseViolation, si el InstanceSpecifier ya está en uso [SWS_CM_00152].
• WrongMethodCallProcessingModeViolation, así como InsufficientPermissionsViolation en caso de permisos insuficientes [SWS_CM_00152].

Interpretación: Dado que el constructor está declarado como noexcept, es de suponer que las violations especificadas no se propaguen como excepciones de C++ lanzadas en tiempo de ejecución, sino que sean interceptadas mediante comprobaciones de la plataforma o Grant Enforcement. Pregunta Q-f1a1a0baeb56e482 (abierta)

Para el ciclo de vida y la concurrencia, el constructor de copia está eliminado [SWS_CM_00134], mientras que se encuentra disponible un constructor de movimiento [SWS_CM_00135]. La liberación se realiza a través del destructor virtual [SWS_CM_11370]. Tras una construcción correcta, el servicio se ofrece típicamente en la red mediante [SWS_CM_00101] (OfferService). Si se seleccionó kPoll como modo de procesamiento, la aplicación debe procesar explícitamente las llamadas entrantes a los métodos de servicio [SWS_CM_00191] a través de [SWS_CM_00199] (ProcessNextMethodCall).

usar

El constructor instancia un esqueleto de servicio a partir de un contenedor de identificadores de instancia (instanceIDs) y conecta la implementación del servicio en el lado del servidor con la capa de transporte de Communication Management [SWS_CM_00153], ARAComAPI §5.1 «Proxy Skeleton Pattern». Mediante el parámetro mode se define cómo se procesan las llamadas a métodos entrantes; de forma predeterminada, la tramitación se realiza dirigida por eventos mediante kEvent [SWS_CM_00153]. Alternativamente, están disponibles constructores para identificadores de instancia individuales [SWS_CM_00130] o especificadores de instancia [SWS_CM_00152].

Tratamiento de errores y concurrencia

La función está declarada como noexcept y especificada como segura frente a excepciones (exception safe) [SWS_CM_00153]. Las posibles infracciones durante la creación son WrongMethodCallProcessingModeViolation en caso de pasar un modo de procesamiento no permitido, así como InsufficientPermissionsViolation si falla la comprobación de autorizaciones (Grant Enforcement) [SWS_CM_00153].

Si para mode se configura el modelo de sondeo (kPoll), la aplicación de servidor debe procesar las llamadas a métodos pendientes de forma síncrona en el contexto de su propio hilo mediante la llamada a ProcessNextMethodCall() [SWS_CM_00199]. El constructor de copia de la clase de esqueleto está eliminado (delete) [SWS_CM_00134]; los movimientos, en cambio, son compatibles mediante el constructor de movimiento [SWS_CM_00135].

Interacción

Tras una instanciación correcta, el servicio se pone a disposición de consumidores remotos o locales mediante OfferService() [SWS_CM_00101], ARAComAPI §6.5 «Service Discovery». Antes de destruir el esqueleto mediante el destructor [SWS_CM_11370], se debe finalizar la provisión a través de StopOfferService() [SWS_CM_00111]. Las llamadas a métodos entrantes devuelven, en cada caso, un ara::core::Future en el lado del servidor [SWS_CM_00191].

El destructor virtual ~<SI>Skeleton() [SWS_CM_11370] finaliza el ciclo de vida de una instancia de skeleton de servicio. Como artefacto generado, el skeleton de servicio conecta la implementación concreta del servicio con la capa de transporte de Communication Management, de modo que los consumidores de servicios puedan acceder a los métodos y a las funcionalidades ofrecidos (ARAComAPI §5.1 «Proxy Skeleton Pattern»).

La destrucción se produce de forma síncrona al desmontar la clase de implementación derivada. El método no recibe parámetros y no declara ningún valor de retorno. A diferencia de los constructores del skeleton, como [SWS_CM_00130] o [SWS_CM_00152], el destructor está clasificado explícitamente en la especificación como not exception safe [SWS_CM_11370].

En cuanto al tratamiento de errores y las condiciones de contorno, se establece que en caso de incumplimiento de una precondición puede producirse una DanglingSamplesViolation [SWS_CM_11370]. Si el servicio se ofreció previamente hacia el exterior mediante OfferService() [SWS_CM_00101] (ARAComAPI §6.5 «Service Discovery»), probablemente deba llamarse al método StopOfferService() [SWS_CM_00111] antes de la invocación del destructor para finalizar limpiamente las relaciones de comunicación activas. Pregunta Q-c430a7f0fc838eba (abierta)

Para el skeleton, el constructor de copia está eliminado [SWS_CM_00134], mientras que las operaciones de movimiento están soportadas [SWS_CM_00135]. Los procesos de tratamiento en curso —como la ejecución de llamadas pendientes a través de ProcessNextMethodCall() [SWS_CM_00199]— deberían completarse antes de iniciar la destrucción.

El método [SWS_CM_00111] finaliza el ofrecimiento de una instancia de servicio por parte de la aplicación proveedora de servicios en ara::com. La llamada se efectúa sin parámetros sobre la instancia concreta de Skeleton en el espacio de nombres <SI-Namespace>::skeleton::<SI> y no devuelve ningún valor (EXP_ARAComAPI §5.4.1 «Skeleton Class API’s»).

Para el uso y el comportamiento en tiempo de ejecución aplican las siguientes condiciones:

• Contexto de llamada y condición previa: el método se invoca cuando una instancia proporcionada previamente mediante OfferService() —por ejemplo, a raíz de cambios de estado— ya no deba estar disponible (EXP_ARAComAPI §5.4.4 «Offering Service instance»).
• Aseguramiento (contrato): una vez que StopOfferService() ha retornado, según el contrato ya no se reenviarán más llamadas a métodos a esta instancia de servicio (EXP_ARAComAPI §5.4.4 «Offering Service instance»).
• Ciclo de vida y destructor: en caso de que una instancia de servicio todavía se ofrezca activamente al invocarse el destructor de la clase Skeleton, el destructor ejecutará StopOfferService() internamente de forma obligatoria (EXP_ARAComAPI §5.4.4 «Offering Service instance»).
• Service Discovery: mediante la llamada se actualiza el registro local o el protocolo de Service Discovery del middleware acerca de la retirada del servicio (EXP_ARAComAPI §7.2.1 «Central vs Distributed approach»).

La función está declarada como noexcept y se considera segura frente a excepciones ([SWS_CM_00111]). No notifica errores ni mediante excepciones ni mediante mensajes de error o códigos de retorno.