Implementação do Serviço de Registro e Diretório

O serviço da infraestrutura que mais sofreu alterações em comparação ao proposto em (Rodrigues, 2009a) foi o Serviço de Registro e Diretório (SRD). Sua implementação inicial era baseada em listas de objetos em memória e foi totalmente remodelada para usar a Ontologia de Recursos como fonte de informações (diretório) dos recursos disponíveis.

Na solução adotada foi abolida a leitura de tipos de recursos pré-cadastrados pelo administrador da infraestrutura, anteriormente realizada na iniciação do SRD. A definição de tipos estáticos foi substituída pela definição de classes dentro da Ontologia de Recursos. Classes estas que são alimentadas ao longo da execução das aplicações cientes de contexto, através do registro de cada recurso na infraestrutura.

AbstractDirectoryService {abstract} - - - - directoryQueryType1Parser directoryQueryType2Parser resource directories : DirectoryQueryType1Parser : DirectoryQueryType2Parser : ResourceOCDRF : List<DirectoryService> = new DirectoryQueryType1Parser() = new DirectoryQueryType2Parser() = new ArrayList<DirectoryService>() + + + + + # # # #

initialize (File configFile) stop ()

federateDirectoryService (String url) queryType1 (String xml)

queryType2 (String xml)

queryType1 (DirectoryQueryType1 query) queryType2 (DirectoryQueryType2 query) getResource ()

setResource (ResourceOCDRF resource) : void : void : DirectoryService : String : String : DirectoryResponseType1 : DirectoryResponseType2 : ResourceOCDRF : void DirectoryService + + + + registerResource (String xml) removeResource (String xml) queryType1 (String xml) queryType2 (String xml) : String : String : String : String OntologyDirectoryService {abstract} - - - - infOntoModel reasonerModel NS discoveryOntologies : OntModel : InfModel : String

: Map<String, String> = new HashMap<String, String>() + - - - - - + + - - - # - - #

initialize (File configFile) loadInitialOntology () testOntology () testOntologyAgain () uploadProperties ()

getAttributeDetails (Resource attribute) registerResource (String xml)

removeResource (String xml) readConfig (File file)

getComponentType (Resource componente)

getComponent (Resource searchResource, Resource searchCapacity) queryType1 (DirectoryQueryType1 query)

getAttribute (DirectoryResponseType1Info resourceInfo, String attributeName) queryOntology (DirectoryQueryType1Target queryTarget)

queryType2 (DirectoryQueryType2 query)

: void : void : void : void : void : Attribute : String : String : void : String : Resource : DirectoryResponseType1 : Attribute : List<DirectoryResponseType1Info> : DirectoryResponseType2

Figura 6 - Estrutura de classes do SRD

A classe abstrata OntologyDirectoryService é a classe responsável pela manipulação da Ontologia de Recursos. Ela possui o atributo infOntoModel, objeto da classe OntModel, disponibilizada pelo framework Jena. Este atributo encapsula a descrição dos componentes de um modelo ontológico e a associa a uma forma de armazenamento e a uma máquina de inferências. Então, infOntoModel representa o modelo ontológico inicial definido pela Ontologia de Recursos, associado a uma especificação de modelo ontológico pré-definida no

Jena, OWL_MEM_MICRO_RULE_INF, que permite que sejam feitas inferências considerando as propriedades de transitividade, inversão e simetria, além de fornecer bom desempenho.

O atributo reasonerModel é um objeto da classe InfModel do Jena. Esta classe permite a associação do modelo ontológico inicial às regras de inferência associadas à Ontologia de Recursos, estabelecidas como no arquivo ResourceRules.txt, configurado no OCDRF como apresentado no Código 28.

A classe Resource fornecida pelo Jena representa qualquer instância da ontologia. Ela é utilizada no OCDRF, para várias funções, entre elas, como parâmetro de entrada do método

getAttributeDetails na classe OntologyDirectoryService que recupera as informações

associadas às instâncias da classe Attribute referentes a um recurso.

O Serviço de Registro e Diretório é inicializado através do método initialize, que sobrescreve o método de mesmo nome de sua super classe conforme o Código 30.

1 @Override

2 public void initialize(File configFile) throws DirectoryServiceException 3 {

4 if (configFile.exists()) { 5 readConfig(configFile); 6 loadInitialOntology(); 7 } else {

8 System.err.println("Configuration file not found: " + configFile.toString());

9 System.exit(4); 10 }

11 }

Código 30 - Inicialização do Serviço de Registro e Diretório

O método initialize, apresentado no Código 30, executa a leitura do arquivo de configuração do serviço através do método local privado readConfig (Linha 5) e a carga e verificação da Ontologia de Recursos inicial através do método loadInitialOntology (Linha 6). O método readConfig (Linha 5) é responsável por ler, além das configurações existentes em (RODRIGUES, 2009a), uma nova propriedade incluída no arquivo de configuração do SRD. Esta propriedade possui o nome do arquivo que contém a Ontologia de Recursos definida pelo administrador da infraestrutura e as regras de inferência que devem ser aplicadas a ela.

Depois de capturado o nome deste arquivo, o método loadInitialOntology é executado (Linha 6). Este método realiza a leitura da ontologia contida no arquivo e, com a utilização do

framework Jena (JENA, 2011), carrega classes Java que representarão as classes e as

propriedades sobre estas classes que foram definidas na ontologia.

