SONUÇ VE ÖNERİLER:

No metamodelo OWL-S são definidos todos os elementos e relacionamentos que podem ser encontrados nos modelos OWL-S. Na abordagem MDD implementada pela ferramenta AutoWebS, um modelo UML, que representa a interface de um serviço Web semântico, é a entrada para um mecanismo que produz um modelo de saída em conformidade com o metamodelo OWL-S.

A Figura 4.7 ilustra um trecho da transformação em QVT que implementa o ma- peamento entre os modelos UML e OWL-S. Esta transformação, chamada de UMLPro- file2OWLS, recebe como entra um modelo da UML 2 na versão 3.0.0 e cria um modelo OWL-S de acordo com o metamodelo OWL-S. No método main (linha 9), a instrução inUML.objectsOfType(UML::Interface)(linha 11) recupera uma lista de todos os elemen- tos UML Interface do modelo de entrada. O operador QVT forEach (linha 11) faz uma iteração sobre estes elementos e o operador QVT if (linha 12) faz uma seleção sobre os elementos que tem o estereótipo SemanticWebService. A instrução seguinte, na linha 13, recupera todos os elementos UML Operation - as operações do serviço Web - definidos no elemento Interface. Ainda na mesma linha, com o operador forEach, é realizado uma iteração sobre os elementos Operation na busca por aqueles com o estereótipo textitSW- SOperation. Para cada operação do serviço Web, um modelo OWL-S é criado. A instrução map(linha 16) faz uma chamada ao mapeamento createOWLS. No mapeamento create- OWLSsão construídos os elementos do modelo OWL-S. O Apêndice D traz na íntegra a implementação da transformação em QVT.

O elemento Profile do modelo OWL-S é criado a partir do valor do tagged- value WSDL Documentation, aplicado ao elemento UML Interface e dos tagged-values do estereótipo Category. O id do elemento Profile é formado pela concatenação do nome da operação com a palavra Profile. Desta forma, uma operação com nome subscribe, formará o id subscribeProfile para o elemento Profile.

4.7 Implementação das Regras de Mapeamento entre UML e OWL-S 64

Figura 4.7: Transformação de UML para OWL-S

criados de forma semelhante ao elemento Profile e os valores das suas propriedades são especificados a medida em que o elemento WsdlAtomicProcessGrounding e os parâmetros WsdlInputMessagee WsdlOutputMessage são criados.

No elemento WsdlAtomicProcessGrounding do modelo OWL-S, o va- lor do seu id é formado pela concatenação do nome da operação com a palavra AtomicProcessGrounding. O valor do atributo wsdlDocument é o valor do tagged- value URI WSDL Document aplicado no elemento UML Interface. O valor do atributo wsdlInputMessage é formado pela concatenação do valor do tagged-value targetNamespace com a caractere #, com nome do serviço e com a palavra Request. O valor do atributo wsdlOutputMessage é formado pela concatenação do valor do tagged-value targetNamespace com o caractere #, com nome do serviço e com a pa- lavra Response. O atributo wsdlOperation recebe uma instância de WsdlOperationRef. No objeto WsdlOperationRef a propriedade portType é formada pela concatenação do tagged-value URI WSDL Document, com o caractere # e com o valor do tagged-value textitendPoint. A propriedade operation é formada pela concatenação do tagged-value URI WSDL Document, com o caractere # e com o nome do serviço.

No elemento OWL-S wsdlAtomicGrounding são especificados os inputs e outputs do serviço Web semântico através da associação do elemento Message Part do documento WSDL com um conceito definido como uma classe no documento OWL. Para os casos em que os inputs e outputs de uma operação do serviço Web não têm uma corres- pondência direta com os elementos da ontologia de domínio, são necessários representar como derivar a Message Part de um ou mais inputs ou outputs do Atomic Process.

A propriedade xsltTransformation contém um script XSLT que gera o Message Partde uma instância de um Atomic Process. O script pode ser diretamente representado como uma string ou pode ser referenciado por um URI. A transformação QVT, que faz o mapeamento entre o modelo UML e o modelo OWL-S, cria automaticamente o script

