INSTITUTO MILITAR DE ENGENHARIA
MAURO MONTEIRO SILVA
PLATAFORMA ORIENTADA A SERVIÇOS PARA O DESENVOLVIMENTO
DE AGENTES PRÓ-ATIVOS
Dissertação de Mestrado apresentada ao Curso de
Mestrado em Sistemas e Computação do Instituto Militar
de Engenharia, como requisito parcial para a obtenção do
título de Mestre em Sistemas e Computação.
Orientador: Prof. Ricardo Choren Noya – D.Sc
Rio de Janeiro
2006
c2006
INSTITUTO MILITAR DE ENGENHARIA
Praça General Tibúrcio, 80 – Praia Vermelha.
Rio de Janeiro – RJ
CEP: 22290 – 270
Este exemplar é propriedade do Instituto Militar de Engenharia, que poderá incluí-lo em base
de dados, armazenar em computador, microfilmar ou adotar qualquer forma de
arquivamento.
É permitida a menção, reprodução parcial ou integral e a transmissão entre bibliotecas
deste trabalho, sem modificação de seu texto, em qualquer meio que esteja ou venha a ser
fixado, para pesquisa acadêmica, comentários e citações, desde que sem finalidade
comercial e que seja feita a referência bibliográfica completa.
Os conceitos expressos neste trabalho são de responsabilidade do(s) autor(es) e do(s)
orientador(es).
S568 Silva, Mauro Monteiro
Plataforma Orientada a Serviços para o Desenvolvimento de
Agentes Pró-Ativos / Mauro Monteiro Silva. – Rio de Janeiro:
Instituto Militar de Engenharia, 2006. 107 p.: il.
Dissertação (mestrado) – Instituto Militar de Engenharia –
Rio de Janeiro, 2006.
1. Sistemas Multi-Agentes. 2. Plataforma de Implementação
de Agentes. 3. Serviços Web. I. Silva, Mauro Monteiro. II.
Instituto Militar de Engenharia. III Título.
COD. 025.04
2
INSTITUTO MILITAR DE ENGENHARIA
MAURO MONTEIRO SILVA
PLATAFORMA ORIENTADA A SERVIÇOS PARA O
DESENVOLVIMENTO DE AGENTES PRÓ-ATIVOS
Dissertação de Mestrado apresentada ao Curso de Mestrado em Sistemas e
Computação do Instituto Militar de Engenharia, como requisito parcial para obtenção
do título de Mestre em Sistemas e Computação.
Orientador: Prof. Ricardo Choren Noya – D.Sc
Aprovada em 20 de fevereiro de 2006 pela seguinte banca examinadora:
_____________________________________________________________
Prof. Ricardo Choren Noya – D.Sc do IME – Presidente
_____________________________________________________________
Profa. Cláudia Maria Garcia de Oliveira – PhD do IME/RJ
_____________________________________________________________
Prof. Marcelo Blois Ribeiro – D.Sc da PUCRS
_____________________________________________________________
Profa. Viviane Torres da Silva – D.Sc da PUC-Rio
Rio de janeiro
2006
3
A minha esposa Eliana, razão da minha força,
vontade, alegria, dedicação, coragem, e da
felicidade em minha vida.
4
AGRADECIMENTOS
Em primeiro lugar, eu gostaria de estar agradecendo ao meu orientador Ricardo
Choren... Calma, não precisa “bater” mais uma vez na mesa e riscar novamente o
texto. Graças a sua orientação pude aprender muitas coisas, desde falar e escrever
melhor até adquirir conhecimentos que me permitissem finalizar esta dissertação.
Agradeço sua paciência e disponibilidade em todos os momentos da realização
deste trabalho, sempre de portas abertas para me ouvir e contribuir com perguntas
que tornavam o trabalho cada vez melhor. Lembro-me das inúmeras apresentações
preparatórias para o WTES que fiz e ao término, sempre com muita propriedade e
paciência, levantava questões que me faziam refletir sobre a dissertação. Meu muito
obrigado e minha admiração.
A minha esposa e família, peço desculpas pela eterna falta de tempo nesses
dois anos de Mestrado, agradeço o apoio e incentivo que tive durante todo o curso.
A Extend Software, agradeço o apoio em permitir que eu trabalhasse meio
expediente para que concretizar o meu sonho.
Aos colegas da turma de Mestrado do IME/2004, pelo convívio agradável que
tive com todos eles. Em especial ao Leonardo Lima Santos, Léo, pelo
companheirismo ao longo desse último ano.
A todos os funcionários e professores do departamento de Sistemas e
Computação do IME (SE/8), pela confiança e apoio que sempre demonstraram em
mim.
Aos professores Cláudia Maria Garcia de Oliveira, Marcelo Blois Ribeiro e
Viviane Torres da Silva pela gentileza em aceitar o convite de participar da defesa
desta dissertação, contribuindo para melhoria do presente trabalho.
Por último, porém, não em último, agradeço a Deus que ao longo de toda a
minha vida tem me presenteado com graças maiores que o meu merecimento.
Mauro Monteiro Silva
5
“Os professores ideais são os que se fazem de
pontes, que convidam os alunos a atravessarem,
e
depois,
tendo
facilitado
a
travessia,
desmoronam-se com prazer, encorajando-os a
criarem as suas próprias pontes.”
NIKOS KAZANTZAKIS
6
SUMÁRIO
LISTAS DE ILUSTRAÇÕES..........................................................................................................10
LISTA DE SIGLAS...........................................................................................................................13
1.
INTRODUÇÃO....................................................................................................................16
1.1.
Problema..............................................................................................................................18
1.2.
Objetivo ................................................................................................................................19
1.3.
Contribuições Esperadas ...................................................................................................20
1.4.
Organização ........................................................................................................................20
2.
FUNDAMENTAÇÃO TEÓRICA.......................................................................................21
2.1.
Arquitetura Orientada a Serviços (SOA)...........................................................................21
2.2.
Web Services (WS) ............................................................................................................24
2.2.1. XML ......................................................................................................................................25
2.2.2. Communications (Camada de Transporte)......................................................................25
2.2.3. Messages (Camada de Mensagem)................................................................................25
2.2.4. Descriptions (Descrição do Serviço) .................................................................................25
2.2.5. Processes (Processos).......................................................................................................26
2.2.6. Discovery (Descoberta de Serviço)...................................................................................26
2.2.7. Choreography......................................................................................................................28
2.3.
Business Process Execution Language (BPEL) .............................................................28
2.3.1. Atividade Receive................................................................................................................30
2.3.2. Atividade Reply....................................................................................................................31
2.3.3. Atividade Invoke ..................................................................................................................31
2.3.4. Atividade Sequence............................................................................................................32
2.3.5. Atividade Flow .....................................................................................................................32
2.3.6. Atividade Wait......................................................................................................................32
3.
TRABALHOS RELACIONADOS....................................................................................33
3.1.
FIPA-OS...............................................................................................................................33
7
3.1.1. Agent Platform (Plataforma de Agentes)..........................................................................34
3.1.2. Message Transport System (MTS)...................................................................................35
3.1.3. Agent Management System (AMS)..................................................................................35
3.1.4. Directory Facilitator (DF).....................................................................................................36
3.1.5. Agent (Agente) ....................................................................................................................36
3.1.6. Software ...............................................................................................................................38
3.2.
Java Agent Development Framework (JADE).................................................................38
3.3.
Web Services Integration Gateway (WSIG).....................................................................40
3.4.
Framework Orientado a Objetos para Implementação de Sociedades de Agentes...42
3.5.
JADEX..................................................................................................................................43
3.6.
SemantiCore........................................................................................................................44
3.7.
Considerações Sobre os Trabalhos Relacionados.........................................................46
4.
PLATAFORMA ORIENTADA A SERVIÇOS PARA O DESENVOLVIMENTO DE
AGENTES PRÓ-ATIVOS..................................................................................................49
4.1.
Características Gerais da Plataforma ...............................................................................49
4.1.1. Uso de Objetivos como Conceito de Primeira Ordem....................................................49
4.1.2. Uso da Abstração de Orientação a Serviços...................................................................50
4.1.3. Implementação da Pró-atividade.......................................................................................51
4.2.
Organização Interna do Agente.........................................................................................53
4.2.1. O Ciclo de Vida do Agente Orientado a Objetivos ..........................................................57
4.3.
Plataforma de Agentes Pró-ativos.....................................................................................59
4.4.
Instância da Plataforma Proposta .....................................................................................62
5.
ESTUDO DE CASO...........................................................................................................66
5.1.
Loan Approval .....................................................................................................................66
5.1.1. Agente “Loan Requester”...................................................................................................67
5.1.2. Agente “Loan Approver”.....................................................................................................75
5.2.
Sistema Book Trading ........................................................................................................79
5.2.1. Agente “Book Buyer” ..........................................................................................................80
5.2.2. Agente “Book Seller”...........................................................................................................85
6.
CONCLUSÕES E TRABALHOS FUTUROS ................................................................87
8
6.1.
Conclusões ..........................................................................................................................87
6.2.
Trabalhos Futuros...............................................................................................................90
7.
REFERÊNCIAS BIBLIOGRÁFICAS...............................................................................91
8.
APÊNDICES .......................................................................................................................95
8.1.
APÊNDICE 1: Diagrama de Caso de Uso – Interface de Cadastro de Contratos .....96
8.2.
APÊNDICE 2: Diagrama de Classes – Interface de Cadastro de Contratos ...............97
8.3.
APÊNCIDE 3: Protocolo de Interação Implementado pelo Agente AD........................98
8.4.
APÊNCIDE 4: Planos de Execução do Sistema Loan Approval.................................100
8.5.
APÊNCIDE 5: Planos de Execução do Sistema Book Trading...................................103
9
LISTAS DE ILUSTRAÇÕES
FIG. 2.1 Paradigma “find, bind and execute” (em inglês)............................................................22
FIG. 2.2 Pilha de WS (em inglês)...................................................................................................24
FIG. 2.3 Estruturas do registro UDDI (em inglês).........................................................................27
FIG. 3.1 Arquitetura de referência definida pela FIPA (em inglês) .............................................34
FIG. 3.2 Ciclo de vida do agente (em inglês)................................................................................37
FIG. 3.3 Plataforma distribuída de agentes JADE (em inglês) ...................................................39
FIG. 3.4 Organização interna do agente genérico JADE (em inglês)........................................40
FIG. 3.5 Módulo Agente ASF (em inglês). ....................................................................................43
FIG. 3.6 Arquitetura Abstrata do Jadex (em inglês) .....................................................................44
FIG. 4.1 Organização Interna proposta para o agente................................................................55
FIG. 4.2 Ciclo de vida do Agente Orientado a Objetivos.............................................................59
FIG. 4.3 Plataforma de Agentes Pró-Ativos..................................................................................60
FIG. 4.4 Modelo de classe da organização Interna do agente orientado a objetivos...............65
FIG. 5.1 Processo da aplicação Loan Approval (em inglês).......................................................66
FIG. 5.2 Modelo de agentes e tabela de objetivos para o sistema Loan Approval ..................67
FIG. 5.3 Associação Objetivo/Plano para o agente “Loan Requester”......................................68
FIG. 5.4 Diagrama de Planejamento para o objetivo requestLoan ............................................70
FIG. 5.6 Representação dos relacionamentos do agente LoanRequester...............................71
FIG. 5.7 Definição dos recursos do plano LoanRequesterPlan..................................................72
FIG. 5.8 Solicitação de colaboração do agente LoanRequester................................................72
FIG. 5.9 Espera o status da solicitação de empréstimo ..............................................................73
FIG. 5.10 Tela de cadastro do contrato loanApprover.................................................................74
10
FIG. 5.11 Código do agente “Loan Requester” ............................................................................75
FIG. 5.12 Associação Objetivo/Plano para o agente “Loan Approver”......................................75
FIG. 5.13 Diagrama de Planejamento para o objetivo validateLoan..........................................76
FIG. 5.14 Chamada de uma ação externa ...................................................................................77
FIG. 5.15 Referências simbólicas aos contratos do agente Loan Approver .............................78
FIG. 5.16 Código do agente “Loan Approver” ..............................................................................79
FIG. 5.17 Modelo de agentes e tabela de objetivos para o sistema Book Trading..................80
FIG. 5.18 Associação Objetivo/Plano para o exemplo “BookTrading”.......................................81
FIG. 5.19 Diagrama de Planejamento para o objetivo buyBook ................................................82
FIG. 5.20 Conjunto de ações do plano do agente BookBuyer ...................................................83
FIG. 5.21 Tela de cadastro do contrato utilizado pelo agente “BookBuyer”..............................84
FIG. 5.22 Código do agente “BookBuyer”.....................................................................................84
FIG. 5.23 Diagrama de Planejamento para o objetivo sellBook.................................................85
FIG. 5.24 Plano de execução do agente “BookSeller” ................................................................86
FIG. 8.1 Diagrama de Caso de Uso ..............................................................................................96
FIG. 8.2 Diagrama de classes........................................................................................................97
FIG. 8.3 Protocolo de Interação .....................................................................................................98
FIG. 8.4 Plano de execução do agente “Loan Requester”........................................................100
FIG.8.5 Plano de Execução agente “Loan Approver”................................................................101
FIG. 8.6 Plano de Execução agente “Loan Approver” (Conitnuação) .....................................102
FIG. 8.7 Plano de execução do agente “BookBuyer” ................................................................103
FIG. 8.8 Plano de execução do agente “BookBuyer”(Continuação)........................................104
FIG. 8.9 Plano de execução do agente “BookBuyer”(Continuação)........................................105
FIG. 8.10 Plano de execução do agente “BookSeller” ..............................................................106
11
FIG. 8.11 Plano de execução do agente “BookSeller” (Continuação).....................................107
12
LISTA DE SIGLAS
ACL
Agent Communication Language
AD
Action Discoverer
AMS
Agent Management System
ASF
Agents Society Framework
BDI
Belief-Desire-Intention
BPEL
Business Process Execution Language
BPML
Business Process Management Language
DF
Directory Facilitator
IEEE
Institute of Electrical and Electronics Engineers
FIPA
Foundation for Intelligent Physical Agents
FIPA-OS
Foundation for Intelligent Physical Agents – Open Source
FTP
File Transfer Protocol
HTN
Hierarchical Task Network
HTTP
Hypertext Transfer Protocol
JADE
Java Agent Development Framework
JADEX
JADE Extension
SMA
Sistemas Multi-Agentes
SMTP
Simple Mail Transfer Protocol
SOA
Service - Oriented Architecture
SOAP
Simple Object Access Protocol
UDDI
Universal Discovery, Description and Integration
WS
Web Services
WSCI
Web Services Choreography Interface
WSDL
Web Services Description Language
W3C
World Wide Web Consortium
XML
Extensible Markup Language
13
RESUMO
O desenvolvimento de Sistemas Multi-Agentes é uma abordagem nova que utiliza a
abstração de agentes para modelagem de sistemas distribuídos e complexos. Os agentes
são definidos como entidades que são capazes de ações autônomas em busca dos seus
objetivos de projeto. Contudo, muitas das plataformas existentes não utilizam o conceito de
objetivo como elemento de primeira ordem (elemento chave) na implementação de Sistemas
Multi-Agentes, não permitem configurar o grau de pró-atividade dos agentes e criam um forte
acoplamento entre os agentes e suas ações.
A falta de uma representação para esses conceitos acaba por transferir a
responsabilidade da implementação deles para o desenvolvedor, contribuindo para que estes
conceitos fiquem misturados e espalhados juntos com a criação das ações executadas pelos
agentes. Desta forma, fica difícil identificá-los na implementação dos agentes. Além disso,
existe o forte acoplamento entre o agente e suas ações, o que dificulta o reuso e a
manutenção das ações, dificultando a evolução dos agentes.
Para resolver estes problemas, este trabalho propõe uma plataforma para o
desenvolvimento de agentes baseada nos objetivos dos agentes, que foram identificados nas
fases de análise. A plataforma oferece uma associação direta destes objetivos aos agentes e
um mecanismo que permite ao desenvolvedor, configurar o grau de pró-atividade que o
agente deve apresentar.
Esta plataforma introduz alguns conceitos definidos na Arquitetura Orientada a Serviços
(SOA) no desenvolvimento de Sistemas Multi-Agentes. Por meio dessa integração, busca-se
uma redução no acoplamento existente entre o agente e suas ações, procurando facilitar o
desenvolvimento das ações e promover o seu reuso.
14
ABSTRACT
Multi-Agent Systems is a new development approach, which uses the agent abstraction
to model and implement distributed and complex systems. Agents are defined as entities that
are capable of autonomous actions to achieve their goals. Nevertheless, most of the existing
agent implementation platforms do not use goal as a key concept (first-order element) to
implement the Multi-Agent System, do not allow the clear definition of the pro-activity level of
the agents, and they also create a strong coupling between agents and their actions.
Without a proper representation for these concepts, the developer is fully responsible for
their implementation, which leads to having these concepts mixed and scattered throughout
the agents’ actions. This problem makes it more difficult to design and implement the agents.
Moreover, the strong coupling between the agent and its actions makes it more, to reuse and
maintain the actions, thus restraining the agent’s evolution.
In order to solve these problems, this work proposes an agent platform based on the goal
concept. The agents’ goals are identified in the analysis phase and the proposed platform
allows the association of these goals to agents. Besides, it provides a mechanism to allow the
developer to set the agents’ pro-activity level.
This platform introduces some Service-Oriented Architecture (SOA) concepts in AgentOriented Approach. The main idea is to separate the agent from its actions in order to make
the development of the actions more modular and to foster their reuse.
15
1. INTRODUÇÃO
Ao longo da evolução da informática, várias abordagens têm sido propostas para auxiliar
os desenvolvedores a lidarem com a complexidade inerente ao desenvolvimento de
software. Nos anos 70, com a utilização da programação estruturada, o software era dividido
em partes menores, chamadas módulos, que podiam ser desenvolvidos separadamente
(BRAGA, 2003). A partir dos anos 80, com a crescente utilização do paradigma do
desenvolvimento orientado a objetos, os softwares passaram a ser decompostos em
pedaços menores, chamados de objetos. Cada objeto é responsável por realizar tarefas
específicas. Na abordagem orientada a objetos, é por meio da interação entre estes que as
funcionalidades do sistema são realizadas (BEZERRA, 2002).
Nas abordagens acima, observa-se a utilização de duas técnicas que auxiliam os
desenvolvedores a lidar com a complexidade inerente ao desenvolvimento de software: a
decomposição, que consiste na divisão de um problema em suas partes menores, reduzindo
o escopo do problema; e a utilização de abstrações, módulos e objetos, permitindo ao
desenvolvedor criar modelos cujo objetivo é representar uma perspectiva do sistema,
enfatizando partes relevantes e ignorando as partes irrelevantes.
Além dessas, várias outras abordagens têm sido propostas pela comunidade de
Engenharia de Software. Isso se faz necessário, pois, com a evolução tecnológica, a
complexidade inerente ao desenvolvimento de software e o tamanho do software têm
crescido muito. Por conseguinte, novas abordagens precisam ser definidas de forma a
acompanhar essa evolução.
Uma abordagem que vem sendo bastante utilizada é o desenvolvimento orientado a
agentes que auxilia o desenvolvedor na construção de sistemas distribuídos e complexos em
que haja uma forte interação entre suas partes (WOOLDRIDGE e CIANCARINI, 2001). A
sua principal abstração são os chamados agentes de software1, ou seja, o sistema é
decomposto em um conjunto de agentes que juntos fornecerão as funcionalidades definidas
para o sistema (JENNINGS e WOOLDRIDGE, 1999).
1
Nesta dissertação, o agente de software será chamado simplesmente de agente.
16
Um agente é um sistema de computação situado em algum ambiente, capaz de ações
autônomas sobre este ambiente para atingir os objetivos desejados. Algumas características
que um agente deve possuir incluem (WOOLDRIDGE e CIANCARINI, 2001):
•
Autonomia: Os agentes decidem qual o melhor momento para buscar o seu objetivo,
baseado em seus estados internos, sem a necessidade de qualquer intervenção
externa.
•
Reatividade: Os agentes possuem sensores que permitem perceber alterações no
ambiente em que residem. Conseqüentemente, podem reagir aos eventos ocorridos.
•
Pró-Atividade: Os agentes apresentam um comportamento orientado a objetivos, ou
seja, eles não atuam simplesmente em resposta a mudanças do ambiente.
•
Habilidade Social: Os agentes podem interagir com outros agentes, inclusive com os
próprios seres humanos, por meio de uma linguagem de comunicação.
É importante destacar, na definição dada acima, que os agentes estão associados a um
conjunto de objetivos que devem ser alcançados ao longo de sua execução, de forma
autônoma ou não. Para que isso ocorra, eles devem seguir e implementar uma seqüência
de atividades (ações). Uma forma de descrever essa seqüência de ações é por meio da
criação de planos (RUSSELL, 1995). Outra característica importante é a forte interação entre
os agentes. Conforme o princípio da decomposição, cada agente contém uma parte da
funcionalidade do sistema, e por meio da interação entre os agentes consegue-se atingir as
funcionalidades do sistema como um todo.
Um Sistema Multi-Agentes (SMA) é um sistema constituído por um conjunto de agentes
que interagem de forma a realizar um determinado conjunto de objetivos. Os agentes que
participam dessas interações são entidades orientadas a objetivos, nas quais autonomia e
pró-atividade são conceitos fundamentais. Agentes também são capazes de deliberar
acerca de seus objetivos, isto é, de determinar que objetivo alcançar e como alcançá-lo
(CHEONG e WINIKOFF, 2005).
A interação entre os agentes é feita por meio de uma linguagem declarativa de mais alto
nível (JENNINGS e WOOLDRIDGE, 1999) e é considerada como um dos fatores que mais
contribuem para o aumento da complexidade do sistema (WOOLDRIDGE e CIANCARINI,
2001). A utilização de uma linguagem de comunicação de mais alto nível reduz a
complexidade no desenvolvimento das interações entre agentes.
17
Essas interações podem ocorrer de várias formas diferentes, desde uma simples troca
de informações, solicitando a execução de uma determinada ação, até a implementação de
protocolos de cooperação, coordenação, negociação, etc. Além dessa forte interação, os
agentes podem se organizar em subconjuntos dentro do sistema com interações próprias
gerando estruturas complexas.
Na definição de SMA destacam-se dois pontos que o diferenciam de outros modelos
computacionais: o sistema está associado a um conjunto de objetivos que devem ser
alcançados durante a sua execução – característica também presente na definição dos
agentes; e o SMA deve ser solucionador flexível de problemas, tomando decisões em
tempo de execução não prevista em tempo de projeto (JENNINGS, 1999, p. 5).
Independente da abordagem a ser usada no desenvolvimento de software, é importante
ter uma representação que permita ao desenvolvedor visualizar as partes que compõem o
sistema. Esta representação fornece um modelo onde ele pode verificar a estrutura do
sistema a ser desenvolvido, sem considerar aspectos de implementação. Por meio da
supressão destes detalhes, o desenvolvedor pode se concentrar na análise dos pontos
cruciais da estruturação do sistema. A abordagem orientada a agentes possui várias
plataformas de desenvolvimento propostas cujo objetivo é auxiliar o desenvolvedor na
construção do sistema. Por exemplo, a FIPA-OS (FIPA, 2001b), o JADE (BELLIFEMINE,
POGGI e RIMASSA, 1999), ASF (SILVA, CORTÉS e LUCENA, 2004), o ZEUS (NWANA et
al., 1999) e o RETSINA (SYCARA et al., 2003). Todas elas apresentam características que
ocultam detalhes técnicos dos desenvolvedores, fornecendo as funcionalidades comuns aos
sistemas.
1.1.
Problema
Analisando as definições de agentes e de SMA verifica-se que em ambas os agentes
são definidos como entidades orientadas a objetivos. Contudo, a maioria das plataformas
existentes não fornece uma representação para que o desenvolvedor use objetivo como um
conceito de primeira ordem, conceito chave, na implementação de um SMA.
Todas as plataformas de desenvolvimento de SMA apresentam alguma forma de criar
as ações que serão executadas pelos agentes para atingir os seus objetivos. Contudo, a
maioria das plataformas se preocupa em implementar as ações isoladamente, sem
18
considerar os objetivos a que elas estão associados ou considerando o objetivo como sendo
simplesmente um estado a alcançar a partir da execução das ações. Isto faz com que se
percam de vista os objetivos dos agentes. Esse distanciamento entre os objetivos e a
implementação das ações acaba por dificultar o entendimento de qual objetivo está se
procurando alcançar com a execução de determinada ação.
Além do mais, os componentes que permitem a criação das ações pelos agentes,
normalmente, estão fortemente associados a estes. Isto acaba dificultando o
compartilhamento das ações entre os agentes, levando a uma possível redundância de
ações pelos agentes do sistema. Para minimizar este problema, de acordo com o nosso
entendimento, a plataforma deve prover mecanismos que reduza a forte ligação existente
entre os agentes e as suas ações.
Outra deficiência encontrada na maioria das plataformas é a pouca ênfase que se dá ao
conceito de pró-atividade exercida pelos agentes. Essa característica não fica evidente nas
plataformas, uma vez que não se tem uma forma clara de se implementar os objetivos e os
seus relacionamentos com as ações. Assim, a característica de pró-atividade acaba por estar
espalhada na implementação das ações executadas pelos agentes.
1.2.
Objetivo
O principal objetivo desta dissertação é permitir que a implementação do agente seja
feita a partir da associação direta de um conjunto de objetivos a ele, permitindo que esses
objetivos sejam perseguidos pelos agentes. Cada objetivo será descrito por um conjunto de
planos que define as ações e a ordem em que elas devem ser executadas.
Outro objetivo é promover a integração de alguns dos conceitos da Arquitetura Orientada
a Serviços à plataforma de desenvolvimento de SMA. Por intermédio desta integração, podese implementar as ações dos agentes como serviços, disponibilizando-os em repositórios
externos e permitindo que o uso destes seja descrito por meio da utilização de contratos.
Também é um objetivo da plataforma assegurar que o uso dos serviços seja
independente dos agentes específicos da aplicação. Ou seja, a plataforma deve fornecer
mecanismos que ocultem os detalhes técnicos necessários ao uso dos serviços, permitindo
assim, que o desenvolvimento dos agentes da aplicação se concentre nos objetivos que eles
devem alcançar.
19
Por último, a plataforma pretende propor um mecanismo que permita ao agente
implementar o conceito de pró-atividade, permitindo que o desenvolvedor possa configurar,
durante a implementação do agente, de forma rápida e direta, o grau de pró-atividade
desempenhada por ele.
1.3.
Contribuições Esperadas
As contribuições esperadas para este trabalho de dissertação são:
•
Concretizar o conceito de orientação a objetivos como um elemento de primeira
ordem na plataforma de desenvolvimento de agentes. Cada objetivo será descrito por
um conjunto de planos de execução, cujo intuito é definir a seqüência de ações
necessárias para atingi-lo com sucesso, e será associado diretamente aos agentes.
•
Integrar a abordagem baseada em agentes com a arquitetura orientada a serviços
(SOA), permitindo que haja uma redução na forte ligação existente entre os agentes e
suas ações.
•
Criar mecanismos que tornem a busca dos contratos das ações independentes dos
agentes da aplicação, permitindo que o desenvolvedor se concentre no seu domínio
do problema e não em detalhes de utilização da plataforma.
•
Permitir a criação de perfis, de maneira que o desenvolvedor possa configurar o grau
de pró-atividade desempenhada pelo agente.
1.4.
Organização
Esta dissertação está organizada em sete capítulos. O capítulo 2 fundamenta os
conceitos que proporcionam o embasamento teórico necessário à compreensão da
plataforma proposta na dissertação. O capítulo 3 descreve alguns trabalhos relacionados à
presente dissertação. Já o capítulo 4 descreve a plataforma proposta. O capítulo 5 apresenta
dois estudos de caso da utilização da plataforma proposta: sistema de empréstimos – estudo
de caso presente na especificação da linguagem BPEL – e um sistema de compra de livro –
presente na documentação do framework JADE. O capítulo 6 destaca as conclusões desta
dissertação, com uma lista das contribuições e possíveis trabalhos futuros. O capítulo 7 exibe
as referências bibliográficas utilizadas nesta dissertação. Por último, segue o apêndice.
20
2. FUNDAMENTAÇÃO TEÓRICA
Para atingir os objetivos propostos nesta dissertação, várias tecnologias foram
estudadas. Algumas delas se mostraram mais interessantes a nossa proposta do que outras.
Por isso, os principais fundamentos das tecnologias que foram utilizadas no desenvolvimento
da plataforma proposta serão apresentados a seguir.
2.1.
Arquitetura Orientada a Serviços (SOA)
A arquitetura SOA (MCGOVERN, et. al., 2003) é uma arquitetura conceitual cujo
principal objetivo é promover o desacoplamento entre as aplicações e os seus serviços, por
meio da separação da implementação do serviço da sua interface (MCGOVERN, et. al.,
2003). Com isso, para o consumidor do serviço, este passa a ser apenas um “alvo” com um
formato de solicitação específico.
O formato para utilização do serviço é definido por meio de contratos cujo objetivo é
definir o protocolo necessário para interação entre as partes envolvidas. O consumidor
precisa apenas obedecer ao protocolo definido, não sendo necessário conhecer nenhum
detalhe a respeito de sua implementação.
Com o intuito de permitir que o consumidor descubra e execute um serviço, a arquitetura
SOA utiliza o paradigma “find, bind and execute”. Por meio dele, o consumidor pode localizar
um determinado serviço (find), se ligar a ele (bind) e executá-lo (execute). Para que tal
mecanismo seja possível, SOA define a arquitetura ilustrada na FIG. 2.1 (MCGOVERN, et.
al., 2003).
O consumidor do serviço (service consumer) representa a aplicação, ou outro tipo de
software, que requer o uso de algum serviço. Ele é o sujeito das ações nesse paradigma, ou
seja, ele promove a busca do serviço, se liga ao provedor deste e executa o serviço. O
consumidor executa o serviço por meio de uma solicitação no formato especificado no
contrato do serviço.
21
FIG. 2.1 Paradigma “find, bind and execute” (em inglês)
O provedor do serviço (Service Provider) é uma entidade, algum tipo de software,
acessível por meio de um endereço de rede que aceita e executa solicitações do
consumidor. Ou seja, é o serviço propriamente dito. Ele disponibiliza o seu contrato de
utilização no repositório de serviço.
O repositório de serviço (Registry) é uma área acessível por meio da rede que contém os
contratos dos serviços existentes. Ele recebe e armazena contratos disponibilizados pelo
provedor do serviço, tornando-os disponíveis para os consumidores. O contrato do serviço
(Contract) é a especificação de como o consumidor do serviço deve interagir com o provedor
desse. Ele especifica o formato da solicitação e da resposta do serviço.
Na especificação da arquitetura SOA ainda existem duas outras entidades que não são
visualizadas diretamente na FIG. 2.1. A primeira delas é o chamado proxy do serviço cuja
existência não é obrigatória. Porém, caso exista, encapsula os detalhes necessários a
implementação do paradigma, permitindo, dessa forma, que a aplicação cliente, consumidor,
fique independente desses detalhes.
A segunda entidade é o chamado lease service cujo objetivo é definir uma fatia de tempo
para validade da concessão do serviço. Ele é necessário para serviços que precisem manter
22
o estado conversacional entre o consumidor e o provedor. Essa entidade ajuda a diminuir o
acoplamento entre o consumidor e o provedor, uma vez que não permite que a ligação entre
as partes envolvidas exista por um longo período.
Por meio da utilização da arquitetura SOA espera-se alcançar uma série de benefícios.
(MCGOVERN, et. al., 2003) enumera esses benefícios, dos quais podem-se destacar:
•
Diminuição do acoplamento: O acoplamento pode ser entendido como o nível de
dependência entre os módulos de um sistema. A arquitetura SOA consegue reduzir o
acoplamento entre o consumidor e o provedor por meio do uso de contratos e da ligação
entre eles ser feita em tempo de execução.
Uma vantagem alcançada com a redução do acoplamento é referente ao isolamento das
alterações. Ou seja, alterações realizadas em um módulo tendem a se restringir a ele,
sem se espalharem pelos demais.
•
Interoperabilidade: A interoperabilidade é habilidade de sistemas que utilizam plataformas
diferentes se comunicarem. Para reforçar a interoperabilidade entre os sistemas, cada
serviço fornece uma interface que pode ser invocada por meio de um conector. O
conector consiste na definição do protocolo e dos tipos de dados suportados.
Essa característica permite que um sistema seja composto por partes heterogêneas e
fique independente da plataforma de execução.
•
Independência de localização: A arquitetura SOA utiliza o paradigma “find, bind and
execute” com o intuito de permitir que o consumidor não conheça a localização do
provedor do serviço até o momento em que o contrato é interpretado.
Mecanismos que aumentam a independência de localização melhoram a disponibilidade
e o desempenho do sistema porque permitem que os serviços sejam remanejados,
devido alguma falha no destino original ou por uma questão de melhor dividir o
processamento, sem afetar o cliente do serviço.
Existem algumas tecnologias que implementam a arquitetura SOA. Nem todas elas
implementam todos os componentes definidos na especificação. Uma tecnologia que
implementa a arquitetura SOA é a chamada Web Services cuja descrição mais detalhada
segue na próxima seção.
23
2.2.
Web Services (WS)
Segundo a definição proposta pelo W3C (BOOTH, 2004) WS é uma tecnologia que
permite a interoperabilidade entre máquinas. Ela possui uma interface cujo formato pode ser
processado diretamente pelas máquinas. Em outras palavras, WS é uma tecnologia que
implementa os conceitos definidos na arquitetura SOA por meio da definição de várias
camadas e da utilização de tecnologias inter-relacionadas. As camadas utilizadas na
tecnologia WS são ilustradas na FIG. 2.2 (BOOTH, 2004).
FIG. 2.2 Pilha de WS (em inglês)
Abaixo segue uma breve descrição das principais camadas cujo entendimento é
necessário para o desenvolvimento da arquitetura proposta no próximo capítulo.
24
2.2.1. XML
A linguagem XML propicia a interoperabilidade entre aplicações por intermédio do uso de
um formato de dado padrão, flexível e extensível. Portanto, ela é utilizada como uma
tecnologia que suporta a arquitetura de WS.
2.2.2. Communications (Camada de Transporte)
Essa camada é a responsável pela disponibilização dos WSs, tornando-os acessíveis
por intermédio de algum dos protocolos de transporte disponíveis, como por exemplo HTTP,
SMTP, FTP. Os WSs são construídos com base em padrões de comunicação existentes,
que os torna independentes do transporte e contribui para a interoperabilidade.
2.2.3. Messages (Camada de Mensagem)
Essa camada é a responsável pela definição do formato das mensagens utilizadas para
comunicação entre as aplicações. O protocolo padrão definido para essa camada é o
chamado SOAP cujo objetivo é prover um framework padrão e extensível que permita o
empacotamento e a troca de mensagens XML. HENDRICKS (2002) apresentada algumas
características importantes do protocolo SOAP:
•
O SOAP é um protocolo superficial e simples, pois tudo o que é necessário é que os
dados em um formato XML passem pela camada de transporte.
•
O SOAP não é vinculado a nenhum protocolo de transporte em particular.
•
O SOAP é facilmente extensível por meio do uso da linguagem XML.
2.2.4. Descriptions (Descrição do Serviço)
Essa camada permite que o provedor do serviço descreva as funcionalidades expostas
pelo WS. Os serviços são descritos por meio da utilização dos chamados WSDL
(CHRISTENSEN et. al., 2001). Um contrato WSDL descreve um WS como um conjunto de
extremidades operando de forma independente.
25
O contrato WSDL pode ser dividido em dois conjuntos. O primeiro deles é formado pelos
componentes utilizados para definição abstrata da interface do WS. O segundo consiste dos
componentes utilizados para definição da parte física necessária ao uso do WS.
A parte abstrata é composta por quatro componentes e a parte física é composta por três
componentes (CHRISTENSEN et. al., 2001). Abaixo segue uma breve descrição dos
componentes que formam cada um desses conjuntos:
•
Abstrata:
1. Operation: É a descrição abstrata de uma ação suportada pelo WS.
2. PortType: É composto por um conjunto de operações representado pelo componente
operation e pode ser suportado por uma ou mais extremidade.
3. Message: Contém a descrição dos dados a serem utilizados pelo WS.
4. Types: Contém os tipos de dados que estão presentes nos componentes Messages.
•
Concreta:
1. Binding: Mapeia os elementos operation para um protocolo específico.
2. Port: Representa uma extremidade simples por meio do uso do Binding e de um
endereço de rede.
3. Service: Representa uma coleção de extremidades inter-relacionadas.
Por meio do uso dos componentes acima, pode-se ligar a definição abstrata de um
serviço a vários protocolos de transporte. Ou seja, a definição do contrato WSDL permite que
se defina um WS independente do protocolo de transporte.
2.2.5. Processes (Processos)
Essa camada permite usar WS em um nível mais alto de abstração. O cliente de um WS
pode ser tanto uma outra aplicação, por exemplo, um outro WS, quanto um ser humano.
Dessa forma, devem existir mecanismos que auxiliem o cliente no uso do WS.
2.2.6. Discovery (Descoberta de Serviço)
Para assegurar a independência da localização do serviço, a tecnologia de WS define o
componente de descoberta de serviço. Esse componente é o responsável por armazenar as
26
informações a respeito do WS cujo conteúdo pode ser tanto informações comerciais quanto
técnicas.
Portanto, a arquitetura de WS propõe a criação de registro central, onde os provedores e
os consumidores de serviços trabalham em conjunto para publicar e recuperar as
informações apropriadas. A especificação para a publicação e localização é a especificação
UDDI (BELLWOOD et. al., 2002).
A especificação UDDI define cinco tipos de estrutura de dados cujo objetivo é propor
uma categorização que permita uma rápida localização e entendimento do serviço. Os
serviços armazenados não são necessariamente serviços relacionados com o uso de
computadores. Na verdade, o UDDI foi projetado para manter informações arbitrárias sobre
um negócio. A FIG. 2.3 ilustra as estruturas propostas (BELLWOOD et. al., 2002):
FIG. 2.3 Estruturas do registro UDDI (em inglês)
A estrutura businessEntity é o elemento raiz da hierarquia de dados do registro UDDI
cujo objetivo é conter informações referentes ao negócio, como por exemplo nome,
endereço, telefone. Uma vez o negócio registrado no UDDI, por meio da criação da estrutura
businessEntity, pode-se descrever os serviços oferecidos pelo negócio. Para isso, utiliza-se a
estrutura businessService.
27
A estrutura businessService pode ser composta dos chamados bindingTemplate cujo
uso é opcional. Este permite um maior detalhamento das informações sobre um determinado
serviço. A estrutura bindingTemplate pode ser composta por um conjunto de tModels cujo
objetivo é representar uma especificação técnica em um registro UDDI. Por exemplo, caso o
serviço cadastrado no UDDI represente um WS, o contrato WSDL será armazenado como
um tModel no UDDI.
Por último, aparece o chamado publisherAssertion, adicionado à versão 2.0 do UDDI,
cujo intuito é fornecer suporte para a vinculação de dois elementos businessEntity.
2.2.7. Choreography
Existem dois termos que se referem a “composição” de WS. O primeiro deles é o
Choreography que se refere a interação observável do serviço com os seus usuários
(AUSTIN et. al., 2004). Os usuários podem ser tantas aplicações, por exemplo, outros WS,
quanto os próprios seres humanos. O segundo é o chamado Orchestration que descreve
como WS interage com outros no nível de mensagem, incluindo lógica de negócio e ordem
da execução das interações (PELTZ, 2003).
Há importantes diferenças entre os dois termos acima. Para o termo Orchestration, o
processo é sempre controlado sobre a perspectiva de um dos participantes da interação. Já
para o termo Choreography a interação entre as partes é mais colaborativa.
Por meio da utilização desses conceitos pode-se modelar um processo de negócio pela
composição da tecnologia de WS. Diversos padrões estão disponíveis para auxiliar nesse
objetivo. Dentre esses padrões destacam-se: BPEL, WSCI e BPML. Na próxima seção
abordam-se os principais conceitos existentes no BPEL, pois ele será utilizado na arquitetura
proposta adiante.
2.3.
Business Process Execution Language (BPEL)
BPEL (ANDREWS et al, 2003) define um modelo e uma gramática que descreve o
comportamento do processo de negócio baseado na interação entre o processo com os seus
parceiros. A interação com cada parceiro ocorre pelo uso de interface WS (ANDREWS et al,
2003). Em outras palavras, BPEL representa uma interação de longa duração que conserva
28
os seus estados, em que cada interação tem um começo, um comportamento definido e um
fim.
Uma característica muito importante no BPEL é a interação com os chamados partner
que representam as aplicações que interagem com o processo de negócio. O partner pode
representar o consumidor do serviço modelado pelo processo de negócio, mas também
pode representar o provedor de algum serviço oferecido pelo processo de negócio. Para
modelar a interação com os partner, BPEL oferece três elementos (ANDREWS et al, 2003):
•
Partner Link Types: Define o relacionamento conversacional entre dois serviços
pela definição de “papéis” associados a cada serviço e pela especificação de
portTypes providos por cada serviço para receber mensagens dentro do contexto
do relacionamento.
•
Partner Links: Modela os serviços que interagem com o processo de negócio.
•
Business Partner: O elemento partner é definido com um subconjunto do
elemento partner links. Sua utilização é opcional e introduz uma restrição na
funcionalidade que deve ser provida pela aplicação que interage com o processo
de negócio.
Além dos elementos que permitem modelar as aplicações que interagem com o
processo de negócio, BPEL oferece um conjunto de atividades cujo objetivo é
permitir a definição do processo de negócio propriamente dito. Abaixo segue a lista
de todas as atividades definidas na especificação BPEL (ANDREWS et al, 2003):
•
receive: Espera por uma mensagem que atenda algum critério. Enquanto espera
não realiza nenhuma ação.
•
reply: Envia uma mensagem de reposta referente a uma mensagem recebida
anteriormente.
•
invoke: Permite chamar alguma operação disponibilizada por meio de algum WS.
•
assign: Realiza atualizações de valores internos ao processo de negócio.
•
throw: Gerencia as falhas ocorridas dentro do processo de negócio.
•
terminate: Termina a execução do processo de negócio.
•
wait: Permite que o processo de negócio fique esperando por um intervalo de
tempo ou até alguma hora específica.
•
empty: Não realiza nenhuma operação. Essa atividade pode ser útil para realizar
sincronização entre atividades concorrentes.
29
•
sequence: Permite definir um conjunto de atividades que será executada de
forma seqüencial.
•
switch: Permite selecionar um caminho de execução.
•
while: Permite executar um conjunto de atividades até que alguma condição seja
satisfeita.
•
pick: Permite definir um conjunto de mensagens a receber, espera que alguma
dessas aconteça e executa as atividades associadas a mensagem recebida.
•
flow: Permite definir um conjunto de atividades que será executada de forma
concorrente.
•
scope: Permite criar escopo para um conjunto de atividades.
•
compensate: permite lidar com falhas ocorridas no processo de negócio.
Todas as atividades definidas na especificação BPEL apresentam um conjunto
de atributos (standard-attributes) e um conjunto de elementos (standard-elements)
em comum cujo o uso é opcional. Por meio do uso dos atributos é possível associar
um nome à atividade, atributo name, definir caminhos de execução concorrentes,
atributo joinCondition, e suprimir falhas ocorridas durante a execução da atividade,
atributo suppressJoinfailure.
Já os elementos em comum permitem realizar sincronização entre atividades
concorrentes. Por meio do uso desses elementos pode-se definir uma atividade
como destino, elemento target, da execução de outras atividades. Como também
pode-se definir uma atividade com origem, elemento source, de outras atividades.
Ou seja, ao término da execução de alguma atividade origem, pode-se avaliar
alguma condição definida pelo processo e, com isso, habilitar ou não a execução
das atividades que são alvos da atividade origem finalizada.
Abaixo segue um detalhamento maior das atividades que serão necessárias
para o desenvolvimento da plataforma proposta no próximo capítulo. Caso o leitor
deseje um maior detalhamento das demais atividades, favor consultar ANDREWS et
al (2003).
2.3.1. Atividade Receive
O processo de negócio provê um serviço para os seus partners por meio do uso das
atividades receive e reply. Uma vez que elas representam o canal de comunicação com o
30
processo de negócio. Ou seja, a atividade receive representa o canal de entrada e a
atividade reply representa o canal de saída.
A atividade receive especifica o partner link de quem ela espera receber a mensagem e
a portType e operation que ela esperar que o partner chame. Ela também pode definir uma
variável que será usada para receber algum dado enviado pelo partner. Além disso, ela
desempenha um papel importante no ciclo de vida do processo de negócio, pois ela permite
a criação de uma instancia do processo por meio do uso do atributo createInstance.
Uma mensagem destinada para um processo de negócio deve ser entregue para a
extremidade de destino correta e para a instância correta do processo. Com esse intuito,
BPEL utiliza o elemento correlations para realizar a associação da mensagem com a
instância apropriada.
2.3.2. Atividade Reply
Essa atividade é utilizada para enviar uma resposta a uma solicitação recebida
anteriormente. Ela pode definir uma variável que conterá algum dado que deverá ser enviado
junto com a resposta. Uma atividade reply deve ser sempre precedida por uma atividade
receive com a mesma definição para o atributos partner link, portType e operation.
Essa atividade também define o uso do elemento correlations que permite realizar a
associação de uma determinada mensagem de resposta com a instância apropriada.
2.3.3. Atividade Invoke
Os WS disponibilizados pelos partners são utilizados pelo processo de negócio para
realizar alguma tarefa. O partner é definido pelo atributo partnerLink e o WS é definido por
meio do uso dos atributos portType e operation. As variáveis inputVariable e outputVariable
representam respectivamente os argumentos de entrada e os argumentos de saída.
O BPEL permite que a chamada de um WS seja síncrona (solicitação/resposta) ou
assíncrona, mantendo a mesma sintaxe para ambas as chamadas. A identificação do tipo de
chamada é feita pelo uso das variáveis de entrada e de saída. A solicitação assíncrona exige
somente a definição da variável de entrada, uma vez que não é esperado nenhum retorno da
31
chamada, enquanto a solicitação síncrona exige a definição de ambas as variáveis, entrada e
saída.
Além da definição do elemento correlations, a atividade invoke define dois outros
elementos. O primeiro é o elemento catch cujo objetivo é permitir a captura de falhas
ocorridas durante a chamada do WS, com o seu respectivo tratamento. O segundo elemento
é o compensationHandler cujo objetivo é definir quais atividade devem ser executadas para
compensar a ocorrência de alguma falha.
2.3.4. Atividade Sequence
A atividade sequence define uma ou mais atividades que devem ser executadas de
forma seqüencial, na ordem em que aparecem no corpo da atividade sequence.
2.3.5. Atividade Flow
A atividade flow define uma ou mais atividades que devem ser executadas de forma
concorrente, na ordem em que aparecem no corpo da atividade flow. Essa atividade define a
criação de links cujo objetivo é realizar sincronização entre as diversas atividades. Os links
criados na atividade flow são utilizados nos elementos padrões de todas as atividades.
2.3.6. Atividade Wait
A atividade wait permite ao processo especificar um tempo determinado de espera ou
até algum prazo ser alcançado. Um uso típico desta atividade é a chamada de operações
num determinado momento específico.
32
3. TRABALHOS RELACIONADOS
Atualmente, existem várias plataformas propostas para SMA. Todas elas disponibilizam
uma infra-estrutura básica que permite ao desenvolvedor abstrair os detalhes comuns à
criação dos agentes. Com isso, o desenvolvedor pode se concentrar nos detalhes
necessários a criação do seu próprio agente.
Por exemplo, todas as arquiteturas fornecem alguma forma de criar agentes e
implementar as ações necessárias para que seus objetivos sejam alcançados. Um outro
exemplo é a presença de algum componente que tem a responsabilidade de implementar o
protocolo de comunicação entre os agentes. Dessa forma, o desenvolvedor, ao construir o
seu agente, recebe essas funcionalidades diretamente da plataforma.
A grande maioria dos conceitos presentes nas definições de agentes e SMA são
implementados nas plataformas disponíveis. Contudo, não existe uma uniformidade na
implementação desses conceitos.
3.1.
FIPA-OS
FIPA (Foundation for Intelligent Physical Agents) é uma organização cujo objetivo é
promover a tecnologia baseada em agentes, por meio da especificação de padrões, e a
interoperabilidade desses padrões com outras tecnologias (FIPA, 2005). A organização
padrão para agentes e para Sistemas Multi-Agentes foi aceita oficialmente pela IEEE
(Institute of Electrical and Electronics Engineers), como seu décimo primeiro comitê, em 8 de
junho de 2005.
Para atingir o seu objetivo, a FIPA propõe uma plataforma abstrata que descreve os
elementos que são necessários para a implementação de um SMA. A partir dessa descrição,
podem-se explorar os relacionamentos existentes entre os diversos elementos, identificando
características comuns à implementação de um ambiente em conformidade com a
especificação. Dessa forma, a plataforma abstrata provê um mecanismo que assegure a
interoperabilidade entre implementações distintas.
33
No modelo de referência apresentado na FIG. 3.1 (FIPA, 2001b), observa-se a
existência de seis componentes – Agent Platform, Message Transport System, Agent
Management System, Directory Facilitator, Agent e Software – que juntos propiciam as
funcionalidades requeridas. Essa plataforma de referência não implica configuração física. Os
detalhes da implementação são responsabilidades dos desenvolvedores.
FIG. 3.1 Arquitetura de referência definida pela FIPA (em inglês)
3.1.1. Agent Platform (Plataforma de Agentes)
A plataforma de agentes representa o ambiente físico onde os agentes residem. Ela é
formada por um conjunto de máquinas, sistemas operacionais, software de suporte a
agentes, os componentes – Directory Facilitator, Agent Management System e Message
Transport System – e os demais agentes. O projeto interno da plataforma não é alvo da
padronização da FIPA, a responsabilidade de definir tais detalhes é atribuída aos
desenvolvedores do ambiente.
34
É importante ressaltar que o conceito de plataforma de agentes não implica que todos os
agentes pertencentes a uma mesma plataforma estejam fisicamente localizados na mesma
máquina. A mesma plataforma pode estar espalhada em máquinas diferentes, contendo
sistemas operacionais diferentes.
3.1.2. Message Transport System (MTS)
O MTS fornece mecanismos para que mensagens ACL (Agent Communication
Language – FIPA, 2001a) sejam trocadas entre os agentes. Os agentes que participam da
troca de mensagens podem estar localizados na mesma plataforma ou em plataformas
diferentes.
Em qualquer plataforma, o MTS é provido pelo chamado Agent Communication Channel
(ACC). O ACC pode acessar informações disponibilizadas pelos demais agentes (AMS e
DF), os quais também utilizam o ACC no envio e recepção de mensagens.
3.1.3. Agent Management System (AMS)
O agente AMS é o responsável pela gerência da operação da plataforma de agentes,
controlando o acesso e o uso da plataforma, criando, terminando os demais agentes e
supervisionando a migração de agentes entre diferentes plataformas. Portanto, para um
agente residir na plataforma é necessário que realize um cadastro no AMS. Durante esse
cadastro, o AMS concede uma identificação única ao agente, chamada de Agent Identifier
Description (AID), quando, então, poderá executar qualquer operação na plataforma, como,
enviar uma mensagem para outro agente.
Existem três situações em que um agente pode realizar um cadastro no AMS: A primeira
é quando o agente é criado na plataforma. A segunda é quando o agente migra de uma
plataforma para outra. E, a última, é quando o agente, diretamente, realiza o cadastro.
O agente AMS também fornece ao sistema o serviço de conversão de nomes,
identificando o endereço físico do agente. Segundo a especificação, o agente AMS é
obrigatório e deve ser único na plataforma. Essa obrigatoriedade é devido ao fato do AMS
fornecer os AIDs para os agentes e ao seu caráter de gerente da plataforma.
35
3.1.4. Directory Facilitator (DF)
O DF é um agente cujo objetivo é prover o serviço de páginas amarelas para a
plataforma de agentes. O conceito de páginas amarelas está presente na arquitetura peer-topeer, onde um nó não sabe da localização do outro. Portanto, um determinado nó consulta o
serviço de páginas amarelas em busca da localização do nó procurado.
Conforme a especificação, a existência do DF, na plataforma, não é obrigatória. Caso ele
não exista, a plataforma não oferecerá o serviço de páginas amarelas. Adicionalmente, em
uma mesma plataforma, podem existir mais de um DF.
Dessa forma, o DF é o agente que contém as informações a respeito dos demais
agentes. Ou seja, todo agente que quiser informar algum serviço seu para os demais
agentes deve realizar um cadastro no DF. Com isso, basta que qualquer outro agente, que
precise de algum serviço, consulte o DF em busca do agente que realize o serviço
procurado.
Apesar do cadastro realizado pelo agente no DF, não existe nenhum compromisso ou
obrigação, por parte do agente que se cadastrou, em atender uma solicitação. Por exemplo,
um determinado agente pode recusar uma solicitação de um serviço seu publicado no DF.
Cabe ressaltar que o DF não garante a validade das informações registradas nele, nem pode
controlar o ciclo de vida de qualquer agente. Contudo, o DF restringe o acesso as
informações cadastradas nele, pois, verifica as permissões de acesso dos agentes.
Além das funcionalidades que permitem o registro e a busca de informações, o DF
também disponibiliza duas outras funcionalidades. A primeira permite desfazer o registro
prévio. Como conseqüência, o DF passa a não ter mais o compromisso de conter
informações sobre o agente. A segunda permite que o agente modifique alguma informação
registrada anteriormente.
3.1.5. Agent (Agente)
O agente é a entidade de software, processo, que implementa os conceitos existentes
na abordagem de desenvolvimento orientado a agentes. O agente é o principal componente
existente no ambiente. Cada agente deve possuir um conjunto de ações que o possibilita
buscar seus objetivos de projeto.
36
Os agentes residem em um determinado ambiente e possuem a capacidade de interagir
com o ambiente e com os demais agentes. A comunicação entre os agentes deve ser feita
com o uso de uma linguagem de comunicação de agentes, a ACL. A ACL é linguagem pela
qual os agentes expressam os seus atos comunicativos (FIPA, 2001c) e constroem suas
mensagens.
O agente utiliza as facilidades oferecidas pela plataforma de agentes para realizar as
suas funcionalidades. A partir do momento que o agente realiza seu cadastro no AMS, ele
pode assumir uma série de estados que representam o seu comportamento observável. A
esse conjunto de estados dá-se o nome de ciclo de vida do agente. A FIG. 3.2 apresenta o
ciclo de vida definida na especificação.
FIG. 3.2 Ciclo de vida do agente (em inglês)
A especificação definida pelo FIPA-OS, não trata dos detalhes a respeito do projeto
interno e da implementação dos agentes e da infra-estrutura de gerenciamento dos agentes.
Esses detalhes estão fora do escopo da FIPA e, são incumbência das implementações que
seguem as suas especificações.
37
3.1.6. Software
Esse componente representa todo artefato executável que não é um agente e que se
localiza fora da plataforma. Ele pode prover novos serviços, novos protocolos de
comunicação, etc. Por meio da utilização desse componente, os agentes podem interagir
com o mundo externo a plataforma.
3.2.
Java Agent Development Framework (JADE)
JADE (BELLIFEMINE, POGGI e RIMASSA, 1999) é um framework de desenvolvimento
de SMA, totalmente desenvolvido na linguagem de programação Java, que está em
conformidade com a especificação FIPA. Desta forma, seu objetivo também é simplificar o
desenvolvimento de aplicações baseadas em agentes, ocultando detalhes que são
independentes da aplicação e permitindo que o desenvolvedor se concentre na lógica dos
agentes da aplicação.
Uma importante característica em um agente é a sua autonomia. Em JADE essa
característica é expressa pela capacidade do agente controlar completamente a sua thread
de execução. Conforme descrito por BELLIFEMINE, POGGI e RIMASSA (1999), JADE
provê um conjunto de funcionalidades que auxiliam os desenvolvedores na construção de
aplicações. Dentre estas se podem destacar:
•
Plataforma de agentes distribuída que pode ser dividida em várias máquinas. Essa
plataforma está em conformidade com o modelo de referência proposto pela FIPA.
•
Disponibilidade dos agentes AMS, DF e ACC. Todos esses agentes são instanciados
automaticamente pela plataforma.
•
Mecanismos de transporte para a troca de mensagens entre os agentes.
•
Interface gráfica com o usuário que permite a gerência da plataforma e dos agentes.
A FIG. 3.3 ilustra arquitetura interna do JADE (BELLIFEMINE et al., 2005). Em cada host
é executado apenas uma única máquina virtual java (JVM, Java Virtual Machine). Cada JVM
é um contêiner básico que provê um ambiente completo para execução dos agentes de
forma concorrente.
38
FIG. 3.3 Plataforma distribuída de agentes JADE (em inglês)
A especificação da FIPA não define a organização interna para o agente, esta definição
é delegada para o desenvolvedor do ambiente. Portanto, o ambiente JADE define sua
própria organização. Ela é composta de cinco componentes: comportamentos ativos (active
agent behaviours), escalonador dos comportamentos (scheduler of behaviours), fila privativa
de mensagens (private inbox of ACL messages), recursos dependentes da aplicação
(application dependent agent resources) e o gerenciador do ciclo de vida (life-cycle manager).
A FIG. 3.4 mostra a organização interna utilizada pelo JADE (BELLIFEMINE, 2002).
Em JADE, toda tarefa, ação ou intenção desempenhada pelo agente é implementada
pelos comportamentos. Um agente JADE deve possuir pelo menos um behaviour. Eles são
executados de maneira concorrente, o que permite que o agente desempenhe tarefas
distintas.
39
FIG. 3.4 Organização interna do agente genérico JADE (em inglês)
O escalonador dos comportamentos é o responsável por definir a ordem de execução
dos comportamentos associados aos agentes. Cada agente possui uma fila privativa de
mensagens onde elas são postadas pelo JADE de forma transparente. Sempre que uma
mensagem é colocada na fila de um determinado agente, esse é notificado pelo JADE.
Contudo, a decisão de consumir uma dada mensagem, quando e qual, é inteiramente
definida pelo desenvolvedor do agente (CAIRE, 2003).
Os recursos dependentes da aplicação são representados pelos protocolos de interação
e comportamentos genéricos que devem ser customizados para as necessidades das
aplicações específicas. O gerenciador do ciclo de vida é o controlador dos estados
observáveis do agente.
3.3.
Web Services Integration Gateway (WSIG)
O WSIG (GREENWOOD, 2005) é uma extensão do framework JADE cujo objetivo é
prover suporte bidirecional para invocar serviços web. Ou seja, por intermédio dessa
extensão é possível tanto um agente procurar e invocar um serviço web quanto um serviço
web procurar e chamar um agente.
40
A plataforma atual consiste na adição de um agente especial chamado de gateway cujo
objetivo é controlar as chamadas originadas e as destinadas à plataforma. Ele é o
responsável por realizar a tradução dos protocolos utilizados na plataforma de agentes, por
exemplo, ACL/SL0, para os utilizados no serviço web, WSDL, SOAP, etc. e vice-versa. O
WSIG permite registrar um serviço web no DF como se fosse um agente. Com isso, o serviço
web registrado pode ser invocado pelos demais agentes por meio do uso do agente
gateway.
Os agentes que deverão ser expostos como serviços web devem ser registrados no DF
como um tipo especial, chamado de web-service. Com isso, o DF informa ao agente gateway
que um novo serviço foi cadastrado. Ele então realiza a conversão da descrição do agente
para os protocolos utilizados pelos serviços web e realiza o cadastro no repositório utilizado
pelo serviço web. A partir desse momento, esse serviço pode ser descoberto por qualquer
serviço web externo.
Para invocar um agente exposto como serviço web, o serviço web cliente deve,
primeiramente, procurar no seu repositório a descrição do serviço desejado. Uma vez
encontrada essa descrição e analisado o protocolo de solicitação que deverá conter uma
referência ao agente gateway, este será invocado com o intuito de converter os protocolos do
serviço web para uma mensagem ACL, com solicitação REQUEST.
Esta mensagem será encaminhada para o agente que provê o serviço. Caso esse
serviço retorne alguma informação, o agente gateway espera por uma mensagem ACL, com
solicitação INFORM, indicando o retorno da informação esperada. Essa, por sua vez, será
repassada para o serviço web cliente.
Por outro lado, para que um serviço web seja exposto com um agente, ele deve ser
registrado diretamente no repositório de serviço web do WSIG. Esses novos registros são
automaticamente detectados pelo agente gateway que promove a conversão dos protocolos
de serviço web para os utilizados pelos agentes e realiza o registro deles no DF. A partir
desse momento, eles podem ser chamados pelos demais.
Para um agente invocar um serviço web, registrado anteriormente no DF, é necessário
que o agente consulte o DF em busca do serviço desejado. Uma vez encontrado, o agente
envia uma mensagem ACL, com solicitação REQUEST, para o agente gateway.
O agente gateway, ao receber a mensagem, interpretá-a em busca de informações
sobre os repositórios de serviço web. No caso desta informação ser encontrada, ele cria uma
41
solicitação para o serviço web desejado e realiza sua chamada. Caso alguma resposta deva
ser retornada, ele espera o fim da execução do serviço e retorna o resultado em uma
mensagem ACL, com solicitação INFORM.
3.4.
Framework Orientado a Objetos para Implementação de Sociedades de Agentes
O framework orientado a objetos ASF (SILVA, CORTÉS e LUCENA, 2004) – Agents
Society Framework – contempla o desenvolvimento de uma sociedade de agentes por meio
da utilização de conceitos como: agentes, papéis, organizações e ambientes. Como tais
conceitos não se encontram presentes no paradigma orientado a objetos, o ASF propõe a
criação de um conjunto de classes para representá-los.
O framework ASF é composto por um conjunto de módulos, implementado na
linguagem de programação Java, que define as classes e os seus relacionamentos para
implementar os conceitos existentes na definição de uma sociedade de agentes (SILVA,
CORTÉS e LUCENA, 2004): o módulo do agente implementa o conceito de agentes e suas
propriedades; o módulo da organização implementa o conceito de organização de agentes; o
módulo do papel do agente implementa o conceito de roles e o módulo do ambiente
implementa o conceito do ambiente no qual o agente reside.
O módulo do agente disponibiliza uma classe abstrata, chamada Agent, que deve ser
estendida pelo usuário do framework. Neste módulo, observa-se a existência dos conceitos
de agentes orientados a objetivos. Por exemplo, o agente está associado a um conjunto de
objetivos, que são descritos por planos. Os objetivos podem ser representados de forma
hierárquica e sua seleção é feita de acordo com esta hierarquia. A princípio os agentes são
entidades pró-ativas, porém o desenvolvedor pode criar um agente reativo. A FIG. 3.5 ilustra
as classes e os relacionamentos definidos no módulo agente.
42
FIG. 3.5 Módulo Agente ASF (em inglês).
3.5.
JADEX
JADEX (POKAHR, BRAUBACH e LAMERSDORF, 2003) é uma extensão da
plataforma JADE que implementa os conceitos da arquitetura BDI ─ Belief-Desire-Intention ─
proposta inicialmente em (BRATMAN, 1987) e adaptados posteriormente por (RAO e
GEORGEFF, 1995) para um modelo formal. Esta arquitetura permite visualizar o agente
como uma entidade orientada a objetivos que se comporta de uma maneira racional,
atribuindo crenças (Belief), desejos (Desire) e intenções (Intention) aos agentes.
A crença representa as informações que o agente possui sobre o ambiente em que ele
reside e sobre o seu estado interno. Os agentes são vistos como entidades orientadas a
objetivos, conseqüentemente, o objetivo, identificado pela abstração Desire, é um conceito
central na arquitetura BDI, representando um estado alvo que o agente tenta alcançar. Os
planos, identificados pela abstração Intention, são os meios pelos quais os agentes atingem
os seus objetivos. Estes não representam apenas uma seqüência básica de ações, mas
permitem a inclusão de subobjetivos.
43
A FIG. 3.6 ilustra a arquitetura abstrata utilizada pelo Jadex. O agente interage com o
ambiente no qual ele reside por meio do envio e recebimento de mensagens. O componente
chamado de Reaction Deliberation pode receber como entrada as mensagens enviadas para
o agente, os eventos internos ou novos objetivos e implementa os mecanismos que
permitem ao agente deliberar sobre o que fazer, qual o objetivo deve ser alcançado.
A partir do resultado da deliberação, são gerados eventos que podem ser enviados para
um plano que esteja sendo executado (Running Plans) ou para novos planos instanciados da
base de planos (Plan Library). Durante sua execução o plano pode acessar e modificar a
base de crenças (Belief Base), enviar mensagens para outros agentes, criar objetivos, tanto
de nível mais alto quanto subobjetivos e originar eventos internos.
FIG. 3.6 Arquitetura Abstrata do Jadex (em inglês)
3.6.
SemantiCore
SemantiCore (BLOIS e LUCENA, 2004) é um framework que define uma camada de
abstração sobre a arquitetura de distribuição de serviço de forma a fornecer artefatos de alto
44
nível para o desenvolvimento de aplicações Web, onde as aplicações Web são compostas
por agentes e conteúdos inteligíveis por máquinas. O seu principal objetivo é permitir o
desenvolvimento do agente e do ambiente no qual ele reside, considerando a semântica
deste ambiente. Outro objetivo é abstrair a plataforma de software e o protocolo de
comunicação, permitindo que aplicação envie e receba mensagens usando diferentes
padrões, como por exemplo: FIPA ACL ou SOAP.
Para facilitar o desenvolvedor na construção de aplicações, o framework SemantiCore
se divide em dois modelos: modelo semântico do agente, que é responsável pela definição
interna do agente, e o modelo semântico do domínio, que é responsável pela definição da
composição do domínio e pelas entidades administrativas.
O modelo semântico do agente é formado por seis componentes: Sensorial, Decision,
Execution Flow, Agent Effector, Memory e Knowledge. A primeira aptidão necessária para o
agente semântico é receber recursos do ambiente, para isso, o componente Sensorial
permite a recepção dos objetos semânticos através do ambiente. Os desenvolvedores
podem definir diferentes tipos de sensores que capturam diferentes tipos de objetos
presentes no ambiente.
Após receber os objetos semânticos, o agente envia o conteúdo dos objetos que
ativaram os sensores para o componente Decision. Este componente encapsula o método
de decisão utilizado pelo agente, transformando a entrada em fatos e regras da linguagem de
representação utilizada. Esses fatos e regras são enviados para máquina de inferência de
decisão e o componente Decision espera pela saída, sobre a forma de uma Action. Action
mapeia os comandos possíveis que o agente semântico pode executar.
O componente Execution Flow abstrai a máquina de workflow utilizada para controlar a
transição das atividades do processo. Alguns processos podem publicar objetos semânticos
no ambiente para que outros agentes os consumam. Para isso, o agente deve possuir
efetuadores apropriados. Estes efetuadores são controlados pelo componente Effector cuja
responsabilidade é recebe dados dos outros componentes e encapsula-os em objetos
semânticos para serem transmitidos pelo ambiente.
O componente Memory é o responsável por encapsular os detalhes sobre a persistência
dos objetos semânticos pelos agentes. Por último, tem-se o componente chamado de
Knowledge cuja responsabilidade é representar o conhecimento e recuperá-lo. Ele controla
as ontologias utilizadas pelos agentes quando decide o que fazer pelo componente Decision
45
e relaciona esse conhecimento com outros elementos internos, como por exemplo, regras,
sensores e processos.
Já para o ambiente onde o agente reside, o modelo semântico do domínio é composto
por três componentes: Domain Manager, Service Manager e Resource Manager. O
componente Domain Manager é um agente responsável pelo registro dos demais agentes
do ambiente, por características de segurança e pela recepção de agentes móveis de outros
domínios.
O componente Service Manager é um agente cuja responsabilidade é oferecer o serviço
de páginas amarelas, permitindo que os agentes encontrem outros por meio dos serviços
que eles executam. Já o componente Resource Manager é o responsável por realizar a
transição entre o domínio semântico e o convencional. Ele recebe mensagens, as traduz
para representação apropriada e as envia através do ambiente do domínio semântico. Ele
também é o responsável por registrar o conhecimento do agente e por permitir a busca de
objetos do conhecimento no ambiente.
3.7.
Considerações Sobre os Trabalhos Relacionados
A especificação feita pela FIPA não define nenhuma organização interna para o agente,
definindo apenas suas interações. Dessa forma, cada implementação que esteja em
conformidade com a FIPA pode apresentar sua própria organização. Isso acaba provocando
um distanciamento da definição conceitual de agente na implementação.
Por exemplo, na implementação JADE, o conceito de objetivo do agente não é
visualizado de forma clara e direta, pois a implementação dos objetivos do agente é embutida
em comportamentos que os agentes apresentam. Esses comportamentos representam a
seqüência de ações que devem ser executadas para atingir os objetivos. Portanto, os
agentes são desenvolvidos por meio da criação de um conjunto de comportamentos que eles
devem executar.
Cada comportamento associado aos agentes não possui referência aos objetivos que
eles descrevem. Com isso, o desenvolvimento dos agentes é orientado à criação de
comportamentos ao invés de ser orientado a objetivos, conforme conceito presente nas
definições.
46
Ainda referente ao framework JADE, uma outra deficiência proporcionada pela
implementação dos comportamentos é o forte acoplamento que é criado entre o agente e
suas ações. Analisando a organização interna do agente JADE, FIG. 2.4, observa-se que os
comportamentos fazem parte da própria organização interna do agente. Como
conseqüência, o framework JADE não incentiva os desenvolvedores a reusarem as ações
durante o desenvolvimento de SMA.
Por meio da utilização da extensão WSIG, o agente é encapsulado como se fosse um
WS. Dessa forma, ele pode ser invocado como um WS normal por aplicações externas à
plataforma de agentes. Contudo, isto faz com que o agente perca uma das principais
características presentes em sua definição, a pró-atividade, uma vez que um WS, por
definição, é uma “extremidade” que deve ser invocada pelo consumidor do serviço.
A integração da arquitetura SOA a plataforma de SMA, segundo o nosso entendimento,
deve ser realizada por meio da implementação das ações dos agentes como serviço porque
isto preserva a característica de pró-atividade do agente e ainda reduz o acoplamento
existente entre o agente e a suas ações. Uma vez que o uso das ações será descrito por
meio da utilização de contratos.
O framework ASF implementa o conceito de orientação a objetivos, disponibilizando
classes que auxiliam aos desenvolvedores na criação dos objetivos associados aos agentes
e os planos que descrevem os passos necessários para atingi-los. A implementação das
ações executadas pelo agente ASF é baseada na extensão da classe Action, proposta no
modelo do agente. Portanto, a utilização das ações não é baseada na utilização de contratos
que definem a sua interface. Dessa maneira, o agente fica fortemente acoplado às suas
ações. O agente ASF implementa mecanismos que permitem ao desenvolvedor criar
agentes reativos ou agentes pró-ativos, contudo, o framework não permite que o agente
possua ambas as características, isto é, o mesmo agente não pode mesclar um
comportamento reativo e pró-ativo, com o desenvolvedor configurando o grau de reatividade
e pró-atividade desempenhada pelo agente, o que é possível com a utilização da plataforma
SOPA.
O framework SemantiCore define a organização interna do agente por meio do modelo
semântico do agente, porém, tal modelo não apresenta o conceito de objetivo com um
elemento de primeira ordem, não fornecendo uma representação direta para os objetivos que
o agente deve alcançar.
47
A maioria das plataformas não implementa de forma direta e clara o conceito do agente
orientado a objetivos. Elas se preocupam com a implementação das ações de forma
isoladas, o que acaba por criar um distanciamento com os seus objetivos, dificultando o
mapeamento direto de objetivos para os agentes. Algumas plataformas trabalham com a
utilização de planos, porém estas não apresentam um mapeamento direto entre os objetivos
e os seus respectivos planos de execução.
Os componentes que permitem a criação das ações pelos agentes, normalmente, estão
fortemente associados a estes. Isto acaba dificultando o compartilhamento das ações entre
os agentes, levando a redundância de ações pelos agentes do sistema, aumentando o
esforço necessário para o desenvolvimento do sistema e dificultando a sua manutenção.
Na maioria destas plataformas, a pró-atividade dos agentes não é muito evidenciada.
Por exemplo, no JADE este conceito é implementado por meio do controle total da thread de
execução do agente.
48
4. PLATAFORMA
ORIENTADA
A
SERVIÇOS
PARA
O
DESENVOLVIMENTO DE AGENTES PRÓ-ATIVOS
A plataforma SOPA (Service-Oriented Environment for Pro-Active Agents Development)
é uma extensão da arquitetura proposta pela FIPA cujo intuito principal é permitir que o
agente seja desenvolvido pela associação direta aos seus objetivos, que foram identificados
durante a fase de análise.
O planejamento de cada objetivo será realizado por meio da construção de planos de
execução que descreverão a seqüência das ações necessárias para que o objetivo seja
alcançado com sucesso. Estas ações não serão implementadas diretamente pelos agentes,
estando disponíveis em repositórios externos a eles. Dessa forma, a plataforma SOPA
também propõe mecanismos para que o agente possa localizar e utilizar as ações de forma
independente do domínio da aplicação.
A plataforma SOPA também propõe mecanismo para que o desenvolvedor possa
configurar o grau de pró-atividade que o agente deve apresentar, permitindo que sua
configuração seja feita diretamente pelo desenvolvedor durante a implementação do seu
agente. A partir dessa configuração o desenvolvedor pode implementar agentes com um
comportamento mais pró-ativo ou reativo.
4.1.
Características Gerais da Plataforma
4.1.1. Uso de Objetivos como Conceito de Primeira Ordem
O agente proposto pela plataforma SOPA utiliza o conceito de orientação a objetivos –
presente nas definições de agente e de SMA – como um conceito-chave para sua
implementação, propondo mecanismos que permitam a associação direta do agente ao seu
conjunto de objetivos. Por meio desta associação, o agente é implementado com foco nos
objetivos que devem ser alcançados, permitindo que o desenvolvedor se concentre no
domínio da aplicação, ao desenvolver o seu agente.
49
A plataforma SOPA propõe a configuração de cada objetivo associado ao agente por
meio da utilização de uma base interna que deve ser povoada durante a instanciação do
agente. Nesta base, o desenvolvedor deve informar as seguintes propriedades do objetivo:
prioridade, o tipo de execução e a identificação do conjunto de planos associado.
A prioridade serve para auxiliar o agente na escolha de qual objetivo ele deve alcançar e
informa o grau de importância definido para cada objetivo. A plataforma propõe a criação de
três graus de prioridade: alta, média e baixa prioridade. Os objetivos de mais alta prioridade
serão aqueles que terão uma maior probabilidade de serem os escolhidos, enquanto que os
objetivos de baixa prioridade terão uma menor probabilidade de serem escolhidos.
É importante ressaltar que a associação da prioridade não determina que os objetivos de
alta prioridade sejam escolhidos e executados antes dos demais objetivos. Apenas informa
ao agente que estes terão uma maior probabilidade de escolha em cada iteração.
O tipo de execução do objetivo define se ele deve ser perseguido de forma contínua, ou
seja, indica se é um objetivo que o agente deve perseguir repetidas vezes durante sua
execução ou se é um objetivo que deve perseguido uma única vez, até ser alcançado com
sucesso. Cada objetivo é associado a um conjunto de planos que descreve o conjunto de
ações que devem ser executadas para atingi-los com sucesso.
4.1.2. Uso da Abstração de Orientação a Serviços
Para cada objetivo associado ao agente, devem-se planejar os passos necessários para
que ele seja alcançado com sucesso. A concretização deste planejamento será feita por
meio da utilização dos planos de execução, onde cada passo descrito nos planos consiste na
definição das ações que devem ser executadas pelos agentes.
Para tanto, a plataforma SOPA propõe o uso da orientação a serviços: as ações
presentes nos planos são implementadas como componentes – serviços – cuja interface de
utilização é definida por meio de contratos. Tanto as ações quanto os contratos devem ser
armazenados externamente aos agentes. Portanto, a plataforma deve fornecer repositórios
externos aos agentes para que os contratos das ações sejam armazenados e mecanismos
que permitam aos agentes interpretarem, executarem esses contratos e realizarem a ligação
com a ação descrita nele.
50
O povoamento desses repositórios externos é de responsabilidade do desenvolvedor e
deve ser realizado durante a implementação do agente. O cadastramento deve consistir na
inclusão de uma referência simbólica para o contrato e no endereço da localização do
serviço. Para auxiliar no gerenciamento desses repositórios, a plataforma SOPA apresenta
uma ferramenta que permite ao desenvolvedor: cadastrar os contratos, alterar, excluir
cadastros anteriores, adicionar, remover repositórios externos, etc.
A localização dos contratos é uma funcionalidade que deve ser fornecida pela própria
plataforma porque ela envolve detalhes que são específicos do repositório de
armazenamento; A responsabilidade do agente é identificar as informações das ações,
contidas nos planos, e repassá-las à plataforma para que esta localize os seus contratos,
retornando ao agente uma lista contendo os contratos encontrados para a ação desejada.
Para que uma ação possa ser executada, o agente precisa interpretar seu contrato, pois
este descreve tanto a interface de utilização da ação quanto sua localização física. Portanto,
o agente proposto pela plataforma SOPA deve ser capaz de interpretar os contratos e
acessar as ações nele descritas. Dessa maneira, somente em tempo de execução é que
ocorre a ligação do agente a ação que ele deseja executar, diminuindo o acoplamento
existente.
Uma vantagem esperada, em virtude da integração com a arquitetura SOA, é a redução
do acoplamento entre os agentes e as suas ações e da inclusão do paradigma “find, bind and
execute” pelos agentes. Por meio deste, a plataforma permite a descoberta de um contrato, a
ligação e a execução da ação independente do agente específico da aplicação.
Devido à redução do acoplamento entre o agente e a ação, a plataforma incentiva o
desenvolvedor a reusar ações entre os agentes. Com isso, espera-se reduzir um pouco a
complexidade do desenvolvimento, reduzir o tempo de desenvolvimento e aumentar a
qualidade, em decorrência da utilização de ações pré-existentes.
4.1.3. Implementação da Pró-atividade
Uma vez feitas as associações – do agente a seu conjunto de objetivos e de cada
objetivo a um conjunto de planos – o agente conhece os seus objetivos e os passos
necessários para que eles sejam alcançados. Contudo, ainda falta ao agente alguma forma
de decidir qual objetivo alcançar e quando alcançá-lo. Esta característica está presente nas
51
definições de agentes e se chama pró-atividade. Porém, muitas das plataformas existentes
não a oferecem de forma direta.
A concretização destes conceitos é fornecida pela plataforma SOPA por meio da
utilização de perfis que podem ser associados aos agentes durante a sua a implementação.
Por intermédio da criação de perfis, o desenvolvedor configura se o agente deve ser mais
pró-ativo ou mais reativo, em cada iteração que ele executar. Em uma iteração pró-ativa o
agente deverá escolher o objetivo que ele deseja perseguir. Já em uma iteração reativa, ele
verifica se existe algum agente que precise de sua colaboração.
No caso de haver alguma solicitação de colaboração, ele decide se pode colaborar ou
não. Esta decisão é baseada na quantidade de colaborações que o agente está efetuando
ao analisar uma nova solicitação. Ou seja, o agente possui uma configuração interna que
determina a quantidade máxima de colaborações, por objetivo, que ele pode atender
simultaneamente.
A plataforma SOPA propõe a criação de três perfis de pró-atividade para o agente: alta,
média e baixa. Cada um destes está associado a uma probabilidade, respectivamente 90%,
50% e 10%, de escolha de como deve ser o seu comportamento durante a iteração corrente.
Para cada iteração executada pelo agente, ele decide se ela deve ser uma iteração pró-ativa
ou se deve ser uma iteração reativa, essa escolha é baseada no perfil – probabilidade –
associado ao agente. Por exemplo, um agente configurado com um grau de alta próatividade terá uma probabilidade de 90% de tentar lançar um novo objetivo a cada nova
iteração. Já um agente configurado como de baixa pró-atividade, terá uma probabilidade
elevada de verificar se algum outro agente precisa da sua colaboração, pois ele possui uma
probabilidade de 10% de apresentar um comportamento pró-ativo.
A associação da probabilidade permite que o agente apresente ambos os
comportamentos, reativo e pró-ativo, permitindo ao desenvolvedor configurar a relação entre
esses dois estados de forma fácil e rápida. Por exemplo, um agente configurado com um
grau de alta probabilidade, lançará a maioria dos seus objetivos de forma pró-ativa. Contudo,
o agente também poderá lançar um objetivo em reação a alguma solicitação externa.
Ambas as configurações, probabilidade de escolha e número máximo de colaborações,
são determinadas pelo perfil do agente escolhido. Outra configuração que faz parte do perfil
do agente é o tempo de espera em cada iteração. Este define o tempo que o agente aguarda
para iniciar uma nova iteração. Portanto, para plataforma SOPA, a pró-atividade representa o
52
comportamento por meio do qual o agente escolhe qual o objetivo ele deve buscar, isto é,
define a ordem na qual os objetivos serão lançados.
A proposta da plataforma é dividida em duas partes. A primeira parte descreve a
organização interna do agente que permite que ele seja desenvolvido a partir dos objetivos
que foram identificados durante a fase de análise. Ou seja, fornece mecanismos para que o
agente seja associado a um conjunto de objetivos; os objetivos sejam ligados aos planos de
ações; os planos sejam descritos como processos que ilustram suas ações; e os agentes
possam descobrir, conectar e executar as ações que estão externalizadas em repositórios e
descritas em seus planos.
A segunda parte propõe a criação de uma plataforma para agentes que forneça as
funcionalidades necessárias à execução dos agentes orientados a objetivos. O intuito dessa
plataforma é fornecer toda a infra-estrutura necessária, de tal forma que as ações sejam
implementadas como componentes externos; os agentes sejam capazes de encontrar as
ações; e os desenvolvedores sejam capazes de administrar (incluir, excluir e alterar) as
ações dos agentes no sistema.
4.2.
Organização Interna do Agente
Em virtude da especificação FIPA não definir uma organização interna para o agente, a
organização interna proposta nesta dissertação é uma extensão da utilizada pela
implementação JADE. O seu objetivo é definir os componentes necessários para que o
agente possa ser associado, de forma direta, a um conjunto de objetivos e implementar o
conceito de pró-atividade.
Para concretizar a associação direta de um conjunto de objetivos ao agente, a
plataforma SOPA disponibiliza mecanismos para que tal associação seja feita pelo
desenvolvedor durante a implementação do agente. Esta associação é realizada em dois
passos distintos: no corpo do agente, o desenvolvedor identifica quais objetivos ele deve
alcançar; e, por meio de um arquivo de configuração, cujo intuito é permitir ao desenvolvedor
configurar os atributos de cada objetivo, que são prioridade, tipo de execução e conjunto de
planos.
O agente SOPA, ao ser instanciado, identifica todos os objetivos associados a ele e
procura pelas demais configurações, no arquivo de configuração. Todas essas informações
53
são armazenadas em um repositório interno ao agente que será utilizado durante sua
execução para identificar as informações acerca dos seus objetivos.
A escolha de qual objetivo será lançado é baseada no atributo prioridade associado a
cada um dos objetivos do agente. Para cada nível de prioridade definido, é estabelecida uma
probabilidade de escolha para os objetivos pertencentes ao nível. Toda vez que o agente
precisar escolher um novo objetivo a ser alcançado, esta escolha segue as probabilidades
definidas para o grau de importância associado pelo desenvolvedor.
Outro atributo definido para o objetivo está relacionado ao tipo de execução que ele deve
apresentar. Este informa se o objetivo deve ser perseguido de forma continua ou se o agente
deve buscá-lo apenas uma única vez. Os objetivos que devem ser executados uma única
vez não são reintroduzidos nas suas respectivas áreas após uma execução com sucesso, já
os que devem ser executados continuamente são reintroduzidos nas respectivas áreas.
O último atributo permite associar cada objetivo a um conjunto de plano de execução. Os
planos descrevem os passos necessários para que um determinado objetivo seja alcançado,
por meio da execução de ações. As ações executadas pelos agentes da plataforma SOPA
estão localizadas fora deles. A única exceção diz respeito a ação de comunicação com os
demais agentes.
A ação que permite ao agente se comunicar com outros agentes (envio e recebimento
de mensagens ACL) é implementada pelo próprio agente porque esta é uma característica
intrínseca dele, todas as outras ações são implementadas fora do agente. Os planos devem
conter referências para os contratos das ações externas, porém, essas referências não
devem ser referências diretas às ações, e sim referências simbólicas.
As referências simbólicas para os contratos devem ser cadastradas nos repositórios de
contratos definidos pela plataforma, associando cada referência ao endereço da real
localização do contrato. Durante a análise do plano, o agente identifica as referências
simbólicas e solicita, à plataforma, a conversão de cada referência simbólica em uma lista de
endereços da real localização dos contratos. A localização do contrato não cabe ao agente,
pois essa funcionalidade está fortemente associada ao ambiente de execução. Portanto, ela
deve ser fornecida pela plataforma em que o agente reside. Isto permite que o agente fique
independente da localização do contrato que descreve a ação, uma vez que, somente em
tempo de execução é que ele terá conhecimento da localização física deste.
54
Portanto, a partir deste momento, o agente conhece a localização física do contrato,
podendo acessá-lo para realizar a sua interpretação. Cada contrato descreve a interface
abstrata necessária para a utilização de determinada ação, a sua localização física, podendo
conter a descrição de mais de uma ação. A utilização de contratos bem definidos permite que
a ligação entre o agente e a ação seja realizada em tempo de execução, reduzindo o
acoplamento entre eles.
Por meio da utilização da organização interna do agente, os detalhes necessários para
implementação desses mecanismos são ocultados dos desenvolvedores. Ou seja, o
desenvolvedor não precisa conhecer estes detalhes para poder construir um agente
específico para sua aplicação.
Dessa forma, além de permitir o desenvolvimento do agente em um nível maior de
abstração, a organização interna ainda encapsula todos os detalhes necessários ao seu uso.
A organização interna para o agente orientado a objetivos é composta pelos componentes
que são ilustrados na FIG. 4.1.
FIG. 4.1 Organização Interna proposta para o agente.
No canto inferior direito da FIG. 4.1 aparecem os componentes que permitem realizar a
associação de um conjunto de objetivos a um conjunto de planos. A base Objetivo/Plano
55
representa o repositório que permite realizar descrição de um conjunto de objetivos e a
associação de cada objetivo a um conjunto de planos.
No canto superior direito da FIG. 4.1 aparecem os componentes cujo objetivo é
implementar os mecanismos para criação do agente orientado a objetivos. A organização
interna proposta é composta pelos componentes: Base Objetivo/Plano, Coordenador,
Planejador, Analisador, Negociador e Executor.
A base Objetivo/Plano representa a base interna que permite ao agente identificar as
propriedades associadas a cada um dos seus objetivos. Esta base é povoada durante a
instanciação do agente por meio da utilização de um arquivo de configuração
O componente Coordenador é o responsável pela gerência dos objetivos associados ao
agente. Ele que deve implementar a política de escalonamento dos objetivos, ou seja, é ele
quem decide se o agente deve reagir às alterações ocorridas no ambiente ou se deve, de
forma pró-ativa, buscar um determinado objetivo.
A escolha da forma como o agente deve atuar em cada iteração deve ser baseada no
perfil que ele apresenta. A partir desse perfil, o componente Coordenador decide se a
iteração será pró-ativa ou será reativa.
A política implementada pelo Coordenador para a seleção de qual objetivo será lançado
deve permitir a busca de objetivos de forma concorrente. Dessa forma, o agente poderá
lançar vários objetivos simultâneos. Ele é o responsável por atribuir uma identificação única
para cada instância de objetivo que o agente tiver lançado.
O Coordenador também é o responsável por realizar o cadastro do agente, com os seus
respectivos objetivos, no serviço DF da plataforma e por manter esse cadastro atualizado.
Para cada novo objetivo que o Coordenador decidir buscar, ele deve criar um novo
componente Planejador.
O componente Planejador está relacionado à execução de um determinado objetivo. A
escolha de qual plano de execução será utilizado para alcançar determinado objetivo é
responsabilidade deste componente. Uma vez escolhido qual plano será instanciado, esse
componente é responsável por garantir que este não apresenta erros quanto a sua
construção e por gerenciar a sua execução. Para implementar essas funcionalidades, ele é
decomposto em três outros componentes: Analisador, Negociador e Executor.
Em SOPA, a interpretação de um plano é composta por quatro fases distintas que são
executadas seqüencialmente. A primeira delas, executada pelo componente Analisador, é a
56
responsável por identificar todos os atributos presentes nas ações definidas no plano e
realizar algumas integridades básicas referentes à linguagem utilizada para descrever os
planos de execução. Durante a identificação dos atributos das diversas ações, também será
identificada às referências simbólicas aos contratos que descrevem as ações utilizadas no
plano. Essas referências devem ser guardadas para que possam ser resolvidas pela
segunda fase.
A segunda fase, realizada pelo componente Negociador, tem como objetivo resolver as
referências simbólicas aos contratos que descrevem as ações. Essa resolução utiliza uma
funcionalidade da plataforma externa de agentes.
Uma vez que todas as referências simbólicas aos contratos tenham sido resolvidas, por
meio da identificação dos seus respectivos contratos, o componente Analisador inicia a
terceira fase da interpretação de um plano. Nesta fase, ocorre a interpretação dos contratos,
onde são identificados os elementos necessários à execução de cada ação. Para cada ação
externa é identificada a sua localização física, os argumentos e os respectivos tipos
necessários a chamada da ação.
A última fase, executada pelo componente Executor, corresponde à criação de uma
versão executável para o plano, com todas as referências simbólicas já resolvidas. O
componente Executor é o responsável por instanciar o plano a ser seguido. Ele deve
gerenciar a execução de cada ação na ordem em que ela aparece no plano. Ao término da
execução da ação, ele verifica se ocorreu algum erro. Caso a execução tenha sido finalizada
com sucesso, ele deve promover a execução da próxima ação. Caso contrário, o erro
ocorrido deve ser informado ao Coordenador.
4.2.1. O Ciclo de Vida do Agente Orientado a Objetivos
Durante sua execução, o agente passará por um conjunto de estados que representam
os diversos comportamentos que ele executa. Esses estados compõem o ciclo de vida do
agente que é ilustrado na FIG. 4.2.
Durante o processo de instanciação do agente, este se encontra em um estado
desconhecido. Uma vez o agente instanciado e os seus respectivos objetivos adicionados,
ele passa para o estado chamado de Instanciado. Este estado representa o estado em que o
agente toma a decisão de qual objetivo ele deve alcançar.
57
O agente pode decidir aguardar um intervalo de tempo pré-definido que é representado
pelo estado Bloqueado. Caso o agente não tenha nenhum objetivo a ser alcançado, ele pode
decidir encerrar a sua execução. No caso de ele receber alguma mensagem solicitando sua
colaboração ou de lançar um objetivo de forma pró-ativa esse estado muda para o chamado
Planejamento.
O estado de Planejamento representa o estado em que o agente realiza a escolha do
plano que será utilizado para alcançar determinado objetivo. Após a escolha do plano, o
agente muda para o estado chamado de Interpretação, onde é realizada a interpretação do
plano de execução. Durante esse estado, o agente pode precisar identificar as referências
simbólicas existentes, o que é feita no estado denominado de Negociação. Por último, temos
o estado chamado de Execução que representa o estado no qual o agente realiza a
execução do plano que descreve o objetivo.
58
FIG. 4.2 Ciclo de vida do Agente Orientado a Objetivos
4.3.
Plataforma de Agentes Pró-ativos
A Plataforma SOPA é o ambiente que suporta a execução do agente orientado a
objetivos. Para isso, é necessário que a plataforma forneça um conjunto de funcionalidades
que permita ao desenvolvedor se concentrar na criação do agente por meio da associação
dos seus objetivos, definidos durante as fases de análise.
A Plataforma SOPA disponibiliza os conceitos de repositório de contratos, fornece um
agente facilitador cujo objetivo é realizar a busca dos contratos que descrevem as ações e
especifica que as ações executadas pelos agentes devam ser implementadas como
serviços. Por intermédio da implementação das ações como serviços, a plataforma deve
permitir que as ações executadas pelos agentes sejam externalizadas. Dessa forma, o
59
agente não mais estará fortemente ligado às ações que ele executa, ao invés disso, ele
deverá descobrir, em tempo de execução, a localização física destas.
A plataforma propõe a adição de quatro novos componentes à arquitetura FIPA: o
agente orientado a objetivos, repositório de contratos, ações e o facilitador de contratos. O
objetivo desses componentes é fornecer a infra-estrutura necessária para que o agente
possa ser desenvolvido unicamente baseado nos objetivos que ele deve alcançar. A FIG. 4.3
exibe a plataforma proposta.
FIG. 4.3 Plataforma de Agentes Pró-Ativos
O Facilitador de Contratos (Action Discoverer, AD) é um agente que deve ser fornecido
por qualquer implementação em conformidade com a plataforma, pois ele é o responsável
por implementar os detalhes necessários à busca dos contratos das ações. A sua presença é
uma condição necessária para que a plataforma seja instanciada.
Durante a inicialização do container principal da aplicação, após instanciar os
componentes definidos na arquitetura FIPA, o AD deve ser instanciado e registrado no DF.
Após realizar o seu registro, o AD deve identificar os repositórios de contratos disponíveis
para ele realizar as suas buscas. A partir desse momento, o AD fica disponível para interagir
com os demais agentes.
60
O AD recebe do agente o nome do contrato que ele precisa para executar uma
determinada ação. De posse dessa informação, o AD deve realizar uma busca nos
repositórios de seu conhecimento. Ao término da busca, o retorno será devolvido para o
agente solicitante. O AD implementa o protocolo de interação definido pela organização
interna, mais especificamente pelo componente negociador, sobre a perspectiva do receptor
da negociação.
Por meio do uso do AD, o agente fica totalmente independente da localização física da
ação. Uma vez que, o AD encapsula os detalhes necessários a busca dos contratos. Para
negociar com o AD, basta implementar o protocolo de interação, informando o nome do
contrato desejado.
O componente chamado de Repositório de contratos é composto pelos repositórios de
contratos, pelos contratos propriamente ditos e por uma ferramenta que auxilia a gerência do
cadastramento dos contratos. Os contratos das ações são cadastrados nesses repositórios.
Na verdade, os repositórios não armazenam os contratos que descrevem as ações, e sim,
uma referência para localização física deles.
Os agentes não devem ter conhecimento a respeito dos repositórios de contratos, uma
vez que o acesso a esses repositórios deverá ser feito exclusivamente pelo AD. O acesso do
AD deverá ser apenas de consulta, não podendo alterar/excluir nenhum registro cadastrado.
A inclusão/exclusão de qualquer registro no repositório é da responsabilidade do
desenvolvedor do sistema, durante sua construção. Para facilitar a gerência dos repositórios,
a plataforma fornece uma interface gráfica que disponibilize as funcionalidades básicas,
como por exemplo: incluir, excluir e alterar.
O Repositório de Ações representa as ações que estão disponíveis para o uso do SMA.
Essas ações serão armazenadas em repositórios distribuídos pela rede. Dessa forma,
diferentes agentes podem compartilhar uma mesma ação.
Uma outra vantagem alcançada com essa abordagem é o processamento distribuído,
pois cada ação será executada na própria máquina em que se encontra o repositório.
Portanto, o agente orientado a objetivos não executa diretamente as ações, ele apenas
gerencia a execução destas. Ao término da execução, ele recebe o resultado retornado pela
ação.
61
4.4.
Instância da Plataforma Proposta
A implementação da plataforma SOPA, apresentada nesta dissertação, foi feita a partir
do framework JADE, porque este é uma implementação em conformidade com a
especificação FIPA. Já para implementar os conceitos da arquitetura SOA, foi escolhida a
tecnologia de WS por ser a mais utilizada para esse fim.
Primeiro, foi construída a Plataforma de Agentes Pró-Ativos. Para construção do
repositório de contratos WSDL, foi utilizada a tecnologia de registros UDDI (BELLWOOD et.
al., 2002). No registro UDDI são armazenados o nome do contrato WSDL e o endereço de
sua localização. A estrutura escolhida para armazenar essas informações foi a categorização
em tModels (BELLWOOD et. al., 2002). Para auxiliar no gerenciamento do repositório de
contratos UDDI foi desenvolvida uma aplicação que disponibiliza as tarefas básicas de
inclusão, exclusão e alteração de um contrato.
O AD foi desenvolvido como um agente FIPA que é instanciado automaticamente pelo
contêiner principal, junto com os demais agentes propostos pela FIPA. Durante sua criação,
ele verifica se existe pelo menos um repositório UDDI disponível para consulta. O seu
principal objetivo é fornecer o serviço de busca de contratos para os demais agentes da
plataforma.
O AD pode consultar os repositórios de contratos, porém, não lhe é permitido realizar
operações de inclusão ou exclusão neles. Portanto, somente os desenvolvedores do sistema
podem alterar, incluir e excluir contratos nos repositórios.
As ações que serão executadas pelos agentes são implementadas como WS. Dessa
maneira, sua localização pode ser qualquer extremidade acessível via rede e cujo protocolo
seja especificado no contrato da ação. Por isso, a plataforma proposta não define nenhum
tipo de repositório para as ações.
O agente orientado a objetivos foi implementado estendendo-se o agente JADE. Para
construção dos componentes da organização interna do agente orientado a objetivos foi
utilizado os comportamentos JADE. Tal escolha foi fundamentada na facilidade do
desenvolvimento, uma vez que, ao implementar os componentes internos como
comportamentos, pode-se utilizar as facilidades propostas pelo framework JADE, como por
exemplo a utilização da comunicação ACL entre as partes. A FIG. 4.4 apresenta o diagrama
de classes, com as principais classes do modelo utilizado para implementar a organização
interna do agente orientado a objetivos.
62
O conjunto de classes identificadas pelo uso do estereótipo OO ─ GOAgent, Goal, Plan,
ActivityMAS, CompositeActivityMAS, InvokeMAS, ReceiveMAS, ReplyMAS, WaitMAS,
SequenceMAS e FlowMAS ─ representa as classes que concretizam o conceito do objetivo
na organização interna, pois mostra os relacionamentos entre o agente orientado a objetivos
com os seus respectivos objetivos, os objetivos relacionados com os planos e estes com as
suas atividades.
A classe identificada pelo estereótipo CO ─ Coordinator ─ implementa o componente
Coordenador e a classe identificada pelo estereótipo PL ─ Planner ─ implementa o
componente Planejador. No canto esquerdo observam-se três classes identificadas pelo
estereótipo AN ─ LexicalAnalyser, Parser e SemanticAnalyser ─ que representam o
componente analisador. Com o uso destas classes, implementou-se o conceito definido por
um compilador, ou seja, a partir da escolha de um plano, a organização interna realiza a
análise léxica da linguagem utilizada no plano, a análise sintática e semântica. A classe
identifica pelo estereótipo NE ─ Negotiator ─ representa o componente negociador cujo
objetivo é resolver as referências simbólicas existentes no plano.
Por último, identificadas pelo estereótipo EX ─ CodeGenerating, Executor,
ActivityMASBehaviour,
CompositeActivityMASBehaviour,
InvokeMASBehaviour,
ReceiveMASBehaviour, ReplyMASBehaviour, WaitMASBehaviour, SequenceMASBehaviour
e FlowMASBehaviour, aparecem as classes que implementam o componente executor.
Essas classes foram implementadas como comportamentos JADE e representam as
atividades definidas na linguagem BPEL.
A linguagem utilizada para descrever os planos de execução foi a linguagem BPEL. De
todas as atividades definidas pela especificação BPEL, a instância desenvolvida
implementou as seguintes atividades: invoke, receive, reply, wait, sequence e flow. A
linguagem BPEL foi escolhida porque permite o desenvolvimento de um processo de
negócio por meio da composição de serviços web. Para isso, ela fornece a atividade invoke
que permite ao desenvolvedor definir os parâmetros necessários para realizar a chamada de
um serviço web.
Durante o desenvolvimento da instância da plataforma, observou-se que algumas
características existentes nesta linguagem não a tornavam a mais apropriada para descrever
os planos dos agentes. Por exemplo, pela especificação da linguagem, toda atividade reply
está associada a uma atividade receive anterior, assegurando que a atividade reply sempre
63
conhece o destinatário da sua mensagem. Mesmo assim, a linguagem BPEL foi utilizada
devido a sua facilidade em utilizar serviços web. Dessa forma, a descrição das ações
utilizadas pelos agentes foi descrita de forma direta e rápida por meio do uso desta
linguagem.
Na descrição dos planos de execução do agente orientado a objetivos, essa restrição
não é verificada porque um agente pode iniciar um plano enviando uma mensagem para
outro solicitando a sua colaboração. Por isso, a linguagem utilizada para descrever os planos
não está em conformidade com a especificação da linguagem BPEL.
O agente orientado a objetivos específico da aplicação será desenvolvido como uma
extensão do agente GOAgent presente na FIG. 4.4. Com isso, o agente da aplicação passa
a ter acesso as características propostas nessa dissertação.
64
FIG. 4.4 Modelo de classe da organização Interna do agente orientado a objetivos
65
5. ESTUDO DE CASO
Para demonstrar o funcionamento da plataforma proposta, foram desenvolvidos dois
estudos de casos: um sistema de empréstimos, presente na especificação da linguagem
BPEL: sistema Loan Approval (ANDREWS, 2003, p. 95); e um sistema de compra de livros,
utilizado como exemplo para demonstrar o funcionamento do framework JADE: sistema
Book Trading (CAIRE, 2003,p. 2-3).
5.1.
Loan Approval
Esse exemplo considera uma aplicação simples de aprovação de empréstimo cujo
objetivo é validar os empréstimos concedidos aos seus clientes. Estes enviam solicitações de
empréstimo junto com suas informações pessoais e a quantia desejada. De posse dessas
informações, a aplicação valida o pedido de empréstimo utilizando o processo ilustrado na
FIG. 5.1 (DUFTLER, CURBERA e KHALAF, 2003). O retorno do sistema informa se o
empréstimo foi concedido (“loan approved”) ou se foi rejeitado (“loan rejected”).
FIG. 5.1 Processo da aplicação Loan Approval (em inglês)
66
O processo de aprovação define dois serviços web que implementam as regras de
negócios utilizadas na validação das solicitações: loan assessor e loan approver. Este serviço
web é o responsável por validar solicitações que apresentem a quantia superior ao limite préestabelecido ou que o solicitante apresente um risco elevado. Já aquele é responsável por
validar solicitações cuja quantia seja menor que o limite.
No exemplo original, os clientes da aplicação conhecem as especificações necessárias
para realizarem a chamada do sistema de aprovação de empréstimo. Este corresponde a
um serviço web que recebe requisições de aplicações clientes e respondem com o resultado
da validação. No nosso exemplo, tanto os clientes da aplicação quanto à própria aplicação
serão modelados como agentes, possuindo objetivos distintos. O primeiro agente ─ “Loan
Requester” ─ tem como objetivo realizar um pedido de empréstimo (requestLoan) e o
segundo ─ “Loan Approver” ─ tem como objetivo validar o empréstimo solicitado pelo cliente
(validateLoan). Na FIG. 5.2 segue o diagrama de agentes, modelado pela linguagem ANote
(CHOREN e LUCENA, 2005) e uma tabela com os objetivos associados a cada um dos
agentes identificados.
FIG. 5.2 Modelo de agentes e tabela de objetivos para o sistema Loan Approval
5.1.1. Agente “Loan Requester”
O processo no qual os agentes são criados na plataforma SOPA segue os seguintes
passos:
1. Definir o conjunto de objetivos dos agentes.
2. Desenvolver os planos de ação para o alcance de cada um dos objetivos, desenvolvendo
um arquivo de associação objetivos/planos.
3. Descrever cada plano de ação por meio de um arquivo de processo, associando as
ações aos serviços web.
4. Cadastrar os contratos no sistema.
67
5. Ligar os objetivos aos agentes.
Este agente possui um único objetivo de realizar pedidos de empréstimos, chamado de
requestLoan. As propriedades desse objetivo são definidas por meio da utilização de um
arquivo de configuração XML cujo nome padrão é planDatabase.xml e que deve estar
localizado no mesmo diretório do agente, por default. Contudo, o desenvolvedor pode
especificar a utilização de outro arquivo durante a associação do objetivo ao agente.
Ao ser instanciado pela plataforma SOPA, o agente realiza a leitura desse arquivo de
configuração e cria sua base interna objetivo/plano. A FIG. 5.3 ilustra o layout do arquivo de
configuração utilizado pela agente da plataforma.
O elemento raiz desse arquivo é a tag <process> que permite a definição de um
conjunto de objetivos por meio da utilização da tag <goal>. Esta tag identifica um objetivo
específico, possuindo três atributos que representam respectivamente: o nome, a prioridade
e o tipo de execução que ele apresenta. O atributo nome representa o objetivo que foi
associado ao agente, no nosso caso é o objetivo requestLoan.
<?xml version="1.0"?>
<process>
<goal name="requestLoan" priority="0" lifecycle="0">
<plan name="requestLoanPlan">
Especificação do objetivo do agente:
requestLoan
http://localhost:8080/loanApproval/loanRequester.plan
</plan>
</goal>
</process>
Endereço do plano para
alcançar o objetivo
requestLoan
FIG. 5.3 Associação Objetivo/Plano para o agente “Loan Requester”
O atributo prioridade (priority) permite ao desenvolvedor atribuir um grau de importância
ao objetivo cujo intuito é fornecer meios para que o agente possa escolher qual objetivo deve
ser lançado. O valor desse atributo pode ser:
•
0: Representa que o objetivo é de prioridade alta (50% de probabilidade de ser o
escolhido).
•
1: Representa que o objetivo é de prioridade média (30% de probabilidade de ser o
escolhido).
68
•
2:: Representa que o objetivo é de prioridade baixa (10% de probabilidade de ser o
escolhido).
•
Somando-se os percentuais acima, verifica-se que existe uma probabilidade (10%) do
agente não escolher um dos objetivos a ele associado. Com isso, o agente, de forma próativa pode decidir não lançar um dos seus objetivos.
•
Caso o desenvolvedor forneça um valor diferente dos especificados acima, o agente
assumirá que o objetivo é de média prioridade.
Já o atributo lifecycle permite ao desenvolvedor configurar a execução do objetivo,
definindo se ele deve ser lançado continuamente ou deve ser buscado até que apresente
uma execução com sucesso. O valor 1 informa que o objetivo deve ser lançado
continuamente. Já um valor diferente de 1 informa que o objetivo deve ser lançado até que
uma execução seja alcançada com sucesso. Para a plataforma SOPA, uma execução com
sucesso significa a ausência de erros durante a execução do plano, isto é, o objetivo é
alcançado sempre que o agente consegue executar o plano sem a ocorrência de erros.
O corpo da tag <goal> é composto por um conjunto, não vazio, de tags <plan>. Esta é
responsável por identificar os planos que descrevem um determinado objetivo. Ela só
apresenta um atributo que identifica o nome do plano, atributo name. No seu corpo vem o
endereço dos planos que devem ser utilizado para atingir o objetivo. O objetivo requestLoan
é descrito por meio do plano requestLoanPlan que está disponível para acesso via o
protocolo HTTP.
Após a definição do conjunto de objetivos associados ao agente e da identificação do
conjunto de planos, deve-se descrever os passos necessários para que o agente “Loan
Requester” possa realizar pedidos de empréstimo. Na nossa aplicação, este agente deve
localizar algum outro agente cujo objetivo seja o de aprovar empréstimos, enviando uma
solicitação com os seguintes dados: nome e estado civil e a quantia a ser emprestada. Após
o envio com o pedido de empréstimo, o agente “Loan Requester” aguarda o retorno para
saber se seu pedido foi aceito ou não. Caso nenhum agente aprovador seja encontrado,
esse objetivo é executado concorrentemente com o agente.
Para auxiliar na modelagem do plano que o agente deve implementar, foi desenvolvido
um diagrama de Planejamento da linguagem ANote. Este diagrama permite descrever os
passos necessários para atingir o objetivo do agente “Loan Requester”. A FIG. 5.4 ilustra o
diagrama desenvolvido.
69
Procurar agente "Loan
Approver"
Agente não encontrado
Esperar um tempo fixo
Agente encontrado
Informar pedido de
empréstimo: nome,
estado civil e quantia
desejada
Esperar retorno
Informar resultado
FIG. 5.4 Diagrama de Planejamento para o objetivo requestLoan
Ao analisar os passos necessários para atingir o objetivo de pedir empréstimo, podem-se
identificar as seguintes ações: localizar agentes que possuam o objetivo de validar
empréstimos porque o agente “Loan Requester” precisa da colaboração destes, enviar uma
mensagem solicitando a colaboração e, por último, receber uma mensagem informando o
resultado obtido da colaboração. Portanto, as ações necessárias para atingir esse objetivo
são referentes a comunicação com outros agentes, cuja implementação é intrínseca ao
agente, logo, o plano de execução desse objetivo não define nenhuma ação implementada
como serviço.
O plano associado ao objetivo de pedir empréstimo é representado por um arquivo XML
que têm como nó raiz a tag <process>. Esta tag define os seguintes atributos:
•
name: Define o nome do plano.
•
targetNamespace: Define o namespace XML associado ao plano.
•
xmlns: Define a URL que contém a especificação da linguagem BPEL.
70
•
xmlns:NomeDocontrato: Para cada contrato utilizado no plano, o seu nome deve ser
definido como um atributo do nó raiz. A definição deste atributo representa a referência
simbólica que será utilizada para localizar o contrato que descreve a ação
correspondente.
A FIG. 5.5 ilustra a representação dos atributos supracitados no arquivo XML
correspondente ao plano de execução.
<process name="loanRequesterPlan"
targetNamespace="http://loans.br/wsdl/loanRequester"
xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
xmlns:loan="loanApprover">
FIG. 5.5 Definição do cabeçalho do plano loanResquesterPlan
No plano de execução, o desenvolvedor especifica quais objetivos devem participar do
relacionamento conversacional, pois, ao solicitar uma colaboração o agente precisa saber o
objetivo que o seu parceiro deve possuir e também qual o seu objetivo. Para que todos esses
objetivos sejam identificados no plano, o desenvolvedor deve utilizar a tag <partnerLinks>
que é composta por um conjunto de tags <partnerLink>. A tag <partnerLink> define os
seguintes atributos:
•
name: Define um nome para o relacionamento entre o agente que instancia o plano e os
seus colaboradores.
•
myGoal: Define o objetivo atribuído ao agente no relacionamento em que ele está
participando.
•
partnerGoal: Define o objetivo atribuído ao agente colaborador.
A FIG. 5.6 ilustra a representação dos relacionamentos conversacionais que o agente
pode realizar com outros.
<partnerLinks>
<partnerLink name="loanRequester"
myGoal="requestLoan"
partnerGoal="validateLoan"/>
</partnerLinks>
FIG. 5.6 Representação dos relacionamentos do agente LoanRequester
71
Após essa definição, o desenvolvedor deve informar todos os recursos que são
utilizados no plano. Para isso, ele deve utilizar a tag <variables> que é formado por um
conjunto de tags <variable>. Para cada tag <variable>, ele informa o nome do recurso e o
seu tipo. A especificação do tipo deve obedecer a seguinte sintaxe: nome do contrato:Tipo
definido no contrato. A FIG. 5.7 ilustra o trecho de código que permite definir os recursos
identificados.
<variables>
<variable
name="request"
messageType="loan:approveRequest"/>
<variable
name="response"
messageType="loan:approveResponse"/>
</variables>
FIG. 5.7 Definição dos recursos do plano LoanRequesterPlan
Após as definições acima, o desenvolvedor pode incluir as ações que descrevem os
passos para que o objetivo seja alcançado. O bloco que define as atividades deve começar
com uma atividade <sequence> ou <flow>. O primeiro permite a definição seqüencial das
ações, enquanto o segundo permite a definição concorrente das ações executadas pelo
agente.
Conforme se observa na FIG. 5.4, inicialmente o agente deve procurar pela existência de
pelo menos um agente LoanApprover e enviar uma solicitação de empréstimo para os
agentes encontrados, informando o nome do cliente, seu estado civil e a quantia desejada.
Este passos são implementados na plataforma SOPA por meio da ação reply cujo objetivo é
localizar os agentes definidos em um processo conversacional, interagir com o usuário para
identificar o conteúdo dos recursos e enviar uma mensagem solicitando a colaboração de
outros agentes. A FIG. 5.8 ilustra a definição da ação reply.
<reply partnerLink="loanRequester"
variable="request"
name="loanRequesterReply"/>
FIG. 5.8 Solicitação de colaboração do agente LoanRequester
72
Após o envio da solicitação, o plano da FIG. 5.4 descreve que o agente deve esperar
pelo retorno desta e informar o seu resultado. Para isso, a plataforma SOPA fornece a ação
receive cujo objetivo é permitir que o agente espere por uma mensagem e exiba o conteúdo
de algum recurso definido anteriormente. A FIG. 5.9 ilustra a ação receive utilizada no plano
do agente LoanResquester.
<receive partnerLink="loanRequester"
variable="response"
name="loanRequesterReceive"/>
FIG. 5.9 Espera o status da solicitação de empréstimo
Agora, é preciso cadastrar os contratos que descrevem as ações contidas nos planos a
fim de que o agente consiga resolver as referências simbólicas aos contratos. Com o objetivo
de auxiliar o desenvolvedor no gerenciamento do repositório de contratos, a implementação
da plataforma SOPA disponibiliza uma interface gráfica de cadastramento de contratos.
Para o contrato descrito anteriormente, o desenvolvedor deve realizar o cadastro do
contrato chamado loanApprover, que é especificado na tag <process> ─ atributo xmlns:loan.
Abaixo segue a FIG. 5.10 que ilustra a tela que permite ao desenvolvedor realizar o cadastro.
O desenvolvedor deve escolher o repositório, informar o nome do contrato e o seu endereço.
73
FIG. 5.10 Tela de cadastro do contrato loanApprover
Como último passo para criação do agente é necessário associar o conjunto de objetivos
que ele deve alcançar. Para isso, o desenvolvedor deve criar uma classe que estenda a
classe jade.core.GOAgent, herdando o método addGoal que permite adicionar um objetivo
ao seu agente. Outra configuração possível está relacionada ao grau de pró-atividade
apresentado pelo agente, permitindo ao desenvolvedor criar um agente mais reativo ao
ambiente ou mais pró-ativo.
Para permitir que o desenvolvedor defina qual o perfil o agente deve apresentar, é
disponibilizado o método setAgentProfile cujo parâmetro representa o perfil do agente. O
agente pode ser configurado como de alta (HIGH_PRO_ACTIVE_DEGREE), média
(MIDDLE_PRO_ACTIVE_DEGREE)
ou
baixa
(LOW_PRO_ACTIVE_DEGREE)
pró-
atividade. No caso de nenhuma configuração ser realizada, o agente assume um nível de
pró-atividade médio.
A FIG. 5.11 ilustra o código necessário para criar o agente “Loan Requester”. Observa-se
que a implementação do agente se resume a estender a classe GOAgent e utilizar o método
addGoal para realizar a ligação do agente ao seu conjunto de objetivos.
74
import jade.core.GOAgent;
public class LoanRequester extends GOAgent {
Definição do agente orientado
a objetivo
protected void setup() {
//It Defines the autonomy degree associated with this agent
setAgentProfile( GOAgent.HIGH_PRO_ACTIVE_DEGREE );
//It Adds the goal that this agent must following
addGoal( "requestLoan" );
}
Configuração do perfil do agente
Adição do objetivo ao agente:
requestLoan
}//End of LoanRequester class
FIG. 5.11 Código do agente “Loan Requester”
5.1.2. Agente “Loan Approver”
Este agente possui um único objetivo de validar a solicitação de empréstimo feita pelos
agentes descritos no item 5.1.1, tal objetivo é chamado de validateLoan. As propriedades
desse objetivo são definidas por meio do arquivo de configuração ilustrado na FIG. 5.12.
Conforme pode ser observado, o objetivo “validateLoan” apresenta o atributo lifecycle igual a
1, representando que ele deve ser lançado continuamente. Tal configuração é conseqüência
do objetivo representar uma funcionalidade que é oferecida para o sistema, ficando
disponível para os demais agentes.
<?xml version="1.0"?>
<process>
<goal name="validateLoan" priority="0" lifecycle="1">
<plan name="validateLoanPlan">
http://localhost:8080/loanApproval/loanApprover.plan
</plan>
</goal>
</process>
Especificação do objetivo do agente:
validateLoanPlan
Endereço do plano para
alcançar o objetivo
validateLoanPlan
FIG. 5.12 Associação Objetivo/Plano para o agente “Loan Approver”
75
Para cada solicitação recebida, o agente aprovador executa o processo definido na FIG.
5.1. Contudo, a implementação que será realizada pelo agente “Loan Approver” é um pouco
diferente daquela disponível em (DUFTLER, CURBERA e KHALAF, 2003). Isto ocorre
porque neste exemplo, optou-se por não desenvolver todo o conjunto de ações descrito em
(ANDREWS et al, 2003). A FIG. 5.13 ilustra como este processo será implementado pelo
agente “Loan Approver”.
Esperar solicitação de
empréstimo
Recursos de entrada são válidos
quantia >= 1000
Informar empréstimo
rejeitado
Chamar serviço
Approver
Chamar serviço
Assessor
risk != HIGH
Informar resultado
Chamar serviço
Approver
Informar
empréstimo
aprovado
Informar resultado
FIG. 5.13 Diagrama de Planejamento para o objetivo validateLoan
Analisando este plano, verifica-se que o agente deve esperar uma mensagem com a
solicitação de aprovação de empréstimo. Caso a quantia seja maior que um valor préexistente, no exemplo R$ 1.000,00, o pedido deve ser aprovado pelo serviço chamado de
Approver. Para quantias inferiores a esse valor, o pedido é analisado pelo serviço chamado
de Assessor. Neste caso, o pedido pode ser aprovado diretamente, caso o risco seja baixo,
76
ou pode necessitar a aprovação do serviço Approver. O resultado da validação é informado
ao agente solicitante.
Os dois serviços, Approver e Assessor, implementam as lógicas necessárias à
aprovação do empréstimo. Neste estudo de caso, criou-se dois serviços web que
implementam critérios de validação de empréstimos e representam as ações executadas
pelo o agente.
Após a definição do conjunto de objetivos associados ao agente e da identificação do
conjunto de planos, deve-se descrever o plano de execução para o agente “LoanApprover”.
Analisando a FIG. 5.13, observa-se a existência de três tipos de passos: Esperar o
recebimento de alguma mensagem, Informar o resultado e chamar algum serviço. Os dois
primeiros representam respectivamente as ações receive e reply presentes na plataforma
SOPA. Já o passo correspondente à chamada de um serviço, representa a definição de uma
ação que está externa ao agente e deve ser implementada com um serviço web.
Para permite que o desenvolvedor utilize as ações implementadas como WS, a
plataforma fornece a ação invoke cujo objetivo é definir a chamada de uma ação
implementada como WS. A FIG. 5.14 ilustra o uso da ação invoke de forma a permitir a
chamada dos serviços Approver e Assessor, utilizados no plano.
<invoke name="invokeApprover"
portType="loanApprover:LoanApprover"
operation="approve"
inputVariable="request"
outputVariable="approvalInfo">
</invoke>
<invoke name="invokeAssessor"
portType="loanAssessor:LoanAssessor"
operation="check"
inputVariable="request"
outputVariable="risk">
</invoke>
FIG. 5.14 Chamada de uma ação externa
Agora, é preciso cadastrar os contratos que descrevem as ações contidas no plano a fim
de que o agente consiga resolver as referências simbólicas aos contratos. O plano da FIG.
5.14 define duas referências simbólicas: loanAssessor e loanApprover que são utilizadas
77
para referenciar as varáveis utilizadas e para referenciar as ações que devem ser
executadas. A FIG. 5.15 mostra que elas foram adicionadas ao repositório de contratos.
FIG. 5.15 Referências simbólicas aos contratos do agente Loan Approver
O agente “Loan Approver” deve ser associado ao objetivo de validar empréstimo e
também deve ser definido o grau de pró-atividade que ele deve apresentar. Como o seu
objetivo é o de colaborar com outros agentes na validação de empréstimos, ele deve
apresentar um nível baixo de pró-atividade. A FIG. 5.16 demonstrar o código do agente “Loan
Approver”.
78
import jade.core.GOAgent;
public class LoanApprover extends GOAgent {
Definição do agente orientado
a objetivo
protected void setup() {
//It Defines the autonomy degree associated with this agent
setAgentProfile( GOAgent.LOW_PRO_ACTIVE_DEGREE );
//It Adds the goal that this agent must following
addGoal( "validateLoan" );
}
Configuração do perfil do agente
Adição do objetivo ao agente:
validateLoan
}//End of LoanApprover class
FIG. 5.16 Código do agente “Loan Approver”
5.2.
Sistema Book Trading
Este exemplo simples é utilizado pelo tutorial JADE para demonstrar os passos
necessários à criação dos seus agentes. A aplicação considera a criação de dois conjuntos
de agentes: um tem como objetivo comprar livros e o outro vender.
Cada agente responsável pela compra do livro recebe o título que deseja comprar como
argumento durante a sua instanciação e, periodicamente, solicita aos vendedores uma oferta.
Assim que ele recebe uma oferta, ele inicia o pedido de compra. Caso receba mais de uma
oferta, ele escolhe aquela cujo livro possui o menor preço, recusando as demais. A sua
execução é finalizada ao comprar um exemplar do livro.
Cada agente vendedor possui um catálogo interno com os livros disponíveis para venda
e os seus respectivos preços. O agente vendedor, continuamente, espera por uma
solicitação de compra. Ao receber esta, ele consulta o seu catálogo para verificar se o livro
desejado esta disponível. Caso exista pelo menos um exemplar, ele responde informando o
preço deste, do contrário, ele responde informando um preço negativo, indicando não possuir
o livro solicitado. Para o caso de possui o exemplar, o agente fica aguardando uma
solicitação com a confirmação da venda do livro. Após receber esta confirmação, o agente
tentar realizar a venda do livro, informando o resultado da transação ao solicitante.
79
No nosso exemplo, também serão criados dois agentes com objetivos distintos. O
primeiro deles, chamado de BookBuyer, terá como objetivo comprar livros (buyBooks). O
segundo, denominado BookSeller, terá como objetivo vender (sellBooks). Na FIG. 5.17
segue o diagrama de agentes, modelado pela linguagem ANote, e uma tabela com os
objetivos associados a cada um dos agentes identificados. .
FIG. 5.17 Modelo de agentes e tabela de objetivos para o sistema Book Trading
5.2.1. Agente “Book Buyer”
O agente “Book Buyer” possui o objetivo de comprar livro, chamado buyBooks. As
propriedades desse objetivo são definidas por meio do arquivo de configuração ilustrado na
FIG. 5.18. Conforme pode ser observado, o arquivo de configuração contém a associação de
vários objetivos com os seus respectivos planos. Neste exemplo, tem-se a associação do
objetivo do agente “Book Buyer” ─ buyBooks ─ ao plano buyBooksPlan, e do objetivo
referente ao agente “Book Seller” ─ sellBooks ─ ao plano sellBookPlan.
80
<?xml version="1.0"?>
<process>
<goal name="buyBooks" priority="0" lifecycle="0">
<plan name="buyBooksnPlan">
http://localhost:8080/bookTrading/buyBooks.plan
</plan>
</goal>
<goal name="sellBooks" priority="0" lifecycle="1">
<plan name="sellBookPlan">
http://localhost:8080/bookTrading/sellBooks.plan
</plan>
</goal>
</process>
Especificação do objetivo do agente:
buyBooks
Endereço do plano para alcançar o
objetivo buyBooks
Especificação do objetivo do agente:
sellBooks
Endereço do plano para alcançar o
objetivo sellBooks
FIG. 5.18 Associação Objetivo/Plano para o exemplo “BookTrading”
O agente “Book Buyer” procura no ambiente por agentes que tenham como objetivo
vender livros. Caso encontre algum agente como este objetivo, ele solicita ao usuário que
informe o título do livro que deve ser comprado, envia uma solicitação de compra para os
agentes encontrados e espera pelo retorno com a informação sobre a disponibilidade do livro.
No caso de nenhum agente ser encontrado, ele fica monitorando o ambiente até localizar
pelo menos um agente com quem possa negociar a compra do livro.
Ao receber a informação sobre a disponibilidade do livro, o agente “Book Buyer” escolhe
o livro de menor preço, caso possua mais de um vendedor disponível, confirmando a compra
deste ao vendedor que fez esta oferta e rejeitando as outras ofertas. Para o pedido de
confirmação de venda feito, ele aguarda uma confirmação informando o resultado da
transação. Portanto, observa-se que o plano associado ao objetivo comprar livro consiste em
procurar por agentes que apresentem o objetivo de vender livros, enviar uma solicitação de
compra, esperar o retorno informando a disponibilidade do livro. Caso o vendedor tenha o
livro para venda, ele escolhe o livro de menor preço, confirma a compra e espera o resultado
final da transação. A FIG. 5.19 ilustra o diagrama de Planejamento correspondente ao
objetivo buyBooks.
81
Procurar
agente
BookSeller
Agente não encontrado
Esperar um tempo fixo
Informar
título do
livro
Esperar
retorno
Chamar serviço
Escolher Menor
Preço
Informar
resultado da
transação
FIG. 5.19 Diagrama de Planejamento para o objetivo buyBook
Caso o agente “Book Buyer” encontre no ambiente mais de um vendedor disponível, ele
inicia negociações simultâneas com os vendedores, solicitando a compra do livro. Dessa
forma, o agente pode criar várias instâncias do mesmo objetivo, para negociar com cada um
dos vendedores encontrados. A criação dessas várias instâncias é independente do plano
porque é uma necessidade surgida devido aos vários parceiros existentes no ambiente, ou
seja, devido a necessidade das ações serem executadas para cada uma das partes
envolvidas na interação. Contudo, o plano deve possuir algumas ações especiais que
permitem realizar o sincronismo dessas várias instâncias, caso elas existam. Por isso, O
agente “Book Buyer” realiza a chamada de três ações especiais: unify, sync e
definePurchase. Estas três operações juntas correspondem ao passo Chamar Serviço
Menor Preço do diagrama de Planejamento da FIG. 5.19.
O primeiro desses serviços corresponde a um WS que armazena o retorno enviado pelo
agente vendedor – titulo do livro e preço – em um banco de dados. Na seqüência, aparece
uma ação – wait – que promove o sincronismo entre as possíveis instâncias do objetivo. Ou
82
seja, esta ação informa ao agente que as ações que a seguem só devem ser executadas
quando todas as instâncias, de um determinado objetivo, executarem a ação wait.
Após realizar o sincronismo entre as várias instâncias, o agente “Book Buyer” invoca um
novo WS que verifica qual livro possui o menor preço. A instância que negociou este livro
envia o pedido de compra, enquanto as demais informam o cancelamento da negociação. A
FIG. 5.20 ilustra a implementação dessas ações na plataforma SOPA.
<invoke
name="unify"
portType="unify:BookBuyer"
operation="storeNegotiationData"
inputVariable="book"
outputVariable="orderResult"/>
<wait name="sync"/>
<invoke
name="definePurchase"
portType="unify:BookBuyer"
operation="acceptBookPrice"
inputVariable="book"
outputVariable="orderResult">
</invoke>
FIG. 5.20 Conjunto de ações do plano do agente “Book Buyer”
Agora, é preciso cadastrar os contratos que descrevem as ações contidas no plano a fim
de que o agente consiga resolver as referências simbólicas aos contratos. A FIG. 5.21 ilustra
a tela que permite ao desenvolvedor realizar o cadastro.
83
FIG. 5.21 Tela de cadastro do contrato utilizado pelo agente “Book Buyer”
Para criar esse agente, o desenvolvedor deve associá-lo ao seu objetivo e configurar o
seu grau de pró-atividade. No nosso exemplo, ele será configurado com um perfil de alta próatividade porque ele deverá tomar a iniciativa na negociação durante a execução do sistema.
A FIG. 5.22 ilustra o código do agente “Book Buyer”.
import jade.core.GOAgent;
public class BookBuyerAgent extends GOAgent {
Definição do agente orientado
a objetivo
protected void setup() {
//Defines the autonomy degree associated with this agent
setAgentProfile( GOAgent.HIGH_PRO_ACTIVE_DEGREE );
//Add the goal that this agent must following
addGoal( "buyBooks" );
Configuração do perfil do agente
Adição do objetivo ao agente:
buyBooks
}
}//End of BookBuyerAgent class
FIG. 5.22 Código do agente “Book Buyer”
84
5.2.2. Agente “Book Seller”
O objetivo desse agente é vender livros. As características desse objetivo foram
definidas anteriormente, junto com o agente “Book Buyer” por meio do arquivo de
configuração ilustrado na FIG. 5.18.
Ele recebe uma solicitação na qual é informado o nome do livro que o solicitante deseja.
Se houver pelo menos um exemplar disponível, ele retorna ao solicitante uma mensagem
informando a disponibilidade do livro. Caso contrário ele recusa a solicitação feita. Uma vez
confirmada a disponibilidade, ele aguarda uma confirmação do solicitante para efetuar a
venda do livro e informa a conclusão da transação. A FIG. 5.23 mostra o diagrama de
Planejamento que descreve os passos necessários para atingir o objetivo sellBook.
Informar
"Livro não
disponível"
Recebe
solicitação
de compra
Chamar Serviço
Availability
Retornar
preço do
Exemplar livro
Esperar
confirmação
da compra
Exemplar
ainda
existe
no
Retirar
estoque exemplar do
estoque
Informar
venda do
livro
desejado
existe
Chamar
serviço Buy
Informar
"Livro não
disponível"
FIG. 5.23 Diagrama de Planejamento para o objetivo sellBook
A consulta ao catálogo para verificar se o livro informado está ou não disponível é
implementada por um serviço web ─ Availability ─ que recebe como argumento de entrada o
título do livro e retorna o valor deste, caso ele exista, do contrário, retorna um valor negativo.
A efetivação da compra também é implementada como um serviço web ─ Buy ─ que recebe
o título do livro como argumento de entrada e retorna uma mensagem com o resultado da
85
transação. Estas duas ações foram implementadas como WS e suas chamadas são
descritas por meio da utilização da ação invoke ilustrada na FIG. 5.24.
<invoke
name="availability"
portType="contractName:Amazon"
operation="isThereBook"
inputVariable="title"
outputVariable="price"/>
<invoke
name="buy"
portType="contractName:Amazon"
operation="buyBook"
inputVariable="title"
outputVariable="purchaseResult"/>
FIG. 5.24 Plano de execução do agente “Book Seller”
Para criar esse agente é necessário associá-lo ao seu objetivo e configurar o seu grau
de pró-atividade. No nosso exemplo, ele será configurado com um perfil de baixa próatividade porque ele deverá colaborar com os demais agentes por meio de uma solicitação
de compra de livro. A FIG. 5.25 ilustra o código do agente “Book Seller”.
import jade.core.GOAgent;
public class BookSellerAgent extends GOAgent {
Definição do agente orientado
a objetivo
protected void setup() {
//Defines the autonomy degree associated with this agent
setAgentProfile( GOAgent.LOW_PRO_ACTIVE_DEGREE );
//Add the goal that this agent must following
addGoal( "sellBooks" );
}
Configuração do perfil do agente
Adição do objetivo ao agente:
sellBooks
}//End of BookSellerAgent class
FIG. 5.25 Código do agente “Book Seller”
86
6. CONCLUSÕES E TRABALHOS FUTUROS
6.1.
Conclusões
O desenvolvimento de Sistemas Multi-Agentes é uma abordagem nova que utiliza a
abstração de agentes para modelagem de sistemas distribuídos e complexos. Os agentes
são definidos como entidades que são capazes de ações autônomas em busca dos seus
objetivos de projeto. Contudo, muitas das plataformas existentes não utilizam o conceito de
objetivo como elemento de primeira ordem (elemento chave) na implementação de Sistemas
Multi-Agentes, não permitem configurar o grau de pró-atividade dos agentes e criam um forte
acoplamento entre os agentes e suas ações.
A falta de uma representação para esses conceitos acaba por transferir a
responsabilidade da implementação deles para o desenvolvedor, contribuindo para que estes
conceitos fiquem misturados e espalhados juntos com a criação das ações executadas pelos
agentes. Desta forma, fica difícil identificá-los na implementação dos agentes. Além disso,
existe o forte acoplamento entre o agente e suas ações, o que dificulta o reuso e a
manutenção das ações, dificultando a evolução dos agentes.
Para resolver estes problemas, este trabalho propõe uma plataforma para o
desenvolvimento de agentes baseada nos objetivos dos agentes, que foram identificados nas
fases de análise. A plataforma oferece uma associação direta destes objetivos aos agentes e
um mecanismo que permite ao desenvolvedor, configurar o grau de pró-atividade que o
agente deve apresentar.
Esta plataforma introduz alguns conceitos definidos na Arquitetura Orientada a Serviços
(SOA) no desenvolvimento de Sistemas Multi-Agentes. Por meio dessa integração, busca-se
uma redução no acoplamento existente entre o agente e suas ações, procurando facilitar o
desenvolvimento das ações e promover o seu reuso.
Dentro deste contexto, as contribuições deste trabalho de mestrado foram as seguintes:
•
Concretização do conceito de orientação a objetivos como um elemento de primeira
ordem na plataforma de desenvolvimento de agentes.
•
Integração da abordagem baseada em agentes com a arquitetura orientada a serviços
(SOA).
87
•
Criação de mecanismos que tornam a busca dos contratos das ações independentes dos
agentes da aplicação.
•
Criação de perfis que permitam ao desenvolvedor configurar o grau de pró-atividade
desempenhada pelo agente.
Com a utilização da plataforma SOPA é possível implementar o conceito de orientação a
objetivos diretamente na plataforma de desenvolvimento, pela associação direta dos
objetivos aos seus agentes. Esta associação é alcançada pela introdução de mecanismos
que permitem ao desenvolvedor definir os objetivos que o agente deve buscar e associar
cada objetivo a um conjunto de planos que descrevem as ações necessárias a atingi-los. A
utilização dos planos permitem que os objetivos sejam especificados em um nível mais alto
de abstração, permitindo uma diminuição do distanciamento entre a modelagem do sistema
e a sua implementação.
A plataforma SOPA é uma extensão da arquitetura proposta pela FIPA e incorpora
alguns dos conceitos existentes na arquitetura SOA, permitindo a integração da abordagem
baseada em agentes com a orientação a serviços. Como conseqüência desta integração, a
plataforma SOPA propôs que as ações executadas pelos agentes sejam implementadas
como serviços cuja utilização é definida por contratos bem definidos. Para armazenar os
contratos que descrevem as ações, a plataforma propôs a utilização de repositórios externos
e uma ferramenta que auxilia o gerenciamento deste repositório pelo desenvolvedor.
Com o intuito de permitir que o agente da aplicação ficasse independente dos detalhes
necessários à busca dos contratos, a plataforma propôs um agente facilitador que realiza a
busca para o agente da aplicação, devolvendo uma lista com os endereços dos contratos
solicitados. O desenvolvedor somente precisa especificar no plano as informações da ação a
ser executada – nome do contrato que a descreve e o seu nome – para que a plataforma
consiga identificar os contratos previamente cadastrados.
A plataforma SOPA também permite que o desenvolvedor configure o comportamento
que agente orientado a objetivos deve apresentar durante a sua execução. Esta configuração
é realizada por meio da associação de um perfil ao agente durante a sua implementação,
não ficando espalhada na implementação das ações executadas por este. Dessa forma, o
desenvolvedor do agente pode definir se o agente deve apresentar um comportamento mais
pró-ativo ou mais reativo, de forma rápida e direta.
88
A realização dos estudos experimentais – desenvolvimento de dois estudos de casos –
serviu como primeira avaliação da plataforma proposta. Nos estudos, a plataforma
demonstrou os mecanismos que permitem ao usuário associar de forma direta os objetivos
de cada agente e como realizar as configurações desses objetivos. Dessa forma, cada
agente foi implementado diretamente dos objetivos identificados na leitura da especificação
do sistema.
O planejamento de cada objetivo também foi identificado pela leitura do requisito do
sistema, gerando os planos que descreviam os passos necessários para alcançá-los. As
ações desempenhadas pelos agentes, com exceção das ações de comunicação, foram
implementadas como serviços e armazenadas em repositórios externos. A utilização destas
ações foi descrita por meio de contratos que foram identificados nos planos com o uso de
referências simbólicas.
O comportamento que cada agente deve desempenhar durante sua execução é
configurado pelo desenvolvedor por meio do uso de perfis cujo objetivo é configurar se o
agente deve apresentar um comportamento pró-ativo.
Os resultados dos estudos experimentais mostraram que o uso da plataforma permitiu
desenvolver os agentes pela associação direta dos seus objetivos, com suas respectivas
configurações e pela criação dos planos de execução para cada objetivo. Dependendo da
característica do agente desenvolvido, também foi possível configurar o seu comportamento
com a utilização dos perfis que definem o grau de pró-atividade.
A criação das ações dos agentes como componentes externos, cujo uso é descrito por
meio de contratos, permite que o agente desenvolvido não possua nenhum conhecimento
acerca da ação que ele vai executar. Somente em tempo de execução ele conhece a ação e
realiza a ligação a ela. Esta característica é uma conseqüência direta do fato de a plataforma
ser orientada a serviços, o que permite a plataforma SOPA reduzir o acoplamento entre o
agente e as suas ações.
Com a redução desse acoplamento, a plataforma SOPA incentiva o desenvolvedor a
reusar ações pré-existentes em outros agentes, bastando que ele especifique no plano a
referência simbólica a ação pré-existente, pois todos os detalhes do uso da ação são
ocultados pelo uso da plataforma SOPA.
89
6.2.
Trabalhos Futuros
O trabalho apresentado nesta dissertação pode ser continuado com a realização das
seguintes atividades:
•
Definição de uma linguagem específica para descrição dos planos de execução que
contemplem as características dos SMA.
•
Permitir que o agente orientado a objetivos seja associado a novos objetivos em tempo
de execução.
•
Introdução de outros conceitos existentes na definição da abordagem orientada a
agentes, como por exemplo: papéis, crenças, etc.
A definição de uma linguagem específica para descrição dos planos se faz necessária
porque a linguagem utilizada não se mostrou a melhor para a finalidade pretendida. Uma
dificuldade encontrada na uso da linguagem BPEL foi referente a modelagem das interações
entre as partes envolvidas em uma colaboração. Para o BPEL, as partes envolvidas são
definidas em tempo de projeto, contudo, em SMA, as interações entre os agentes devem ser
flexivas e as partes envolvidas são determinadas durante a execução do sistema.
Outro fator limitante foi à falta de mecanismos na linguagem que permitissem ao
desenvolvedor do plano descrever a comunicação entre os agentes por meio da linguagem
ACL.
A plataforma SOPA propôs mecanismos que permitem ao desenvolvedor do agente
associar, em tempo de projeto, os objetivos que o agente deve buscar durante sua execução.
Um passo adiante seria permitir que o agente adquirisse novos objetivos a serem alcançados
– em tempo de execução. Um dos fatores que permite a extensão da plataforma neste
sentido é o baixo acoplamento existente entre o agente e as ações, uma vez que elas são
implementadas como componentes externos aos agentes e sua utilização ser descrita por
contratos bem definidos.
Apesar de a plataforma SOPA introduzir alguns conceitos existentes na definição de
agentes – orientação a objetivos e pró-atividade, alguns outros ainda precisam ser inseridos
na plataforma SOPA. Com isso, a implementação do sistema ficará mais próxima das
definições existentes na abordagem orientada a agentes, o que facilitará a transição deste
modelo para a implementação.
90
7. REFERÊNCIAS BIBLIOGRÁFICAS
ANDREWS, T. et. al. Business Process Execution Language for Web Services. 2003
Version 1.1. Specification, BEA Systems, IBM Corp., Microsoft Corp., SAP AG, Siebel
Systems. Disponível no site
http://www-128.ibm.com/developerworks/library/specification/ws-bpel/ em 20/01/2006
AUSTIN, D. et al. Web Services Choreography Requirements. 2004. Technical Report,
World Wide Web Consortium. Disponível no site http://www.w3.org/TR/ws-chor-reqs/
em 05/12/2005.
BELLIFEMINE, F. JADE Java Agent Development Framework and beyond. 2002.
Presentation at Agent Cities information Day 1, Lausanne, Feb. 2002
BELLIFEMINE, F. et al. JADE Programmer’s guide. 2005. Disponível no site
http://jade.cselt.it/.
BELLIFEMINE, F.; POGGI, A.; RIMASSA, G. JADE – A FIPA – compliant agent
framework. 1999. Technical report, CSELT S.p.A, in Proceedings of the Conference on
Practical Applications of Agents and Multi-Agents, pp. 97--108.
BELLWOOD, T. et. al. UDDI Version 2.03 Data Structure Reference. 2002. Specification,
Organization for the Advancement of Structured Information Standards
Disponível no site http://www.oasis-open.org/specs/index.php#uddiv2 em 05/12/2005.
Bezerra, E. Princípios de Análise e Projeto de Sistemas com UML. 8. ed. Rio de Janeiro:
Campus, 2002. 6 p. ISBN 85-352-1032-6
BLOIS, M., LUCENA, C. MULTI-AGENT SYSTEMS AND THE SEMANTIC WEB – The
SemanticCore Agent-based Abstraction Layer. In: ICEIS – International Conference
on Enterprise Information Systems, 2004, Porto. Proceedings of Sixth International
Conference on Enterprise Information Systems ICEIS 2004. Porto: INSTICC, 2004. v.4.
p.263 - 270
BOOTH, D. et al. Web Service Architecture. 2004. Technical Report, World Wide Web
Consortium. Disponível no site http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/
em 05/12/2005.
91
BRAGA, R. T. V. Um processo para construção e Instanciação de Frameworks
baseados em um Linguagem de Padrões para um Domínio Específico. 2003.
Tese de Doutorado. Instituto de Ciências Matemáticas e de Computação (ICMC/USP),
São Paulo, 2003.
BRATMAN, M. Intention, Plans, and Pratical Reason. 1987. Harvard University Press.
Cambridge, MA, USA.
CAIRE, G. JADE Tutorial – JADE Programming for Beginners. 2003 Disponível no site
http://jade.cselt.it/.
CHEONG, C.; WINIKOFF, M. Improving Flexibility and Robustness in Agent
Interactions: Extending Prometheus with Hermes. 2005. In Software Engineering for
Multi-Agent Systems IV: Research Issues and Practical Applications. Springer.
CHOREN, R., LUCENA, C. Modeling Multi-agent Systems with ANote. Journal on
Software and Systems Modeling, 4(2) (2005) 199-208.
CHRISTENSEN, E. et. al. Web Services Description Language (WSDL) 1.1. 2001.
Technical Report, World Wide Web Consortium. Disponível no site
http://www.w3.org/TR/wsdl em 05/12/2005.
DUFTLER, M.; CURBERA, F.; KHALAF, R. Business Process with BPEL4WS: Learning
BPEL4WS, Part 5 adding links and manipulating data. 2003. Disponível no site
http://www-128.ibm.com/developerworks/webservices/library/ws-bpelcol5/ em 09/12/2005.
FOUNDATION FOR INTELLIGENT PHYSICAL AGENTS. FIPA ACL Message Structure
Specification. 2001a. Technical Report XC00061, Foundation for Intelligent Physical
Agents.
FOUNDATION FOR INTELLIGENT PHYSICAL AGENTS. FIPA Agent Management
Specification. 2001b. Technical Report XC00023, Foundation for Intelligent Physical
Agents.
FOUNDATION FOR INTELLIGENT PHYSICAL AGENTS. FIPA. Communicative Act
Library Specification. 2001c.Technical Report XC00037H, Foundation for Intelligent
Physical Agents.
92
GREENWOOD, D. JADE Web Services Integration Gateway (WSIG). 2005. In Fourth
International Joint Conference on Autonomous Agents and Multiagent Systems.
HENDRICKS, M. et. al. Profissional Java Web Services. 1 ed. Rio de Janeiro: Alta Books,
2002. 12 p. ISBN 85-88745-45-3
JENNINGS, N. R. On agent-based software engineering. 1999. In Sixteenth International
Joint Conference on Artificial Intelligence. Stockholm.
JENNINGS, N. R.; WOOLDRIDGE, M. Agent-Oriented Software Engineering. 1999. In 9th
European Workshop on Modelling Autonomous Agents in a Multi-Agent World.
MCGOVERN, J. et. al. Java Web Services Architecture. Morgan Kaufmann, 2003. 831 p.
ISBN 1558609008
PELTZ, C. Web Services Orchestration: a review of emerging technologies, tools and
standards. 2003. Technical report, Hewlett-Packard Company.
POKAHR, A.; BRAUBACH, W.; LAMERSDORF, W. Implementing a BDI-Infrastructure for
Jade Agents. 2003. In Exp in Search of Innovation, vol. 3, n. 3., September 2003.
RAO, A.; GEORGEFF, M. BDI Agents: from theory to practice. 1995. V. Lesser.
Proceedings of the First International Conference on Multi-Agent Systems (ICMAS'95).
The MIT Press. Cambridge, MA, USA. 1995. pp.312-319.
RUSSELL, S.; NORVIG, P. Artificial Intelligence A Modern Approach. Prentice-Hall, Inc.
1995 ISBN 0-13-103805-2
SILVA, V. T.; CORTÉS, M. I.; LUCENA, C. J. P. An Object-Oriented Framework for
Implementing Agent Societies, MCC32/04. Technical Report, Computer Science
Department, PUC-Rio. Rio de Janeiro, Brazil, 2004.
SYCARA, K. et al. The RETSINA MAS, a Case Study. Software Engineering for Large Scale
Multi-Agent Systems: Research Issues and Practical Applications, LNCS 2603, Garcia
et al., ed., Springer-Verlag, 2003, pp. 232--250.
93
WOOLDRIDGE, M.; CIANCARINI, P. Agent-Oriented Software Engineering: The State of
the Art. In Agent-Oriented Software Engineering. Ciancarini, P. and Wooldridge, M,
editors, Springer-Verlag Lecture Notes in AI Volume 1957, 2001.
94
8. APÊNDICES
95
8.1.
APÊNDICE 1: Diagrama de Caso de Uso – Interface de Cadastro de Contratos
Cadastrar Contratos
Consultar Contratos
<<include>>
Usuário do
Sistema
Alterar/Excluir Contratos
Consultar Entrada UDDI
Criar Entrada UDDI
<<include>>
Criar Confi guração BD
Alterar/Excluir Configuração BD
Alterar/Excluir Entrada UDDI
<<include>>
Con sultar Configu raçã o BD
FIG. 8.1 Diagrama de Caso de Uso
96
8.2.
APÊNDICE 2: Diagrama de Classes – Interface de Cadastro de Contratos
P ro xyUDDI
Ca da stro Co ntra to sS e rvl e t
c om andos : H as htable = null
paginaOK : H as htable = null
paginaN OK : H as htable = null
F U N C ION ALID AD E : String = F U N C ION ALID AD E
POSIC AOIN IC IAL : Integer = 0
init()
doGet()
doPos t()
des troy ()
regis troU D D I : String = null
urlC ons ulta : String = null
urlPublic ac ao : s tring = null
us uarioU D D I : s tring = null
s enhaU D D I : String = null
prox y : U D D IProx y = null
authInf o : String = null
C adas trarC ontratos
Prox y U D D I()
s alv arR egU D D I()
c ons ultarR egU D D I()
deletarR egU D D I()
C o ns ultarC ontratos
Modif ic arC ontratos
Reg i stroUDDIB e a n
Efe tu arModif C on tr
$ ST_ref R egis troU D D I : Vec tor = null
$ ST_pos ic aoVetorC orrente : Integer = 0
Co man d oA b stra to
getQtdR egis tros U D D I()
s etPos ic aoVetorC orrente()
getN om eR egis troU D D I()
getU rlC ons ulta()
getU rlPublic ac ao()
getU s uarioU D D I()
getSenhaU D D I()
getD ef inic aoTrans porte()
getR egis troU D D I()
alterarR egis troU D D I()
ex c luirR egis troU D D I()
c arregarR egU D D I()
ex ec utarSolic itaç ãoPg()
Selec ionarModif
Mo dif ic arU D D I
Va l i d arUsu ari o
C riarR egU D D I
ex ec utarC ons ulta()
Modif ic arC onf BD
Re gi st ro UDDI
C riarC onf BD
regis troU D D I : String = null
urlC ons ulta : String = null
urlPublic ac ao : String = null
us uarioU D D I : String = null
s enhaU D D I : String = null
Co n exa oB DS i g l e ton
$ S T_c on exa oBD : C o nne ct io n = null
get C on ex a oBD ()
R egis troU D D I()
getR egis troU D D I()
getU rlC ons ulta()
getU rlPublic ac ao()
getU s uarioU D D I()
getSenhaU D D I()
A rq ui vo Co nfi g u ra ca o
c ria rArqC o nf ig ur ac ao( )
c on s ult ar C onf igurac oes ()
M sgE rro Be an
Reg i stroM sg
$ ST_ref R egis troMs g : Vec tor = null
$ ST_as s oc iac aoSim boloC odigo : H as htable = null
$ ST_nom eSim bolic oMs gC orrente : String = null
nom eSim bolic oMs g : String = null
indic adorGrav idadeMs g : String = null
m s gErro : String = null
Ms gErroBean()
getC odigoAc es s oMs g()
getIndic adorGrav idadeMs g()
getMs gErro()
getMs gErro()
s etN om eSim bolic oMs gC orrente()
R egis troMs g()
getN om eSim bolic oMs g()
getIndic adorGrav idadeMs g()
getMs gErro()
FIG. 8.2 Diagrama de classes
97
8.3.
APÊNCIDE 3: Protocolo de Interação Implementado pelo Agente AD
Para facilitar essa negociação, a organização interna define um protocolo de interação
que deve ser obedecido por ambas as partes envolvidas na negociação. Esse protocolo
deve ser implementado por meio de troca de mensagens ACL.
A FIG. 8.3 ilustra o protocolo pela perspectiva do solicitante da negociação. O receptor
processa uma solicitação REQUEST e responde a consulta informando se aceita (AGREE)
ou se rejeita (REFUSE) a solicitação. Um dos motivos para que solicitação seja recusada é a
indisponibilidade de pelo menos um repositório para realizar a busca. Caso o receptor
concorde em aceitar a solicitação, o solicitante envia o nome do contrato que deve ser
procurado, por meio de uma solicitação INFORM. O receptor, após realizar a busca do
contrato especificado, pode retornar uma resposta INFORM ou uma reposta FAILURE.
FIG. 8.3 Protocolo de Interação
98
No primeiro caso, o receptor informa que a busca foi realizada com sucesso e devolve
uma lista com os contratos localizados. Já no segundo caso, o receptor informar que não foi
possível encontrar nenhum contrato com o nome informado.
99
8.4.
APÊNCIDE 4: Planos de Execução do Sistema Loan Approval
<process name="loanRequesterPlan"
targetNamespace="http://loans.br/wsdl/loanRequester"
xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
xmlns:loan="loanApprover">
<partnerLinks>
Relacionamentos implementados pelo agente
<partnerLink name="loanRequester"
myGoal="requestLoan"
partnerGoal="validateLoan"/>
</partnerLinks>
<variables>
Variáveis utilizadas no plano
<variable
name="request"
messageType="loan:approveRequest"/>
Tipo da variável está definido no contrato
loan
<variable
name="response"
messageType="loan:approveResponse"/>
</variables>
<sequence name="loanApprovalSeq">
<reply partnerLink="loanRequester"
variable="request"
name="loanRequesterReply"/>
Tipo da variável está definido no contrato
loan
Conjunto de ações do plano
Ação1: loanRequesterReply - Localiza um agente aprovador
e envia uma mensagem solicitando a colaboração
Ação2: loanRequesterReceive - Aguarda
<receive partnerLink="loanRequester"
o retorno da solicitação
variable="response"
name="loanRequesterReceive"/>
</sequence>
</process>
FIG. 8.4 Plano de execução do agente “Loan Requester”
100
<process name="loanApproverPlan"
targetNamespace="http://loans.br/wsdl/loanApprover"
xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
xmlns:loanAssessor="loanAssessor"
xmlns:loanApprover="loanApprover">
<partnerLinks>
<partnerLink name="loanApprover"
myGoal="validateLoan"
partnerGoal="requestLoan"/>
</partnerLinks>
<variables>
Referência simbólica aos contratos
Relacionamentos implementados pelo agente
Variáveis utilizadas no plano
<variable
name="request"
messageType="loanApprover:approveRequest"/>
<variable
name="risk"
messageType="loanAssessor:checkResponse"/>
<variable
name="approvalInfo"
messageType="loanApprover:approveResponse"/>
</variables>
Conjunto de ações do plano
<flow name="startFlowActivity">
<links>
<link name="go-to-loan-assessor"/>
<link name="go-to-loan-approver"/>
<link name="go-to-loan-approverAgain"/>
<link name="go-to-loan-assessorAgain"/>
</links>
<receive
partnerLink="loanApprover"
variable="request"
name="loanApproverStartUp">
Tipo da variável está definido no contrato
loanApprover
Utilização de links para sincronização das atividades
Ação1: Aguardar solicitação de
empréstimo
<source
linkName="go-to-loan-assessor"
transitionCondition="request:in2 &lt; 1000"/>
<source
linkName="go-to-loan-approver"
transitionCondition="request:in2 &gt;= 1000"/>
</receive>
Determina qual caminho será seguido no
plano
FIG.8.5 Plano de Execução agente “Loan Approver”
101
<sequence name="sequenceApprover">
Quantia solicitada inferior ao limite definido
<target linkName="go-to-loan-approver"/>
<invoke name="invokeApprover"
portType="loanApprover:LoanApprover"
operation="approve"
inputVariable="request" outputVariable="approvalInfo">
</invoke>
<reply partnerLink="loanApprover"
variable="approvalInfo" name="loanApproverReply3">
</reply>
Ação2: Chamada do servço
web Approver
Ação3: Informa o resultado do
serviço Approver para o agente
solicitante
</sequence>
<sequence name="sequenceAssessor">
<target linkName="go-to-loan-assessor"/>
<invoke name="invokeAssessor"
portType="loanAssessor:LoanAssessor"
operation="check"
inputVariable="request" outputVariable="risk">
<source linkName="go-to-loan-approverAgain"
transitionCondition="risk == HIGH"/>
<source linkName="go-to-loan-assessorAgain"
transitionCondition="risk != HIGH"/>
</invoke>
Ação4: Chamada do servço
web Assessor
Determina qual caminho será seguido no
plano
<sequence name="sequenceAssessorAgain">
<target linkName="go-to-loan-approverAgain"/>
Ação5: Nova chamada do serviço
<invoke name="invokeApproverAssessor"
Approver
portType="loanApprover:LoanApprover"
operation="approve"
inputVariable="request" outputVariable="approvalInfo">
</invoke>
<reply partnerLink="loanApprover"
variable="approvalInfo" name="loanApproverReply1">
</reply>
Ação6: Retorno do serviço
Approver
</sequence>
<reply partnerLink="loanApprover"
variable="risk"
name="loanApproverReply2">
<target linkName="go-to-loan-assessorAgain"/>
</reply>
Ação7: Retorno do serviço
Approver
</sequence>
</flow>
</process>
FIG. 8.6 Plano de Execução agente “Loan Approver” (Conitnuação)
102
8.5.
APÊNCIDE 5: Planos de Execução do Sistema Book Trading
<process name="buyerPlan"
targetNamespace="http://loans.br/wsdl/loanApprover"
xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
xmlns:contractName="amazon"
xmlns:unify="bookBuyer">
Referência simbólica ao contrato
<partnerLinks>
<partnerLink name="Buyer"
Relacionamentos implementados pelo agente
myGoal="buyBooks"
partnerGoal="sellBooks"/>
</partnerLinks>
<variables>
<variable
name="book"
messageType="unify:storeNegotiationDataRequest"/>
<variable
name="orderResult"
messageType="unify:storeNegotiationDataResponse"/>
Tipo da variável está definido nos contratos
unify e contractName
<variable
name="purchaseResult"
messageType="contractName:buyBookResponse"/>
</variables>
<flow name="BookBuyer">
<links>
<link name="acceptLink"/>
<link name="buyerLink"/>
<link name="rejectLink"/>
</links>
<sequence name="Requester">
<reply
partnerLink="Buyer"
variable="book.in0"
name="BookRequester"/>
Definição de links para
realizar a sincronização
Ação1: BookRequester - Localiza os
vendedores e inicia a negociação
FIG. 8.7 Plano de execução do agente “Book Buyer”
103
<receive
partnerLink="Buyer"
variable="book.in1"
name="AvailabilityReceiver">
Ação2: AvailabilityReceiver - Aguarda o
preço do livro
<source linkName="acceptLink" transitionCondition="book.in1 > 0"/>
</receive>
</sequence>
Informa se o livro está disponível:
preço (book.in1) > 0
<sequence name="Sequence1">
<target linkName="acceptLink"/>
<invoke
name="unify"
portType="unify:BookBuyer"
operation="storeNegotiationData"
inputVariable="book"
outputVariable="orderResult"/>
<wait name="sync"/>
Ação3: unify - Armazena as cotações do
livro
Ação4: sync - Sincronização entre as
instâncias
<invoke
name="definePurchase"
portType="unify:BookBuyer"
operation="acceptBookPrice"
inputVariable="book"
outputVariable="orderResult">
Ação3: definePurchase - Implementa
critérios para escolha do livro
<source
linkName="buyerLink"
transitionCondition="orderResult == true"/>
Define que caminho seguir
<source
linkName="rejectLink"
transitionCondition="orderResult == false"/>
</invoke>
FIG. 8.8 Plano de execução do agente “Book Buyer”(Continuação)
104
<flow>
<sequence name="Sequence2">
<target linkName="buyerLink"/>
<reply
partnerLink="Buyer"
variable="orderResult"
name="OrderRequester2"/>
<receive
partnerLink="Buyer"
variable="purchaseResult"
name="OrderResult2"
displayOutput="yes"/>
</sequence>
Ação6: OrderRequester2 - Confirma pedido
de compra
Ação7: OrderResult2 - Espera confirmação
da venda
<sequence name="Sequence3">
<target linkName="rejectLink"/>
<reply
partnerLink="Buyer"
variable="orderResult"
name="OrderRequester3"/>
</sequence>
</flow>
</sequence>
Ação8: OrderRequester3 - Informa o
cancelamento do pedido
</flow>
</process>
FIG. 8.9 Plano de execução do agente “Book Buyer”(Continuação)
105
<process name="amazonPlan"
targetNamespace="http://loans.br/wsdl/loanRequester"
xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
xmlns:contractName="amazon"
Referência simbólica aos contratos
xmlns:unify="bookBuyer">
<partnerLinks>
<partnerLink name="AmazonBookSeller"
myGoal="sellBooks"
partnerGoal="buyBooks"/>
</partnerLinks>
Relacionamentos implementados pelo agente
<variables>
<variable
name="title"
messageType="contractName:isThereBookRequest"/>
<variable
name="price"
messageType="contractName:isThereBookResponse"/>
Tipo da variável está definido no contrato
contractName
<variable
name="purchaseResult"
messageType="contractName:buyBookResponse"/>
<variable
name="orderResult"
messageType="unify:storeNegotiationDataResponse"/>
</variables>
<flow name="BookSeller">
<links>
<link name="orderLink"/>
<link name="buyBookLink"/>
<link name="rejectPurchaseLink"/>
</links>
Tipo da variável está definido no contrato
unify
Utilização de links para sincronização das ações
FIG. 8.10 Plano de execução do agente “Book Seller”
106
<sequence name="Receiver">
<receive
partnerLink="AmazonBookSeller"
variable="title"
name="OrderReceiver"/>
Ação1: Aguarda pedido de compra
<invoke
name="availability"
portType="contractName:Amazon"
operation="isThereBook"
inputVariable="title" outputVariable="price"/>
<reply
partnerLink="AmazonBookSeller"
variable="price"
name="availabilitySender">
Ação2: isThereBook - Verifica se o
livro está disponível:
Ação3: Informa se o livro está
diposnível (price > 0)
<source linkName="orderLink" transitionCondition="price > 0"/>
</reply>
</sequence>
<sequence name="OrderSeq">
<target linkName="orderLink"/>
<receive
partnerLink="AmazonBookSeller"
variable="orderResult" name="OrderReceiver1">
Ação4: Agurda confirmação do pedido
<source linkName="buyBookLink" transitionCondition="orderResult == true"/>
</receive>
<sequence name="sequence2">
<target linkName="buyBookLink"/>
<invoke
name="buy"
portType="contractName:Amazon"
operation="buyBook"
inputVariable="title"
outputVariable="purchaseResult"/>
<reply
partnerLink="AmazonBookSeller"
variable="purchaseResult"
name="availabilitySender1"/>
</sequence>
Ação5: buyBook - realiza a venda do
livro
Ação6: Informa o resultado da
transação
</sequence>
</flow>
</process>
FIG. 8.11 Plano de execução do agente “Book Seller” (Continuação)
107