antónio luís morais costa da silva lopes dissertação submetida...

TT EECCNNOOLL OOGGII AA SS DDEE AA GGEENNTT EESS PPAA RRAA AA

EEXX EECCUUÇÇÃÃ OO SSEENNSSÍÍ VV EELL AA OO CCOONNTT EEXX TT OO DDEE

SSEERRVV II ÇÇOOSS NNAA WW EEBB SSEEMM ÂÂ NNTT II CCAA

António Luís Morais Costa da Silva Lopes

Dissertação submetida para a obtenção do grau de

MESTRE EM ENGENHARIA INFORMÁTICA E

TELECOMUNICAÇÕES

pelo

Instituto Superior das Ciências do Trabalho e da Empresa

Departamento de Ciências e Tecnologias de Informação

Orientador

Luís Miguel Pina Coelho Teixeira Botelho (ISCTE/DCTI)

Setembro de 2005

ii

Resumo

A presente tese insere-se na temática da execução de serviços em ambientes multi-

agente e na influência de informação de contexto sobre a mesma. O seu objectivo é a

definição e implementação de software reutilizável e de um agente de execução sensível

ao contexto de serviços descritos em OWL-S. Os seus principais contributos para avançar

o estado actual dos conhecimentos são (i) a execução de serviços de forma sensível ao

contexto; (ii) a extensão do OWL-S para permitir a especificação da interacção com

agentes prestadores de serviços; e (iii) a execução de serviços cuja descrição pode usar

quaisquer mecanismos de controlo de execução do OWL-S.

A extensão da ontologia de serviços OWL-S foi feita porque, originalmente, a

utilização do OWL-S implicava o uso de serviços na Web1 e não permitia a utilização de

agentes prestadores de serviços.

Criou-se um conjunto de componentes reutilizáveis de software para a execução de

serviços a partir do qual se definiu a arquitectura de um agente de execução sensível ao

contexto de serviços na Web Semântica. Usando os componentes de software criados e a

arquitectura definida implementou-se um agente que executa serviços descritos em

OWL-S, através da decomposição dos seus modelos processuais e contactando os

prestadores de serviços atómicos correspondentes, os quais poderão ser serviços na Web

ou agentes prestadores de serviços. O agente usa ainda informação de contexto para

optimizar o processo de execução de serviço.

A implementação do agente recorreu à integração e/ou extensão das seguintes

ferramentas: JADE, OWL-S API e XSP. O agente implementado foi testado num cenário

concreto de comércio electrónico de livros.

Palavras-chave: Execução de Serviços, Serviços na Web, Web Semântica, OWL-S,

Agentes, Sensibilidade ao Contexto.

1 Tradução de “Web Services”

iii

Abstract

This thesis is related to context-aware service execution in multi-agent environments.

Its main objective is to define and implement reusable components and an OWL-S

services execution agent. The main contributions of this thesis to the state of the art are:

(i) context-aware service execution; (ii) an OWL-S extension to enable the grounding

specification of agent-based service providers; and (iii) a service execution model that

covers all of the control constructs of the OWL-S language.

The OWL-S extension for enabling grounding specification of agent-based service

providers was made because originally OWL-S implied the use of Web Services only,

and did not allow the use of service provider agents.

A set of reusable software components for the execution of services was created,

from which the architecture for a semantic web services context-aware execution agent

was defined. Using the defined architecture and the created software components, a

context-aware service execution agent was developed. The developed agent executes

services through the decomposition of their OWL-S descriptions and the invocation of

the corresponding atomic service providers. The agent also uses context-aware

capabilities to optimize the execution process.

The implementation of the agent was done through the integration and/or the

extension of the following software tools: JADE, OWL-S API and XSP. The

implemented agent was tested on a concrete book e-commerce scenario.

Keywords: Services Execution, Web Services, Semantic Web, OWL-S, Agents,

Context-Awareness.

iv

Agradecimentos

Ao Luís Botelho, não só pela coordenação, orientação e entusiasmo na elaboração do

trabalho de investigação que deu origem a esta tese de mestrado, mas também pela

amizade e companheirismo que perduram ao longo dos anos em que trabalhamos juntos.

Aos colegas do projecto CASCOM pelo apoio, material, motivação e pelo tempo

disponibilizado para discussões que largamente contribuíram para o sucesso deste

trabalho: Fábio Calhau, Lino Pereira, Luís Mota, Paulo Costa, Pedro Pais e Tiago Santos.

Ao Bruno Gonçalves, pelo apoio e cedência do software Prolog Interface Module

para integração no trabalho desenvolvido.

À ADETTI no geral pelo apoio e meios materiais utilizados na tese e em particular à

Ana Rita, Fátima Estevens e Sónia Ferro, para quem o apoio aos colegas está sempre

primeiro.

À minha família, pelo apoio e compreensão nos momentos mais difíceis

À Vânia

v

Glossário

Agente - programa computacional, autónomo na prossecução dos seus objectivos, que comunica com outros agentes e reage a alterações no seu ambiente.

API – abreviatura de Application Program Interface, representa um conjunto de rotinas, protocolos e ferramentas que se podem usar na interacção com uma aplicação.

FIPA – abreviatura de Foundation for Intelligent Physical Agents, entidade promotora de especificações-padrão para o desenvolvimento de sistemas baseados em agentes.

GPS – abreviatura de Global Positioning System, é um sistema de satélites, computadores e receptores que possibilita a determinação da latitude e longitude de um determinado receptor no planeta Terra, calculando a diferença entre o tempo que leva a enviar sinais para esse receptor, vindos de vários satélites.

Hardware – um computador e o equipamento físico correspondente, directamente envolvido no processamento de dados e/ou funções de comunicação.

Internet – sistema interligado de redes que permite a conexão e comunicação entre computadores de todo o mundo.

ISBN – abreviatura de International Serial Book Number, representa o número de identificação unívoco de publicações literárias a nível mundial.

Middleware – software que serve de intermediário entre sistemas e/ou aplicações.

PDA – abreviatura de Personal Digital Assistant, é um dispositivo computacional de dimensões muito reduzidas, usado como organizador pessoal e para actividades de gestão com menor necessidade de processamento.

Software – programas, rotinas e linguagens simbólicas que controlam o funcionamento do hardware e gerem a sua operação.

Web – serviço da Internet que permite o acesso à World Wide Web (WWW).

Web Semântica – Colaboração conjunta de diversas entidades (sob a orientação do World Wide Web Consortium) que visa definir uma especificação-padrão das estruturas de dados na Web, para que a informação fornecida por esta possa ser processada por máquinas.

WWW – abreviatura de World Wide Web, representa o conjunto de documentos acessíveis a partir da Internet segundo um conjunto de protocolos definidos, que se encontram interligados num sistema de hiper-ligação.

vi

Índice

CAPÍTULO 1. I NTRODUÇÃO E M OTIVAÇÃO 1

1.1. Motivação 1

1.1.1. Enquadramento 2

1.1.1.1. Agentes e a execução de serviços 3

1.1.1.2. Ambientes dinâmicos e a Computação Sensível ao Contexto 5

1.1.2. Âmbito do trabalho 6

1.2. Estado actual dos conhecimentos e contribuições 7

1.3. Resultados e avaliação 8

1.3.1. Avaliação 9

1.4. Estrutura da tese 9

CAPÍTULO 2. ESTADO ACTUAL DOS CONHECIMENTOS 11

2.1. Estado actual, limitações e necessidades 11

2.1.1. Linguagens de descrição de serviços 11

2.1.1.1. OWL-S 12

2.1.1.2. WSMO 13

2.1.1.3. Limitações e necessidades 15

2.1.2. Ferramentas de desenvolvimento de Software com base em componentes 15

2.1.2.1. JavaBeans, Microsoft COM, .NET e CORBA 16

2.1.2.2. Jini 17

2.1.2.3. eXtended Service Platform 17


2.1.3. Tecnologias de Agentes 18

2.1.3.1. JADE e LEAP 19

vii

2.1.3.2. AgentBuilder e AgentAcademy 19

2.1.3.3. Zeus e APRIL 20


2.1.4. Execução de serviços na Web Semântica 21

2.1.5. Computação Sensível ao Contexto 23

2.2. Contribuições da tese 25

2.2.1. Contribuições ao nível da melhoria e divulgação de ferramentas 26

2.2.2. Contribuições para o avanço do estado actual dos conhecimentos 27

CAPÍTULO 3. CENÁRIO DE DEMONSTRAÇÃO 28

3.1. História do cenário 28

3.2. Descrição do cenário 30

3.2.1. Elementos comuns às duas versões do cenário 30

3.2.1.1. Elementos intervenientes 30

3.2.1.2. Interacções entre os elementos 32

3.2.2. Versão do cenário com serviços na Web 34


3.2.2.2. Execução do serviço composto 35

3.2.3. Versão do cenário com Agentes Prestadores de Serviços 36


3.2.3.2. Execução do serviço composto 37

CAPÍTULO 4. DEFINIÇÃO CONCEPTUAL DO SISTEMA 39

4.1. Análise de requisitos e desenho 39

4.1.1. Requisitos do cenário e análise informal 40

4.1.2. Desenho 42

4.1.2.1. Modelação de Actores – Agente Cliente 43

viii

4.1.2.2. Modelação de Actores – Agente de Execução de Serviços 44

4.1.2.3. Interacções entre os elementos 46

4.1.2.4. Utilização de informação de contexto 53

4.1.3. Lista de requisitos 55

4.2. Definição da arquitectura do Agente de Execução de Serviços 57

4.2.1. Descrição dos Componentes 57

4.2.1.1. Componente de Interacção com Agentes 57

4.2.1.2. Componente de Motor do Agente 58

4.2.1.3. Componente de Execução de Serviços 58

4.2.2. Interacção entre os componentes 60

CAPÍTULO 5. EXTENSÕES À ONTOLOGIA DE DESCRIÇÃO E

EXECUÇÃO DE SERVIÇOS 63

5.1. Ontologia de serviços OWL-S 63

5.1.1. Perfil do Serviço 64

5.1.2. Modelo Processual do Serviço 65

5.1.3. Instanciação do Serviço 66

5.2. Extensões ao OWL-S 66

5.2.1. Extensão AgentGrounding 66

5.2.2. Extensão para Expressões Condicionais 71

5.2.2.1. Expressões Condicionais em SWRL 72

5.2.2.2. Expressões Condicionais em Prolog 74

5.3. Considerações finais das contribuições 75

CAPÍTULO 6. I MPLEMENTAÇÃO 76

6.1. Entidades externas 76

6.1.1. Agente Pessoal 77

ix

6.1.2. Prestadores de Serviços 77

6.1.3. Agentes de Descoberta e Composição de Serviços 78

6.1.4. Plataforma Genérica de Informação de Contexto 79

6.2. Agente de Execução de Serviços 79

6.2.1. Tecnologias utilizadas 80

6.2.1.1. eXtended Service Platform 80

6.2.1.2. JADE 80

6.2.1.3. OWL-S API 81

6.2.2. Implementação dos componentes internos 81

6.2.2.1. Componente de Interacção com Agentes 82

6.2.2.2. Componente do Motor do Agente 84

6.2.2.3. Componente de Execução de Serviços 87

6.2.3. Interfaces e Interacções 88

6.2.3.1. Agente Pessoal 88

6.2.3.2. Agente de Descoberta de Serviços 93

6.2.3.3. Prestadores de Serviços 95

6.2.3.4. Plataforma Genérica de Informação de Contexto 97

6.3. Considerações finais da implementação 99

CAPÍTULO 7. AVALIAÇÃO 100

7.1. Critérios, testes e procedimentos 100

7.1.1. Utilidade e qualidade do Agente de Execução de Serviços 101

7.1.2. Flexibilidade, interoperabilidade e facilidade de utilização do agente 102

7.1.3. Abrangência e independência do domínio 103

7.1.4. Melhorias introduzidas pela Computação Sensível ao Contexto 104

7.1.5. Autonomia 105

7.1.6. Rapidez 106

7.2. Resultados e Avaliação 107

x

7.2.1. Utilidade e qualidade do agente de execução de serviços 107

7.2.2. Flexibilidade, interoperabilidade e facilidade de utilização do Agente 107

7.2.3. Abrangência e independência do domínio 108

7.2.4. Melhorias introduzidas pela Computação Sensível ao Contexto 109

7.2.5. Autonomia 111

7.2.6. Rapidez 112

7.3. Considerações finais de avaliação 122

CAPÍTULO 8. CONCLUSÕES E TRABALHO FUTURO 124

8.1. Continuidade do trabalho 126

Referências 128

Anexos 133

xi

Índice de Tabelas Tabela 1 - Descrição dos Casos de Utilização do Agente Cliente 44

Tabela 2 - Descrição dos Casos de Utilização do Agente Executor de Serviços 46

Tabela 3 - Descrição dos Casos de Utilização do AES sobre o Subsistema de Contexto 55

Tabela 4 - Detalhes do teste de execução do serviço "Book Table" - 2º teste 115

Tabela 5 - Detalhes do teste de execução do serviço "Book Price" - com serviços na Web 117

Tabela 6 - Requisito Execução de Serviços OWL-S 136

Tabela 7 - Requisito Execução de serviços com qualquer tipo de Fornecedores de Serviços 137

Tabela 8 - Requisito Execução de serviços recorrendo a Procura e Composição de Serviços 138

Tabela 9 - Requisito Execução de serviços com aprovação do Cliente 139

Tabela 10 - Requisito Execução de serviços com Informação de Contexto 140

Tabela 11 - Requisito Possibilidade de obtenção de contexto do cliente 141

Tabela 12 - Requisito Processamento de Informação de Contexto 142

Tabela 13 - Requisito Interface simples com o Agente Cliente 143

Tabela 14 - Requisito Rapidez da execução de serviços 144

Tabela 15 - Requisito Robustez, Disponibilidade e Escalabilidade da Execução de Serviços 145

Tabela 16 - Requisito Compatibilidade com as especificações da FIPA 146

xii

Índice de Figuras Figura 1 - Cenário com serviços na Web 36

Figura 2 - Cenário com Agentes Prestadores de Serviços 38

Figura 3 – Casos de Utilização do Actor Agente Cliente 43

Figura 4 – Casos de Utilização do Actor Agente Executor de Serviços 45

Figura 5 - Pedido de execução de serviço 47

Figura 6 - Pedido de execução de serviço com prestadores de serviços não especificados 49

Figura 7 - Pedido de execução de serviço com Prestadores de Serviços indisponíveis 51

Figura 8 - Dependências das funcionalidades 53

Figura 9 - Casos de Utilização - AES e Subsistema de Contexto 54

Figura 10 - Interacções entre os componentes internos do agente 60

Figura 11 - Infra-estrutura de serviços na Web Semântica 64

Figura 12 - Exemplo de especificação AgentGrounding 69

Figura 13 - Mensagem FIPA gerada a partir do AgentGrounding 70

Figura 14 - Exemplo de Expressão Condicional em SWRL 73

Figura 15 - Exemplo de Expressão Condicional em Prolog 74

Figura 16 - Funcionamento interno do Componente de Interacção com Agentes 82

Figura 17 - Funcionamento interno do Componente Motor do Agente 85

Figura 18 - Mensagem Request de pedido de execução de serviço 89

Figura 19 - Mensagem Agree do AES para o AP 91

Figura 20 - Mensagem Inform com o resultado da execução 93

Figura 21 - Mensagem Request de pedido de procura de prestador de serviço alternativo 94

Figura 22 - Mensagem Inform com o resultado da pesquisa de prestadores alternativos 95

Figura 23 - Mensagem Inform de resposta ao pedido do AgentGrounding 96

Figura 24 - Execução do Serviço "Book Price" usando Agentes como Fornecedores de Serviços 112

Figura 25 - Overhead de execução do serviço "Book Price" 114

Figura 26 - Execução do Serviço "Book Price" - 2º teste 114

Figura 27 - Overhead de execução do serviço "Book Price" – 2º teste 115

Figura 28 - Execução do serviço "Book Price" usando serviços na Web como prestadores de serviços 117

Figura 29 - Execução detalhada do serviço composto "Book Price" 118

Figura 30 - Execução do serviço "Book Price" – expressões condicionais em Prolog 120

Figura 31 - Execução detalhada do serviço composto "Book Price" – com Prolog 120

Figura 32 - Teste de execução de expressões condicionadas em Prolog 121

Figura 33 - Protocolo de interacção FIPA-Request 147

Figura 34 - Protocolo de interacção FIPA-Query 149

1

CCaappííttuulloo 11.. II NNTTRROODDUUÇÇÃÃOO EE

MM OOTTII VVAAÇÇÃÃOO

Neste capítulo inicial procura-se, de forma breve, apresentar a essência deste trabalho

de investigação, enquadrando-o com as áreas relacionadas e descrevendo o âmbito em

que este foi desenvolvido. É feita uma breve descrição da abordagem escolhida e das

principais contribuições do trabalho da tese, assim como uma apresentação resumida do

estado actual dos conhecimentos nas áreas de trabalho relacionado. O capítulo introduz

também a metodologia de avaliação usada no decorrer do trabalho, assim como uma

breve descrição dos principais resultados e da avaliação inerente. No final do capítulo

apresenta-se a restante estrutura da dissertação.

1.1. Motivação

A Web Semântica potencia a prestação e o usufruto de serviços a um leque cada vez

mais alargado de prestadores e clientes, através da mediação expedita de agentes, pois

contribui para que a informação e os serviços disponibilizados possam ser compreendidos

e processados não apenas por pessoas mas também por programas de computadores, os

quais facilitam e melhoram a sua fruição aos utilizadores. Neste ambiente, e dado que, em

regra, os utentes da Web semântica podem ter necessidades que não podem ser satisfeitas

por um serviço atómico prestado por entidades singulares, surge a necessidade de criar

serviços de valor acrescentado através da composição mais ou menos complexa de

serviços simples e escolher os prestadores mais adequados ao fornecimento de cada

serviço atómico. Com esse objectivo em vista, surgiram os agentes de composição de

Tecnologias de Agentes para a Execução Sensível ao Contexto de Serviços na Web Semântica

2

serviços capazes de criar serviços compostos de vários serviços simples cuja selecção

estará a cargo da entidade que irá executar o serviço composto.

Para ser possível executar as descrições de serviços compostos criadas pelos agentes

de composição é necessário criar agentes de execução de descrições de serviços

compostos. Todas as entidades naturais ou artificiais que necessitem da prestação de

serviços para os quais não exista um único prestador capaz de os fornecer, ou da

prestação de serviços em que os prestadores tenham de ser escolhidos de modo a melhor

adequar a execução ao contexto do utilizador, beneficiarão desta abordagem de

coordenação e execução de serviços.

O trabalho de investigação desenvolvido nesta tese, visa criar, através da definição e

implementação de um agente intermediário de execução de serviços, um ambiente de

execução sensível ao contexto de serviços na Web Semântica que possam ser fornecidos

por diversos tipos de prestadores de serviços, incluindo outros agentes. O uso de

informação de contexto tem como objectivo a adaptação do ambiente de execução ao

serviço específico, com vista à melhoria do próprio processo de execução. As melhorias

da introdução de informação de contexto no ambiente de execução, como a diminuição

do tempo de execução do serviço e a procura de alternativas em caso de falha, são mais

notórias em ambientes dinâmicos em que os agentes tipicamente operam.

1.1.1. Enquadramento

Com a evolução constante da maior rede distribuída de computadores do mundo, a

Internet, surgem novas maneiras de oferecer serviços diversos de forma totalmente

distribuída e automática. Os serviços na Web fazem parte de uma das explosões

tecnológicas baseadas na Internet que vieram para ficar, em parte, devido ao elevado

número de metodologias e ferramentas que existem para ajudar pessoas e organizações a

usufruir de e a implementar serviços acessíveis através da Internet. No entanto, a maior

parte destas tecnologias apontam para solucionar problemas de comunicação (protocolos

e transporte) e descoberta de serviços a um nível muito baixo. Por exemplo, esses

mecanismos processam e interpretam facilmente a estrutura das mensagens mas não o seu

Capítulo 1. Introdução e Motivação

3

conteúdo. Embora esta infra-estrutura seja adequada para as pessoas poderem usufruir

dos serviços disponíveis na Internet, a mesma não é adequada para ser processada por

máquinas ou programas, isto é, os serviços e a informação disponibilizados por esta infra-

estrutura, têm um determinado significado para pessoas mas não para máquinas e

programas.

Surge assim, a noção de Web Semântica, que “promete” fazer com que a Internet

passe a ser um dispositivo distribuído de conteúdos acessíveis, processáveis e

interpretáveis por máquinas, processos e aplicações de todo o tipo, para mudar o mundo

dos serviços na Web, permitindo que estes possam, também eles, ser acessíveis não só

por pessoas, mas também por máquinas, aplicações e outros processos e serviços. Para

além disso, a infra-estrutura criada pela Web Semântica abriu portas para a criação de

mecanismos de coordenação de serviços, que englobam a sua descoberta, composição e

execução automáticos. Esta tese centra-se na execução de serviços na Web Semântica e

no desenvolvimento de tecnologias que façam a ligação entre esta, os agentes inteligentes

e a computação sensível ao contexto.

1.1.1.1. Agentes e a execução de serviços

Paralelamente à evolução dos dispositivos computacionais, do poder de cálculo

disponível e da conectividade dos sistemas, encontra-se a evolução dos paradigmas

computacionais. Desde a ideia inicial de que o processamento era monolítico

(centralizado em super computadores), passando pelo avanço da conectividade e das

redes de comunicação, até ao aparecimento de paradigmas computacionais como a

computação distribuída, a evolução dos sistemas de informação é notória.

Semelhante evolução teve a área da Inteligência Artificial, que passou da criação de

sistemas periciais centralizados para a criação de sistemas autónomos distribuídos que

interagissem com o intuito de resolver problemas mais diversificados e complexos de

forma dinâmica e aberta. A Inteligência Artificial Distribuída permitiu, assim, adicionar

uma nova escala na evolução dos sistemas computacionais, dando origem às arquitecturas

abertas onde a distribuição é um dado adquirido e a adição dinâmica de componentes

externos permite o crescimento das aplicações e das suas capacidades.


4

Pouco tempo passou até que surgisse a primeira atribuição do nome Agente às

entidades autónomas que interagindo entre elas permitiam a criação e funcionamento de

uma mente artificial [Minsky, 1985]. Surge assim o novo paradigma da computação, cuja

base é a programação orientada por agentes [Shoham, 1993]. O conceito de Agente é

ambíguo uma vez que é difícil estabelecer uma fronteira concreta entre aquilo que se

considera como sendo um Agente e um programa genérico. A definição de Agente que se

apresenta em seguida não é uma definição exclusiva, uma vez que um sistema ou

entidade não deixa de ser considerado como um Agente se não preencher um ou mais

destes requisitos. A definição visa apenas clarificar o conceito de Agente que será usado

ao longo da tese e passa pela caracterização de um Agente como sendo um sistema com

as seguintes propriedades [Bradshaw, 1997]: autonomia na prossecução de um ou mais

objectivos; reacção aos eventos que ocorrem no ambiente em que opera; interacção com

outros agentes e serviços; execução de tarefas em nome de pessoas ou organizações.

A construção de uma rede semântica, como a Web Semântica, que facilita o acesso

de máquinas e aplicações à informação presente na Internet, evidencia-se como um

ambiente rico onde entidades autónomas e inteligentes como os agentes podem operar e

oferecer serviços de valor acrescentado aos seus utilizadores. A Web Semântica baseia-se

na ideia da existência de fontes heterogéneas, dinâmicas e distribuídas de informação que

partilham conhecimento num formato processável por máquinas, de forma semelhante à

maneira que esse conhecimento é distribuído na Internet. Integrada nesta visão, está uma

sinergia com as tecnologias de agentes, no sentido em que estes podem utilizar este

conhecimento para atingirem os seus próprios objectivos e/ou produzir novo

conhecimento que pode ser disseminado. Por sua vez, a Web Semântica beneficiaria

destes agentes autónomos e distribuídos responsáveis por obter/agregar conhecimento,

raciocinar e inferir novos factos, identificar e gerir inconsistências, e fornecer

mecanismos de segurança e confiança. Neste âmbito a tese visa criar um ambiente de

execução que permita aos agentes não só, usufruir dos serviços e informação presentes na

Web Semântica, como também permitir que os próprios actuem como prestadores de

serviços na mesma rede semântica.


5

1.1.1.2. Ambientes dinâmicos e a Computação Sensível ao

Contexto

O contexto é um conceito muito poderoso nas interacções entre pessoas e máquinas.

A interacção com dispositivos computacionais é feita através de actos explícitos, porém o

contexto é implícito uma vez que é usado para interpretar actos alheios à comunicação

explícita (como o apontar para um menu ou deslocar o rato de uma determinada forma)

como elementos de informação que podem tornar a comunicação mais eficiente. Ao

juntar a computação ao contexto, a comunicação torna-se mais fluida e adequa-se mais

naturalmente às actividades correntes e à situação de um utilizador, uma vez que as

acções por ele desencadeadas adquirem um significado mais rico sem a correspondente

sobrecarga das mensagens trocadas. O mesmo se aplica à comunicação entre aplicações,

isto é, a utilização de contexto simplifica os actos comunicativos e fornece informação

adicional que ajuda a enriquecer o significado dos mesmos.

Com esta meta em vista, surge a Computação Sensível ao Contexto (Context-aware

Computing), um paradigma de computação no qual aplicações podem descobrir e

aproveitar as vantagens de obter informação de contexto em tempo útil, para melhorar a

sua actividade. Um dos objectivos da Computação Sensível ao Contexto é “adquirir e

utilizar informação acerca do contexto de um dispositivo, para fornecer serviços que são

apropriados a uma determinada pessoa, lugar, tempo ou evento” [Moran & Dourish,

2001]. Muitas tentativas foram feitas para definir contexto desde o início dos anos 90.

Uma definição de contexto que parece ser geralmente aceite é a fornecida em [Dey &

Abowd, 1999] e [Dey, Abowd & Salber, 2001]: “Contexto é qualquer informação que

pode ser usada para caracterizar a situação de uma entidade. Uma entidade é uma

pessoa, lugar ou objecto que é considerado relevante na interacção entre um utilizador e

uma aplicação, incluindo o próprio utilizador e aplicação.”

Os sistemas multi-agentes baseiam-se em arquitecturas abertas que permitem a total

distribuição de componentes e conhecimento, dando origem a ambientes altamente

dinâmicos, onde a adição e a remoção de novas entidades inteligentes são uma constante.

A operação de um agente neste tipo de ambientes é difícil e envolve grandes quantidades


6

de processamento só para estar actualizado, pelo que a necessidade de obter informação

útil sobre a sua própria situação e a das entidades directamente relacionadas com a sua

actividade, assume grande importância. Através da utilização da computação sensível ao

contexto, um agente pode adaptar-se ao seu ambiente influenciando e melhorando a sua

actividade. Tal pode ser conseguido através de um mecanismo geral de Computação

Sensível ao Contexto, o qual pode ser resumido nos seguintes passos [Abowd et al,

1998]: (1) obter informação sobre o estado físico e emocional de uma entidade; (2)

analisar a informação, seja tratando-a como sendo uma variável independente, seja

tratando-a em conjunto com outra informação recolhida no passado e/ou no presente; (3)

realizar acções com base na análise realizada; e (4) repetir do passo 1, com alguma

adaptação baseada nas iterações anteriores.

Com vista ao melhoramento do ambiente de execução no que toca à reacção a

alterações que ocorrem no mesmo, um dos objectivos do trabalho da tese é a introdução

do conceito de Computação Sensível ao Contexto no processo de execução de serviços.

Esta abordagem permitirá que a execução esteja constantemente actualizada sobre os

prestadores de serviços que estão disponíveis ou até utilizar a informação de contexto

para determinar quais os prestadores de serviços mais adequados numa determinada

situação, como por exemplo, a imposição de restrições temporais e a necessidade de

utilizar os prestadores de serviços mais rápidos na execução de um determinado serviço.

1.1.2. Âmbito do trabalho

O trabalho de investigação descrito nesta tese foi desenvolvido na linha de

investigação “We, the Body and the Mind”2 da Associação para o DEsenvolvimento das

Telecomunicações e Técnicas de Informática (ADETTI)3 no âmbito do projecto europeu

Context-aware business Application Service Co-Ordination in Mobile computing

2 www.we-b-mind.org

3 www.adetti.pt – A ADETTI é um centro de estudos associado ao Departamento de Ciências e

Tecnologias de Informação do ISCTE


7

environments (CASCOM)4. O projecto CASCOM é um STREP (Specific Targeted

Research Project) financiado pelo programa IST (Information Society Technologies) do

6º Programa Quadro da União Europeia. O projecto começou em Setembro de 2004, tem

uma duração total de 36 meses e conta com a participação de 8 parceiros de 7 países

europeus. O principal objectivo do projecto é implementar uma infra-estrutura para a

coordenação de serviços de valor acrescentado na Web Semântica em redes fixas ou

móveis. Este objectivo contempla ainda o teste e a validação da tecnologia desenvolvida

em cenários aplicados a Sistemas de Saúde e de Comércio Electrónico. O trabalho desta

tese insere-se no projecto CASCOM com o objectivo de fornecer mecanismos para a

execução sensível ao contexto de serviços na Web Semântica fornecidos por agentes.

1.2. Estado actual dos conhecimentos e

contribuições

A principal contribuição do trabalho desta tese consistiu na criação de um Agente de

Execução de Serviços, que actua como intermediário para a execução de serviços

requeridos por outros agentes, tendo em conta informação contextual para a adaptação do

processo de execução dos serviços à situação actual dos clientes, dos prestadores e de

todos os sistemas intermédios. Optou-se por escolher o paradigma dos agentes para que

este trabalho seja usado em sociedades abertas de agentes, permitindo que estes façam

uso de serviços na Web Semântica. Uma abordagem semelhante foi escolhida para o

desenvolvimento de um agente intermediário para a descoberta e mediação de serviços

num ambiente multi-agente [Paolucci et al, 2004]. No entanto, esta abordagem não inclui

a utilização de informação de contexto para optimizar o processo de descoberta e

mediação de serviços.

O agente desenvolvido no trabalho da tese executa serviços descritos na ontologia de

descrição de serviços OWL-S [Martin et al, 2005], a qual apresentava, inicialmente, um

conjunto de limitações. Uma das limitações prendia-se com o facto de não ser possível

4 Contrato FP6 – 511632 da União Europeia - www.ist-cascom.org; www.we-b-mind.org/cascom


8

especificar agentes como prestadores de um serviço. A outra limitação baseava-se na

ausência de uma linguagem que permitisse descrever expressões condicionais nos

diversos mecanismos de controlo do OWL-S que o exigissem, bem como na

especificação de pré-condições e efeitos da execução de serviços. Estas limitações eram

igualmente visíveis na ferramenta OWL-S API [Sirin, 2004], a qual oferece um motor de

execução de serviços descritos em OWL-S.

Para superar estas limitações, o trabalho desenvolvido nesta tese incluiu a definição e

implementação das seguintes extensões à linguagem OWL-S e à ferramenta OWL-S API:

definição do AgentGrounding [Lopes & Botelho, 2005] (e do correspondente mecanismo

de conversão para mensagens de agentes), uma norma de especificação de agentes como

prestadores de serviços; integração de um módulo de avaliação de expressões

condicionais em Prolog [Clocksin & Mellish, 1981], que permite a execução de

instruções condicionadas e a verificação de pré-condições e efeitos da execução de

serviços, descritas na linguagem referida.

1.3. Resultados e avaliação

Para proceder à avaliação da tese, adoptou-se uma metodologia que consiste em

apresentar os critérios mais adequados à avaliação da medida em que os objectivos

assumidos foram satisfeitos e, em seguida, apresentar um conjunto de testes que servirão

para comprovar a satisfação desses mesmos critérios no trabalho desta tese de mestrado.

Posteriormente, na parte final da tese, foi feita uma ligação destes critérios e testes com

os resultados obtidos, de forma a estabelecer um guia de avaliação para o trabalho da

tese.

Foram definidos os seguintes critérios: utilidade e qualidade do agente desenvolvido;

flexibilidade, interoperabilidade e facilidade de utilização do agente desenvolvido;

abrangência e independência do domínio; melhorias introduzidas pela computação

sensível ao contexto; autonomia do agente; e rapidez do processo de execução. Dos

critérios enunciados não foi possível realizar os testes associados aos critérios de

utilidade e qualidade do Agente de Execução de Serviços porque os mesmos implicariam


9

a criação de diversos agentes e serviços (para a criação de um cenário de testes realista),

sendo que o excesso de recursos necessários atrasaria o decorrer do trabalho normal da

tese. No entanto, a metodologia que seria usada foi explicada com a finalidade de servir

de reflexão a outros trabalhos com os mesmos requisitos.

1.3.1. Avaliação

Através da realização de testes adequados para a avaliação de cada um dos critérios

enunciados foi possível obter um conjunto de resultados que evidenciam a qualidade do

trabalho desenvolvido. Mais concretamente, o desenvolvimento de um Agente de

Execução de Serviços, que usa informação de contexto, revelou-se como uma forma

eficaz de optimizar o processo de execução de serviços, adaptando-se a situações de falha

(prestadores de serviços indisponíveis) e a restrições temporais (impostas pelo cliente), e

executando o serviço com sucesso, sem que isso aumente em demasia o tempo normal de

execução do serviço. Testes efectuados mostram que o tempo de overhead (tempo

acrescentado ao tempo normal de execução) é tão reduzido que é imperceptível pelo

