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

O namespace <SI-Namespace>::skeleton::triggers disponibiliza classes específicas para esqueletos de serviço no módulo de comunicação com da AUTOSAR Adaptive Platform, a fim de aceder no lado do servidor a triggers definidos em ServiceInterface. Para cada trigger declarado no papel trigger, é disponibilizada uma instância da classe <Trigger>, através da qual os fornecedores de serviços podem disparar sinais de eventos para clientes conectados. Presumivelmente, o tempo de vida destas classes de trigger está estritamente vinculado ao objeto skeleton superior, razão pela qual a sua utilização pressupõe a inicialização prévia e a oferta do respetivo serviço. Os fornecedores de serviços devem também ter em conta que chamadas de trigger simultâneas a partir de várias threads deverão exigir sincronização do lado da aplicação. Pergunta (aberta)

mais ›

Contexto

O namespace <SI-Namespace>::skeleton::triggers é um espaço de nomes especializado do módulo de comunicação com da AUTOSAR Adaptive Platform (Release R25-11). Dentro da arquitetura orientada a serviços (SOA), o ServiceInterface constitui a especificação formal de interface que define o âmbito funcional e os padrões de comunicação entre fornecedores de serviços (skeletons) e consumidores de serviços (proxies). Além de métodos para chamadas de funções síncronas ou assíncronas, eventos para transmissão de dados e campos para propriedades com estado, as interfaces de serviço também podem conter triggers. Para cada trigger declarado num ServiceInterface no papel trigger, o namespace <SI-Namespace>::skeleton::triggers disponibiliza uma classe própria de trigger de esqueleto de serviço <Trigger>.

O papel central destas classes consiste em fornecer à aplicação de servidor uma abstração dedicada para a sinalização de impulsos de controlo ou de notificação. Ao contrário dos eventos clássicos, que servem primariamente o transporte de dados contínuo ou orientado a eventos, um trigger sinaliza tipicamente a ocorrência de um evento definido ou mudança de estado. Entre os principais intervenientes na interação das classes de trigger encontram-se a lógica da aplicação fornecedora, o esqueleto de serviço agregador, bem como o middleware de comunicação de com, que assume o reencaminhamento dos sinais através do respetivo binding de transporte.

Ciclo de vida

O ciclo de vida das classes de trigger no namespace <SI-Namespace>::skeleton::triggers está diretamente acoplado ao esqueleto de serviço superior. Presumivelmente, para cada trigger definido em ServiceInterface, é instanciada exatamente uma instância da classe <Trigger> aquando da criação do esqueleto de serviço e gerida por este. Pergunta Q-a0d69b49748aa8c4 (aberta) Habitualmente não ocorre uma criação ou destruição isolada pela aplicação de serviço.

Na fase de operação, a utilização divide-se em três fases características: a fase de inicialização, a fase de transmissão ativa e a fase de terminação. Durante a inicialização, a camada de comunicação configura os bindings e recursos necessários para o trigger. Assim que o provedor do serviço disponibiliza oficialmente o serviço no sistema através do skeleton, o trigger transita para o estado operacional. Nesta fase, a lógica da aplicação pode acionar processos de disparo repetidamente. Se a oferta do serviço terminar ou se o skeleton for libertado, os recursos de trigger associados também são limpos. Em termos de concorrência, no caso de acionamento simultâneo do trigger a partir de múltiplas threads, é provável que seja necessária uma sincronização do lado da aplicação, a menos que o framework de comunicação subjacente garanta segurança intrínseca de threads para chamadas concorrentes do trigger. Pergunta Q-eb23aad9119e9a8f (aberta)

Caminho de utilização

O percurso de utilização típico para as classes de <SI-Namespace>::skeleton::triggers compreende todo o fluxo, desde a definição da interface até à desativação do serviço:

• Design da interface e geração de código: No modelo de software é definido um ServiceInterface que contém pelo menos um trigger no papel trigger. O gerador de código da plataforma gera a partir daí o namespace <SI-Namespace>::skeleton::triggers e a classe correspondente <Trigger>.
• Instanciação do skeleton: A aplicação servidora instancia a implementação concreta do skeleton de serviço. Interpretação: O acesso à instância de <Trigger> é exposto ao provedor do serviço através da interface de membros do skeleton. Pergunta Q-f287180a040cea33 (aberta)
• Disponibilização do serviço: O skeleton de serviço inicia a oferta de serviço na rede, para que os proxies de cliente possam encontrar o serviço e registar-se em notificações de trigger.
• Acionamento do trigger: Assim que uma condição de trigger é satisfeita na lógica da aplicação, o software do servidor chama o método de disparo no objeto <Trigger>. A plataforma transmite o sinal a todos os consumidores registados.
• Desativação: A aplicação servidora retira a oferta de serviço e destrói a instância do skeleton, desalocando também de forma determinística os objetos de trigger.