classe <SI-Namespace>::proxy::methods::<Method>

A classe de método proxy <SI-Namespace>::proxy::methods::<Method> permite que aplicações cliente efetuem chamadas de método com valor de retorno para operações cliente-servidor definidas em ServiceInterface [SWS_CM_00196]. A chamada é efetuada de modo não bloqueante através de operator(), que retorna imediatamente um ara::core::Future para a consulta flexível, síncrona ou assíncrona, de resultados [SWS_CM_00196]. Complementarmente, GetE2EStateMachineState() permite a leitura do estado de proteção da máquina de estados End-to-End associada [SWS_CM_00148]. Dado que as operações estão especificadas como seguras contra exceções, os erros de transmissão e de execução são reportados através do Future com códigos de erro padronizados.

mais ›

Contexto

A classe <SI-Namespace>::proxy::methods::<Method> representa a interface do lado do cliente para chamadas de método síncronas e assíncronas no âmbito do Communication Management do AUTOSAR Adaptive. Para cada operação cliente-servidor declarada em ServiceInterface na qual o atributo ClientServerOperation.fireAndForget == FALSE esteja configurado, o framework de comunicação gera exatamente uma classe de método proxy própria no papel de um método. A classe é declarada como final e incluída através do cabeçalho #include "<SiNamespaceDerivedDirectoryPath>/<SiShortname>_proxy.h" SWS Communication Management, p. 39. Como parceiros diretos de interação atuam a aplicação cliente chamadora, bem como o Network Binding, que reencaminha a transmissão do método para a instância de serviço remota e recebe a sua resposta [SWS_CM_00196]. O método proxy recebe os parâmetros de chamada e encapsula o fluxo assíncrono através de um objeto ara::core::Future, através do qual o cliente consulta a conclusão e o resultado da chamada.

Ciclo de vida

A instanciação de <SI-Namespace>::proxy::methods::<Method> ocorre em conjunto com o proxy de serviço de nível superior. Interpretação: a classe de método deverá ser instanciada e destruída juntamente com o objeto proxy gerado, como parte integrante do mesmo, pelo que o utilizador não aloca a instância separadamente. Pergunta Q-546c9b1bceedef6b (aberta) Relativamente à concorrência, a chamada de método via operator() foi concebida para ser não bloqueante; a função inicia a transmissão e retorna imediatamente ao chamador [SWS_CM_00196]. Um estado central da instância é a proteção através de mecanismos End-to-End (E2E). Através do método GetE2EStateMachineState(), a aplicação pode determinar o estado atual da máquina de estados específica do método (ara::com::e2e::SMState) [SWS_CM_00148]. Este estado é determinado pela função interna de verificação E2E_Check(), que é executada durante o processamento da última chamada de operator() [SWS_CM_00148], SWS Communication Management, p. 55. Interpretação: a atualização do estado da máquina de estados E2E deverá tornar-se efetiva de forma assíncrona com a chegada e a verificação da mensagem de resposta. Pergunta Q-283a9927420e2952 (aberta)

Caminho de utilização

A sequência típica de chamadas compreende o desencadear da chamada do método, a sincronização com o resultado e a subsequente verificação de integridade:

1. Disparar a chamada: a aplicação cliente chama o objeto de função através de operator() com os parâmetros de entrada declarados [SWS_CM_00196], [SWS_CM_00191].
2. Retorno imediato: a chamada não bloqueia a thread solicitante, retornando imediatamente um objeto do tipo ara::core::Future<Output> [SWS_CM_00196].
3. Consulta do resultado: o chamador decide autonomamente entre a espera síncrona (p. ex., através do objeto Future) ou a monitorização assíncrona da conclusão da chamada [SWS_CM_00196]. Em caso de conclusão bem-sucedida, o Future fornece o objeto Output com os valores de resposta [SWS_CM_00196], [SWS_CM_99333].
4. Verificar o estado de proteção E2E: após a conclusão da chamada, a aplicação pode consultar o estado da máquina de estados E2E através de GetE2EStateMachineState(), para assegurar a validade da transmissão de dados [SWS_CM_00148].

Diagrama de sequência: fluxo típico de uma chamada de método com retorno assíncrono através de Future e subsequente consulta de estado E2E. Fontes: [SWS_CM_00196], [SWS_CM_00148].

Cenários de erro

As operações operator() e GetE2EStateMachineState() estão especificadas como seguras contra exceções (exception safe) e declaradas com noexcept [SWS_CM_00148], [SWS_CM_00196]. Erros de comunicação e de disponibilização não são, portanto, reportados através de exceções C++, sendo antes transportados através do objeto ara::core::Future resultante, que em caso de erro encapsula um respetivo ara::core::FutureErrc ou códigos de erro [SWS_CM_00196]. Entre as causas de erro especificadas contam-se, nomeadamente:

• CommunicationFailure: o Network Binding reporta um erro de comunicação recuperável ou a falha de uma ligação protegida; no caso de timeouts de comunicação, isto pode conduzir a um estado incerto no servidor remoto [SWS_CM_00196].
• ComErrc::kServiceNotAvailable: a instância de serviço já não se encontra acessível após uma disponibilização prévia [SWS_CM_00196].
• ComErrc::kUnknownApplicationError: um serviço remoto reporta um erro de aplicação não configurado [SWS_CM_00196].
• ComE2EErrc::kUnspecifiedE2EError: o serviço remoto reporta um erro End-to-End não especificado [SWS_CM_00196].
• ComErrc::kMinimumSendIntervalViolationError: a solicitação de chamada ocorreu mais depressa do que o intervalo de envio mínimo minimumSendInterval configurado para o elemento de interface permite [SWS_CM_00196].
• Violação de permissões (InsufficientPermissionsViolation): caso faltem ao chamador as permissões necessárias, a execução é recusada pelo Grant Enforcement [SWS_CM_00196].

Para estes erros de aplicação e de comunicação estão definidas, de acordo com a especificação, semânticas de rollback (rollback_semantics) [SWS_CM_00196].