UNIVERSIDADE FEDERAL DA BAHIA INSTITUTO DE MATEMÁTICA DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO

Transcrição

1 UNIVERSIDADE FEDERAL DA BAHIA INSTITUTO DE MATEMÁTICA DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO ALEXANDRO NASCIMENTO DA SILVA Composição Automática de Web Services: Avaliando os planejadores JSHOP2 e JESS Salvador 2007

2 ALEXANDRO NASCIMENTO DA SILVA Composição Automática de Web Services: Avaliando os planejadores JSHOP2 e JESS Monografia apresentada ao Curso de graduação em Ciência da Computação, Departamento de Ciência da Computação, Instituto de Matemática, Universidade Federal da Bahia, como requisito parcial para obtenção do grau de Bacharel em Ciência da Computação. Orientadora: Drª. Sc. Daniela Barreiro Claro Salvador 2007

3 ALEXANDRO NASCIMENTO DA SILVA Composição Automática de Web Services: Avaliando os planejadores JSHOP2 e JESS Objetivo: Avaliação dos planejadores JSHOP2 e JESS no ambiente de composição automática de serviços. UNIVERSIDADE FEDERAL DA BAHIA Bacharelado em Ciência da Computação Data de Aprovação: de Orientadora: Drª. Sc. Daniela Barreiro Claro, LaSiD/UFBA Salvador 2007

4 Dedico este trabalho a toda minha família, aos meus amigos e em especial meu filho Caio

5 AGRADECIMENTOS Primeiramente a DEUS, que me concedeu paciência e sabedoria para concluir esta etapa da minha vida. Aos meus pais que me proporcionaram a vida, a educação e o equilíbrio para batalhar por meus objetivos. A minha esposa que me apóia em todos os nossos projetos e preenche minha vida de amor e otimismo. Aos meus amigos da faculdade, de infância, do trabalho e todos os outros, que fazem parte de minha vida tornado-a mais alegre e solidaria. Aos meus professores que me enriqueceram de conhecimentos e ensinou a importância da dedicação para ser diferente. A minha orientadora Prof.ª Daniela Barreiro Claro, por ter me apoiado e dado à direção necessária para a conclusão desse trabalho. Ao meu filho que chegou e me deixou mais amadurecido para o mundo, me proporcionou alegrias indescritíveis, deixando claro que o amor transforma tudo em nossas vidas.

6 RESUMO A disponibilidade de serviços na Web através de Web Services tem trazido muitos benefícios para a integração de sistemas heterogêneos e distribuídos. Porém, muitas vezes um único serviço não atende a uma requisição de um cliente. Neste caso, faz-se necessária a composição de serviços, criando assim um novo serviço com o objetivo de atender a um novo tipo de requisição. A depender da quantidade de serviços envolvidos na composição e das restrições analisadas, esse trabalho pode ser muito dispendioso e falho devido às incertezas inerentes ao ambiente Web, como a disponibilidade dos serviços, mudanças das interfaces de comunicação e a concorrência de recursos. Assim, a composição automática de serviços Web determina quais serviços participam em uma composição a fim de atender a um objetivo pré-definido por um cliente. Planejadores da área de Inteligência Artificial têm sido utilizados com o intuito de automatizar o processo de composição de serviços. Assim, o presente trabalho visa analisar as características de dois planejadores da IA (JSHOP2 e JESS) na composição automática de serviços Web. Palavras-chave: serviços Web, composição de serviços Web, planejador, JESS, JSHOP2 Key-words: Web services, web service compositions, AI planning, JESS, JSHOP2

7 LISTA DE FIGURAS Figura 1 - Estrutura de uma mensagem SOAP... 6 Figura 2 Exemplo de uma mensagem SOAP para um serviço de meteorologia... 6 Figura 3 Uma requisição SOAP sobre HTTP... 7 Figura 4 Uma resposta SOAP sobre HTTP... 7 Figura 5 Elementos de um documento WSDL Figura 6 Exemplo de interface para o método getweather... 9 Figura 7 Exemplo de binding para o método getweather... 9 Figura 8 Exemplo de um processo WS-BPEL para e-commerce Figura 9 Nível topo da ontologia Service Figura 10 Exemplo de definição da classe Service Figura 11 Exemplo de definição da classe ServiceProfile Figura 12 Classes e propriedade do ServiceModel Figura 13 Exemplo de definição da classe ServiceModel Figura 14 Exemplo de definição da classe ServiceGrounding Figura 15 Mapeamento entre OWL-S e WSDL Figura 16 Estado inicial e final do mundo dos cubos Figura 17 Descrição do domínio do Mundo dos Cubos Figura 18 Solução para o mundo dos cubos... 24