utilizador do serviço. Os mesmos testes mostram também que a optimização do processo

de execução permitiu melhorar a qualidade do serviço executado.

1.4. Estrutura da tese

No presente capítulo (Capítulo 1 - Introdução e Motivação) foi feita uma introdução

ao trabalho realizado onde se apresentaram as áreas relacionadas, e foi feita uma

descrição da motivação por trás da elaboração desta tese de mestrado. A descrição do

resto do trabalho inicia-se no Capítulo 2 (Estado Actual dos Conhecimentos) onde é feita

uma apresentação do estado actual dos conhecimentos nas áreas referidas no Capítulo 1.

Apresentam-se também as limitações e as necessidades de cada uma das áreas descritas, e

as contribuições do trabalho realizado na tese.

Em seguida, no Capítulo 3 (Cenário de Demonstração) é descrito um cenário que foi

utilizado para demonstrar o trabalho que foi produzido ao longo da tese. O cenário

produzido reflecte uma história onde um utilizador pretende fazer uso de um serviço


10

composto que visa descobrir qual a loja que vende um determinado livro ao preço mais

baixo. O Capítulo 4 (Definição Conceptual do Sistema) usa o trabalho descrito no

Capítulo 3 para realizar uma análise do sistema que consiste no levantamento de

requisitos e definição conceptual do sistema a desenvolver no decorrer do trabalho da

tese. Este capítulo inclui ainda a descrição da arquitectura geral da sociedade de Agentes,

serviços e utilizadores, onde o Agente irá operar, assim como a arquitectura interna do

próprio Agente.

No Capítulo 5 (Extensões à Ontologia de Descrição ) é descrita a implementação das

contribuições específicas da tese para o avanço do estado actual dos conhecimentos, que

inclui a descrição do AgentGrounding (usado na especificação de Agente Prestadores de

Serviços) e a utilização do Prolog na definição de expressões condicionais na descrição

de serviços OWL-S. Ainda no âmbito da implementação do trabalho da tese, o Capítulo 6

(Implementação) descreve o processo de implementação e desenvolvimento do Agente de

Execução de Serviços e dos componentes internos do mesmo. É ainda descrita, neste

capítulo, a implementação dos restantes intervenientes do ambiente em que o agente

opera, assim como as interacções que o agente realiza com os mesmos.

O Capítulo 7 (Avaliação) é dedicado à avaliação do trabalho realizado ao longo da

tese. Neste capítulo é descrita a metodologia e os critérios que foram utilizados na

avaliação do trabalho desenvolvido. Posteriormente, apresentam-se os testes realizados e

finalmente descreve-se o processo de avaliação efectuado e os resultados obtidos.

Finalmente, no Capítulo 8 (Conclusões e Trabalho Futuro) conclui-se a dissertação

apresentando as considerações finais e identificando os pontos, que por não terem sido

abordados ou não terem sido suficientemente desenvolvidos, constituem as directrizes de

trabalho futuro.

Na última parte do documento, na secção relativa aos anexos são apresentados, para

além dos anexos referidos ao longo da dissertação, os artigos escritos no período do

trabalho realizado e que foram aceites em conferências ou workshops de áreas

relacionadas.

11

CCaappííttuulloo 22.. EESSTTAADDOO AACCTTUUAALL DDOOSS

CCOONNHHEECCII MM EENNTTOOSS

Neste capítulo é descrito o estado actual dos conhecimentos dos temas relacionados

com o trabalho da tese. O âmbito do trabalho abrange as seguintes áreas: linguagens de

descrição e execução de serviços na Web Semântica, ferramentas de desenvolvimento de

software com base em componentes, ferramentas de criação de agentes inteligentes e

sistemas sensíveis à informação de contexto.

O capítulo encontra-se dividido em duas secções: a primeira descreve o estado actual

dos conhecimentos das áreas em questão, incluindo as limitações e as necessidades que

cada uma apresenta; e na segunda secção remete-se para o contributo que o trabalho da

tese terá para avançar com o estado actual dos conhecimentos.

2.1. Estado actual, limitações e necessidades

Nesta secção é feita uma introdução que reflecte o actual estado dos conhecimentos,

incluindo as limitações e necessidades, para cada um dos temas relacionados com o

trabalho da tese.

2.1.1. Linguagens de descrição de serviços

Os serviços na Web permitiram a adição de um novo nível de funcionalidades na

Internet, permitindo o acesso e a combinação de componentes funcionais sem fronteiras.

A necessidade de adicionar significado à descrição destes serviços para automatizar a sua


12

descoberta, composição e execução (criando assim a Web Semântica) impulsionou

actividades de investigação nesta área, sendo que duas iniciativas se distinguem pelo

impacto que tiveram na comunidade dos serviços na Web Semântica5: Web Ontology

Language for Services (OWL-S) [OWL Services Coalition, 2003], [Martin et al, 2005] e

Web Service Modelling Ontology (WSMO) [Roman, Keller & Lausen, 2004].

2.1.1.1. OWL-S

O OWL-S6, sucessor do DARPA7 Agent Modelling Language for Services (DAML-

S) [Ankolekar et al, 2002], é uma ontologia de serviços baseada em OWL [McGuiness &

Harmelen, 2003] que fornece um conjunto de classes e propriedades básicas para declarar

e descrever serviços, isto é, uma ontologia para descrever serviços na Web que permite

que agentes de software possam automaticamente descobrir, compor, invocar e

monitorizar recursos da Internet que fornecem serviços específicos [Martin et al, 2005].

O OWL-S pretende abranger a descrição de serviços num sentido lato, pelo que não se

concentra num domínio específico de aplicação ou problema.

A ontologia está dividida em três partes: o Perfil do serviço (Service Profile) que

descreve o serviço em traços gerais (descrevendo os parâmetros de entrada e saída, as

pré-condições e os efeitos do serviço) e que pode ser usado para anunciar e

procurar/descobrir serviços; o Modelo Processual do serviço (Service Process Model) que

descreve detalhadamente o funcionamento interno do serviço e que é usado para o

executar; e a Instanciação do serviço (Service Grounding) que fornece detalhes sobre

como utilizar o serviço, através da descrição das mensagens, protocolos e operações a

utilizar na execução concreta do serviço.

5 Tradução de “Semantic Web Services”

6 Uma descrição mais detalhada do OWL-s pode ser consultada na secção 5.1 do Capítulo 5

7 Defense Advanced Research Projects Agency – www.darpa.mil

Capítulo 2 - Estado Actual dos Conhecimentos

13

2.1.1.2. WSMO

A ontologia WSMO (Web Service Modelling Ontology) é uma iniciativa Europeia

que começa a atrair muita atenção na área da descrição semântica de serviços na Web e,

tal como a ontologia OWL-S, partilha da opinião de que as ontologias devem suportar a

descoberta, composição e interoperabilidade entre serviços. Esta iniciativa faz parte de

um conjunto de iniciativas que compõe a WSMF (Web Service Modelling Framework). A

WSMF é uma base de trabalho que fornece um modelo conceptual para desenvolver,

descrever e compor serviços na Web Semântica [Fensel & Bussler, 2002]. A WSMF é

composta por três componentes específicos que facilitam a automatização de processos

descritos por este tipo de serviços:

• Web Service Modelling Language – a WSML é a linguagem desenvolvida no

âmbito desta base de trabalho destinada a ser usada na descrição de Classes e

Objectos de interesse para a Web Semântica.

• Web Service Modelling Ontology – a WSMO é a ontologia de serviços, que

através da WSML, permite a descrição de serviços na Web Semântica.

• Web Service Modelling eXecution – o WSMX é um motor genérico que visa

oferecer mecanismos de automatização da descoberta, composição e execução de

serviços na Web Semântica descritos usando WSMO.

O WSMO [Roman, Keller & Lausen, 2004] é composto por quatro elementos

principais: Objectivos, Ontologias, Mediadores e Serviços na Web. Esta ontologia baseia-

se em dois princípios complementares: máxima independência e fortes mediadores. De

acordo com o princípio da máxima independência, todos os componentes são

especificados autonomamente, independentes da ligação e da interoperabilidade com

outros componentes. De acordo com o princípio dos fortes mediadores, a ligação e a

interoperabilidade entre componentes são atingidas através de mediadores. De seguida é

apresentada uma descrição dos principais elementos do WSMO.

Ontologias. As ontologias, as quais são descritas a um meta-nível, são a base para a

ligação conceptual à semântica do mundo real, definidas e aceites pelas comunidades de


14

utilizadores. Uma meta-ontologia permite a descrição de todos os elementos das

ontologias utilizados para a modelação de serviços. Uma ontologia descrita usando

WSMO é composta por propriedades não funcionais, mediadores utilizados, ontologias

importadas, e a definição de conceitos, relações, axiomas, funções e instâncias de uma

ontologia.

Mediadores. Mediadores são elementos especiais que ligam componentes

heterogéneos utilizados na modulação de um serviço na Web. Estes elementos definem o

mapeamento, as transformações e as conversões necessárias entre os componentes

ligados.

Objectivos: Os objectivos são definidos em WSMO como sendo os resultados que

um cliente obtém da execução de um serviço na Web. Estes objectivos consistem em

propriedades não funcionais, ontologias importadas, mediadores utilizados, pós-

condições e efeitos.

Serviços na Web: serviços na Web são descritos através de uma especificação

funcional denominada Capacidade e por uma Interface. A Capacidade descreve os

aspectos funcionais do serviço modelado em termos de Pré-condições, Suposições, Pós-

condições e Efeitos. As Pré-condições descrevem um conjunto de condições que têm

necessariamente de se verificar antes de o serviço ser executado. As Pós-condicões

descrevem o estado das condições que é garantido após a execução do serviço. As

Suposições são semelhantes às Pré-condições mas definem estados válidos do mundo

para uma correcta execução do serviço. Os Efeitos descrevem o estado do mundo após a

execução do serviço. A Capacidade desempenha um papel semelhante à secção de Perfil

de uma descrição OWL-S. A Interface de um serviço fornece detalhe da execução do

serviço em termos de Coreografia e Orquestração. A Coreografia fornece a informação

necessária para um utilizador comunicar com o serviço na Web, descreve como o serviço

funciona e como um utilizador pode contactar o serviço. A Coreografia inclui também a

Instanciação (Grounding) utilizada para tecnologias de execução semelhante à secção de

Instanciação de serviços de uma descrição OWL-S. A Orquestração descreve como o

serviço funciona do ponto de vista do fornecedor do serviço indicando como um serviço

utiliza outros serviços na Web ou outros objectivos de modo a atingir os seus próprios


15

objectivos. A Interface de um serviço na Web desempenha um papel semelhante à secção

do modelo processual do serviço de uma descrição OWL-S mas é mais elaborado no que

diz respeito ao modelo conceptual e à especificação das linguagens utilizadas.

2.1.1.3. Limitações e necessidades

O âmbito do trabalho da tese envolve o desenvolvimento de um agente capaz de

executar serviços descritos em OWL-S. A utilização da ontologia de serviços OWL-S é

uma obrigação imposta pelo projecto CASCOM. Por outro lado, apesar do WSMO cobrir

a maior parte dos elementos descritivos do OWL-S [Cabral et al, 2004], a utilização da

ontologia WSMO está limitada pelo nível de detalhe que oferece no que toca à

Coreografia e mais concretamente à Instanciação [Lara et al, 2004]. Isto deve-se ao facto

de esta ontologia encontrar-se ainda em fase de definição e desenvolvimento.

A linguagem OWL-S, apesar de se encontrar num estado mais maduro, não inclui

uma forma de especificar a Instanciação de serviços que em vez de serem prestados por

recursos na Internet, são prestados por agentes. Outra limitação da ontologia de serviços

OWL-S baseia-se no facto de não haver especificação formal do conteúdo de expressões

lógicas na descrição do serviço, como as pré-condições e efeitos de um serviço. Apesar

de o OWL-S reconhecer esta necessidade, não especifica como é que estas expressões

lógicas devem ser descritas, oferecendo essa liberdade à comunidade de utilização da

linguagem. Estas propriedades necessitam de estar especificadas para ser possível avaliar

o sucesso da execução de um serviço, uma vez que esta avaliação é feita com base na

comparação entre os efeitos especificados de um serviço e os resultados obtidos na

execução.

2.1.2. Ferramentas de desenvolvimento de Software com

base em componentes

O desenvolvimento de software com base em componentes potencia a reutilização

dos mesmos através da modularização de um sistema em diversos subsistemas, cada um

com um conjunto de funcionalidades próprias e uma interface de utilização bem definida.


16

Este paradigma de desenvolvimento de software potenciará também melhorias

significativas em termos de eficiência, já que os componentes podem ser executados em

computadores diferentes. Existem actualmente diversas iniciativas de ferramentas que

permitem o desenvolvimento de software com base em componentes.

2.1.2.1. JavaBeans, Microsoft COM, .NET e CORBA

JavaBeans [Englander, 1997] é uma arquitectura de componentes para a plataforma

JavaTM8 [Arnold & Gosling, 1996]. Esta tecnologia permite o desenvolvimento de

componentes reutilizáveis que podem ser utilizados de forma distribuída, dada a

característica de portabilidade do Java. Os Beans são classes Java que podem ser

manipuladas através de uma ferramenta visual e incluídas como fazendo parte do corpo

de uma aplicação. Qualquer classe Java que implemente um determinado interface e

inclua um conjunto específico de propriedades pode ser considerada como um Bean.

A tecnologia COM (Component Object Model) [Williams & Kindel, 1994],

[Microsoft, 1995] permite criar componentes de software reutilizáveis, compor uma

aplicação através da ligação entre vários componentes e usufruir das vantagens dos

serviços disponibilizados pelo Microsoft Windows. A família das tecnologias COM inclui

COM+ [Platt, 1999], Distributed COM (DCOM) [Brown & Kindel, 1998] e ActiveX®

Controls [Chappell, 1996]. Esta tecnologia sofreu uma evolução, fazendo surgir a

plataforma de desenvolvimento de software com base em componentes .NET [Platt,

2001]. Embora a Microsoft recomende agora o uso de .NET em vez de COM, a

integração entre as duas é perfeitamente possível e podem-se mesmo considerar

tecnologias complementares.

CORBA (Common Object Request Broker Architecture) [Orfali, Harkey & Edwards,

1997] é uma tecnologia de desenvolvimento de software de componentes inter-operáveis

que comunicam utilizando o protocolo de comunicação IIOP. Isto permite que sejam

desenvolvidos componentes que consigam obter informação de outros componentes que

8 Java e outros nomes baseados em Java e logótipos são marcas registadas da Sun Microsystems, Inc., e referem-se à família de marcas, produtos e serviços do Java.


17

se encontrem em pontos completamente distintos do globo e assim desenvolver

aplicações distribuídas de dimensão considerável. O CORBA apresenta uma vantagem

relativamente às abordagens descritas anteriormente que assenta no facto de ser

independente da plataforma sobre a qual se desenvolve a aplicação. Tal é possível devido

ao facto de existirem as ferramentas CORBA adequadas para qualquer sistema operativo.

A utilização de um componente CORBA baseia-se na chamada de objectos e métodos

que esse componente oferece, através da definição concreta e detalhada do interface do

mesmo.

2.1.2.2. Jini

A tecnologia Jini [Arnold, 1999] permite a criação de um sistema distribuído de

componentes baseado na ideia da federação de grupos de utilizadores e recursos

necessários por esses utilizadores. O objectivo é transformar uma rede numa ferramenta

flexível e fácil de administrar que permita que clientes (pessoas ou máquinas) possam

encontrar os recursos que necessitem. Estes recursos podem ser dispositivos físicos,

programas ou uma combinação de ambos. Mais concretamente, estes recursos podem ser

componentes de software. A tecnologia Jini pretende oferecer a infra-estrutura necessária

para que os diversos componentes possam ser descobertos e utilizados de forma

transparente. Um sistema Jini inclui as seguintes partes: um conjunto de componentes

que fornece uma infra-estrutura para federar serviços num sistema distribuído; um

modelo de programação que suporta e encoraja a produção de serviços distribuídos;

serviços que podem fazer parte de um sistema federado Jini e que oferecem

funcionalidades a qualquer outro membro do sistema federado.

2.1.2.3. eXtended Service Platform

O software XSP (eXtended Service Platform) [Gonçalves, Jesus & Botelho, 2003] é

uma plataforma de desenvolvimento de componentes criada pela linha de investigação


18

“We, the Body and the Mind” e pela empresa Accedo9. O XSP, para além de facilitar a

criação de componentes e das estruturas de dados relacionadas, fornece uma infra-

estrutura de comunicação transparente que facilita a interoperabilidade entre os

componentes. Para criar um componente XSP, basta definir o seu interface através de um

XML Schema [Thompson et al, 2004], e definir um conjunto de métodos que funcionam

como gestores de processamento de mensagens. Cada um destes gestores fica responsável

por processar mensagens que cheguem através do interface definido no XML Schema.


Uma vez que o trabalho da tese se insere no âmbito do projecto CASCOM

actualmente a decorrer na linha de investigação “We, the Body and the Mind”, é de todo o

interesse da linha, que se use a ferramenta de desenvolvimento com base em

componentes da própria linha, o XSP. Devido à necessidade de interagir com um sistema

de fornecimento de informação de contexto, será utilizada também a tecnologia Jini, pelo

facto do sistema escolhido para esse efeito (ver secção 2.1.5) oferecer um interface Jini.

2.1.3. Tecnologias de Agentes

À medida que aumenta a aceitação do paradigma dos agentes inteligentes, aumenta a

necessidade de criar ferramentas abstractas de alto nível que ajudem no desenho e

desenvolvimento de aplicações baseadas em agentes. Abstracção significa, a este nível, a

capacidade de criar facilmente aplicações baseadas em agentes para diferentes domínios

sem que seja necessário mudar substancialmente o ambiente de desenvolvimento.

Igualmente importante é a facilidade de poder estender e incorporar novas características

às aplicações desenvolvidas, pois tal permite aumentar as capacidades dos agentes

inteligentes e/ou dos sistemas multi-agentes. A maior parte das ferramentas de criação de

agentes inteligentes são incorporadas em plataformas de agentes, pelo que a sua criação

funde-se com a actividade dos mesmos. Para facilitar a interoperabilidade das diversas

9 www.accedo.pt


19

aplicações e plataformas de agentes, foram definidas várias normas de especificação,

nomeadamente por parte da FIPA [FIPA, 2002], que permitem regular a forma como os

agentes interagem, comunicam e colaboram.

2.1.3.1. JADE e LEAP

JADE (Java Agent DEvelopment framework) [Bellifemine, Poggi & Rimassa, 1999]

é uma plataforma multi-agente que permite o desenvolvimento e execução de agentes

inteligentes totalmente interoperáveis em aplicações distribuídas. A plataforma JADE é

extensível, pelo que os programadores podem facilmente desenvolver extensões à

plataforma original de forma a potenciar as capacidades dos agentes ou de todo o sistema

multi-agente. Isto é conseguido pelo facto da plataforma ser totalmente gratuita e

funcionar sobre o princípio do Código-Livre10. Testes de compatibilidade11 disponíveis

indicam que a plataforma JADE é compatível com as especificações FIPA. A plataforma

JADE é, de longe, a plataforma mais usada nos projectos europeus em que se criaram

sistemas de agentes cujo principal objectivo é a interoperabilidade em comunidades

abertas.

A Plataforma LEAP (Light Extensible Agent Platform) [Bergenti & Poggi, 2001] é uma

versão mais reduzida da plataforma JADE. Esta versão reduzida foi desenvolvida com o

intuito de proporcionar as funcionalidades da plataforma JADE a dispositivos com

capacidades limitadas de memória e processamento, como PDAs e Telemóveis.

2.1.3.2. AgentBuilder e AgentAcademy

AgentBuilder [Minton, Ticrea & Beach, 2003] é uma ferramenta integrada de

software que permite aos programadores criar agentes de software inteligentes e

10 Tradução de “Open-Source”

11 Estes testes foram realizados em sessões organizadas pela FIPA, denominadas de Bake-off,

onde diversos programadores de plataformas de agentes tiveram oportunidade de testar a

interoperabilidade entre as suas implementações, segundo as especificações da mesma

organização.


20

aplicações baseadas em agentes. O AgentBuilder fornece uma ferramenta gráfica para

suportar todas as fases do processo de construção de agentes. Para além de fornecer um

conjunto de ferramentas para programar agentes inteligentes, permite a sua extensão

através de bibliotecas computacionais, denominadas de PAC (Project Accessory Class).

Estas PAC podem ser feitas em algumas linguagens de programação (como C, C++ e

Java) e incluem tarefas como acesso FTP e funcionalidades de correio electrónico.

AgentAcademy [Mitkas et al, 2002] é uma plataforma integrada de desenvolvimento,

implementada ela própria como um sistema multi-agente que permite o desenho de

comportamentos de agentes, a definição de ontologias e a instanciação de agentes

individuais ou comunidades multi-agente. Em adição a essas características, esta

plataforma aprofunda o desenvolvimento dos agentes, permitindo a implementação

interna de mecanismos de raciocínio baseado em regras. O AgentAcademy é gratuito, foi

desenvolvido no topo da plataforma JADE e usa outras ferramentas externas como

Jakarta [Goodwill, 2002], Jess [Sandia National Laboratory, 2003], Jena [McBride,

2002] e WEKA [Holmes, Donkin & Witten, 1994].

2.1.3.3. Zeus e APRIL

ZEUS [Nwana, Ndumu & Lee, 1998] é uma plataforma de agentes totalmente

implementada em Java, desenvolvida pelos laboratórios da BT – British Telecom12 e

integra ferramentas para construir aplicações colaborativas multi-agente. Esta plataforma

é compatível com as especificações da FIPA, fornece um conjunto de funcionalidades

genéricas para agentes e tem um suporte sofisticado para planeamento e calendarização

de acções dos agentes desenvolvidos. Esta plataforma, tal como o JADE, é totalmente

gratuita e foi construída segundo o princípio de “Código-Livre”.

A plataforma de agentes APRIL [Dale, 2002] é uma plataforma compatível com as

especificações da FIPA e foi desenvolvida usando a linguagem de programação April

[McCabe, 2002] e o sistema de comunicação InterAgent [McCabe-2, 2002]. Esta

12 www.bt.com


21

plataforma também é de uso gratuito e o seu principal objectivo é fornecer uma solução

poderosa no que toca ao desenvolvimento de sistemas baseados em agentes. Isto é

conseguido através do fornecimento de pequenas ferramentas que aceleram o

desenvolvimento dos agentes e da própria plataforma.


Com o interesse de tornar a tecnologia desenvolvida no âmbito desta tese reutilizável

e interoperável com outros sistemas já desenvolvidos, o agente terá de ser desenvolvido

num ambiente que seja compatível com as especificações da FIPA, uma vez que estas são

actualmente as normas utilizadas no projecto CASCOM e na maior parte dos sistemas

multi-agentes desenvolvidos. A plataforma AgentBuilder apesar de ser bastante completa,

não cumpre as especificações da FIPA e como tal, inviabiliza a sua utilização. Por outro

lado, esta plataforma é limitada no sentido em que não é gratuita e apenas está disponível

uma versão para avaliação que só permite utilizar os exemplos já desenvolvidos, não

permitindo o desenvolvimento de novos agentes nem a modificação dos já existentes nos

exemplos. O sistema AgentAcademy é gratuito e como é feito no topo do JADE, respeita

as especificações da FIPA. Igualmente, as plataformas Zeus, APRIL e JADE foram

desenvolvidas com base nas especificações da FIPA e são todas interoperáveis. No

entanto, a plataforma JADE (e a sua versão reduzida LEAP) tem a maior comunidade de

utilizadores e já vem sendo usada no seio da linha de investigação “We, the Body and the

Mind”, por ser uma plataforma num estado bastante maduro e optimizado. Como tal, a

utilização da plataforma JADE para o desenvolvimento dos agentes manter-se-á nesta

tese.

2.1.4. Execução de serviços na Web Semântica

Sendo que a utilização da linguagem OWL-S é uma imposição do projecto

CASCOM, têm de se considerar as ferramentas que estão disponíveis para a execução de

serviços descritos segundo esta.


22

O OWL-S é composto, entre outros, por um modelo processual (ver secção 2.1.1.1)

que especifica a forma como serviços mais simples devem ser organizados e integrados

para criarem um serviço composto. Este modelo é expresso em termos de mecanismos de

controlo muito semelhantes aos existentes na maioria das linguagens de programação

estruturadas como por exemplo, o ciclo de execução condicionada (“while” ), a instrução

condicionada (“if” ) e a execução concorrente (“split” ). Como tal, a execução de um

serviço OWL-S passa pela interpretação desse modelo processual e pela completa

execução dos seus elementos, isto é, os processos compostos ou atómicos.

A ontologia de serviços OWL-S é uma especificação relativamente nova e apenas

recentemente foi aceite como uma recomendação do W3C. Ainda não existem muitas

ferramentas para lidar com o OWL-S e as poucas que existem não cobrem esta área

específica da execução do serviço, sendo que a maior parte delas servem para lidar com

outras questões como edição de descrições OWL-S, comparação entre perfis de serviços

(usado na descoberta e composição de serviços) e tradução/mapeamento de OWL-S para

outras linguagens (como WSDL).

No que toca à temática da execução de serviços OWL-S, actualmente só existe uma

ferramenta que pode ser usada: a OWL-S API [Sirin, 2004]. A OWL-S API é uma API

para o JAVA que oferece um motor de execução para serviços descritos em OWL-S. Esta

ferramenta permite executar serviços que estejam descritos em OWL-S e que tenham um

mapeamento de Instanciação de serviços na Web descrito em WSDL. Existe uma outra

ferramenta que já tem vindo a ser anunciada mas que ainda não está disponível para

utilização para a execução de serviços descritos em OWL-S, a OWL-S VM (OWL-S

Virtual Machine) [Paolucci & Srinivasan, 2004]. A OWL-S VM vai já sendo referida nos

grupos de discussão relacionados com a tecnologia OWL-S como uma ferramenta que

permitirá executar serviços OWL-S através da sua descrição, apresentando-se assim

como uma alternativa à OWL-S API. No entanto, a OWL-S VM ainda não tem qualquer

versão disponível conhecida nem prazo para tal13, pelo que não poderá ser utilizada nesta

tese ou mesmo analisada para comparar como alternativa à OWL-S API.

13 Última verificação: 2005-08-20


23

A OWL-S API é uma ferramenta recente e ainda não está na sua versão final pelo

que conta com a participação dos seus utilizadores actuais para contribuírem para as

melhorias da ferramenta. O desenvolvimento e melhoria da OWL-S API estão

directamente ligados com a actividade continuada de desenvolvimento e melhoria do

próprio OWL-S, sendo que as partes do OWL-S que ainda não estão totalmente

especificadas não têm correspondência de utilização na OWL-S API. Por esta razão, no

início do período sobre o qual se realizou o trabalho desta tese, a OWL-S API não

suportava algumas das características do OWL-S como a utilização de expressões

condicionais. Posteriormente, com a nova versão da OWL-S API14, a limitação da

representação de expressões condicionais foi superada, permitindo a descrição das

mesmas utilizando a linguagem SWRL [Horrocks et al, 2004].

Uma outra limitação da OWL-S API (que advém do facto do OWL-S não determinar

ao certo qual a norma de Instanciação de um serviço OWL-S) é que apenas é possível

executar serviços OWL-S que usem como serviços atómicos descrições de serviços na

Web em WSDL [Christensen et al, 2001]. No âmbito do trabalho da tese, pretende-se que

os prestadores de serviços atómicos não sejam apenas serviços na Web, mas também

Agentes Prestadores de Serviços.

2.1.5. Computação Sensível ao Contexto

A sensibilidade e interpretação de informação de contexto é um assunto que tem

recebido cada vez mais atenção por parte da comunidade de investigação em agentes

inteligentes pelo seu potencial para melhorar sistemas que operem em ambientes

dinâmicos. Actualmente, a maior parte dos serviços apenas lida com informações básicas

de contexto como a localização do utilizador. No entanto, a investigação nesta área

caminha no sentido de permitir a utilização de informação de contexto mais complexa

como os recursos disponíveis em rede e em dispositivos físicos (largura de banda, visores

dos dispositivos), propriedades dos ambientes circundantes (temperatura, ruído,

visibilidade) e características específicas dos utilizadores (orientação, disposição).

14 Em Abril de 2005


24

O Agente de Execução de Serviços terá por vezes de se adaptar a determinadas

situações que sofreram uma alteração do contexto15. O agente terá de estar preparado

para, de alguma forma, lidar com estas situações, seja através da inclusão de um

componente interno que lide com contexto, seja através do recurso à comunicação com

outros agentes (ou sistemas) que lhe forneçam a informação de contexto necessária.

Existem actualmente diversas arquitecturas de sistemas de informação de contexto

que visam endereçar algumas das questões apontadas como os desafios desta área. O

GAIA Middleware [Ranganathan & Campbell, 2003] é um sistema que gere os recursos e

os serviços presentes num espaço físico. O sistema fornece uma ferramenta de criação de

aplicações que esconde a complexidade e a dinâmica do espaço físico, e que permite aos

utilizadores programarem o ambiente de execução associado ao mesmo.

O Reconfigurable Context Sensitive Middleware (RCSM) [Yau et al, 2002] é um

sistema que facilita o desenvolvimento e a monitorização de aplicações que necessitam

de capacidades de percepção e processamento de informação de contexto. As aplicações

baseadas nesta plataforma de contexto funcionam com base nos chamados Objectos

Sensíveis ao Contexto. Usando estes objectos o RCSM determina qual o tipo de contexto

que deve monitorizar e que métodos dos objectos é que devem ser activados quando um

determinado contexto ocorre.

A Context Broker Architecture (CoBrA) [Chen, Finin & Joshi, 2004] é uma

arquitectura baseada em agentes que permite a criação de sistemas que lidem com

informação de contexto em espaços inteligentes, como casas, salas de reuniões e carros

inteligentes. Esta arquitectura usa a linguagem de ontologias OWL [McGuiness &

Harmelen, 2003] para definir ontologias de contexto (para pessoas, agentes, aparelhos,

eventos, tempo, espaço).

A Generic Context Framework [Costa & Botelho, 2005] é uma plataforma de gestão

e manutenção de informação de contexto sobre entidades de um determinado ambiente,

desenvolvida pela linha de investigação “We, the Body and the Mind” no âmbito do

15 Exemplos destas situações podem ser consultados no Capítulo 3


25

projecto CASCOM. Todas as entidades (agentes, serviços na Web, sensores físicos e

aplicações externas) que operem num determinado ambiente no qual tenham acesso a esta

plataforma, podem obter e fornecer informação de contexto de e para as restantes

entidades. A plataforma Generic Context Framework fornece o seguinte conjunto de

funcionalidades para que as entidades possam lidar com a informação de contexto

disponível: aquisição/fornecimento de informação de contexto através de sensores;

aquisição/fornecimento de histórico de informação de contexto; subscrição de eventos de

contexto.

Alguns projectos têm também lidado com as questões ligadas aos sistemas de

informação de contexto e pretendem resolver, ou pelo menos, contribuir para a resolução

dos desafios e ambições desta área. Destacam-se os projectos Web Architectures for

Services Platforms (WASP) [Sinderen, Eijkel & Meer, 2002], Context Toolkit [Salber,

Dey & Abowd, 1999] e Context Fabric [Hong, 2002].

O agente de execução de serviços terá de processar informação de contexto e, a partir

daí, raciocinar sobre o seu comportamento de forma a determinar as suas acções

adaptadas a alterações de contexto. A forma como o agente irá realizar esta tarefa

específica está dependente da arquitectura adoptada no seio do projecto CASCOM, uma

vez que o trabalho desta tese está intimamente ligado ao projecto. Por outro lado, é do

interesse da linha de investigação, na qual este projecto está a decorrer, utilizar as suas

ferramentas internas, inclusivamente no que toca ao desenvolvimento do sistema de

contexto. Como tal, o sistema utilizado deverá ser o desenvolvido na linha, a Generic

Context Framework.

2.2. Contribuições da tese

Nesta secção, são apresentadas as contribuições concretas que se espera que o

trabalho da tese influencie o actual estado de conhecimentos. Para além das contribuições

que visam avançar o estado actual dos conhecimentos nas áreas relacionadas com o

trabalho da tese, esta tese visa contribuir para o melhoramento e divulgação das diversas

tecnologias utilizadas no âmbito do trabalho desenvolvido.


26

2.2.1. Contribuições ao nível da melhoria e divulgação de

ferramentas

A utilização do software XSP permitirá contribuir para o seu melhoramento e

divulgação, uma vez que o trabalho realizado na tese insere-se num projecto europeu e a

ferramenta poderá ser utilizada em projectos futuros da linha.

A aplicação da ontologia de serviços OWL-S no trabalho da tese permitirá obter

conhecimento e experiência nesta área. Esta aplicação será importante para o trabalho a

realizar no projecto CASCOM e em projectos futuros da linha de investigação. Por outro

lado, o uso do OWL-S permitirá gerar a informação de avaliação necessária (como

propostas de melhorias ou extensões) ao grupo de trabalho correspondente, uma vez que

a linguagem foi recentemente aceite como uma recomendação do W3C16.

Ao nível da utilização da computação sensível ao contexto, o trabalho desenvolvido

incluirá o uso da arquitectura de contexto adoptada no projecto CASCOM, isto é a

Generic Context Framework (ver secção 2.1.5). Como tal, o trabalho desenvolvido

servirá de base de testes para a plataforma, pelo que o seu contributo directo no projecto,

