UNIVERSIDADE FEDERAL DA BAHIA
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
MARCUS VINÍCIUS ALMEIDA SILVA
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
MARCUS VINÍCIUS ALMEIDA SILVA
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
4
A
Meus pais, Antoniel e Gilvanda, pelo seu amor e carinho, e a minha esposa, Vilmária
Silva.
AGRADECIMENTOS
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
RESUMO
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.
Palavras-chaves: composição de serviços Web, owl-s, planejador JSHOP2.
7
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.
Keywords: web services composition, owl-s, JSHOP2 planner.
LISTA DE ILUSTRAÇÕES
FIGURA 1 – CICLO DE VIDA DO WEB SERVICE. ........................................................... 14
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
FIGURA 48 – SOLUÇÃO DO TRANPLAN PARA O CENÁRIO RFQ ............................... 61
8
LISTA DE TABELAS
TABELA 1 CLASSES DO PACOTE MODEL. ...................................................................... 53
TABELA 2 CLASSES DO PACOTE JSHOP2. ...................................................................... 55
TABELA 3 AVALIAÇÃO DO TRANSPLAN ....................................................................... 61
TABELA 4 COMPARAÇÃO COM OS TRABALHOS CORRELATOS. ............................ 64
9
SUMÁRIO
INTRODUÇÃO
1.1
1.2
2
TRABALHOS CORRELATOS
ORGANIZAÇÃO DO TRABALHO
SERVIÇOS WEB
2.1 TECNOLOGIAS BÁSICAS
2.1.1 SIMPLE OBJECT ACCESS PROTOCOL (SOAP)
2.1.2 WEB SERVICES DESCRIPTION LANGUAGE (WSDL)
2.2 COMPOSIÇÃO DE SERVIÇOS WEB
2.2.1 ONTOLOGY WEB LANGUAGE FOR SERVICES (OWL-S)
2.3 AUTOMATIZANDO A COMPOSIÇÃO
3
PLANEJADORES DA INTELIGÊNCIA ARTIFICIAL
3.1 CONCEITOS BÁSICOS
3.1.1 ESTADO
3.1.2 PRECONDIÇÃO
3.1.3 EFEITO
3.1.4 AÇÃO
3.1.5 PLANO
3.1.6 AMBIENTE
3.1.7 REPLANEJAMENTO
3.2 TIPOS DE PLANEJAMENTO
3.2.1 PLANEJAMENTO COM BUSCA NO ESPAÇO DE ESTADOS
3.2.2 PLANEJAMENTO DE ORDEM PARCIAL
3.2.3 PLANEJAMENTO DE REDE HIERÁRQUICA DE TAREFA
3.3 JSHOP2
3.3.1 EXEMPLOS DE UTILIZAÇÃO
4
10
11
12
13
15
15
18
19
21
28
29
29
29
29
30
30
30
30
31
31
32
35
36
38
39
MAPEANDO E PLANEJANDO COM O TRANSPLAN
49
4.1 ANÁLISE E PROJETO
4.1.1 PROJETO ARQUITETURAL DO TRANSPLAN
4.1.2 PROJETO ARQUITETURAL DE BAIXO NÍVEL
4.1.3 UTILIZAÇÃO DO TRANSPLAN
4.2 EXPERIMENTOS
4.2.1 CONCORRÊNCIA PÚBLICA
4.3 AVALIAÇÃO DOS RESULTADOS
50
50
52
56
58
58
61
CONCLUSÃO
65
REFERÊNCIAS
67
APÊNDICE A –BOOKFINDER EM JSHOP2
70
APÊNDICE B –BOOKFINDER EM JSHOP2 COM DOIS PLANOS
72
ANEXO A - MUNDO DOS CUBOS EM JSHOP2
75
10
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
11
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
12
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 destinase as considerações obtidas sobre o trabalho e são apresentadas possibilidades de
melhorias e ampliações em trabalhos futuros.
13
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
14
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).
15
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.
16
Figura 3 – Estrutura do Envelope
Fonte: Adaptado de Coulouris, 2005.
A mensagem SOAP é transportada em um envelope,
envelope Figura 3, que possui um
cabeçalho, facultativo, um corpo que contém as informações principais das
requisições
isições e respostas aos métodos. Na Figura 4 observa-se
se a presença
prese
de um
elemento opcional Fault, responsável por provê informações sobre falhas ocorridas
(GRAHAM et al., 2004).
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soapxmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap encoding">
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Header>
[...]
</soap:Header>
<soap:Body>
[...]
<soap:Fault>
[...]
</soap:Fault>
</soap:Body>
</soap:Envelope>
Figura 4 - Estrutura de uma mensagem SOAP.
SOAP
Fonte: W3SCHOOLS, 2007
A Figura 5 e a Figura 6 mostram exemplos de mensagens SOAP de requisição e
resposta respectivamente ao serviço GetStockPrice –obter
obter preço no estoque usando o protocolo HTTP. A mensagem de requisição possui o parâmetro
StockName -nome
nome do estoque - e a mensagem response retornará o Price através
17
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
18
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
<portType>
<message>
<types>
<binding>
Definição
Define as operações disponível no serviço
Define as mensagens utilizadas pelo serviço
Define os tipos de dados utilizados pelo serviço
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
19
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
20
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
21
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
22
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,
23
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
A classe ServiceProfile descreve o que o serviço faz, de maneira que ele possa ser
24
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.
25
<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
26
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
27
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/OWLS/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 OWLS para WSDL: classes, inputs e outputs, processos atômicos.
Figura 17 – Mapeamento de ServiceModel para WSDL
Fonte: W3C, 2007
28
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.
29
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
um estado, para que uma determinada ação possa ser executada (RUSSELL et. al.,
30
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
determinado pelo estado atual e pela ação executada, então o ambiente é
31
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
32
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
33
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.
A solução proposta por RUSSELL et. al. (2004), propõe a definição do literal de
34
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.
35
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.
36
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:
37
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 é
38
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
39
lista de literais que serão excluídos da base de conhecimento. A (add list)
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,
cujo valor padrão é 1 (ILGHAMI,
ILGHAMI, 2006).
2006)
Figura 21 - Macro-fluxo do JSHOP
Os métodos são atividades compostas que definem como decompor o plano em
busca de tarefas primitivas
mitivas (operadores). Um método no JSHOP2 é definido pela
sintaxe (:method h [[D] P T]+)
T]+ em que h é o cabeçalho contendo o nome do método,
e P (precondition)) contém a lista de literais para que as tarefas em T sejam
executadas. T pode conter métodos e operadores,
operadores e estes serão executados na
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 Swap (troca
40
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.
41
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: MultiStep e Single 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.
42
Figura 25 – Ambiente gráfico do JSHOP2
Figura 26 – Plano SWAP
43
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.
apresenta
a
solução
composta
por
três
serviços
A Figura 27
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).
Figura 27 – Solução do Cenário BookFinder
44
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
A Figura 31 apresenta o plano retornado pelo JSHOP2 que corresponde a execução
45
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
46
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
Figura 34 – Nova atividade acrescentada ao plano
47
(: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
48
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.
49
4 MAPEANDO E PLANEJANDO COM O TRANSPLAN
Neste capítulo é apresentada a solução proposta destacando os principais objetivos
deste trabalho referenciando
enciando a metodologia adotada. Na seqüência,
seqüência é descrita a
análise e projeto do 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
(Translate e Planner)- para o mapeamento e planejamento dos serviços web
descritos em OWL-S para o planejador
planej
JSHOP2. Assim, os seguintes objetivos
objetiv
específicos foram identificados:
•
Converter automaticamente a descrição semântica dos serviços para uma
linguagem compreensível para
p
o planejador JSHOP2;
•
Planejar a seqüência de execução dos serviços web exibindo todos os planos
encontrados no espaço de estado;
•
O sistema deverá manter-se
manter se desacoplado do planejador utilizado de modo
que esse possa ser alterado facilmente.
Figura 36 – Macro fluxo do TransPlan
50
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.
51
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
de sua URI. A OWL-S API utilizada na solução é a disponibilizada pela Maryland
52
Information and Network Dynamics Lab Semantic Web Agents Project (MINDSWAP)
cujo desenvolvimento é liderado por Sirin.
Sirin. O objetivo dessa API é fornecer um
conjunto de abstrações para manipulação de OWL-S,, utilizando como base o
framework Jena - API Java para manipulação de ontologias.
4.1.2 PROJETO ARQUITETURAL DE BAIXO NÍVEL
Nessa seção é descrito o projeto de baixo nível (modelo físico) adequado ao projeto
arquitetural do TransPlan.
TransPlan Dessa forma serão apresentados os módulos e classes
mais importantes do sistema, suas responsabilidades e relacionamentos.
A Figura 38 apresenta o diagrama de dependência em um nível maior de abstração
com o objetivo de mostrar as dependências
dependências entre os subsistemas do TransPlan.
Figura 38 – Diagrama de dependência de módulos.
A seguir, são detalhadas as principais classes pertencentes
pertencentes aos módulos da Figura
38.. Estas classes estão agrupadas de acordo com suas funcionalidades
funcionalidade levando em
53
consideração a coesão e o acoplamento entre os módulos.
gui: esse subsistema encapsula a camada de apresentação do sistema.
sistema A principal
classe que compõe esse pacote é TransPlanGUI.. Essa classe é uma subclasse da
classe JFrame da API Swing do Java, responsável por apresentar uma janela para
interação com o usuário.
model: esse pacote encapsula as classes que fazem parte do domínio da aplicação.
aplicaç
A Figura 39 apresenta as classes e seus relacionamentos, e a Tabela 1 apresenta a
descrição de cada classe do subsistema.
Figura 39 – Diagrama do pacote model.
Tabela 1
Classes do pacote model.
Classe
Descrição
54
TransPlan.model.Process
br.ufba.lasid.easd.wsc.TransPlan
Classe que representa um Process
OWL-S.
br.ufba.lasid.easd.wsc.TransPlan
TransPlan.model.CompositeProces
s
Classe que herda da classe Process e
representa um CompositeProcess da
OWL-S.
br.ufba.lasid.easd.wsc.TransPlan
TransPlan.model.AtomicProcess
Classe que herda da classe Process e
representa um processo atômico da
OWL-S
br.ufba.lasid.easd.wsc.TransPlan
TransPlan.model.Literal
Classe que representa
Proposicional
br.ufba.lasid.easd.wsc.TransPlan
TransPlan.model.State
br.ufba.lasid.easd.wsc.TransPlan
TransPlan.model.Plan
um
Literal
Classe que encapsula o estado definido
a partir de um conjunto de literais
Classe que encapsula o Plano gerado,
que possui a solução encontrada e o
custo do plano.
service: esse subsistema corresponde a camada de aplicação do TransPlan. A sua
principal classe é TransPlanService,
TransPlan
, através dela é possível acessar as
funcionalidades da aplicação. Como pode ser visualizado na Figura 40 existe uma
dependência desse pacote com o pacote owls, que encapsula a manipulação de
arquivos OWL-S.
Figura 40 – Diagrama do pacote service.
planner: A Figura 41 apresenta o diagrama das principais classes pertencentes
pertencent ao
gerenciador de eventos. A classe destacada (Planner) representa o ponto de
extensão do TransPlan,, portanto, o desenvolvedor pode estender e personalizar.
personalizar
Ressalta-se
se a existência do subsistema jshop2 que contém as classes específicas
espec
55
para o planejador JSHOP2,
JSHOP2 cada qual implementa o método write que encapsula o
elemento para a linguagem JSHOP2.
JSHOP2 Para o uso de tipos semânticos a classe
Domain lê a definição da hierarquia dos tipos semânticos mapeados para axiomas
em JSHOP2 e adicioná-los
adicioná
ao domínio gerado. As classes desse pacote estão
descritas na Tabela 2.
Tabela 2
Classes do pacote jshop2.
Classe
br.ufba.lasid.easd.wsc.TransPlan
TransPlan.planner.jshop2.Domain
Descrição
Classe que representa um Domínio em
JSHOP2.
br.ufba.lasid.easd.wsc.TransPlan
TransPlan.planner.jshop2.
JSHOP2Planner
Classe que herda da classe Planner e
encapsula a execução do planejador
JSHOP2.
br.ufba.lasid.easd.wsc.TransPlan
TransPlan.planner.jshop2. Method
Classe abstrata que representa um
método genérico em JSHOP2
br.ufba.lasid.easd.wsc.TransPlan
TransPlan.planner.jshop2.
MethodIfThenElse
Classe que encapsula a um método IfIf
Then-Else
Else do JSHOP2
Classe que representa um Operador em
br.ufba.lasid.easd.wsc.TransPlan
TransPlan.planner.jshop2. Operator JSHOP2
br.ufba.lasid.easd.wsc.TransPlan
TransPlan.planner.jshop2. Problem
Classe que encapsula o a definição do
problema em JSHOP2
Figura 41 – Diagrama de dependência de módulos
56
A Figura 42 apresenta um dos algoritmos implementados no TransPlan. O algoritmo
exibido converte um arquivo em OWL-S para JSHOP2. A implementação do
algoritmo levou em consideração que 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. Entretanto, para que o algoritmo não se limitasse a ler
precondições e efeitos em OWL-S, foi acrescentado uma rotina que permitir mapear
inputs para precondições e outputs para efeitos, caso não existam precondições e
efeitos na OWL-S.
Entrada: uma definição OWL-S de um processo atômico (A)
Saída: um operador JSHOP2 (O)
1. Para cada pré-condição (p) em A
1.1. Adicionar p como uma pré-condição em (O)
Pre := Pre U { p }
1.2. Adicionar p como um efeito negativo em (O)
Del := Del U { p }
2. Se a lista de precondição for vazia (Se Pre == { })
2.1. Para cada entrada(i) em A
2.1.1.Adicionar (i) como uma pré-condição em (O)
Pre := Pre U { i }
2.1.2.Adicionar (i) como um efeito negativo em (O)
Del := Del U { i }
3. Para cada efeito (e) em A
3.1. Adicionar (e) como um efeito positivo em (O)
Add := Add U { e }
4. Se a lista de efeitos (Add) for vazia (Se Add == { })
4.1. Para cada output(o) em A
4.1.1.Adicionar (o) como uma efeito em (O)
Add := Add U { o }
5. Retornar (:O Pre Del Add)
Figura 42 - Converter processos atômicos para operadores
4.1.3 UTILIZAÇÃO DO TRANSPLAN
Com o objetivo de esclarecer o funcionamento da solução implementada, nesta
seção são apresentadas as formas pela qual o TransPlan poderá ser utilizado:
diretamente (pelo usuário) ou como uma API (para outra aplicação).
57
A Figura 43 exibe a tela principal do TransPlan quando executado por um usuário.
Através dessa tela é possível carregar uma OWL-S, definir o estado inicial e o
objetivo, bem como executar o planejador configurado.
.
Figura 43 – Tela Principal do TransPlan
A API pública do TransPlan permite que outras aplicações acessem-na e tenham
acesso as funcionalidades encapsuladas. Além disso, é possível personalizar o
TransPlan para utilizar um novo planejador. Para tal, como observado na Figura 44,
é necessário criar uma nova classe que herde a classe abstrata Planner e
implementar o método abstrato execute. Em seguida é necessário apontar a classe
criada no arquivo de configuração do TransPlan (Figura 45).
58
Figura 44 – Customizando o TransPlan
# arquivo de configuração
PLANNER_CLASS=br.ufba.lasid.easd.wsc.TransPlan.planner.jshop2.JSHOP2Planner
Figura 45 – Arquivo de configuração do TransPlan
4.2 EXPERIMENTOS
Com o intuito de validar a solução , foram realizados dois experimentos cada um
utilizando um cenário distinto: busca e conversão de preço de livros (BookFinder)
apresentado na seção 3.3.1.2; Concorrência Pública (Request For Quotes - RFQ).
Esse último cenário foi proposto por Claro (2008) e utilizado para validação da
solução proposta.
4.2.1 CONCORRÊNCIA PÚBLICA
O processo de concorrência pública para restauração de prédios públicos começa
com uma abertura de uma licitação. Um arquiteto com um funcionário do governo
59
planeja o que será executado.
O escopo proposto para validação em Claro(2008) foca a atividade de construção de
escada, creationEscalier, que poderá ser de madeira e concreto ou ferro e concreto.
A Figura 46 mostra os serviços envolvidos no processo de construção de escada, a
seguir a descrição de cada um deles:
EscalierBetonBois – escada de concreto e madeira – escada de concreto e madeira:
serviço responsável por criar um escada de madeira. Esse serviço tem como précondição os literais fornecerConcreto - fournitureBeton - e fornecerMadeira –
fournitureBois - e possui como efeito a escada criada - creationEscalier;
EscalierBetonENT2 – escada de concreto e ferro: serviço responsável por criar um
escada de Ferro. Esse serviço tem como pré-condição o literais fornecerConcreto –
fournitureBeton- e fornecerFerro – fournitureFer - e possui como efeito a escada creationEscalier;
fournitureFer: serviço responsável pelo fornecimento de ferro - fer. Tem como précondição a ausência de ferro - not_fournitureFer - e tem como efeito o fornecimento
de ferro - fournitureFer;
fournitureBeton: serviço responsável pelo fornecimento de concreto - beton. Tem
como pré-condição a ausência de concreto
- not_fournitureBeton - e tem como
efeito o fornecimento de concreto - fournitureBeton;
fournitureBois: serviço responsável pelo fornecimento de madeira (Bois). Tem como
pré-condição a ausência de madeira - not_ fournitureBois e tem como efeito o
fornecimento de madeira - fournitureBois.
60
Figura 46 – Cenário para criação de escadas
Para efeito de validação foram realizados os seguintes casos de testes:
Carregar ontologias OWL-S.
OWL
testar
estar o módulo que manipula ontologias OWL-S,
validando o recurso de cache. O sistema deverá carregar as ontologias com
sucesso.
Localizar o plano
lano para o cenário busca de livros:
livros localizar
ocalizar o plano para o cenário
de busca de livros fornecendo um estado inicial e objetivo válidos. O sistema deverá
encontrar o plano exibido na Figura 47.
61
Plan cost: 3.0
(bookfinderprocess)
(bnpriceprocess)
(currencyconverterprocess)
Figura 47 – Solução do TranPlan para o Cenário BookPrice
Localizar planos para o cenário de concorrência pública: Localizar os planos
para o cenário de concorrência pública fornecendo um estado inicial e objetivo
válidos. O sistema deverá encontrar o plano exibido na Figura 48.
Plan 01 cost: 4.0
(fournitureferatomicprocess)
(fournitureboisatomicprocess)
(fourniturebetonatomicprocess)
(escalierbetonatomicprocess)
Plan 02, cost: 4.0
(fournitureferatomicprocess)
(fournitureboisatomicprocess)
(fourniturebetonatomicprocess)
(escalierbetonent2atomicprocess)
Figura 48 – Solução do TranPlan para o Cenário RFQ
Localizar plano informando estado inicial e estado objetivo inválidos: tentar
localizar um plano para os cenários de testes sem informar os estados iniciais e
objetivo. O sistema não deve encontrar um plano.
4.3 AVALIAÇÃO DOS RESULTADOS
Para avaliação dos resultados obtidos neste trabalho, a solução TransPlan foi
submetida ao ambiente descrito na seção 4.2. A tabela 6 exibe os resultados da
avaliação da ferramenta. Nota-se que o TransPlan alcançou resultados satisfatórios
na avaliação em que foi submetido.
Casos de Testes
1. Carregar ontologias OWL-S
Tabela 3
Avaliação do TransPlan
Resultado
COMENTARIOS
Executado
sucesso
com Foram realizados testes com e sem o
recurso de cache.
62
2. Localizar plano para
cenário busca de livros
o Executado
sucesso
3. Localizar planos para o
cenário de concorrência pública
4. Localizar plano informando
estado inicial e estado objetivo
inválidos
com O plano foi
satisfatório
localizado
em
tempo
Executado
sucesso
com os planos foram localizados em tempo
satisfatório
Executado
sucesso
com
O planejador não encontrou o plano
Outra critério utilizado para avaliação dos resultados foi um comparativo com os
trabalhos correlatos citados na seção 1.1: OWL2JSHOP proposto por Murtagh
(2004) e JSHOPTranslator disponível em Mindswap (2004) e apresentado em
Sirin(2004). A Tabela 4 mostra as características atendidas por cada solução. A
seguir, são descritas as características mencionadas na Tabela 4.
1. Suporte a planejador genérico. Essa característica oferece a solução o
desacoplamento e independência do planejador utilizado. Como não existe um
consenso com relação ao planejador ideal a composição de serviços web torna-se
relevante essa qualidade.
2. Reutilização. A solução permite ser utilizada por outras aplicações, permitindo o
desenvolvimento mais eficiente. Ressaltando que o reuso não se limita a apenas
código, mas também aos requisitos, especificações, projetos, testes, e todos os
outros elementos produzidos durante as fases de desenvolvimento. Dessa forma,
permite ao desenvolvedor concentrar-se naquilo que é particular à aplicação.
3. Abstração no Planejamento. Abstrair do usuário o conhecimento da linguagem
utilizada pelo planejador, permitindo que em posse das descrições semânticas do
serviços, associado ao estado inicial e final seja possível localizar as soluções
disponíveis automaticamente, sem a intervenção do usuário.
63
4. Geração automática de método para decomposição. A geração automática do
método para decomposição em busca do plano permite que somente seja
necessário carregar os processos atômicos da OWL-S. O TransPlan atende
parcialmente esse requisito pois limita-se a utilizar a estrutura IF-Then-Else,
sugerindo-se como trabalho futuro a implementação das demais estruturas
suportadas pelo JSHOP2.
5. Localização de todos os planos. A localização de todos os planos disponíveis
no espaço de estado é relevante, pois em posse de todos os planos é o possível
identificar a melhor solução e traçar caminhos alternativos em caso de falhas na
solução escolhida.
6. Definição Semântica automática. Essa característica permite converter os tipos
semânticos, definidos em OWL-S, automaticamente para a linguagem utilizada pelo
planejador. No JSHOP eles são definidos com axiomas. No TransPlan essa
característica foi contemplada parcialmente, pois é necessária a intervenção do
usuário.
7. Etapas da composição. As fases da composição incluem descoberta,
planejamento e execução apresentados na seção 2.2. O TransPlan limita-se a fase
de planejamento, sugerindo-se como trabalho futuro as demais etapas.
8. Uso de IOPE. O conjunto entrada (I), saída (O), precondição (P) e efeito (E)
deverá ser utilizada pelo planejador para encontrar a solução.
9. Uso de Cache das OWL-S. Por serem disponibilizadas no ambiente internet fazse necessário a utilização de cache local das OWL-S, oferecendo assim um menor
tempo de resposta para tal funcionalidade.
64
9. Compatibilidade com o JSHOP2. O JSHOP2 é uma versão que apresenta
vantagens sobre outras versões, como o SHOP, SHOP2 e JSHOP como
apresentado na seção 3.3.
CARACTERÍSTICAS
Tabela 4
Comparação com os trabalhos correlatos.
OWL2JSHOP
TRANSPLAN
JSHOPTranslator
1. Suporte a planejador genérico
Atende
Não atende
Não atende
2. Reutilização
Atende
Não Atende
Atende
3. Abstração no Planejamento
Atende
Não mencionado
Parcialmente
4. Geração automática de método para
decomposição
Parcialmente. Não Atende. Lê
Utiliza IFdefinição em
then-else
OWL-S
Não Atende. Lê
definição em OWLS
5. Localização de todos os planos
Atende
Não mencionado
Não mencionado
6. Definição Semântica automática
Parcialmente
Atende
Atende
7. Etapas da composição
Parcialmente.
Parcialmente.
Parcialmente.Apen Apenas
Apenas
as planejamento.
planejamento e
Planejamento
execução
8. Uso de IOPE
Atende
9. Uso de Cache das OWL-S
Atende. A API
utilizada já
Não Atende
implementa
Atende
10. Compatibilidade com o JSHOP2
Atende
Não Atende
Parcialmente.
Apenas I/O
Não Atende
Parcialmente
Apenas I/O
Assim, de acordo com a avaliação do experimento, o TransPlan se mostra adequado
para realizar o mapeamento e o planejamento dos serviços web semânticos.
65
CONCLUSÃO
Este trabalho propôs uma solução para o mapeamento e planejamento de serviços
web semânticos descritos em OWL-S usando o planejador JSHOP2.
As avaliações às quais foi submetido o TransPlan evidenciam resultados
satisfatórios. Observa-se que, a partir da análise dos resultados obtidos da seção
4.3, os testes em que foi submetido o TransPlan foram executados com sucesso.
Além disso atendeu-se boa parte dos critérios utilizados para a avaliação da
ferramenta. Dentre as características do TransPlan, destacam-se as seguintes
vantagens em relação aos trabalhos correlatos.
Flexibilidade e reutilização: para adoção dessa ferramenta, poderá ser configurado
um novo planejador para o TransPlan.
Geração automática de método para decomposição: é possível com a ferramenta
a geração automática de métodos com estrutura de controle IF-then-Else para definir
a decomposição do problema.
Abstração no Planejamento: é possível que um usuário ou uma aplicação utilize a
solução sem necessitar conhecer a linguagem do planejador.
Ao mesmo tempo, foi identificada a existência de oportunidades de melhorias e
acréscimo de novas funcionalidades não contempladas no escopo desse trabalho.
Como trabalho futuro sugere-se a integração com outras ferramentas, um vez que
para execução de todas as atividades da composição automática de serviços web
torna-se necessário a utilização de outras ferramentas que contemplem as demais
atividades desse processo. Dessa forma, é relevante integrar o TransPlan às
66
ferramentas já existentes que contemplem as demais atividades na composição
automática de serviços web. Uma outra oportunidade de melhoria envolve converter
os planos encontrados para OWL-S e converter tipos semânticos automaticamente.
E por fim, disponibilizar o TransPlan como um serviço web.
67
REFERÊNCIAS
CALHAU, Fábio D. J. Composição de Serviços por Planeamento.
2006.167f.Dissertação (Mestrado Engenharia Informática e Telecomunicações) –
Instituto Superior de Ciências do Trabalho e da Empresa. Salvador, 2006.
CLARO D. B., MACEDO R. J. A. Dependable Web Service Compositions using a
Semantic Replication Scheme. In Anais do XXVI Simpósio Brasileiro de Redes de
Computadores e Sistemas Distribuídos (SBRC 2008). Rio de Janeiro, RJ, Brasil,
Maio 2008.
CLARO D.B., ALBERS P.; HAO J-K. A Framework for Automatic Composition of
RFQ Web Services. In IEEE Proceedings of the First Workshop on Web Service
Composition and Adaptation (WSCA) held in conjunction with International
Conference of Web Services (ICWS'07) IEEE SCW 2007. Salt Lake City, Utah, USA
p. 221-228, 2007.
COULORIS, G., Dollimore, J., Kindberg, T.. Distributed Systems concepts and
Design. Addison Wesley, 4º Edição, 2005. ISBN 0321263545.
CARVALHO, L. LIMA, César. Ontologias - OWL (Web Ontology Language).
Technical Report - RT-INF_004-05 - Relatório Técnico- 2005 – Junho. UFG - Instituto
de Informática Universidade Federal de Goiás. Goias, 2005.
DUSTDAR, Schahram; SCHREINER, Wolfgang. A survey on web services
composition. Int. Web and Grid Services, [S.l. : s. n.], v. 1, n 1, p.1-30, 2005.
DIGIAMPIETRI, Luciano A; ALCÁZAR, J. J. Pérez; MEDEIROS, C. B.AI Planning in
Web Services Composition: a review of current approaches and a new
solution. VI ENIA – Encontro Nacional de Inteligência Artificial. Rio de Janeiro,
2007.
GHALLAB, M.; Traverso, Paolo; NAU, Dana. Automated Planning: Theory and
Practice, Morgan Kaufmann, 2004. ELSEVIER. ISBN: 1-55860-856-7.
GRAHAM, Steve; DAVIS, Doug;, SIMEONOV, Simeon; DANIELS, Glen;
BRITTENHAM, Peter; NAKAMURA, Yuichi; FREMANTLE, Paul; KOENIG, Dieter;
ZENTNER, Claudia. Building Web Services with Java: Making Sense of XML,
SOAP, WSDL, and UDDI. 2004. SAMS. ISBN 0-6723-2641-8.
ILGHAMI, Okhtay. Documentation for JSHOP2. Department of Computer Science –
University
of
Maryland,
USA,
2006.
Disponível
em:
<http://www.cs.umd.edu/~okhtay/jshop2doc.pdf>. Acessado em: 09 maio 2008.
LOPES, C. J.F.; RAMALHO, J. C. Web Services: Metodologias de
Desenvolvimento. XML, Aplicações e Tecnologias Relacionadas – XATA, Porto,
Portugal. 2004.
MACHADO, João Coutinho. Um estudo sobre o desenvolvimento orientado a
serviços. 2004. Dissertação (Mestrado) — PUC-Rio, Rio de Janeiro, 2004.
68
Disponível
em:
<
http://www2.dbd.pucrio.br/pergamum/tesesabertas/0210486_04_pretextual.pdf >. Acesso em: 15 mai.
2006.
MARTIN, David. OWL-S: Semantic markup for web services; W3C Member
Submission, 2004a. Disponível em: <http://www.w3.org/Submission/2004/SUBMOWL-S-20041122>, Acesso em: 5 Jun. 2006.
MARTIN, David et al. Bringing Semantics to Web Services: The OWL-S
Approach. In: First International Workshop on Semantic Web Services and Web
Process Composition – SWSWPC, San Diego, CA, USA, 2004b.
MINDSWAP: Maryland Information and Network Dynamics Lab Semantic Web
Agents Project. 2004. Disponível em: <http://www.mindswap.org/2004/owl-s/
services.shtml>. Acesso em: 05 junho. 2008.
MURTAGH, Dónal. Automated Web Service Composition. University of Dublin.
2004
Disponível
em:
<https://www.cs.tcd.ie/publications/tech-reports/trindex.05.php>. Acesso em: 15 out 2007
PAUTASSO, Cesare. SOAP vs. REST - Bringing the Web back into Web
Services. Business Integration Technologies. IBM Zurich Research Lab. 2007
Disponível em <http://www.iks.inf.ethz.ch/education/ss07/ws_soa/slides/SOAPvs
REST_ETH.pdf> Acesso em: 2 set. 2008
PEER, J.; Web Service Composition as AI Planning - a Survey; Technical Report,
2005; Univ. of St.Gallen, Switzerland, Suiça. 2005 .
RAO, J.; SU, X.; 2004; A Survey of Automated Web Service Composition
Methods; Proceedings of the First International Workshop on Semantic Web
Services and Web Process. 2004. Disponível em <http://www.cs.cmu.edu/~
jinghai/papers/survey_rao.pdf>. Acesso em: 08 jan 2008
RUSSELL, Stuart J.; NORVIG, Peter. Inteligência Artificial. 2. ed. Tradução de
PubliCare Consultoria. 2004, ISBN 85-352-1177-2.
SIRIN, E.; Parsia, B.; Wu, D; Hendler, J.; and Nau,D.; 2004; HTN Planning for Web
Service Composition Using SHOP2; Journal of Web Semantics 2004
SMITH, M. K; WELTY, C; MCGUINNESS, D. L. OWL Web Ontology Language
Guide.2004.
Disponível
em
<http://www.w3.org/TR/2004/REC-owl-guide20040210/>. Acesso em: 21 abr 2008.
SRIVASTAVA, Biplav; et. al. Web Service Composition – Current Solutions and
Open Problems. ICAPS 2003. International Conference on Automated Planing and
Scheduling, June. Trento, Italia, 2003.
ILGHAMI, Okhtay, NAU, Dana.. A General Approach to Synthesize ProblemSpecific Planners. Technical Report CS-TR-4597 e UMIACS-TR-2004-40, 2003.
W3C. World Wide Web Consortium. OWL Web Ontology Language Guide. 2007.
Disponível em <http://www.w3.org/TR/owl-guide/>. Acessado em: Dezembro.
69
W3C: SOAP Specifications. 2007. Disponível em< http://www.w3.org/TR/soap/ >
Acesso em: 02 set 2008.
W3SCHOOLS:
SOAP
Tutorial.
2007.
Disponível
<http://www.w3schools.com/soap /default.asp>. Acesso em: 8 maio. 2008.
em
W3SCHOOLS:
em
WSDL
Documents.
2007.
Disponível
<http://www.w3schools.com/wsdl/ wsdl_documents.asp>. Acesso em: 8 maio. 2008.
70
APÊNDICE A –BOOKFINDER EM JSHOP2
(defdomain domain_generated
(
(:operator (!BNPriceProcess)
(
(BookInfo)
)
(
(BookInfo)
)
(
(BookPrice)
)
)
(:operator (!BNPriceProcess)
(
(BookPrice)
)
(
(BookInfo)
)
(
(BookPrice)
)
)
(:operator (!CurrencyConverterProcess)
(
(InputPrice)
(OutputCurrency)
)
(
(InputPrice)
(OutputCurrency)
)
(
(OutputPrice)
)
)
(:operator (!BookFinderProcess)
(
(BookName)
)
(
(BookName)
)
(
(BookInfo)
)
)
)
;; O operador assert é definido com o objetivo de inserir informações ao
71
domínio
(:operator (!!assert ?g)
()
()
(?g)
;; Desde !!ASSERT não é um operador real, o custo deve ser 0
0)
;; Um conjunto de métodos é responsável por inserir uma lista de
objetivos, definidos na definição do problema (ver Figura 38),
;; como informações do domínio antes de chamar o método CompositeProcess
(:method (achieve-goals ?goals)
()
((assert-goals ?goals) (CompositeProcess)))
(:method (assert-goals (?goal . ?goals))
()
((!!assert (goal ?goal)) (assert-goals ?goals)))
(:method (assert-goals nil)
()
())
(:method (CompositeProcess)
; testa se ja alcancou o objetivo
((goal (OutputPrice)) (OutputPrice))
nil
((BookInfo))
((!BNPriceProcess) (CompositeProcess))
((InputPrice)(OutputCurrency))
((!CurrencyConverterProcess) (CompositeProcess))
((BookName))
((!BookFinderProcess) (CompositeProcess))
)
;Axiomas
(:- (InputPrice)
((BookPrice)))
)
)
72
APÊNDICE B –BOOKFINDER EM JSHOP2 COM DOIS
PLANOS
(defdomain domain_generated
(
(:operator (!BNPriceProcess)
(
(BookInfo)
)
(
(BookInfo)
)
(
(BookPrice)
)
(:operator (!BNPriceProcess)
(
(BookPrice)
)
(
(BookInfo)
)
(
(BookPrice)
)
)
(:operator (!CurrencyConverterProcess)
(
(InputPrice)
(OutputCurrency)
)
(
(InputPrice)
(OutputCurrency)
)
(
(OutputPrice)
)
)
(:operator (!BookFinderProcess)
(
(BookName)
)
(
(BookName)
)
(
(BookInfo)
)
)
(:operator (!BookFinderINFO)
(
(BookID)
)
(
(BookID)
73
)
(
(BookInfo)
)
)
(:operator (!BookFinderID)
(
(BookName)
)
(
(BookName)
)
(
(BookID)
)
)
;; O operador assert é definido com o objetivo de inserir
informações ao domínio
(:operator (!!assert ?g)
()
()
(?g)
;; Desde !!ASSERT não é um operador real, o custo deve ser 0
0)
;; Um conjunto de métodos é responsável por inserir uma lista de
objetivos, definidos na definição do problema (ver Figura 38),
;; como informações do domínio antes de chamar o método
CompositeProcess
(:method (achieve-goals ?goals)
()
((assert-goals ?goals)
(CompositeProcess)
)
)
(:method (assert-goals (?goal . ?goals))
()
((!!assert (goal ?goal))
(assert-goals ?goals))
)
(:method (assert-goals nil)
()
()
)
(: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))
74
((BookName))
((BookNameAnother) (CompositeProcess))
((BookID))
((!BookFinderINFO) (CompositeProcess))
)
;Axiomas
(:- (InputPrice)
((BookPrice)))
)
)
75
ANEXO A - MUNDO DOS CUBOS EM JSHOP2
(defdomain oldblocks
(
;; operadores
(:operator (!pickup ?a)
()
((clear ?a) (on-table ?a))
((holding ?a)))
(:operator (!putdown ?b)
()
((holding ?b))
((on-table ?b) (clear ?b)))
(:operator (!stack ?c ?d)
()
((holding ?c) (clear ?d))
((on ?c ?d) (clear ?c)))
(:operator (!unstack ?e ?f)
()
((clear ?e) (on ?e ?f))
((holding ?e) (clear ?f)))
;; metodos
(:operator (!!assert ?g)
()
()
?g
;; custo 0
(:method (achieve-goals ?goals)
()
((assert-goals ?goals nil) (move-block)))
(:method (assert-goals (?goal . ?goals) ?out)
()
((assert-goals ?goals ((goal ?goal) . ?out))))
(:method (assert-goals nil ?out)
()
((!!assert ?out)))
(:method (move-block)
;; method for moving x from y to z
((clear ?x) (not (nomove ?x)) (on ?x ?y)
(goal (on ?x ?z)) (not (same ?x ?z)) (clear ?z) (not (need-to-move
?z)))
((!unstack ?x ?y) (!stack ?x ?z) (!!assert ((nomove ?x))) (moveblock))
;; method for moving x from y to table
((clear ?x) (not (nomove ?x))
(on ?x ?y) (goal (on-table ?x)))
((!unstack ?x ?y) (!putdown ?x) (!!assert ((nomove ?x))) (moveblock))
;; method for moving x from table to y
((clear ?x) (not (nomove ?x))
(on-table ?x) (goal (on ?x ?y)) (clear ?y) (not (need-to-move ?y)))
((!pickup ?x) (!stack ?x ?y) (!!assert ((nomove ?x))) (move-block))
;; method for moving x out of the way
((clear ?x) (not (nomove ?x))
(on ?x ?y) (need-to-move ?x))
((!unstack ?x ?y) (!putdown ?x) (move-block))
;; if nothing else matches, then we're done
nil
nil)
;; Axiomas
(:- (same ?x ?x) nil)
76
(:- (need-to-move ?x)
;; need to move x if x needs to go from one block to another
((on ?x ?y) (goal (on ?x ?z)) (not (same ?y ?z)))
;; need to move x if x needs to go from table to block
((on-table ?x) (goal (on ?x ?z)))
;; need to move x if x needs to go from block to table
((on ?x ?y) (goal (on-table ?x)))
;; need to move x if x is on y and y needs to be clear
((on ?x ?y) (goal (clear ?y)))
;; need to move x if x is on z and something else needs to be on z
((on ?x ?z) (goal (on ?y ?z)) (not (same ?x ?y)))
;; need to move x if x is on something else that needs to be moved
((on ?x ?w) (need-to-move ?w)))
))