Figura 5.1: Arquitetura do OpenCOPI - extraído de [Lopes et al., 2009b]
componente implementa a interface do lado do OpenCOPI e define as operações para a transformação do modelo de contexto e a comunicação entre OpenCOPI e um middleware específico [Lopes et al., 2009b].
Entretanto, a criação de um driver é um processo que requer um profundo conhecimento da API do middleware de provisão de contexto e necessita da recompilação do OpenCOPI, pois o driver é um componente de software embutido. Além disso, não existe um padrão ou metodologia bem definida para sua criação. Ademais, as transformações implementadas em um driver para adequação dos elementos de contexto entre middleware-OpenCOPI, normalmente não podem ser reaproveitadas para criação de outros drivers.
Neste estudo de caso usamos a ferramenta AutoWebS para a modelagem e gera- ção automática de serviços Web semânticos para os serviços de sistemas de middleware de provisão de contexto não baseados em serviços Web e/ou que não utilizam ontologias para representação dos elementos de contexto. Desta forma, conforme ilustrado na Figura 5.1, os serviços Web semânticos gerados para os serviços fornecidos por cada middleware de contexto substituem os drivers e toda complexidade envolvida na sua construção.
5.2 Ontologia de Domínio
O estudo de caso utiliza uma ontologia, chamada de OilExploration, que des- creve os conceitos do domínio da indústria de Petróleo. Esses conceitos, ilustrados na Figura 5.2, são usados como inputs e outputs para os vários serviços que possam estar relacionados a este domínio. Todos os conceitos desta ontologia foram especificados em um arquivo OWL.
5.2 Ontologia de Domínio 70
Figura 5.2: Ontologia de domínio OilExploration
Na Figura 5.2, as elipses mais escuras representam tarefas (tasks). Para cada uma das tarefas deve existir, pelo menos, um serviço Web correspondente. A Figura 5.3 ilustra um trecho da ontologia OilExploration que define o conceito PumpUnit que representa uma unidade de bombeio mecânico (UB) e foi definido como uma classe OWL. A classe PumpUnit possui como superclasse Equipment e tem três propriedades: minBurdenValue e maxBurdenValue, propriedades DatatypeProperty, definidas como tipo String do Schema XML; e actualRegime, uma propriedade ObjecProperty, uma referência à classe Regime que indica o regime atual de opera- ção da UB. Maiores detalhes da ontologia OilExploration podem ser encontrado no site http://www.ppgsc.ufrn.br/∼fred/opencopi/case_studies.html.
Na ontologia de domínio, a tarefa subscribe, existe um serviço chamado WellDatabase. Este serviço provê informações sobre os poços de petróleo e, assincro- namente, fornece o valor atual da carga de petróleo (burden) em cada UB. O serviço WellDatabaseabstrai um widget do framework Context Toolkit (CT) [Dey et al., 2001]. O frameworkCT é um middleware de provisão de contexto que utiliza um modelo de comu- nicação não baseado nas tecnologias dos serviços Web, porém baseado em um protocolo XML transportado por HTTP. Esse widget monitora o funcionamento da UB e representa os elementos de contexto no formato chave-valor.
Desta forma, para o serviço WellDataBase, faz-se necessário a conversão do modelo de contexto de chave-valor para ontologia e do modelo de comunicação HTTP para serviços Web. A próxima seção apresenta como procedemos a modelagem e geração do serviço Web semântico para o serviço WellDataBase.
5.3 Modelagem do Serviço Web Semântico 71
Figura 5.3:Trecho da ontologia de domínio OilExploration
5.3
Modelagem do Serviço Web Semântico
Para criar o serviço Web semântico para o serviço WellDatabase usamos a ferramenta AutoWebS e realizamos cinco atividades, conforme demonstra a Figura 5.4.
Figura 5.4: Atividades realizadas para o estudo e caso
1. Importação da ontologia de domínio; 2. Modelagem da interface do serviço Web;
3. Acionamento do mecanismo de geração automática do arquivo OWL-S e esqueleto de código fonte do serviço Web;
4. Implementação da regra de negócio do serviço Web; 5. Deploy do serviço Web.
A primeira atividade consiste em selecionar o arquivo OWL que contém a ontologia de domínio e repassá-la para o AutoWebS. Desta forma, a ferramenta cria um modelo UML (diagrama de classes) representando alguns elementos desta ontologia. Conforme ilustrado na Figura 5.5, o AutoWebS cria uma representação dos conceitos da ontologia especificados como classes OWL em classes UML.
5.3 Modelagem do Serviço Web Semântico 72
Figura 5.5: Trecho da ontologia de domínio OilExploration
Os elementos do modelo UML, criados a partir da ontologia de domínio, foram usados para especificação da interface do serviço Web, ou seja, para reali- zar a segunda atividade. Neste estudo de caso, criamos a interface WellDatabase e aplicamos o estereótipo «semanticWebService». Nesta interface definimos o método subscribeBurdenAssyncServicee aplicamos o estereótipo «SWSOperation». Este método recebe como parâmetros de entrada (input) os tipos OilWell e PumpUnit, ambos classes do modelo UML estereotipados por «owl:Class». O retorno do método (output) é uma classe do tipo Regime, que também foi importada da ontologia de domínio.
Na terceira atividade, após modelado a interface do serviço Web, acionamos na ferramenta AutoWebS o mecanismo de geração automática do arquivo OWL-S e esque- leto de código fonte do serviço Web. A Figura 5.6 ilustra os artefatos de código gerados automaticamente pela ferramenta. O arquivo WellDatabase.wsdl contém o documento WSDL do serviço Web. O descritor de deploy, services.xml, contém a configuração de execução do serviço Web. A classe Java WellDatabaseMessageReceiverInOut.java é responsável pela comunicação fim-a-fim do serviço Web com os clientes, enquanto que as classes Java WellDatabaseSkeleton.java e WellDatabaseStub.java são, respec-
5.3 Modelagem do Serviço Web Semântico 73
tivamente, o skeleton e stub e implementam o protocolo SOAP utilizado para transmissão das mensagens entre servidor e cliente. O arquivo build.xml descreve o processo de construção (build) e as dependências do serviço Web. Todos os artefatos foram incluídos em um projeto Java para plataforma Eclipse.
Figura 5.6: Artefatos de códigos gerados
A quarta atividade consistiu da implementação das regras de negócio do serviço Web. Nesta atividade foram implementadas as chamadas à API do serviço WellDatabase, implementado com o framework CT. A Figura 5.7 ilustra o trecho de código da operação subscribeBurdenAssyncService do serviço Web. No método Java subscribeBurdenAssyncService são realizadas a conexão ao serviço WellDataBase im- plementado com CT, a subscrição ao serviço de notificação e o tratamento dos dados recebidos pelo serviço WellDataBase implementado com o CT. Conforme a Figura 5.7, os tratamentos dos dados são realizados pelo método getRegime. Neste método, o retorno que está no formato chave-valor, é convertido para um objeto Regime.
Após ter implementado as regras de negócio do serviço Web, usamos as funci- onalidades de compilação e deploy. O projeto Java Eclipse foi compilado utilizando o script build.xml do Apache Ant. O resultado da compilação é um arquivo com a ex- tensão aar que contém o código fonte do serviço Web e a implementação do protocolo SOAP, no lado servidor, fornecida pelo Axis2. O processo de deploy é bastante simples. No deploy, a ferramenta faz uma cópia do arquivo com a extensão aar para no contêiner Web que tenha instalado o Axis2 Runtime.
5.4 Resultados 74
Figura 5.7: Implementação da regra de negócio do serviço Web
5.4 Resultados
A ferramenta AutoWebS proporcionou a criação do serviço Web semântico para o serviço WellDataBase usando os conceitos definidos em uma ontologia OWL. Os conceitos definidos como classes na ontologia foram mapeados para classes em um modelo UML. Tais classes UML foram usadas para criar a interface do serviço Web semântico. Durante o processo de modelagem da interface do serviço Web semântico a ferramenta abstraiu a sintaxe da linguagem OWL e o uso da UML tornou mais claro e intuitivo a criação do serviço Web semântico.
Com a ferramenta AutoWebS foi possível criar os serviços Web semânticos que abstraem o modelo de comunicação usado pelo CT e também realizam a conversão da representação dos elementos de contexto de chave-valor para ontologia. O serviço Web semântico foi implantado em um contêiner Web e testado a partir de uma aplicação cliente desenvolvida com a API OWL-S.
Com o estudo de caso podemos demonstrar o uso da ferramenta e descobrir alguns erros/inconsistências que foram corrigidos. Os principais erros apresentados pela ferramenta estavam presentes nas transformações entre os modelos UML e OWL-S. Os erros foram corrigidos e os artefatos de código gerados pela ferramenta foram analisados sintaticamente com validadores disponíveis na Internet.
O estudo de caso em questão apresenta algumas limitações. Dentre as limitações do estudo de caso está o fato de não existirem expressões lógicas que especificam condições que determinam a funcionalidade do serviço Web como, por exemplo, as pré- condições (precondition) requisitadas pelo serviço e os efeitos (effects) esperados da execução do serviço. As condições precondition e effects são representadas no modelo UML como elementos Constraints.
5.4 Resultados 75
Após o estudo de caso constatou-se a necessidade de uma avaliação mais elaborada sobre a ferramenta. Desta forma, conduzimos um experimento controlado que avalia a ferramenta AutoWebS no processo de criação de um conjunto de serviços Web semânticos, confrontando-a com uma suíte de aplicativos que se propõe a realizar as mesmas atividades que o AutoWebS. O experimento controlado é apresentado no Capítulo 6.