ao nível do contexto e no que toca à melhoria da plataforma de informação de contexto

utilizada, é evidente.

No âmbito do trabalho da tese, pretende-se criar uma ferramenta integrada de criação

de agentes, através de uma extensão à plataforma JADE. Esta extensão visa adicionar ao

JADE a capacidade de desenvolver agentes com base em componentes, nomeadamente o

software XSP. Isto permite criar agentes com capacidades distribuídas e reutilizáveis

através da infra-estrutura de comunicação, descoberta e utilização de componentes do

software XSP. A ferramenta criada será posteriormente utilizada na linha de investigação

em projectos futuros para o desenvolvimento de agentes inteligentes e de componentes

mais complexos.

16 World Wide Web Consortium - www.w3.org


27

2.2.2. Contribuições para o avanço do estado actual dos

conhecimentos

Uma vez que a linguagem escolhida para a utilização na descrição de serviços foi o

OWL-S (ver secção 2.1.1.3), a escolha de uma ferramenta de execução de serviços na

Web Semântica tem de ser naturalmente na base de utilização desta mesma linguagem.

Até à data, apenas se encontra disponível uma ferramenta que permite a execução de

serviços OWL-S (ver 2.1.4), a OWL-S API. Naturalmente, esta é a ferramenta escolhida.

As principais contribuições nesta área que vêm do trabalho da tese são:

• A definição ou escolha da linguagem a utilizar na representação de expressões

condicionais usando uma linguagem lógica adequada;

• A extensão do motor de execução da OWL-S API para suportar a execução de

instruções condicionadas que dependam da representação escolhida de expressões

condicionais;

• A extensão da ontologia de serviços OWL-S para suportar a especificação de

utilização de serviços atómicos prestados por agentes inteligentes;

• A extensão do motor de execução da OWL-S API para suportar a invocação de

prestadores de serviços descritos através da extensão referida, isto é, agentes

inteligentes.

Todas estas extensões, que se encontram descritas no Capítulo 5, irão ser

comunicadas à comunidade OWL-S e aos utilizadores da OWL-S API para que possam

ser avaliadas e integradas em futuras especificações da linguagem e/ou da ferramenta.

Ao nível da computação sensível ao contexto, a principal contribuição da tese será a

introdução da temática do contexto na execução de serviços. A utilização de informação

de contexto visa influenciar o processo de execução de serviços de forma a melhorar o

mesmo e fornecer um serviço de valor acrescentado a quem o usa.

28

CCaappííttuulloo 33.. CCEENNÁÁRRII OO DDEE

DDEEMM OONNSSTTRRAAÇÇÃÃOO

Esta secção descreve o cenário a ser utilizado na demonstração do trabalho da tese,

começando por apresentar a história por trás do cenário e em seguida apresentando o

cenário em concreto onde se descrevem os seus intervenientes e as interacções entre os

mesmos.

Para realizar uma comparação, a mesma história será descrita usando duas versões

diferentes do cenário. Numa usam-se serviços na Web como prestadores de serviços e na

outra usam-se agentes como prestadores de serviços. Esta abordagem permitirá, na fase

de recolha e análise de resultados do trabalho da tese, realizar uma comparação entre os

dois cenários e analisar as vantagens e desvantagens de cada uma das tecnologias.

3.1. História do cenário

A história usada para descrição do cenário de demonstração do trabalho da tese

baseia-se no pressuposto da existência de uma plataforma em que é possível usufruir de

serviços complexos através da Internet, prestados por diversas entidades diferentes, sejam

elas serviços na Web, sejam agentes inteligentes.

A história centra-se num utilizador, o Fonseca, que pretende procurar o livro “O

Código Da Vinci” ao preço mais baixo possível e a loja que o comercializa a esse preço.

O Fonseca tem a possibilidade de utilizar o seu Agente Pessoal (AP) que se encontra

alojado no seu dispositivo (PDA, computador ou telemóvel), para realizar a dita pesquisa.

Capítulo 3 - Cenário de Demonstração

29

No entanto, a situação do Fonseca é limitativa, pois o contexto actual influencia a

pesquisa a realizar. Acontece que o livro que o Fonseca procura é para servir de prenda

para o aniversário do amigo Barbosa, o qual vai se realizar dali a vinte minutos num

restaurante relativamente perto do sítio onde o Fonseca se encontra. Portanto, existem

dois factores muito importantes nesta história: a localização (a loja com o preço do livro

mais barato tem de se encontrar relativamente perto da localização actual do Fonseca) e a

restrição temporal (o Fonseca tem apenas vinte minutos para encontrar a loja, comprar o

livro e dirigir-se para o sítio do aniversário).

O trabalho do AP consiste em encontrar o serviço que permita descobrir a loja que

vende o livro ao preço mais baixo e executá-lo (caso tenha capacidade para tal) ou então

pedir a execução a um Agente de Execução de Serviços (AES). A procura por um serviço

que permite satisfazer a vontade do Fonseca passa pela interacção com um Agente de

Descoberta de Serviços (para descobrir serviços que já existam com essa finalidade) ou

com um Agente de Composição de Serviços (para pedir a composição de um serviço

adequado, quando a pesquisa por serviços não devolve resultados). Posteriormente a ter

obtido a descrição de um serviço que permite realizar a tarefa pretendida pelo Fonseca, o

AP procura um Agente de Execução de Serviços (AES) para executar o serviço

composto, e fornece-lhe as informações necessárias (parâmetros de entrada) para que este

possa realizar a execução.

A informação contextual é muito importante no processo de execução,

nomeadamente no que toca a restrições de localização e tempo por parte do Fonseca. No

história do cenário, considera-se que a situação actual do Fonseca constitui informação

importante que o AES pode usar para melhorar a execução do serviço indicado pelo AP.

Por exemplo, o AES pode usar a localização do Fonseca para tentar procurar lojas que se

encontrem perto da sua localização. Desta forma oferece um melhor serviço, pois o

Fonseca poderá ir directamente à loja indicada pelo serviço de procura da loja com o

preço do livro mais barato. Por outro lado, o AES pode também usar informação

contextual obtida através do repositório da Plataforma Genérica de Informação de

Contexto para descobrir quais os prestadores de serviço que têm um tempo de prestação

de serviço mais rápido. Desta forma, o serviço prestado é melhorado por ser mais rápido


30

e é conveniente quando existe uma restrição temporal na situação actual do utilizador,

como a citada na história (a festa de aniversário do Barbosa).

Utilizando esta informação para melhorar a execução do serviço, o AES devolve

finalmente o resultado ao AP, ainda dentro do tempo exigido pelo Fonseca. Assim, este

poderá facilmente comprar o livro na loja ali perto e ainda chegar a tempo ao aniversário.

3.2. Descrição do cenário

Nesta secção serão descritos as duas versões do cenário a utilizar na demonstração do

trabalho da tese, começando pela apresentação dos elementos constituintes de cada

cenário e em seguida, ilustrando as interacções que decorrem entre os elementos

descritos.

3.2.1. Elementos comuns às duas versões do cenário

Alguns elementos que são comuns aos dois cenários serão descritos nesta secção,

embora pequenas referências possam ser feitas noutras secções, com o intuito de ilustrar

diferenças que esses elementos poderão ter entre cenários.

3.2.1.1. Elementos intervenientes

Os elementos comuns aos dois cenários são: o Agente Pessoal, o Agente de Execução

de Serviços, o Agente de Descoberta de Serviços, o Agente de Composição de Serviços e

a Plataforma Genérica de Informação de Contexto.

Agente Pessoal. O Agente Pessoal (AP) é o agente que irá pedir a execução de um

serviço ao Agente de Execução de Serviços. Neste cenário, assume-se que o AP já obteve

a descrição do serviço a ser executado, através da interacção com agentes de descoberta

ou composição de serviços. O AP representa um determinado utilizador e realiza tarefas

no interesse do mesmo. Neste caso específico, o AP irá pedir ao Agente de Execução de

Serviços a execução de um serviço de procura das lojas que vendem determinado livro ao


31

melhor preço. A descrição OWL-S do serviço que se pretende executar é enviada ao

agente executor juntamente com o pedido de execução.

Agente de Execução de Serviços. O Agente de Execução de Serviços (AES) é o

agente que executa serviços, a pedido de agentes clientes, recorrendo à descrição dos

mesmos na ontologia de serviços OWL-S. A execução de serviços pelo AES tem

preocupações de contexto, pelo que a actividade inerente à execução de serviços é

largamente influenciada pela situação contextual na altura da execução do serviço.

Informação contextual a este nível pode ser algo como o facto dos recursos necessários à

execução do serviço não estarem disponíveis. Desta forma, o AES terá de ser capaz de se

adaptar a esta nova realidade, por exemplo terá de encontrar os recursos necessários

considerando o contexto, nomeadamente a localização do cliente e a disponibilidade dos

prestadores de serviços.

No caso específico deste cenário, o AES irá receber do Agente Pessoal (AP) uma

descrição OWL-S de um serviço de procura de livros e das lojas que os vendem ao

melhor preço (juntamente com o pedido de execução desse mesmo serviço). O AES irá

posteriormente usar essa descrição para executar o serviço e devolver o resultado ao AP.

Durante a execução deste serviço, o AES poderá ver-se limitado pela não disponibilidade

de determinado recurso (um agente ou um serviço na Web) pelo que terá de empregar

outros métodos, por exemplo através da iniciativa de pesquisa de serviços alternativos,

para conseguir levar a bom cabo a execução deste serviço. Esta procura será efectuada

por um agente de descoberta de serviços o qual considerará outros factores contextuais.

Agente de Descoberta de Serviços. O Agente de Descoberta de Serviços (ADS) é

um agente que actua como repositório (ou como intermediário de um ou mais

repositórios) de informação sobre serviços e os seus prestadores, permitindo aos seus

clientes realizar pesquisas sobre serviços ou sobre prestadores de um determinado

serviço. No cenário descrito, o ADS servirá de solução de recurso para o Agente de

Execução de Serviços (AES) quando este precisar de procurar prestadores alternativos

para um determinado serviço, cujos prestadores originais se encontrem indisponíveis. O

ADS é utilizado também pelo Agente Pessoal (AP) para procurar serviços no início do

cenário, mas essa interacção não é coberta pelo âmbito desta tese.


32

Agente de Composição de Serviços. O Agente de Composição de Serviços (ACS) é

um agente que realiza a composição de serviços a pedido de outros agentes. A

composição é realizada através de informação que um agente cliente fornece ao ACS,

nomeadamente, parâmetros de entrada e de saída que o serviço tem de usar, ou então

relativamente a pré-condições que o serviço composto tem de cumprir e efeitos que o

serviço composto tem de produzir. No cenário descrito, o ACS é usado pelo Agente de

Execução de Serviços (AES) como uma solução de recurso, quando este necessita de

criar um serviço composto novo para substituir o que o Agente Pessoal (AP) enviou

originalmente. Esta situação ocorre quando o AES se deparou com uma situação onde os

serviços necessários se encontram indisponíveis e o Agente de Descoberta de Serviços

(ADS) não consegue encontrar alternativas. O ACS é também usado pelo AP, para

produzir um serviço composto que permita ao AP satisfazer determinada necessidade que

não é satisfeita com os serviços que existem nessa altura. No entanto, esta interacção não

é abrangida pelo trabalho desta tese.

Plataforma Genérica de Informação de Contexto. A Plataforma Genérica de

Informação de Contexto (PGIC) é um sistema onde os diversos elementos do cenário

podem adquirir/fornecer informação de contexto acerca dos outros elementos ou deles

próprios. O acesso à informação de contexto pode influenciar a forma como os diversos

elementos operam no seu ambiente e interagem com os restantes elementos intervenientes

do cenário. Neste exemplo, a PGIC será usada por todos os intervenientes do cenário com

o intuito de partilhar informação de contexto que pode ser útil para a actividade dos

diversos elementos. O Agente de Execução de Serviços (AES) usará a PGIC para

recolher informação de contexto sobre o Agente Pessoal (AP) e sobre os diversos

prestadores de serviços como forma de melhorar o seu processo de execução.

3.2.1.2. Interacções entre os elementos

O cenário inicia-se com a interacção entre o Utilizador e o seu Agente Pessoal. O

Utilizador indica ao seu Agente Pessoal (AP) o título do livro que ele pretende procurar e

a unidade monetária em que pretende que o preço seja indicado. A unidade monetária

poderia ser obtida como informação de contexto através da localização do Utilizador, mas


33

para o cenário escolhido optou-se por usar esta informação explicitamente como um

parâmetro de entrada do serviço.

Após receber essa informação do Utilizador, o AP envia um pedido de execução do

serviço composto (serviço este que descreve o processo estruturado de execução do

serviço de cada um dos passos necessários – serviços atómicos – para encontrar o livro

pretendido ao preço mais baixo) ao Agente de Execução de Serviços (AES) enviando-lhe

a descrição OWL-S do serviço e os parâmetros de entrada recebidos pelo seu Utilizador.

O AES, ao receber estes dados, inicia o processo de execução do serviço, decompondo-o

nos correspondentes serviços atómicos, e impondo o fluxo de controlo especificado na

descrição do serviço composto em OWL-S.

Durante o processo de execução o AES pode contactar os outros três intervenientes

comuns do cenário: o Agente de Descoberta de Serviços (ADS), o Agente de

Composição de Serviços (ACS) e a Plataforma Genérica de Informação de Contexto

(PGIC). O recurso à interacção com a PGIC deve-se ao facto do AES usar informação de

contexto para influenciar o seu processo de execução de serviços, na tentativa de o

melhorar, seja pela rapidez, seja pelo melhor aproveitamento dos recursos disponíveis.

Como tal, a comunicação com a PGIC permitirá ao AES determinar se certos prestadores

de serviços estão disponíveis ou se o tempo de espera de execução de determinados

serviços atómicos é demasiado, tendo em conta a situação actual (por restrições de tempo

ou localização impostas pelo cliente). Em situações específicas em que é necessário

procurar prestadores de serviços alternativos (por indisponibilidade dos prestadores

originais), o AES pode recorrer à interacção com o ADS para obter alternativas que lhe

permitirão prosseguir com a execução de um serviço. Se a interacção com o ADS não for

suficiente (por este não ter conseguido encontrar alternativas para o serviço específico), o

AES pode ainda contactar o ACS para este lhe fornecer um novo serviço composto

diferente do originalmente enviado pelo AP, mas com resultado semelhante.


34

3.2.2. Versão do cenário com serviços na Web

Nesta secção é apresentada a versão do cenário em que o AES recorre unicamente a

serviços na Web como prestadores de serviços.


Esta secção apresenta detalhadamente os diversos elementos constituintes do cenário

de demonstração em que se usam serviços na Web como prestadores de serviços.

Book Finder. O Book Finder (BF) é um serviço na Web disponível no XMethods17,

um sítio público na Internet onde é possível alojar serviços na Web para estarem

disponíveis para testes e aplicações reais. Este serviço permite obter informação sobre

livros publicados, mais concretamente, saber o ISBN de um determinado livro, através do

seu título. No cenário, o serviço BF será usado para obter o ISBN correspondente ao livro

cujo título é indicado pelo Utilizador.

Barnes & Noble Price Finder. O Barnes & Noble Price Finder (BNPF) é um

serviço na Web disponibilizado pela Abundant Technologies18, uma empresa que aloja

um conjunto de serviços na Web para serem usados por utilizadores desta tecnologia. O

serviço permite obter o preço (em Dólares) de um determinado livro na conhecida

empresa de compras pela Internet, Barnes & Noble, através do ISBN do mesmo. No

cenário, o serviço será usado como uma das fontes de obtenção do preço do livro

procurado pelo Utilizador.

Amazon Price Finder. O Amazon Price Finder (APF) é um serviço na Web também

disponível no sítio da XMethods. Este serviço permite obter o preço (em Dólares) de um

determinado livro na conhecido empresa de compras pela Internet, Amazon, através do

ISBN do mesmo. No cenário, o serviço será usado como uma das fontes de obtenção do

preço do livro procurado pelo Utilizador.

17 www.xmethods.net

18 www.abundanttech.com


35

Comparação de Preços. Nesta versão do cenário, a comparação dos diversos preços

obtidos e a determinação da loja que vende o livro com o melhor preço não é feita

recorrendo a um serviço na Web. Para efectuar este passo, é necessário recorrer a uma

das facilidades de descrição de serviços em OWL-S para realizar essa comparação

internamente no serviço composto, mas sem recorrer a prestadores de serviços: o If-Then-

Else. Este mecanismo de controlo permite definir uma condição (ou conjunto de

condições) e as acções a tomar em cada um dos seus possíveis valores

(Verdadeiro/Falso). Esta descrição está incluída no serviço composto e efectua a

comparação entre os preços obtidos na pesquisa de preços do livro procurado pelo

Utilizador. Posteriormente, consoante a avaliação referida, indicará qual a loja em que o

preço do livro é menor.

Currency Converter. O Currency Converter (CC) é um serviço na Web

disponibilizado pelo Mindswap19, projecto que se dedica a promover tecnologias,

ferramentas e métodos relacionados com o avanço da Web Semântica. Este serviço

realiza a conversão de valores entre unidades monetárias. Ao nível deste cenário, o CC é

outra das fontes a utilizar pelo Agente de Execução de Serviços para obter a informação

necessária na execução do serviço requerido pelo Agente Pessoal. Neste caso específico,

o CC irá converter um determinado valor de Dólares para Euros e devolver esta

informação ao Agente de Execução de Serviços.

3.2.2.2. Execução do serviço composto

A execução do serviço composto inicia-se com o envio do pedido de execução (passo

1 da Figura 1) do Agente Pessoal (AP) para o Agente de Execução de Serviços (AES).

Em primeiro lugar, o AES contacta o serviço na Web Book Finder (BF), para o qual

envia a informação obtida do AP (o título) para obter o ISBN do livro procurado (passo 2

da Figura 1).

19 www.mindswap.org


36

Figura 1 - Cenário com serviços na Web

Após o BF devolver a informação pretendida, o AES contacta de seguida e em

simultâneo (passos 4a e 4b da Figura 1) o serviço na Web Barnes & Noble Price Finder

(BNPF) e o serviço na Web Amazon Price Finder (APF) para que estes devolvam o preço

do livro procurado pelo Utilizador. No momento em que recebe as informações (passos

5a e 5b da Figura 1) dos dois serviços na Web (BNPF e APF), o AES tem ainda de

realizar a operação de determinar qual o preço mais baixo. Este passo é realizado através

de um mecanismo de controlo If-Then-Else que compara os dois valores obtidos e indica

qual o mais baixo e qual a loja que pratica esse preço (passo 6 da Figura 1). Após obter a

informação do preço do livro, o AES precisa ainda de converter o preço devolvido (que

se encontra em Dólares) para um valor em Euros. Para isso, contacta (passo 7 da Figura

1) o serviço na Web Currency Converter (CC) o qual realiza esta conversão, devolvendo

então o preço do livro em Euros ao AES (passo 8 da Figura 1). O AES termina assim a

execução do serviço devolvendo o resultado final ao AP (passo 9 da Figura 1), o qual

apresenta, por sua vez, a informação ao seu Utilizador.

3.2.3. Versão do cenário com Agentes Prestadores de

Serviços

Nesta secção é apresentada versão do cenário em que o Agente de Execução de

Serviços recorre unicamente a agentes prestadores de serviços.


37


Esta secção apresenta detalhadamente os diversos elementos constituintes do cenário

de demonstração em que se usam agentes de informação como prestadores de serviços.

Agente de Informação Literária. O Agente de Informação Literária (AIL) é um

agente de informação que fornece informações sobre livros a outros agentes. Ao nível do

cenário, o AIL representa uma das fontes a utilizar pelo Agente de Execução de Serviços

(AES) para obter a informação necessária na execução do serviço requerido pelo Agente

Pessoal. Neste caso específico, o AIL irá fornecer ao AES o ISBN do livro que o cliente

procura.

Agente de Pesquisa de Preços. O Agente de Pesquisa de Preços (APP) é um agente

que tem a capacidade de realizar uma pesquisa de preços de diversos itens,

nomeadamente livros, em diversas fontes diferentes, tais como sítios na Web, serviços na

Web e outros agentes de informação, usando o número de identificação universal. No

caso dos livros, o APP usa o ISBN. A sua principal função é devolver o melhor preço (em

Dólares) encontrado (após pesquisa nas várias fontes) para o item desejado, juntamente

com a indicação do vendedor correspondente. Neste cenário, o APP irá fornecer ao

Agente de Execução de Serviços o melhor preço encontrado e respectivo vendedor (loja

ou representante) do livro que o Utilizador procura.

Agente de Conversão de Valores. O Agente de Conversão de Valores (ACV) é um

agente que oferece a funcionalidade de realizar a conversão entre medidas de diversos

valores, incluindo a conversão de valores de diferentes unidades monetárias. No cenário

descrito, o ACV irá realizar a conversão do preço do livro procurado pelo Utilizador de

Dólares para Euros.

3.2.3.2. Execução do serviço composto

Mais uma vez, a execução do serviço composto inicia-se com o envio do pedido de

execução (passo 1 da Figura 2) do Agente Pessoal (AP) para o Agente de Execução de

Serviços (AES).


38

Figura 2 - Cenário com Agentes Prestadores de Servi ços

Em primeiro lugar, o AES contacta o Agente de Informação Literária (AIL), para o

qual envia a informação obtida do AP (o título) para obter o ISBN do livro procurado

(passo 2 da Figura 2). No decorrer do cenário, o AES pode descobrir que o AIL não se

encontra disponível para satisfazer o seu pedido. Esta informação é recolhida através da

interacção do AES com a Plataforma Genérica de Informação de Contexto e é um

exemplo de situação contextual que influencia a execução do serviço. Para ultrapassar

esta limitação, o AES toma a iniciativa de procurar um agente alternativo que preste o

mesmo serviço ou um serviço semelhante. Esta pesquisa pode ser feita recorrendo ao

Agente de Descoberta de Serviços (ADS). Após o AIL (ou um agente alternativo que

tenha sido obtido através do ADS) devolver a informação pretendida (passo 3 da Figura

2), o AES contacta o Agente de Pesquisa de Preços (APP) para que este devolva o melhor

preço do livro procurado (e o vendedor correspondente) pelo Utilizador (passo 4 da

Figura 2). Quando o APP devolver a informação do preço do livro (passo 5 da Figura 2),

o AES precisa ainda de converter o preço devolvido (que se encontra em Dólares) para

um valor em Euros. Para isso, contacta o Agente de Conversão de Valores (ACV) o qual

realiza esta conversão (passo 6 da Figura 2) e devolve o resultado (passo 7 da Figura 2).

O AES termina a execução do serviço devolvendo o resultado final ao AP (passo 8 da

Figura 2), o qual apresenta, por sua vez, a informação ao seu Utilizador.

39

CCaappííttuulloo 44.. DDEEFFII NNII ÇÇÃÃOO CCOONNCCEEPPTTUUAALL

DDOO SSII SSTTEEMM AA

Este capítulo encontra-se organizado em duas partes principais. Na secção 4.1

realiza-se a análise de requisitos e desenho formal do sistema descrito no capítulo

anterior. Na segunda parte do capítulo, na secção 4.2, é descrita em detalhe a arquitectura

do Agente de Execução de Serviços, incluindo a descrição das funcionalidades

específicas de cada componente interno e das interacções que ocorrem entre os mesmos.

A arquitectura foi definida de acordo com os requisitos levantados no processo de

modelação do sistema.

4.1. Análise de requisitos e desenho

Nesta secção são descritos sumariamente, na subsecção 4.1.1, os diversos elementos

do sistema, numa abordagem informal de recolha de requisitos com origem no cenário de

demonstração descrito no Capítulo 3. Esta subsecção descreve o ambiente em que o

agente irá operar e os requisitos impostos por esse ambiente, nomeadamente a

necessidade de comunicar numa linguagem de comunicação normalizada e a necessidade

de seguir os protocolos de interacção adequados ao problema.

Posteriormente, na subsecção 4.1.2 realiza-se a modelação do sistema descrito no

cenário de demonstração. Em particular, propõe-se a modelação UML [Warmer &

Kleppe, 1998] relativa aos diversos elementos do cenário, incluindo diagramas de

sequência que especificam as interacções entre os elementos existentes no sistema.


40

Finalmente, na secção 4.1.3, é utilizada a norma de especificação Volere [Robertson &

Robertson, 1997] para descrever em detalhe a lista de requisitos resultantes da análise

efectuada sobre o desenho formal do sistema.

4.1.1. Requisitos do cenário e análise informal

No Capítulo 3 foram descritos os diversos elementos do sistema e as suas

interacções. Nesta secção é feita apenas uma breve descrição dos elementos relevantes no

âmbito da modelação do sistema e das interacções dos mesmos com o Agente de

Execução de Serviços e com outros elementos. Esta descrição permite criar uma base de

análise de requisitos para a secção seguinte, onde se realizará a modelação do sistema. No

cenário de demonstração descrito anteriormente, existem as seguintes classes de

elementos:

• Agente Cliente – É o agente que pede a execução de um serviço ao Agente

Executor de Serviços. O Agente Cliente pode ser qualquer agente que tem em sua

posse uma descrição OWL-S de um serviço e pretende vê-lo executado de forma

a obter o resultado do mesmo. No caso particular descrito no cenário, o cliente é o

Agente Pessoal.

• Agente de Execução de Serviços – É o agente que executa serviços através das

sua descrição em OWL-S, a pedido do Agente Cliente. A execução de serviços

compostos assenta na utilização de serviços atómicos fornecidos por prestadores

de serviços.

• Prestador de Serviços – O Prestador de Serviços pode ser um agente ou serviço

na Web que presta serviços atómicos. Os Prestadores de Serviços atómicos

podem ou não ser incluídos na descrição OWL-S de um serviço composto.

• Procura de Serviços – A procura de serviços é fornecida por Agentes de

Descoberta de Serviços e consiste no fornecimento de informação sobre serviços

disponíveis para serem fornecidos por diversos Prestadores de Serviços.

Capítulo 4 - Definição Conceptual do Sistema

41

• Composição de Serviços – A composição de serviços é fornecida por agentes de

composição de serviços e consiste na criação de serviços compostos que incluem

outros serviços (atómicos ou compostos) agregados por um modelo processual

que explicita a sua execução.

O Agente Cliente (AC) comunica com o Agente de Execução de Serviços (AES) para

pedir a execução de um determinado serviço composto. Após a execução do serviço

especificado na descrição recebida, o AES irá comunicar o resultado de volta ao Agente

Cliente, se for produzido algum resultado. Um serviço executado pode, pela sua natureza,

não devolver nenhum resultado, pelo que interessa saber apenas se este foi executado

com sucesso. Se for este o caso, o que o AES devolve ao Agente Cliente, é uma

notificação do resultado da execução do serviço (sucesso/falha).

O AES pode receber descrições de serviços compostos cujos prestadores poderão não

vir especificados, ou vindo especificados, não se encontram disponíveis na altura em que

o serviço está a ser executado. Nestas alturas o AES comunica com o Agente de

Descoberta de Serviços (ADS) para que este lhe forneça informações referentes a

prestadores alternativos. Quando a pesquisa por alternativas a prestadores de serviços que

se encontram indisponíveis não devolve os resultados necessários, o AES pode interagir

com o Agente de Composição de Serviços (ACS) para que este lhe crie um serviço

composto alternativo, mas cuja execução produza um efeito semelhante ao original. A

comunicação entre o AES e todos estes agentes rege-se segundo as especificações da

FIPA [FIPA-2, 2002], com o objectivo de permitir a total interoperabilidade entre os

mesmos. Essas especificações apresentam um conjunto de normas que visam definir a

forma como deverá ocorrer a comunicação e as interacções entre agentes. Isto inclui

normas relacionadas com protocolos de interacção, linguagens de comunicação,

linguagens de conteúdo de mensagens e ontologias. De forma a permitir a

interoperabilidade referida, o AES terá de respeitar as normas especificadas pela FIPA.

A descrição de serviços OWL-S [Martin et al, 2005], a qual é usada pelo AES para

executar o serviço, é composta por vários partes, nomeadamente, o modelo processual. O

modelo processual do serviço descreve os vários passos necessários para a execução do

mesmo. Basicamente, um serviço composto divide-se em vários serviços atómicos que


42

são prestados pelos respectivos fornecedores. O AES realiza a execução do serviço

composto comunicando com os prestadores dos serviços atómicos de acordo com o que

está descrito no modelo processual do serviço composto. Estes prestadores podem ser

serviços na Web ou Agentes Prestadores de Serviços (APS). A comunicação com estes

prestadores varia conforme o tipo dos mesmos. Se o fornecedor for um APS, então a

comunicação é regida pelas normas de especificação FIPA. Se o fornecedor for um

serviço na Web, então a comunicação é feita segundo o protocolo definido na descrição

do serviço atómico. Na descrição OWL-S do serviço atómico existe uma parte que

descreve a forma como se deve aceder ao mesmo. Esta descrição é normalmente feita

com base na linguagem WSDL [Christensen et al, 2001], [Martin et al, 2004], a qual

especifica o endereço, as operações e o protocolo que deverá ser respeitado para realizar a

comunicação com o respectivo prestador do serviço atómico. O AES tem de estar

preparado para processar essa descrição e comunicar com os Prestadores de Serviços de

acordo com o especificado em WSDL na descrição do serviço.

4.1.2. Desenho

Nesta secção é apresentada a modelação do cenário de demonstração descrito no

Capítulo 3. A modelação recorre a diagramas UML de Casos de Utilização (Use-Cases),

de Sequência e de Classes para caracterizar a estrutura e as funcionalidades do sistema, os

seus elementos concretos e as comunicações entre eles. Os diagramas UML serão

complementados com a norma de especificação Volere a qual é usada para descrever

detalhadamente os requisitos do sistema. Esta secção encontra-se organizada da seguinte

forma. Na secção 4.1.2.1, apresenta-se a modelação de actores, usando Diagramas de

Casos de Utilização. Nesta fase, considera-se que o actor é o Agente Cliente. Na secção

4.1.2.2, apresenta-se a modelação de actores a um nível de sistema, também usando

Diagramas de Casos de Utilização, sendo que nesta fase considera-se que o actor é o

Agente de Execução de Serviços. Na secção 4.1.2.3, são detalhadas as interacções entre

os diversos elementos do sistema, recorrendo a Diagramas de Sequência. Na secção

4.1.2.4 é apresentada a modelação do uso de informação de contexto por parte do Agente

de Execução de Serviços.


43

4.1.2.1. Modelação de Actores – Agente Cliente

No cenário descrito no Capítulo 3, um agente que pretenda usar um determinado

serviço composto, tem primeiro de obter a sua descrição. Numa situação típica, o Agente

Cliente (AC) pede ao Agente de Descoberta de Serviços (ADS) para este encontrar o

serviço desejado. Supondo que o ADS não encontra o serviço desejado, o AC pede ao

Agente Compositor de Serviços (ACS) para criar uma descrição procedimental do serviço

pretendido. Independentemente do processo usado para a adquirir, assume-se que o AC

possui uma descrição OWL-S do serviço composto que pretende executar. O AC usa

posteriormente essa descrição para pedir a um Agente de Execução de Serviços (AES)

que o execute e que lhe devolva o resultado.

Figura 3 – Casos de Utilização do Actor Agente Clie nte

A Figura 3 mostra o diagrama de Casos de Utilização para o actor Agente Cliente. A

interacção entre o Cliente e as funcionalidades de Procura de Serviços e Composição de

Serviços não se encontram abrangidas pelo âmbito desta tese, pelo que estas interacções

não serão descritas. Apenas os elementos a vermelho na figura pertencem ao universo do


44

Agente de Execução de Serviços. A Tabela 1 complementa a figura, identificando e

descrevendo em detalhe cada um dos Casos de Utilização do Agente Cliente.

# Caso

Utilização

Designação Descrição

UC1.1 Composição

de Serviços

Permite ao Agente Cliente usufruir de um serviço de Composição

de Serviços OWL-S. Este serviço consiste em planificar e construir

a descrição em OWL-S de um serviço composto, isto é, um serviço

que efectua diversos passos para executar uma tarefa ou conjunto

de tarefas. A Composição de Serviços pode consultar a Procura de

Serviços para encontrar serviços adequados para a composição.

UC1.2 Procura de

Serviços

Permite ao Agente Cliente procurar por serviços através de um

algoritmo de comparação (matchmaking) de Perfis de serviços. O

Agente de Descoberta de Serviços pode devolver um de dois

resultados: ou a descrição OWL-S do serviço encontrado ou a

identificação do Agente que presta o serviço encontrado.

UC1.3 Execução de

Serviços

Quando em posse de uma descrição OWL-S de um serviço, o

Agente Cliente pode requerer a execução desse mesmo serviço a

um Agente de Execução de Serviços. Este ao receber a referida

descrição irá executar o serviço e devolver o resultado ao Agente

Cliente. Por vezes, é necessário ao Agente Executor de Serviços

procurar por serviços alternativos. Para este efeito usa a Procura

de Serviços e a Composição de Serviços.

Tabela 1 - Descrição dos Casos de Utilização do Age nte Cliente

4.1.2.2. Modelação de Actores – Agente de Execução de Serviços

Neste nível da modelação do sistema, considera-se que o Actor é o Agente de

Execução de Serviços (AES). A execução de um determinado serviço composto recorre a

diversos serviços atómicos que terão de ser executados. A descrição do serviço composto

poderá incluir informação de utilização dos serviços atómicos e a identificação dos seus

prestadores. O AES usa essa informação para requerer a execução dos serviços atómicos