4.8 Funcionamento da Ferramenta 65

XSLT para os casos em que são usados elementos da ontologia de domínio importada como input ou output para especifi cação de uma operação do serviço Web semântico.

4.8

Funcionamento da Ferramenta

O funcionamento do AutoWebS, ilustrado na Figura 4.8, compreende basica- mente três principais atividades que devem realizadas sequencialmente, (i) importação da ontologia de domínio, (ii) criação do modelo UML e (iii) geração automática do serviço Web e sua ontologia. A primeira e a última atividade são automatizadas pela ferramenta. O usuário precisa realizar somente a segunda atividade, a modelagem da interface do serviço Web semântico.

Figura 4.8: Funcionamento do AutoWebS

A primeira atividade consiste na importação da ontologia de domínio (ver Seção 4.5) para a criação de um modelo UML. Na primeira atividade a ferramenta usa o componente ImporterModule para execução das transformações XSLT e criação do modelo UML. Este modelo UML contém os elementos da ontologia de domínio que podem ser usados para modelagem da interface de um serviço Web. A segunda atividade consiste na edição do modelo UML. Na segunda atividade, o usuário pode inserir ou remover elementos no modelo UML recém criado para modelagem da interface do serviço Web.

A terceira atividade ocorre após a modelagem da interface do serviço Web. Neste ponto, o AutoWebS exporta a representação gráfica do modelo UML para um

4.8 Funcionamento da Ferramenta 66

documento XMI. Então, no documento XMI é aplicado um conjunto de regras de transformações QVT para geração automática de um modelo OWL-S. Também, sobre o mesmo documento XMI, é aplicado um template Acceleo, chamado UML to Java, para criação do código fonte na linguagem Java dos elementos contidos no modelo UML que define a interface do serviço Web. Depois de criado o modelo OWL-S, outro template Acceleo é utilizado para criar o documento OWL-S. Após esta atividade de geração de artefatos, são produzidos o código fonte do serviço Web e o documento OWL-S correspondente.

Para geração do código fonte do serviço Web a descrição das operações do serviço Web, que são representadas através de métodos públicos em uma interface Java, é submetida ao componente WebServiceModule. Este componente, por intermédio do subcomponente Factory, faz chamadas à API do Engine do Axis2 para realizar as seguintes tarefas:

1. Criar o documento WSDL associado ao serviço Web;

2. Gerar o código fonte para implementação do serviço Web, isto é, os artefatos de código que compõem a infraestrutura do serviço Web;

3. Criar o script Ant build.xml para o projeto do serviço Web.

Os principais artefatos de código gerados são: i) o descritor de deploy services.xml, que contém a configuração de execução do serviço Web, ii) o MessageReceiver, que é responsável pelo comunicação fim-a-fim, iii) Skeletons e Stubs que implementam qual protocolo utilizado para transmissão das mensagens no lado servidor e cliente, iv) o arquivo build.xml, que descreve o processo de construção (build) e as dependências do projeto do serviço Web com APIs de terceiros. O arquivo build.xml é utilizado pelo Apache Ant [Loughran and Hatcher, 2007] para automatizar a construção do serviço Web a medida que automatiza o processo de build das classes e o empacotamento para o formato aar que é o formato usado para deploy em contêineres Web.

O componente WebServiceModule agrega o documento WSDL e os artefatos de código do serviço Web em um projeto para plataforma Eclipse para que o usuário possa programar as regras de negócio do serviço Web, ou seja, implementar as chamadas aos métodos de APIs, incluir bibliotecas de terceiros, etc. Após ter implementado as regras de negócio do serviço Web, o usuário pode usar as funcionalidades de compilação e deploy oferecidas pelos subcomponentes Deployer e Compiler. O subcomponente Compilercompila o projeto utilizando o script build.xml do Apache Ant. O resultado da compilação é um arquivo com a extensã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. Através de alguns parâmetros, que podem estar pré-definidos em um arquivo de configuração, o subcomponente Deployer pode fazer o deploy do serviço Web em um contêiner Web que tenha instalado o Axis2 Runtime.

CAPÍTULO

5