8 Figura 19 Exemplo de regra em um sistema que utiliza motor de regras Figura 20 Solução para um simples problema de translado Figura 21 Exemplo do operador ride em JSHOP Figura 22 Exemplo dos métodos travel e travel-by-taxi Figura 23 Exemplo de uso de axioma em JSHOP Figura 24 Exemplo de definição do domínio Figura 25 Exemplo de definição do problema Figura 26 Estado inicial e final do mundo dos cubos Figura 27 Exemplo de deftemplate Figura 28 Semelhança da memória de trabalho do JESS e um banco relacional Figura 29 Representação do estado inicial e final em JESS Figura 30 Exemplos de defrule Figura 31 Tipo Nome dos parâmetros de entrada e saída Figura 32 Descrição em OWL-S do BookFinderProcess Figura 33 Descrição em OWL-S do BNPriceProcess Figura 34 Descrição em OWL-S do CurrencyConverterProcess Figura 35 Hierarquia de tipos de classes de entrada e saída Figura 36 Estado inicial do problema Figura 37 Definição do domínio em JSHOP Figura 38 Definição do problema em JSHOP Figura 39 Seqüência de comandos para iniciar o JSHOP2 para um domínio especifico. 50 Figura 40 Tela que mostra caminho percorrido pelo JSHOP2 para encontrar um plano. 50

9 Figura 41 Tela de exibição do plano encontrado Figura 42 Exemplo de estrutura Sequence em JSHOP Figura 43 Processo composto para o cenário de BookPriceProcess Figura 44 Exemplo de chamada externa Figura 45 Exemplo de precondições OWL-S em linguagem nativa Figura 46 Exemplo de uso do operador forall Figura 47 Solução em JESS para o cenário Parte I Figura 48 Solução em JESS para o cenário Parte II-IV Figura 49 Resultado do JESS para o problema descrito no cenário Figura 50 É possível usar JESS a partir o Java e vice-versa Figura 51 Exemplos de JESS integrado com o Java Figura 52 Exemplos de Java integrado com o JESS Figura 53 Código em JESS para pesquisa de ontologias (books.jess) Figura 54 Código Java que executa o OWLJessKB Figura 55 Resultado da pesquisa pelo OWLJessKB Figura 56 Trecho de código da implemetação de uma interface Userfunction Figura 57 Exemplo de quantificador universal... 63

10 SUMÁRIO 1. INTRODUÇÃO COMPOSIÇÃO DE SERVIÇOS Web Services Tecnologias Básicas SOAP WSDL Tipos de Composição de Serviços Linguagens de composição de Serviços Web WS-BPEL OWL-S ServiceProfile ServiceModel ServiceGrounding Ciclo de vida de uma composição de serviços Web PLANEJAMENTO DA IA Planejamento Clássico Mundo dos Cubos Planejamento HTN... 24

11 3.3. Algoritmo Rete Outros tipos de planejadores PLANEJADORES PARA WSC Características específicas para WSC O Planejador JSHOP O Planejador JESS Outros planejadores para WSC COMPARATIVO ENTRE JSHOP2 E JESS APLICADOS A WSC Critérios de Comparação CENÁRIO JSHOP JESS CONCLUSÃO BIBLIOGRAFIA APÊNDICE A Mundo dos Cubos em JESS ANEXOS Mundo dos Cubos em JSHOP

