namespace <SI-Namespace>::proxy::fields

O namespace <SI-Namespace>::proxy::fields encapsula, no módulo com da Adaptive Platform, as classes proxy geradas <Field> para cada campo de dados definido em uma ServiceInterface. Aplicações clientes acessam essas classes de campo por meio do proxy de serviço superior para consultar ou definir valores remotos de campos, ou processar notificações sobre alterações de valor. Chamadas em campos são processadas de forma assíncrona por meio da infraestrutura de comunicação a fim de garantir interações não bloqueantes. Pergunta (aberta) O tempo de vida das instâncias individuais de campo está provavelmente vinculado de forma fixa ao ciclo de vida do objeto proxy superior e não pode ser gerenciado independentemente dele.

mais ›

Contexto

O namespace C++ <SI-Namespace>::proxy::fields assume, no módulo com da AUTOSAR Adaptive Platform, uma função de estruturação claramente delimitada para interfaces orientadas a serviços. Interfaces de serviço (ServiceInterfaces) frequentemente definem, além de métodos e eventos, campos de dados que representam um estado atual. Para disponibilizar esses campos no lado do cliente para consumidores de serviço com segurança de tipos e de forma semanticamente inequívoca, o gerador de código organiza as classes de campo específicas dentro desse sub-namespace dedicado. Para cada campo modelado na respectiva ServiceInterface, é gerada exatamente uma classe de campo de proxy <Field>. Esse encapsulamento estrutural evita conflitos de nomes com métodos ou eventos homônimos dentro do namespace de proxy superior. Interpretação: as classes de campo geradas <Field> disponibilizam tipicamente funções de interface especializadas para funcionalidades de Get, Set e notificação, a fim de consultar valores pontualmente, modificá-los ou receber alterações assinadas. Pergunta Q-f088d0c5052459d3 (aberta) O parceiro direto de interação das classes de campo é a lógica de aplicação do consumidor do serviço, de um lado, e o middleware de comunicação subjacente, de outro.

Ciclo de vida

A instanciação e o gerenciamento dos objetos de <SI-Namespace>::proxy::fields estão indissociavelmente vinculados à arquitetura do proxy de serviço. Desenvolvedores de aplicação geralmente não criam instâncias da classe gerada <Field> manualmente como variáveis autônomas na heap ou na stack. Em vez disso, o tempo de vida de uma instância de <Field> está provavelmente vinculado por completo ao ciclo de vida do proxy de serviço superior, que mantém esses campos como membros. Com a construção bem-sucedida da instância de proxy após a localização de um endpoint de serviço adequado, os objetos de campo são inicializados e colocados em um estado operacional. Durante a fase ativa, o objeto de campo gerencia recursos internos de comunicação, bem como eventuais registros para atualizações de estado. Se a instância de proxy for destruída pela aplicação ou sair de seu escopo de validade, consequentemente as instâncias de campo associadas também são devidamente desconstruídas, liberando assim recursos vinculados do middleware. Pergunta Q-4da7e86f88f269b1 (aberta)

Caminho de utilização

O fluxo de utilização típico das classes no namespace <SI-Namespace>::proxy::fields subdivide-se em uma ordem fixa de etapas de interação. Inicialmente, a aplicação cliente determina a instância do serviço desejado por meio dos mecanismos de busca da Adaptive Platform e instancia o respectivo proxy de serviço. Na segunda etapa, a aplicação acessa, por meio do proxy, a respectiva instância membro da classe gerada <Field>. Dependendo das propriedades do campo definidas no modelo de interface, a aplicação inicia então um acesso de leitura, um acesso de escrita ou registra um callback para notificações sobre alterações de valor. As chamadas em campos devem ser processadas de forma assíncrona por meio de ara::core::Future ou de mecanismos de callback da infraestrutura de comunicação, a fim de evitar chamadas bloqueantes na thread chamadora. Após a chegada da resposta ou notificação, o chamador avalia o resultado fornecido e reage ao estado do campo remoto. Pergunta Q-33586a48d8777f7f (aberta)