LABORATÓRIO DE SISTEMAS DISTRIBUÍDOS
ESPECIALIZAÇÃO AVANÇADA EM SISTEMAS DISTRIBUÍDOS
MARCUS VINÍCIUS ALMEIDA SILVA
TRANSPLAN: UMA SOLUÇÃO PARA MAPEAR E
PLANEJAR SERVIÇOS WEB SEMÂNTICOS
Salvador
2008
TRANSPLAN: UMA SOLUÇÃO PARA MAPEAR E
PLANEJAR SERVIÇOS WEB SEMÂNTICOS
Monografia apresentada ao Curso de Especialização Avançada em Sistemas Distribuídos do Laboratório de Sistemas Distribuídos, Universidade Federal da Bahia.
Orientadora: Drª. Sc. Daniela Barreiro Claro
Salvador
2008
TRANSPLAN: UMA SOLUÇÃO PARA MAPEAR E
PLANEJAR SERVIÇOS WEB SEMÂNTICOS
UNIVERSIDADE FEDERAL DA BAHIA
Monografia apresentada ao Curso de Especialização Avançada em Sistemas Distribuídos do Laboratório de Sistemas Distribuídos, Universidade Federal da Bahia
Aprovada em 13 de Outubro de 2008.
Banca Examinadora Marco Simões
Orientadora: Drª. Sc. Daniela Barreiro Claro, LaSiD/UFBA
Salvador
2008
A
Meus pais, Antoniel e Gilvanda, pelo seu amor e carinho, e a minha esposa, Vilmária Silva.
São tantos e tão especiais...
À Deus, em primeiro lugar, por me ter concedido vida e saúde. À minha esposa, Vilmária Silva pelo apoio incondicional. À meus pais, Antoniel e Gilvanda, pelo amor fraternal.
À meus irmãos e amigos, Lucas e Gabriel pela cumplicidade.
À Daniela Claro, minha orientadora, que me conduziu durante o processo, sempre tão atenciosa.
À Carlos, Monique e Fábio pela ajuda na revisão do trabalho.
À todos meus amigos e professores que de alguma forma contribuíram para elaboração deste trabalho.
Muito obrigado por possibilitarem essa experiência ímpar que contribuiu para o meu crescimento como ser humano e profissional
Os serviços web têm sido cada vez mais utilizados pelas organizações para prover funcionalidades aos seus parceiros. Em determinadas situações, apenas um serviço não é suficiente para atender uma requisição de um cliente. Neste caso, estes serviços devem ser combinados dando origem às composições de serviços. Por se tratar de um ambiente dinâmico, a composição manual pode envolver muitos serviços e se tornar muito onerosa. Para realizar essa atividade automaticamente é necessário que os serviços web sejam descritos em uma linguagem que máquinas consigam compreender, ou seja, de uma maneira não ambígua. Assim, a linguagem semântica utilizada para descrever os serviços e o planejador utilizado para compor estes serviços necessitam trocar mensagens para que o processo seja automático. Diante deste contexto, o objetivo deste trabalho é desenvolver uma solução para o mapeamento e planejamento dos serviços web semânticos descritos em OWL-S para o planejador JSHOP2. Foram avaliados dois cenários de testes, um deles presente dentro do framework SAREK. O Transplan obteve resultados satisfatórios no mapeamento destes serviços.
ABSTRACT
The web services have been increasingly used by organizations to provide functionality to their partners. In certain situations, only one service is not enough to answer a request from a client. In this case, they should be combined leading to the compositions of services. It is a dynamic environment, the composition may involve many manual services and become very costly. To automatically perform this activity is necessary that the web services are described in a language that machines can understand, ie, an unambiguous way. Thus, the language semantics used to describe the services and the planner used to compose these services need to exchange messages that the process is automatic. In this context, the objective of this work is to develop a solution to the mapping and planning of semantic web services described in OWL-S for the planner JSHOP2. We evaluated two scenarios for testing, this one within the framework SAREK. Transplan has satisfactory results obtained in these mapping services.
FIGURA 2 – ARQUITETURA DOS SERVIÇOS WEB. ... 15
FIGURA 3 – ESTRUTURA DO ENVELOPE ... 16
FIGURA 4 - ESTRUTURA DE UMA MENSAGEM SOAP. ... 16
FIGURA 5 - UMA REQUISIÇÃO SOAP SOBRE HTTP. ... 17
FIGURA 6 - UMA RESPOSTA SOAP SOBRE HTTP. ... 17
FIGURA 7 - ELEMENTOS DO WSDL. ... 18
FIGURA 8 – ESTRUTURA DE UM DOCUMENTO WSDL. ... 18
FIGURA 9 – SERVIÇO DE CONVERSÃO DE ARQUIVOS ... 20
FIGURA 10 - VISÃO DE ALTO NÍVEL DA ONTOLOGIA OWL-S ... 23
FIGURA 11 – EXEMPLO DE DEFINIÇÃO DA CLASSE SERVICE ... 23
FIGURA 12 – EXEMPLO DE DEFINIÇÃO DA CLASSE SERVICEPROFILE ... 24
FIGURA 13 – EXEMPLO DE DEFINIÇÃO DE UM PROCESSO ATÔMICO ... 25
FIGURA 14 – EXEMPLO DE DEFINIÇÃO DA ESTRUTURA CONDICIONAL ... 26
FIGURA 15 – EXEMPLO DE DEFINIÇÃO DA CLASSE SERVICEMODEL ... 26
FIGURA 16 – EXEMPLO DE DEFINIÇÃO DE UM PROCESSO COMPOSTO ... 27
FIGURA 17 – MAPEAMENTO DE SERVICEMODEL PARA WSDL ... 27
FIGURA 18 - MUNDO DOS CUBOS ... 34
FIGURA 19 - LISTAGEM DA AÇÃO MOVER EM STRIPS. ... 34
FIGURA 20 - DESCRIÇÃO DO DOMÍNIO DO MUNDO DOS CUBOS. ... 35
FIGURA 21 - MACRO-FLUXO DO JSHOP ... 39
FIGURA 22 – DOMÍNIO DE EXEMPLO PARA SWAP ... 40
FIGURA 23 – PROBLEMA DE EXEMPLO PARA SWAP ... 41
FIGURA 24 – PASSOS PARA EXECUÇÃO DO JSHOP2GUI ... 41
FIGURA 25 – AMBIENTE GRÁFICO DO JSHOP2 ... 42
FIGURA 26 – PLANO SWAP ... 42
FIGURA 27 – SOLUÇÃO DO CENÁRIO BOOKFINDER ... 43
FIGURA 28 – EXEMPLO DE USO DE AXIOMAS EM JSHOP2 ... 44
FIGURA 29 – EXEMPLO DE ESTRUTURA IF-THEN-ELSE ... 44
FIGURA 30 – EXEMPLO DO PROBLEMA PARA O DOMÍNIO BOOKFINDER ... 44
FIGURA 31 – SOLUÇÃO DO CENÁRIO BOOKFINDER ... 45
FIGURA 32 – INTERFACE GRÁFICA DO JSHOP2 ... 45
FIGURA 33 – RETORNO DO JSHOP2 ... 46
FIGURA 34 – NOVA ATIVIDADE ACRESCENTADA AO PLANO ... 46
FIGURA 35 – ALTERAÇÃO DO DOMÍNIO ... 47
FIGURA 36 – MACRO FLUXO DO TRANSPLAN ... 49
FIGURA 37 – ARQUITETURA DE ALTO NÍVEL DO TRANSPLAN. ... 51
FIGURA 38 – DIAGRAMA DE DEPENDÊNCIA DE MÓDULOS. ... 52
FIGURA 39 – DIAGRAMA DO PACOTE MODEL. ... 53
FIGURA 40 – DIAGRAMA DO PACOTE SERVICE. ... 54
FIGURA 41 – DIAGRAMA DE DEPENDÊNCIA DE MÓDULOS ... 55
FIGURA 42 - CONVERTER PROCESSOS ATÔMICOS PARA OPERADORES ... 56
FIGURA 43 – TELA PRINCIPAL DO TRANSPLAN ... 57
FIGURA 44 – CUSTOMIZANDO O TRANSPLAN ... 58
FIGURA 45 – ARQUIVO DE CONFIGURAÇÃO DO TRANSPLAN ... 58
FIGURA 46 – CENÁRIO PARA CRIAÇÃO DE ESCADAS ... 60
FIGURA 47 – SOLUÇÃO DO TRANPLAN PARA O CENÁRIO BOOKPRICE ... 61
LISTA DE TABELAS
TABELA 1 CLASSES DO PACOTE MODEL. ... 53
TABELA 2 CLASSES DO PACOTE JSHOP2. ... 55
TABELA 3 AVALIAÇÃO DO TRANSPLAN ... 61
SUMÁRIO
INTRODUÇÃO 10 1.1 TRABALHOS CORRELATOS 11 1.2 ORGANIZAÇÃO DO TRABALHO 12 2 SERVIÇOS WEB 13 2.1 TECNOLOGIAS BÁSICAS 152.1.1 SIMPLE OBJECT ACCESS PROTOCOL (SOAP) 15
2.1.2 WEB SERVICES DESCRIPTION LANGUAGE (WSDL) 18
2.2 COMPOSIÇÃO DE SERVIÇOS WEB 19
2.2.1 ONTOLOGY WEB LANGUAGE FOR SERVICES (OWL-S) 21
2.3 AUTOMATIZANDO A COMPOSIÇÃO 28
3 PLANEJADORES DA INTELIGÊNCIA ARTIFICIAL 29
3.1 CONCEITOS BÁSICOS 29 3.1.1 ESTADO 29 3.1.2 PRECONDIÇÃO 29 3.1.3 EFEITO 30 3.1.4 AÇÃO 30 3.1.5 PLANO 30 3.1.6 AMBIENTE 30 3.1.7 REPLANEJAMENTO 31 3.2 TIPOS DE PLANEJAMENTO 31
3.2.1 PLANEJAMENTO COM BUSCA NO ESPAÇO DE ESTADOS 32
3.2.2 PLANEJAMENTO DE ORDEM PARCIAL 35
3.2.3 PLANEJAMENTO DE REDE HIERÁRQUICA DE TAREFA 36
3.3 JSHOP2 38
3.3.1 EXEMPLOS DE UTILIZAÇÃO 39
4 MAPEANDO E PLANEJANDO COM O TRANSPLAN 49
4.1 ANÁLISE E PROJETO 50
4.1.1 PROJETO ARQUITETURAL DO TRANSPLAN 50
4.1.2 PROJETO ARQUITETURAL DE BAIXO NÍVEL 52
4.1.3 UTILIZAÇÃO DO TRANSPLAN 56
4.2 EXPERIMENTOS 58
4.2.1 CONCORRÊNCIA PÚBLICA 58
4.3 AVALIAÇÃO DOS RESULTADOS 61
CONCLUSÃO 65
REFERÊNCIAS 67
APÊNDICE A –BOOKFINDER EM JSHOP2 70
APÊNDICE B –BOOKFINDER EM JSHOP2 COM DOIS PLANOS 72
INTRODUÇÃO
Com a evolução da Internet, a web tem sido cada vez mais utilizada. Inicialmente as organizações utilizavam os documentos web para oferecer aos seus fornecedores e clientes um ambiente interativo de fácil acesso, por meio do qual fosse possível a execução de rotinas semi-automatizadas, por exemplo, solicitar um pedido. Entretanto, esse modelo é custoso, sendo necessário que sistemas possam interagir entre si sem a necessidade da intervenção humana. Para atender tal demanda desenvolveram-se tecnologias de sistemas distribuídos, dentre elas os serviços web, pelo qual uma aplicação cliente interage pela internet com um serviço que possui uma interface bem definida e padronizada (COLOURIS et. al., 2005).
Com o advento dos serviços web, muitas organizações passam a desenvolver seus próprios serviços e a publicá-los na web. Entretanto, um serviço isolado pode não atender a um objetivo de um cliente. Neste caso, observa-se a necessidade de encadear um conjunto de serviços já existentes. Este encadeamento pode ser realizado de maneira automática através do uso de planejadores da inteligência artificial.
Uma das linguagens utilizadas para agregar valor semântico aos serviços web é a OWL-S. De forma análoga, cada planejador possui uma linguagem própria para compreender o ambiente modelado. Sendo portanto necessário desenvolver uma mapeamento da linguagem OWL-S para a linguagem utilizada pelo planejador, nesse trabalho, JSHOP2.
Assim, o objetivo desse trabalho é propor uma solução para o mapeamento e planejamento dos serviços descritos em OWL-S para o planejador JSHOP2. Dessa
forma, as principais contribuições desse trabalho são: converter automaticamente a descrição semântica dos serviços para uma linguagem compreensível para o planejador JSHOP2; planejar a seqüência de execução dos serviços web exibindo todos os planos encontrados no espaço de estado.
Para elaboração desse trabalho foi necessário desenvolver um estudo na literatura específica para localizar o planejador da Inteligência Artificial que mais se ajustasse ao problema de composição de serviços. Embora existam diversos planejadores já implementados (CALHAU, 2006), o fato é que dadas as características especiais da composição de serviços ainda não existem tecnologias de composição aceitas em geral pela comunidade científica. No estudo desenvolvido observou-se a preferência pela utilização da técnica de planejamento HTN -JSHOP2.
1.1 TRABALHOS CORRELATOS
Murtagh (2004) apresenta uma solução para composição de serviços web que contempla a fase de planejamento, utilizando como planejador o JSHOP. A OWLS2JSHOP demonstra a pertinência da aplicação de planejamento HTN para o planejamento de serviços web. Contudo, segundo o autor este sistema poderia ser melhorado em vários aspectos, dentre as melhorias encontra-se a compatibilidade com outras estruturas de controle de decomposição, além da já suportada estrutura Sequence. Essas estruturas serão discutidas na seção 3.2.3.
Sirin(2004) propõe uma solução que contemple as fases de planejamento e execução da composição de serviços web. Para a conversão OWL-S para o SHOP2 é proposto o mapeamento de processos atômicos e compostos para respectivamente operadores e métodos. Esse último contempla todas as estruturas
de controle suportadas pelo planejador utilizado. Na fase de execução é possível, em caso de falha, replanejar em busca de uma nova solução, e permite a invocação de programas externos.
Diferente do TransPlan estas soluções são incompatíveis com a versão mais atual do SHOP que é o JSHOP2. Elas também não são flexíveis para permitir a sua utilização com outro planejador. Este trabalho apresenta um comparativo mais detalhado na seção 4.3, onde se destacam as principais diferenças e semelhanças.
1.2 ORGANIZAÇÃO DO TRABALHO
O trabalho está organizado da seguinte maneira: o capítulo 1 apresenta os conceitos de serviços web, as principais tecnologias envolvidas e a utilização de semântica para definição desses serviços. No capítulo 2 são apresentados conceitos relacionados aos planejadores da Inteligência Artificial, e algumas das técnicas utilizadas para planejamento, dentre elas a Rede Hierárquica de Tarefas (HTN), ressaltando as vantagens de sua utilização na composição de serviços web. Já no capítulo 3 é apresentada a solução proposta nesse trabalho, os cenários utilizados para validação e os resultados alcançados. E por fim, o capítulo 4 destina-se as considerações obtidas sobre o trabalho e são apredestina-sentadas possibilidades de melhorias e ampliações em trabalhos futuros.
2 SERVIÇOS WEB
A globalização alavancou grandes transformações mercadológicas, o que impactou diretamente nas soluções tecnológicas. Essas soluções foram revisadas e hoje existem propostas como a Arquitetura Orientada a Serviços (SOA), em que aplicações monolíticas com escopo bem definido são substituídas pelo conceito de aplicações compostas por um conjunto de serviços web.
A utilização de uma arquitetura orientada a serviços facilita o reuso, fazendo com que se tornem dinâmicos na medida em que serviços podem ser substituídos em tempo de execução de maneira transparente. Como as organizações estão em constante atualização, sempre buscando vantagens competitivas, a dinamicidade dos sistemas torna-se uma questão relevante (MACHADO, 2004).
Segundo Peer (2005) os serviços web são componentes de software disponibilizados e invocados pela internet usando protocolos padrão da rede. O serviço web quando invocado por uma requisição HTTP pode provocar a execução da rotina de um programa local ou de serviços diversos. Segundo Colouris (2005) um serviço web e um servidor web possuem diferentes definições, enquanto o servidor fornece serviço HTTP básico que pode ser acessado pelos browsers, os serviços web é baseado nas operações definidas em sua interface não sendo possível o acesso diretamente pelos navegadores. Contudo, um serviço web pode ser fornecido por um servidor, junto com páginas web, ou como um serviço isolado.
Como pode ser observado na Figura 1, o ciclo de vida de um serviço web é constituído de quatro estados: publicação, descoberta, descrição e invocação. A publicação é um processo opcional, através do qual o fornecedor do serviço torna
pública a existência do mesmo, registrando-o em um repositório, e.g. UDDI.
Figura 1 – Ciclo de vida do Web Service. Fonte: Lopes et al.(2004).
A descoberta é um processo no qual uma aplicação cliente toma conhecimento da existência do serviço pretendido pesquisando-o em um repositório UDDI. A descrição expõe a interface do serviço, onde se encontram descritas todas as funcionalidades por ele disponibilizadas, assim como os tipos de mensagens que podem ser enviadas e recebidas. A invocação é o processo pelo qual o cliente e o servidor interagem através do envio de mensagens de requisição e de eventual recepção de mensagem de saída - output.
Na Figura 2, é possível ser visualizado uma arquitetura para os serviços web. As aplicações, representadas na camada superior, acessam os serviços web descritos em Web Services Description Language (WSDL) (W3C, 2007), utilizando um serviço de diretório (páginas amarelas para os serviços web) ou diretamente quando possui o conhecimento da sua Uniform Resource Location (URL).
Figura 2 – Arquitetura dos serviços Web. Fonte: Adaptado de Coulouris, 2005.
Os dados são empacotados usando geralmente o protocolo de troca de mensagens Simple Object Access Protocol (SOAP). O uso de protocolos como o HTTP permite que o tráfego de informações se efetive facilmente pela internet, uma vez que os firewalls das organizações geralmente permitem esse tipo de tráfego. As tecnologias básicas utilizadas pelos serviços web serão descritas com mais detalhes a seguir.
2.1 TECNOLOGIAS BÁSICAS
2.1.1 SIMPLE OBJECT ACCESS PROTOCOL (SOAP)
O SOAP é um protocolo utilizado pelos serviços web para troca de mensagens entre as partes envolvidas. Esse protocolo utiliza mensagens – requisição e resposta – com conteúdo em eXtensible Markup Language (XML). Essa mensagem XML é encapsulada em uma mensagem HTTP, mas a versão mais atual desse protocolo também pode ser utilizada sobre SMTP, TCP ou UDP. A especificação do protocolo SOAP define basicamente como o XML deve ser usado para representar o conteúdo das mensagens e como os destinatários das mensagens devem processar os elementos XML.
A mensagem SOAP é transportada em um envelope
cabeçalho, facultativo, um corpo que contém as informações principais das requisições e respostas aos métodos. Na
elemento opcional Fault, (GRAHAM et al., 2004). <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap soap:encodingStyle="http://www.w3.org/2001/12/soap <soap:Header> [...] </soap:Header> <soap:Body> [...] <soap:Fault> [...] </soap:Fault> </soap:Body> </soap:Envelope> A Figura 5 e a Figura 6
resposta respectivamente ao serviço
usando o protocolo HTTP. A mensagem de requisição possui o parâmetro StockName -nome do estoque
Figura 3 – Estrutura do Envelope Fonte: Adaptado de Coulouris, 2005.
A mensagem SOAP é transportada em um envelope, Figura
facultativo, um corpo que contém as informações principais das isições e respostas aos métodos. Na Figura 4 observa-se a prese
Fault, responsável por provê informações sobre falhas ocorridas
<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
Figura 4 - Estrutura de uma mensagem SOAP Fonte: W3SCHOOLS, 2007
6 mostram exemplos de mensagens SOAP de requisição e resposta respectivamente ao serviço GetStockPrice –obter preço no estoque usando o protocolo HTTP. A mensagem de requisição possui o parâmetro
nome do estoque - e a mensagem response retornará o
Figura 3, que possui um facultativo, um corpo que contém as informações principais das se a presença de um responsável por provê informações sobre falhas ocorridas
-envelope" encoding">
Estrutura de uma mensagem SOAP.
mostram exemplos de mensagens SOAP de requisição e obter preço no estoque - usando o protocolo HTTP. A mensagem de requisição possui o parâmetro retornará o Price através
da tag GetStockPriceResponse.
POST /InStock HTTP/1.1
Host: www.example.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Body xmlns:m="http://www.example.org/stock"> <m:GetStockPrice> <m:StockName>IBM</m:StockName> </m:GetStockPrice> </soap:Body> </soap:Envelope>
Figura 5 - Uma requisição SOAP sobre http. Fonte: W3SCHOOLS, 2007
HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Body xmlns:m="http://www.example.org/stock"> <m:GetStockPriceResponse> <m:Price>34.5</m:Price> </m:GetStockPriceResponse> </soap:Body> </soap:Envelope>
Figura 6 - Uma resposta SOAP sobre http. Fonte: W3SCHOOLS, 2007
Uma alternativa para utilização do SOAP é o Representational State Transfer (REST) no qual clientes utilizam operações HTTP para acessar recursos representados em XML. Nesse protocolo o cliente recebe o estado inteiro do recurso
ao invés de invocar uma operação que forneça parte dele, como acontece com o SOAP. Nessa tecnologia quando um novo recurso é criado, passa a ser disponibilizado em uma nova URL (PAUTASSO, 2007).
2.1.2 WEB SERVICES DESCRIPTION LANGUAGE (WSDL)
A Linguagem WSDL é um padrão World Wide Web Consortium (W3C) para descrição da interface dos serviços web, escrita em XML ela também é utilizada para localizá-los. As definições de interface são necessárias para formar um contrato que deverá ser seguido tanto pelo cliente quanto pelo servidor. A Figura 7 lista os principais elementos que compõem a WSDL e a Figura 8 apresenta a estrutura de um documento WSDL compostos pelos elementos.
Elemento Definição
<portType> Define as operações disponível no serviço <message> Define as mensagens utilizadas pelo serviço <types> Define os tipos de dados utilizados pelo serviço <binding> O protocolo de comunicação utilizado pelo serviço
Figura 7 - Elementos do WSDL. Fonte: W3SCHOOLSb (2007) <definitions> <types> definition of types... </types> <message> definition of a message.... </message> <portType> definition of a port... </portType> <binding> definition of a binding.... </binding> </definitions>
Figura 8 – Estrutura de um documento WSDL. Fonte: W3SCHOOLSb, 2007
2.2 COMPOSIÇÃO DE SERVIÇOS WEB
Para a comunicação de uma aplicação cliente com um serviço web, as tecnologias SOAP e WSDL são suficientes. Entretanto, caso seja necessário a invocação de outros serviços web é relevante a combinação de suas funcionalidades e adoção de novas tecnologias. A atividade de combinar os serviços é conhecida como composição de serviços web (CLARO et. al., 2008).
A composição de serviços é possível devido a publicação da interface do serviço, o que permite que suas operações sejam combinadas com outros serviços para oferecer um novo serviço (COLOURIS et. al., 2005). Para ilustrar a composição de serviços será utilizado um cenário para conversão de arquivos Microsoft Word (doc) para Portable Document Format (pdf), Figura 9. Nesse cenário, parte-se do princípio que não exista um serviço capaz de atender ao objetivo isoladamente, mas existe um serviço denominado de A capaz de converter do formato doc para Rich Text Format (RTF) e um outro serviço B que converte de RTF para DOC como mostra a Figura 9. Assim, com o intuito de atingir o objetivo proposto, converter doc-pdf, estes serviços podem ser combinados e executados. A definição desse fluxo poderá ocorrer de duas formas: manual ou automática (DUSTDAR et. al, 2005).
A composição manual necessita da intervenção do usuário. O próprio usuário especificará o fluxo utilizando-se de uma linguagem, como Business Process Execution Language for Web Services (BPEL4WS) (SRIVASTAVA, 2003). Devido a simplicidade do problema apresentado no cenário é possível realizar a composição manualmente. Entretanto, a medida que surgem novos serviços esse processo torna-se mais custoso, podendo até tornar-se inviável. Na composição automática, existe uma mínima intervenção humana no processo (CLARO et al, 2007). Na
Figura 9, a aplicação cliente apenas fornece seu objetivo para um serviço web e ele será responsável por localizar e determinar a ordem que os serviços deverão ser invocados (fluxo para execução dos serviços), que no cenário mencionado converterá um documento DOC para PDF.
Figura 9 – Serviço de Conversão de Arquivos
Murtagh(2004) acrescenta que com a composição automática é possível substituir serviços em tempo de execução para incluir outros serviços que fariam o objetivo ser atingido, por exemplo, com menor custo, como também, substituir serviços que não estejam mais em operação, criando uma solução tolerante a falhas.
Claro et al (2007) e Murtagh (2004) apresentam 3 fases para composição automática: descoberta, planejamento e execução. Estas etapas são descritas a seguir.
Descoberta. A fase de descoberta tem como objetivo localizar os serviços web
candidatos que poderão ser utilizados para atender determinado objetivo do usuário.
Planejamento. A fase de planejamento é responsável determinar quais e em que ordem os serviços candidatos – identificados na fase de descoberta – serão
utilizados para atender o objetivo definido. A ênfase desse trabalho concentra-se nessa etapa.
Execução. Nessa fase todos os serviços candidatos identificados, na fase de planejamento, serão invocados. Essa fase tem o objetivo em recuperar os dados dos serviços candidatos.
Para que seja viável a composição automática é necessário que a descrição dos serviços seja interpretável por máquinas. As informações contidas nos documentos WSDL apenas descrevem sintaticamente os serviços, havendo a necessidade de linguagens como Ontology Web Language for Services (OWL-S) para descrição semântica desses serviços (MURTAGH,2004).
2.2.1 ONTOLOGY WEB LANGUAGE FOR SERVICES (OWL-S)
A web semântica permite que dados e serviços sejam interpretados por software sem problemas de ambigüidade, problema existente na abordagem sintática. Linguagens como WSDL ou WS-BPEL precisam ser estendidas ou novas linguagens precisam ser utilizadas para permitir que os serviços web sejam descritos de forma que sejam compreendidos automaticamente pelos computadores de forma não ambígua(DIGIAMPIETRI et al, 2007). Para ilustrar a importância da semântica, considera-se uma pessoa que ao ler a assinatura dos seguintes métodos:
converterDocParaPdf(Arquivo doc) e transformarDocParaPdf(Arquivo doc)
compreenderá que os métodos tem o mesmo objetivo. Entretanto para um sistema computacional que utilize definição sintática esta interpretação não é tão fácil. O processo de adicionar semântica, processáveis por máquinas, aos conteúdos e aos serviços na web é possível através da definição e utilização de descrições
semânticas. As características semânticas podem utilizar ontologias para uma descrição não ambígua.
Uma ontologia define os conceitos, as propriedades e axiomas para um determinado domínio de forma que possa ser compreendido e usado por pessoas ou máquina. Por esta característica, a ontologia é uma das tecnologias chaves para a implementação da Web Semântica (CARVALHO, 2005). Em geral, essas ontologias são representadas em Ontology Web Language (OWL), linguagem baseada em Resource Definition Language (RDF) proposta pelo W3C (CALHAU, 2006).
A OWL é uma linguagem para definição de ontologias na Web. Uma ontologia OWL formaliza um domínio através da definição de classes e seus relacionamentos, indivíduos, propriedades e axiomas sobre eles. Também é possível especificar como derivar conseqüências lógicas, isto é, fatos que não estão presentes nas ontologias (SMITH et al, 2004).
A descrição semântica de serviços web utiliza dentre outras linguagens uma variação da OWL, denominada OWL-S – OWL for Services – também proposta pela W3C. Segundo Martin (2004a) a OWL-S descreve os serviços web através de classes e propriedades em OWL, para que possa ser compreendida por máquinas. Murtagh (2004) propõe que para conseguir distinguir dois serviços com sucesso é necessário descrever: propriedades, habilidades e axiomas, utilizado na etapa de descoberta; precondições, efeitos, entrada e saída, utilizado na fase de planejamento; Interfaces, pontos de acesso e protocolos, utilizado na fase de execução.
A Figura 10 mostra a ontologia OWL-S e suas principais subontologias. A subontologia Service fornece uma referência organizacional para um serviço web,
uma instância dessa classe existirá para cada serviço publicado. Essa ontologia possui as seguintes propriedades: presents descreve o que ele faz describedBy -descreve como funciona - e supports - que -descreve como acessá-lo (MARTIN, 2004b). A linguagem OWL-S permite descrever serviços em três seções: o perfil do serviço (ServiceProfile), o modelo processual do serviço (ServiceModel) e a instanciação do serviço (ServiceGrounding). A Figura 11 mostra um exemplo de definição da subontologia Service em OWL-S.
Figura 10 - Visão de alto nível da ontologia OWL-S
<!-- Service description --> <service:Service rdf:ID="BookFinderService"> <service:presents rdf:resource="#BookFinderProfile"/> <service:describedBy rdf:resource="#BookFinderProcess"/> <service:supports rdf:resource="#BookFinderGrounding"/> </service:Service>
Figura 11 – Exemplo de definição da classe Service
encontrado na fase de descoberta de serviços. Nessa classe encontram-se principalmente as pré-condições, os efeitos, as entradas - hasInput - e as saídas - hasOutput (Figura 12).
<mind:BookInformationService rdf:ID=" ConverterDoc2RtfProfile">
<service:presentedBy rdf:resource="#ConverterDoc2RtfService"/>
<profile:serviceName xml:lang="en">DOC 2 PDF</profile:serviceName>
<profile:textDescription xml:lang="en"> This service returns the file at RTF format.
</profile:textDescription>
<profile:hasInput rdf:resource="#FileDoc"/> <profile:hasOutput rdf:resource="#FileRtf"/>
</mind:BookInformationService>
Figura 12 – Exemplo de definição da classe ServiceProfile
A ontologia ServiceModel informa ao cliente do serviço como usá-lo, permitindo encontrar as pré-condições, efeitos, entradas e saídas do serviço, incluídas no ServiceProfile (CALHAU, 2006). A ontologia ServiceModel possui uma referência a subontologia Process e suas subontologias SimpleProcess (Processo Simples), AtomicProcess (Processo Atômico) e CompositeProcess (Processo Composto).
O processo Simples é um modelo abstrato que não pode ser instanciado, utilizado para representar um processo atômico ou composto. Um processo atômico é todo aquele que um serviço web pode ser executado diretamente, sem a necessidade de outros processos (serviço). A Figura 13 contém um exemplo da definição do processo atômico ConverterDoc2Rtf que poderia ser utilizado no cenário para conversão de arquivos.
<process:AtomicProcess rdf:ID="ConverterDoc2RtfProcess"> <service:describes rdf:resource="#ConverterDoc2RtfService"/> <process:hasInput rdf:resource="#FileDoc"/> <process:hasOutput rdf:resource="#FileRtf"/> </process:AtomicProcess> − <process:Input rdf:ID="FileDoc"> <process:parameterType rdf:datatype="http://www.w3.org/2001/XMLSchema#anyURI">http://www.w3.org/20 01/XMLSchema#string</process:parameterType> <rdfs:label>File Doc</rdfs:label> </process:Input> − <process:Output rdf:ID="FileRtf"> <process:parameterType rdf:datatype="http://www.w3.org/2001/XMLSchema#anyURI">http://purl.org/net/ nknouf/ns/bibtex#FileRtf</process:parameterType> <rdfs:label>File Rtf</rdfs:label> </process:Output>
Figura 13 – Exemplo de definição de um Processo Atômico
Como pode ser observado na Figura 15, os processos compostos (CompositeProcess) são resultantes da composição de processos atômicos ou outros processos compostos, e são utilizados quando a requisição do usuário não pode ser atendida por um processo atômico diretamente. Pelo fato de ser utilizado mais de um processo atômico, torna-se necessário estruturas de controle para especificar o fluxo de execução. A OWL-S suporta estruturas de controle como Sequence, Split, Split+Join, Any-Order, If-Then-Else. A estrutura Sequence define a execução dos serviços de forma seqüencial (e.g., [A]→[B]→[C]). O controle Split define a execução simultânea dos processos. O Split+Join é utilizado para especificar serviços que podem ser executados concorrentemente, mas que necessitam de ter a sua execução concluída (e.g., [A, B]→[C]). O Any-Order permite que os processos possam ser executados arbitrariamente, entretanto, não podem
ser executados simultaneamente. A estrutura If-Then-Else executa os serviços a medida que as condições dos mesmos são atendidas.
...
<rdf:Property rdf:ID="ifCondition">
<rdfs:comment> The if condition of an if-then-else </rdfs:comment> <rdfs:domain rdf:resource="#If-Then-Else"/>
<rdfs:range> rdf:resource ="#Condition" </rdfs:range> </rdf:Property> <rdf:Property rdf:ID="then"> <rdfs:domain rdf:resource="#If-Then-Else"/> <rdfs:range rdf:resource="#ProcessComponent"/> </rdf:Property> <rdf:Property rdf:ID="else"> <rdfs:domain rdf:resource="#If-Then-Else"/> <rdfs:range rdf:resource="#ProcessComponent"/> </rdf:Property> ...
Figura 14 – Exemplo de definição da estrutura condicional
.
Figura 15 – Exemplo de definição da classe ServiceModel
A Figura 16 mostra um exemplo de um processo composto para o cenário de conversão de arquivos que utiliza a estrutura de controle seqüencial. Define-se
nessa composição a execução do serviço ConverterDoc2Rtf e na seqüência ConverterRtf2Pdf. ... <process:composedOf> <process:Sequence> <process:components> <process:ControlConstructList> <list:first> <process:Perform rdf:nodeID="ConverterDoc2Rtf"/> </list:first> <list:rest> <process:ControlConstructList> <list:rest rdf:resource="http://www.daml.org/services/OWL-S/1.1/generic/ObjectList.owl#nil"/> <list:first>
<process:Perform rdf:nodeID=" ConverterRtf2Pdf"/> </list:first> </process:ControlConstructList> </list:rest> </process:ControlConstructList> </list:rest> </process:ControlConstructList> </process:components> </process:Sequence> </process:composedOf> ...
Figura 16 – Exemplo de definição de um Processo Composto
A classe ServiceGrounding contém a informação acerca do acesso ao serviço descrito, provendo um mapeamento da classe abstrata ServiceModel para WSDL como pode ser visualizado na Figura 17. Dessa forma, é possível converter de OWL-S para WOWL-SDL: classes, inputs e outputs, processos atômicos.
Figura 17 – Mapeamento de ServiceModel para WSDL Fonte: W3C, 2007
2.3 AUTOMATIZANDO A COMPOSIÇÃO
Rao (2004) cita duas técnicas para a composição dinâmica de serviços web: workflow dinâmico e planejamento da IA. A técnica de workflow é composta por um conjunto de passos lógicos (funções), dependências entre funções, regras de encaminhamento e participantes. Entretanto, é necessário um processo automatizado para encontrar e coordenar recursos concretos - e.g os serviços Web. (CALHAU, 2006).
Segundo Murtagh (2004) o problema abordado na composição de serviços web para determinar a seqüência de execução dos serviços para alcançar um objetivo definido, é precisamente o tipo de problema resolvido pelo planejamento da inteligência artificial. O próximo capítulo tem como objetivo compreender os planejadores da Inteligência Artificial e a utilização desses na composição automática de serviços.
3 PLANEJADORES DA INTELIGÊNCIA ARTIFICIAL
O planejamento da IA surgiu de investigações em busca do espaço de estado, prova de teoremas e teoria de controle, e das necessidades práticas da robótica. O primeiro sistema de planejamento importante, Stanford Research Institute Problem Solver (STRIPS), influenciou a maioria das linguagens utilizadas atualmente pelos sistemas de planejamento (RUSSELL et. al., 2004). A visão clássica para o planejador corresponde ao agente responsável por apresentar uma seqüência de ações para atingir determinado objetivo (PEER, 2005).
3.1 CONCEITOS BÁSICOS
Para uma melhor compreensão dos planejadores da IA e para alcançar um entendimento comum é importante apresentar os conceitos básicos relacionados a essa área do conhecimento, tais como estado, precondição e efeito, ação e plano.
Estado. Um estado é representado por um conjunto de proposições atômicas,
instanciadas, que podem ser literais proposicionais (e.g. Pobre ^ Desconhecido poderia representar o estado de um agente infeliz), ou literais de primeira ordem (e.g. Em(Aviao, Salvador) para representar um estado para um problema de logística). Já as condições não mencionadas em um estado são consideradas falsas. Sabe-se que o estado objetivo é alcançado quando um estado contém todas as proposições e não necessariamente somente elas. Por exemplo, o estado Rico ^ Famoso ^ Miserável satisfaz ao objetivo Rico ^ Famoso (RUSSELL et. al., 2004).
Precondição. A precondição é um literal que define o que deve ser verdadeiro em
2004).
Efeito. O efeito corresponde ao resultado da ação, as modificações que são
realizadas ao estado. Alguns sistemas de planejamento dividem os efeitos em positivos, serão acrescentados ao estado, e negativos, serão retirados do estado. (RUSSELL et. al., 2004). Além disso, as poscondições são condições que deverão ser atendidas ao final da execução da ação. Os efeitos correspondem ao resultado da ação (MURTAGH, 2004).
Ação. A ação, também conhecido como operador, é responsável pela transição de
um estado para outro (CALHAU, 2006). E, para sua execução é necessário que suas pré-condições sejam satisfeitas. Uma vez executada, a ação modifica o estado com os seus efeitos.
Plano. Um plano corresponde a uma seqüência de ações, necessário para sair do
estado inicial e chegar ao estado final. Sendo que o custo do caminho que determinará a qualidade da solução (CALHAU, 2006).
Ambiente. Existe uma grande variedade de ambientes em que um planejador pode
atuar. Russel (2004) classifica-os de acordo com suas propriedades que são apresentadas a seguir.
• Observável: quando é possível detectar os aspectos que são relevantes para a escolha de uma ação, então o ambiente é completamente observável. Neste caso, o não se precisa ter qualquer estado interno para controlar o mundo. Caso contrário o ambiente é tido como parcialmente observável. • Determinístico: se o próximo estado do ambiente é completamente
determinístico. Caso contrário, ele é estocástico ou não determinístico (GHALAB et al, 2004).
• Episódico: quando cada tomada de decisão não depende de decisões anteriores, se isso acontecer, então o ambiente será seqüencial, e assim, a decisão atual pode afetar todas as decisões futuras.
• Estático: se a passagem do tempo é importante e o ambiente puder se alterar enquanto decide-se sobre a realização de uma ação, então ele é dinâmico. Caso contrário, ele é estático.
• Discreto: se o ambiente puder ser determinado pelo número de estados, percepções, ações e pelo tempo, então ele é discreto. Caso contrário, ele é contínuo.
.Replanejamento. Processo de invocar novamente o planejador para apresentar um plano alternativo quando algo inesperado acontece durante a execução de um plano (RUSSEL, 2004).
3.2 TIPOS DE PLANEJAMENTO
Antes de citar algumas das técnicas de planejamento, é importante ressaltar que não existe um consenso sobre qual a melhor estratégia de planejamento. O que existem, são técnicas mais apropriadas a determinados problemas. De qualquer forma, a competição entre elas resultou em ganhos significativos em eficiência para os sistemas de planejamento (RUSSELL et. al., 2004).
A perspectiva clássica de um planejador nem sempre é suficiente, dada a complexidade de algumas soluções. A complexidade de um plano é marcada pela
definição do domínio ou do objetivo, como também pelo modelo previsto para a execução do plano (e.g. se uma operação não produzir o resultado desejado, o agente poderia ter a oportunidade de voltar e regerar o plano, ao invés de ter que confiar nele). (PEER, 2005).
No que diz respeito à ordem das ações, o planejador pode ser linear ou não linear. O planejador linear, também conhecido como planejador de ordem total, gera um plano constituído por uma seqüência de ações totalmente ordenadas. Já o não linear, também conhecido como planejador de ordem parcial, é capaz de produzir planos com ações que não obedeçam a uma ordem específica de execução, ou seja, algumas ações podem ser executadas em paralelo, não seqüencial, o que muitas vezes aumenta a eficiência do sistema (CALHAU, 2006).
3.2.1 PLANEJAMENTO COM BUSCA NO ESPAÇO DE ESTADOS
O mais simples algoritmo clássico de planejamento é o planejamento com busca no espaço de estado. Essa estratégia de busca utiliza como espaço de busca o espaço de estados, onde cada nó corresponde a um estado do mundo (GHALLAB et al, 2004).
O planejamento por procura no espaço de estados (State-Space Planning) tenta encontrar o plano buscando ações – operadores - que formem um caminho entre o estado inicial e o estado objetivo. Dessa forma, a procura pelo estado desejado pode ocorrer para frente – progressão - ou para trás - regressão. Na progressão, parte-se do estado inicial do mundo e, através da execução de ações, constrói-se a árvore de estados. A procura chega ao fim quando o estado objetivo é alcançado ou quando já não há mais nós na árvore a se percorrer. Já na regressão, parte-se do estado
objetivo, executando as ações, gerando uma árvore de estado e retrocedendo até atingir o estado inicial ou até não ser possível continuar a expansão da árvore. A busca para frente e a busca para trás no espaço de estados são formas específicas de busca de planos totalmente ordenados (RUSSEL, 2004).
As estratégias de busca por regressão e progressão não são eficientes sem uma função heurística. As funções heurísticas têm o objetivo de guiar o planejador na escolha de bons caminhos, buscando uma solução ótima (RUSSEL, 2004).
.
3.2.1.1 O DOMÍNIO DO MUNDO DOS CUBOS COM BUSCA NO ESPAÇO DE ESTADO
O mundo dos cubos é um problema clássico para o planejamento da Inteligência Artificial mencionado por Russel (2004). A seguir ele será descrito, com o objetivo de esclarecer a representação de um problema e como solucioná-lo, utilizando as técnicas de busca no espaço de estado.
Como pode ser observado na Figura 18, esse domínio contempla um conjunto de cubos empilhados sobre uma mesa. Um braço robô pode movimentar o cubo para outra posição, que somente poderá ser em cima da mesa, ou para cima de outro cubo. A única restrição para essa operação é que o cubo o qual deseja-se mudar a posição não tenha outro em cima dele. Por exemplo, na Figura 18 só é possível inicialmente movimentar D ou A. O objetivo consiste em a partir do estado inicial definido alcançar o estado objetivo. Ambos os estados são apresentados, na Figura 18.
primeira ordem Sobre(b,x) para indicar que o bloco b está sobre x, onde x é outro bloco ou a mesa. A ação Mover(b,x,y) será utilizada para mover um determinado cubo de x(cubo ou mesa) para y(cubo ou mesa). O literal Livre(x) será verdadeiro quando não há nada sobre x.
Figura 18 - Mundo dos Cubos Fonte: Adaptado de (RUSSEL, 2004).
Logo, a ação Mover(b,x,y) poderá ser representada como mostra a Figura 19. Entretanto, a solução oferecida até o momento, ainda contém dois problemas: 1. Quando x for a mesa, a ação Mover tem o efeito Livre(Mesa), 2. A mesa não precisa ficar limpa quando y=mesa; ações desnecessárias (e.g. Mover(B,C,C)).
Ação(Mover(b, x, y),
PRECONDIÇÃO: Sobre(b, x) ∧ Livre(b) ∧ Livre(y) ∧(b _ x) ∧ (b _ y) ∧ (x _ y)
EFEITO: Sobre(b, y) ∧ Livre(x) ∧ ¬Sobre(b, x) ∧ ¬Livre(y))
Figura 19 - Listagem da Ação Mover em Strips. Fonte: Adaptado de (RUSSEL, 2004).
Para corrigir o primeiro problema mencionado pode-se introduzir outra ação para mover um bloco b de x para a mesa e adicionar o predicado Bloco e acrescentar Bloco(b) e Bloco(y) à precondição Mover. Já o segundo problema poderá ser resolvido adicionando precondições de desigualdade, como mostra a Figura 20.
Iniciar(
Bloco(A) ∧ Bloco(B) ∧ Bloco(C) ∧ Bloco(D) ∧ Bloco(E) ∧
Sobre(A, Mesa) ∧ Sobre(B, A) ∧ Sobre(C, B) ∧ Livre(C) ∧
Sobre(D, Mesa) ∧ Sobre(E, D) ∧ Livre(E))
Objetivo(Sobre(E, B)) Ação(Mover(b, x, y),
PRECONDIÇÃO: Sobre(b, x) ∧ Livre(b) ∧ Livre(y) ∧ Bloco(b) ∧
(b _ x) ∧ (b _ y) ∧ (x _ y),
EFEITO: Sobre(b, y) ∧ Livre(x) ∧ ¬Sobre(b, x) ∧ ¬Livre(y))
Ação(MoverParaMesa(b, x),
PRECONDIÇÃO: Sobre(b, x) ∧ Livre(b) ∧ Bloco(b) ∧ (b _ x),
EFEITO: Sobre(b, Mesa) ∧ Livre(x) ∧ ¬Sobre(b, x))
Figura 20 - Descrição do domínio do Mundo dos Cubos. Fonte: Adaptado de (RUSSELL et. al., 2004)
3.2.2 PLANEJAMENTO DE ORDEM PARCIAL
A busca no espaço de estado explora apenas seqüências estritamente lineares de ações conectadas de forma direta ao início ou ao objetivo, não utilizando a técnica de decomposição de problema, que permite quebrar o problema em parte, e atuar sobre cada subproblema separadamente. Por exemplo, um problema de entregar um conjunto de encomendas a seus respectivos destinos, poderia apresentar como uma possível solução, decompor o problema em várias partes, uma para cada aeroporto (RUSSELL et. al., 2004).
A estratégia de ordem parcial, também conhecido como não linear ou planejamento com busca no espaço dos planos (Plan-Space Planning), é uma abordagem que funciona de forma independente sobre os subobjetivos gerando subplanos e depois combinando-os (RUSSELL et. al., 2004). Dessa forma, qualquer técnica que possa adicionar duas ações em um plano sem especificar qual delas deve ser executada primeiro, é um exemplo de planejador de ordem parcial.
Essa abordagem diferencia-se da abordagem de espaço de estados não somente pelo espaço de busca, como, também, na definição da solução. A ordem parcial usa mais que uma seqüência de ações. Nessa estratégia o planejamento é definido por duas operações: a) a escolha das ações; b) a ordem das ações escolhidas para alcançar o objetivo. Um plano é definido por um conjunto de operadores associado às restrições ordenadas e associadas, o que poderá não corresponder à seqüência de ações alcançada pelo espaço de estado (GHALLAB et al, 2004).
3.2.3 PLANEJAMENTO DE REDE HIERÁRQUICA DE TAREFA
O planejamento de Rede Hierárquica de Tarefa, HTN, Hierarchical Task Network planning) é uma técnica que cria o plano através da decomposição de tarefas. A descrição do domínio inclui um conjunto de operadores, semelhante às ações dos planejadores clássicos, possuindo entrada, saída, pré-condições, efeitos (IOPE - Inputs, Outputs, Preconditions, Effects) e, também, um conjunto de métodos que descrevem como decompor uma tarefa em um conjunto de subtarefas. O planejamento ocorre usando métodos para decompor as tarefas recursivamente até encontrar tarefas primitivas que correspondem aos operadores do domínio (SIRIN, 2004).
Segundo Russel(2004) a decomposição hierárquica é uma das técnicas mais difundidas para atuar com soluções complexas, pelo fato de que cada nível da hierarquia é reduzido a um número menor de atividades até encontrar atividades atômicas (operadores).
Sirin (2004) apresenta diversas características que justifica a utilização da técnica HTN na composição de serviços web, dentre elas destacam-se:
O HTN permite modularidade. Os métodos podem ser escritos sem considerar
como as subtarefas serão decompostas ou o que compõe as tarefas que ele decompõe. Esta modularidade adequa-se muito bem ao cenário de serviços web. Os métodos correspondem a workflows compostos recursivamente. Estes workflows estão em diferentes fontes, sendo necessário que o planejador integre-os de forma a apresentar uma composição desses workflows para um problema específico.
Exploração do espaço de estados. Uma vez que o planejador considera a
completa execução do mundo de estados, existem possibilidades de minimizar vários tipos de falhas ou custos. Ressalta-se que se o planejador encontra um plano, ele saberá que o domínio fornecido é possível encontrar um plano.
Escalabilidade. O planejador HTN suporta um grande número de métodos e
operadores. O que geralmente ocorre em problemas complexos do mundo real. Alguns planejadores HTN, e.g., Simple Hierarchical Ordered Planner (SHOP2), suportam a definição de pré-condições complexas, que permite integrar os conhecimentos existentes sobre as bases semânticas, bem como fornecer informações dos serviços web.
Aquisição de Informações durante o Planejamento. O planejador HTN dispõe de
pontos específicos em sua linguagem para a intervenção humana em tempo de execução. Como exemplo, poderia ser solicitado ao usuário uma informação em um ponto específico, ou se o planejador atingir um ponto em que não é possível continuar a decomposição, é possível interagir com um agente externo, que poderá ser humano ou software.
Um sistema baseado nessa proposta é o Integrated Service PLanning and Execution (ISP&E). Ele gera várias alternativas para solução e uma das alternativas é
selecionada usando notação genérica de custo. Este plano é executado e alterado no ambiente de execução e checado periodicamente. Quando ocorre uma falha o plano é reexecutado ou, se a falha continua, um mecanismo de replanejamento é acionado (DIGIAMPIETRI et. al., 2007).
Outros exemplos de sistemas planejadores HTN são o SHOP e o seu sucessor SHOP2, que serão descritos a seguir.
3.3 JSHOP2
O Java Simple Hierarchical Ordered Planner (JSHOP) 2 é a versão em Java do SHOP2, desenvolvido em LISP. Dentre as vantagens para utilização do JSHOP2, em relação às versões anteriores do SHOP destaca-se a performance (ILGHAMI, 2003).
O SHOP2 classificou-se entre os 4 dos 14 planejadores que concorreram na competição internacional de planejamento (SIRIN, 2004). Os planejadores SHOP foram testados numa grande variedade de problemas, desde os mais simples aos mais complexos
.
A Figura 21 mostra o macro-fluxo do JSHOP. A entrada do JSHOP2 é composta pelo domínio e problema e a saída é a solução encontrada.
O domínio é composto por operadores (atividades atômicas), métodos (atividades compostas) e axiomas. Um operador é definido pela sintaxe (:operator h P D A [c]), em que h (head) é o cabeçalho que contém o nome do operador iniciando com uma exclamação. P (precondition) é o conjunto de literais que define a precondição para que o operador seja executado. D (delete list) corresponde aos efeitos negativos, a
lista de literais que serão excluídos da base de conhecimento. A corresponde aos efeitos positivos,
base de conhecimento. Já C (
cujo valor padrão é 1 (ILGHAMI, 2006)
Os métodos são atividades compostas que definem como decompor o plano em busca de tarefas primitivas (operadores). Um método
sintaxe (:method h [[D] P T]+
e P (precondition) contém a lista de literais para que as tarefas em executadas. T pode conter métodos e operadores
ordem que forem dispostos, desde que suas precondições sejam satisfeitas (ILGHAMI, 2006).
3.3.1 EXEMPLOS DE UTILIZAÇÃO
Para ilustrar a utilização do JSHOP2 são apresentados dois domínios lista de literais que serão excluídos da base de conhecimento. A
corresponde aos efeitos positivos, ou seja, a lista de literais que serão incluídos na base de conhecimento. Já C (cost) corresponde ao custo de execução do operador,
ILGHAMI, 2006).
Figura 21 - Macro-fluxo do JSHOP
Os métodos são atividades compostas que definem como decompor o plano em mitivas (operadores). Um método no JSHOP2 é definido pela (:method h [[D] P T]+) em que h é o cabeçalho contendo o nome do método,
) contém a lista de literais para que as tarefas em
T pode conter métodos e operadores, e estes serão executados na ordem que forem dispostos, desde que suas precondições sejam satisfeitas
DE UTILIZAÇÃO
Para ilustrar a utilização do JSHOP2 são apresentados dois domínios
lista de literais que serão excluídos da base de conhecimento. A (add list) lista de literais que serão incluídos na de execução do operador,
Os métodos são atividades compostas que definem como decompor o plano em no JSHOP2 é definido pela é o cabeçalho contendo o nome do método, ) contém a lista de literais para que as tarefas em T sejam estes serão executados na ordem que forem dispostos, desde que suas precondições sejam satisfeitas
de objetos) apresentado por Ilghami (2006) e BookFinder (Localização de Livros) apresentado por Murtagh(2004).
3.3.1.1 TROCA DE OBJETOS - SWAP
O domínio SWAP é útil para ilustrar as principais características do JSHOP2. Ele consiste basicamente em trocar um objeto de uma determinada posição por outro. A Figura 22 apresenta a definição desse domínio em JSHOP2. O domínio foi modelado com dois operadores colocar e retirar. O operador (colocar ?a) adiciona a base de conhecimento o literal (tem a), indicando que o objeto (a) ocupa a posição. Não foi definido precondição nem efeito negativo para esse operador). O operador (retirar ?a) elimina o objeto da posição através do efeito negativo. Não definiu-se efeito positivo para esse operador.
Figura 22 – Domínio de exemplo para SWAP
Na Figura 22 pode-se observar o método swap que descreve como decompor o plano. O problema no JSHOP2 é composto pelo estado inicial, que corresponde a uma lista de atividades de alto nível que será utilizada para a decomposição do problema na busca do objetivo também descrito na formulação do problema. Além dos operadores e métodos na definição do domínio é possível adicionar axiomas.
Figura 23 – Problema de exemplo para SWAP
A Figura 23 mostra um exemplo de como descrever um problema em JSHOP2. Uma vez definido o domínio e o problema é possível executar o JSHOP2 fornecendo-os como argumento. A Figura 24 mostra os comandos necessários para executar o JSHOP2GUI, a interface gráfica do JSHOP2.
Figura 24 – Passos para execução do JSHOP2GUI
A Figura 25 exibe o JSHOP2GUI em execução. Suas principais ações são: Multi-Step e Single Multi-Step, que permitem acompanhar os passos do planejador na busca da solução; a opção Run permite executar o planejador; e a opção Restart permite reiniciar o planejador. Quando o planejador encontra um plano, o JSHOP2GUI exibe a janela apresentada na Figura 26.
Figura 25 – Ambiente gráfico do JSHOP2
3.3.1.2 BUSCA E CONVERSÃO DE PREÇO DE LIVROS (BOOK FINDER)
Este exemplo é uma adaptação do exemplo utilizado por Murtagh (2004) e descreve um domínio de serviços de busca e conversão de preço de livros, a partir do nome do livro, e do tipo de moeda e retorna como resultado o preço. A Figura 27 apresenta a solução composta por três serviços em OWL-S: BookFinderProcess,BNPriceProcess e CurrencyConverterProcess.
BookFinderProcess: retorna o ISBN (BookInfo) de um livro sendo informado seu título (BookName);
BNPriceProcess: retorna o preço de um livro (BookPrice) dado seu ISBN (BookInfo);
CurrencyConverterProcess: converte um preço (InputPrice) informado em dólares, para um preço (OutputPrice) especificado em outra moeda (OutputCurrency).
InputPrice e BookPrice possuem os mesmos valores semânticos na OWL-S. Para fazer essa definição usando JSHOP2 é necessário utilizar os axiomas., que modela a semântica dos tipos de dados OWL-S envolvidos na troca de mensagens, como apresentado na Figura 28.
;Axiomas (:- (InputPrice)
((BookPrice)))
Figura 28 – Exemplo de Uso de Axiomas em JSHOP2
O Apêndice A desse trabalho apresenta a definição do domínio, na Figura 29 é apresentado a definição do método usando a estrutura if-then-else para decompor os operadores. Na Figura 30 encontra-se um exemplo da definição do problema para o domínio BookFinder.
(:method (CompositeProcess)
; testa se já alcançou o objetivo
((goal (OutputPrice)) (OutputPrice)) nil ((BookInfo)) ((!BNPriceProcess) (CompositeProcess)) ((InputPrice)(OutputCurrency)) ((!CurrencyConverterProcess) (CompositeProcess)) ((BookName)) ((!BookFinderProcess) (CompositeProcess)) )
Figura 29 – Exemplo de estrutura IF-then-else
(defproblem problem domain_generated (
; se passar um argumento tipo: (BookName SD)
; tem que obter BookName com parâmetro (BookName ?x) (BookName) (OutputCurrency) ) ( (achieve-goals ((OutputPrice))) ) )
Figura 30 – Exemplo do problema para o domínio BookFinder
seqüencial dos processos bookfinderprocess, bnpriceprocess e currencyconverterprocess com custo 3, assumindo que cada processo tem custo igual a 1. Na Figura 32 mostra-se a interface gráfica do JSHOP2 que permite acompanhar a execução do planejador em busca do plano.
[Plan cost: 3.0
(!!assert (goal (outputprice))) (!bookfinderprocess)
(!bnpriceprocess)
(!currencyconverterprocess) ---
]
Figura 31 – Solução do Cenário BookFinder
Figura 32 – Interface Gráfica do JSHOP2
Na Figura 34 acrescentou-se uma nova atividade denominada BookFinderID. Sendo assim, existe uma nova solução no espaço de estado. Para que o JSHOP2 localize todos os planos existentes no espaço de estados é necessário adicionar os
parâmetros (–ra) ao comando: java JSHOP2.InternalDomain -ra problem. Além da alteração do comando é necessário modificar o domínio, definindo o novo operador BookFinderID (Apêndice B) e recodificar o método como descrito na Figura 35. A Figura 33 mostra o resultado retornado pelo JSHOP2 com as duas soluções encontradas.
[Plan cost: 3.0
(!!assert (goal (outputprice))) (!bookfinderprocess)
(!bnpriceprocess)
(!currencyconverterprocess)] [Plan cost: 4.0
(!!assert (goal (outputprice))) (!bookfinderid)
(!bookfinderinfo) (!bnpriceprocess)
(!currencyconverterprocess)]
Figura 33 – Retorno do JSHOP2
(:method (BookNameAnother) ((BookName)) ((!BookFinderID) (CompositeProcess)) ) (:method (BookNameAnother) ((BookName)) ((!BookFinderProcess) (CompositeProcess)) ) (:method (CompositeProcess) ; testa se ja alcancou o objetivo ((goal (OutputPrice)) (OutputPrice)) nil ((BookInfo)) ((!BNPriceProcess) (CompositeProcess)) ((InputPrice)(OutputCurrency)) ((!CurrencyConverterProcess) (CompositeProcess)) ((BookName)) ((BookNameAnother) (CompositeProcess)) ((BookID)) ((!BookFinderINFO) (CompositeProcess)) )
Figura 35 – Alteração do domínio
3.3.1.3 USO DO JSHOP2 NA COMPOSIÇÃO DE SERVIÇOS WEB
O JSHOP2 não faz distinção entre precondições, com origem em entradas e saídas – inputs e outputs – de informações pelo usuário, e precondições e efeitos – preconditions e effects – com origem em regras do domínio. Todas as precondições e entradas descritas em OWL-S são representados como simples precondições – preconditions – em JSHOP2. Além disso, não distingue entre efeitos – outputs – que tem o objetivo de alimentar com informações o domínio e os efeitos – effects– que efetivamente alteram o domínio. Com relação a estrutura de controle dos métodos, o JSHOP2 suporta todas as estruturas definidas pela OWL-S com exceção das estruturas que definem a execução concorrente dos processos atômicos como o Split e Split + Join. (MURTAGH 2004).
Os planejadores SHOP2 planejam as tarefas na mesma ordem em que serão posteriormente executados. Essa característica permite conhecer o estado atual do
mundo em cada etapa do processo de planejamento, o que torna possível a avaliação de mecanismos para inferência, incluindo a capacidade para chamar programas externos Isto é apontando por SIRIN(2004) como relevante por permitir integrar o planejamento com informações externas como no ambiente web.
4 MAPEANDO E
Neste capítulo é apresentada a solução proposta destacando os principais objetivos deste trabalho referenciando a metodologia adotada. Na
análise e projeto do experimento prático desenvolvido para homologação da solução proposta e finalizando com a
O objetivo desse trabalho é desenvolver (Translate e Planner)-
descritos em OWL-S para o planej específicos foram identificados:
• Converter automaticamente a descrição semântica dos serviços para uma linguagem compreensível p
• Planejar a seqüência de execução dos serviços web encontrados no espaço de
• O sistema deverá manter
que esse possa ser alterado facilmente.
MAPEANDO E PLANEJANDO COM O TRANSPLAN
apresentada a solução proposta destacando os principais objetivos enciando a metodologia adotada. Na seqüência
experimento prático desenvolvido para homologação da solução proposta e finalizando com a avaliação dos resultados obtidos.
O objetivo desse trabalho é desenvolver uma ferramenta denominada TransPlan para o mapeamento e planejamento dos serviços web para o planejador JSHOP2. Assim, os seguintes objetiv específicos foram identificados:
Converter automaticamente a descrição semântica dos serviços para uma linguagem compreensível para o planejador JSHOP2;
Planejar a seqüência de execução dos serviços web exibindo encontrados no espaço de estado;
O sistema deverá manter-se desacoplado do planejador utilizado de modo que esse possa ser alterado facilmente.
Figura 36 – Macro fluxo do TransPlan
TRANSPLAN
apresentada a solução proposta destacando os principais objetivos seqüência, é descrita a experimento prático desenvolvido para homologação da solução
denominada TransPlan o mapeamento e planejamento dos serviços web os seguintes objetivos
Converter automaticamente a descrição semântica dos serviços para uma
exibindo todos os planos
A Figura 36 mostra o fluxo macro do TransPlan, em que a partir da descrição semântica dos serviços web em OWL-S, é gerado o plano, caso exista, que corresponde a seqüência de execução dos serviços web - web services - para alcançar um objetivo informado.
4.1 ANÁLISE E PROJETO
O objetivo desta seção é apresentar a solução proposta destacando os principais elementos da arquitetura e o modelo físico do TransPlan.
4.1.1 PROJETO ARQUITETURAL DO TRANSPLAN
Na engenharia de software a fase de projeto tem por objetivo a definição da arquitetura de um software, estrutura ou organização dos mais significativos componentes do sistema e suas interações. Para concepção da arquitetura do TransPlan foram tomadas as seguintes decisões:
Linguagem Java. Escolheu-se a linguagem Java por ser multiplataforma e
amplamente utilizada pela comunidade. O TransPlan contém aproximadamente 2200 linhas de código desenvolvido nesta linguagem..
Uso da linguagem OWL-S. Os serviços web semânticos são descritos na
linguagem OWL-S, uma recomendação da W3C, motivo pelo qual foi adotada no projeto. Outros motivos são encontrados na seção 2.2.1.
Planejador JSHOP2. Os planejadores SHOP foram testados numa grande
variedade de problemas, tendo mostrando-se suficientemente poderosos para conseguirem com os mais diversos cenários. Outros motivos são na seção 3.3.
Apesar dessa decisão, o TransPlan é flexível e permite a substituição do planejador para sua utilização em outros cenários, como por exemplo de não determinismo.
Figura 37 – Arquitetura de alto nível do TransPlan.
A Figura 37 contempla a arquitetura de alto nível da solução proposta, destacando os principais módulos lógicos, que são descritos a seguir.
Planner Plug-In– Esse componente é responsável por invocar o planejador
configurado no TransPlan, que no contexto desse trabalho, corresponde ao JSHOP2. Além disso, o TransPlan gera a partir da OWL-S o domínio e o problema para que o JSHOP2 possa iniciar o planejamento. A API Java Reflection foi utilizada para execução do JSHOP2.
OWL-S Reader – Esse componente é responsável por carregar uma OWL-S a partir
