namespace <SI-Namespace>::proxy

O namespace <SI-Namespace>::proxy disponibiliza, dentro do módulo com, a interface do lado do cliente para a interação com uma Service Interface. Seu componente central é a classe proxy <SI>Proxy, que abstrai a comunicação do middleware e possibilita chamadas de método bem como assinaturas de eventos. A instanciação do proxy tipicamente pressupõe um handle válido decorrente da busca de serviço. Como condição de contorno essencial, a aplicação chamadora deve tratar de forma robusta interrupções de conexão e tempos de resposta assíncronos em chamadas remotas. Pergunta (aberta)

mais ›

Contexto

O namespace <SI-Namespace>::proxy mapeia, dentro do módulo de comunicação com da AUTOSAR Adaptive Platform, a representação do lado do cliente de uma Service Interface. Ele reúne todos os artefatos e tipos necessários para que consumidores de serviços interajam com um serviço oferecido pela rede de comunicação. No centro desse namespace está a classe proxy gerada <SI>Proxy. Essa classe abstrai a configuração subjacente de rede e de comunicação interprocessos baseada em mensagens e disponibiliza uma interface C++ por meio da qual o software de aplicação pode chamar métodos, assinar eventos, bem como consultar e observar campos.

Arquiteturalmente, o proxy atua como um intermediário entre a lógica de cliente específica da aplicação e o ambiente de execução da Adaptive Platform. Em vez de interações diretas com a rede ou memória compartilhada, o desenvolvedor da aplicação interage exclusivamente com as instâncias de <SI-Namespace>::proxy. Dessa forma, realiza-se um desacoplamento que permite que protocolos de comunicação, formatos de transmissão de dados e detalhes de localização sejam gerenciados de forma transparente pelo middleware subjacente da plataforma.

Ciclo de vida

O ciclo de vida de objetos no namespace <SI-Namespace>::proxy está estreitamente vinculado à disponibilidade da instância de serviço correspondente. Antes que uma instância de proxy possa ser criada, deve ocorrer uma detecção de instâncias. A instanciação do proxy <SI>Proxy tipicamente requer um handle resultante da busca de serviço. Após a instanciação bem-sucedida, o objeto proxy representa uma conexão lógica com o respectivo provedor de serviço. Pergunta Q-3dcfd734b218f865 (aberta)

Durante a fase de operação ativa, a instância de proxy gerencia os estados relativos a eventos assinados e a chamadas de método assíncronas pendentes. Em relação à concorrência, deve-se observar que as chamadas ao proxy precisam ser concebidas de forma thread-safe ou sincronizadas adequadamente pelo cliente, caso múltiplas threads utilizem o mesmo objeto proxy. A liberação ou destruição do objeto proxy encerra a vinculação com a instância de serviço encontrada e desfaz assinaturas em andamento. Pergunta Q-e9d55205ba1bf55b (aberta)

Caminho de utilização

Um caminho de uso típico para a utilização do proxy de Service Interface subdivide-se em várias fases consecutivas:

• Localização da instância de serviço: o cliente inicia, por meio dos mecanismos de plataforma do módulo com, uma busca por instâncias disponíveis do serviço e recebe de volta as respectivas estruturas de handle.
• Construção do proxy: utilizando um handle válido, instancia-se uma instância de <SI>Proxy, estabelecendo-se assim o canal de comunicação com o servidor.
• Interação com elementos de serviço: por meio da instância, métodos são chamados de forma síncrona ou assíncrona, eventos são assinados e callbacks são registrados. Padrões de comunicação assíncronos são provavelmente mapeados por meio de wrappers tipados de eventos e métodos dentro da instância de proxy. Pergunta Q-2e6b91c7e5f88567 (aberta)
• Encerramento e limpeza: após a conclusão da comunicação, o cancelamento da assinatura dos eventos é realizado e a instância de proxy é devidamente destruída a fim de liberar recursos ocupados.

Cenários de erro

Na interação com o namespace do proxy, podem ocorrer diferentes cenários de erro. Entre eles estão quedas de conexão com o servidor, timeouts em chamadas remotas, bem como a indisponibilidade de instâncias de serviço solicitadas durante a inicialização. Como a comunicação ocorre através de fronteiras de processos e de computadores, falhas de infraestrutura ou indisponibilidades do interlocutor refletem-se nos valores de retorno. Chamadas antes de uma vinculação bem-sucedida ou após a destruição da instância levam a estados inválidos, razão pela qual pré-condições relativas à validade do handle devem ser estritamente respeitadas.