aos respectivos fornecedores.


45

Como mostra a Figura 4, o AES usa dois tipos de prestadores de serviço (serviços na

Web e agentes) para levar a cabo a execução dos serviços atómicos.

Figura 4 – Casos de Utilização do Actor Agente Exec utor de Serviços


46

A Tabela 2 descreve em detalhe os Casos de Utilização do AES.

# Caso de

Utilização


UC2.1 Web

Services

(Serviços na

Web)

Prestadores de Serviços Atómicos sob a forma de Serviços na

Web, fornecidos por diversas entidades diferentes e respeitando o

formato de descrição da linguagem WSDL [Christensen et al,

2001], [Martin et al, 2004].

UC2.2 Serviços

prestados por

agentes

Prestadores de Serviços Atómicos sob a forma de Agentes

Inteligentes. O Agente Executor de Serviços comunica com estes

Agentes (para usar os serviços atómicos) através da comunicação

normal entre Agentes (ACL – Agent Communication Language

[FIPA-2, 2002])

UC2.3 Procura de

Serviços

Permite ao Agente Executor de Serviços procurar por serviços

através de um algoritmo de comparação e emparelhamento

(matchmaking) de Perfis de serviços. O Agente de Descoberta de

Serviços pode devolver um de dois resultados: ou a descrição

OWL-S do serviço encontrado ou a identificação do Prestador de

Serviço que presta o serviço encontrado.

UC2.4 Composição

de Serviços

Permite ao Agente Executor de Serviços obter um novo serviço

composto, alternativo ao inicialmente enviado pelo Agente Cliente,

mas que produza os mesmos efeitos. A Composição de Serviços

faz ainda uso da Descoberta de Serviços quando é necessário

encontrar Prestadores de Serviço adequados ao serviço que

pretende compor.

Tabela 2 - Descrição dos Casos de Utilização do Age nte Executor de Serviços

4.1.2.3. Interacções entre os elementos

Nesta secção são descritas em detalhe as diversas interacções entre os elementos do

sistema descritos anteriormente. As descrições são feitas usando diagramas de sequência

UML.

Pedido de execução de serviço. A Figura 5 detalha a interacção entre o Agente

Cliente (AC), o Agente de Execução de Serviços (AES) e os Prestadores de Serviços


47

(PS). Este pedido representa uma interacção normal entre estes elementos sem

ocorrências extraordinárias. Os exemplos seguintes representam as situações em que é

necessária uma adaptação por parte do Agente de Execução de Serviços. A interacção

começa com o envio do pedido do AC ao AES. Este, ao receber o pedido, pode aceitá-lo

ou rejeitá-lo, enviando a mensagem correspondente ao AC.

Figura 5 - Pedido de execução de serviço

Como mostra a figura (através da condição imposta “Aceitou Pedido”), quando o

AES aceita o pedido, executa o serviço decompondo-o e pedindo a execução dos serviços

atómicos aos prestadores de serviços correspondentes. O número de pedidos de execução

de serviços atómicos aos prestadores de serviços na interacção, depende do serviço

especificado pelo Agente Cliente. Após a execução dos serviços atómicos de acordo com

o modelo processual do serviço composto, o AES devolve o resultado da execução ao

AC. O resultado da execução do serviço pode ser de dois tipos: ou um conjunto de

informação que representa o resultado da execução do serviço (quando a execução do

serviço é suposto devolver um resultado concreto); ou apenas uma confirmação de

execução do serviço (quando a execução do serviço não é suposto devolver um resultado


48

concreto mas apenas realizar uma acção directa sobre o seu ambiente). Caso a execução

do serviço falhe por alguma razão, o AES comunica a falha ao AC juntamente com a

razão para a mesma ter ocorrido. No caso da execução do serviço ter decorrido com

sucesso, o AES devolve o seu resultado (ou simplesmente a confirmação de execução do

serviço) ao AC através da comunicação especificada na Figura 5.

Pedido de execução de serviço com Prestadores de Serviços não especificados. A

descrição OWL-S do serviço que é enviada ao Agente de Execução de Serviços (AES)

para execução, pode não especificar os Prestadores de Serviços (PS) dos serviços

atómicos usados no serviço composto. O AES interpreta esta situação como uma

alteração no contexto do ambiente de execução de serviços. Neste caso, terá sido uma

limitação de quem produziu a descrição OWL-S do serviço. Por exemplo, o agente que

construiu a descrição OWL-S do serviço não foi capaz de encontrar os PS adequados.

Este é um exemplo concreto de mudança de contexto ao qual o AES terá de se adaptar e

encontrar uma solução alternativa. Quando a descrição do serviço composto não inclui a

especificação dos PS, assume-se que o Agente Cliente (AC) está, implicitamente, a pedir

ao AES que complete a descrição e a execute de seguida. Como tal, o AES deverá

encarregar-se de completar a descrição do serviço, procedendo ele próprio à pesquisa dos

prestadores de serviços adequados.


49

A Figura 6 detalha todo o processo de execução de um serviço composto quando os

PS não se encontram especificados na descrição em OWL-S.

Figura 6 - Pedido de execução de serviço com presta dores de serviços não especificados

Perante a situação relatada, o AES pede a um ou mais Agentes de Descoberta de

Serviços para encontrar prestadores de serviços que forneçam os serviços atómicos que

compõem o serviço composto.

Pedido de execução de serviço cujos Prestadores de Serviços se encontram

indisponíveis. Outras vezes, apesar da descrição OWL-S do serviço estar completa com a


50

descrição dos Prestadores de Serviços (PS) necessários, estes poderão estar indisponíveis

no momento em que o Agente de Execução de Serviços (AES) os tenta usar. Nesta

situação, o AES já não deve assumir que o Agente Cliente (AC) pretende que ele procure

PS alternativos. Antes de realizar a pesquisa referida, o AES terá de perguntar ao AC se o

autoriza a prosseguir a execução do serviço, usando PS alternativos. Esta negociação é

feita através do pedido de autorização para procurar novos PS e submetendo-os à

aprovação do AC. Este é mais um exemplo de adaptação do AES a uma nova realidade

originada pela introdução de um contexto específico. A Figura 7 detalha esta situação

extraordinária em que o AES, antes de prosseguir com a execução do serviço (quando se

apercebe que alguns dos PS se encontram indisponíveis), pergunta ao AC se o autoriza a

procurar alternativas.


51

Tal como evidenciado na Figura 7, o AES só prossegue a execução do serviço se

obtiver uma resposta afirmativa da parte do AC no que toca ao pedido de autorização

para procurar novos PS. Após a resposta afirmativa do AC, o AES realiza a pesquisa de

PS alternativos para os Serviços Atómicos que integram o serviço composto especificado.

Figura 7 - Pedido de execução de serviço com Presta dores de Serviços indisponíveis


52

Se a pesquisa não devolver PS alternativos (por não existirem), o AES comunica ao

AC que não é possível continuar a execução do serviço. Se forem encontradas

alternativas, o AES apresenta-as, uma a uma, ao AC para tentar obter respostas

afirmativas, no que toca ao pedido de aprovação das mesmas20. Após este processo de

negociação, se obtiver aprovação de todos os PS alternativos, o AES retoma a execução

do serviço composto especificado. No entanto, se o AC não aprovar algum dos PS

alternativos apresentados, o AES poderá proceder a uma nova pesquisa de alternativas.

Se assim for, será necessário proceder a um novo processo de aprovação dos PS

alternativos. Embora exista a possibilidade de esta interacção dar origem a um ciclo do

qual estes agentes poderão não sair, o ciclo será terminado, como indica a Figura 7,

quando a pesquisa de serviços não devolver resultados.

Pedido de execução de serviço com necessidade de compor novo serviço.

Anteriormente, foram descritas as situações em que é necessário recorrer ao Agente de

Descoberta de Serviços (ADS) para obter prestadores de serviços alternativos para

continuar a execução do serviço. Por vezes, o ADS pode não conseguir descobrir as

alternativas necessárias. Nesta altura, a outra opção do Agente de Execução de Serviços

(AES) é contactar um Agente de Composição de Serviços (ACS) para que este crie um

novo serviço composto que faça o mesmo que o serviço original, mas com novo modelo

processual e/ou novos serviços atómicos e respectivos prestadores. Esta situação é em

tudo semelhante à descrita anteriormente, onde o AES pede ao ADS para encontrar

outros prestadores e posteriormente pede a aprovação dos resultados obtidos ao Agente

Cliente (AC). Nesta situação, é usada a mesma ideia de interacção21, onde o AES

contacta o ACS para compor um novo serviço e após receber o resultado, envia-o para o

AC para este aprovar. Após receber a resposta do AC, caso seja afirmativa, o AES pode

20 A forma como o Agente Cliente realiza a aprovação dos PS alternativos não é abrangida pelo

âmbito desta tese. Uma sugestão possível é o uso de um serviço de reputação de PS que

ajudasse o AC a tomar esta decisão.

21 Devido ao nível de semelhança com a interacção referida anteriormente, esta secção não terá

um diagrama de sequência explicativo das interacções entre os elementos.


53

continuar a execução do serviço. Caso o AC rejeite a proposta do AES, a execução falha

e o processo pára.

4.1.2.4. Utilização de informação de contexto

O Agente de Execução de Serviços consulta informação de contexto relativa ao seu

ambiente para incorporar na sua actividade, de forma a que possa executar os serviços da

melhor forma possível para o Agente Cliente. Nesta fase, considera-se a existência de um

Subsistema de Informação de Contexto que oferece a capacidade de obter, monitorizar e

processar informação de contexto que está ligada ao ambiente sobre o qual os agentes

operam. A Figura 8 ilustra as dependências existentes entre as funcionalidades

anteriormente referidas. Mais uma vez, a incidência desta análise será sobre a “Execução

de Serviços”. As interacções entre a “Execução de Serviços” e as “Descoberta de

Serviços” e “Composição de Serviços” foram descritas na secção 4.1.2.3. Nesta secção

apenas será detalhada a interacção entre a “Execução de Serviços” e o “Subsistema de

Contexto”.

Figura 8 - Dependências das funcionalidades

A necessidade de adaptar a execução de um determinado serviço a uma realidade ou

ambiente específico surge do facto de existirem determinadas situações que obrigam à

modificação de parte da actividade do agente. Exemplo destas situações são: a

indisponibilidade de prestadores de serviços e a necessidade de procurar alternativas;

largura de banda reduzida obrigando a que as comunicações entre o AES e o cliente


54

estejam limitadas a determinadas velocidades e/ou conteúdos; localização do cliente que

pode influenciar a forma ou o conteúdo do serviço que é prestado.

Figura 9 - Casos de Utilização - AES e Subsistema d e Contexto

A Figura 9 reflecte o conjunto de Casos de Utilização do AES sobre a utilização do

Subsistema de Informação de Contexto. Através da interacção com este Subsistema o

AES poderá obter informação de contexto sobre si próprio ou sobre os seus Agentes

Cliente.


55

A Tabela 3 descreve em detalhe os Casos de Utilização ilustrados na Figura 9.

# Caso

Utilização


UC3.1 Pedido

Contexto

Cliente

O AES pode realizar uma conversação com o Agente Cliente

para obter informação concreta sobre o seu contexto de forma a

prestar um serviço mais adequado e completo.

UC3.2 Processamento

Informação

Contexto

O AES pode usar o Subsistema de Contexto para processar

determinada informação de contexto. Esta pode ser informação

de contexto sobre si próprio ou sobre os Agentes aos quais

presta o serviço de execução.

UC3.3 Monitorização

Informação

Contexto

A Monitorização de Informação de Contexto é uma extensão do

Processamento da Informação de Contexto. Isto permite ao AES

monitorizar um determinado ambiente para captar alterações de

contexto que influenciem a sua actividade de execução.

UC3.4 Obtenção

Informação

Contexto

A Obtenção de Informação de Contexto é usada pelos restantes

Casos de Utilização como uma forma transparente de obter a

informação de contexto num determinado formato uniforme. A

informação é obtida através da Leitura de Sensores.

UC3.5 Leitura

Sensores

Este Caso de Utilização reflecte o acesso a sensores de

captação de informação de contexto. Estes sensores podem ser

de vários tipos e captar informação tão variada como

temperatura, localização, orientação, batimento cardíaco e ruído.

Tabela 3 - Descrição dos Casos de Utilização do AES sobre o Subsistema de Contexto

4.1.3. Lista de requisitos

Nesta secção são apresentados os requisitos retirados da análise realizada sobre o

cenário de demonstração e a modelação do sistema. Os requisitos foram definidos através

da norma de especificação Volere e são apresentados através de uma tabela para

descrição dos requisitos. Devido à extensão da descrição dos mesmos esta análise é

apresentada em anexo e nesta secção é apenas feita uma breve descrição de cada um dos


56

requisitos obtidos. A listagem completa dos requisitos assim como uma descrição

detalhada dos mesmos é apresentada no Anexo B (Listagem de Requisitos do Sistema).

Da análise realizada ao cenário de demonstração e da modelação efectuada na secção

anterior, diversas necessidades surgem que influenciam o desenvolvimento do Agente de

Execução de Serviços (AES). O primeiro requisito (R1) representa a necessidade do AES

ser capaz de executar serviços que contemplem qualquer mecanismo de controlo do

OWL-S. Por outro lado, é necessário também que o AES seja capaz de comunicar com

qualquer tipo de prestadores de serviços, sejam estes serviços na Web ou Agentes

Prestadores de Serviços, tal como descreve o segundo requisito (R2).

O terceiro requisito (R3) reflecte a necessidade de adaptação do AES perante

alterações relacionadas com os prestadores de serviços, indicando que este têm de

conseguir interagir com Agentes de Descoberta e Composição de Serviços. O requisito

R4 complementa o R3, indicando que face à possibilidade de surgirem novos prestadores

de serviços por consequência da Procura ou Composição de Serviços, o AES tem de ser

capaz de interagir com o Agente Cliente para requerer a aprovação deste sobre as

alternativas obtidas. Todos estes requisitos dependem do facto do AES precisar de obter e

processar informação de contexto, facto que se encontra descrito nos requisitos R5 e R7.

Estes requisitos são complementados pelo requisito R6 que indica a possibilidade do AES

ter de obter informação de contexto sobre o cliente. Apesar de todos estes requisitos que

reflectem as necessidades do processo de execução levado a cabo pelo AES, este tem

também de ter uma interacção simples com o cliente, isto é, o interface do AES com o

cliente deverá ser o mais simples possível para evitar que este necessite de capacidades

especiais para comunicar com o AES. Esta necessidade é descrita no requisito R8.

O requisito R9 aborda o problema da rapidez da execução de serviços, descrevendo a

necessidade da execução de serviços do AES dever ser rápida ao ponto de ser útil para o

cliente. O requisito R10 segue na linha do R9, descrevendo a necessidade do AES ser

robusto, escalável e encontrar-se sempre disponível. Finalmente, o requisito R11 descreve

a necessidade do AES cumprir com as especificações da FIPA. Este requisito reflecte a

necessidade de interoperabilidade entre os diversos elementos do sistema descrito.


57

4.2. Definição da arquitectura do Agente de

Execução de Serviços

Nesta secção é descrita a arquitectura interna do Agente de Execução de Serviços

(AES). Na secção 4.2.1, descrevem-se os componentes internos separadamente. Na

secção 4.2.2 descrevem-se os fluxos de comunicação que ocorrem entre os componentes

descritos na secção 4.2.1. Os componentes descritos visam preencher os requisitos

levantados pelo ambiente e que estão descritos na secção anterior (ver secção 4.1). Ao

longo desta secção é feita a correspondência entre os requisitos definidos e as opções de

definição da arquitectura do Agente.

4.2.1. Descrição dos Componentes

Nesta subsecção são descritos os componentes internos do Agente de Execução de

Serviços (AES). Para cada componente é apresentado o seu papel esperado. O AES

divide-se em 3 componentes internos: o Componente de Interacção com Agentes

(responsável pela interacção com outros agentes), o Componente de Motor do Agente

(responsável pelas decisões e controlo interno da actividade do Agente e acesso à

informação de contexto) e o Componente de Execução de Serviços (responsável pela

execução concreta dos serviços). Estes componentes são descritos detalhadamente nas

subsecções seguintes.

4.2.1.1. Componente de Interacção com Agentes

Este componente visa equipar o AES com a capacidade de interactuar com Agentes

compatíveis com as especificações FIPA. Este componente tem como base os requisitos

R3, R8 e R11. O componente oferece funcionalidades como:

• Comunicação – o agente envia e recebe mensagens segundo as normas de

comunicação da FIPA


58

• Processamento de mensagens – o agente processa as mensagens recebidas

através da análise sintáctica da linguagem de comunicação e da linguagem de

conteúdo definidas nas especificações da FIPA

• Protocolos – o agente rege a sua actividade e a sua interacção com outros agentes

através dos protocolos de interacção definidos pela FIPA e pelo próprio agente.

• Ontologias – o agente interpreta os dados que tem ou que recebe através de

ontologias que definem o significado de determinados conceitos.

• Bases de dados – o agente interpreta mensagens com uma sintaxe especial como

sendo comandos de acesso a bases de dados.

No geral, este componente servirá para receber as mensagens dos agentes clientes

(que pretendem a execução de um determinado serviço composto), processá-las e

entregá-las ao motor do agente para que este determine qual deverá ser a restante

actividade do agente. Por outro lado, o componente pode ser usado para comunicar com o

Agente de Descoberta de serviços ou com os Agentes Prestadores de Serviços, uma vez

que estes são Agentes compatíveis com as especificações da FIPA.

4.2.1.2. Componente de Motor do Agente

Este componente funciona como o “cérebro” do agente, uma vez que rege a

actividade dos restantes componentes. O motor rege a actividade do agente e dos seus

componentes internos, determinando qual os passos que estes deverão executar em cada

altura do ciclo de vida do agente. Este componente é também responsável pela recolha,

análise e utilização de informação de contexto nas diversas fases do processo de

execução, onde esta se evidencie relevante, tal como descrito nos requisitos R5, R6 e R7.

4.2.1.3. Componente de Execução de Serviços

O componente de execução permite ao agente executar os serviços compostos, cujas

descrições recebe dos agentes clientes. Este componente tem de cumprir diversos

requisitos dos enunciados anteriormente, nomeadamente, os requisitos R1 e R2. Este


59

componente, quando recebe uma descrição OWL-S de um serviço, realiza os seguintes

passos para o executar:

1. Verifica se as pré-condições do serviço especificadas no perfil da descrição são

verdadeiras. Se forem, a execução poderá continuar. Caso contrário, o agente tem de

notificar o cliente de que a execução não foi possível porque as suas pré-condições

não se encontram satisfeitas. A avaliação das pré-condições está dependente do facto

do Agente conseguir executar instruções condicionadas, cumprindo assim o requisito

R1.

2. Após a verificação das pré-condições, o componente decompõe o serviço composto

nos vários passos que tem de executar individualmente. Estes passos são

normalmente serviços atómicos que estão organizados por elementos de natureza

procedimental, nomeadamente, sequências, execução paralela de procedimentos,

instruções condicionadas (“If-Then-Else”) ou instruções de repetição (e.g., “Repeat-

Until”).

3. Executando o procedimento especificado na descrição do serviço, o componente

comunica com cada um dos prestadores de serviços atómicos para pedir a execução

dos mesmos. A diversidade dos prestadores de serviços, coberta pelo requisito R2,

tem de ser tida em conta nesta fase da execução do serviço. Ou seja, o Agente tem de

ser capaz de invocar qualquer tipo de prestador de serviço. Para cada serviço

atómico, o componente precisa de verificar se a sua execução tem sucesso, pois caso

contrário, a execução do serviço composto falha. Novamente, nestes casos, será

necessário notificar o cliente.

3.a Se eventualmente, os prestadores de serviços se encontrarem indisponíveis

ou não estiverem especificados na descrição OWL-S do serviço, o

componente deverá requisitar que o Componente de Interacção com Agentes

comunique com o Agente de Descoberta de Serviços para obter a

informação necessária sobre prestadores de serviços alternativos.


60

3.b Se igualmente, este componente obtiver da parte do Componente de Motor

do Agente, informação contextual que implique a alteração do processo de

execução do serviço, tem também de realizar os ajustes necessários.

4. Quando todos os serviços atómicos foram executados de acordo com o plano

definido (através da verificação dos efeitos do serviço, em comparação com o

resultado), o resultado do serviço composto é enviado ao Agente Cliente.

4.2.2. Interacção entre os componentes

Os componentes descritos na secção anterior representam a arquitectura interna do

Agente de Execução de Serviços (AES). Esses componentes interagem entre si para levar

a cabo a execução de serviços a pedido de agentes clientes. A Figura 10 apresenta um

diagrama explicativo das interacções que ocorrem entre os componentes de acordo com

um exemplo da execução de um serviço.

Figura 10 - Interacções entre os componentes intern os do agente


61

De acordo com a Figura 10, o processo inicia-se quando um Agente Cliente envia um

pedido de execução de um serviço composto ao AES (passo 1). Sendo que esta

comunicação é feita segundo as normas especificadas pela FIPA (exigido pelo requisito

R11), o Componente de Interacção com Agentes (CIA) do agente recebe a mensagem e

realiza o pré-processamento associado (realiza a análise sintáctica da mensagem e

transforma-a numa estrutura de dados processável pelo Componente Motor do Agente).

Posteriormente, o CIA envia essa estrutura de dados (passo 2) para o Componente Motor

do Agente (Motor). O CIA é também responsável por realizar o processo inverso: receber

o resultado da execução do serviço (passo 9) e transformar na estrutura adequada para

enviar como mensagem para o Agente Cliente (passo 10).

O Motor processa a estrutura de dados recebida, retirando a descrição OWL-S da

mesma. Esta descrição é pré-processada e após recolher informação de contexto relevante

(passo 3) é enviada (passo 4) para o Componente de Execução de Serviços (CES) para

que este possa realizar a execução do serviço composto. Alternativamente, se o Motor,

após análise da informação contextual (exigido pelos requisitos R5, R6 e R7), decidir que

é necessário proceder à descoberta de alternativas de serviços, é enviado um pedido ao

CIA para este contactar um Agente de Descoberta de Serviços (exigido pelo requisito R3)

ou um Agente de Composição de Serviços (passos *). Durante o processo de execução, o

Motor é também responsável por fornecer informação contextual à Plataforma Genérica

de Informação de Contexto, seja acerca de si mesmo (tempos médios de execução e

actualização da lista de pedidos), seja acerca de outras entidades com quem interagiu,

como os Prestadores de Serviços (disponibilidade e tempo médio de execução).

O plano de execução do serviço composto consiste numa especificação que descreve

o fluxo de controlo da execução de um conjunto de serviços atómicos (prestados por

serviços na Web ou Agentes Prestadores de Serviços). O CES utiliza este plano de

execução para executar o serviço. A execução do serviço consiste em comunicar com os

Prestadores de Serviços atómicos (serviços na Web e Agentes Prestadores de Serviço) e

pedir a execução dos respectivos serviços atómicos (passos 5.a e 5.b) de acordo com o

fluxo de controlo especificado na descrição do serviço. A interacção entre o CES e os

Agentes Prestadores de Serviço (APS) é feita através do CIA, uma vez que são Agentes


62

FIPA e a comunicação com eles terá de ser feita recorrendo às normas de especificação

publicadas por esta instituição (ver requisitos R2 e R11). Os prestadores de serviços

atómicos, após receberem os pedidos do componente de execução do agente, enviam as

suas respostas de volta (passos 6.a e 6.b). Novamente, o passo 6.b representa a interacção

indirecta entre o CES e os AFS, porque esta é feita através do CIA.

Após a execução do serviço específico e da agregação dos seus resultados, o CES

envia-os para o Motor (passo 7) para posterior análise e pós-processamento, que inclui

enviar informação de contexto recolhida durante o processo de execução para a

plataforma genérica de informação de contexto (passo 8) e enviar os resultados para o

Agente Cliente (através do CIA – passos 9 e 10).

63

CCaappííttuulloo 55.. EEXXTTEENNSSÕÕEESS ÀÀ

OONNTTOOLL OOGGII AA DDEE DDEESSCCRRII ÇÇÃÃOO EE

EEXXEECCUUÇÇÃÃOO DDEE SSEERRVVII ÇÇOOSS

O presente capítulo, que descreve a implementação dos contributos específicos da

tese, inicia-se com uma descrição detalhada da ontologia de serviços escolhida, o OWL-

S. Posteriormente, são apresentadas as duas extensões realizadas: o AgentGrounding

[Lopes & Botelho, 2005], que permite a especificação da Instanciação de serviços que

são fornecidos por Agentes Prestadores de Serviços; e a utilização da linguagem lógica

Prolog para descrever expressões condicionais usadas na definição de instruções

condicionadas. Neste capítulo são também descritas as extensões realizadas à OWL-S

API (software utilizado para a execução de serviços) correspondentes às necessidades

levantadas pelas extensões realizadas ao nível da ontologia de serviços, nomeadamente a

geração de mensagens a partir do AgentGrounding, e a interpretação e avaliação de

expressões em Prolog.

A implementação concreta do Agente de Execução de Serviços e dos restantes

elementos descritos no cenário de demonstração, encontra-se descrita no Capítulo 6

(Implementação).

5.1. Ontologia de serviços OWL-S

O OWL-S fornece um conjunto de classes e propriedades básicas para declarar e

descrever serviços, isto é, uma ontologia para descrever serviços na Web que permite que


64

agentes de software possam automaticamente descobrir, compor, invocar e monitorizar

recursos da Internet que fornecem serviços específicos. O OWL-S pretende abranger a

descrição de serviços num sentido lato, pelo que não se concentra num domínio

específico de aplicação ou problema.

A ontologia está dividida em três partes: o Perfil do serviço (Service Profile) que

pode ser usado para anunciar e descobrir serviços; o Modelo Processual do serviço

(Service Process Model) que descreve detalhadamente o funcionamento de um serviço; e

a Instanciação do serviço (Service Grounding) que fornece detalhes sobre como utilizar o

serviço, através do uso de mensagens trocadas com prestadores específicos.

Figura 11 - Infra-estrutura de serviços na Web Semâ ntica

Como mostra a Figura 11, as partes que compõem um serviço OWL-S são usadas em

operações distintas da infra-estrutura da Web Semântica: o Perfil é usado para permitir a

descoberta do serviço; o Modelo Processual é usado na composição e execução de

serviços; e a Instanciação é usada na execução do serviço para a invocação do respectivo

prestador do serviço.

5.1.1. Perfil do Serviço

O Perfil de um serviço OWL-S explica concretamente o que o serviço faz,

apresentando os parâmetros que recebe como entrada e saída, as pré-condições e os

efeitos (alterações que o serviço realiza no ambiente no qual opera). O Perfil descreve

Capítulo 5 - Extensões à Ontologia de Descrição e Execução de Serviços

65

ainda algumas propriedades adicionais como a Categoria do serviço, que classifica o

serviço segundo uma determinada taxinomia classificativa22; e os Parâmetros do serviço,

que permitem adicionar características específicas ao serviço que não estejam cobertas

pela restante descrição do Perfil.

5.1.2. Modelo Processual do Serviço

O Modelo Processual descreve a forma como o serviço funciona apresentando o

conjunto de processos que o mesmo terá de executar para que o serviço seja prestado. Os

processos que compõem o serviço podem ser de 3 tipos: Atómicos, Simples e Compostos.

Os Processos Atómicos são directamente invocáveis (usando as mensagens

apropriadas), não têm sub-processos e executam-se através de um único passo (no que

toca à entidade que pede a execução deste serviço). Isto é, precisam de uma mensagem de

entrada (Input), processam-na e devolvem como resposta uma mensagem de saída

(Output). A cada Processo Atómico terá de estar associada uma Instanciação (Grounding)

que explica a interacção necessária (isto é, a mensagem que deverá ser enviada para o

prestador de serviço correspondente e a consequente resposta). Os Processos Simples não

são invocáveis e não têm uma Instanciação (Grounding) associada, mas tal como os

Processos Atómicos, são concebidos para ter uma execução com um único passo. Os

Processos Simples são usados como elementos de abstracção; podem ser usados quer

para fornecer uma visualização de (uma forma especializada de usar) alguns Processos

Atómicos, quer para fornecer uma representação simplificada de alguns Processos

Compostos (quando o objectivo é planear ou raciocinar sobre um serviço). Processos

Compostos podem ser decompostos noutros processos (compostos ou não). A sua

decomposição pode ser feita recorrendo a estruturas de controlo (Control Constructs) tal

como Sequência (Sequence – executar processos em sequência) e Acção Condicionada

(If-Then-Else – executar processos segundo determinadas condições). Por sua vez, estas

estruturas de controlo contêm Processos Atómicos e/ou Simples que são utilizados.

22 O OWL-S não restringe esta classificação por taxinomias a nenhum domínio em particular. No

desenvolvimento de serviços, esta classificação fica ao cargo dos programadores.


66

5.1.3. Instanciação do Serviço

A Instanciação (Grounding) especifica os detalhes de como aceder a um serviço.

Estes detalhes consistem em informação como protocolos, formatos de mensagens,

serialização, transporte e endereços. No caso do OWL-S e dos Serviços na Web, a

proposta para a Instanciação de um Serviço consiste em usar a linguagem de descrição

WSDL [Christensen et al, 2001], [Martin et al, 2004], tal como mostra a Figura 11. Esta

linguagem usa uma especificação XML e permite descrever o interface de utilização de

um serviço na Web. A ligação existente entre o OWL-S e o WSDL consiste num

mapeamento que se estabelece entre Processos Atómicos e Operações, e entre Parâmetros

de Entrada (Inputs) e de Saída (Outputs) e Mensagens. Quer isto dizer, que para cada

Processo Atómico de um determinado serviço OWL-S deverá haver uma descrição

WSDL do serviço na Web correspondente que permitirá fazer uso do mesmo.

5.2. Extensões ao OWL-S

Nesta secção são descritas as extensões realizadas tanto à linguagem OWL-S como à

ferramenta utilizada que permite a execução de serviços descritas na linguagem referida,

a OWL-S API. Foram realizadas duas extensões: o AgentGrounding, uma extensão que

permite especificar, na Instanciação de um serviço OWL-S, o acesso a serviços

fornecidos por Agentes Prestadores de Serviços; e a utilização do Prolog para especificar

expressões condicionais nos mecanismos de controlo do OWL-S que assim o exijam.

5.2.1. Extensão AgentGrounding

O OWL-S definiu que a Instanciação de um serviço atómico (Grounding) deve ser

feita através da linguagem de descrição de serviços na Web, WSDL. Porém, a

especificação desta parte de um serviço OWL-S não se encontra limitada a esta

linguagem, pelo que é permitido realizar extensões ao OWL-S que possibilitem a

especificação de outro tipo de prestadores de serviços atómicos, para além de serviços na

Web. A própria OWL-S API oferece o suporte para a especificação de serviços atómicos


67

UPnP23 e a especificação de serviços que se encontrem acessíveis sob a forma de

métodos Java.

A linguagem WSDL descreve o acesso a serviços de rede, como por exemplo, os

serviços acessíveis através do protocolo de comunicação SOAP24 (ver Figura 11). Porém,

falta-lhe a expressividade necessária para representar interacções com entidades mais

complexas, como é o caso dos agentes. Num cenário como o descrito no trabalho desta

tese, evidencia-se necessária a especificação de interacções mais complexas com

prestadores de serviços como os Agentes Prestadores de Serviços. Com este fim em vista,

foi criada a extensão AgentGrounding, que possibilita a especificação da forma de

interacção com um Agente Prestador de Serviço descrito.

Esta extensão surge no seguimento do requisito R2 apresentado no Capítulo 4 e

resulta de uma análise dos requisitos necessários para interagir com agentes quando se

realiza a invocação de serviços atómicos. A definição AgentGrounding descreve um

Agente Prestador de Serviços através dos seguintes elementos:

• agentName – o nome do agente prestador de serviço - String

• agentAddress – o endereço do agente prestador de serviço - String

• serviceName – nome do serviço a ser invocado - String

• serviceType – tipo do serviço a ser invocado. Este pode ser de vários tipos: acções

(action), perguntas (query) - String

• hasArgumentParameter – usado para representar os argumentos de entrada de um

serviço

o argumentType – tipo do argumento (string, integer, float, boolean) - String

o owlsParameter – referência para um parâmetro definido no serviço OWL-S

– OWL-S Parameter

23 UPnP é uma iniciativa industrial que visa facilitar a conectividade entre dispositivos e

computadores de diferentes fabricantes

24 SOAP é uma especificação de um formato de mensagem que define um método uniforme de transportar dados numa sintaxe XML


68

o paramIndex – ordem pela qual o argumento aparece na invocação do

serviço - Integer

• serviceOutput – usado para representar os resultados de um serviço

o argumentType

o owlsParameter

• protocol – protocolo de interacção para ser usado na invocação do serviço - String

• serviceOntology – ontologia que descreve os termos usados na interacção com o

agente prestador do serviço - String

• agentCommunicationLanguage – linguagem de comunicação de agentes usada para

comunicar com o agente (FIPA-ACL [FIPA-2, 2002], KQML [Finin, Labrou &

Mayfield, 1997]) - String

• contentLanguage – linguagem de conteúdo usada na comunicação com o agente

(FIPA-SL [FIPA-2, 2002], KIF [Genesereth, 1998]) - String

A Figura 12 é um exemplo da Instanciação de um serviço fornecido por um agente,

usando a proposta de especificação AgentGrounding. O exemplo ilustra um serviço,

fornecido por um agente compatível com as normas FIPA, de procura de livros através de

