Relacionamento dos Componentes Arquiteturais

A concisa definição dos requisitos demandados por cada componente fornece uma visão mais sólida do papel desempenhado por estes, entretanto seu relacionamento

permanece ainda fluído. Uma ilustração sucinta da relação entre eles é ilustrada na Figura 27, em que uma consulta realizada por um usuário em um nó A é remetida a um nó B utilizando os diversos componentes acima descritos.

Figura 27. A Estrutura de Componentes e Relacionamentos da Arquitetura de Nomes

Observando o hipotético cenário da Figura 27 que nó A deseja obter um objeto remoto localizado em um nó B utilizando os componentes da nova Arquitetura de Nomes sem hierarquia, o primeiro passo consiste na identificação do SID associado ao nome semântico deste objeto. Para tal, será necessária uma consulta ao RRS de Canonização e este deve retornar um conjunto de possíveis identificadores realizando o mapeamento:

• 1 nome semântico -> n referências flat SID

Obtido este conjunto de possíveis SIDs, o nó cliente (com ou sem a interferência do usuário) deve selecionar o SID candidato (cenário análogo ao que ocorre atualmente, por exemplo, quando um usuário realiza uma consulta a uma máquina de busca e necessita selecionar uma entre várias possíveis respostas) e então consultar a DHT SID para obter o(s) referido(s) EID. Um conjunto de EIDs pode estar associado a um único SID, conforme previsto na proposta arquitetural. Um hipotético cenário em que isso é desejável consiste em mecanismos de balanceamento de carga ou replicação de conteúdo. E, portanto, diferentes QoSC estarão associados a cada resposta obtida de acordo com as características disponibilizadas pela entidade provedora de informações QoSC. A cardinalidade deste mapeamento bem como características hipotéticas de serem fornecidas pelas respostas é a seguinte:

• 1 referência SID -> n referências flat EID (identificador, caminho, porta, latência, carregamento, ..., etc)

Cada identificador de nós EID pode, e provavelmente deve, apresentar características diversas de QoSC e a escolha de qual candidato é mais adequado representa um critério definido pelo cliente. Esta escolha pode consistir em um mecanismo automatizado que priorize certa característica em detrimento de outra, como por exemplo, sempre escolher o servidor com menor carregamento ou maior largura de banda, ou ser selecionada manualmente.

A solicitação de características de QoSC não consiste em um requisito mandatório do sistema e sua ausência não deve inviabilizar o funcionamento do mesmo, ficando o cliente responsável pela decisão de prosseguir ou não em face a indisposição das mesmas. A disposição/atuação do Provedor de QoSC pode ser tão dispersa quanto o modelo de economia que norteará esta arquitetura e sua escolha representa uma questão aberta e fluída, assim como o era o futuro das Máquinas de Busca nos seus primórdios (com inserções manuais de novas entradas e sem uma política econômica bem definida).

Atualmente, diversos são os incentivos para sua subsistência econômica daquelas sendo sua fonte principal de capital a publicação de anúncios privados criteriosamente selecionados de acordo com as buscas realizadas por seus clientes e altamente automatizada é a inserção de novas entradas, como pode ser observada através do algoritmo de busca e classificação adotado pelo Google, o Map Reduce [87].

Desta forma, pode-se vislumbrar alguns cenários para a disposição e o acionamento do Provedor de QoSC, como será ilustrado abaixo. Ressalvas devem ser feitas aqui, entretanto, quanto à necessidade de o mesmo ser uma entidade confiável e terceira ao sistema, ou seja, há um conflito claro de interesses entre proprietários de conteúdos e Provedores de QoSC, pois estes serão responsáveis por classificar aqueles e, portanto, não é desejável que representem simultaneamente ambos os papéis.

• O Provedor de QoSC pode ser acionado pela Máquina de Busca Canônica e esta disponibilizará (automaticamente ou manualmente) uma conjunto de informações associadas às referências consultadas. É possível a existência de cenários em que os clientes optem por um “modo avançado”, em que estes desejem escolher minuciosamente quais critérios de QoSC representam sua preferência. Ou, por um “modo básico” em que a Máquina de Busca define que a melhor referência para seus

clientes neste modo será norteada por um critério (e.g. latência) ou por um conjunto deles (e.g. latência, largura de banda e carregamento do servidor).

• O Provedor de QoSC pode ser acionado simultaneamente pelo cliente no momento da consulta à DHT SID quando da procura pelo conjunto de referências EID. E neste caso, novamente, é possível imaginar a existência de escolhas manuais ou automatizadas na definição final de qual EID acessar.

• Finalmente, é possível imaginar um terceiro cenário, que tem grande potencial de ser o modelo inicialmente adotado, que é aquele em que o auditor de QoSC representa uma entidade relativamente desvinculada das consultas feita pela Máquina de Busca ou ao RRS SID. Neste caso, quando os clientes desejarem verificar a existência de informações de QoSC de um certo conteúdo, estes terão, por exemplo que navegar pelo site de QoSC e verificar quais os indicadores estão disponíveis para um certo proprietário e então definir sua classificação pessoal sobre este proprietário.

Por fim, selecionado qual o EID candidato, deve-se remeter ao subsistema de resolução RRS EID, ou seja, à DHT EID para obter o conjunto de possíveis endereços associados ao servidor procurado (e.g. cenário de servidor em multihoming). O mapeamento esperado é o seguinte:

• 1 referência EID -> n endereços IP

Neste momento, ambas as partes podem ser sensibilizadas (i.e. um pedido de conexão pode acontecer), autenticadas e um fluxo seguro (e.g. IPSEC) pode ser iniciado.

Considerações sobre a mobilidade de objetos podem ser feitas neste momento. Conforme discutido anteriormente, a conexão nesta nova proposta arquitetural não será mais baseada no par <IP, Porta>, mas sim no par <SID, Porta> e mobilidades de EIDs e IPs são mutuamente suportadas. A ocorrência de mudanças nos endereços IP, caso mais freqüente, requer a atualização na associação <EID, IP> e correrá, por exemplo, quando houver a mobilidade de um nó entre domínios distintos. Mudanças no identificador EID, menos freqüentes, também são suportadas e estas requerem atualizações na associação <SID, EID> para que a semântica da conexão seja mantida.

No cenário hipotético em que uma aplicação seja migrada de um servidor mais sobrecarregado para um terceiro servidor menos congestionado em um processo naturalmente suportado de balanceamento de carga por esta nova Arquitetura, seu EID seria modificado ainda que a aplicação mantenha seu SID intacto. Obviamente, mudanças no identificador de

um objeto (i.e. um dado, serviço ou usuário) são possíveis e modificam seu SID e, neste caso, a semântica da conexão não será preservada.