Ferramentas Utilizadas

Plataforma de Agentes JADE

A arquitetura da plataforma JADE é baseada na coexistência de várias JVM (Java Virtual Machine) podendo ser distribuída por diversas máquinas independente de sistema operacional que cada uma utiliza. Na Figura 5.1, nós temos uma visão distribuída da plataforma de agentes JADE dividida em 3 hosts.

Figura 5.1: Plataforma de Agentes JADE

Em cada host temos uma JVM, JRE 1.4 (Java Run-time Enviroment, versão 1.4) para enfatizar o conceito de independência de plataforma. Em cada JVM temos basicamente um container de agentes que fornece um ambiente completo para execução destes agentes, além de permitir que vários agentes (cada agente é representado na Figura 5.1 pelo quadro Agente de Aplicação) possam rodar concorrentemente no mesmo processador (host). Assim, durante a execução, deve existir uma JVM por processador, sendo possível vários agentes por JVM. A comunicação entre JVMs é feita através de RMI (Remote Method Invocation) de Java.

O JADE Main-Container, localizado no Host 1 da Figura 5.1, é o container onde se encontra o AMS (Agent Management System), o DF (Directory Facilitator) e o registro

RMI (Remote Method Invocation Registry). Esse registro RMI nada mais é que um servidor de nomes que Java usa para registrar e recuperar referências a objetos através do nome. Ou seja, é o meio que JADE usa em Java para manter as referências aos outros containers de agentes que se conectam a plataforma. Os outros containers de agentes conectam ao JADE Main-Container fazendo com que o desenvolvedor fique abstraído da separação física dos hosts, caso exista, ou das diferenças de plataformas dos quais cada host possa ter. Essa abstração é ilustrada na Figura 5.1, na parte central, na qual a plataforma JADE integra todos os três hosts atuando como um elo de ligação e provendo um completo ambiente de execução para qualquer conjunto de agentes JADE.

Um agente JADE funciona como uma “thread” que emprega múltiplas tarefas ou comportamentos e conversações simultâneas. Esse agente JADE é implementado como uma classe Java chamada Agent.

Do ponto de vista do programador, um agente JADE é simplesmente uma instância da classe Agent, no qual os desenvolvedores deverão escrever seus próprios agentes como subclasses de Agent, adicionando comportamentos específicos de acordo com a necessidade e objetivo da aplicação, através de um conjunto básico de métodos. A Figura 5.2 apresenta um fragmento das duas principais classes que dão suporte na criação de um Agente JADE.

Agent Agent Agent Agent -setup() AgentA AgentAAgentA AgentA Behaviour BehaviourBehaviour Behaviour -action() -done() BehaviourA BehaviourA BehaviourA BehaviourA

Figura 5.2: Fragmento das Classes de um Agente JADE

Cada serviço/funcionalidade de um agente deve ser implementado como um ou mais comportamentos. A abstração de comportamento do modelo do agente de JADE permite a integração de softwares externos para enriquecer a arquitetura do agente.

Todo e qualquer comportamento de um agente JADE é na verdade uma subclasse da classe Behaviour. A Classe Behaviour é uma classe abstrata do JADE que tem como finalidade provê a estrutura de comportamentos para os agentes JADE.

O desenvolvedor que pretende implementar um comportamento deve escrever uma ou mais subclasses Behaviour, instanciá-las e adicioná-las ao agente.

No nosso protótipo, nós utilizamos o JADE versão 3.214.

Systinet Developer for Eclipse 6.0

Systinet Developer for Eclipse é um plug-in, um módulo auto-contido que se acopla ao IDE do Eclipse. Systinet Developer for Eclipse permite ao desenvolvedor criar, testar, disponibilizar e gerenciar aplicações baseadas em Web service seguindo os padrões e regras do IDE Eclipse.

O desenvolvimento de Web services usando Systinet Developer for Eclipse é semelhante ao desenvolvimento de uma classe Java qualquer, conforme podemos ver na Figura 5.3.

Figura 5.3: Tela de Novo Projeto do Eclipse.

Junto com o plug-in da Systinet é fornecido um Systinet Server for Java. Um servidor não seguro, por default, utilizado para o deploy e testes dos Web services criados.

Quando o desenvolvimento de um Web service é finalizado, o desenvolvedor pode registrar seus serviços no UDDI registry.

Systinet Developer for Eclipse permite criar clientes que remotamente chamam os serviços disponibilizados em um servidor. A ferramenta permite fazer o debug remoto e também capturar mensagens SOAP passadas entre as aplicações cliente e servidor.

Systinet Developer for Eclipse possui como características principais:

• Geração automática do WSDL a partir de Classes Java e geração de Classes Java a partir de arquivos WSDL;

• SOAP Spy: uma ferramenta que captura mensagens SOAP entre o cliente e o servidor;

• Systinet Server for Java um servidor que dá suporte ao gerenciamento e deploy dos Web services criados;

• UDDI integration: suporta as especificações do UDDI versão 2 e 3.

Systinet Developer for Eclipse versão 6.0 suporta WS-I através do Web services Interoperability Compliance Check. Para fazer uso de WS-I Compliance Checking, deve-se fazer download do Systinet WS-I Validator Plug-in.

Systinet Developer for Eclipse através do Systinet Server for Java provê suporte a vários mecanismos de segurança, tal como SSL (Secure Socket Layer) com autenticação HTTPBasic. Usando a característica de segurança avançada do Systinet Server for Java, pode-se:

• Criar e rodar um Systinet Server for Java em modo seguro; • Criar e fazer o deploy de um Web service seguro;

• Criar um usuário e dar permissões a ele; • Criar um cliente seguro.

Conforme a Figura 5.4, podemos observar um servidor Systinet Server for Java não seguro e um servidor Systinet Server for Java seguro disponíveis para utilização pelo desenvolvedor.

O Systinet Developer for Eclipse versão 6.0 pode ser obtido no site da Systinet15.

MDR Browser for NetBeans IDE 3.5.1

O MDR Browser for NetBeans IDE 3.5.1 foi coberto de forma introdutória, na explicação relacionada ao seu uso no desenvolvimento dos NIDIA Profiles, no Capítulo 4. Reafirmamos aqui a importância de sua utilização e suas principais características que definem o “porquê” da sua utilização.

O MDR implementa o padrão MOF (Meta Object Facility) da OMG (Object Management Group). O MDR é baseado em padrões industriais definida pela OMG e JCP (Java Community Process). O MDR é integrado à Plataforma de Ferramentas do NetBeans, e contém a implementação de um repositório MOF incluindo um mecanismo de armazenamento persistente para metadados. A interface do repositório MOF é baseada no JMI (Java Metadata Interface). O MDR também define características que ajudam a incorporá-lo no IDE NetBeans (exemplo, mecanismo de notificação de eventos). O MDR é mais que uma infra-estrutura de um projeto, conforme o apresentado no Capitulo 4. Para apresentar a funcionalidade de um MDR, é usualmente necessário escrever um módulo que use o MDR.

Toda a documentação técnica, assim como o download do MDR Browser for NetBeans IDE 3.5.1 estão disponíveis no site da NetBeans16.