um título fornecido como parâmetro de entrada.

<agentGrounding:AgentAtomicProcessGrounding rdf:ID="BookFinderProcessGrounding"> <grounding:owlsProcess rdf:resource="#BookFinderP rocess"/> <agentGrounding:agentName> [email protected] </agentGrounding:agentName> <agentGrounding:agentAddress> http://localhost:9669/acc </agentGrounding:agentAddress> <agentGrounding:serviceName> find-book</agentGrounding:serviceName> <agentGrounding:hasArgumentParameter> <agentGrounding:ArgumentParameter rdf:ID="input -string"> <agentGrounding:argumentType> java.lang.String</agentGrounding:argumentTy pe> <agentGrounding:owlsParameter rdf:resource="# InputString"/> <agentGrounding:paramIndex>1</agentGrounding: paramIndex> </agentGrounding:ArgumentParameter> </agentGrounding:hasArgumentParameter> <agentGrounding:serviceOutput>


69

<agentGrounding:ArgumentVariable rdf:ID="book-i nfo"> <agentGrounding:argumentType> java.lang.String</agentGrounding:argumentTy pe> <agentGrounding:owlsParameter rdf:resource="# BookInfo"/> </agentGrounding:ArgumentVariable> </agentGrounding:serviceOutput> <agentGrounding:serviceType>action</agentGroundin g:serviceType> <agentGrounding:protocol>fipa-request</agentGroun ding:protocol> <agentGrounding:agentCommunicationLanguage> fipa-acl</agentGrounding:agentCommunicationLang uage> <agentGrounding:contentLanguage> fipa-sl</agentGrounding:contentLanguage> <agentGrounding:serviceOntology> book-finder-ontology</agentGrounding:serviceOnto logy> </agentGrounding:AgentAtomicProcessGrounding>

Figura 12 - Exemplo de especificação AgentGrounding

O exemplo ilustrado na Figura 12 descreve um serviço chamado

BookFinderService , cuja invocação é feita através da acção find-book . Esta acção

aceita como argumento um parâmetro do tipo String com nome input-string . Este

argumento está associado ao parâmetro de entrada InputString da descrição OWL-S. A

acção devolve o resultado book-info , que por sua vez está associado ao parâmetro

BookInfo da descrição do serviço. Outras informações que podem ser extraídas da

especificação incluem o protocolo de comunicação (fipa-request ), a linguagem de

comunicação de agentes (fipa-acl ), a ontologia (book-finder-ontology ) e a

linguagem de conteúdo (fipa-sl ) a serem usados na mensagem de invocação do serviço.

A especificação descrita é usada para criar mensagens para serem enviadas a Agentes

Prestadores de Serviços. O processo que realiza essa conversão é baseado no algoritmo

com os seguintes passos:

• Construção da mensagem de acordo com a linguagem de comunicação de agentes a

utilizar (agentCommunicationLanguage )

o Definição do acto comunicativo através do tipo de serviço (serviceType )

o Construção do cabeçalho da mensagem

� Definir o Destinatário (agentName , agentAddress ) e o Remetente

(o Agente de Execução de Serviços)


70

o Construção do conteúdo de acordo com o tipo de serviço (serviceType ) e

linguagem de conteúdo (contentLanguage ) a utilizar

� Construção da estrutura do conteúdo de acordo com a linguagem de

conteúdo a utilizar (contentLanguage )

� Mapeamento entre os valores fornecidos (owlsParameter ) e os

argumentos fornecidos (ArgumentParameter )

� Atribuição dos valores fornecidos (owlsParameter ) aos argumentos

no conteúdo da mensagem

o Construção do resto do corpo da mensagem usando as propriedades

restantes (protocol , serviceOntology , contentLanguage )

A extensão feita à OWL-S API permite a execução de especificações como a

ilustrada na Figura 12, através da transformação desta especificação na mensagem FIPA

ilustrada na Figura 13.

(REQUEST :sender (agent-identifier :name [email protected] -mind.org) :receiver (set (agent-identifier :name [email protected] -mind.org)) :content "((action (agent-identifier :name [email protected] :addresses (set http://localhost:9669/acc)) (find-book :input-string \"Da Vinci Code\"))) " :language fipa-sl :ontology book-finder-ontology :protocol fipa-request :conversation-id SEA-AGR-CID-1117800292257)

Figura 13 - Mensagem FIPA gerada a partir do AgentGrounding

A informação extraída do AgentGrounding, juntamente com a informação dos

parâmetros de entrada do serviço OWL-S, permite criar a mensagem ilustrada na Figura

13. Neste caso, o parâmetro de entrada utilizado foi a String “Da Vinci Code ”. A

especificação AgentGrounding possibilita a representação de diversas instâncias de

mensagens que podem ser enviadas para agentes, incluindo o uso de actos comunicativos

e linguagens de comunicação e conteúdo diferentes.


71

A invocação do serviço é feita através do envio de uma mensagem directamente ao

agente que presta o serviço. Toda a informação que é necessária para enviar a mensagem

é incluída na descrição AgentGrounding. A extensão realizada na OWL-S API para

fornecer o suporte para este tipo de representação, foi implementada utilizando a infra-

estrutura de comunicação dos componentes XSP. Desta forma, o Componente de

Execução de Serviços pode enviar o pedido (de envio de mensagem para um agente

fornecedor de serviços) ao Componente de Interacção com Agentes.

5.2.2. Extensão para Expressões Condicionais

A limitação do uso de expressões condicionais sofreu, no decurso do trabalho da tese,

uma alteração. A mais recente versão do OWL-S indica que se pode usar qualquer

linguagem desejada para especificar expressões condicionais na descrição do serviço,

mas esta aconselha o uso da linguagem SWRL [Horrocks et al, 2004]. Com o intuito de

permitir o uso dessa linguagem na descrição e execução de serviços OWL-S, a equipa da

OWL-S API lançou uma nova versão da API, em Abril de 2005, que já permite a

utilização de expressões condicionais em SWRL. Apesar desta alteração ter surgido

durante o período de implementação do trabalho da tese, decidiu-se implementar uma

nova versão do componente de execução de serviços para incluir a nova versão da OWL-

S API e ter assim acesso à nova funcionalidade.

Face às limitações indicadas anteriormente (ver secção 2.1.1.3), o trabalho decorria já

no sentido de escolher uma linguagem adequada para especificar as expressões

condicionais na descrição de serviços OWL-S. A linguagem escolhida foi o Prolog

[Clocksin & Mellish, 1981] e a extensão necessária foi realizada na OWL-S API. O

Prolog foi a linguagem escolhida por preencher os requisitos necessários para a

especificação de expressões lógicas e pelo facto de existir, na linha de investigação “We,

the Body and the Mind”, um módulo JAVA de interface ao LPA-Prolog [Westwood,

1997] que possibilitou realizar a integração com a OWL-S API, para permitir a avaliação

de expressões lógicas em Prolog. A extensão realizada funciona da seguinte forma: de

cada vez que uma expressão condicional de um serviço OWL-S se encontrar descrita em

Prolog, a mesma é transformada num formato adequado e enviada para este módulo onde


72

é interpretada e avaliada. Posteriormente, o módulo referido devolve o resultado da

avaliação da condição.

A utilização de ambas as abordagens (SWRL e Prolog) apresenta, porém, uma

limitação pelo facto de ainda só ser possível especificar expressões que usam os

predicados “built-in” especificados nas linguagens, isto é, não é permitido ao cliente do

serviço especificar predicados extra para expressar condições específicas do domínio. No

que toca ao Prolog, esta limitação é causada apenas pelo facto de não ter sido possível

implementar um mecanismo de carregamento de predicados específicos de um domínio

(através da definição de ontologias), em tempo útil para o uso no trabalho da tese. O

módulo de interface com o LPA-Prolog fornecido pela linha de investigação “We, the

Body and the Mind” permite qualquer definição, mas o agente implementado não fez uso

dessa possibilidade. Como tal, no caso do Prolog, os predicados que podem ser utilizados

correspondem aos disponibilizados pelo LPA-Prolog. No caso do SWRL, os predicados

que podem ser utilizados estão limitados pelos predicados disponibilizados pela equipa da

OWL-S API. Estes predicados consistem apenas em operações básicas de avaliação

numérica (“maior”, “menor”, “igual”). Deste ponto de vista, a abordagem com a

linguagem Prolog apresenta maiores vantagens pelo conjunto de predicados disponíveis

ser maior e por ser possível especificar outros predicados através do módulo de interface

referido. É necessária uma comparação mais profunda das duas abordagens para concluir

qual é a melhor. Os detalhes desta comparação encontram-se especificados no Capítulo 7

(Avaliação). Em seguida, são descritas em detalhe as duas abordagens.

5.2.2.1. Expressões Condicionais em SWRL

As expressões condicionais expressas em SWRL são descritas numa sintaxe XML e

têm uma estrutura como demonstra o exemplo seguinte, que define uma instrução

condicionada por uma expressão lógica descrita em SWRL.

<process:If-Then-Else> <process:ifCondition> <expr:SWRL-Condition> <expr:expressionBody rdf:parseType="Literal">


73

<swrl:AtomList> <rdf:first> <swrl:BuiltinAtom> <swrl:builtin rdf:resource="&swrlb;# lessThan"/> <swrl:arguments> <rdf:List> <rdf:first rdf:resource="&this;# Value1"/> <rdf:rest> <rdf:List> <rdf:first rdf:resource="&this;# Value2"/> <rdf:rest rdf:resource="&rdf; #nil"/> </rdf:List> </rdf:rest> </rdf:List> </swrl:arguments> </swrl:BuiltinAtom> </rdf:first> <rdf:rest rdf:resource="&rdf;#nil"/> </swrl:AtomList> </expr:expressionBody> </expr:SWRL-Condition> </process:ifCondition> <process:then> … processo a realizar se verdadeiro … </process:then> <process:else> … processo a realizar se falso … </process:else> </process:If-Then-Else>

Figura 14 - Exemplo de Expressão Condicional em SWR L

O exemplo ilustrado na Figura 14 representa uma expressão condicional “If-Then-

Else”. Esta expressão é usada para avaliar uma determinada condição e posteriormente

para executar um de dois possíveis processos, consoante o resultado obtido na avaliação.

No exemplo, é usado o predicado lessThan que permite averiguar se um determinado

valor numérico é menor que outro valor numérico. Neste caso, se Value1 for menor que

Value2 então o processo contido entre as partes <process:then> e </process:then> é

executado, caso contrário, é executado o processo contido entre as partes

<process:else> e </process:else> .


74

Por usar a mesma sintaxe que o OWL-S, a atribuição dos valores dos parâmetros

contidos no serviço OWL-S aos valores das variáveis da expressão condicionada (Value1

e Value2 ) é directa, sendo que não é necessário realizar nenhum tipo de mapeamento.

5.2.2.2. Expressões Condicionais em Prolog

As expressões condicionais expressas em Prolog obedecem à sintaxe do próprio

Prolog. A Figura 15 demonstra como uma expressão deste tipo é integrada num processo

“ If-Then-Else” do OWL-S.

<process:If-Then-Else> <process:ifCondition> <expr:PROLOG-Condition> Value1 < Value2. <expr:PROLOG-CONDITION> </process:ifCondition> <process:then> … processo a realizar se verdadeiro … </process:then> <process:else> … processo a realizar se falso … </process:else> </process:If-Then-Else>

Figura 15 - Exemplo de Expressão Condicional em Prolog

Este exemplo representa a mesma condição que o exemplo na Figura 14, isto é,

compara os valores Value1 e Value2 um com o outro, determinando se o primeiro é

menor que o segundo. Se a condição for verdadeira é executado o processo contido entre

as partes <process:then> e </process:then> , caso contrário, é executado o processo

contido entre as partes <process:else> e </process:else> .

No que toca à atribuição dos valores dos parâmetros contidos no serviço OWL-S aos

valores das variáveis da expressão condicional em Prolog, esta abordagem apresenta uma

desvantagem relativamente ao SWRL. Não existe ainda uma maneira explícita de indicar

que a variável na expressão Prolog corresponde a um determinado parâmetro do serviço

OWL-S. Para já, esta situação específica é resolvida através do mapeamento directo por


75

nome, isto é, se uma variável numa expressão condicional tiver o mesmo nome que um

parâmetro contido no serviço OWL-S, então o valor da mesma corresponde ao valor

desse parâmetro. Esta limitação será ultrapassada no futuro, possivelmente, através da

inclusão de uma secção de mapeamento na própria instrução condicionada.

5.3. Considerações finais das contribuições

Ao longo deste capítulo foram descritas as contribuições do trabalho da tese ao nível

da ontologia escolhida, OWL-S, para a descrição de serviços na Web Semântica e ao

nível do software de execução escolhido, OWL-S API, para a execução de serviços. As

contribuições realizadas permitem especificar outros prestadores de serviços para além

dos serviços na Web, como os Agentes Prestadores de Serviços, através da definição de

uma linguagem específica (AgentGrounding) e da implementação da extensão para a

conversão desta em mensagens de agentes; e a especificação, interpretação e avaliação de

expressões condicionais usando a linguagem lógica Prolog.

Este avanço no estado actual dos conhecimentos ao nível das ontologias de descrição

de serviços permite a ligação entre a Web Semântica e os agentes inteligentes,

potenciando o desenvolvimento de sistemas inteligentes com acesso ao vasto conteúdo de

informação que é a Web.

76

CCaappííttuulloo 66.. II MM PPLL EEMM EENNTTAAÇÇÃÃOO

Este capítulo descreve todo o processo de desenvolvimento e implementação do

trabalho realizado na tese. São apresentadas todas as decisões relativas à implementação

dos diversos elementos que constituem o sistema descrito no Capítulo 3 (Cenário de

Demonstração) e Capítulo 4 (Definição Conceptual do Sistema). Na secção dedicada ao

Agente de Execução de Serviços, para além de serem descritos todos os detalhes relativos

ao seu desenvolvimento, são também descritas em detalhe as interacções que este agente

tem com os restantes elementos do sistema, assim como todas as decisões associadas à

implementação das mesmas.

Devido a restrições temporais ou de insuficiência de recursos, alguns dos elementos

não foram implementados ou a sua implementação foi simplificada para permitir apenas a

demonstração dos mesmos. Qualquer uma destas situações encontra-se descrita na secção

relativa à implementação de cada um dos elementos em que tal ocorreu.

6.1. Entidades externas

Nesta secção são descritas as diversas entidades que interagem com o Agente de

Execução de Serviços (AES). Para cada uma das entidades é feita uma pequena descrição

da sua interacção com o AES e são descritas as opções de implementação.

Capítulo 6 - Implementação.

77

6.1.1. Agente Pessoal

O Agente Pessoal (AP) representa um cliente do AES. Este agente pede ao AES a

execução de um determinado serviço que se encontra descrito em OWL-S e o resultado

da execução desse serviço é lhe posteriormente enviada.

Sendo que esta tese não se centra no desenvolvimento de agentes pessoais e como a

implementação do AP exigiria muito tempo e recursos que iriam afectar o

desenvolvimento do AES, optou-se por não se implementar este agente. Como

alternativa, optou-se por usar um agente simplificado de testes fornecido pela plataforma

de agentes JADE25. Sendo assim, o AP irá ser demonstrado recorrendo a este agente

especial de testes26, cujas funcionalidades restringem-se ao envio de mensagens pré-

definidas. A descrição completa da interacção entre o AP e o AES será explicada

detalhadamente na secção 6.2.3.1.

6.1.2. Prestadores de Serviços

Esta secção é dedicada à descrição dos prestadores de serviços que foram

desenvolvidos e/ou utilizados na criação do sistema de demonstração. Existem dois tipos

de prestadores de serviços: os serviços na Web e os Agentes Prestadores de Serviços. Os

serviços na Web utilizados encontram-se descritos na secção 3.2.2.1. A interacção entre o

AES e os serviços na Web será descrita em detalhe na secção 6.2.3.3.

Agentes Prestadores de Serviços. Os Agentes Prestadores de Serviços27 utilizados

no sistema foram desenvolvidos com base no Componente de Interacção com Agentes28.

Este componente constitui uma base de desenvolvimento para agentes, fornecendo um

conjunto de funcionalidades, tal como descrito na secção 4.2.1.1. Os Agentes Prestadores

25 A plataforma JADE foi usada como base para todos os agentes implementados e utilizados

26 Daqui em diante, este agente será referido como Dummy

27 Estes agentes encontram-se descritos na secção 3.2.3.1

28 Os detalhes de implementação deste componente são descritos na secção 6.2.2.1


78

de Serviços foram desenvolvidos por não haver disponível o conjunto de agentes

necessários à demonstração do sistema.

O Agente de Informação Literária e o Agente de Pesquisa de Preços foram

implementados recorrendo especificamente à utilização de uma das funcionalidades

oferecidas pelo Componente de Interacção com Agentes, o acesso a bases de dados.

Foram criadas as bases de dados que constituem a informação disponibilizada por cada

um destes agentes e posteriormente estas foram preenchidas com amostras reais da

informação que cada um dos agentes disponibiliza. No caso do Agente de Informação

Literária, este fornece informação sobre um conjunto pequeno de livros. No caso do

Agente de Pesquisa de Preços, a sua base de dados foi preenchida com os preços dos

livros contidos na base de dados do Agente de Informação Literária, em várias lojas.

O Agente de Conversão de Valores não é um típico agente de informação, uma vez

que o serviço prestado consiste numa acção específica de conversão de valores entre

unidades monetárias. Como tal, este agente não foi implementado como os anteriormente

descritos, recorrendo ao uso de bases de dados. O Agente de Conversão de Valores

recebe a mensagem relativa ao pedido de conversão, processa a mensagem e realiza a

conversão dos valores através de um processo que foi implementado recorrendo a uma

das facetas do JADE: os comportamentos. Os comportamentos29 são processos que são

implementados para realizar uma tarefa associada a um tipo específico de mensagem

recebida. A interacção entre o AES e os Agentes Prestadores de Serviços encontra-se

detalhadamente descrita na secção 6.2.3.3.

6.1.3. Agentes de Descoberta e Composição de Serviços

Os Agentes de Descoberta e Composição de Serviços são usados pelo AES quando

este precisa de procurar serviços ou prestadores de serviços alternativos, numa situação

em que os serviços e prestadores originais não se encontram disponíveis. No que toca ao

Agente de Descoberta de Serviços, não foi necessário desenvolver o agente em questão

29 Tradução de “behavior”


79

uma vez que já existe uma implementação disponível. No desenvolvimento do cenário,

foi usado o Agente de Descoberta de Serviços [Pais & Botelho, 2005] disponibilizado

pela linha de investigação “We, the Body and the Mind” no seio do projecto CASCOM e

do projecto “Descoberta Contextualizada de Serviços em Redes P2P”30. A interacção

entre o ADS e AES é descrita na secção 6.2.3.2. Na implementação do cenário, não será

usado nenhum agente de composição de serviços por não existir uma implementação

disponível que se possa usar e porque o desenvolvimento de um agente deste calibre

usaria muitos recursos do trabalho, para além de que o desenvolvimento do mesmo não se

enquadra no âmbito da tese.

6.1.4. Plataforma Genérica de Informação de Contexto

A interacção do AES com um sistema responsável por captar informação de contexto

relativa a um ambiente específico, é imprescindível para melhorar o processo de

execução. Na implementação deste cenário, será usada a Plataforma Genérica de

Informação de Contexto (PGIC) [Costa & Botelho, 2005] disponibilizada pela linha de

investigação “We, the Body and the Mind” no seio do projecto CASCOM. A interacção

entre o AES e a PGIC é descrita em detalhe na secção 6.2.3.4.

6.2. Agente de Execução de Serviços

Esta secção é dedicada à descrição detalhada do desenvolvimento do AES e das

decisões associadas à sua implementação. Na secção 6.2.1 são descritas as tecnologias

utilizadas. Na secção 6.2.2 é descrita a implementação e o funcionamento dos

componentes internos do AES. Posteriormente, na secção 6.2.3 são descritas as interfaces

e as interacções do agente com os elementos externos descritos na secção 6.1.

30 Projecto de final de curso (2004/2005) de IGE (Informática e Gestão de Empresas) do ISCTE

pelo aluno Pedro Pais ([email protected]) com orientação do Professor Luís Botelho.


80

6.2.1. Tecnologias utilizadas

Nesta secção serão descritas as tecnologias utilizadas na implementação dos

componentes referidos anteriormente. Esta secção visa clarificar o uso destas tecnologias

face às alternativas possíveis.

6.2.1.1. eXtended Service Platform

O XSP (eXtended Service Plataform) foi usado no desenvolvimento dos

componentes do Agente de Execução de Serviços, os quais são reutilizáveis noutras

aplicações. O XSP é um software que visa facilitar a criação de aplicações baseadas em

componentes, incluindo o desenvolvimento dos próprios componentes. Os componentes

de uma aplicação podem ser executados no mesmo computador ou em computadores

diferentes. Os componentes da aplicação comunicam entre si através de mensagens XML.

O XSP oferece dois tipos de apoio: apoio de desenvolvimento e apoio de execução. No

que concerne à execução, o XSP oferece um componente especial chamado

NetworkYellowPager, um sistema de páginas amarelas que permite a cada componente

registar os serviços que oferece e procurar serviços prestados por outros componentes

sem necessitar saber a identidade do componente que o oferece. No que toca ao

desenvolvimento, o XSP oferece uma interface através da qual se pode fazer a criação da

aplicação incluindo a criação de componentes da aplicação. O XSP oferece também

partes do código a usar por cada componente, nomeadamente o código relativo à

comunicação entre componentes e ao registo e consulta dos serviços registados no

NetworkYellowPager sem necessidade de saber a identidade do componente que oferece

o serviço utilizado.

6.2.1.2. JADE

Através da plataforma JADE, foi possível criar uma base de operação para os agentes

desenvolvidos, que permite a estes descobrirem-se uns aos outros e comunicarem seja

internamente (entre agentes da mesma plataforma), seja externamente (com agentes

residentes noutras plataformas). A plataforma de agentes JADE é o software mais usado


81

na criação de agentes inteligentes, por ser gratuita, por se basear no princípio de código-

livre (open-source) e por ser extensível no sentido em que facilita a tarefa de desenvolver

novos componentes e estender as capacidades da própria plataforma. A plataforma JADE

é totalmente desenvolvida em Java.

6.2.1.3. OWL-S API

A OWL-S API [Sirin, 2004] é uma API desenvolvida em Java que oferece

funcionalidades de leitura, escrita e execução de serviços descritos segundo a ontologia

OWL-S. A leitura de serviços OWL-S é feita através de ferramentas de análise sintáctica

XML e RDF e permite processar serviços OWL-S descritos nas várias versões da

linguagem. A API fornece também um motor de execução que permite invocar a maior

parte dos processos OWL-S, incluindo processos atómicos descritos em WSDL. A OWL-

S API é, até à data, a única ferramenta do género disponível para utilização no

desenvolvimento de aplicações ligadas à execução de serviços na Web Semântica. A API

é bastante recente e ainda apresenta algumas limitações. Estas limitações são

apresentadas na secção 6.2.2.3 onde é descrito o componente que foi criado com base

nesta API.

6.2.2. Implementação dos componentes internos

O Agente de Execução de Serviços (AES) foi implementado através da integração de

3 componentes reutilizáveis: o Componente de Interacção com Agentes, usado para

permitir que o AES comunique com outros agentes; o Componente Motor do Agente ,

que corresponde ao centro de decisão do Agente; e o Componente de Execução de

Serviços que realiza a tarefa de executar as descrições de serviços, invocando os

prestadores de serviços de acordo com o modelo processual do serviço. As interacções

entre os componentes estão descritas na secção 4.2.2.


82

6.2.2.1. Componente de Interacção com Agentes

O Componente de Interacção com Agentes (CIA) tem um objectivo principal:

fornecer ao Agente de Execução de Serviços (AES) um mecanismo que permita interagir

com outros agentes. A interacção com outros agentes implica que a informação trocada

com outros componentes seja transformada no formato adequado, pelo que o componente

é também responsável por realizar essa conversão. Outra tarefa realizada pelo

componente é a gestão das conversações que o AES tem com os diversos agentes com

quem interage, de acordo com os protocolos de interacção usados.

Figura 16 - Funcionamento interno do Componente de Interacção com Agentes

A Figura 16 detalha o funcionamento interno deste componente. A actividade do

agente inicia-se com a criação de 3 processos passivos. Os processos são passivos no

sentido em que, quando se iniciam, encontram-se num estado no qual aguardam que


83

determinado evento ocorra. Basicamente, o componente fica à espera que 3 tipos de

eventos ocorram: recebimento de uma mensagem de um outro agente, recebimento de um

pedido (gerado internamente) para envio de uma mensagem para um determinado agente

e recebimento do resultado da execução de um serviço. A actividade do componente

associada à ocorrência desses eventos, encontra-se detalhada em seguida.

• Recebimento de Mensagem de outro Agente – Quando o componente recebe

uma mensagem que foi enviada por outro agente, este realiza a análise sintáctica

da mensagem e em seguida transforma o conteúdo recebido num formato

adequado para ser processado pelo Componente Motor de Agente (Motor). Nesta

altura, interessa distinguir se a mensagem recebida é um pedido de execução ou

se é um outro tipo de mensagem. Se for um pedido de execução, então o

componente regista uma nova conversação relativa a este pedido e manda-o para

o Motor. Se não for, o componente consulta anteriores conversações que tenham

sido registadas e envia para o processamento adequado.

• Recebimento de Pedido de Envio de Mensagem – Quando um dos outros

componentes precisa de enviar uma mensagem para um agente exterior (por

exemplo agentes de descoberta e composição de serviços e agentes prestadores de

serviços), estes enviam esse pedido para o CIA. Quando o CIA recebe esse

pedido, converte a informação no formato adequado para envio da mensagem,

cria um registo da nova conversação e envia a mensagem para o agente

destinatário.

• Recebimento de Resultados de Pedidos de Execução – Quando um serviço foi

executado e o CIA recebe o seu resultado (seja o resultado efectivo ou uma

notificação do sucesso/insucesso da execução), este transforma-o num formato

adequado para envio da mensagem, consulta a conversação associada ao pedido

de execução e envia a mensagem para o agente destinatário.

O CIA foi implementado através da criação de um componente envolvente de um

software disponibilizado pela linha de investigação “We, the Body and the Mind”, o


84

AnyAgent31. O AnyAgent é um software que introduz um conjunto de funcionalidades

extra à classe Agent disponibilizada pela plataforma de agentes JADE. Essas

funcionalidades baseiam-se na capacidade para realizar a análise sintáctica de mensagens

em diversas linguagens de conteúdo diferentes32, na geração de estrutura de dados

relacionadas com ontologias definidas, na execução de acções e na interpretação de

conteúdos de mensagens como comandos de interacção com bases de dados.

O CIA encapsula todas as funcionalidades do AnyAgent e do JADE num componente

XSP que pode ser usado no desenvolvimento de agentes com bases em componentes.

Deste ponto de vista, o componente criado inclui quatro funcionalidades: envio e

recebimento de mensagens; acesso às funcionalidades do AnyAgent e do JADE;

conversão de mensagens recebidas no formato de estrutura de dados do XSP e vice-versa;

e gestão de conversações.

6.2.2.2. Componente do Motor do Agente

O Componente Motor do Agente (Motor) é o centro de decisão do Agente de

Execução de Serviços (AES). Este componente é responsável por avaliar, consoante a

situação contextual, os pedidos de execução recebidos e por efectuar decisões

relacionadas com o funcionamento interno e externo do agente, nomeadamente pela

aceitação/rejeição de pedidos de execução e pela necessidade de comunicação com outros

agentes em situações específicas.

A Figura 17 ilustra o funcionamento interno do componente. Inicialmente o

componente encontra-se num estado de espera, aguardando pela chegada de pedidos de

execução que precisem de ser avaliados. Quando um pedido chega, a primeira tarefa do

componente consiste em decompor o serviço composto (se for o caso) e dividir a sua

actividade em dois processos diferentes.

31 http://we-b-mind.org/PT/software.html#ANYAGENT

32 http://we-b-mind.org/PT/software.html#SLKIFPCLALL


85

Figura 17 - Funcionamento interno do Componente Mot or do Agente

Do ponto de vista da análise individual de cada serviço atómico, a avaliação é

realizada com o intuito de saber se o prestador de serviços correspondente se encontra


86

disponível. Esta informação pode ser obtida através da interacção com a Plataforma

Genérica de Informação de Contexto (PGIC). Se o prestador do serviço não se encontrar

disponível, o Motor envia o pedido de envio de mensagem para o Componente de

Interacção com Agentes (CIA). Este pedido consiste numa mensagem de procura de

prestadores de serviços alternativos que deve ser enviada para um Agente de Descoberta

de Serviços. Se for encontrado um prestador alternativo, então o processo da consulta da

disponibilidade reinicia-se. Se este não for encontrado, então o Motor pode ainda

procurar um serviço composto alternativo através da interacção com um agente de

composição de serviços. Novamente esta interacção é realizada através do envio de um

pedido de envio de mensagem para o CIA. Se o prestador de serviços original se

encontrar disponível, interessa então comparar a localização do Agente Cliente com a

localização do prestador de serviço (ou a da entidade que o prestador de serviço

representa). De notar que esta comparação só é realizada se o serviço for de natureza

geográfica, como é o caso do cenário descrito no Capítulo 3. Se a localização não for

satisfatória, o processo de procura de um prestador de serviços alternativo repete-se. Se

por outro lado, a localização for satisfatória, então o serviço atómico e o prestador de

serviços correspondente podem ser usados na execução do serviço composto.

No que toca ao conjunto dos serviços atómicos, é importante analisar se o tempo total

de execução dos serviços atómicos respeita as restrições temporais impostas pelo Cliente

(se for o caso). Para tal, o componente recolhe informação de contexto relativamente ao

tempo médio de execução (TME) e tempo estimado de espera (TEE) para cada um dos

prestadores dos serviços atómicos. Esta informação é acessível através da PGIC e

corresponde aos sensores que cada prestador de serviços disponibiliza para os seus

clientes. O TME reflecte o tempo médio que o prestador de serviço leva a executar o seu

serviço atómico. O TEE representa a carga de trabalho do prestador de serviço no

momento. Este valor é calculado pela multiplicação do TME com a fila de espera de

pedidos actual do prestador. Uma vez recolhidos todos os valores necessários, o Motor

calcula o tempo que o serviço composto em média levaria a ser executado. Se esse tempo

ultrapassar o limite imposto pelo Cliente, então o Motor reinicia o processo de encontrar

um serviço composto alternativo, através da interacção com um agente de composição de


87

serviços (novamente através do pedido de envio de mensagem ao CIA). Se o tempo

calculado não ultrapassar o tempo imposto então o Motor agrega esta informação com a

recolhida através do outro processo (análise individual dos serviços atómicos), e envia o

serviço composto para execução no Componente de Execução de Serviços (CES). Após o

Motor receber o resultado da execução do serviço, este verifica se a mesma ocorreu com

sucesso e se for o caso, envia o resultado da execução ao Cliente, através do envio do

mesmo para o CIA. Se durante a execução do serviço ocorrerem erros, o Motor recebe

essa notificação e envia a notificação adequada ao cliente, novamente através do CIA.

O Motor foi implementado através de um componente XSP e a sua actividade é

realizada pelo conjunto de processos implementados para processar os pedidos dos

restantes componentes. A sua comunicação com os componentes CIA e CES é feita

através da infra-estrutura de comunicação do XSP. A interacção do Motor com a PGIC é

feita através do interface Jini que esta oferece. Esta interacção encontra-se detalhada na

secção 6.2.3.4.

6.2.2.3. Componente de Execução de Serviços

O Componente de Execução de Serviços (CES) foi desenvolvido para executar

serviços na Web Semântica. Este componente foi implementado através de um

componente XSP envolvente sobre a OWL-S API. No entanto, a execução de serviços

através do uso desta API apresenta algumas limitações. Limitações essas que têm origem

na ausência de especificação de determinadas partes da ontologia de serviços OWL-S.

Por um lado, não é possível utilizar o OWL-S para representar serviços prestados for

prestadores de serviços com representações mais complexas de utilização, como por

exemplo, Agentes Prestadores de Serviços. Por outro lado, o uso de expressões

condicionais encontra-se limitado por o OWL-S não impor nenhuma linguagem de

especificação desta parte da descrição dos serviços. Como tal, o CES foi desenvolvido

para incluir extensões à OWL-S API que cubram as limitações enunciadas. Estas

extensões encontram-se detalhadamente descritas no Capítulo 5 (Extensões à Ontologia

de Descrição ).


88

6.2.3. Interfaces e Interacções

Nesta secção são descritas em detalhe as interacções do Agente de Execução de

Serviços com os restantes elementos do cenário. Esta descrição inclui descrever os

interfaces que foram definidos e implementados para suportar essas interacções.

6.2.3.1. Agente Pessoal

O Agente Pessoal (AP), sendo o cliente do Agente de Execução de Serviços (AES),

comunica com este para pedir a execução de um serviço composto descrito em OWL-S.

Este pedido é efectuado com o envio, por parte do AP para o AES, de uma mensagem

FIPA com o acto comunicativo Request. Este acto comunicativo é regido pelo protocolo

de interacção entre agentes FIPA-Request [FIPA-2, 2002]. O protocolo FIPA-Request é o

mais usado nas interacções do AES com os outros agentes e encontra-se descrito no

anexo C (Protocolos Utilizados).

A comunicação entre o AP e o AES inicia-se com o envio da mensagem Request por

