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

O espaço de nomes encapsula as classes de campo do lado do servidor para cada campo declarado numa ServiceInterface dentro da arquitetura de skeleton do módulo com. Os fornecedores de serviços utilizam estas classes geradas para gerir o valor atual do campo e transmiti-lo aos clientes conectados em caso de alterações de valor. A instanciação e o tempo de vida dos objetos de campo deverão estar diretamente vinculados à instância de skeleton superior. Pergunta Q-bd1d4d2cab97eada (aberta) Na atualização e disponibilização dos dados, deve ter-se em conta a sincronização de acordo com o modelo de threading do esqueleto de serviço.

mais ›

Contexto

O espaço de nomes <SI-Namespace>::skeleton::fields faz parte da arquitetura de comunicação (módulo com) da AUTOSAR Adaptive Platform na release R25-11. Contém as classes geradas do lado do servidor para todos os campos que foram modelados num ServiceInterface no papel field. Para cada campo definido na interface, existe uma classe de campo de esqueleto de serviço correspondente que segue o esquema de nomes genérico <Field>. Estas classes constituem a ligação entre a implementação de um serviço específica da aplicação e a camada de comunicação subjacente, de modo a disponibilizar estruturas de dados relativas a campos de forma estruturada.

Em arquiteturas orientadas a serviços (SOA), os campos representam propriedades de um serviço que podem ser tipicamente compostas por uma combinação de acessos de leitura (getters), acessos de escrita (setters) e notificações baseadas em eventos (notifiers). Enquanto no lado do cliente, no espaço de nomes de proxy, são geradas interfaces correspondentes para o acesso de consumo, skeleton::fields disponibiliza as classes com as quais o fornecedor de serviços (servidor) gere o estado interno e o expõe externamente. As classes no espaço de nomes <SI-Namespace>::skeleton::fields encapsulam a comunicação e a transmissão específica do protocolo, permitindo ao programador da aplicação concentrar-se na lógica funcional do serviço.

Ciclo de vida

No que diz respeito à criação e às relações de posse, o tempo de vida de uma classe de campo no espaço de nomes skeleton::fields deverá estar diretamente vinculado à classe de skeleton superior da interface de serviço. Em implementações da Adaptive Platform baseadas em C++, as instâncias de campo são tipicamente instanciadas como objetos-membro diretos dentro do skeleton gerado. Consequentemente, o ciclo de vida dos objetos de campo começa com a chamada do construtor do esqueleto de serviço e termina automaticamente com a sua destruição. Pergunta Q-375f07429819a937 (aberta)

Durante a fase de operação, o objeto de campo permanece na memória do fornecedor de serviços. Antes ou durante a oferta do serviço na rede (por exemplo, antes do registo do serviço ou imediatamente após), a instância de campo é inicializada com um valor inicial válido. Visto que o skeleton se encontra disponível para consultas e atualizações ao longo de todo o seu tempo de vida, a instância de campo também permanece persistentemente disponível.

No que diz respeito à concorrência e ao threading, o tratamento de acessos a campos deverá depender fortemente do modelo de processamento escolhido para o skeleton. Pergunta Q-d3456f67c7a4ba8d (aberta) Caso a classe de campo disponibilize mecanismos de callback para pedidos de leitura ou escrita recebidos ou ofereça métodos para atualização do valor do campo, os acessos concorrentes através da implementação do serviço utilizador têm de ser sincronizados para evitar condições de corrida (race conditions) durante o processamento concorrente.

Caminho de utilização

O caminho de utilização típico para as classes de <SI-Namespace>::skeleton::fields tem início no âmbito da inicialização do fornecedor de serviços. Durante a construção da instância de skeleton, é gerado o respetivo objeto de campo para cada campo configurado. A implementação do serviço atribui tipicamente à classe de campo um valor inicial válido, para que os clientes requisitantes encontrem dados consistentes desde o início.

Na operação contínua, a interação ocorre primariamente através de atualizações de valores. Assim que estados internos, valores de sensores ou dados de cálculo se alteram na aplicação de serviço, o skeleton chama o respetivo método de atualização da instância de campo. A classe de campo assume de seguida a distribuição dos novos dados para o framework de comunicação, que envia os valores como mensagens de notificador para todos os proxies de serviço interessados e subscritos na rede.

Caso o campo esteja configurado para acessos de escrita por clientes, a classe de campo processa os pedidos de atualização recebidos (operações de set). A implementação do serviço recebe os valores alterados, valida-os e atualiza o estado interno. Através deste fluxo direcionado de inicialização, transmissão de valores periódica ou baseada em eventos e encerramento controlado com o fim do tempo de vida do skeleton, as classes de campo integram-se harmoniosamente no padrão de interação do nível de serviços da AUTOSAR Adaptive.