12 1 1. INTRODUÇÃO Um Web service é um objeto distribuído cujo objetivo é garantir a interoperabilidade entre aplicações utilizando protocolos padronizados e se comunicando através de mensagens XML sobre a Internet. A Web Service Description Language (WSDL) é uma linguagem de definição de interface baseada em XML que permite a separação entre a descrição abstrata e a concreta da implementação do serviço. A padronização e a fácil manipulação contribuíram para a proliferação dos Web services na rede. Porém, muitas vezes não é possível encontrar um único serviço que atenda a um requisito especificado por um cliente. Neste contexto, Web services devem ser combinados com o intuito de atingir a demanda do cliente. A esta combinação de serviços Web dá-se o nome de composição de serviços Web (Web service composition). Diversas infraestruturas, dentre elas linguagens de composição, surgiram a fim de facilitar a manipulação destes serviços, tais como, OWL-S, SAWSDL e WS-BPEL. A composição de serviços Web pode ser feita atualmente através da Internet utilizando diversos serviços disponíveis e combinando-os. A depender da quantidade de serviços envolvidos, este processo pode ser complexo e demorado. Neste caso, a utilização de mecanismos que possam automatizar este processo de composição vem sendo amplamente estudados. A composição automática de serviços Web, a partir de um objetivo especificado e um conjunto de serviços, não é um problema com uma solução trivial. Além disso, ainda não está claramente definida quais técnicas são melhores aplicadas para resolvê-lo. Uma família de técnicas oriundas da IA tem sido proposta para resolver este tipo de problema, dentre elas o planejamento. Planejamento é um problema complexo que tem sido investigado extensivamente pela IA e é definido como uma espécie de problema onde um agente usa suas crenças sobre as ações disponíveis e suas conseqüências para identificar uma solução sobre um conjunto abstrato de planos [RUSSELL, 2004].

13 2 Neste contexto, este trabalho pretende descrever as principais características de um planejador e analisar o comportamento de dois planejadores (JSHOP2 e JESS) aplicados à composição automática de serviços Web. Os próximos capítulos são organizados da seguinte maneira: O Capítulo 2 apresenta os conceitos básicos necessários para a composição de serviços. O Capítulo 3 introduz conceitos de planejamento da IA, quais as técnicas utilizadas e como são utilizadas. O Capítulo 4 integra o ambiente de composição de serviços com a área de planejamento, analisando suas características. O Capítulo 5 descreve um estudo dos planejadores JSHOP2 e JESS aplicados a composição de serviços Web. Por fim, seguem as conclusões e ponderações sobre esta nova área da ciência da computação.

14 3 2. COMPOSIÇÃO DE SERVIÇOS A ciência da computação está em uma importante fase de abstração. Há um tempo atrás, observou-se a abstração do hardware, hoje se observa o crescimento da abstração do software. Esta nova fase está sendo atingida através de arquiteturas orientadas a serviços (SOAs) 1, que permite reutilizar e combinar arbitrariamente componentes de softwares para servir às necessidades através de interfaces padronizadas [FENSEL, 2007]. Web Services é especialmente uma nova tecnologia que tem como objetivo fazer componentes de software e aplicações comerciais disponíveis via interfaces padronizadas, tornando simples o desenvolvimento de aplicações distribuídas e a integração com sistemas existentes [FENSEL, 2007] Web Services Esforços na tentativa de desenvolver um padrão comum de desenvolvimento de aplicações distribuídas têm uma longa historia na ciência da computação. A maioria das propostas falharam completamente ou tiveram seu uso restrito a determinado uso ou adotado por algumas corporações. Na década de 80, Birell e Nelson apresentaram o Remote Procedure Calls (RPC), a primeira tecnologia utilizada para invocar métodos em sistemas distribuídos. A definição do RPC esconde detalhes de implementação dos desenvolvedores e utiliza uma linguagem padrão para descrição de interface (entrada/saída). O RPC oferece um mecanismo independente de plataforma e linguagem de programação para inserir chamada a métodos distribuídos em aplicações [BIRELL, 1984]. Arquiteturas, como a CORBA (Common Object Request Broker Architecture) apresentada por Object Management Group (OMG) na década de 90, já permitiam características avançadas como a seleção e execução dinâmica de serviços. Mas, não alcançaram o nível esperado de aceitação por não ter uma implementação simples [FENSEL, 2007]. 1 Do inglês Service-Oriented Arquiteture