parte do AP. Esta mensagem obedece à seguinte estrutura:

• Acção: execute-service-by-url

• Número de Parâmetros: 1

• Tipo de Parâmetro: owl-s-service

A definição da estrutura de dados owl-s-service é a seguinte:

• name – indica o nome do serviço

• url – indica o URL (endereço na Internet) onde a descrição OWL-S do

serviço se encontra

• inputs – indica o conjunto de parâmetros de entrada que são fornecidos para

a sua execução. Estes parâmetros são do tipo owl-s-input-parameter , que

tem a seguinte estrutura:

o name – indica o nome do parâmetro e corresponde a uma String


89

o value – indica o valor do parâmetro e pode ser qualquer tipo básico

(como uma String ou Integer) ou alternativamente do tipo de owl-s-

individual-input-parameter . Este tipo de parâmetro corresponde a

um objecto complexo que não pode ser representado através de um

tipo básico e obedece à seguinte estrutura:

� ontology-url – indica o URL onde se encontra especificada a

ontologia deste objecto complexo

� value – indica o valor que o objecto assume no âmbito da

ontologia referida

Através desta especificação, é possível ao AP iniciar a conversação com o AES que

lhe permitirá pedir a execução de um serviço. Essa conversação é iniciada através do

envio da mensagem Request ilustrada na Figura 18.

(REQUEST :sender (agent-identifier :name [email protected] -b-mind.org) :receiver (set (agent-identifier :name sea@servic es.we-b-mind.org) ) :content "((action (agent-identifier :name [email protected]. org) (execute-service-by-url (owl-s-service :name \"Book Price Composed Web Service\" :url \"http://localhost/www/owl-s/remoteBookP rice/BookPrice.owl\" :inputs (set (owl-s-input-parameter :name \"BookName\" :value \"Da Vinci Code\") (owl-s-input-parameter :name \"Currency\" :value (owl-s-individual-input-parameter :ontology-url \”http://localhost/w ww/owl/currency.owl\” :value \"EUR\")))))))" :language fipa-sl :protocol fipa-request :ontology owl-s-service-execution-ontology :conversation-id test_book_price1 )

Figura 18 - Mensagem Request de pedido de execução de serviço

Nesta mensagem podemos evidenciar que o AP (aqui interpretado pelo agente

[email protected] ) está a pedir ao AES (aqui identificado como o agente


90

[email protected] ) a execução da acção execute-service-by-url com o

argumento do tipo owl-s-service que descreve o serviço “Book Price Composed Web

Service” que se encontra descrito em OWL-S no seguinte endereço

“http://localhost/www/owl-s/remoteBookPrice/BookPrice.owl”. Este serviço, que

corresponde ao serviço descrito no cenário de demonstração no Capítulo 3, admite como

parâmetros de entrada, dois argumentos: BookName que corresponde ao título do livro que

o AP pretende pesquisar (neste caso, o livro “Da Vinci Code”); e Currency que

corresponde à indicação da unidade monetária no qual o AP pretende que o resultado seja

apresentado. Sendo este um objecto complexo o mesmo é apresentado no âmbito da

estrutura owl-s-individual-input-parameter . Neste caso, o objecto pertence à

ontologia de unidades monetárias que se encontra localizada no endereço

“http://localhost/www/owl/currency.owl” e o seu valor corresponde à classe “EUR” que,

neste caso, especifica que a unidade monetária desejada é o Euro.

Após receber esta mensagem e realizar a avaliação necessária (descrita na secção

6.2.2.2), o AES responde ao AP com a mensagem adequada dependendo do resultado da

avaliação. Se o processamento da mensagem não foi possível por haver algum erro ou

termo não reconhecido na mensagem, o AES responderia com uma mensagem Not-

Understood, como indica o protocolo. Caso contrário, e se o AES recusar realizar a acção

porque através da análise contextual determinou que não consegue executar a acção

(devido a restrições temporais ou de recursos), então este responde com uma mensagem

Refuse, indicando a razão para a não aceitação do pedido. No entanto, se o AES aceitar o

pedido então este responde com a mensagem ilustrada na Figura 19.


91

(AGREE :sender (agent-identifier :name [email protected] -mind.org) :receiver (set (agent-identifier :name dummy@serv ices.we-b-mind.org) ) :content "((action (agent-identifier :name [email protected]. org) (execute-service-by-url (owl-s-service :name \"Book Price Composed Web Service\" :url \"http://localhost/www/owl-s/remoteBookP rice/BookPrice.owl\" :inputs (set (owl-s-input-parameter :name \"BookName\" :value \"Da Vinci Code\") (owl-s-input-parameter :name \"Currency\" :value (owl-s-individual-input-parameter :ontology-url \”http://localhost/w ww/owl/currency.owl\” :value \"EUR\")))))) (true))" :language fipa-sl :protocol fipa-request :ontology owl-s-service-execution-ontology :conversation-id test_book_price1 )

Figura 19 - Mensagem Agree do AES para o AP

Em seguida, o AES procede à execução da acção pedida e consoante o seu resultado,

o agente envia a mensagem adequada. Se a execução da acção, neste caso da execução de

um serviço, não tiver sucesso o AES responde ao AP com uma mensagem Failure

indicando a razão para a ocorrência. As razões possíveis estão ligadas à ocorrência dos

seguintes erros33:

• Service-url-error – indica que o endereço (URL) enviado no pedido contém

erros. Isto pode dever-se ao facto do URL estar mal escrito e não apontar para um

ficheiro válido ou então para o facto do ficheiro para o qual o URL aponta conter

erros na própria estrutura sintáctica da descrição de um serviço OWL-S

• Service-providers-error – este erro ocorre quando os prestadores de serviço

especificados não se encontram disponíveis ou quando não foi possível ao AES

encontrar prestadores alternativos

33 Todos estes erros têm apenas um parâmetro que corresponde a uma String descritiva do erro

exacto que ocorreu


92

• Unsatisfied-pre-condition – indica que uma (ou mais) das pré-condições

existentes na descrição do serviço não são verdadeiras. Como tal, a execução não

pode ser realizada.

• Feature-not-implemented – este erro ocorre quando o serviço descrito utiliza

partes do OWL-S que ainda não se encontram implementadas ao nível da OWL-S

API (como é o caso do suporte para vários perfis dentro de um só serviço) ou

então relativamente a partes do OWL-S que ainda não se encontram especificadas

na própria linguagem, mas que estarão em futuras versões da mesma.

• Condition-error – indica que não foi possível realizar a avaliação de

determinada expressão condicional que se encontra descrita no serviço, por esta

ter erros de escrita ou de estrutura sintáctica.

• Internal-error – este erro existe para indicar que ocorreu um erro de

funcionamento interno do próprio agente que não é coberto pelos erros anteriores.

• General-execution-error – este erro indica que ocorreu um evento durante o

processo de comunicação que não é coberto pelos erros anteriores e que é alheio

ao próprio agente, como por exemplo, erros durante a comunicação com os

prestadores de serviços.

Se o serviço foi executado com sucesso e caso exista resultado, então o AES

responde ao AP através da mensagem ilustrada na Figura 20.

(INFORM :sender (agent-identifier :name [email protected] -mind.org) :receiver (set (agent-identifier :name dummy@serv ices.we-b-mind.org)) :content "((result (action (agent-identifier :name [email protected]. org) (execute-service-by-url (owl-s-service :name "Book Price Composed Web Service" :url "http://localhost/www/owl-s/remoteBook Price/BookPrice.owl" :inputs (set (owl-s-input-parameter :name "BookName" :value "City of Glass") (owl-s-input-parameter :name "Currency" :value (owl-s-individual-input-parameter :ontology-url “http://localhost/www /owl/currency.owl”


93

:value "EUR")))))) (owl-s-service-result :outputs (set (owl-s-output-parameter :name "BookStore" :value "Amazon") (owl-s-output-parameter :name "BookPrice" :value (Price :currency EUR :amount 11.85 22151))))))" :language fipa-sl :protocol fipa-request :ontology owl-s-service-execution-ontology :conversation-id test_book_price1 )

Figura 20 - Mensagem Inform com o resultado da execução

Esta mensagem apresenta o resultado de execução do serviço, que neste caso indica

que o melhor preço do livro é de 11.85€ na loja Amazon, através do parâmetro owl-s-

service-result que tem a seguinte estrutura:

• outputs – lista de resultados da execução do serviço. Estes resultados são

apresentados através do tipo de parâmetro owl-s-output-parameter que tem a

seguinte estrutura:

o name – corresponde ao nome do parâmetro

o value – indica o valor do parâmetro. Este valor pode ser de um tipo

básico ou qualquer outro tipo reconhecido pela linguagem FIPA-SL

[FIPA-2, 2002], como é o caso do exemplo da Figura 20 onde o resultado

do preço é apresentado como uma expressão funcional.

6.2.3.2. Agente de Descoberta de Serviços

O Agente de Descoberta de Serviços (ADS) é contactado pelo Agente de Execução

de Serviços (AES) quando este precisa de encontrar prestadores de serviços alternativos.

A interacção entre estes dois agentes é também regida pelo protocolo FIPA-Request (ver

anexo C). Durante a execução de um serviço, se o AES se depara com a situação de um

ou mais prestadores de serviços não se encontrarem especificados ou disponíveis, então

este recorre aos serviço do ADS para procurar alternativas. Esta procura é feita com base

no perfil de serviço que o AES procura, ou seja, quando o prestador de um determinado


94

serviço não se encontra disponível, o AES procura um prestador alternativo através da

descrição do perfil desse serviço, enviando-o para o ADS.

A Figura 21 descreve um exemplo da mensagem que o AES teria de enviar ao ADS

(aqui identificado como [email protected] ), quando procura um prestador

para o serviço, cujo perfil encontra-se descrito no endereço “http://localhost/www/owl-

s/remoteBookPrice/BookFinder.owl”.

(REQUEST :sender (agent-identifier :name [email protected] mind.org) :receiver (set (agent-identifier :name sda@service s.we-b-mind.org)) :content "((action (agent-identifier :name [email protected] rg) (getMatchingGroundings :profileLocation \"http://localhost/www/owl-s/remoteBookPrice /BookFinder.owl\" :useMatchmaker false)))" :language fipa-sl :protocol fipa-request :ontology owl-s-service-discovery-ontology :conversation-id test-sda-1 )

Figura 21 - Mensagem Request de pedido de procura de prestador de serviço alter nativo

Neste exemplo, utiliza-se a acção getMatchingGroundings 34 porque o que se

pretende descobrir são prestadores de um determinado serviço e a identificação destes

está contida na Instanciação do mesmo, ou seja, o seu Grounding. A acção

getMatchingGroundings tem como argumentos os parâmetros profileLocation , que

indica o endereço do Perfil do serviço que se pretende pesquisar, e useMatchmaker , que

indica se a pesquisa deve ser feita recorrendo a um processo mais complexo e profundo

de emparelhamento de serviços. No exemplo da Figura 21, o valor deste parâmetro é

false , porque apenas se pretende encontrar prestadores através de um emparelhamento

exacto de perfis de serviços. Antes de executar a acção de pesquisa, o ADS envia também

a mensagem Agree, caso aceite realizar a mesma. Após realizar a acção, o ADS envia a

mensagem de resposta com o resultado do serviço, cujo exemplo encontra-se ilustrado na

Figura 22.

34 Mais detalhes sobre o agente de descoberta de serviços e sobre os serviços que presta

podem ser consultados em http://www.we-b-mind.org/sda/


95

(INFORM :sender (agent-identifier :name [email protected] -mind.org) :receiver (set (agent-identifier :name sda@servic es.we-b-mind.org)) :content “((result (action (agent-identifier :name [email protected]. org) (getMatchingGroundings :profileLocation "http://localhost/www/owl-s/remoteBookPrice /BookFinder.owl" :useMatchmaker false)) (set (sequence "http://localhost/www/owl-s/remoteBookPrice /BookFinder_alt.owl" EXACT) (sequence "http://localhost/www/owl-s/remoteBookPrice /BookFinder.owl" EXACT))))” :language fipa-sl :protocol fipa-request :ontology owl-s-service-discovery-ontology :conversation-id test-sda-1 )

Figura 22 - Mensagem Inform com o resultado da pesquisa de prestadores alterna tivos

Na mensagem da Figura 22, percebe-se que o ADS encontrou dois prestadores de

serviços alternativos, sendo que um deles é o próprio que foi enviado como referência da

pesquisa. Após receber este resultado o AES, usa a informação para adaptar o serviço que

precisa de executar. Para tal, o AES consulta a alternativa enviada pelo ADS e após obter

os dados necessários relativos ao prestador de serviço alternativo, o AES adapta o serviço

original para agora usar o novo prestador.

6.2.3.3. Prestadores de Serviços

A execução de um serviço composto é feita através da execução dos serviços

atómicos que o compõem. Cada serviço atómico tem um prestador associado, e a

execução do mesmo é feita através da sua invocação que consiste em contactar o

prestador pedindo a execução pretendida. No seu trabalho de execução o Agente de

Execução de Serviços (AES) comunica com os prestadores de serviços de acordo com o

seu tipo, sendo que eles podem ser dois: serviços na Web e Agentes Prestadores de

Serviços.

Serviços na Web. Os serviços na Web representam serviços de rede disponíveis

através da infra-estrutura de comunicação da Internet e são normalmente descritos usando


96

a linguagem de descrição de serviços na Web WSDL. O WSDL descreve um serviço na

Web, através de uma sintaxe XML, como sendo um ponto de comunicação que opera

segundo determinadas mensagens que originam processos de obtenção de informação ou

a execução de determinados procedimentos. As operações e mensagens são descritas na

linguagem de forma abstracta, sendo depois associadas a protocolos de comunicação e

formatos de mensagens (como o SOAP) para definir a interface concreta do serviço. Os

serviços na Web descritos na secção 3.2.2.1 são todos invocáveis através do recurso ao

protocolo SOAP. A OWL-S API inclui um motor de execução que processa a descrição

WSDL/SOAP desses serviços na Web e executa-os de acordo com o estabelecido na

interface descrita.

Agentes Prestadores de Serviços. Quando o prestador de um serviço atómico é um

agente, a sua Instanciação é feita através da extensão AgentGrouding, descrita na secção

5.2.1. Nesta secção foi descrito o exemplo de um agente que era prestador de um serviço

atómico de procura de livros através de um parâmetro de entrada (o título do livro), onde

foi usado o protocolo de interacção entre agentes, FIPA-Request (ver anexo C). Neste

exemplo, a resposta do Agente Prestador de Serviço ao pedido enviado (ver Figura 13 na

secção 5.2.1) seria a mensagem ilustrada na Figura 23.

