CD Componente Diretório

O Componente Diretório (CD), instanciado no EXEHDABase, é formado por três módulos:

1. Controlador de Recursos - esse módulo tem 5 objetivos: (i) realizar a manu- tenção do estado dos recursos; (ii) gerenciar o Repositório de Recursos Ativos (RRA); (iii) gerenciar o Repositório de Recursos Negados (RRN); (iv) receber as consultas dos Componentes Cliente; e (v) receber as mensagens enviadas pelos Componentes Recurso. O lease é um intervalo de tempo, gerenciado pelo Con- trolador de Recursos. O Componente Recurso precisa renovar, periodicamente, o lease do recurso localizado no CD, caso contrário, será removido do Repositó- rio de Recursos Ativos (RRA). Quando se referir aos recursos presentes no am- biente computacional, a modelagem parte da premissa de que todo e qualquer recurso, quando descoberto pela primeira vez, tem suas características extraí- das de seu arquivo de configuração para armazenamento na ontologia. Uma vez presente no ambiente, há troca de mensagens entre o Componente Diretório e o Componente Recurso, garantindo que todos os recursos que não tenham seu lease renovado no período previsto, sejam desativados.

A modelagem proposta por este módulo, defende o uso de três possíveis valores para o estado atual de um recurso presente no ambiente:

• Inativo - estado de um recurso que se encontra no ambiente mas não teve seu estado renovado no limite de tempo previsto para sua renovação na arquitetura.

• Ativo - estado de um recurso que se fez descoberto recentemente pela ar- quitetura e que pode ser acessado por aplicações.

• Negado - estado de recurso definido de forma manual na arquitetura. Neste estado, todo e qualquer recurso neste estado será ignorado pela aplicação.

Para auxiliar com o controle do estado de recursos, são mantidas informações do estado atual de cada recurso presente no ambiente, bem como informa- ções referentes à última data que determinado recurso enviou uma mensagem, autoafirmando-se ativo no ambiente computacional. Por sua vez, o módulo Con- trolador de Recursos possui um serviço, denominado Controlador de Estado, que utiliza os seguintes repositórios: Repositório de Recursos Ativos (RRA) e Repositório de Recursos Negados (RRN).

O serviço Controlador de Estado é responsável por verificar periodicamente to- dos os recursos que não tiveram seu estado renovado, removendo-os do Re- positório de Recursos Ativos. Esse serviço implementa uma funcionalidade de autoconfiguração, visto que não é necessária a iteração do usuário para realizar a manutenção do estado do recurso.

O RRA é um repositório em base de dados relacional Postgres que mantém armazenados todos os recursos que se encontram ativos no ambiente computa- cional gerenciado pelo middleware EXEHDA, seu identificador e data de última atualização, tempo este utilizado para validação de seu estado atual.

O RRN, de igual modo que o RRA, também é um repositório em base de dados relacional Postgres, com a diferença, que mantém armazenados os recursos no primeiro momento em que eles forem anunciados pelo Componente Recurso, e que não podem ser retornados em consultas realizadas por aplicações externas.

2. Processador Semântico - responsável pelo processamento das consultas em lin- guagem SPARQL, segue o padrão arquitetural REST com a integração do Apa- che Jena Fuseki (DILLI et al., 2017). A base de dados TDB realiza a persistência de dados, sendo que o motor de inferência foi configurado para utilizar o racioci- nador genérico do Apache Jena. Com isso, é possível definir regras adicionais para aumentar a expressividade nas consultas. Por meio desse módulo, são re- alizadas as consultas à ontologia e são utilizados raciocinadores com o intuito

de aumentar a expressividade das consultas, gerando, por sua vez, melhores resultados (AZEVEDO, 2017).

O Processador Semântico atual foi aperfeiçoado e sua ontologia (Figura 12) re- modelada para fazer uso do servidor Apache Fuseki, base de dados TDB e lin- guagem de consulta SPARQL.

Figura 12 – Ontologia Concebida para o Processador Semântico do EXEHDA-RR

O Apache Fuseki é um componente do Apache Jena que engloba vários de seus componentes, a fim de disponibilizar um servidor SPARQL standalone, per- mitindo que sejam utilizadas as demais funcionalidades providas pelo Apache Jena (HOFEREK, 2012). A ferramenta Jena oferece as seguintes funcionalida- des:

• leitura, processamento e escrita de dados RDF em XML, em formato de triplas;

• uma API de ontologia para manipular OWL, com uso de RDF; • motor de inferência de raciocinadores RDF sobre dados OWL;

• armazenamento de grandes quantidades de triplas RDF, armazenadas em disco;

• motor de consulta com base nas últimas especificações da linguagem SPARQL;

• conjunto de configurações internas que permite que dados RDF sejam pu- blicados por outras aplicações, utilizando uma variedade de protocolos, in- cluindo SPARQL.

Em adição a todas essas características, o Fuseki permite que as consultas, as atualizações e os uploads de arquivos SPARQL sejam direcionadas a uma base de dados. Também conta com a presença de validadores para consultas e atualizações SPARQL, expandindo a comunicação para formatos além de RDF ou XML (XIN et al., 2013).

O TDB é uma base de dados que armazena informações em pares, contendo chaves e valores, sendo seus dados armazenados em formato binário. No Apa- che Jena, ele é o componente responsável por armazenar os dados RDF e realizar as consultas por meio da linguagem SQL. O Apache Fuseki admite a realização de procedimentos com a linguagem SPARQL no conjunto de dados presentes no TDB, baseado em padrões REST sobre o protocolo HTTP (XIN et al., 2013).

De acordo com a W3C, SPARQL contém um conjunto de padrões de triplas, de- nominado padrão básico de grafos. O resultado de dados de consulta SPARQL pode retornar conjuntos de grafos RDF. É considerada uma linguagem para trabalhar com dados RDF pela possibilidade de gerar consultas mais comple- xas, relacionadas diretamente com expressividade em resultados de buscas (PRUD’HOMMEAUX; SEABORNE, 2008).

3. Comunicador Intercelular - responsável pela comunicação com as células vizi- nhas. A comunicação entre as células é realizada utilizando tecnologias P2P entre os EXEHDABase de cada célula. A comunicação cliente/servidor ocorre apenas entre os diretórios localizados nos EXEHDABase. Os CC e CR acessam apenas o diretório da célula local. O Comunicador Intercelular é responsável por repassar a pesquisa para as células vizinhas.

4. Classificador de Recursos - tem por finalidade realizar a classificação dos recur- sos mais adequados à solicitação do cliente. Este módulo contém os seguintes serviços:

• Classificador MCDA - responsável por classificar todos os recursos desco- bertos através do algoritmo MCDA proposto.

• Pré-Classificador Machine Learning - por meio deste serviço, os novos re- cursos recém descobertos são pré-classificados, visando reduzir o custo computacional gerado pelo algoritmo MCDA.

• Classificador Fuzzy - tem por objetivo resolver as incertezas na especifica- ção e processamento de preferências do cliente.

A Figura 13 ilustra o fluxo de execução dos componentes do EXEHDA-RR e a atuação do módulo Classificador de Recursos e seus serviços.

Figura 13 – Fluxo de Execução do Módulo Classificador de Recursos

Considerando que o Módulo Classificador de Recursos do EXEHDA-RR agrega as principais contribuições desta Tese, segue, na Seção 4.2 uma discussão circunstanci- ada sobre esse módulo. Nesta seção estão sistematizadas as suas funcionalidades, os serviços da arquitetura que são envolvidos e a sua sinergia de atuação no atendi- mento das diferentes demandas.