15 4 As tecnologias que hoje em dia estão incluídas no termo Web Services têm várias vantagens comparadas com seus predecessores. Estas vantagens são as razões para a aceitação dos Web Services e a garantia da alta probabilidade de utilização por um longo período [FENSEL, 2007]: A comunicação entre Web Services depende de protocolos que já são amplamente aceitos, como os protocolos HTTP, SMTP e FTP. Com isso, tem a vantagem de permitir a reutilização das existentes infra-estruturas e experiências de seus usuários. Utiliza um protocolo para troca de mensagens entre Web Services, como o Simple Object Access Protocol (SOAP), que funciona sobre HTTP e utiliza o XML como formato de mensagem. Isso resolve um problema existente em outras soluções como RMI e CORBA, onde firewalls normalmente bloqueiam estes tipos de pacotes devido ao uso de protocolos proprietários. Similar ao RPC e CORBA, existe uma linguagem padrão para descrição da interface, a Web Service Description Language (WSDL). A WSDL permite a distinção entre a descrição das funcionalidades que o Web Service provê e os detalhes de como acessar o serviço. De um lado, métodos com seus parâmetros de entrada e saída, e por outro, o endereço onde o serviço está disponível e os protocolos de transporte suportados podem ser descritos independentemente. Uma estrutura modular onde cada módulo utiliza padrões e é responsável por certos subproblemas. Basicamente, Web Services permite acesso a funcionalidades utilizando um conjunto de padrões abertos que fazem a interação com aplicações heterogêneas e distribuídas de forma independente de aspectos de implementação como sistema operacional e linguagem de programação utilizada Tecnologias Básicas Esta seção aborda as tecnologias básicas atualmente aplicadas aos Web Services: SOAP e WSDL.

16 SOAP O principal objetivo do Simple Object Access Protocol (SOAP) em sua primeira versão, publicada como uma nota W3C em Maio/2000 [W3C, 2007], foi prover um framework 2 para comunicação de mensagens ponto a ponto em formato XML. Em Junho/2003, SOAP 1.2 tornou-se uma Recomendação W3C e tem ganhado forças desde então, sendo adotado na maioria das aplicações baseadas em Web Services. Serviços de mensagens comunicando sobre HTTP podem ser codificados diretamente em requisições HTTP Get ou Post, mas SOAP adicionou um rígido framework especialmente projetado para a troca de mensagens em formato XML. De fato, hoje em dia o termo Web Services é freqüentemente usado de forma sinônima com Web Services de comunicação sobre SOAP [FENSEL, 2007]. Uma mensagem SOAP é um documento XML contendo os seguintes elementos [W3SCHOOLS, 2007]: Um elemento obrigatório Envelope que identifica um documento XML como uma mensagem SOAP; Um elemento opcional Header que contém informações com instruções para processamento da mensagem; Um elemento obrigatório Body que contém as informações principais das requisições e respostas aos métodos; E um elemento opcional Fault que prover informações sobre erros ocorridos durante o processamento da mensagem. A Figura 1 mostra a estrutura de uma mensagem SOAP. A Figura 2 mostra um exemplo de um documento SOAP que é usado para invocar um serviço de meteorologia contendo dois textos indicando a cidade, descrita por seu nome e país. 2 Framework é uma estrutura de suporte definida em que um outro projeto de software pode ser organizado e desenvolvido [WIKIPEDIA, 2007].

17 6 <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:header> [...] </soap:header> <soap:body> [...] <soap:fault> [...] </soap:fault> </soap:body> </soap:envelope> Figura 1 - Estrutura de uma mensagem SOAP [W3SCHOOLS, 2007] <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:body> <GetWeather xmlns= > <CityName>Salvador</CityName> <CountryName>Brasil</CountryName> </GetWeather> </soap:body> </soap:envelope> Figura 2 Exemplo de uma mensagem SOAP para um serviço de meteorologia [FENSEL, 2007] Na prática, mensagens SOAP podem ser enviadas utilizando uma variedade de protocolos, embora no contexto Web seja usual a utilização sobre HTTP. Existem outros protocolos frequentemente usados e bem definidos, por exemplo SMTP 3. Quando uma mensagem SOAP é enviada sobre HTTP, basicamente um cabeçalho HTTP é adicionado à mensagem. Desta maneira, SOAP pode alcançar uma estrutura que já está pronta para interpretar o protocolo e desta forma eliminar os problemas com firewalls e routers que ocorrem quando usamos RPC [FENSEL, 2007]. A Figura 3 e a Figura 4 mostram um exemplo de envio de mensagens SOAP sobre HTTP. Somente o cabeçalho é dependente do atual protocolo de transporte utilizado, a mensagem SOAP transferida não necessita de mudanças para diferentes protocolos. O cabeçalho contém elementos padrões para um cabeçalho HTTP, como POST, Content-Type e Content-Length. 3

