classe ara::com::InstanceIdentifier

A classe ara::com::InstanceIdentifier representa o identificador técnico unívoco de uma instância de serviço concreta na AUTOSAR Adaptive Platform e permite o endereçamento através de bindings de comunicação específicos (AUTOSAR_AP_EXP_ARAComAPI p. 22 §4.1 «InstanceIdentifier class»). Como tipo de valor serializável, pode ser criada a partir de cadeias de carateres, comparada e gerida em contentores ([SWS_CM_11520], [SWS_CM_11523]). Enquanto aplicações padrão utilizam primordialmente identificadores de modelo abstratos, o uso direto deste identificador técnico serve casos especiais como multi-binding e soluções de fail-over (AUTOSAR_AP_EXP_ARAComAPI p. 25 «InstanceIdentifier Usage»).

mais ›

Contexto

A classe ara::com::InstanceIdentifier serve para a identificação inequívoca de uma instância concreta de serviço na Adaptive Platform (AdaptivePlatformServiceInstance), a fim de distinguir diferentes instâncias de exatamente o mesmo serviço entre si. Ela encapsula o endereçamento específico da tecnologia do binding de comunicação selecionado, mas não contém deliberadamente nenhum nome totalmente qualificado com informações sobre o tipo de serviço. Para o programador regular de software, a interação direta com ara::com::InstanceIdentifier é geralmente abstraída: enquanto no modelo de componentes de software são predominantemente utilizados nomes lógicos através de ara::core::InstanceSpecifier (AUTOSAR_AP_EXP_ARAComAPI p. 23 §4.2 «InstanceSpecifier class»), o integrador associa-os, através de ficheiros de manifesto, aos bindings técnicos e aos seus respetivos IDs de instância (AUTOSAR_AP_EXP_ARAComAPI p. 23 §4.2 «InstanceSpecifier class»).

No âmbito do chamado Multi-Binding, um único identificador abstrato pode ser mapeado em múltiplos bindings técnicos. A resolução através de ResolveInstanceIDs() retorna, por conseguinte, um ara::com::InstanceIdentifierContainer que agrega múltiplos ara::com::InstanceIdentifier (ARAComAPI p. 1 «Figure 6.6: InstanceIdentifier Resolution», AUTOSAR_AP_EXP_ARAComAPI p. 24 §4.3 «InstanceSpecifier Resolution»). Isto permite que servidores (Skeletons) atendam clientes através de diferentes tecnologias de transporte, ou que clientes (Proxies) implementem caminhos de fail-over (ARAComAPI p. 1 «Figure 6.6: InstanceIdentifier Resolution»).

Diagrama de contexto: Interação entre aplicação, manifesto de deployment, resolução de instâncias e interfaces de serviço. Fontes: ARAComAPI p. 103 «Figure 6.5: Service Discovery», AUTOSAR_AP_EXP_ARAComAPI p. 23 §4.2 «InstanceSpecifier class», AUTOSAR_AP_EXP_ARAComAPI p. 24 §4.3 «InstanceSpecifier Resolution»

Ciclo de vida

Instâncias de ara::com::InstanceIdentifier dispõem de semântica de valor plena. Elas cumprem os requisitos equalitycomparable, lessthancomparable bem como copyassignable de acordo com a ISO/IEC 14882:2014, o que permite geri-las, ordená-las e registá-las em contentores padrão. A classe disponibiliza os seguintes construtores e funções de ciclo de vida:

• Criação livre de exceções através do método de fábrica estático Create ([SWS_CM_11520]) com noexcept.
• Construtor explícito com base numa representação de string ([SWS_CM_11521]), o qual é expressamente não seguro contra exceções (not exception safe).
• Construtor de cópia ([SWS_CM_00056]) e construtor de movimento ([SWS_CM_00053]), ambos especificados como noexcept.
• Operador de atribuição por cópia ([SWS_CM_11525]) e operador de atribuição por movimento ([SWS_CM_00054]), cada um com noexcept.
• Operadores de comparação operator== ([SWS_CM_11523]) e operator< ([SWS_CM_11524]) para verificação de igualdade e de ordem.
• Destrutor ~InstanceIdentifier() ([SWS_CM_00055]) com noexcept.