O arquivo que contém a Ontologia de Recursos e o arquivo que contém as regras associadas a esta ontologia são definidos no arquivo de configuração do SRD, conforme apresentado no Código 28.

As operações expostas pelo Serviço de Registro e Diretório são definidas pela interface DirectoryService apresentada no Código 31.

1 public interface DirectoryService { 2 String registerResource(String xml); 3 String removeResource(String xml); 4 String queryType1(String xml); 5 String queryType2(String xml); 6 }

Código 31 - Interface do Serviço de Registro e Diretório

A interface do SRD foi simplificada em comparação com a proposta em (RODRIGUES, 2009a). O SRD disponibiliza operações para registro de novos recursos “registerResource” (Linha 2) e para exclusão de um recurso do diretório “removeResource” (Linha 3). Além de operações de busca, “queryType1” (Linha 4), método principal de busca na Ontologia de Recursos, e “queryType2” (Linha 5), método que dá suporte aos pontos de extensão para buscas de propriedades definidas em Ontologias Cliente, que são as consultas estendidas apresentadas na Seção 2.4.1. Todas estas operações disponibilizadas pelo SRD recebem como parâmetro uma string XML que especifica os detalhes necessários para sua execução.

O método registerResource, implementado na classe OntologyDirectoryService, é o responsável por tratar os pedidos de registro de ARs e agregar à ontologia principal as configurações recebidas. Ao utilizar o método registerResource, os recursos que desejarem fazer parte da infraestrutura não precisarão obedecer a um formato fixo de mensagem, tampouco estar associados a tipos pré-cadastrados, como proposto em (RODRIGUES, 2009a). Não há necessidade de registro prévio com os tipos aceitos.

Um AR ao se registrar, informa suas características utilizando a linguagem OWL. Para isto devem ser definidas instâncias de classes da Ontologia de Recursos e novas classes e propriedades, caso seja necessário, assim como apresentado no exemplo do Código 39. Estas

informações são então adicionadas à Ontologia de Recursos já registrada no SRD. Para isto, o método registerResource faz a leitura do OWL enviado pelos ARs e o carrega no SRD utilizando o método add da classe InfModel do framework Jena.

Sempre que as informações de registro de um novo recurso são carregadas, o atributo privado infOntoModel da classe OntologyDirectoryService é atualizado. Desta forma, informações completas e atualizadas estão sempre disponíveis para as consultas efetuadas no SRD. Este trabalho é realizado pelo método registerSubOntology.

Na Figura 7 é apresentado o diagrama de sequência com as operações realizadas durante o processo de registro de um AR no sistema. Através do método registerSubOntology, a cada registro efetuado, novos elementos são adicionados à ontologia principal.

registerSubOntology(subModel: OntModel) resourceRegister(ontologyStr: String)

AR :OntologyDirectoryService

registerSubOntology(subModel: OntModel) resourceRegister(ontologyStr: String)

Figura 7 - Diagrama de Sequência da operação de registro de um AR

Os serviços da infraestrutura (Serviço de Contexto e o Serviço de Descoberta) também são tratados pelo SRD como recursos logo, também precisam se registrar enviando suas informações em formato OWL, assim como descrito nas Seções 4.3 e 4.4.

As buscas realizadas pelo OCDRF, através dos métodos “queryType1” e “queryType2”, retornam as informações dos recursos que possuam características semanticamente equivalentes às pesquisadas. Para a análise dos recursos durante as buscas, são consideradas informações alcançadas através de inferências considerando todas as relações entre as instâncias da ontologia. Entre elas, relações especificadas nativamente na linguagem OWL como herança, e relações de equivalência de instâncias, “sameAs” e de classes, “equivalentClass”.

O SD e SC realizam as consultas ao SRD através do método queryType1 da interface

DirectoryService que é implementado na classe OntologyDirectoryService. Este método

invoca os métodos de consulta, disponibilizados pelo Jena, sobre o atributo reasonerModel para montar a lista de recursos de resposta. A partir desta lista, o parser implementado

utilizando o pacote com.thoughtworks.xstream(XSTREAM, 2011) é utilizado para montar a

mensagem de retorno no formato esperado.

Finalmente, o método queryType2 pode ser invocado para tratar restrições de suas consultas do tipo ClientConstraint. Na implementação de referência, apenas o SD invoca o método queryType2 disponibilizado pelo SRD. Este método recupera valores de propriedades definidas em Ontologias Cliente e atribuídas às instâncias da Ontologia de Recursos. As propriedades utilizadas para estas consultas devem estar corretamente configuradas na inicialização do SRD como apresentado no Código 6.

4.2.1 Representação dos Elementos da Infraestrutura

Na proposta deste trabalho, os próprios elementos da arquitetura do OCDRF são também representados e posteriormente localizados a partir da Ontologia de Recursos.

Os elementos do OCDRF poderiam ser mapeados na Ontologia de Recursos de várias formas. Uma forma seria criar uma instância de Resource que representasse o OCDRF, isto é que representasse um conjunto de serviços da infraestrutura. Nesta representação, os serviços SC e SD seriam mapeados como ResourceComponents.

Porém a forma adotada foi representar cada elemento da infraestrutura como um

Resource. Desta forma, cada serviço pode ter sua implementação como um web service

separado, com string de conexão própria. Isto permite uma maior escalabilidade e facilidade de migração do ambiente de execução de cada serviço. Um exemplo da representação utilizada para um serviço da infraestrutura é apresentado no Código 33 da Seção 4.3.