18 7 POST /InStock HTTP/1.1 Host: Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:body xmlns:m=" <m:getstockprice> <m:stockname>ibm</m:stockname> </m:getstockprice> </soap:body> </soap:envelope> Figura 3 Uma requisição SOAP sobre HTTP [W3SCHOOLS, 2007] HTTP/ OK Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:body xmlns:m=" <m:getstockpriceresponse> <m:price>34.5</m:price> </m:getstockpriceresponse> </soap:body> </soap:envelope> Figura 4 Uma resposta SOAP sobre HTTP [W3SCHOOLS, 2007] Em resumo, SOAP é um formato XML para troca de mensagens que pode ser combinado com diferentes protocolos de transporte para permitir o envio de mensagens XML, tornado-se uma ferramenta popular para o transporte de mensagens XML na Web WSDL O Web Services Description Language (WSDL) é uma linguagem baseada em XML utilizada para descrever Web Services. Trata-se de um documento que além de descrever o serviço, especifica como acessá-lo, quais as operações ou métodos disponíveis e suas mensagens de entrada e saída [WIKIPEDIA, 2007]. A Figura 5 mostra a definição de uma estrutura WSDL: O elemento types descreve os tipos de mensagens que o serviço irá enviar e receber;

19 8 O elemento interface descreve quais funcionalidades o Web Service provê; O elemento binding descreve como acessar o serviço; O elemento service descreve onde acessar o serviço. Figura 5 Elementos de um documento WSDL 2.0 [MARTIN, 2007] A Figura 6 mostra como as entradas e saídas são definidas em um documento WSDL e como eles podem ser associados a um método. A definição relevante no exemplo é o elemento para definir GetWeather. Ele indica que existe um elemento filho CityName e CountryName do tipo string. Mais abaixo no exemplo pode ser visto a definição da interface para o método GetWeather. O exemplo na Figura 7 mapeia a definição abstrata para o protocolo real. O elemento binding define o SOAP sobre HTTP como o protocolo padrão de comunicação. Finalmente o elemento service declara o ponto de acesso do serviço.

20 9 [...] <types> <xs:schema xmlns:xs=" targetnamespace=" xmlns=" <xs:element name="weather" type="tweather"/> <xs:complextype name="tweather"> <xs:sequence> <xs:element name="cityname" type="s:string" /> <xs:element name="countryname" type="s:string" /> </xs:sequence> </xs:complextype> <xs:element name="weatherresponse" type="xs:double"/> <xs:element name="invaliddataerror" type="xs:string"/> </xs:schema> </types> <interface name="weatherinterface"> <fault name="invaliddatafault" element="ghns:invaliddataerror"/> <operation name="getweather" pattern=" style=" wsdlx:safe="true"> <input messagelabel="in" element="ghns:weather" /> <output messagelabel="out" element="ghns:weatherresponse" /> <outfault ref="tns:invaliddatafault" messagelabel="out"/> </operation> </interface> [...] Figura 6 Exemplo de interface para o método getweather [FENSEL, 2007] [...] <binding name="weathersoapbinding" interface="tns:weatherinterface" type=" wsoap:protocol=" <fault ref="tns:invaliddatafault" wsoap:code="soap:sender"/> <operation ref="tns:getweather" wsoap:mep=" </binding> <service name="weatherservice" interface="tns:weatherinterface"> <endpoint name="weatherendpoint" binding="tns:weathersoapbinding" address=" </service> [...] Figura 7 Exemplo de binding para o método getweather [FENSEL, 2007] Com este exemplo, ilustram-se as características do WSDL: (1) esquemas XML podem ser reutilizados em declarações de tipo; (2) interfaces são definidas independentemente do protocolo de transporte; (3) uma interface pode ser facilmente reutilizada por vários outros bindings.