Graças à interação do construtor de string com o método toString() ([SWS_CM_11522]), a classe é serializável (AUTOSAR_AP_EXP_ARAComAPI p. 22 §4.1 «InstanceIdentifier class»). Isso permite persistir, transmitir e posteriormente reutilizar um identificador. Uma interpretação de conteúdo (introspeção) da string serializada pela lógica da aplicação não está prevista, uma vez que a estrutura depende inteiramente do produto de middleware e do binding (AUTOSAR_AP_EXP_ARAComAPI p. 22 §4.1 «InstanceIdentifier class»).

Caminho de utilização

Como ara::com oferece sobrecargas para métodos comuns que aceitam diretamente ara::core::InstanceSpecifier, o manuseio manual de ara::com::InstanceIdentifier destina-se primariamente a casos de uso avançados, como bindings especializados ou failover direcionado (AUTOSAR_AP_EXP_ARAComAPI p. 25 «InstanceIdentifier Usage»). O fluxo típico divide-se nas seguintes etapas:

1. Resolução: A aplicação traduz o identificador abstrato de modelo por meio de ResolveInstanceIDs() nos identificadores técnicos de instância atribuídos (AUTOSAR_AP_EXP_ARAComAPI p. 24 §4.3 «InstanceSpecifier Resolution»).
2. Seleção: A partir do ara::com::InstanceIdentifierContainer resultante, a aplicação seleciona o ara::com::InstanceIdentifier pretendido (ARAComAPI p. 1 «Figure 6.6: InstanceIdentifier Resolution»).
3. Busca de serviço: O identificador é passado para o método estático FindService(ara::com::InstanceIdentifier instance) da classe proxy (ARAComAPI p. 103 «Figure 6.5: Service Discovery»).
4. Processamento: A busca de serviço retorna um ServiceHandleContainer com base no qual proxies são instanciados (ARAComAPI p. 103 «Figure 6.5: Service Discovery»). O identificador de instância pode ser consultado via GetInstanceId() (AUTOSAR_AP_EXP_ARAComAPI p. 30 «GetInstanceId»).

Diagrama de sequência: Resolução do identificador e busca direcionada de serviço por meio do InstanceIdentifier técnico. Fontes: ARAComAPI p. 103 «Figure 6.5: Service Discovery», AUTOSAR_AP_EXP_ARAComAPI p. 24 §4.3 «InstanceSpecifier Resolution»

Cenários de erro

Ao lidar com ara::com::InstanceIdentifier, devem ser consideradas especialmente duas situações de erro:

• Formato de string inválido (InvalidInstanceIdentifierStringViolation): Se for passado para Create ([SWS_CM_11520]) ou para o construtor ([SWS_CM_11521]) um identificador serializado que esteja corrompido, não conforme ou duplicado, ocorre esta violação. Interpretação: Enquanto o método de fábrica sem exceções Create provavelmente reporta isso por meio de um objeto de erro, o construtor não seguro contra exceções deverá disparar uma exceção em caso de erro. Pergunta Q-45a6fdd0859218bd (aberta)
• Mapeamento ausente na resolução: Se o integrador não tiver definido um mapeamento para um ara::core::InstanceSpecifier no manifesto de implantação, a chamada de ResolveInstanceIDs() retorna uma lista vazia (ARAComAPI p. 1 «Figure 6.6: InstanceIdentifier Resolution», AUTOSAR_AP_EXP_ARAComAPI p. 24 §4.3 «InstanceSpecifier Resolution»). Isso geralmente representa um erro de configuração.
• Instância de serviço ausente: Se nenhum OfferService() correspondente tiver sido executado no lado do skeleton para o identificador especificado, o ServiceHandleContainer fornecido por FindService permanece vazio (ARAComAPI p. 103 «Figure 6.5: Service Discovery»).