(INFORM :sender (agent-identifier :name bookeeper@service s.we-b-mind.org) :receiver (set (agent-identifier :name sea@servic es.we-b-mind.org)) :content ((result (action (agent-identifier :name [email protected] -b-mind.org") (find-book :input-string "Da Vinci Code")) (RequestResult :book-info "385504209")))" :language fipa-sl :ontology book-finder-ontology :protocol fipa-request :conversation-id SEA-AGR-CID-1117800292257)

Figura 23 - Mensagem Inform de resposta ao pedido do AgentGrounding

Como se pode ver, a mensagem de resposta especifica que o resultado da execução

do serviço atómico find-book é a expressão funcional (RequestResult :book-info

“385504209”) , indicando que o valor pretendido (book-info ) é “385504209” .


97

Outros protocolos de interacção podem ser usados, se a especificação de utilização do

serviço atómico assim o indicar. Outro protocolo que pode ser usado é o FIPA-Query

[FIPA-2, 2002]. Este protocolo encontra-se descrito no anexo C (Protocolos Utilizados).

6.2.3.4. Plataforma Genérica de Informação de Contexto

A Plataforma Genérica de Informação de Contexto (PGIC) é a base de toda a

informação de contexto sobre as entidades de um determinado ambiente. O AES interage

com a PGIC no sentido de obter a informação de contexto necessária para melhorar o seu

processo de execução de serviços. A comunicação com a PGIC é feita através da

interface Jini que a plataforma oferece.

A PGIC permite a qualquer entidade do ambiente sobre o qual opera, fornecer

qualquer tipo de informação de contexto desde que esta seja modelada segundo as regras

impostas pela plataforma:

• Herança – qualquer classe criada com o intuito de constituir um objecto de

informação de contexto tem de herdar da classe ContextObject fornecida pela

plataforma.

• Propriedades – qualquer objecto de informação de contexto tem de estar

associado a um conjunto de propriedades que o permitam identificar

univocamente em relação a objectos semelhantes.

Na implementação do cenário, foram criadas as seguintes classes que constituem

objectos de informação de contexto dos agentes:

• AverageServiceExecutionTime – Esta classe visa especificar o tempo médio de

execução do serviço que fornece esta informação

• EstimatedWaitingTime – Esta classe indica o tempo estimado que um cliente

tem de esperar até que possa utilizar o serviço que fornece esta informação

• LocationPlace – Esta classe fornece informação geográfica sobre uma

determinada entidade, com base numa localização por lugar (cidade, país)


98

• LocationGPS – Esta classe fornece informação geográfica sobre uma

determinada entidade, com base numa localização por coordenadas GPS

• ServiceAvailability – Esta classe reflecte a disponibilidade de um determinado

prestador de serviço

• ServiceRequestsQueue – Esta classe indica o número de pedidos em espera que

um determinado prestador de serviço tem

Com o objectivo de permitir a identificação unívoca dos objectos de contexto na

implementação do cenário, foi criada a classe Owner, que tem as seguintes propriedades:

• name – nome da entidade dona do objecto de contexto

• category – categoria a que a entidade pertence (Agente de Descoberta de

Serviços, Prestador de Serviço)

Para ser possível identificar a entidade que realiza a manutenção de um determinado

objecto de contexto, é necessário fazer uma associação entre o objecto de Contexto e um

objecto da classe Owner. Essa associação é feita quando a entidade regista os seus

objectos de contexto na PGIC através da criação de um sensor de contexto. O sensor de

contexto é uma das formas pela qual outras entidades podem consultar informação de

contexto sobre uma determinada entidade.

Quando o AES pretende obter determinada informação de contexto basta comunicar

com a PGIC através de um dos mecanismos referidos (XSP ou Jini) e realizar uma

pesquisa com a seguinte estrutura:

• Owner – indica a entidade sobre a qual o AES pretende saber determinada

informação de contexto

• ContextObject – indica o tipo de informação de contexto que o AES pretende

obter (pode ser uma das várias classes que foram criadas para identificar contexto

no cenário de demonstração)


99

6.3. Considerações finais da implementação

Os componentes desenvolvidos permitiram a criação de um Agente de Execução de

Serviços que opera numa infra-estrutura de coordenação de serviços, que combinando a

descoberta e composição de serviços com acesso a informação de contexto, consegue

executar todo o tipo de serviços descritos em OWL-S que sejam fornecidos por qualquer

tipo de prestador de serviços, sejam serviços na Web, sejam Agentes Prestadores de

Serviços. Foi possível também implementar os restantes elementos do cenário de

demonstração, reutilizando os componentes desenvolvidos no âmbito do Agente de

Execução de Serviços, nomeadamente através do uso do Componente de Interacção com

Agentes.

Toda a implementação foi baseada nas necessidades expressas nos requisitos

levantados durante o processo de modelação do sistema. Durante o capítulo foram

descritas todas as decisões associadas ao desenvolvimento do Agente de acordo com os

requisitos apresentados, incluindo a resolução de conflitos dos mesmos tendo em conta o

âmbito e o enquadramento da realização do trabalho da tese, nomeadamente, restrições

temporais e de recursos.

100

CCaappííttuulloo 77.. AAVVAALL II AAÇÇÃÃOO

Este capítulo descreve a metodologia que foi aplicada à avaliação do trabalho desta

tese de mestrado. A metodologia usada na avaliação do trabalho consiste em apresentar

os critérios que devem ser satisfeitos para considerar que o trabalho efectuado atinge os

objectivos propostos e que se pode classificar como inovador e útil e, em seguida,

apresentar um conjunto de testes que servirão para comprovar a satisfação desses mesmos

critérios no trabalho.

O capítulo encontra-se dividido em duas partes. A primeira parte, que corresponde à

secção 7.1, descreve os critérios considerados para a avaliação do trabalho. Esta secção

inclui ainda a descrição dos testes e procedimentos de avaliação que deverão ser

realizados para comprovar a satisfação dos critérios enunciados. Na segunda parte do

capítulo, na secção 7.2, serão apresentados os resultados dos testes e será feita a avaliação

dos mesmos segundo os critérios estabelecidos de acordo com a metodologia.

7.1. Critérios, testes e procedimentos

A avaliação da tese consiste em determinar quais os pontos fortes da mesma que

permitirão de certa forma diferenciar este trabalho de trabalho relacionado já realizado.

Nesta secção serão apresentados os critérios de avaliação e é descrita a sua importância

na aferição da qualidade do trabalho realizado. Os critérios visam analisar características

do trabalho como a sua utilidade, qualidade, flexibilidade, interoperabilidade, facilidade

de utilização, abrangência, independência do domínio, autonomia, rapidez e a utilização

de informação de contexto. Na subsecção dedicada a cada um destes critérios serão

Capítulo 7 - Avaliação

101

apresentados também os testes e procedimentos que deverão ser realizados para

determinar a qualidade do trabalho da tese.

7.1.1. Utilidade e qualidade do Agente de Execução de

Serviços

A utilidade de um serviço prestado é extremamente importante quando toca à sua

avaliação pois é vital que um serviço seja útil para o conjunto dos seus clientes. A sua

utilidade pode ser determinada pela medida em que o serviço prestado satisfaz as

necessidades e resolve os problemas do rol de clientes. O teste que visa avaliar este

critério está associado à qualidade do serviço prestado ao cliente, e para tal é preciso

efectuar testes em que se definem à partida quais os resultados esperados do pedido de

execução de um serviço ao Agente de Execução de Serviços. O Agente de Execução de

Serviços deverá executar o serviço requisitado pelo agente cliente e o resultado devolvido

deverá corresponder ao resultado esperado por parte do agente cliente. O resultado

esperado de um determinado serviço corresponde aos efeitos do mesmo (presentes na

descrição OWL-S do serviço).

Por vezes a execução do serviço pode estar comprometida por problemas alheios ao

Agente de Execução de Serviços. Nestes casos a satisfação do agente cliente é

determinada com base na comparação entre o resultado esperado e os resultados obtidos

pelas alternativas que o Agente de Execução de Serviços propôs. Para este efeito, é

necessário definir uma métrica que permita comparar a semelhança entre os efeitos do

serviço original e o resultado do serviço alternativo. Isto corresponde a definir um

conjunto de heurísticas que dependem especificamente de informação de comparação do

domínio sobre o qual o Agente opera na execução do serviço. Estas heurísticas podem ser

definidas nas ontologias que descrevem o conhecimento dos domínios dos serviços

executados.

O teste referido não será realizado, uma vez que o mesmo implica a criação de

diversos agentes e serviços (nomeadamente os agentes e serviços que irão servir de


102

alternativa), sendo que o excesso de recursos necessários poderá atrasar o decorrer do

trabalho normal da tese.

7.1.2. Flexibilidade, interoperabilidade e facilidade de

utilização do agente

A flexibilidade e facilidade de utilização de um componente é normalmente dada

pela caracterização da interface desse componente, isto é, a sua ligação ao exterior. Para

esse efeito, o critério visa estabelecer, através da análise da interface do agente, se ela é

fácil de usar ou requer que os agentes que usam este serviço tenham capacidades

excepcionalmente sofisticadas (e.g., geração de perguntas complexas e processamento

das respostas). Pretende-se também analisar se a interface é suficientemente expressiva

sem comprometer a facilidade de uso e que possa ser usada numa classe suficientemente

lata de problemas sem que comprometa igualmente a capacidade de resolver problemas

específicos. Para testar a interoperabilidade e facilidade de utilização, interessa analisar a

interface de forma a determinar se o agente cliente necessita de alguma capacidade

especial para comunicar e pedir a execução do serviço ao agente executor de serviços. A

situação ideal será a de que o agente cliente apenas precise de respeitar as especificações-

padrão existentes na tecnologia de agentes (nomeadamente as especificações da FIPA

[FIPA-2, 2002]) para fazer uso da execução de serviços disponibilizada pelo agente.

Qualquer interacção que tenha de existir e que não esteja regida pelas especificações

indicadas, inviabiliza a interoperabilidade do agente. Como tal, a avaliação será feita no

sentido de analisar se existem estas situações específicas. Esta avaliação passa por

analisar os protocolos de interacção e as mensagens trocadas, de forma a determinar se

tudo está dentro do âmbito das especificações da FIPA. Por outro lado, também interessa

testar se o agente é flexível o suficiente para negociar com o Agente Cliente sobre

determinados parâmetros ou situações (como a necessidade de procurar serviços

alternativos).

Embora esta situação pareça criar um conflito entre a flexibilidade do agente e a sua

interoperabilidade, a avaliação visa determinar se se conseguiu atingir um meio termo


103

entre estas características. Isto é, fazer com que o agente seja interoperável e fácil de

utilizar sem comprometer a sua flexibilidade. A avaliação deste possível conflito é feita

com base na complexidade associada à implementação de cada um dos requisitos,

contrabalançando com os recursos disponíveis, seja ao nível de infra-estrutura de

desenvolvimento, seja ao nível de restrições temporais da tese.

7.1.3. Abrangência e independência do domínio

Um ponto de análise que assume grande importância na avaliação de um sistema

computacional é a sua abrangência e independência do domínio de aplicação. A aplicação

do Agente de Execução de Serviços em qualquer tipo de domínio ou ambiente de

execução é um critério deveras importante, pois este define o nível de utilização que o

mesmo poderá ter no futuro. Uma ferramenta genérica, embora mais difícil de

desenvolver, torna-se mais útil pela possibilidade de reutilização e aplicação em vários

domínios diferentes. Portanto, interessa avaliar, por um lado, se o Agente de Execução de

Serviços definido e implementado pode processar qualquer tipo de mecanismos de

controlo definidos na linguagem OWL-S, isto é, pretende-se determinar qual o grau de

cobertura da linguagem de descrição utilizada. Por outro lado, interessa também

determinar se o trabalho realizado irá permitir que o mesmo possa ser utilizado em

diferentes domínios de aplicação.

Para avaliar a abrangência do Agente, a utilização da linguagem OWL-S para

descrever os serviços que vão ser usados pelo Agente de Execução de Serviços terá de ser

correcta e a mais completa possível. A este nível interessa determinar se o Agente de

Execução de Serviços consegue processar descrições de serviços OWL-S de forma

completa e sem limitações. Para este efeito, são feitos testes de execução de descrições de

serviços que incluem todas as capacidades da linguagem OWL-S para determinar se o

agente executor processa toda a linguagem ou apenas um subconjunto.

No que toca à independência do domínio, pretende-se que o agente de execução de

serviços não esteja limitado a nenhum domínio em específico no que toca à execução de

serviços. A ferramenta que permite a execução de serviços descritos em OWL-S deverá


104

ser totalmente genérica e independente do domínio da aplicação. Para o efeito, serão

feitos testes que visam comprovar que o agente é capaz de processar exemplos de

descrições de serviços de domínios completamente diferentes. Isto poderá ser feito

recorrendo a descrições diversas de serviços de domínios diferentes, nomeadamente

serviços na Web e serviços prestados por outros agentes. Também serão considerados

domínios de aplicação diferentes tais como serviços de saúde e assistência a clientes em

centros comerciais, no âmbito do projecto CASCOM, embora não seja possível analisar

os resultados dessa aplicação em tempo útil para apresentar a devida avaliação nesta tese.

7.1.4. Melhorias introduzidas pela Computação Sensível

ao Contexto

A informação de contexto usada na interacção com uma entidade consiste no

conjunto de informação não explícita num acto de comunicação que pode influenciar a

forma como a actividade de uma entidade decorre. No trabalho em questão, interessa

investigar em que medida a informação de contexto pode influenciar a actividade do

Agente de execução de serviços. A avaliação da influência da informação de contexto na

execução de serviços assume maior importância quando se pretende determinar se a

execução pode ser melhorada, isto é, se o agente em questão melhora o desempenho da

execução do serviço que lhe foi requerida, pela utilização de informação de contexto.

Face a um determinado contexto, o agente adapta a execução de um determinado

serviço à nova realidade que surge da introdução de informação de contexto. Exemplos

de informação que influenciam a forma como o agente executor de serviços desempenha

a sua actividade são:

• Localização do agente cliente – quando a natureza do serviço executado é

geográfica e a localização do cliente importa para obter a informação desejada.

• Largura de banda e possibilidade de falhas na comunicação – isto influencia

o conteúdo que é transmitido. Por exemplo, se a quantidade de informação que é

trocada na execução de um serviço é muito grande (como um vídeo ou música) e

o Agente Cliente reside num aparelho com poucos recursos (como um PDA ou


105

telemóvel) que usa uma ligação sem fios (Wireless), a probabilidade de o serviço

ser executado com qualidade é muito baixa. Como tal, o agente deverá adaptar-se

a esta situação e modificar a forma como o serviço é executado ou então como o

conteúdo é apresentado.

• Propriedades dos prestadores de serviços – uma das situações que o Agente de

Execução de Serviços terá de enfrentar será a inexistência ou indisponibilidade

das fontes descritas na descrição do serviço. O agente executor terá de se adaptar

a esta situação e tomar a iniciativa de procurar fontes alternativas para poder

prosseguir com a execução do serviço.

Para se poder avaliar a qualidade do trabalho ao nível deste critério, são feitos testes

que comprovam a capacidade do agente de execução de serviços de se adaptar a

mudanças de contexto e a forma como essa adaptação melhora a actividade do agente.

Porém, este teste apenas revela a importância de se usar a informação de contexto para

influenciar a actividade do agente, mas não evidencia as vantagens de se usar uma

abordagem de “sensibilidade ao contexto” ao invés de uma em que o conhecimento de

contexto seja explícito na comunicação entre entidades. Isto é, em vez de o Agente de

Execução de Serviços obter a informação de contexto através de um sistema externo que

monitoriza e facilita a difusão da mesma, este obtém-na directamente na comunicação

com as entidades às quais a informação de contexto respeita. Na secção 7.2.4 é feita uma

análise destas duas abordagens para que se identifiquem as suas vantagens e

desvantagens.

7.1.5. Autonomia

A autonomia de um sistema é uma característica importante, pois um sistema

inteligente que consegue ter a autonomia necessária para tomar decisões importantes

relativas ao seu funcionamento/actividade sem necessitar da intervenção de um utilizador

ou outra entidade, constitui uma grande mais-valia. No trabalho em questão, é importante

determinar o grau de autonomia do agente na execução dos serviços, sem esquecer que há

certos tipos de decisões que devem ser tomadas pelos clientes.


106

Em determinadas alturas da execução de um serviço, o agente poderá ter de tomar

decisões relativas aos passos seguintes da execução do serviço. Nesta altura, é importante

avaliar se as decisões tomadas autonomamente pelo agente de execução de serviços

satisfazem ou não os seus clientes, e a medida em que a escolha das situações em que o

agente pode decidir é judiciosa. Isto é, interessa avaliar se o agente decidiu numa situação

em que deveria ter sido o cliente a decidir e também o caso em que se o agente não

decidiu, quando deveria ter decidido. Mais uma vez, o teste em questão não será realizado

por o mesmo implicar a criação de diversos agentes e serviços (para retratar a existência

de diversas situações e cenários diferentes), sendo que o excesso de recursos necessários

poderia atrasar o decorrer do trabalho normal da tese.

7.1.6. Rapidez

A rapidez de actuação de um sistema é um factor muito importante, pois o tempo

condiciona a utilidade de grande parte das acções executadas pelo mesmo. Por exemplo, a

informação criada pela actividade de um sistema pode ser útil apenas num determinado

intervalo de tempo. Se a obtenção dessa informação demora mais tempo do que o

intervalo de tempo determinado, ela deixa de ser útil. Por outro lado, a análise do tempo

de execução do sistema poderá ajudar também a determinar se a abordagem escolhida

para a sua implementação e funcionamento é a melhor, comparativamente com as suas

alternativas.

Para que o serviço prestado pelo Agente de Execução de Serviços seja considerado

como um serviço útil, este terá de decorrer em tempo útil. Os testes realizados visam

medir os tempos de execução do agente durante a sua actividade, e os resultados são

analisados para determinar se o tempo é considerado satisfatório para quem o requereu.

São também feitos testes comparativos entre o trabalho desenvolvido na tese e

abordagens alternativas que existam. Esta comparação visa determinar se o trabalho

desenvolvido é melhor que as abordagens alternativas, ou pelo menos, se não introduz um

tempo adicional exagerado, face às restantes vantagens que apresenta em relação às

alternativas.


107

7.2. Resultados e Avaliação

O cenário descrito no Capítulo 3 foi totalmente implementado, o que permitiu avaliar

a satisfação de alguns dos critérios descritos na secção 7.1. Nesta secção são apresentados

os resultados obtidos com o desenvolvimento e teste do cenário implementado e é feita

uma análise e avaliação desses resultados sobre vários pontos de vista, de acordo com os

critérios definidos na metodologia de avaliação.

7.2.1. Utilidade e qualidade do agente de execução de

serviços

Apesar deste teste não ter sido realizado, tenciona-se aplicar o mesmo no decorrer do

projecto CASCOM, onde se espera que a quantidade elevada de serviços operando em

ambientes dinâmicos sirvam como base realista para o teste descrito.

7.2.2. Flexibilidade, interoperabilidade e facilidade de

utilização do Agente

Apesar de todas as interacções entre o Agente de Execução de Serviços e o Agente

Cliente poderem ocorrer respeitando as especificações da FIPA (tornando assim o agente

totalmente interoperável), a facilidade de utilização do Agente pode ser comprometida,

como reflecte o conflito existente entre os requisitos R4 (ver Tabela 9 no anexo B –

Requisito “Execução de serviços com aprovação do Cliente”) e R8 (ver Tabela 13 no

anexo B – Requisito “Interface simples com o Agente cliente”). A necessidade de

aprovação individual de Prestadores de Serviços por parte do Agente Cliente, exige que

este seja capaz de processar perguntas complexas. Esta necessidade elimina o factor

enunciado como elementar na facilidade de utilização do Agente de Execução de

Serviços: um cliente não teria de ter capacidades especiais para interagir com este. Uma

vez que a importância dada ao requisito R8 é maior que a dada ao requisito R4 (com base

nos valores de Satisfação/Insatisfação de cliente da tabela de especificação Volere),


108

optou-se por implementar o primeiro e não implementar o segundo. Esta decisão parte da

análise da complexidade associada à implementação do requisito R4 (sendo que este

obrigaria ao desenvolvimento de um Agente Cliente mais sofisticado que conseguisse

responder às perguntas realizadas pelo Agente de Execução de Serviços) face à restrição

temporal da própria tese, não permitindo o desenvolvimento de um Agente Cliente de

testes com estas características.

Apesar de se eliminar assim a flexibilidade do Agente de Execução de Serviços no

que toca à situação específica de requerer a aprovação do Agente Cliente, conseguiu-se

manter a interoperabilidade e facilidade de utilização do mesmo e ainda fomenta-se a

capacidade de autonomia do Agente. Em relação à implementação do requisito, decidiu-

se que o Agente é autónomo na necessidade de procura de prestadores de serviços (ou

seja, não contacta o Agente Cliente), mas esta procura é feita tendo em conta as restantes

restrições contextuais do serviço (como por exemplo, restrições temporais). O efeito desta

decisão ao nível da execução de serviços é dado pela comparação entre o resultado

efectivo da execução e o resultado esperado (efeito) de um serviço. Sendo que esta

decisão influencia também o critério de autonomia, a mesma é discutida na secção 7.2.5.

7.2.3. Abrangência e independência do domínio

A abrangência e independência do domínio de um componente mede-se através da

sua possibilidade de reutilização e aplicação em vários domínios diferentes. Para avaliar o

resultado do desenvolvimento do Agente a este nível, analisou-se o trabalho de

implementação do mesmo a três níveis: a reutilização dos componentes, a abrangência do

executor de serviços em relação à especificação OWL-S e a utilização do agente em

diferentes domínios de aplicação.

No que toca à reutilização dos componentes, os mesmos foram desenvolvidos com o

intuito de serem reutilizados no desenvolvimento de outros agentes. O componente de

interacção com agentes foi utilizado para criar os restantes agentes na implementação do

cenário: o Agente de Descoberta de Serviços e os diversos Agentes Prestadores de

Serviços. Os componentes do motor do agente e de execução de serviços desenvolvem


109

tarefas muito específicas que estão muito ligadas ao domínio da execução de serviços,

dificultando a sua utilização no desenvolvimento de outros agentes. No entanto, algumas

partes desenvolvidas nestes componentes são facilmente reutilizáveis, como é o caso da

API que gere a interacção do motor do agente com a plataforma genérica de informação

de contexto.

A abrangência do executor de serviços foi testada através da execução de vários tipos

de serviços diferentes que incluem todo o tipo de construções procedimentais do OWL-S,

incluindo “RepeatUntil”, “ Split-Join”, “ If-Then-Else”, “ RepeatWhile” e “Sequence”. Os

serviços utilizados foram também usados para testar a independência do domínio do

agente desenvolvido. Os testes realizados consistiram na execução de serviços de teste

disponíveis na página oficial do software OWL-S API35 e incluem domínios como

pesquisa de códigos postais, pesquisa de coordenadas geográficas, utilização de

dicionários em inglês e francês, tradução de textos entre línguas e pesquisa de preços de

livros. Todos estes exemplos de domínios diferentes foram executados com sucesso,

provando que o software desenvolvido é independente do domínio sobre o qual executa

serviços. O Agente de Execução de Serviços será também testado ao longo do projecto

CASCOM em domínios mais complexos como aplicações relacionadas com sistemas de

saúde e sistemas de serviços de áreas comerciais específicas, como centros comerciais.

7.2.4. Melhorias introduzidas pela Computação Sensível

ao Contexto

A introdução do uso de informação de contexto no processo de execução de serviços

é uma das principais contribuições do trabalho desta tese. O objectivo desta introdução

consistia em avaliar em que medida é que a computação sensível ao contexto pode

influenciar e melhorar o processo de execução de serviços. A este nível é importante

analisar qual a vantagem de considerar informação de contexto no domínio da execução

de serviços, e para tal, é necessário comparar esta abordagem com uma abordagem de

35 http://www.mindswap.org/2004/owl-s/services.shtml


110

execução de serviços que não utilize informação de contexto. A OWL-S API pode ser

usada nessa comparação uma vez que permite realizar a execução de serviços sem usar

informação de contexto. Por outro lado, seria igualmente importante realizar a

comparação entre a abordagem escolhida para lidar com a informação de contexto

(através da computação sensível ao contexto) com outra abordagem onde esse

conhecimento estivesse explícito na comunicação entre as entidades.

A grande vantagem da introdução da computação sensível ao contexto prende-se com

o facto de o agente poder adaptar-se a situações específicas que poderiam impossibilitar a

execução de um serviço e ainda assim executá-lo com sucesso. A infra-estrutura de

coordenação de serviços, criada pela junção da computação sensível ao contexto com a

interacção com agentes de descoberta e composição de serviços, permite melhorar o

processo de execução de serviço no sentido em que o agente consegue encontrar

alternativas (procura de prestadores de serviços alternativos caso seja necessário) ou

adequar o serviço às condições/restrições actuais (procura de prestadores de serviços que

forneçam os mesmos mais rapidamente diminuindo assim o tempo de execução), coisa

que, por exemplo, a OWL-S API não faz se for utilizada como um componente isolado na

execução de serviços. Desta forma, comprova-se que a introdução da informação de

contexto no processo de execução de serviços apresenta vantagens em relação a uma

abordagem tradicional de execução de serviços. No entanto, interessa analisar de que

forma esta medida influencia também a eficácia e rapidez da execução de serviços. Esta

análise é feita na secção 7.2.6.

A abordagem escolhida assume a existência de uma infra-estrutura de informação de

contexto que permite que diversas entidades partilhem o seu contexto/situação de forma

implícita. Uma abordagem alternativa passaria por usar a mesma informação, mas de

forma explícita na comunicação entre as entidades. Embora não tenha sido possível

realizar esta comparação (pelo facto de não existir um sistema que use esta abordagem) é

possível realizar uma pequena análise comparativa entre as duas abordagens para tentar

perceber qual é a mais adequada para utilizar no domínio da execução de serviços.

Em termos práticos, qualquer abordagem que utilize informação de contexto

consegue obter os mesmos resultados que a abordagem utilizada no trabalho da tese. No


111

entanto, a segunda, apesar de não mostrar qualquer vantagem aparente ao nível do

processamento da informação de contexto (uma vez que em princípio a informação usada

e o processamento efectuado por ambas as abordagens seriam os mesmos), evidencia-se

melhor ao nível da interacção, pois esta fica mais simplificada por não existir a

introdução explícita de informação de contexto na comunicação. Uma abordagem

alternativa comprometeria o requisito que reflecte a necessidade de simplificação e

facilidade de utilização do Agente de Execução de Serviços (ver Tabela 13 no anexo B).

Por esta razão, optou-se por desenvolver a abordagem que usa a computação sensível ao

contexto.

7.2.5. Autonomia

Como explicado na secção 7.2.2, foi necessário proceder a uma decisão para a

resolução de um conflito entre a facilidade de utilização e a flexibilidade do Agente de

Execução de Serviços. A decisão consistiu em eliminar a possibilidade do agente recorrer

ao cliente para obter a aprovação de alternativas de prestadores de serviços, caso fosse

necessário. Apesar de se abdicar da flexibilidade do agente, esta decisão é um passo

importante no que toca à análise da autonomia do mesmo, na resolução de problemas face

a situações específicas. Devido à falta de recursos, não foi possível implementar uma

base de testes que permitisse testar a fundo as consequências desta decisão ao nível da

procura de alternativas na execução de serviços. Esta base de testes teria de incluir

diversos serviços diferentes fornecidos por diversos agentes, para ser possível ao agente

procurar as alternativas necessárias. No entanto, foi possível realizar um teste controlado

a uma escala menor, encenando uma situação que obrigava o agente a procurar uma

alternativa ao prestador de serviço original, que se encontrava indisponível. Para permitir

essa pesquisa foi necessário implementar o prestador de serviço alternativo que fornecia

um serviço semelhante ao do prestador original. Este cenário controlado permitiu testar a

integração global dos diversos elementos, sendo que foi possível apreciar o Agente de

Execução de Serviços a interagir com o Agente de Descoberta de Serviços para procurar

um prestador alternativo, quando obteve a informação necessária por parte da plataforma

genérica de informação de contexto.


112

Uma vez comprovada a capacidade do agente se adaptar a este tipo de situações,

interessa analisar se a adição destas capacidades ao agente, influencia a sua capacidade de

resposta no que toca ao tempo de processamento e execução de um serviço. Esta análise é

feita na secção seguinte.

7.2.6. Rapidez

O agente desenvolvido utiliza informação contextual para tomar decisões autónomas

que melhoram o processo de execução, permitindo que este ofereça aos seus clientes um

serviço de execução bastante satisfatório. Porém, a utilização destas técnicas para

influenciar o processo de execução, pode ter consequências ao nível do tempo total de

execução de um serviço.

Para se proceder à análise desta potencial desvantagem, foram realizados testes

intensivos de execução de serviços para registar não só o tempo acrescido ao tempo total

de execução (devido à utilização de informação de contexto e do contacto com outros

agentes), mas também a actividade do agente ao longo do tempo.

0

2

4

6

8

10

12

14

1 30 59 88 117

Pedidos

Seg

. TET

OET

TNE

Figura 24 - Execução do Serviço "Book Price" usando A gentes como Fornecedores de

Serviços

A Figura 24 ilustra o teste realizado na execução do serviço “Book Price”, o serviço

da pesquisa do melhor preço de um determinado livro que foi descrito no Capítulo 3.

Neste teste foram utilizados os Agentes Prestadores de Serviços descritos na secção


113

3.2.3.1. O teste realizado consistiu na execução intensiva do serviço, em que o Agente

Cliente pediu a execução do serviço 120 vezes, sendo que o tempo total de execução do

teste foi de 421 segundos. A área a amarelo representa o tempo normal de execução

(TNE) do serviço, isto é, representa o tempo que demoraria a executar o serviço se se

usasse só a abordagem tradicional36 de execução de serviços. A área a vermelho (OET –

Overhead de Execução Total) representa o tempo adicionado (denominado de overhead)

pelo Agente de Execução de Serviços (AES), ao tempo de execução normal do serviço.

Isto inclui a comunicação com o Agente Cliente (AC), a gestão interna do AES, a

interacção com a Plataforma Genérica de Informação de Contexto (PGIC) e a preparação

para a execução do serviço. A área a verde (TET – Tempo de Execução Total) representa

o tempo total de execução do serviço, isto é, o tempo normal de execução do serviço mais

o overhead causado pelo AES.

A conclusão que se retira imediatamente da visualização do gráfico é a de que o AES

vai deteriorando a execução do serviço ao longo do tempo, aumentando

exponencialmente o overhead de execução. Sendo que esta situação reflecte uma situação

anormal, decidiu-se proceder à elaboração de um segundo teste que permitisse

determinar, dentro do tempo de overhead, o que estaria a causar este comportamento de

deterioração ao longo do tempo.

Para a realização do teste, decidiu-se dividir o tempo de overhead em três tipos para

determinar qual a tarefa do agente que estaria a causar este comportamento: tempo de

comunicação com o AC (TCA); tempo de gestão e preparação (TP), que inclui a gestão

de conversações e o acesso a informação de contexto; e tempo de preparação para a

execução (TPE), que inclui a adaptação do serviço à situação.

Facilmente se percebe, da leitura do gráfico na Figura 25, que o que causa o aumento

do overhead é o tempo de preparação, ou seja, a gestão das conversações e o acesso à

informação de contexto.

36 Pode-se usar como referência da abordagem tradicional, o uso da OWL-S API como

componente único, isto é, sem adicionar as capacidades extra que o Agente de Execução de

Serviços adiciona.


114

0

2

4

6

8

10

12

14

1 30 59 88 117

Pedidos

Seg

. OET-TP

OET-TCA

OET-TPE

Figura 25 - Overhead de execução do serviço " Book Price"

Procedendo a testes mais concretos, descobriu-se que o causava este comportamento

no overhead, era uma utilização não optimizada de tabelas de dispersão (Hashtables) no

algoritmo de gestão de conversações entre o AES e os seus clientes. Corrigida a situação,

que consistiu numa utilização optimizada das tabelas de dispersão através da integração

destas com vectores (quando estes se mostraram mais eficientes), procedeu-se à

reelaboração dos testes referidos.

0,0

0,1

0,2

0,3

0,4

0,5

0,6

0,7

0,8

0,9

1,0

1 51 101 151 201 251

Pedidos

Seg

. TET

TNE

OET

Figura 26 - Execução do Serviço " Book Price" - 2º teste

De forma a testar se a optimização realizada influencia a execução do serviço ao

longo do tempo, decidiu-se aumentar o número de pedidos realizados para 280, sendo que

o tempo total da realização do teste foi de cerca de 120 segundos. A Figura 26 ilustra o


115

resultado do segundo teste de execução do serviço “Book Price”. Devido à optimização

realizada, o overhead de execução é agora constante, ao contrário do apresentado no teste

anterior (ver Figura 24 e Figura 25). Os detalhes do teste realizado podem ser consultados

na Tabela 4. Todos os valores desta tabela são em segundos.

Total Médio Max Min

TET 120,22 0,43 0,93 0,27

TNE 103,99 0,37 0,88 0,25

OET 16,23 0,06 0,32 0,01

Tabela 4 - Detalhes do teste de execução do serviço "Book Table" - 2º teste

Nesta tabela podemos apreciar o resultado geral da execução do serviço ao longo dos

280 pedidos efectuados. No total dos 280 pedidos, o overhead de execução foi de cerca

de 16 segundos, e em termos médios este foi de 0,06 segundos. Isto significa, em termos

percentuais, que o tempo que é acrescentado ao tempo normal de execução de um serviço

é em média de 14%. Tal como no teste anterior, é importante detalhar o overhead, para

saber qual a parte deste processo que está a causar o maior acréscimo no tempo normal de

execução. A Figura 27 ilustra o teste realizado, para detalhar o overhead de execução do

serviço “Book Price”.

0,0000

0,0500

0,1000

0,1500

0,2000

0,2500

0,3000

0,3500

1 51 101 151 201 251

Pedidos

Seg

. OET-TP

OET-TCA

OET-TPE

Figura 27 - Overhead de execução do serviço "Book Price" – 2º teste

Ao longo do tempo de execução dos 280 pedidos efectuados, o overhead de execução

é mais ou menos constante. A tarefa específica que mais contribui para a causa do


116

overhead de execução é a tarefa de preparação (OET-TP), embora por vezes a tarefa de

comunicação com agentes (OET-TCA) seja a tarefa que mais contribui para o aumento

do overhead. Porém, a explicação para a causa da OET-TCA contribuir para este efeito é

dada pelo ambiente em que os agentes operam, sendo que estas oscilações estão

dependentes do tráfego de rede sobre a qual estes comunicam.

No que toca à análise do efeito causado pela tarefa de preparação no overhead,

embora as oscilações ilustradas na figura também possam ser explicadas pelo tráfego

existente na rede, esta evidencia no entanto um comportamento constante de contribuição

para o aumento do overhead, sendo que em média esta acrescenta 0,05 segundos ao

serviço executado. Uma análise mais profunda desta tarefa permitiu concluir que o que

causa este acrescento é na verdade a comunicação com a plataforma genérica de

informação de contexto. Esta comunicação é feita através do interface cliente em Jini

disponibilizado pela própria plataforma. Como tal, este acréscimo acaba por ser alheio ao

desempenho do agente, sendo que qualquer optimização a ser realizada, terá de ocorrer

do lado da plataforma genérica de informação de contexto. Está previsto o

desenvolvimento, num futuro imediato, de um acesso à plataforma genérica de

informação de contexto através da infra-estrutura de comunicação do XSP. Esta alteração

poderá diminuir o tempo acrescentado pelo agente durante a execução de um serviço,

mas para já não é possível realizar os testes necessários, por não ter sido ainda

desenvolvida essa interface na plataforma genérica de informação de contexto.

Após a realização de todos estes testes, chegou-se à conclusão que o overhead é, em

média, de 14%. No entanto, este é um valor relativo, obtido em função do tempo normal

de execução do serviço “Book Price” que, em termos absolutos, demora em média 0,37

segundos a ser executado. A análise necessária passa agora por determinar se o overhead

acompanha o aumento do tempo normal de execução de um serviço. Isto é, se o tempo

normal de execução de um serviço for muito superior, será que o overhead acompanha

esse aumento?

A resposta é dada pela realização de vários testes de execução de serviços, cujos

tempos normais de execução sejam muito diferentes dos do serviço demonstrado. Para

analisar o comportamento do overhead na variação do tempo normal de execução de um


117

serviço, decidiu-se realizar os mesmos testes anteriormente efectuados sobre um serviço

cujo tempo normal de execução é muito superior ao do serviço “Book Price” cujos

prestadores de serviços são agentes. O teste escolhido foi o mesmo serviço “Book Price”,

mas desta vez com a utilização de serviços na Web como prestadores de serviços. A

razão para a utilização destes prestadores originar um tempo normal de execução do

serviço composto superior ao anterior, passa pelo facto de estes serviços na Web estarem

disponíveis na Internet onde são utilizados por diversos sistemas de teste que estão

constantemente a aceder aos mesmos, aumentando em grande escala o tráfego de acesso

aos serviços.

0

100

200

300

400

500

600

700

1 11 21 31 41 51 61

Pedidos

Seg

. TET

OET

TNE

Figura 28 - Execução do serviço " Book Price" usando serviços na Web como prestadores

de serviços

A Figura 28 ilustra o resultado da execução do serviço “Book Price” usando serviços

na Web como prestadores de serviços. Como se pode ver no gráfico, o overhead de

execução causado pelo agente é constante. A Tabela 5 complementa o gráfico com alguns

valores absolutos.

Total Médio Max Min

TET 14553,94 210,93 607,79 39,77

TNE 14550,87 210,88 607,68 39,75

OET 3,07 0,04 0,16 0,01

Tabela 5 - Detalhes do teste de execução do serviço "Book Price" - com serviços na Web


118

No tempo total de execução do teste, o overhead total foi apenas de 3 segundos, e em

termos médios este valor foi de 0,04 por pedido de execução, representando apenas

0,00021% do tempo normal de execução. Isto comprova que o overhead não tem um

comportamento variável associado à execução dos serviços.

No entanto, a execução normal do serviço ao longo do tempo apresenta um aumento

exponencial à medida que a realização de pedidos de execução aumenta. Como é visível

na tabela, o tempo total da execução dos 70 pedidos efectuados, foi de cerca de 242,5

minutos, ou seja, cerca de 4 horas. Este valor elevado deve-se ao facto de haver um

comportamento estranho na execução do serviço, que influencia o tempo de execução de

pedidos consecutivos. Para determinar a causa deste comportamento foi realizado um

teste que visa determinar qual a parte da execução do serviço que está a causar o aumento

do tempo normal de execução.

Tal como explicado na secção 3.2.2.1, o serviço “Book Price” é composto por

diversos serviços atómicos: Book Finder, Barnes & Noble Price, Amazon Price,

Compare Prices e Currency Converter. A Figura 29 ilustra o tempo de execução do

serviço composto e o detalhe de cada um dos serviços que o compõem.

0

20

40

60

80

100

120

140

1 11 21 31

Pedidos

Seg

.

Book Finder

Barnes & Noble Price

Amazon Price

Compare Prices

Currency Converter

Total

Figura 29 - Execução detalhada do serviço composto "Book Price"


119

Como se pode comprovar pela figura, todos os serviços atómicos apresentam um

comportamento constante, à excepção do processo responsável pela comparação dos

preços obtidos (Compare Prices). A execução deste processo deteriora-se ao longo do

tempo, causando o aumento exponencial do tempo normal de execução do serviço “Book

Price”.

Após análise mais profunda da execução deste serviço atómico, determinou-se que a

causa deste atraso é a ferramenta que realiza a análise sintáctica e a avaliação das

expressões condicionais contidas neste processo. Neste teste, foi usada a linguagem

SWRL para descrever as expressões condicionais e a execução deste processo é feita

através da utilização da linguagem de perguntas SPARQL [Prud’hommeaux & Seaborne,

2004], para a avaliação das expressões na sua sintaxe XML/RDF. No entanto, a

implementação da ferramenta que realiza a análise sintáctica da expressão condicional em

SWRL e a sua avaliação através da linguagem SPARQL, não foi ainda optimizada ou

testada o suficiente para evitar o comportamento ilustrado no teste realizado. Sendo que a

OWL-S API inclui o software referido, esta (e consequentemente o agente) apresenta o

mesmo comportamento quando se usam expressões condicionais em SWRL.

Uma vez que um dos objectivos iniciais do trabalho da tese era a definição da

linguagem a utilizar na especificação de expressões condicionais em serviços OWL-S, foi

implementada a extensão necessária na OWL-S API para processar as mesmas na

linguagem escolhida, o Prolog. Apesar de posteriormente, a nova versão da OWL-S API

ter apresentado uma alternativa (o uso do SWRL), é importante realizar também uma

comparação entre estas duas abordagens para determinar qual a mais adequada para a

utilização de expressões condicionais. Para tal, decidiu-se realizar o mesmo teste ao

serviço “Book Price” usando serviços na Web, mas desta vez utilizando a representação

Prolog das expressões condicionais descritas no serviço OWL-S.

A Figura 30 ilustra o resultado do teste de execução do serviço “Book Price”, desta

vez descrevendo as expressões condicionais em Prolog.


120

0

10

20

30

40

50

60

70

1 11 21 31 41 51

Pedidos

Seg

. TET

OET

TNE

Figura 30 - Execução do serviço " Book Price" – expressões condicionais em Prolog

Apesar da execução do serviço usando o Prolog ser bastante mais rápida ao longo do

tempo, nota-se uma ligeira subida do tempo de execução total no final do teste. Para

determinar a causa desta subida, é necessário realizar o teste detalhado dos serviços

atómicos que compõem o serviço da mesma forma que se realizou para a abordagem em

que se usa a linguagem SWRL.

0

5

10

15

20

25

30

35

40

45

50

1 11 21 31 41 51

Pedidos

Seg

.

Book Finder

Barnes & Noble Price

Amazon Price

Compare Prices

Currency Converter

Total

Figura 31 - Execução detalhada do serviço composto "Book Price" – com Prolog


121

Apesar do processo de comparação de preços, no qual estão descritas as expressões

condicionais em Prolog, apresentar uma ligeira subida no final do teste, são na verdade

os dois serviços “Barnes & Noble Prices” e “Amazon Price” que causam o aumento do

tempo de execução do serviço “Book Price”. Esta ligeira subida pode dever-se à

invocação intensiva dos serviços ou então ao tráfego de rede existente na altura do teste.

Para comprovar que este aumento evidenciado pelo teste foi apenas um acaso das

condições em que o Agente opera, decidiu-se realizar um teste de execução de um serviço

que continha apenas uma expressão condicional descrita em Prolog, para observar o

comportamento da execução ao longo do tempo. Optou-se por não incluir serviços na

Web neste teste para evitar os comportamentos evidenciados anteriormente (atrasos da

execução devido a tráfego na rede). Este teste consistiu na invocação do serviço de forma

consecutiva, em 1500 pedidos. A Figura 32 ilustra o teste realizado, o qual demonstra que

o comportamento da execução do serviço é constante ao longo do tempo. Como tal, pode

concluir-se que a utilização de expressões condicionais descritas em Prolog apresenta um

comportamento constante e eficiente ao longo do tempo na utilização intensiva de

serviços.

0,0

0,1

0,2

0,3

0,4

0,5

0,6

0,7

0,8

1 251 501 751 1001 1251

Pedidos

Seg

. TET

TNE

OET

Figura 32 - Teste de execução de expressões condici onadas em Prolog

Face aos testes e análises efectuadas nesta secção, pode concluir-se que a execução

de serviços levada a cabo pelo agente (com a mais-valia da utilização de informação de

contexto e de uma infra-estrutura de coordenação de serviços) é bastante satisfatória,


122

sendo que o overhead de execução introduzido é de apenas, em média, 0,05 segundos,

valor este, que não é de maneira alguma perceptível pelo Utilizador. Apesar de não ser

possível concluir que a utilização do Prolog é a mais indicada na descrição de expressões

condicionadas no serviço OWL-S, por a diferença encontrada nos testes dever-se a uma

má implementação do motor de execução associado à linguagem SWRL, a sua utilização

mostrou-se eficiente ao longo do tempo em testes de execução intensiva de serviços.

7.3. Considerações finais de avaliação

A metodologia de avaliação aplicada ao trabalho da tese evidenciou a qualidade do

trabalho desenvolvido, especialmente ao nível da criação de um Agente de Execução de

Serviços que usa informação de contexto para melhorar o processo de execução de

serviços. Essa optimização consiste na adaptação do serviço a uma situação específica (de

acordo com informação de contexto disponível) de forma a que a execução deste decorra

sempre num tempo considerado útil para o cliente que o requereu e que, em caso de falha

de algum dos elementos que compõem o serviço, proceda à procura de alternativas

adequadas.

Testes realizados evidenciaram também que, apesar da inclusão da computação

sensível ao contexto à infra-estrutura de execução de serviços, o tempo que é

acrescentado ao tempo normal de execução, o overhead, não é de forma alguma

perceptível pelo utilizador do serviço, por ser tão reduzido. Foi também evidenciado nos

testes realizados que esta melhoria do desempenho pode, em determinadas circunstâncias,

reduzir o tempo total de execução do serviço, mesmo abaixo do seu tempo normal de

execução. Isto deve-se ao facto de, por vezes, ser necessário ao Agente de Execução de

Serviços procurar prestadores de serviços alternativos para executar um serviço, e as

alternativas encontradas serem mais rápidas que as originais.

A utilização do Prolog na especificação de expressões condicionais na descrição dos

serviços OWL-S mostrou-se eficiente, através de testes intensivos de execução de

serviços com instruções condicionadas descritas com esta linguagem, ao contrário do que

sucedeu com os mesmos testes realizados utilizando SWRL como a linguagem de


123

especificação de expressões condicionais. Porém, não foi possível provar que esta

desvantagem da abordagem SWRL reside na própria linguagem, uma vez que os testes

efectuados apenas reflectem que o motor de execução da mesma não foi bem

implementado.

124

CCaappííttuulloo 88.. CCOONNCCLL UUSSÕÕEESS EE

TTRRAABBAALL HHOO FFUUTTUURROO

A infra-estrutura semântica da Web e o avanço das tecnologias de agentes,

juntamente com a inovação da computação sensível ao contexto, foram a base para a

realização deste projecto de investigação. A motivação do mesmo surgiu da necessidade

de executar descrições de serviços compostos e descrições de serviços em que a escolha

dos prestadores depende de contexto. A ambição do trabalho centrou-se no

desenvolvimento de um Agente de Execução de Serviços que, através do uso de

informação de contexto, consegue melhorar a execução de todo o tipo de serviços

descritos em OWL-S, fornecidos por qualquer tipo de prestadores de serviços (incluindo

agentes inteligentes).

O trabalho desenvolvido iniciou-se com a avaliação do estado actual de

conhecimentos das áreas em questão, onde se evidenciou a necessidade de

desenvolvimento de uma infra-estrutura de coordenação de serviços que oferecesse uma

base de execução de serviços sensível a alterações contextuais, típicas dos ambientes

dinâmicos. Após a definição de um cenário descritivo de um serviço inovador de

comércio electrónico de livros, foi possível realizar a modelação de um sistema que

permitisse a demonstração do mesmo. Esta modelação consistiu no levantamento de

requisitos, no desenho formal do sistema e na definição de um conjunto de componentes

reutilizáveis de software que visam endereçar as necessidades evidenciadas pelos

requisitos.

Capítulo 8 - Conclusões e Trabalho Futuro

125

Os requisitos impostos pelo cenário serviram também de base à implementação de

um conjunto de extensões à ontologia de descrição de serviços, que possibilitam a

especificação de outros prestadores de serviços, como os agentes inteligentes (através da

definição da linguagem AgentGrounding e do algoritmo de conversão de mensagens

correspondente), e a especificação de expressões condicionais (as quais são usadas em

instruções condicionadas e nas pré-condições e efeitos) utilizando o Prolog como

linguagem de descrição. As extensões realizadas foram incorporadas no conjunto de

componentes definidos na modelação do sistema, cuja implementação e integração deu

origem ao Agente de Execução de Serviços.

Todo o trabalho desenvolvido, embora realizado sobre premissas de trabalho

inovador (originadas pelo trabalho de investigação levado a cabo na análise do estado

actual de conhecimentos, da elaboração de um cenário inovador e da análise de

requisitos), foi avaliado sob um conjunto de critérios que caracterizam a qualidade do

mesmo. Através da realização de testes associados aos critérios identificados, foi possível

concluir que, por um lado, o trabalho desenvolvido apresenta uma qualidade elevada

quando comparado com as alternativas existentes, e por outro, este evidencia-se inovador

no sentido em que conseguiu demonstrar a sua utilização num cenário complexo, sem

afectar princípios básicos do desenvolvimento de software em geral (como a

interoperabilidade, facilidade de utilização, robustez, escalabilidade, abrangência,

independência do domínio e rapidez) e do desenvolvimento de software inteligente em

particular (como a autonomia).

O Agente inteligente desenvolvido está actualmente a ser integrado com o restante

software criado no projecto CASCOM. A integração está a cargo de um projecto final de

curso de alunos de IGE (Informática e Gestão de Empresas) do ISCTE, colaboradores do

grupo de investigação “We, the Body and the Mind”. Estima-se que mais resultados

relativos ao seu desempenho no ceio do CASCOM estejam disponíveis na altura da

discussão da tese.


126

8.1. Continuidade do trabalho

Embora os resultados obtidos sejam satisfatórios, no sentido em que evidenciam a

inovação do trabalho realizado, há elementos desta investigação que precisam ser tratados

convenientemente para permitir uma aceitação mais alargada do trabalho desenvolvido.

Um dos elementos que não permitiu apresentar resultados mais sólidos no que toca à

avaliação do trabalho desenvolvido, foi a ausência de uma base de testes mais completa e

representativa dos ambientes dinâmicos em que se visa utilizar um agente do tipo do

implementado neste trabalho de investigação. Esta limitação será superada pela utilização

do agente desenvolvido no âmbito do projecto CASCOM. Esta utilização permitirá

realizar testes mais completos e efectuar uma análise mais profunda da inovação do

trabalho desenvolvido, isto é, analisar se as contribuições realizadas cumprem totalmente

os seus objectivos ou se as mesmas necessitam ser corrigidas, melhoradas ou

optimizadas.

Apesar do Agente de Execução de Serviços desenvolvido interagir com outros

agentes e subsistemas externos para melhorar o seu processo de execução, não foi

possível testar a interacção deste com uma outra característica fundamental de uma infra-

estrutura de coordenação de serviços: a composição de serviços. Espera-se que no

decorrer do projecto CASCOM, seja possível realizar a integração do Agente de

Execução de Serviços com um Agente de Composição de Serviços e que seja possível

testar a melhoria que é introduzida no processo de execução de serviços, como

consequência desta integração.

A extensão realizada ao nível da especificação das expressões condicionais, usando a

linguagem Prolog, apresenta actualmente a limitação de só ser possível utilizar o

conhecimento incluído no motor de inferência do próprio Prolog, isto é, não é possível

introduzir conhecimento específico do domínio do serviço que está a ser executado numa

dada altura37. Esta limitação acontece, porém, apenas ao nível do agente desenvolvido por

não ter havido tempo para implementar esta funcionalidade. O software integrado no

37

Capítulo 8 - Conclusões e Trabalho Futuro

127

agente (módulo de interface ao LPA-Prolog) já permite esta funcionalidade de adição

dinâmica de conhecimento (novos predicados e factos). Como tal, espera-se também

poder superar esta limitação, integrando a extensão com trabalho desenvolvido ao nível

da definição e publicação de ontologias de forma a permitir ao Agente de Execução de

Serviços a utilização de conhecimento específico do domínio, alargando assim o rol de

conhecimento a que este tem acesso na avaliação de expressões condicionais contidas na

descrição de um serviço OWL-S. De notar que a eliminação desta limitação não deve, de

forma alguma, comprometer o requisito de independência do domínio exigido pela

aplicabilidade do agente desenvolvido em diversos domínios diferentes.

128

Referências [Abowd et al, 1998] Abowd, G.D.; Dey, A.; Orr, R. and Brotherton, J.; 1998; Context-awareness in

wearable and ubiquitous computing; IEEE International Symposium on Wearable Computers,

ISBN:0-8186-8192-6, p.179.

[Ankolekar et al, 2002] Ankolekar, A.; Burstein, M.; Hobbs, J.R.; Lassila, O.; Martin, D.; McDermott, D.;

McIlraith, S.A.; Narayanan, S.; Paolucci, M.; Payne, T. and Sycara, K.; 2002; DAML-S: Web

Service Description for the Semantic Web; Proceedings of the First International Semantic Web

Conference, ISSN: 0302-9743, p. 348.

[Arnold & Gosling, 1996] Arnold, K. and Gosling, J.; 1996; The Java™ Programming Language;

Addison-Wesley.

[Arnold, 1999] Arnold, K.; 1999; The Jini specification; Harlow: Addison-Wesley.

[Bellifemine, Poggi & Rimassa, 1999] Bellifemine, F.; Poggi, A. and Rimassa, G.; 1999; JADE – a FIPA-

compliant agent framework; CSELT internal technical report; Parte deste relatório foi também

publicado nos Proceedings do PAAM'99, London, pp.97-108.

[Bergenti & Poggi, 2001] Bergenti, F. and Poggi, A.; 2001; LEAP: A FIPA Platform for Handheld and

Mobile Devices; 8th International Workshop on Intelligent Agents, ISSN: 0302-9743, p. 436.

[Bradshaw, 1997] Bradshaw, J. M.; 1997; An Introduction to Software Agents; Software Agents, MIT

Press, ISBN:0-262-52234-9.

[Brown & Kindel, 1998] Brown, N. and Kindel, C. ; 1998; Distributed Component Object Model Protocol

DCOM/1.0, Microsoft Corporation.

[Bruijn et al, 2005] Bruijn, J. ; Lausen, H.; Krummenacher, R.; Polleres, A.; Predoiu, L.; Kifer, M. and

Fensel, D.; 2005; Web Service Modelling Language (WSML) – version 0.2; Disponível on-line em

http://www.wsmo.org/TR/d16/d16.1/v0.2/

[Cabral et al, 2004] Cabral, L.; Domingue, J.; Motta, E.; Payne, T. and Hakimpour, F.; 2004, Approaches to

Semantic Web Services: An Overview and Comparisons; The Semantic Web: Research and

Applications, ISBN: 3-540-21999-4, pp. 225 – 239.

[Chappell, 1996] Chappell, D.; 1996; Understanding ActiveX and OLE; Redmond, Wash, Microsoft Press

[Chen, Finin & Joshi, 2004] Chen, H.; Finin, T. and Joshi, A.; 2004; Semantic Web in the Context Broker

Architecture; Proceedings of PerCom 2004; Disponível on-line em

http://ebiquity.umbc.edu/v2.1/get/a/publication/76.pdf.

129

[Christensen et al, 2001] Christensen, E.; Curbera, F.; Meredith, G. and Weerawarana, S.; 2001; Web

Services Description Language (WSDL) 1.1; Disponível on-line em

http://www.w3.org/TR/2001/NOTE-wsdl-20010315.

[Clocksin & Mellish, 1981] Clocksin, W.F.; Mellish, C.S.; 1981; Programming in Prolog; Springer-Verlag,

New York.

[Costa & Botelho, 2005] Costa, P. and Botelho, L.; 2005; Generic Context Acquisition and Management

Framework; Proceedings of the First European Young Researchers Workshop on Service Oriented

Computing; Disponível on-line em http://www.we-b-mind.org/publications/pcosta-gcamf-

yrsoc2005.pdf.

[Dale, 2002] Dale, J.; 2002; April Agent Platform Reference Manual; Fujitsu Laboratories of America;

Disponível on-line em http://sf.us.agentcities.net/aap/

[Dey & Abowd, 1999] Dey, A. K. and Abowd, G. D.; 1999; Towards a better understanding of context and

context awareness; GVU Technical Report GIT-GVU-99-22, College of Computing, Georgia

Institute of Technology.

[Dey, Abowd & Salber, 2001] Dey, A. K.; Abowd, G. D. and Salber, D.; 2001; A Conceptual Framework

and a Toolkit for Supporting the Rapid Prototyping of Context-Aware Applications; Human

Computer Interaction, Volume 16, pp. 97–66.

[Englander, 1997] Englander, R.; 1997; Developing Java Beans; O’Reilly & Associates.

[Fensel & Bussler, 2002] Fensel, D. and Bussler, C.; 2002; The Web Service Modeling Framework –

WSMF; Electronic Commerce: Research and Applications, 1 (2002), pp.113-137.

[FIPA, 2002] FIPA; 2002; Foundation for Intelligent Physical Agents website; Disponível on-line em

http://www.fipa.org/.

[FIPA-2, 2002] FIPA; 2002; Foundation for Intelligent Physical Agents Specification Repository;

Disponível on-line em http://www.fipa.org/repository/index.html.

[Finin, Labrou & Mayfield, 1997] Finin, T.; Labrou, Y. and Mayfield, J.; 1997; KQML as an agent

communication language; Software Agents, MIT Press, Cambridge.

[Genesereth, 1998] Genesereth, M. R.; 1998; Knowledge Interchange Format; draft proposed American

National Standard (dpANS); NCITS.T2/98-004; Disponível on-line em

http://logic.stanford.edu/kif.

[Gonçalves, Jesus & Botelho, 2003] Gonçalves, B.; Jesus, N. and Botelho, L.M.; 2003; Salt & Pepper

Architecture and Toolkit; Proceedings of the Joint International Conference of Cognitive Science.

[Goodwill, 2002] Goodwill, J.; 2002; Apache Jakarta Tomcat; Berkeley, CA: New York: Apress.

130

[Holmes, Donkin & Witten, 1994] Holmes, G.; Donkin, A. and Witten, I.H.; 1994; Weka: A machine

learning workbench; Proceedings of the Second Australia and New Zealand Conference on

Intelligent Information Systems.

[Hong, 2002] Hong, J.I.; 2002; The Context Fabric: An Infrastructure for Context – Aware Computing;

ACM 1-58113-454-1/02/0004.

[Horrocks et al, 2004] Horrocks, I.; Patel-Schneider, P.F.; Boley, H.; Tabet, S.; Grosof, B. and Dean, M.;

2004; SWRL: A Semantic Web Rule Language combining OWL and RuleML; W3C Member

Submission; Disponível on-line em http://www.w3.org/Submission/2004/SUBM-SWRL-

20040521/.

[Lara et al, 2004] Lara, R.; Roman, D.; Polleres, A. and Fensel, D.; 2004; A Conceptual Comparison of

WSMO and OWL-S; European Conference on Web Services; ISBN: 3-540-23202-8, pp.254 - 269.

[Lopes & Botelho, 2005] Lopes, A. and Botelho, L.M.; 2005; SEA: a Semantic Web Services Context-

aware Execution Agent; Proceedings of the AAAI Fall Symposium on Agents and the Semantic

Web; Arlington, VA, U.S.A.

[Martin et al, 2004] Martin, D. ; Burstein, M. ; Lassila, O. ; Paolucci, M. ; Payne, T. and McIlraith. S.;

2004; Describing Web Services using OWL-S and WSDL; DARPA Markup Language Program;

Disponível on-line em http://www.daml.org/services/owl-s/1.1/owl-s-wsdl.html.

[Martin et al, 2005] Martin, D.; Paolucci, M.; McIlraith, S.; Burstein, M.; McDermott, D.; McGuinness, D.;

Parsia, B.; Payne, T.; Sabou, M.; Solanki, M.; Srinivasan, N. and Sycara, K.; 2005; Bringing

Semantics to Web Services: The OWL-S Approach; Proceedings of the First International

Workshop on Semantic Web Services and Web Process Composition; ISBN: 3-540-24328-3,

p. 26.

[McBride, 2002] McBride, B.; 2002; Jena: A semantic Web toolkit; IEEE Internet Computing, 6(6), 55-59.

[McCabe, 2002] McCabe, F.; 2002; April Programming Language Reference Manual; Fujitsu Laboratories

of America; Disponível on-line em http://www.nar.fujitsulabs.com/april/.

[McCabe-2, 2002] McCabe, F.; 2002; InterAgent Communications Model Reference Manual; Fujitsu

Laboratories of America; Disponível em http://www.nar.fujitsulabs.com/icm/.

[McGuiness & Harmelen, 2003] McGuinness, D. and Harmelen, F.; 2003; OWL Web Ontology Language

Overview; W3C Recommendation; Disponível on-line em http://www.w3.org/TR/owl-features/.

[Microsoft, 1995] Microsoft Corporation and Digital Equipment Corporation; 1995; The Component Object

Model Specification; Redmond, WA.

[Minsky, 1985] Minsky, M.; 1985; The Society of Mind; Simon & Schuster, New York.

131

[Minton, Ticrea & Beach, 2003] Minton, S. N.; Ticrea, S. I. and Beach, J.; 2003; Trainability: Developing

a responsive learning system; Proceedings of the Workshop on Information Integration on the

Web; Disponível on line em http://www.isi.edu/info-agents/workshops/ijcai03/proceedings.htm.

[Mitkas et al, 2002] Mitkas, P.; Symeonidis, A.; Kechagias, D.; Athanasiadis, I.; Laleci, G.; Kurt, G.;

Kabak, Y.; Acar, A. and Dogac, A.; 2002; An Agent Framework for Dynamic Agent Retraining:

Agent Academy; Challenges and Achievements in e-business and e-work, B. Stanford-Smith, E.

Chiozza, and M. Edin (eds.), Prague, Czech Republic, IOS Press, pp.757-764

[Moran & Dourish, 2001] Moran, T. P. and Dourish, P.; 2001; Introduction to this Special Issue on Context

Aware Computing; Human Computer Interaction, Volume 16, pp. 87–95.

[Nwana, Ndumu & Lee, 1998] Nwana, H.S.; Ndumu, D.T. and Lee, L.C.; 1998; ZEUS: An advanced Tool-

Kit for Engineering Distributed Mulyi-Agent Systems; Proceedings of PAAM98, pp. 377-391.

[Orfali, Harkey & Edwards, 1997] Orfali, R.; Harkey, D. and Edwards, J.; 1997; Client/server

programming with Java and CORBA; New York: Wiley Computer Pub.

[OWL Services Coalition, 2003] OWL Services Coalition; 2003; OWL-S: Semantic Markup for Web

Services; DARPA Markup Language Program; Disponível on-line em

http://www.daml.org/services/owl-s/1.1/overview/

[Pais & Botelho, 2005] Pais, P. and Botelho, L.M.; 2005; Hybrid, Two-Step Service Discovery; Proceedings

of the First European Young Researchers Workshop on Service Oriented Computing; Disponível

on-line em http://www.we-b-mind.org/publications/ppais-htwsd-yrsoc2005.pdf

[Paolucci & Srinivasan, 2004] Paolucci, M. and Srinivasan, N.; 2004; OWL-S Virtual Machine Project

Page; Disponível on-line http://projects.semwebcentral.org/projects/owl-s-vm/.

[Paolucci et al, 2004] Paolucci, M.; Soudry, J.; Srinivasan, N. and Sycara, K.; 2004; A Broker for OWL-S

Web Services; Semantic Web Services: Papers from the 2004 AAAI Spring Symposium, pp.92–99

[Platt, 1999] Platt, D.S.; 1999; Understanding COM+. Microsoft Press.

[Platt, 2001] Platt, D.S.; 2001; Introducing Microsoft .NET. Microsoft Press

[Prud’hommeaux & Seaborne, 2004] Prud’hommeaux, E. and Seaborne, A.; 2004; SPARQL Query

Language for RDF; W3C Working Draft; Disponível on-line em

http://www.w3.org/TR/2004/WD-rdf-sparql-query-20041012/

[Ranganathan & Campbell, 2003] Ranganathan, A. and Campbell, R. H.; 2003; A Middleware for Context-

Aware Agents in Ubiquitous Computing Environments; ISSN: 0302-9743, pp. 143 – 161.

[Robertson & Robertson, 1997] Robertson, J . and Robertson, S.; 1997; Volere Requirements Specification

Template; Atlantic Systems Guild; Disponível on-line em http://www.volere.co.uk

132

[Roman, Keller & Lausen, 2004] Roman, D.; Keller, U. and Lausen, H.; 2004; Web Service Modeling

Ontology (WSMO) – version 1.2; Disponível on-line em http://www.wsmo.org/TR/d2/v1.2/.

[Salber, Dey & Abowd, 1999] Salber, D.; Dey, A. and Abowd, G. D.; 1999; The Context Toolkit: Aiding

the Development of Context-Enabled Applications; Proceedings of CHI'99, pp. 434-441.

[Sandia National Laboratory, 2003] Sandia National Laboratory; 2003; Jess in Action; Manning

Publications Co.; ISBN: 1930110898.

[Shoham, 1993] Shoham, Y; 1993; Agent oriented programming; Artificial Intelligence, 60:51-92

[Sinderen, Eijkel & Meer, 2002] Sinderen, M.; Eijkel, G. and Meer, J.; 2002; WASP Full Project Proposal;

Disponível on-line em http://wasp.freeband.nl/

[Sirin, 2004] Sirin, E.; 2004; OWL-S API project website; Disponível on-line em

http://www.mindswap.org/2004/owl-s/api/.

[Thompson et al, 2004] Thompson, H.; Beech, D.; Maloney, M. and Mendelsohn, N.; 2004; XML Schema

Part I: Structures; World Wide Web Consortium (W3C) working draft; Disponível on-line em

http://www.w3.org/TR/xmlschema-1.

[Warmer & Kleppe, 1998] Warmer, J. and Kleppe, A.; 1998; The Object Contraint Language: precise

modelling with UML; Addison-Wesley Object Technology Series, Addison-Wesley Longman,

ISBN: 0201379406.

[Westwood, 1997] Westwood, D.; 1997; LPA-Prolog Technical Reference; Logic Programming Associates

Ltd, London, England.

[Williams & Kindel, 1994] Williams, S. and Kindel, C.; 1994; The Component Object Model: A Technical

Overview; Dr. Dobb’s Journal.

[Yau et al, 2002] Yau, S. S.; Karim, F.; Wang, Y.; Wang, B. and Gupta, S.K.S.; 2002; Reconfigurable

Context-Sensitive Middleware for Pervasive Computing, IEEE Pervasive Computing.

133

Anexos

A. CLASSIFICAÇÃO DE T IPO DE REQUISITOS (VOLERE)

1. Functional and Data Requirements

1.a. Functional Requirements

1.b. Data Requirements

1.c. Interface Requirements

2. Look and Feel Requirements

2.a. The Interface

2.b. The Style of the Product

3. Usability Requirements

3.a. Ease of Use

3.b. Personalization and Internationalization Requirements

3.c. Ease of Learning

3.d. Accessibility Requirements

4. Performance Requirements

4.a. Speed and Latency Requirements

4.b. Safety Critical Requirements

4.c. Precision Requirements

4.d. Reliability and Availability Requirements

4.e. Robustness Requirements

4.f. Capacity Requirements

4.g. Scalability or Extensibility Requirements

5. Operational Requirements

5.a. Expected Physical Environment

5.b. Expected Technological Environment

5.c. Partner Applications

5.d. Productization Requirements

6. Maintainability and Support Requirements

134

6.a. Ease of Maintenance

6.b. Special Conditions of Maintenance

6.c. Supportability

6.d. Portability Requirements

7. Security Requirements

7.a. Access Requirements

7.b. Integrity Requirements

7.c. Privacy Requirements

7.d. Audit Requirements

7.e. Immunity Requirements

8. Cultural and Political Requirements

9. Legal Requirements

9.a. Law Enforcement Requirements

9.b. Compliance to Standards Requirements

135

B. L ISTAGEM DE REQUISITOS DO SISTEMA

Este anexo descreve a análise de requisitos realizada na modelação do sistema,

usando a norma de especificação Volere. A norma de especificação Volere permite

definir e descrever requisitos usando uma tabela em Inglês. Para uso desta norma na tese,

foi usada uma versão em Português da tabela referida. Segue-se uma breve explicação de

cada um dos parâmetros a preencher na tabela:

• Requisito # - Identificador do Requisito (tem de ser unívoco)

• Tipo – Identificação do tipo de Requisito (usa uma tabela de classificação

apresentada no anexo A. Classificação de Tipo de Requisitos (Volere))

• Casos de Utilização # - Identificadores dos Casos de Utilização que deram

origem a este Requisito

• Designação – Uma frase que descreve a intenção deste requisito

• Descrição – Uma descrição mais detalhada ou justificação do requisito

• Fonte – Identificação da pessoa ou entidade que levantou este requisito

• Teste de cumprimento – Descrição do teste a realizar após a implementação

para verificar se o requisito foi cumprido

• Satisfação do Cliente – Medida do Grau de Satisfação do Cliente pelo facto de

este requisito ser implementado (1=Desinteressado; 5=Extremamente satisfeito)

• Insatisfação do Cliente – Grau de Insatisfação do Cliente pelo facto de este

requisito não ser incluído no produto final (1=Desinteressado; 5=Extremamente

insatisfeito)

• Dependências – Identificação dos Requisitos dos quais este depende (se

existirem dependências)

• Conflitos – Identificação dos Requisitos com os quais este entra em conflito (se

existirem conflitos)

136

• Material de Suporte – Identificação do material que foi usado para levantar este

requisito (casos de utilização, diagramas)

• História – Indicação das descrições e datas de criação e alterações

O primeiro requisito, R1, descrito na Tabela 6, retirado do cenário de demonstração

(descrito no Capítulo 3) e dos casos de utilização descritos ao longo deste capítulo,

reflecte a necessidade do Agente que será desenvolvido de ter a capacidade de executar

qualquer tipo de serviço OWL-S. Isto é, que seja capaz de executar qualquer estrutura de

controlo que seja possível de ser representada usando a ontologia de serviços OWL-S. No

teste de cumprimento enunciado neste requisito (R1) e noutros requisitos ao longo desta

secção, é dito que é preciso verificar se o serviço é bem executado. Realizar esta

verificação implica comparar os Efeitos do serviço (especificados na descrição OWL-S

do serviço) com o resultado do serviço (o que o agente de execução de serviços fez).

Requisito #: R1 Tipo: 1.a Caso(s) Utilização #: UC1.3;

Designação: Execução completa de serviços OWL-S

Descrição: A execução de serviços deverá contemplar qualquer serviço descrito em OWL-

S.

Fonte: António Lopes

Teste de

Cumprimento:

Verificar se a execução de serviços contempla todos os mecanismos de

controlo de execução do OWL-S e verificar se o serviço é bem executado.

Satisfação do Cliente: 5 Insatisfação do Cliente: 5

Dependências: Conflitos :

Material de Suporte: Cenário de Demonstração, Diagramas de Casos de Utilização

História: Criado a 2004-12-28 por António Lopes

Tabela 6 - Requisito Execução de Serviços OWL-S

De notar que poderão ocorrer situações alheias ao agente de execução de serviços

(como um agente prestador de serviços recusar a execução de um serviço atómico) que

poderão comprometer a execução de um serviço específico, não se podendo realizar a

avaliação desejada.

137

Na Tabela 7 encontra-se descrito outro requisito que descreve a necessidade de

abrangência por parte do Agente de Execução de Serviços. Este requisito descreve a

necessidade de o agente conseguir lidar com a execução de serviços cujos fornecedores

sejam de qualquer tipo, isto é, sejam serviços na Web ou Agentes Prestadores de

Serviços. No que toca à verificação do sucesso da execução do tipo de serviços

enunciados no teste de cumprimento deste requisito, há que estabelecer uma nota prévia:

em certos casos, especialmente quando o prestador do serviço é um agente, a mensagem

com o pedido da execução pode estar correcta, mas o prestador pode recusar a sua

execução.

Requisito #: R2 Tipo: 1.a Caso(s) Utilização #: UC1.3;UC2.1;UC2.2

Designação: Execução de serviços com qualquer tipo de prestadores de serviços

Descrição:

A execução de serviços levada a cabo pelo agente deverá contemplar qualquer

tipo de prestadores de serviços. Isto é, serviços na Web e Agentes Prestadores

de Serviços que comunicam usando as linguagens FIPA ACL e FIPA SL.


Teste de

Cumprimento:

Requisitar ao agente a execução de um serviço cuja descrição especifique

prestadores de serviços de vários tipos e verificar se o prestador do serviço

recebe a mensagem necessária para que o serviço possa ser bem executado.


Dependências: R1, R11 Conflitos :



Tabela 7 - Requisito Execução de serviços com qualq uer tipo de Fornecedores de

Serviços

O requisito R2 depende de R1 no sentido em que a execução de serviços com

qualquer tipo de prestadores de serviços, implica que não haja limitações ao nível da

execução de serviços OWL-S. Depende ainda de R11, por causa da necessidade de ser

compatível com as especificações da FIPA.

O requisito R3, descrito na Tabela 8, surge da necessidade do AES em encontrar

alternativas ao serviço original enviado pelo seu cliente, quando o contexto assim o exija.

138

Isto inclui interagir com a Procura de Serviços e a Composição de Serviços, mais

concretamente com os agentes que instanciam estas funcionalidades para obter a

informação necessária.

Requisito #: R3 Tipo: 1.a Caso(s)

Utilização #: UC1.1;UC1.2;UC1.3;UC2.3;UC2.4;

Designação: Execução de Serviços recorrendo a Procura de Serviços e Composição de

Serviços

Descrição:

O agente deverá ter a capacidade de comunicar com os agentes de descoberta

e composição de serviços de forma a encontrar alternativas ao serviço enviado

pelo cliente, quando a situação contextual assim o exigir


Teste de

Cumprimento:

Requisitar a execução de um serviço para o qual se saiba que não existem

prestadores de serviços e verificar se o executor de serviços contacta a Procura

de Serviços e posteriormente a Composição de Serviços para executar com

sucesso o serviço pedido.

Satisfação do

Cliente: 4

Insatisfação do

Cliente: 4

Dependências: R1, R11 Conflitos :

Material de

Suporte:

Cenário de Demonstração, Diagramas de Casos de Utilização, Diagramas

de Sequência


Tabela 8 - Requisito Execução de serviços recorrend o a Procura e Composição de

Serviços

139

Em consequência da existência de R3, é necessário especificar R4, descrito na Tabela

9, que descreve a necessidade do AES requerer a aprovação do cliente no que toca à

obtenção de alternativas ao serviço originalmente enviado por este. Este requisito, poderá

entrar em conflito com R8 (que descreve a necessidade do AES ter uma interface simples

com o seu cliente) porque esta interacção pode comprometer a definição de um interface

simples e sem interacções complexas.

Requisito #: R4 Tipo: 1.a Caso(s) Utilização #: UC1.3;

Designação: Execução de serviços com aprovação do Cliente

Descrição: O agente deverá comunicar com o Cliente quando é necessário requerer a

aprovação deste para a procura de alternativas para prestadores de serviços


Teste de

Cumprimento:

Requisitar a execução de um serviço cuja descrição especifique prestadores de

serviços que estão indisponíveis e verificar se o serviço é bem executado,

através da comunicação com o Cliente (para aprovação de novos prestadores

de serviços)


Dependências: R1, R3 Conflitos : R8

Material de Suporte: Cenário de Demonstração, Diagramas de Casos de Utilização,

Diagramas de Sequência


Tabela 9 - Requisito Execução de serviços com aprov ação do Cliente

140

O requisito R5, descrito na Tabela 10, reflecte a necessidade do AES consultar

informação de contexto para melhorar o seu processo de execução.

Requisito #: R5 Tipo: 1.a Caso(s) Utilização #: UC3.1-3.5

Designação: Execução de serviços com Informação de Contexto

Descrição: O agente deverá executar serviços tendo sempre em conta a informação de

contexto disponível que possa influenciar a mesma.

Fonte: António Lopes, projecto CASCOM

Teste de

Cumprimento:

Verificar se, em ambientes dinâmicos de mudança constante de contexto, o

agente usa essa informação (disponibilizada pelos sistemas de aquisição de

contexto acessíveis) para adaptar a sua actividade de execução de serviços


Dependências: R1 Conflitos :



Tabela 10 - Requisito Execução de serviços com Info rmação de Contexto

141

No seguimento de R5, descreve-se o requisito R6, na Tabela 11, que descreve a

possibilidade do AES consultar o cliente para lhe pedir informação de contexto que

poderá melhorar o processo de execução.

Requisito #: R6 Tipo: 1.a Caso(s) Utilização #: UC3.1

Designação: Possibilidade de obtenção de contexto do cliente

Descrição: O agente poderá pedir informação sobre o contexto do cliente ao próprio


Teste de

Cumprimento:

Requisitar a execução de um serviço e verificar se o agente pergunta ao cliente

informação de contexto (para usar na execução de serviços com o intuito de a

melhorar).


Dependências: R5 Conflitos : R8



Tabela 11 - Requisito Possibilidade de obtenção de contexto do cliente

142

Ainda no seguimento de R5, a execução de serviços com Informação de Contexto,

implica que o AES seja capaz de a obter e processar, tal como mostra o requisito R7,

descrito na Tabela 12. Isto implica a comunicação com o sistema de contexto e com

outras entidades no ambiente, tudo com o intuito de melhorar o processo de execução do

serviço.

Requisito #: R7 Tipo: 1.a Caso(s) Utilização #: UC3.2-3.5

Designação: Processamento de Informação de Contexto

Descrição: O agente deverá comunicar com o subsistema de contexto de forma a obter

informação de contexto relacionada com o ambiente em que opera

Fonte: António Lopes, projecto CASCOM

Teste de

Cumprimento:

Requisitar a execução de um serviço e verificar se o agente comunica com o

subsistema de contexto para obter informação de contexto (para usar na

execução de serviços com o intuito de a melhorar)





Tabela 12 - Requisito Processamento de Informação d e Contexto

143

O requisito descrito na Tabela 13, R8, descreve a necessidade de simplicidade na

interface do AES com o seu cliente. Uma possível verificação do cumprimento deste

requisito poderá ser a compatibilidade da comunicação entre os agentes com as

especificações da FIPA. Este requisito foi baseado, não só no cenário de demonstração e

nos casos de utilização, mas também na necessidade de avaliar a interoperabilidade do

trabalho realizado com sistemas e especificações já existentes. Este critério faz parte de

um conjunto vasto de critérios de avaliação descritos no Capítulo 7.

Requisito #: R8 Tipo: 1.c Caso(s) Utilização #: UC1.3

Designação: Interface simples com o Agente cliente

Descrição:

O interface do agente de execução de serviços com o agente cliente deverá ser o

mais simples possível para evitar que os clientes tenham de ter qualquer tipo de

capacidade especial para comunicar com este.


Teste de

Cumprimento:

Verificar se a comunicação entre o cliente e o agente exige que o primeiro tenha

de ter capacidades especiais de raciocínio ou de comunicação para comunicar

com o segundo.


Dependências: R11 Conflitos : R4, R6

Material de Suporte: Cenário de Demonstração, Metodologia de Avaliação, Diagramas de

Casos de Utilização


Tabela 13 - Requisito Interface simples com o Agent e Cliente

144

O requisito R9, descrito na Tabela 14, reflecte a necessidade do AES prestar um

serviço rápido aos seus clientes. No entanto, a introdução deste requisito poderá causar

conflitos com outros requisitos que influenciam o tempo de execução de um serviço,

como é o caso do R5 (ver Tabela 10) e R7 (ver Tabela 12), requisitos que apontam para a

necessidade de se processar informação de contexto durante a execução de um serviço. A

verificação do cumprimento deste requisito poderá ser feita através de restrições

temporais impostas pelo Agente Cliente.

Requisito #: R9 Tipo: 4.a Caso(s) Utilização #: UC1.3

Designação: Rapidez da execução de serviços

Descrição: A execução de serviços levada a cabo pelo agente deverá ser rápida ao ponto

de ser útil para o agente cliente.


Teste de

Cumprimento:

Após a execução de um serviço requerido por um agente cliente, verificar se a

rapidez da execução foi satisfatória para o cliente.


Dependências: R1 Conflitos : R5, R7, R10




Tabela 14 - Requisito Rapidez da execução de serviç os

145

O requisito R10, descrito na Tabela 15, é baseado na necessidade da maior parte dos

sistemas computacionais distribuídos serem robustos, escaláveis e sempre disponíveis,

pois isto reflecte-se na utilização dos mesmos por parte dos clientes. No entanto, a

imposição deste requisito pode comprometer o requisito da rapidez.

Requisito #: R10 Tipo: 4.d, 4.e, 4.g Caso(s) Utilização #: UC1.3

Designação: Robustez, Disponibilidade e Escalabilidade da Execução de Serviços

Descrição:

A execução de serviços levada a cabo pelo agente deverá estar sempre

disponível, deverá ser robusta e ser capaz de receber diversos pedidos de

diferentes clientes.


Teste de

Cumprimento:

Requisitar a execução de vários serviços ao mesmo tempo e verificar se a

capacidade de resposta do agente não compromete a rapidez e a própria

execução dos serviços.



Material de Suporte: Metodologia de Avaliação, Diagramas de Casos de Utilização


Tabela 15 - Requisito Robustez, Disponibilidade e E scalabilidade da Execução de Serviços

146

O requisito R11, descrito na Tabela 16, surge no seguimento dos requisitos R2, R3 e

R8, os quais reflectem a necessidade do AES comunicar com outros agentes no ambiente.

Como tal, para garantir a interoperabilidade do AES com esses agentes, este tem de ser

compatível com as especificações da FIPA.

Requisito #: R11 Tipo: 9.b Caso(s) Utilização

#: UC1.3

Designação: Compatibilidade com as especificações da FIPA

Descrição: O agente deverá comunicar e actuar segundo as especificações da FIPA


Teste de

Cumprimento:

Verificar se as comunicações do agente e as suas interacções com os

restantes elementos do sistema são compatíveis com as especificações da

FIPA


Dependências: Conflitos :




Tabela 16 - Requisito Compatibilidade com as especificações da FIPA

147

C. PROTOCOLOS UTILIZADOS

Este anexo descreve os protocolos utilizados pelo agente implementado.

Protocolo de Interacção FIPA-Request

Este protocolo, tal como ilustra a Figura 33, especifica que o agente Initiator inicia a

conversação enviando uma mensagem Request para o agente Participant.

Figura 33 - Protocolo de interacção FIPA-Request 38

Este, ao receber a mensagem e após realizar uma análise prévia da mensagem, pode

responder (embora este passo seja facultativo) numa de 3 formas: através de uma

38 Imagem retirada do documento de especificação FIPA: “FIPA Request Interaction Protocol

Specification”. Disponível on-line em http://www.fipa.org/specs/fipa00026/

148

mensagem Not-Understood, indicando que não conseguiu processar a mensagem por

existirem alguns termos que ele não entende ou não conhece; através de uma mensagem

Refuse, indicando que se recusa a executar a acção pedida; ou através de uma mensagem

Agree, indicando que aceita executar a acção pedida. O passo seguinte no protocolo

ocorrerá apenas se o agente Participant assumiu um estado de concordância sobre o

pedido realizado pelo agente Initiator. Isto é, se o agente Participant concordou realizar a

acção, então segue o protocolo realizando a execução da acção requerida.

Após a execução da acção, o agente pode agora responder de 3 formas: através de

uma mensagem Failure, indicando que a execução da acção não foi realizada com

sucesso; através de uma mensagem Inform-done, indicando que a execução da acção

decorreu com sucesso e que não devolveu nenhum resultado; ou através da mensagem

Inform-ref, que permite, para além de indicar que a acção foi executada com sucesso,

comunicar o resultado da acção.

149

Protocolo de Interacção FIPA-Query

O Protocolo FIPA-Query permite efectuar perguntas abertas e perguntas fechadas

entre agentes.

Figura 34 - Protocolo de interacção FIPA-Query 39

A Figura 34 ilustra os passos que tem de ser dados pelos Agentes que comuniquem

usando este protocolo. O protocolo é iniciado pelo Agente Initiator que envia uma de

duas possíveis mensagens para realizar uma pergunta ao Agente Participant: a mensagem

Query-If é usada para perguntar se determinada proposição é verdadeira, pelo que a

resposta esperada deverá ser um valor Boolean (verdadeiro ou falso); a mensagem Query-

Ref é usada para realizar uma pergunta aberta, isto é, para obter determinada informação

que respeita um conjunto de condições ou restrições. Ao receber a mensagem e após

realizar o processamento adequado de acordo com a pergunta realizada, o Agente

Participant pode responder com uma de quatro possíveis mensagens: Not-Understood,

39 Imagem retirada do documento de especificação FIPA: “FIPA Query Interaction Protocol

Specification”. Disponível on-line em http://www.fipa.org/specs/fipa00027/

150

indicando que não percebeu a pergunta enviada; Refuse, indicando que não aceita

responder à pergunta; Failure, indicando que não conseguiu responder à pergunta porque

durante o processo ocorreu um erro; e Inform, para responder à pergunta feita.

151

D. ARTIGOS PUBLICADOS

Este anexo apresenta os artigos publicados ao longo do tempo em que decorreu o

trabalho de investigação:

• Lopes, A. and Botelho, L.M.; 2005; Agent Technology for Context-aware

Execution of Semantic Web Services; Poster (incluindo uma página de resumo)

apresentado no Young Researchers Workshop on Service Oriented Computing,

em Leicester, no Reino Unido.

• Lopes, A. and Botelho, L.M.; 2005; SEA: a Semantic Web Services Context-

aware Execution Agent; Artigo apresentado no AAAI Fall Symposium on Agents

and the Semantic Web, Arlington, Virgínia, nos Estados Unidos da América.

antónio luís morais costa da silva lopes dissertação submetida...

Documents