21 Tipos de Composição de Serviços Para ilustrar as possíveis formas de compor serviços Web, um exemplo do domínio de manipulação de arquivos, citado por [MURTAGH, 2004], será utilizado. Suponha que uma pessoal deseja converter um documento.doc para um documento.pdf. Assuma que não exista um serviço capaz de desempenhar esta conversão diretamente, mas existe um serviço que converte documentos.doc para um formato intermediário.rtf e outro serviço que converte desse formato intermediário para um documento.pdf. Existem duas maneiras de compor esses dois serviços, associando suas interfaces, de forma seqüencial e correta para alcançar o objetivo de converter um documento.doc em.pdf: manual ou automático [CLARO, 2007]. Para esse exemplo, na composição manual o usuário deve buscar por serviços que convertam um documento.doc para formatos intermediários e para cada formato intermediário pesquisar um serviço que converta o formato intermediário para um documento.pdf. É obvio que este processo é muito dispendioso e que para um número grande de serviços é impraticável. A situação pode ser agravada ainda mais se, para obter a conversão de.doc para.pdf, várias conversões intermediarias sejam necessárias. Algumas linguagens surgiram no contexto da composição manual, como a WS-BPEL discutida mais adiante. Na composição automática o usuário apenas especifica um objetivo e então, o sistema automaticamente inicia o processo de busca e seleção de serviços e os integram de forma que o objetivo seja atingido, criando assim, um novo serviço, que no exemplo acima converteria um documento.doc em.pdf. Composição automática de serviços tem outras vantagens em relação à composição manual [MURTAGH, 2004]: Serviços selecionados podem ser substituídos no decorrer do tempo para incluir outros serviços que fariam o objetivo ser atingido mais rapidamente, com menor custo ou outras características não-funcionais; Ajustar a composição para encontrar serviços que melhor atenda as necessidades do usuário (ex. preferência no modo de pagamento);

22 11 Substituir serviços que estejam inacessíveis, criando um plano tolerante a falhas. Contudo, para tornar o processo de composição automática possível, deve existir uma linguagem que possa ser interpretada, entendida de forma não ambígua, por uma máquina ou software [BERNERS-LEE, 2001]. Por exemplo, para uma pessoa que ler a assinatura de um método public File converterdocparapdf(file doc), sabe que este método converte um documento.doc em.pdf, mas para uma máquina esta interpretação não é tão fácil Linguagens de composição de Serviços Web Esforços para tornar o processo de composição de Web Services possível, fizeram surgir algumas linguagens com este propósito. A seguir é explanado duas dessas principais linguagens WS-BPEL A maioria das linguagens de composição segue o paradigma workflow, no qual a composição é definida como um processo de negócio que determina manualmente quais Web Services participam da composição, quais dados são transferidos entre as atividades do processo e como acontecem as interações (fluxos de controle). A orquestração e a coreografia de Web Services são abordagens baseadas em padrões abertos para conectar os serviços e criar processos de negócios de alto nível. A orquestração apresenta um processo de negócio executável, que pode interagir com serviços internos e externos à organização, que descreve como os Web Services podem interagir em nível de mensagem e que inclui a lógica de negócio e a ordem de execução das tarefas (atividades). Com a orquestração, o processo é sempre controlado por uma das partes do negócio, o que difere da coreografia que é mais colaborativa e que permite que cada parte envolvida descreva sua participação na interação [PELTZ, 2003]. A WS-BPEL (Web Services Business Process Execution Language), padronizada pela OASIS [OASIS, 2007], é a linguagem mais popular para orquestração de Web Services. Diversas companhias de software, tais como Oracle, SAP, IBM, HP, entre outras,

23 12 comprovaram a aceitação deste padrão quando integraram motores de orquestração de workflows dentro de seus produtos. A Figura 8 mostra um exemplo de um processo WS- BPEL para venda e entrega de pedidos de um site de e-commerce. Figura 8 Exemplo de um processo WS-BPEL para e-commerce [TYPEPAD, 2007] OWL-S Embora um documento WSDL descreva a interface, protocolo de transporte e ponto de acesso de um Web Service, ele não provê nenhuma informação interpretável por máquinas sobre o objetivo do serviço, o quê ele faz. Por exemplo, assuma que um Web Service disponibiliza dois métodos, um que aceita como parâmetro um número x, e retorna e x, e outro que aceita um número de cartão de crédito x e retorna e x, uma quantidade em Real debitada de sua conta. Por consultar um documento WSDL, uma analise rápida por uma pessoa pode corretamente decidir qual o propósito de cada método, analisando os nomes dos métodos ou mensagens de entrada e saída. Mas, uma máquina não é capaz de

24 13 distinguir entre eles, por que ambos têm o mesmo número de mensagens de entrada e saída como os mesmos tipos de dados [MURTAGH, 2004]. É obvio que para atingir o propósito de compor Web Services automaticamente, uma linguagem deve possibilitar que máquinas distingam entre esses dois métodos. De maneira geral, para que isso aconteça serviços devem ser descritos em uma forma que não seja ambígua e que máquinas possam entender o que um serviço se propõe a fazer, a linguagem deve descrever [MURTAGH, 2004]: Propriedades e habilidades para busca e seleção automática; Precondições, efeitos, mensagens de entrada e mensagens de saída para composição automática; Interfaces, pontos de acesso e protocolos para execução automática. A Web Semântica apareceu para tentar resolver esses problemas. A Web Semântica permite que dados e serviços sejam interpretados por software, sem o problema de ambigüidade [BERNERS-LEE, 2001]. Uma das atuais linguagens que possibilita descrever semanticamente Web Services é a o Ontology Web Language for Service (OWL-S). Sua origem tem como base a Web Ontology Language (OWL), que é uma linguagem baseada em XML usada para descrever ontologias. OWL-S é uma ontologia que fornece classes e propriedades em OWL, adequados para a descrição de Web Services [OWL-S, 2007]. Uma ontologia OWL consiste em um conjunto de classes, instancias e propriedades que descrevem o conceito dentro de um domínio particular. Embora classes, instâncias e propriedades em OWL possuam características herdadas da Orientação a Objeto (OO), OWL prover uma rica opção de construtores para especificar relacionamentos entre classes, propriedades e indivíduos [MURTAGH, 2004]. A Figura 9 mostra as classes que compõe o OWL-S. A classe Service age como um ponto de referência organizacional para descrições OWL-S. Cada descrição de um Web Service terá uma simples instância de Service, com apropriados valores para presents, describedby e supports. As respectivas extensões dessas propriedades são ServiceProfile, ServiceModel e ServiceGrounding, cada uma detalha diferentes tipos de conhecimentos sobre o serviço sendo descrito. Uma introdução em cada uma dessas extensões é exposta a seguir.

25 14 Figura 9 Nível topo da ontologia Service [MARTIN, 2007] [...] <!-- Service description --> <service:service rdf:id="currencyconverterservice"> <service:presents rdf:resource="#currencyconverterprofile"/> <service:describedby rdf:resource="#currencyconverterprocess"/> <service:supports rdf:resource="#currencyconvertergrounding"/> </service:service> [...] Figura 10 Exemplo de definição da classe Service [MINDSWAP, 2007] ServiceProfile O serviço apresenta um ServiceProfile, que tem uma subclasse Profile. O Profile contem um vocabulário para caracterizar propriedades funcionais (ex. inputs 4, output 5, precondições e efeito) e não-funcionais (ex. informação para contato, categoria do serviço). O Profile anuncia as habilidades do serviço e torna mais fácil o processo de descoberta automática [MARTIN, 2007]. 4 A palavra input daqui em diante será sinônimo para mensagem de entrada. 5 A palavra output daqui em diante será sinônimo para mensagem de saída.

26 15 [...] <!-- Profile description --> <mind:currencyservice rdf:id="currencyconverterprofile"> <service:ispresentedby rdf:resource="#currencyconverterservice"/> <profile:servicename xml:lang="en">price Converter</profile:serviceName> <profile:textdescription xml:lang="en"> Converts the given price to another currency. </profile:textdescription> <profile:hasinput rdf:resource="#inputprice"/> <profile:hasinput rdf:resource="#outputcurrency"/> <profile:hasoutput rdf:resource="#outputprice"/> </mind:currencyservice> [...] Figura 11 Exemplo de definição da classe ServiceProfile [MINDSWAP, 2007] ServiceModel O serviço é descrito por um ServiceModel, que tem uma subclasse Process. A Figura 12 mostra a classe Process, suas subclasses e propriedades. Figura 12 Classes e propriedade do ServiceModel [MARTIN, 2007]