UNIVERSIDADE FEDERAL DO RIO GRANDE DO SULINSTITUTO DE INFORMÁTICA

CURSO DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

Um Estudo sobre Mobili dade

em Sistemas Distr ibuídos

por

DÉBORA NICE FERRARI

T.I. 780 CPGCC-UFRGS

Trabalho Individual II

Prof. Dr. Cláudio Fernando Resin GeyerOrientador

Porto Alegre, fevereiro de 1999

2

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL

Reitora: Profa. Wrana Panizzi

Pró-Reitora de Pós-graduação: Profa. Lorena Holzmann da Silva

Diretor do instituto de Informática: Phili pe Oliver Navaux

Coordenador do CPGCC: Carla Freitas

Bibliotecária-Chefe do Instituto de Informática: Zita Prates de Oliveira

3

Sumário

SUMÁRIO...................................................................................................................................................3

LISTA DE FIGURAS.................................................................................................................................4

LISTA DE TABELAS................................................................................................................................5

RESUMO ....................................................................................................................................................6

ABSTRACT ................................................................................................................................................6

1 INTRODUÇÃO.................................................................................................................................7

1.1 TEMA ..............................................................................................................................................71.2 MOTIVAÇÃO....................................................................................................................................71.3 OBJETIVOS ......................................................................................................................................91.4 ESTRUTURA DO TEXTO ...................................................................................................................9

2 MOBILIDADE................................................................................................................................10

2.1 CONCEITOS ...................................................................................................................................102.2 MECANISMOS................................................................................................................................112.3 PARADIGMAS PARA MOBILIDADE...................................................................................................142.3.1 Avaliação Remota.........................................................................................................................152.3.2 Código em Demanda....................................................................................................................152.3.3 Agentes Móveis.............................................................................................................................162.4 CONCLUSÕES ................................................................................................................................16

3 MOBILIDADE EM OBJETOS E AGENTES..............................................................................17

3.1 PARADIGMA ORIENTADO À OBJETOS ............................................................................................173.2 PARADIGMA ORIENTADO A AGENTES............................................................................................183.3 AGENTES MÓVEIS.........................................................................................................................203.4 CONCLUSÕES ................................................................................................................................23

4 TECNOLOGIAS PARA SUPORTE À MOBILIDADE..............................................................24

4.1 FERRAMENTAS PARA SUPORTE À MOBILIDADE ..............................................................................244.1.1 Java ..............................................................................................................................................244.1.2 Obliq.............................................................................................................................................254.1.3 Oz Distribuído..............................................................................................................................264.1.4 CORBA.........................................................................................................................................274.2 AMBIENTES QUE PERMITEM EXPLORAR MOBILIDADE ....................................................................304.2.1 Voyager ........................................................................................................................................304.2.2 Aglets............................................................................................................................................334.2.3 Concordia.....................................................................................................................................354.3 APLICAÇÕES..................................................................................................................................374.4 CONCLUSÕES ................................................................................................................................38

5 ANÁLISE COMPARATIVA DAS TECNOLOGIAS QUE SUPORTAM M OBILIDADE .....40

5.1 ANÁLISE COMPARATIVA DAS FERRAMENTAS.................................................................................405.2 CONCLUSÕES ................................................................................................................................44

6 CONCLUSÃO .................................................................................................................................45

BIBLIOGRAFIA ......................................................................................................................................47

4

Lista de Figuras

FIGURA 2.1 - Mecanismos de Mobili dade 13

FIGURA 4.1 - Arquitetura de Gerenciamento de Objetos (OMA) 29

FIGURA 4.2 - Objeto Voyager 32

FIGURA 4.3 - Criação de um programa Voyager 32

FIGURA 4.5 - Arquitetura do Concordia 35

5

Lista de Tabelas

TABELA 1 - Ferramentas para suporte à mobili dade 42

TABELA 2 - Ambientes para explorar mobili dade 44

6

ResumoO número de aplicações distribuídas criadas para serem usadas na Internet aumentouconsideravelmente nos últimos anos. Uma das mais complexas questões nestasaplicações diz respeito à mobili dade das entidades envolvidas na computaçãodistribuída. Neste texto define-se mobili dade como a capacidade das entidadescomputacional deslocar-se de um ambiente para outro, através do sistema distribuído.

Os estudos sobre mobili dade intensificaram-se com o uso em grande escala da Internet.Atualmente, a maioria das aplicações de mobili dade são desenvolvidas utili zando oubaseando-se nos paradigmas de orientação a objetos ou de agentes. Pode-se observarque estes dois paradigmas, estão cada vez mais presentes no desenvolvimento deaplicações para Internet.

Considerando os aspectos acima mencionados e o interesse crescente da comunidadecientífica com relação à mobili dade, este trabalho procura estudar aspectos referente àmobili dade em sistemas distribuídos envolvendo agentes e objetos. Neste texto sãoabordados assuntos importantes como os fundamentos que envolvem os estudos emmobili dade, resultados dos estudos envolvendo mobili dade em objetos e agentes,tecnologias e aplicações para suporte à mobili dade. Apresenta-se também uma análisecomparativa referente à mobili dade dos sistemas distribuídos apresentados nestetrabalho.

Palavras-chave: Orientação a Objetos, Agentes Móveis, Mobili dade, SistemasDistribuídos.

Abstract In the last few years, the number of Internet-based distributed applications increasedmeaningfully. One of the most complex issues involving these applications are relatedto entity mobilit y. This text defines mobilit y as the capacity of an computational entityto relocate itself from an environment to another one, through the distributed system.

Research on mobilit y had been intensified with the Internet large-scale use. Currently,the majority of mobilit y applications is developed using or being based onobject oriented or agents paradigms. Note that these two paradigms are even morepresent in the development of applications for Internet.

Considering the aspects mentioned above and the scientific community increasinginterest with relation to mobilit y, in this work are presented mobilit y aspects indistributed systems involving agents and objects. These aspects include: thefundamental concepts of mobilit y research, results of studies involving mobilit y inobjects and agents, technologies and applications for mobilit y support. An comparativeanalysis related to mobilit y in distributed systems is also presented in this work.

Keyword: Objects, Mobile Agents, Mobilit y, Distributed Systems.

7

1 Introdução

1.1 Tema

O paradigma orientado a objetos e o paradigma de agentes são interesses constantes dacomunidade científica, principalmente em ambientes distribuídos. Sendo assim,surgiram modelos para computação distribuída de objetos e agentes. Uma das maiscomplicadas questões envolvendo ambientes distribuídos com estas características dizrespeito à mobili dade nesses dois paradigmas. O texto [GLA 98] define mobili dadecomo a habili dade de mover-se independentemente de um dispositivo para outro atravésda rede. Como é visto no capítulo 2, vários conceitos sobre mobili dade são encontradosna literatura. O tema deste trabalho é o estudo da mobili dade em sistemas distribuídos,principalmente envolvendo objetos e agentes.

1.2 Motivação

A rápida disseminação de microcomputadores e estações de trabalho, o aumento nassuas capacidades de processamento, e o surgimento de redes de comunicação comgrande largura de banda, têm levado ao desenvolvimento cada vez maior de aplicaçõesdistribuídas. Os sistemas distribuídos apresentam várias características que são objetosde constante pesquisa na busca de soluções, tais como: afastamento, concorrência,ausência de estado global, ocorrência de falhas parciais, assincronismo,heterogeneidade, autonomia e mobili dade.

Diversos modelos de arquitetura distribuída têm sido desenvolvidos com o objetivo deoferecer conceitos que auxili em o tratamento das características de distribuição citadasacima. A característica de heterogeneidade, presente em grande parte destes modelos,impõe a necessidade de especificações abertas, com interfaces padronizadas e públicas,levando ao desenvolvimento de middlewares abertos.

Um middleware é uma camada de software, residente acima do sistema operacional e dacamada de comunicação, que oferece abstrações de alto nível, com objetivo de facilit ar aprogramação distribuída. As abstrações oferecidas fornecem uma visão uniforme nautili zação de recursos heterogêneos existentes nas camadas de sistema operacional eredes[OMG 95].

Ambientes de sistemas abertos permitem aos usuários escolherem entre um grupo decomputadores e tecnologias, aqueles que se adequam a suas necessidades. Essessistemas oferecem também uma crescente interoperabili dade, escalabili dade eportabili dade. A interoperabili dade permite que sistemas diferentes convivam juntos. Jáa portabili dade permite que um software desenvolvido em uma plataforma possaexecutar em outra com adaptações mínimas. A escalabili dade permite que novosrecursos, tanto hardware quanto software, sejam adicionados ao sistema a medida quehá necessidade de novos recursos ou de aumento do poder de processamento.

Juntamente com estes adventos quanto aos sistemas distribuídos, surgiram várias frentesde pesquisas para que as organizações pudessem explorar ao máximo os sistemas

8

distribuídos. Dentre estas linhas de pesquisa, este texto destaca à mobili dade emsistemas distribuídos como sendo a principal motivação para este trabalho. O estudosobre mobili dade abrange tanto aspectos conceituais, quanto sistemas e linguagens.

A orientação a objetos tornou-se um dos principais padrões no desenvolvimento desistemas. As linguagens orientadas a objeto tentam propor a diminuição da distânciasemântica existente entre a modelagem computacional e o mundo real. Neste sentido,surgem os objetos e suas diversas características (herança, polimorfismo,encapsulamento, etc). Desta forma, a orientação a objetos tenta alcançar um nível deabstração que aproxima a programação de computadores à forma usual do homeminteragir com o mundo.

Da mesma forma, nos últimos anos vem crescendo o interesse dos cientistas dacomputação pelo paradigma orientado a agentes. O desenvolvimento orientado a agentespossui uma forte relação com o desenvolvimento orientado a objetos. O conceito deagentes introduz consciência no universo inanimado dos objetos. Esta é uma dascontribuições do paradigma orientado a agentes [BAR 98].

Tanto objetos como agentes são amplamente usados pela comunidade científica emambientes distribuídos. Sendo assim, surgiram modelos para computação distribuída deobjetos e agentes. Um dos fatores principais nestes ambientes diz respeito à mobili dadedestas entidades.

Os estudos sobre mobili dade intensificaram-se com o uso em grande escala da Internet.Embora à mobili dade não seja uma concepção nova, pois redes locais já usam umaformas de mobili dade como migração, a Internet trouxe a possibili dade de explorarmobili dade através de redes heterogêneas, conectadas por diferentes links decomunicação e distantes uma das outras.

Atualmente, a maioria das aplicações são desenvolvidas utili zando ou baseando-se naorientação a objetos. Da mesma forma, várias aplicações, principalmente na área deInformática na Educação e Inteligência Artificial, são desenvolvidas usando comoentidade base o agente. O que pode-se observar é que estas duas entidades, objetos eagentes, estão cada vez mais presentes no desenvolvimento de aplicações para seremusadas na Internet. Talvez o que tenha auxili ado muito para que isto acontecesse é o usocada vez maior da linguagem Java [SUN 96], como linguagem de programação destasaplicações.

É importante observar que a exploração da mobili dade envolve muito a questão dalocalização. Uma premissa básica é que o usuário não necessita saber, se assim oquiser, onde a sua computação está sendo desenvolvida, pois a aplicação deve abstrairaspectos de localização do usuário. Outra questão importante em mobili dade é asegurança. Como a computação é distribuída através da rede, a integridade destacomputação deve ser preservada. No desenvolvimento de aplicações que suportemmobili dade, a tolerância a falhas e segurança da computação deve sempre estar presente.

Além destes aspectos, à mobili dade traz novos desafios ao desenvolvimento deaplicações distribuídas, como pensar à mobili dade durante o projeto de software. Parasuportar mobili dade de forma transparente para o usuário, a noção de ambientecomputacional deve estar presente. Este ambiente será elemento principal no suporte àmobili dade das entidades envolvidas.

9

Considerando os aspectos acima mencionados e o interesse crescente da comunidadecientífica com relação à mobili dade em ambientes distribuídos, este trabalho procuracompreender o estado da arte e os problemas relacionados à mobili dade em sistemasdistribuídos.

1.3 Objetivos

O objetivo geral deste trabalho consiste em estudar os aspectos relacionados àmobili dade de objetos e agentes em ambientes distribuídos.

Como objetivos específicos podem ser destacados:

• Pesquisar conceitos relacionados à mobili dade;

• Pesquisar o estado da arte relacionado à mobili dade em sistemas distribuídos,em especial envolvendo objetos e agentes;

• Estudar tecnologias para o desenvolvimento de aplicações que suportemmobili dade;

• Identificar características necessárias para que uma tecnologia de apoio aodesenvolvimento de aplicações que suportem mobili dade.

1.4 Estrutura do Texto

Este texto é composto de seis capítulos. O capítulo 2 descreve os fundamentos queenvolvem os estudos em mobili dade. O capítulo 3 apresenta o resultado dos estudosenvolvendo mobili dade em sistemas distribuídos. Além disso, será apresentado,brevemente, os fundamentos dos paradigmas orientado a agentes e orientado a objetos.No capítulo 4 são apresentadas algumas tecnologias e aplicações para suporte àmobili dade. Merece destaque neste capítulo Voyager [OBJ 97] [OBJ 98]. No capítulo 5é feita uma comparação referente à mobili dade em sistemas distribuídos apresentadasneste trabalho. Finalmente, o capítulo 6 contém as conclusões deste trabalho.

10

2 Mobili dade

Este capítulo descreve os fundamentos que envolvem os estudos de mobili dade. Asseções contêm os conceitos necessários para compreender o universo que envolve asaplicações que utili zam mobili dade. A seção 2.1 analisa conceitos relacionados àmobili dade conforme vários autores. A seção 2.2 descreve os mecanismos que permitemexplorar mobili dade. A seção 2.3 explora aspectos relacionados aos paradigmas queexploram mobili dade. Finalmente, a Seção 2.4 faz uma síntese das demais seçõesconcluindo o capítulo.

2.1 Conceitos

Por ser uma área de pesquisa relativamente nova, as pesquisas que envolvemmobili dade conceituam este termo de várias formas. A maioria refere-se à mobili dadeatravés do termos código móvel (mobile code) [FUG 98] [CAR 97] [THO 97] [CUG96] e agentes móveis (mobile agent) [DÖM 97] [CHE 96] [KNA 96] . Estes termos sãoconceituados de diferentes formas por diferentes pesquisadores:

• Mobili dade é a habili dade de mover-se independentemente de um dispositivo paraoutro através da rede [GLA 98];

• Código móvel pode ser definido como a capacidade de dinamicamente trocar asligações entre os fragmentos de código e a localização onde o código é executado[CUG 98] [FUG 98] [CAR 97];

• Código móvel é um software que viaja através de redes heterogêneas, atravessandovários domínios, sendo que é automaticamente executado quando chega em seudestino [THO 97];

• Agentes móveis são programas que podem ser disparados de um computador clientee transportado para um computador remoto para ser executado [CHE 96];

• Agentes móveis são programas que podem se mover através de uma rede decomputadores conforme queiram seus usuários [DÖM 96];

• Agentes móveis são programas “ inteligentes” que podem ser transmitidos entre osdiversos computadores de um sistema distribuído [KNA 96].

Observando os itens acima, pode-se notar um elemento presente em todos os conceitos:o deslocamento das entidades envolvidas (objetos ou agentes). Sendo assim, pode-sedizer que mobili dade é a ca pacidade das entidades envolvidas na computaçãodeslocarem-se através de um sistema distribuído.

Mobili dade não é uma concepção nova, embora sua aplicação na Internet seja. Umexemplo é a migração, pois migrar processos ou objetos é uma forma de mobili dade,que já é usada em pequena escala. As pesquisas em mobili dade vem crescendo muitoatualmente devido principalmente a possibili dade de explorar código móvel em grandeescala através da Internet, onde as redes interligadas são heterogêneas e gerenciadas pororganizações diferentes.

11

2.2 Mecanismos

Tecnologias que exploram mobili dade devem prover mecanismos que suportem odeslocamento de suas entidades. Estes mecanismos necessitam de uma estruturacomputacional que suporte à mobili dade. Sendo assim, a concepção de um ambientecomputacional (Computational Environment) deve ser introduzida para suportar osdiversos mecanismos necessários à mobili dade. Um ambiente computacional retêm aidentidade do nodo onde está localizado dando suporte para que as aplicações tenham acapacidade de recolocar dinamicamente seus componentes em diferentes ambientescomputacionais. Um exemplo de ambiente computacional é a máquina virtual Java(Java Virtual Machine).

O texto [FUG 98] trata mobili dade através do termo código móvel. O texto tambémdestaca que um ambiente computacional é uma espécie de “ container” para as entidadesenvolvidas na computação, chamadas componentes. Estes podem ser unidades deexecução ou recursos. Unidade de execução representa a entidade básica da linguagem,um objeto por exemplo, através de um fluxo seqüencial da computação. Uma unidadede execução é composta pelo segmento de código, que contém a descrição estática docomportamento da computação, e um estado. Recursos representam entidades quepodem ser compartilhadas por múltiplas unidades de execução, como uma variável dosistema operacional por exemplo.

A princípio, cada unidade de execução pode mover-se independentemente. Em algunssistemas que exploram código móvel, o código e o estado da unidade de execuçãopodem estar em diferentes ambientes computacionais. À mobili dade é determinada pelacaracterística do sistema. Por exemplo, em Java é possível mover somente o código deum Applet [SUN 96]. Já em Java Aglet [LAN 97], tanto o código quanto o estado sãomovidos.

Podem ser identificadas duas formas de mobili dade [FUG 98]: mobili dade for te emobili dade fraca.

Mobili dade forte permite que a unidade de execução possa mover seu código e o estadoda computação para diferentes ambientes computacionais. Neste caso, a execução ésuspensa, transmitida para o ambiente computacional destino, e sua execução éretomada. Mobili dade fraca permite transferir código de um ambiente computacionalpara outro. O código pode conter alguns dados inicializados, mas o estado da unidade deexecução não é movido. A figura 2.1 apresenta uma classificação dos mecanismos demobili dade [FUG 98].

12

Mobil itymechanisms

Code andexecution statemanagement

Strongmobility

Weakemobility

Migration

RemoteCloning

Proactive

Reactive

Proactive

Reactive

Codeshipping

Stand-alonecode

Synchronou s

Asynchronou s

Imediate

Deferred

Codefragment

Synchronou s

Asynchronou sImediate

Deferred

Stand-alonecode

Synchronou s

Asynchronou s

Imediate

Deferred

Codefragment

Synchronou s

Asynchronou s

Imediate

Deferred

Codefetching

Data spacemanagement

Binding removal

Network reference

Re-binding

By copy

By Move

FIGURA 2.1 - Mecanismos de Mobili dade

Mobili dade forte pode ser explorada através de dois mecanismos: migração (migration)e clone remoto (remote cloning). O mecanismo de migração suspende a execução deuma unidade de execução, transmite para o ambiente computacional destino e retomasua execução. A migração pode ser proativa (proactive) ou reativa (reactive). Naprimeira, o tempo e o destino da migração são determinadas pela unidade de execuçãomigrante. Na segunda, a migração é acionada por diferentes unidades de execução quetenham alguma espécie de ligação com a unidade de execução migrante. O mecanismode clone remoto cria uma cópia da unidade de execução no ambiente computacionalremoto. A unidade de execução não é isolada do ambiente computacional origem. Comona migração, o clone remoto pode ser proativo ou reativo.

Mecanismos que suportam mobili dade fraca têm a capacidade de transferir códigoatravés de ambientes computacionais e ligar-se dinamicamente com uma unidade deexecução ativa ou criar uma nova unidade de execução no ambiente remoto para aexecução. Estes mecanismos podem ser classificados de acordo com a direção datransferência do código, a natureza do código movido, a sincronização envolvida e omomento em que o código é executado no ambiente remoto.

Conforme a direção do código a ser transferido, uma unidade de execução pode trazer(fetching) o código para ser dinamicamente ligado e/ou executado, ou pode levar(shipping) o código para outro ambiente computacional. Nos dois casos, o código a sertransferido pode ser um código autônomo (stand-alone code) ou fragmentado (code

13

fragment). No primeiro caso, no ambiente computacional destino é criada uma unidadede execução para executar o código que chega. No segundo caso, a unidade de execuçãodeve ligar-se com um contexto que esteja executando o código ou que eventualmente otenha executado. Além disso, tanto no código autônomo como no fragmentado, estesmecanismos podem ser síncronos (synchronous) ou assíncronos (asynchronous),dependendo se a unidade de execução que solicita a transferência fica suspensa ou nãoaté que o código seja executado. No modo assíncrono, a execução do código transferidopode ser imediata (imediate), isto é, o código é executado logo que recebido oupostergada (deferred), isto é, espera alguma condição ser satisfeita para iniciar aexecução.

Após a migração de uma unidade de execução para um novo ambiente computacional,sua ligação com os recursos que acessa deve ser reorganizada. Por exemplo, a unidadede execução pode necessitar acessar um arquivo, portanto, ela deve estar apta a acessareste arquivo mesmo que este esteja em outro local. Isto pode envolver novas ligações ousempre migrar alguns recursos necessários a computação junto com a unidade deexecução, dependendo da natureza do recurso e da aplicação. Por isto é necessário ogerenciamento do espaço de dados.

Os recursos podem ser transferíveis ou não-transferíveis através da rede. Por exemplo,um recurso do tipo arquivo pode ser transferível mas um recurso do tipo impressora não.Recursos transferíveis podem ser marcados como livres ou fixos. O primeiro podemigrar para outro ambiente computacional, enquanto que o último deve semprepermanecer associado ao ambiente computacional.

Na reorganização dos recursos, duas classes de problemas devem ser analisados quandouma unidade de execução desloca-se através da rede: realocação de recursos ereconfiguração das ligações. Para isto deve ter um gerenciamento do espaço de dados(data space management). A estratégia para gerenciar os recursos e os dados envolvidosna transferência de código pode variar de sistema para sistema. Os mecanismos maisusados são:

• remoção das ligações (binding removal) - quando a unidade de execução migra, asligações são simplesmente descartadas. Pode-se observar que esta estratégiageralmente é usada quando há migração da entidade envolvida na computação,portanto, num tipo de mobili dade forte;

• referência na rede (network reference)- quando um recurso é não transferível, aligação na unidade de execução com o recurso é modificada para referenciar orecurso no ambiente computacional fonte, depois que a unidade de execução tenhaalcançado o ambiente computacional destino. Referência na rede geralmente é usadaquando à mobili dade forte é explorada, através do clone remoto;

• re-ligação (re-binding) - no ambiente computacional remoto há um recurso domesmo tipo que é referenciado na unidade de execução que chega. Sendo assim, aligação com o recurso no ambiente computacional fonte é desfeita, e uma novaligação apontando para o recurso no ambiente computacional destino é criada. Estaestratégia é usada quando à mobili dade fraca é explorada, na forma de levar ou trazercódigo fragmentado;

14

• por cópia (by copy)- uma copia do recurso é criada, e a ligação é modificada parareferenciar a cópia e esta é transferida junto com a unidade de execução para oambiente computacional destino. Pode-se observar que o mecanismo por cópia éassociado ao clone remoto, portanto explorando uma mobili dade forte;

• por movimento (by move)- o recurso é transferido junto com a unidade de execuçãopara o ambiente computacional destino mas a ligação com o ambiente computacionalfonte não é desfeita. Esta estratégia é usada em aplicações que exploram mobili dadefraca.

2.3 Paradigmas para mobili dade

Abordagens tradicionais para projeto de software não são suficientes quando necessita-se projetar aplicações distribuídas em larga escala que exploram código móvel ereconfiguração dinâmica dos componentes do software. Neste caso, a distribuição doscomponentes para diferentes ambientes deve ser pensada durante o projeto de software.Também deve-se considerar os aspectos que diferenciam a interação entre componenteslocais em ambientes remotos. Dentre esses aspectos cita-se uma maior latência decomunicação, maior tempo para acesso a memória não local, mais pontos de falha enecessidade de utili zação de mecanismos para controle de concorrência e sincronização.

Portanto, é importante identificar paradigmas para projeto de sistemas distribuídosexplorando código móvel. Além disso, deve-se identificar a tecnologia mais adequadapara implementação do paradigma. Os paradigmas apresentados a seguir podem servistos como um guia de referência para o projeto de aplicações distribuídas quecomportam mobili dade. Antes de introduzir os paradigmas, é necessário apresentaralgumas concepções básicas que abstraem as entidades envolvidas no sistema comoarquivos, variáveis, código executável ou processos. As abstrações básicas são asseguintes [CAR 97]:

• Componentes - são os elementos que compõem a arquitetura. Podem estar dividosem :

• componente recurso: é o componente embutido na arquitetura que representadados passivos ou dispositivos físicos;

• componente computacional: representa o fluxo de controle da computação. Écaracterizado por um estado e ligações com outros componentes;

• Interações - são eventos que envolvem dois ou mais componentes. Por exemplo, umamensagem trocada entre dois componentes computacionais pode ser consideradacomo uma interação entre eles;

• Sites - são os ambientes de execução. Eles suportam a execução dos componentescomputacionais. Sites tem ligados a si a noção de localização [FUG 98]. Interaçõesentre componentes no mesmo site são consideradas pouco expressivas serelacionadas com interações em sites diferentes, pois como os recursos estão locais,as interações acontecem de forma mais rápida e sem problemas de latência da rede,acesso aos recursos, tempo de acesso, etc.

15

O paradigma é descrito em termos de padrões de interações que definem a re-colocaçãoe a coordenação entre componentes necessários para realizar um serviço.

Conforme [FUG 98], são três os principais paradigmas que exploram código móvel:Avaliação Remota, Código em Demanda e Agentes Móveis. Estes paradigmas sãocaracterizados pela localização dos componentes antes e depois da execução dosserviços, pelo componente computacional que é responsável para execução do código eonde a computação acontece.

Paradigmas para código móvel tem explicitamente a noção de localização. Assim, épossível modelar, a nível de projeto, custos para interações entre componentes. Emgeral, conforme [FUG 98], interações entre componentes que compartilham a mesmalocalização tem um custo considerado negligenciável quando comparado a interaçõesentre sites através da rede. A escolha do paradigma a ser explorado deve ser pensadocaso a caso, de acordo com o tipo de aplicação.

2.3.1 Avaliação Remota

De acordo com o paradigma de Avaliação Remota, um componente de um sistemaque suporta mobili dade pode invocar serviços providos por outros componentes, queestão distribuídos pelos nodos da rede, através do fornecimento dos dados necessáriospara desenvolver o serviço bem como o código que descreve como o serviço é feito.Avaliação Remota pode ser explicada da seguinte forma: um componente A, no site A ,sabe (conhecimento) como realizar uma determinada tarefa (serviço) mas não tem osrecursos necessários para que ela seja feita. Estes recursos estão localizados em outrosite (site B). Conseqüentemente, A envia o conhecimento de como fazer o serviço para ocomponente computacional localizado no site remoto. O componente B realiza o serviçoutili zando os recursos nele contidos. Após a execução, há novamente uma interaçãoentre os dois componentes para enviar o resultado da computação de volta para A.

Este paradigma é semelhante a abordagem cliente-servidor, onde os serviços sãoexecutados em um servidor que contém os recursos e o conhecimento necessário paraexecutar uma tarefa. A semelhança pode ser verdadeira se todos os recursos, e a formade manipulação destes, estão ligados a um servidor da rede. No paradigma deAvaliação Remota, o “ cliente” sabe como executar uma tarefa, mas o recurso podeencontrar-se em outro computador da rede. Neste caso, o conhecimento é transmitidopara onde está o recurso, sendo que no computador destino pode existir somente orecurso em si, mas não o conhecimento necessário para manipulá-lo.

2.3.2 Código em Demanda

Na abordagem de Código em Demanda, o código que descreve o comportamento deum componente em um sistema que suporta mobili dade pode ser buscado em um siteremoto para ser executado localmente. Exempli ficando este paradigma, um componenteA tem acesso aos recursos localizados no Site A mas não tem o conhecimento de comomanipular estes recursos. Portanto, A interage com o componente B no Site B,requisitando o conhecimento para acessar o recurso. Uma segunda interação acontece

16

quando B envia o conhecimento para A e este realiza a computação (abordagemcontraria a Avaliação Remota).

2.3.3 Agentes Móveis

No paradigma Agentes Móveis, onde os agentes são considerados unidades de execução[CUG 96], todo o componente computacional é movido para o site remoto, inclusive oseu estado, o código e alguns recursos necessários para o desenvolvimento da tarefa.Para exempli ficar, um componente A é dono do conhecimento, que esta no Site A, pararealizar alguns serviços. Só que em um determinado momento da execução, elenecessita de alguns recursos que estão no Site B. Então A migra para o Site Bcarregando o conhecimento necessário para executar uma tarefa. Ao mover-se para osite remoto, A completa o serviço neste site. Este paradigma é diferentes dos outrosparadigmas, pois nestes o foco é a transferência de código entre componentes enquantoque no paradigma de agentes móveis o código e o estado da computação são movidospara o site remoto (migração).

2.4 Conclusões

Este Capítulo descreveu os fundamentos que envolvem os estudos em mobili dade,necessários para compreender o universo que envolve as aplicações que utili zammobili dade. Pode-se observar que o conceito de mobili dade não é consenso entre acomunidade científica que se dedica a estudar o assunto. Vários autores entendemmobili dade de forma diferenciada, embora sejam unânime em um aspecto: odeslocamento da entidade envolvida na computação móvel. Desta forma, pode-se dizerque mobili dade, como o próprio nome diz, pressupõe que a entidade base dacomputação possa mover-se de um ambiente computacional para outro.

O texto [FUG 98] apresenta uma estrutura conceitual para compreender código móvel.O texto tem várias contribuições. Entre elas, um conjunto de termos e conceitos paracompreender e comparar as abordagens baseadas na noção de código móvel, através demecanismos e paradigmas que auxili am o desenvolvimento de aplicações para códigomóvel. Além disso, apresenta algumas tecnologias que suportam mobili dade e algumasaplicações.

A capítulo 3 aborda aspectos de mobili dade em sistemas distribuídos.

17

3 Mobili dade em Objetos e Agentes

A maioria das tecnologias distribuídas que suportam mobili dade são construídas a partirdo paradigma orientado a agente. Como em alguns ambientes um agente é consideradoum objeto especial [OBJ 97] [OBJ 98], os conceitos da orientação a objetos sãoamplamente utili zados por tecnologias que suportam mobili dade. Sendo assim, esteCapítulo apresenta aspectos relacionados à mobili dade em sistemas distribuídos,especialmente envolvendo objetos e agentes. Para isto, são abordados aspectosreferentes a orientação a objetos, orientação a agentes e agentes móveis. A seção 3.1aborda o paradigma orientado a objetos. A seção 3.2 apresenta o paradigma orientado aagentes. A Seção 3.3 apresenta aspectos referentes a agentes móveis. Finalmente, aseção 3.4 apresenta as conclusões do capítulo.

3.1 Paradigma Or ientado à Objetos

O objetivo desta seção é “ lembrar” vários aspectos relacionados à objetos que sãoimportantes para entender porque mobili dade é explorada usando objetos e agentes.Além disso, em tecnologias como Voyager [OBJ 97], um agente é visto como um objetoespecial. Desta forma, os conceitos da orientação à objetos são muito utili zados no quese refere a agentes. Amandi no texto [AMA 97], diz que observando as definições deobjeto e de agente, vê-se que existem características em comuns entre estas entidades eentre sistemas multi -agentes e sistemas orientado à objetos.

Segundo [AMA 97], objetos são representações de entidades físicas ou abstratas domundo real, que pertencem ao contexto do sistema a ser projetado. Este possui comocaracterísticas fundamentais: os atributos, os métodos e as mensagens. Conceitosimportantes relacionados com o paradigma orientado a objetos, tais como: mensagem,encapsulamento, classe, instância, herança, associação dinâmica, polimorfismo ereusabili dade devem ser observados em tecnologias que exploram mobili dade emobjetos. Estes conceitos podem ser encontrados, de forma descritiva, no livro de JamesRumbaugh ([RUM 96]), um clássico da orientação a objetos.

Outra característica importante é a concorrência. Quanto a concorrência em objetos,existem dois tipos naturais:

• Concorrência intra-objetos - a concorrência surge da existência de vários acessosconcorrentes a um mesmo objeto, que pode implicar a execução concorrente demétodos de um mesmo objeto;

• Concorrência inter-objetos - a forma de concorrência mais natural, que estáassociada ao fato de vários objetos poderem executar simultaneamente.

Havendo concorrência, deve haver sincronização. Em objetos, é necessário sincronizaros vários objetos, no caso de concorrência inter-objetos e as várias threads em umobjetos, no caso de concorrência intra-objetos.

A comunicação entre objetos pode ser feita de duas formas: síncrona e assíncrona. Nasíncrona, após o envio de uma mensagem a um objeto, a execução do emissor ficasuspensa enquanto não houver retorno por parte do receptor. Num contexto concorrente,

18

deve-se tomar precauções para evitar que o emissor de uma mensagem fiqueindefinidamente bloqueado caso não receba resposta. Este tipo de problema levou autili zação de mecanismos de mensagens assíncronas. Neste caso, o emissor ao enviaruma mensagem ao um objeto não fica bloqueado, podendo seguir sua execução.

A associação entre concorrência e paralelismo é bastante natural, pois a concorrênciapode ser visto como paralelismo lógico entre tarefas. Embora sejam conceitosindependentes, na prática a diferença entre os dois torna-se difuso, pois cada vez mais ossistemas concorrentes apoiam-se em sistemas paralelos. Isto acontece porque grandeparte dos conceitos associados a concorrência tem correspondência nos sistemasparalelos: mecanismos de troca de mensagens, mecanismos de sincronização, etc.

Sendo assim, a passagem de um modelo de objetos concorrente para um modelo deobjetos paralelo é relativamente natural, pois o objeto como unidade de execuçãoconcorrente assegura a localidade em termos de código e dados (encapsulamento). Alémdisso, a troca de mensagens permite grande liberdade em termos de implementações emambientes paralelos.

Com referência a objetos distribuídos, pode-se dizer que um objeto distribuído é umaespécie de código que pode “ viver” em qualquer lugar de uma rede. Eles são umaespécie de pacotes com código independente que podem ser acessados por clientesremotos via invocação de métodos. O cliente não precisa saber em que lugar, na rede, oobjeto distribuído reside. Os objetos podem ser executados em sistemas operacionaisdiferentes e podem trocar mensagens com outros objetos em qualquer parte da rede[ORF 96].

Existe recentemente uma tendência de se construir sistemas computacionais abertosutili zando objetos distribuídos. Estes possuem as mesmas características principais dosobjetos das linguagens de programação: encapsulamento, polimorfismo e herança,tendo, dessa forma, as mesmas principais vantagens: fácil reusabili dade, manutenção edepuração, só para citar algumas.

3.2 Paradigma Or ientado a Agentes

A comunidade científica têm proposto uma variedade de definições, cada qual tentandoexplicar o seu uso da palavra “ agente” . Essas definições vão de um nível elementar atéum nível mais elaborado. Pesquisadores inventaram também novos termos parareferenciar seus agentes, tais como: agentes inteligentes, interfaces inteligentes,interfaces adaptativas, knowbots, softbots, userbots, taskbots, personal agentes enetwork agentes.

Durante o estudo, observou-se que não há uma definição unificada e universal a respeitodo termo "agente". Vários pesquisadores salientam a dificuldade para criação de umadefinição de agente. Amandi em [AMA 97] afirma que um agente representa umaentidade computacional com um comportamento autônomo, que pode comunicar-secom outros agentes com o fim de participar na realização de uma tarefa. Os agentespodem auxili ar outros agentes e usuários de diferentes formas: eles ocultam acomplexidade de tarefas difíceis, podem treinar ou ensinar, ajudam em diferentescolaborações, monitoram eventos e procedimentos, etc. Um sistema multiagentes é

19

definido por um conjunto de agentes que colaboram entre si para cumprir com asresponsabili dades do sistema.

Um agente deve apresentar algumas propriedades. Elas definem qual é a classificaçãodo agente, ou seja, um agente inteligente, reativo, capaz de aprender, etc. Propriedadesde agentes correspondem a características de um sistema que são resultados diretos daarquitetura do sistema ou são níveis de operação que existem sobre a arquitetura quetem um efeito no comportamento global do sistema. Por arquitetura se entende a porçãodo sistema que fornece e gerência os recursos primitivos de um agente [FLE 98]. Paraque o sistema seja considerado agente, ele não necessita apresentar todas aspropriedades mas algumas delas são recomendáveis. Algumas propriedades são:

• Autonomia - é a capacidade de perseguir uma agenda independentemente de seuusuário. Isso requer aspectos de ação periódica, execução espontânea e iniciativa, emque o agente precisa ser capaz de tomar ações preemptivas (optativas) eindependentes que eventualmente beneficiarão o usuário [FLE 98]. Em outraspalavras, a autonomia permite ao agente ter algum tipo de controle sobre suas açõese estado interno.

• Mobili dade - conforme [FLE 98], é a habili dade para mover-se de uma localizaçãopara outra, enquanto preservam seu estado interno.

• Comunicabili dade - é a capacidade de trocar informações com outras entidades(agentes, humanos, objetos, seu ambiente) [FLE 98]. Nas interfaces entre os agentes,é necessário decidir que tipo de declaração os agentes serão capazes de gerar ecompreender. Obviamente, o projeto da interface é cuidadosamente relatado para oprojeto da arquitetura de todo o sistema. Há ainda um outro problema nacomunicação que é a interpretação e significado das declarações do agente. Umtermo pode ter diferentes significados para diferentes agentes, o que é chamado deconflito. Diferentes termos podem, entretanto, ter significado similar, o que significauma correspondência.

• Aprendizagem - agentes são capazes de examinar o ambiente externo (porexemplo, a Web) e o "sucesso" de ações prévias levam condições similares, eadaptam suas ações para melhorar a probabili dade de atingir prosperamente suasmetas.

• Reatividade - um agente está inserido em um ambiente que pode ser o mundofísico, um usuário via uma interface gráfica, uma coleção de agentes, a Internet, outalvez todos esse combinados. A reatividade é a capacidade de um agente responderde uma maneira oportuna à mudanças que ocorre nele e no ambiente.

• Iniciativa - Possuir iniciativa é a habili dade de exibir comportamento direcionadoao objetivo, oportunístico e que não reage simplesmente ao seu ambiente.

• Sociabili dade - significa interagir com outros agentes (e possivelmente humanos)através de algum tipo de linguagem para comunicação de agente.

• Racionalidade - é a suposição de que um agente atuará para atingir seus objetivos,e não atuará de modo que impeça que seu objetivo seja alcançado - pelo menos atéonde sua opinião permitir.

20

• Percepção - os agentes sentem o mundo e geram conhecimentos acessíveis paraprocessar o que a razão está dizendo para perceber no mundo.

• Cooperação - agentes inteligentes precisam ter um "espírito" cooperativo paraexistir e ter sucesso em "sistemas orientados a agentes". O que se quer é que agentesinteligentes trabalhem juntos para que possam executar tarefas mutuamentebenéficas mais complexas .

Dentro das propriedades, tem-se observado que os agentes as possuem em níveis. Porexemplo: a autonomia de um agente é demonstrada diferentemente de agente paraagente, o que leva a considerar que os agentes apresentam níveis de propriedades. Damesma forma que as definições de agente ainda não estão estabelecidas pelo meiocientífico de forma homogênea, as propriedades também apresentam esta característica.As definições das propriedades parecem ser mais convergentes, porém oferecemmargem à várias interpretações. Dependendo das característica que um agente apresentaele pode ser classificado em categorias distintas de agentes.

Para poder dizer que um agente é desta ou daquela forma, é necessário que o agenteatenda algumas características peculiares. Por exemplo, para um agente ser consideradoum agente móvel, ele precisa possuir a propriedade de mobili dade. Algumasclassificações de agentes, como agentes inteligentes, agentes autônomos, agentesreativos, etc, podem ser encontradas no texto [FLE 98].

3.3 Agentes Móveis

Agentes móveis são programas que podem ser disparados em um computador eenviados para executar em um computador remoto. Chegando no computador remotoele apresenta suas “ credenciais” e obtêm acesso aos serviços locais e aos dados [LAN97]. É uma tecnologia emergente que promete tornar sistemas distribuídos mais fáceisde projetar, implementar e manter. Agentes móveis não estão restritos aos sistemas emque iniciaram sua execução, pois eles têm a habili dade de se transportar de um sistemapara outro através de uma rede. Este recurso permite a um agente móvel mover-se para osistema que possui um objeto com o qual o agente deseja interagir, obtendo a vantagemde residir na mesma máquina ou rede do objeto.

Agentes móveis podem oferecer um paradigma uniforme para objetos distribuídos,englobando passagem de mensagens síncronas e assíncronas, passagem de objetos eobjetos móveis e estacionários. Além de suportar os serviços existentes em uma rede,agentes móveis também tornam possíveis novos serviços e novas oportunidades denegócios. Características como cooperação, autonomia e representatividade foramherdadas da própria origem de agentes, entretanto, foram acopladas outras a fim desuprir as necessidades exigidas para o bom funcionamento de modelos que utili za oparadigma de agentes móveis, tais como objetos passantes, assincronismo, interaçãolocal, operações sem conexão e execução paralela. Estas características são definidascomo [LAN 97]:

• Objetos passantes - quando um agente móvel é transferido, todo o objeto é movido,ou seja, o código, os dados, o itinerário para chegar ao servidor necessário, o estadode execução, etc;

21

• Assincronismo - o agente móvel possui sua própria thread de execução e esse nãoprecisa ser executado sincronamente;

• Interação local - o agente móvel interage com outros agentes móveis ou objetosestacionários locais. Se necessário, um agente mensageiro é enviado para facilit ar ainteração com agentes remotos;

• Operações sem conexão - o agente móvel pode executar tarefas mesmo com aconexão fechada. Quando se faz necessário transferência de agentes, aguarda-se atéque a conexão seja restabelecida;

• Execução paralela - múltiplos agentes podem ser disparados para diferentesservidores a fim de executar tarefas em paralelo.

Apesar de conter semelhanças entre esse novo paradigma e outros métodos de despachoremoto, os agentes móveis primam por segurança, uma característica fracamenteexplorada em sistemas antigos. Isso deve-se, principalmente, ao fato dos sistemasanteriores não terem sido projetados para utili zação em redes geograficamentedistribuídas, sem opções, que hoje fazem parte do cotidiano, como o uso de cartões decrédito em algum tipo de comércio eletrônico. A nível de segurança os agentes móveisrealizam tarefas relacionadas à autenticação de usuário/servidor e autorização deserviços no servidor. Aplicações que utili zam os conceitos de agentes seguem oparadígma atual de funções/procedimentos ou Orientação a Objetos como paradígma deimplementação.

A aplicação cliente é um ambiente de interação com o usuário que utili za os conceitosde agentes móveis. Além disso, essa aplicação tem interface com o ambiente agente.Logo, quando as tarefas são executadas, o ambiente agente de execução envia o agentemóvel, através do subsistema de mensagens. No servidor, ocorre a ação contrária: oagente é recebido através do subsistema de mensagem e é encaminhado ao ambienteagente de execução, que deve ser compatível com o ambiente do cliente. Daí, as tarefassão realizadas a nível de aplicação servidora e se necessário, um agente mensageiro édisparado.

Segundo [LAN 97], agentes móveis apresentam uma série de vantagens como:

• Redução do tráfego da rede - Sistemas distribuídos demandam um grande volumede comunicação (interação) para realizar uma determinada tarefa, principalmentequando há restrições de segurança envolvidos. Agentes móveis permitem reduzir otráfego da rede, pois permitem despachar tarefas que podem executar suas interaçõeslocalmente. Agentes móveis podem ainda reduzir o tráfego de dados da rede, poispermitem mover o processamento para o local onde os dados estão armazenados aoinvés de transferir os dados para depois processá-los. O princípio é simples: "Movero processamento para os dados ao invés de mover os dados para o local deprocessamento".

• Oculta a latência da rede - Sistemas críticos necessitam de respostas em tempo realpara mudanças no ambiente. O controle desses sistemas através de uma redesubstancialmente grande ocasiona uma latência inaceitável. Agentes móveisoferece uma solução, pois podem ser enviados pelo controlador central pararealizarem suas tarefas localmente.

22

• Encapsulamento de protocolo - Cada máquina em um sistema distribuído possuiseu próprio código necessário para implementar a transferência de dados. Porém,novos requisitos de segurança e eficiência demandam mudanças no protocolo quepodem ocasionar problemas na manutenção do código existente. Agentes móveis,por outro lado, podem mover-se para máquinas remotas a fim de estabelecer canaisde comunicação baseados em protocolos proprietários.

• Execução assíncrona e autônoma - Tarefas podem ser embutidas em agentesmóveis que podem ser enviados pela rede. Após serem enviados, os agentes sãoautônomos e independentes da criação de processo, podendo executarassincronamente. Este recurso é útil principalmente porque um dispositivo móvel(ex. laptops) pode se reconectar na rede para coletar o agente mais tarde.

• Adaptação dinâmica - Agentes móveis possuem a habili dade de percebermudanças no ambiente de execução e reagir autonomamente. Múltiplos agentespodem interagir entre si e se distribuir pela rede, de modo a manter umaconfiguração ótima para resolver um problema em particular.

• Independência de plataforma - Redes de computadores, geralmente sãoheterogêneas, tanto na perspectiva de hardware como a de software. Agentes móveissão independentes da máquina e também da rede, sendo dependentes somente do seuambiente de execução, não dificultando a integração de sistemas. Mas é necessárioque o ambiente de execução do agente esteja disponível para um determinadohardware ou software.

• Robustez e tolerância a falhas - A habili dade dos agentes móveis de reagiremdinamicamente a situações e eventos desfavoráveis torna fácil a construção desistemas distribuídos robustos e tolerantes a falhas. Por exemplo, se uma máquinaestá para ser desligada, todos os agentes em execução na máquina podem seradvertidos para que possam ser enviados e continuar suas tarefas em outra máquinada rede.

Para comunicação entre os agentes, merece destaque o Protocolo de Transferência deAgentes (ATP - Agent Transfer Protocol). Este é um protocolo a nível de aplicação parasistemas distribuídos baseados em agentes. Enquanto agentes móveis podem serprogramados em diferentes linguagens e para diferentes plataformas, através de umamáquina virtual e de bibliotecas, o ATP oferece a oportunidade de manejar agentesmóveis através de uma forma geral e uniforme.

Uma máquina que suporta agentes tem um serviço de agente baseado em ATP, que é umcomponente capaz de enviar e receber agentes de um computador remoto via protocoloATP. O serviço de agente é identificado por um endereço único, independente daplataforma específica de agente suportada pela máquina. Uma máquina pode rodarmúltiplos serviços de agentes. Além disso, uma mensagem ATP carrega informaçõessuficientes para identificar a plataforma de agente específica, na máquina receptora, eum gerenciador ATP é chamado para gerenciar a mensagem.

O protocolo ATP é baseado no paradigma de requisição/resposta entre serviços ATP.Um serviço ATP A estabelece uma conexão com um serviço ATP B, e envia umarequisição para B esperando uma resposta. ATP/0.1 pode ser obtido no endereçohttp://www.trl.ibm.co.jp/aglets/ e faz parte do IBM Aglets Workbench.

23

Além disso, para que os agentes possam se comunicar com outros agentes distribuídosatravés da rede, é desejável que eles se comuniquem através de um protocolo comum.Desta forma, existe um esforço da comunidade científica no sentido de normalizar alinguagem de comunicação entre os agentes. Uma proposta é a linguagem KQML(Knowledge Query Manipulation Language) [FIN 94] e um outro para a representação eintercâmbio do conhecimento adquirido pelos agentes através do formato KIF(Knowledge Interchange Format). Estes padrões são importantes para haver umconsenso no desenvolvimento de aplicações com suporte a agentes móveis.

A linguagem Java viabili zou a concepção de diversos sistemas experimentais de agentesmóveis. Numerosos sistemas estão atualmente em desenvolvimento ou jácomercializados tais como: Voyager [OBJ 97] [OBJ 98], Aglets [LAN 97] e Concordia[WONG 97] [CAS 98]. Estes são apresentados no capítulo 4. Os sistemas citados acimapossuem muitas características em comum, como a utili zação da máquina virtual Javapadrão, mecanismos de serialização de objetos e arquitetura baseada em servidor.Contudo, os mecanismos de transporte de agentes e interação variamconsideravelmente. Estas diferenças são apresentadas no capítulo 5.

3.4 Conclusões

Este capítulo apresentou aspectos de mobili dade em sistemas distribuídos,especialmente envolvendo objetos e agentes. Como a maioria das aplicaçõesdistribuídas que suportam mobili dade são construídas a partir do paradigma orientado aagente e algumas aplicações consideram o agente um objeto especial, os conceitos daorientação a objetos são amplamente utili zados por tecnologias que suportammobili dade.

Pode-se concluir que não há diferença entre objetos e agentes móveis que justifiquemum estudo separado destas duas entidades. A filosofia da orientação a objetos éabsorvida pela orientação a agentes, portanto, um agente pode ser considerado umobjeto, mas com autonomia, isto é, pode-se dizer que um agente é uma evolução doobjeto. Um exemplo do uso deste conceito é Voyager [OBJ 97] [OBJ 98]. Esta é umatecnologia promissora para desenvolvimento de aplicações com suporte à mobili dadeque considera agente um objeto especial, isto é, que tem autonomia.

O Capítulo 4 apresenta as tecnologias usadas para implementar mobili dade e algumasaplicações que utili zam mobili dade.

24

4 Tecnologias para Supor te à Mobili dade

Este capítulo apresenta algumas ferramentas usadas para desenvolver sistemas quesuportem mobili dade e alguns ambientes que permitem explorar mobili dade. A seção4.1 apresenta as ferramentas para suporte à mobili dade, tais como Java [SUN 96], Obliq[CAR 95] e Oz Distribuído [ROY 97], que são linguagens de programação quepermitem implementar mobili dade. Além disso apresenta CORBA [OMG 95],destacando sua contribuição para exploração da mobili dade. A seção 4.2 apresentaalguns ambientes que suportam mobili dade, tais como Voyager[OBJ 97] [OBJ 98],Aglets [OSH 98] e Concordia [WON 97]. A seção 4.3 apresenta alguns exemplos deaplicações onde à mobili dade pode ser aplicada. Finalmente, a seção 4.4 apresenta asconclusões do capítulo.

4.1 Ferramentas para supor te à mobili dade

4.1.1 Java

Java [SUN 96] é uma linguagem orienta a objetos, baseada em classes, criada pela SunMicrosystems, com ênfase em portabili dade e segurança. O compilador Java transformaprogramas fontes em uma linguagem independente de plataforma chamada Java ByteCode. Este é interpretado pela Java Vir tual Machine (JVM) - a implementação doambiente computacional Java. Através da rede, a carga das classes é feita através doClassLoader. Este é invocado pela JVM quando, na execução de um código corrente,uma classe que ainda não foi carregada é referenciada. O ClassLoader busca a classecorrespondente, possivelmente de uma máquina remota, e carrega na JVM. Nesteponto, o código correspondente é executado.

Java foi criada com a concepção de segurança, essencial em um sistema distribuído,garantindo que regras de acesso sejam sempre respeitadas. Muitos recursos querequerem controle de acesso dinâmico, como um sistema de arquivo ou um acesso arede, são controlados por um monitor chamado Secur ityManager.

Um dos fatores de sucesso de Java é o seu uso na Internet. Browsers suportam JVM ecarregam classes chamadas Applet. Estas podem ser carregadas em páginas HTMLpermitindo acesso a pequenas aplicações. Sendo assim, um Applet é um tipo deaplicação em menor escala para executar em um Web Browser. Toda Applet é criada apartir de uma subclasse da classe Applet. Esta hierarquia determina muito do que aApplet não pode fazer. Uma Applet executada pela internet é considerada, por default,código não confiável.

Sendo assim, pode-se concluir que Java possui uma estrutura computacional própria,que consiste em seu ambiente computacional, isto é, a máquina virtual Java. Atravésdesta, Java provê suporte aos mecanismos da linguagem que permitem implementarmobili dade. A sua entidade computacional é o objeto. Além disso, Java exploramobili dade fraca, do tipo autônoma, pois permite que os programas sejam carregadosdinâmicamente pela rede, através do ClassLoader. Com estas características, Java é a

25

linguagem mais usada para implementar mobili dade. Ainda pode-se observar queaplicações móveis desenvolvidas através do paradigma de Código em Demanda podemser desenvolvidas utili zando Java. Um exemplo do uso deste paradigma em Java é oApplet, pois este é buscado em um site remoto para ser executado localmente.

Maiores informações sobre a linguagem Java pode ser encontrado em [SUN 96].

4.1.2 Obliq

Obliq [CAR 95] da DEC System Research Center, é uma linguagem com um escopoléxico, é dinamicamente tipada, baseada em protótipo, projetada para computaçãodistribuída orientada a objeto. A computação é transparente da rede, isto é, não temnenhuma dependência de localização quanto a computação, mas a distribuição égerenciada explicitamente à nível de linguagem.

A linguagem tem três principais características:

• A migração de um objetos pode ser programada com a combinação de transmissãofechada (como se fosse uma caixa preta), apelidos (outro nome para um objeto) eobjeto clone (cópia do objeto). Depois da migração, operações no objeto originalsão redirecionadas para o site remoto e executadas nele. A migração pode serserializada através das primitivas serialized e protected para que o estado do objetonão possa trocar durante a chamada migrate.

• Obliq pertence a uma classe de linguagens orientada a objetos chamada “ baseada emprotótipo” . Nestas linguagens não existem classes e objetos são criados por cópia(clone) de objetos existentes (os protótipos);

• Obliq é tipada dinamicamente. Erros com relação aos tipos da linguagem sãodescobertos claramente e propagados para o site origem.

São quatro as operações básicas em um objeto: seleção/invocação, atualização, clone eapelido.

Na seleção/invocação, quando o valor de um objeto é selecionado, este valor étransmitido através da rede para o site que selecionou. Quando o método de um objetoremoto é invocado, os argumentos são transmitidos através da rede para o site remoto, oresultado é realizado no computador remoto, e o valor final é retornado para o site queinvocou.

Na atualização, quando um objeto remoto é atualizado, um valor é transmitido atravésda rede para o objeto remoto.

Pode-se notar neste ponto que Obliq suporta o paradigma de Avaliação Remota, pois oconhecimento vai para onde está o recurso e depois retorna ao site requisitante.

No Clone, uma cópia do objeto é criada, mas a estrutura dos valores é compartilhada.Por exemplo, os elementos de um vetor são compartilhados entre o clone e o objetooriginal. No apelido, atributos podem ser redirecionados para atributos em outrosobjetos. Apelidos são usados para criar procuradores.

26

Objetos podem ser protegidos através da palavra protected. Interfaces seguras podem serconstruídas através do uso do mecanismo de proteção e procuradores. Para tratar acessosconcorrentes, Obliq suporta objetos serializados. Um objeto é serializado se mais deuma thread pode acessar o objeto. Isto é feito usando mecanismos de exclusão mutua,que é adquirido quando um dos métodos é invocado e solto quando retorna do método.

O escopo léxico oculta valores chamados externamente e o sistema de execuçãoassegura que o escopo seja cumprido. Comunicações entre servidores independentes sãomediadas através de uma variável global compartilhada contendo o nome do servidor(endereço IP da máquina por exemplo), permitindo servidores importar e exportarvalores. Para um procedimento ser executado em um servidor distante, o nome doservidor é solicitado para a máquina de execução (execution engine) receber oprocedimento. Máquina de execução implementa um tipo de ambiente de execução,permitindo execução remota de procedimentos. Uma thread, que é a unidade deexecução Obliq, pode requisitar a execução de um procedimento em uma máquina deexecução remota. O código para o procedimento é enviado para a máquina destino eexecutada nela em uma nova thread. As referências do objeto local usadas peloprocedimento são automaticamente transformados em referências para rede.

Sendo assim, Obliq suporta mobili dade forte, tanto através de migração quanto atravésde clone remoto. No primeiro caso o gerenciamento do espaço de dados se dá através daremoção das ligações e no segundo através de referências na rede e por cópia. Alémdisso, a máquina de execução Obliq oferece um ambiente computacional propício aexploração da mobili dade e sua entidade base é o objeto.

Maiores informações sobre Obliq pode ser encontrado em [CAR 95].

4.1.3 Oz Distr ibuído

A linguagem Oz distribuída [ROY 97] é uma linguagem projetada para processamentosimbólico concorrente. O Oz integra vários paradigmas de programação, incluindoorientação a objetos, funcional e restrições lógicas, em um único modelo.

A semântica distribuída estende a semântica da linguagem através do controle damobili dade. Mobili dade em OZ é a habili dade que uma entidade stateful, que podemudar seu estado, tem de migrar entre os sites ou de permanecer estacionária entre ossites, dependendo das intenções do programamador [ROY 97].

A construção do Oz distribuído tem quatro características essenciais [ROY97]: (1) éuma linguagem concorrente; (2) tem um fluxo de dados sincronizado. Threads sãobloqueadas quando um dado é requisitado por ela mas ainda não está disponível. Estebloqueio é transparente do ponto de vista da thread; (3) tem procedimentos de primeira-classe com escopo léxico; (4) tem informação de estados (state-aware), distinguindodados stateless (não mudam seus estados e são replicados entre os sites ) e stateful.

A linguagem satisfaz a semântica centralizada garantindo a transparência na rede. Esterequisito requer mecanismo como um espaço de computação compartilhado (sharedcomputation space) e concorrência (concurrency). O primeiro provê a ilusão de umagrande memória comum (espaço de endereçamento para as entidades) para todos osdados. Além disto, um programa que executa em muitos sites deve se comportar da

27

mesma maneira quando executado em um site. Portanto, outro mecanismo necessário éa concorrência, isto é, várias computações ativas devem coexistir independentemente.

São usados dois mecanismos para identificar a rede: informação de estado (state-awareness) e controle da mobili dade (mobilit y control). O sistema deve distinguirentre estas duas formas de dados através de uma informação de estado. Para dadosstateful, é necessário um controle maior da localização. Para isto surge o controle damobili dade. Entidades móveis migram para sites remotos invocando estes. Isto éimplementado usando um protocolo para mobili dade [ROY 98].

Pode-se observar neste ponto que OZ Distribuído pode suportar mobili dade forte atravésda migração do tipo proativa, onde a unidade migrante determina quando migrar. Suaentidade base é o objeto. Seu ambiente computacional é a Oz Virtual Machine que,como em Java, é portável, podendo executar tanto em Unix como em Windows.

A meta do projeto de distribuição é não impedir a implementação centralizada, para isto,o espaço de computação pode ser representado em termos de dois grafos: o grafo paralinguagem, onde não existe a noção de site e o grafo de distribuição, que fazexplicitamente a noção de site.

A execução distribuída é feita em dois passos: no primeiro passo o espaçocomputacional é modelado em um grafo chamado grafo da linguagem. O segundo passoé estender o grafo da linguagem para o grafo de distribuição, com a noção de site,introduzindo um conjunto finito de site e colocando em cada nodo o grafo da linguagemcom o site. Se um nodo é referenciado por um nodo em outro site, ele é mapeado paraum conjunto de nodos no grafo de distribuição. Este conjunto é chamado de estrutura deacesso do nodo original. Uma estrutra de acesso consiste em um conjunto de nodosglobais, um chamado procurador (proxy) pelo site e outro de gerenciador por toda aestrutura.

As células tem ponteiro para os dados (content-edge), que são conhecidos somente porum procurador. Os procuradores geralmente não conhecem onde o ponteiro para osdados está localizado. Se procurador quer fazer uma operação de troca e não tem oponteiro para os dados, este deve perguntar ao gerenciador. Isto diminui a latência darede.

OZ tem um modelo simples para tolerância a falhas. A detecção de falhas deverealmente informar ao programador se e onde a falha ocorreu. O modelo suportasomente falha no site, não suportando falha na rede. Cada espécie de falhas torna-sevisível somente a um procurador, quando este tenta fazer uma operação na célula edescobre que ocorreu uma falha. O procurador tem então um nodo falho e algumasmensagens para este são ignoradas. Excepcionalmente é criada uma thread queinicicializa as operações na célula.

Maiores informações sobre o modelo de programação do Oz distribuído podem serencontrados em [ROY 98] e [ROY 97].

4.1.4 CORBA

A organização OMG (Object Management Group) estabeleceu a arquitetura CORBA(Common Object Request Broker Architecture) [OMG 95] como uma forma de

28

especificar um middleware aberto composto de objetos distribuídos. O objetivo primárioé alcançar sistemas baseados em objetos em ambientes distribuídos heterogêneos comcaracterísticas de reusabili dade, portabili dade e interoperabili dade.

Em 1990, a OMG criou o OMA (Object Management Architecture) com o objetivo defomentar o crescimento de tecnologias baseadas em objetos e fornecer uma infra-estrutura conceitual para todas especificações OMG. O OMA é composto por quatroelementos principais: ORB (Object Request Broker), Serviços de Objetos, Facili dadesComuns e Objetos de Aplicação. Para este texto, o elemento que merece destaque é oORB. Este habilit a os objetos enviarem e receberem requisições e, da mesma maneira,receberem respostas a suas requisições, de forma transparente em um sistemadistribuído. O ORB é a base para a construção de aplicações, utili zando objetosdistribuídos, que possuam características de interoperabili dade entre aplicações emambientes heterogêneos ou homogêneos.

A Figura 4.1 dá uma idéia geral da estrutura e dos elementos que compõe o OMA.

FIGURA 4.1 - Arquitetura de Gerenciamento de Objetos (OMA)

O principal objetivo de se definir uma arquitetura comum para ORB's é para se obter ainteroperabili dade entre diferentes implementações. A grande diversidade dessasimplementações mostra que fazê-las interoperar não será tarefa simples, bem como nãofoi interconectar redes distintas com diferentes protocolos, por isso, este último vemsendo usado como modelo para se alcançar o objetivo, a interoperabili dade.

Objetos clientes requisitam serviços às implementações de objetos através de um ORB.O ORB é responsável por todos os mecanismos requeridos para encontrar o objeto,preparar a implementação de objeto para receber a requisição, e executar a requisição. Ocliente vê a requisição de forma independente de onde o objeto está localizado, quallinguagem de programação ele foi implementado, ou qualquer outro aspecto que nãoestá refletido na interface do objeto.

O primeiro requisito para se obter a interoperabili dade é definir um modelo de alto nívelpara que suas diferenças sejam disfarçadas. No caso do ORB esse modelo é uma IDL(Interface Definition Language). CORBA utili za a OMG IDL como uma forma dedescrever interfaces, isto é, de especificar um contrato entre os objetos. OMG IDL éuma linguagem puramente declarativa baseada em C++. E por ser definidaindependentemente do ORB, permite que clientes e implementações se comuniquemtranspassando vários ORB's distintos preservando a semântica dos pedidos de formatransparente para clientes e implementações. Isso garante que os componentes em

29

CORBA sejam auto-documentáveis, permitindo que diferentes objetos, escritos emdiferentes linguagens, possam interoperar através das redes e de sistemas operacionais[ORF 96].

Para fazer uma requisição, um cliente pode usar a Interface de Invocação Dinâmica (DII- Dynamic Invocation Interface) ou um Stub de IDL. Para algumas poucas edeterminadas funções, um cliente pode interagir diretamente com a interface do ORB.

O fato de permitir tanto a invocação dinâmica quanto a estática, torna CORBA bastanteflexível. A invocação estática possui uma série de vantagens sobre a invocação dinâmica[ORF 96]: é mais fácil de programar, faz verificação de tipos mais robusta, executa maisrápido e é auto-documentável. Já a invocação dinâmica permite a adição de novosserviços às implementações de objetos sem alterações nos clientes. Dessa forma, osclientes podem descobrir em tempo de execução quais são os serviços oferecidos.

A invocação dinâmica é possível através dos serviços do Repositório de Interfaces. UmRepositório de Interfaces é uma base de dados que contém interfaces OMG IDL, e seusserviços basicamente permitem o acesso, armazenagem e atualização dessas interfaces.

Ao receber uma requisição, o ORB localiza o código da implementação transmiteparâmetros e transfere o controle para a implementação do objeto. Quando a requisiçãoé completada, o controle e os valores de saída são retornados ao cliente. De formaparecida ao que ocorre na requisição de um cliente, o ORB pode invocar aimplementação de objeto através de um Esqueleto de IDL Estático ou Dinâmico. AInterface de Esqueleto de IDL Dinâmica (DSI - Dynamic Skeleton Interface) é umaforma de se enviar requisições de um ORB para uma implementação de objetos que nãopossui informações sobre a implementação do objeto em tempo de compilação.

Para executar a requisição, a implementação de objeto pode obter alguns serviços doORB através do Adaptador de Objetos. O Adaptador de Objetos se situa no topo dosserviços de comunicação do Núcleo de ORB. Ele fornece o ambiente para instanciarobjetos, atribuir referências de objetos, e passar requisições a eles. Com um adaptadorde objetos, é possível a uma implementação de objeto ter acesso a um serviçoindependentemente se ele está implementado no Núcleo de ORB — se o Núcleo deORB oferecer o serviço, o adaptador simplesmente fornece uma interface para ele, casocontrário, o adaptador deve implementá-lo no topo do Núcleo de ORB.

Para localizar e ativar implementações de objetos, um ORB se utili za de Repositórios deImplementações. Esses repositórios servem adicionalmente para armazenar informaçõesadicionais associadas com implementações de ORBs, tais como, informações dedepuração, controles administrativos, segurança, dentre outras.

A especificação de interfaces de objetos obrigatoriamente em OMG IDL, garante aportabili dade dos objetos através de diferentes linguagens, ferramentas, sistemasoperacionais e redes. Entretanto, a característica de interoperabili dade entre objetos sófoi coberta na versão 2.0 do CORBA, introduzida em dezembro de 1994.

O protocolo entre ORBs genérico (GIOP - Generic Inter-ORB Protocol) especifica umasintaxe de transferência padrão e um conjunto de formatos de mensagens paracomunicação entre ORBs. O protocolo entre ORBs para Internet (IIOP - Internet Inter-ORB Protocol) especifica como mensagens GIOP são trocadas usando conexõesTCP/IP. Ele especifica um protocolo de interoperabili dade padrão para Internet.

30

O ORB, por si só, não executa todas as tarefas necessárias para os objetosinteroperarem. Ele só fornece os mecanismos básicos. Outros serviços - como serviçode nomes, de controle de concorrência, de tempo - necessários são oferecidos porobjetos com interface IDL, que a OMG vem padronizando para os objetos de aplicaçãopoderem utili zar.

Analisando as características CORBA, pode-se observar que suporta o paradigma deAvaliação Remota, pois através do ORB, objetos podem enviar requisições e recebersuas respostas. CORBA é usado para o desenvolvimento de aplicações que envolvemobjetos distribuídos, isto é, não suporta em sua essência mobili dade. O papel deCORBA na mobili dade, e também neste texto, advém do fato de que esta tecnologiaserviu de inspiração para várias outras tecnologias que suportam mobili dade. Voyager[OBJ 97] [OBJ 98], que será visto a seguir, é um exemplo de tecnologia queimplementa mobili dade e que usa uma plataforma ORB, além de permitir integraçãocom CORBA.

Maiores informações a respeito da tecnologia CORBA pode se encontrada nasreferências [OMG 95] e [ORF 96].

4.2 Ambientes que permitem explorar mobili dade

4.2.1 Voyager

Conforme [GLA 98], ObjectSpace VoyagerTM Core Technology - Voyager [OBJ 97][OBJ 98] - consiste de uma plataforma ORB implementado em Java e com suporte aagentes. É uma plataforma que integra computação distribuída com tecnologia deagentes, suportando objetos móveis e agentes autônomos. Permite que objetos e agentespossam enviar mensagens padrão Java para um agente mesmo sem saber sua localizaçãoatual. Além disso, também inclui um conjunto de serviços que implementa, de formatransparente, persistência, comunicação em grupo e serviço básico de diretório.

Uma das habili dades de Java é carregar classes na máquina virtual em tempo deexecução. Isto habilit a uma infra-estrutura para usar objetos móveis e agentesautônomos bem como ferramentas para construção de sistemas distribuídos. Temsintaxe própria para construir, enviar mensagens e mover objetos e agentes e permiteimplementar persistência distribuída. Desta forma, Voyager provê suporte paramobili dade de objetos e agentes, utili zando o modelo de objetos Java.

Voyager permite integração com CORBA desde 1997. Um pacote adicional Javapermite ao Voyager criar uma interface para ser usada em um cliente ou servidorCORBA. Sem modificação do código, por exemplo, pode-se exportar algumas classesJava para servidores CORBA, gerando automaticamente IDL para ser usada pelaimplementação CORBA.

Redes de computadores são, geralmente, compostas de hardware e sistema operacionaldiferentes. Sistemas usando ORBs freqüentemente necessitam código binário emseparado para cada plataforma. Isto aumenta o tempo de desenvolvimento ecomplexidade para manutenção do sistema. Como Voyager é implementado em Java,

31

portanto portável, as aplicações são escritas somente uma vez, podendo executar emcima de qualquer arquitetura que suporte Java.

Resursos em sistemas distribuídos necessitam ser usados sabiamente. Quando umamáquina está sobrecarregada, parte da carga deve ser levada para uma máquina que nãoesteja sobrecarregada. O desenvolvimento somente com ORBs não auxili a aosprogramadores resolverem este problema [GLA 98]. Em Voyager, objetos e agentesmóveis podem ser usados para encapsular processamento e migrar através da rede,levando a carga de trabalho com eles. Sendo assim, voyager permite balanceamentodinâmico de carga.

Um objeto Voyager é um componente de software que tem um conjunto bem definidode funções e dados encapsulados.

Quando um programa Voyager inicia, ele automaticamente cria threads que provêemalgum serviço, como garbage collection e verificação do tráfego da rede. Cadaprograma Voyager tem um endereço na rede consistindo no nome da máquina e onúmero da porta de comunicação, que é um inteiro único para a máquina. Números deportas são alocados aleatoriamente para os programas. Isto é suficiente para clientescomunicarem-se com objetos remotos, criar e lançar agentes através da rede. Contudo,se um programa pode ser endereçado por outro programa, pode-se atribuir um númerode porta conhecido para o programa em inicialização.

Uma classe controla instâncias remotas se sua instância pode ser criada fora do espaçode endereçamento local do programa e se esta instância pode receber mensagens comose ela estivesse localmente. Sendo assim, no Voyager, esta classe "esconde" o fato deestar remota. É importante salientar que fora do contexto Voyager, uma classe remotanão esconde o fato de estar remota. Para simpli ficar, este trabalho denomina classesque controlam instâncias remotas como classes remotas. Voyager permite um objetocomunicar-se com uma instância de uma classe remota através de referências vir tuais.Mensagens enviadas para referências virtuais são automaticamente repassadas para ainstância da classe remota. Se uma mensagem retorna um valor, o objeto receptor enviao valor de retorno para a referência virtual, que retorna este valor para o emissor.

Após a criação de uma classe remota, pode-se construir instâncias remotamente,mesmo se o código da classe não exista na máquina remota; enviar mensagens parainstâncias remotas usando uma sintaxe Java regular; conectar instâncias remotasexistentes em outros programas; mover instâncias remotas para outros programas,mesmo se o código da classe não esteja no programa destino e construir instânciasremotas persistentes.

Depois de criar uma classe remota, pode-se criar instâncias remotas da classe original(objetos remotos). As instâncias remotas podem residir no programa corrente ou numprograma diferente, e uma referência virtual para a instância remota é criada noprograma corrente. Para construir uma instância remota de uma classe, dá-se aoconstrutor de classes virtuais o endereço do programa destino onde a instância remotadeve residir. Se o código original da classe para a instância remota não existir noprograma destino, Voyager carrega automaticamente o código da classe original noprograma destino.

Neste ponto nota-se que Voyager suporta o paradigma de Código em Demanda.

32

Quando um objeto remoto é criado, é automaticamente atribuído a ele um identificadorglobal único, que identifica o objeto em todos os programas da rede. Opcionalmente,pode-se atribuir um alias para um objeto remoto durante a criação. O identificador ou oalias podem ser usados para localizar ou conectar o objeto em qualquer ponto da rede.

Um objeto remoto pode ser referenciado por qualquer número de referência virtual.Para criar uma nova referência virtual e associa-la com o objeto remoto existente, deve-se fornecer o endereço do programa onde o objeto remoto existente reside e o seu aliaspara o método VObject.forObjectAt( ).

Quanto à mobili dade, pode-se mover qualquer objeto serializado de um programa paraoutro enviando a mensagem moveTo( ) para o objeto via refêrencia remota, fornecendo oendereço do programa destino como parâmetro. Mobili dade é a habili dade de mover-seindependentemente de um dispositivo para outro através da rede [GLA 98].

Uma mensagem pode ser enviada para um objeto mesmo que o objeto tenha-se movidode um programa para outro, simplesmente enviando a mensagem para o objeto noúltimo endereço conhecido. Quando a mensagem não localiza o objeto destino, amensagem procura por um retransmissor representando o objeto. Se um retransmissor élocalizado, este envia a mensagem para o objeto na nova localização. O valor retornadoé marcado como a nova localização do objeto remoto, para que a referencia virtual possaatualizar a localização do objeto. Após isto, mensagens são enviadas diretamente para anova localização do objeto, sem necessitar do retransmissor.

Mobili dade é útil porque os objetos que trocam grande número de mensagens podemser movidos para junto um do outro, reduzindo assim o tráfego na rede. Um programapode mover objetos dentro de um dispositivo móvel. Assim o programa podepermanecer com o dispositivo depois de ele ser desconectado da rede.

Analisando o texto até o momento, observa-se que Voyager também pode dar suporte aodesenvolvimento através do paradigma de Avaliação Remota. Sendo assim, os objetospodem mover-se para onde está o recurso.

Voyager também suporta agentes móveis. A filosofia do Voyager é que o agente ésimplesmente uma espécie especial de objeto que pode mover-se independentemente,podendo continuar sua execução ao se mover, e no entanto comportar-se exatamentecomo qualquer outro objeto. Um agente é um tipo especial de objeto pois ele temautonomia, isto é, ele é um objeto que pode existir mesmo sem ter uma referência paraele. Um agente autônomo pode ser programado para satisfazer uma ou mais metas,mesmo se, ao mover-se, perder contato com seu criador.

Neste ponto fica claro que não há diferença entre objetos e agentes móveis quejustifiquem um estudo separado destas duas entidades. A filosofia da orientação aobjetos é absorvida pela orientação a agentes, portanto, um agente pode ser consideradoum objeto, mas com autonomia, isto é, pode-se dizer que um agente é uma evolução doobjeto.

Um agente em Voyager suporta, além da autonomia, mobili dade. Além disso, um agentetem todas as características de um objeto simples: pode ser atribuído um alias,referências virtuais, comunicação com objetos remotos, etc. Sendo assim, um agentepode mover-se de um programa para outro. Mas, diferentemente de objetos simples, umagente pode mover-se de forma autônoma.

33

Através dos agentes, nota-se que Voyager também suporta o desenvolvimento deaplicações através do paradigma de Agentes Móveis. Além disso, pode implementaruma mobili dade forte através da migração destes agentes.

Existem várias vantagens em usar agentes móveis em Voyager:

• Se uma tarefa tem que ser desempenhada independentemente do computador que ainicializou, um agente pode ser criado para desempenhar esta tarefa. Ele podemover-se dentro da rede e completar a tarefa num programa remoto;

• Se um programa precisa enviar um grande número de mensagens a objeto emprogramas remotos, um agente pode ser construído para visitar cada programa eenviar mensagens localmente;

• Para particionar um programa e tê-lo executando em paralelo, o processamento podeser distribuído por vários agentes que migram para programas remotos e secomunicam para atingir a meta final. Se um objeto remoto precisa ser monitoradoperiodicamente, ter um agente que o encontra e o monitora localmente é maiseficiente que monitorá-lo através da rede.

Voyager suporta persistência. Um objeto persistente tem uma cópia backup na base dedados, chamada VoyagerDb, e é automaticamente recuperado se o seu programatermina inesperadamente.

Maiores informações a respeito da tecnologia Voyager pode ser encontrada em [OBJ 97]e [OBJ 98].

4.2.2 Aglets

Aglets [IBM 97] são objetos Java com a capacidade de se mover de uma máquina paraoutra em uma rede, levando consigo o código de programa e o estado dos objetos quecompõe o Aglet. Este é um agente móvel porque suporta a idéia de execução autônomae rota dinâmica de seu etinerário. A biblioteca de classes de um Aglet tem os seguintesobjetivos:

• fornecer um modelo simples de programação utili zando agentes móveis, sem noentanto implicar em modificação na JVM ou em código nativo;

• disponibili zar mecanismos de comunicação poderosos e dinâmicos quepermitam agentes se comunicarem com outros agentes;

• projetar uma arquitetura de agentes móveis que permita extensibili dade ereusabili dade;

• obter uma arquitetura altamente coerente com o modelo tecnológico Web/Java.

A biblioteca Aglets/API (J-AAPI - Java Aglet Application Programming Interface) éuma proposta padrão para criar Aglets. Contém métodos para inicialização, mensagens,movimento, ativação/desativação, etc. Plataformas escritas com estas bibliotecas podemser escritas e executadas em qualquer computador que suporte a interface para Aglet. Omodelo define um conjunto de abstrações e de comportamento necessários para que atecnologia de agentes móveis seja usada na Internet. As principais abstrações do modelo

34

são o Aglet, o contexto, o procurador, a mensagem, o itinerário e o identificador, como évisto a seguir:

• Aglet - é o elemento básico da biblioteca e consiste em um objeto Java móvelautônomo (pois possui sua própria thread de execução) e reativo pois poderesponder a mensagem externas.

• Contexto (context) - é um objeto estacionário que provê um ambiente paramanutenção e gerenciamento de aglets em execução.

• Procurador (proxy) - é um objeto que representa um Aglet, e tem por objetivofornecer transparência de localidade e proteção a métodos públicos.

• Mensagem (message) - é um objeto transmitido entre Aglets, permitindo passagemde mensagens síncronas e assíncronas, usados para colaboração e troca deinformações.

• I tinerár io (itinerary) - é o plano de viagem do Aglet. Isto provê uma convenienteabstração de padrões de viagens e rota.

• Identificador (identifier) - cada aglet possui um único e global identificador que éimutável durante todo seu ciclo de vida.

O modelo Aglet provê comportamentos essenciais com relação a um agente tais como:criação, clonagem, envio, retirada, desativação, ativação, liberação, mensagem enomeação [LAN 97].

A criação de um Aglet coloca ele no contexto. Ao novo Aglet é atribuído umidentificador, inserido no contexto e inicializado. O Aglet começa a execução assim queele seja inicializado com sucesso. A clonagem produz uma cópia quase idêntica doAglet original no mesmo contexto. Somente há diferença na atribuição do identificadore o fato da execução reiniciar em um novo Aglet. Com isto, a thread em execução não éclonada. O envio de um Aglet de um contexto para outro remove ele do contextocorrente e insere dentro do contexto destino, onde a execução da thread é reinicializada.

Sendo assim, embora Java suporte mobili dade fraca, a biblioteca Aglet suportamobili dade forte através de migração, pois como colocado no parágrafo acima, o enviode um Aglet tira ele de um contexto e o coloca em outro. Além disso, o contexto podeser considerado o ambiente computacional que dá suporte à mobili dade dos agentes emAglet. A entidade base do Aglet é o agente.

A retirada de um Aglet remove ele do contexto corrente e o insere dentro do contexto aoqual a retirada foi requisitada. A desativação de um Aglet remove temporariamente docontexto corrente e o coloca em um armazenamento secundário. A ativação restaura oAglet para o contexto corrente. A liberação de um Aglet pára a execução corrente e oremove do contexto corrente. Mensagens entre Aglet envolvem envio, recebimento eparada de mensagens síncronas bem como assíncronas. O mecanismo de nomeaçãoautomático atribui um identificador imutável para um novo Aglet.

Voyager utili za o protocolo ATP (Agente Transfer Protocol), abordado no Capítulo 3,para a comunicação e transferência de agentes entre os contextos.

35

Quanto a segurança dos agentes, o Modelo de Segurança Aglet provê vários frameworkpara segurança em Aglet. Como Aglets são objetos Java que podem migrar de umamáquina para outra, eles tem um potencial de acesso para todos os recursos da máquina.Eles também confiam na segurança do interpretador Java para sua própria execução.Assim, segurança em Aglet e segurança em Java andam juntas.

Maiores informações sobre Aglet podem ser encontradas em [IBM 97] , [OSH 98] e[LAN 97].

4.2.3 Concordia

O Concordia [WONG 97] [CAS 98], concebido pela Mitsubishi constitui-se de umframework para o desenvolvimento e gerenciamento de aplicações de agentes móveis.O Concordia compreende múltiplos componentes, todos escritos em Java, na qual sãocombinados para prover um ambiente para aplicações distribuídas. Este sistema ésimples, e requer somente uma implementação padrão do servidor Concordia, feito emcima da máquina virtual Java, e seu ambiente é composto de um servidor e um conjuntode agentes. O agente é também um programa Java que é gerenciado pelo servidorConcordia. Cada agente está associado a um usuário particular e carrega umaespecificação que contém o caminho de migração e o método a ser executado em cadamáquina. Nota-se que a entidade base do Concordia é o agente.

Quanto a arquitetura do sistema, cada nodo num sistema Concordia consiste em umservidor Concordia e provê serviços básicos para criação, migração, execução,comunicação e administração de agentes móveis. O servidor pode ser executado em umaou mais máquinas virtuais Java. A figura 4.5 mostra como é formada a arquitetura doConcordia [WON 97].

Secur ityM anager

AdministrationM anager

ConduitM anager

AgentsPersistentM anager

EventM anager

QueueM anager

Java Vir tual M achine

remote queuemanagers

remote conduitservers

CorporateDB server

FIGURA 4.5 - Arquitetura do Concordia

36

O Servidor Concordia é um componente completo, instalado e executando em umarede Concordia. O servidor é o ambiente computacional necessário para a computação,permitindo que à mobili dade seja explorada através das estruturas contidas dentro doambiente.

O Gerenciador de Agentes provê a infra-estrutura de comunicação que permite aosagentes serem transmitidos e recebidos pelos nodos da rede. Além disso, gerencia ociclo de vida do agente, provê suporte à mobili dade e interface para administração(inclusive remota) dos serviços do servidor Concordia.

À mobili dade do agente é transparente para os usuários do sistema. A viagem do agenteé descrita através de um itinerário. Este é composto de múltiplos destinos. Cada destinodescreve a localização do agente na viagem e o trabalho que o agente realiza nestalocalização. A localização pode ser definida pela identificação da máquina na rede e otrabalho através dos métodos manipulados pelo agente.

O Concordia usa uma infra-estrutura similar a Java para mobili dade dos agentes.Durante a viagem de um agente através da rede, seu byte code e o byte code de algunsobjetos são carregados via uma classe especial chamada ClassLoader. Neste pacote, obyte code contém uma estrutura de dados que viaja com o agente. Durante adeserialização do agente, o byte code para o agente e suas classes podem serrecuperadas e usadas para inicializar uma nova copia do agente.

Pode-se notar que Concordia permite uma mobili dade fraca do tipo autônoma,semelhante a Java, pois permite que os programas sejam carregados dinâmicamente pelarede, através do ClassLoader.

Concordia dá suporte a duas formas de comunicação inter-agente: eventos assíncronosdistribuídos e colaboração entre agentes. Eventos assíncronos distribuídos sãoescalonados e gerenciados pelo Gerenciador de Eventos, enquanto a colaboração entreagentes requer que o programador da aplicação agente especifique um objetoAgentGroup através da utili zação da biblioteca de classes Concordia. A colaboraçãoentre agentes permite a interação entre agentes, colaboração num grupo (agentes podemenviar eventos para outros agentes ou para aplicação pai).

Persistência em agentes é um requisito que assegura recuperação do agente em caso defalha. A persistência é oferecida através do Gerenciador de ArmazenamentoPersistente, permitindo a reinicialização do agente quando ocorrer uma falha ou atémesmo a reinicialização do servidor Concordia. A implementação do Gerenciador deArmazenamento Persistente é baseada na serialização de objetos Java.

Agentes em Concordia são móveis e sua mobili dade pode extender-se tanto em redeslocais como na Internet. O Gerenciador de Filas é responsável pelo controle deprioridades na execução de agentes, e também pela migração de agentes, garantindo umnível de tolerância a falhas através do armazenamento do agente antes de transmití-lo(store-and-forward).

O modelo de segurança Concórdia provê suporte para dois tipos de proteção: (1)proteção contra agentes com origem falsificada e (2) proteção dos recursos do servidorcontra acessos não autorizados. Agentes são protegidos contra falsidade quando sãoarmazenados no sistema cliente e quando são armazenados na base de dados persistente.Esta proteção é feita através de criptografia. Sendo assim, garante a proteção do agente

37

no armazenamento e na migração, além de autenticar a origem do agente. OGerenciador de Segurança gerencia os recursos de proteção. A cada agente é atribuídouma identificação, permitindo ao agente acessar os recursos.

A administração do sistema Concordia é feita pelo Gerenciador de Administração.Este inicializa e termina os servidores do sistema de agentes. Ele também gerencia atroca de política de segurança entre os agentes e os servidores fazendo uma requisiçãodo comportamento do agente ou do servidor para o Gerenciador de Seguraça. Alémdisso, monitora o comportamento dos agentes através da rede, provêndo estatísticassobre isto.

O Gerenciador de Diretór io permite aos agentes móveis localizar os servidores deaplicação para interação. O sistema pode ser configurado para incluir um ou maisgerenciador de diretórios. Além disso, registra os serviços de aplicações disponíveis narede e disponibili za uma operação de lookup para os agentes que estão a procura deserviços para interagir.

As Pontes de Serviço possibilit am que os agentes e/ou aplicações acrescentem serviçosao servidor Concordia, aumentando a funcionalidade e a interação do servidor com osagentes.

Em Concordia fica muito claro a concepção de um ambiente computacional, assimcomo em Java. Este ambiente, além de permitir mobili dade, oferece segurança, acessosautorizados, confiança etc.

Maiores Informações sobre Concordia podem ser encontradas nos textos [WONG 97] e[CAS 98].

4.3 Aplicações

São várias as aplicações que podem ser desenvolvidas utili zando tecnologia demobili dade. Entre elas:

• Recuperação de informações distr ibuídas - estas informações são recuperadas deacordo com algum critério específico. O informação a ser recuperada pode serdefinida estaticamente ou dinâmicamente durante o processo de recuperação. Sendoassim, um agente, por exemplo, pode ser encarregado de viajar pela rede, obtendo asinformações a serem recuperadas;

• Serviços avançados de telecomunicações - o suporte e o gerenciamento de serviçoscomo vídeo conferência, telemarketing, etc, requerem mecanismos de reconfiguraçãodinâmica e customização do uso. O uso de mobili dade permite o desenvolvimentodestes serviços. Por exemplo, uma aplicação que gerencia a sinalização, o sinal eapresentação de um serviço de vídeo conferência pode ser despachado pelos usuáriosatravés de um agente;

• Controle e configuração de dispositivos remotos - a tecnologia de código móvelpode ser usada para projetar e implementar componentes de monitoramento que estãolocalizados nos dispositivos a serem monitorados e transmitir eventos querepresentem a evolução do estado do dispositivo. O estudo de caso do gerenciamentode uma rede é apresentado em [FUG 98];

38

• Gerenciamento de Workflow - o workflow define que atividades devem sercarregadas para serem cumpridas em uma determinada tarefa bem como de quemaneira, onde e quando estas atividades envolvem cada parte. Código móvel podeser usado para prover suporte à mobili dade de atividades que encapsulem suasdefinições e seu estado. Por exemplo, um componente móvel pode encapsular umdocumento texto que suporta várias versões. O componente gerência a informaçãosobre o estado do documento, que operações foram feitas, e qual o próximo passopara revisão;

• Comércio Eletrônico - aplicações de comércio eletrônico permitem usuáriosdesenvolver aplicações comerciais através da rede. Uma transação pode envolvernegociação com entidades remotas e requisição de informações. Portanto, é desejávelque o componente móvel da aplicação sé forneça informações relevantes para onegócio. Aplicações deste tipo podem ser implementadas com a tecnologia deagentes móveis.

4.4 Conclusões

Este capítulo apresentou as tecnologias usadas para desenvolver sistemas que suportemmobili dade, bem como as aplicações que podem ser desenvolvidas. Foram apresentadasas linguagens Java, Obliq e Oz Distribuído. Estas foram apresentadas com o objetivo demostrar alternativas, a nível de linguagem, para o desenvolvimento de aplicações queexploram mobili dade. O texto [THO 97] apresenta uma comparação de váriaslinguagens que implementam código móvel.

Além disso, foi apresentado CORBA, Voyager, Aglets e Concordia. Estes podem serconsiderados middleware para o desenvolvimento de aplicações que permitemmobili dade. É importante destacar o aspecto de contribuição de CORBA, já que ele porsi só não permite mobili dade. Como ele é usado para implementar objetos distribuídos,vários conceitos de CORBA são usados em outros middleware para o desenvolvimentode aplicações. Também foi apresentado alguns exemplos de aplicações onde àmobili dade pode ser aplicada.

Este capítulo procurou também destacar, nas tecnologias, aspectos que permitissemclassifica-las conforme a proposta de [FUG 98], apresentada no capítulo 2.Relembrando, esta proposta aborda uma estrutura conceitual para compreender códigomóvel, apresentando um conjunto de termos e conceitos para compreender e compararas abordagens baseadas na noção de código móvel, através de mecanismos e paradigmasque auxili am o desenvolvimento de aplicações para código móvel. Tanto osmecanismos quanto os paradigmas foram destacados nas tecnologias apresentadas nestecapítulo.

Pode-se concluir também as várias vantagens no desenvolvimento de sistemas quepermitem mobili dade. Destacam-se:

• possibili dade de operações desconectadas, permitindo que a computação sejarealizada mesmo quando não se está conectado na rede;

• diminuição do tráfego da rede, aproximando a entidade computacional do recurso;

39

• possibili dade de coleta de estatísticas e dados sobre a rede e/ou funcionamento deaplicações distribuídas;

• personificação de uma transação ou cliente, permitindo que informações específicassejam coletadas.

Observando as várias vantagens e possibili dades de desenvolvimento de aplicações,nota-se que elas estão mais de acordo com o desenvolvimento utili zando agentesmóveis, devido a suas características, já destacadas no capítulo 3. Por isto, a grandemaioria das tecnologias que permitem mobili dade suportam o desenvolvimento deaplicações através de agentes móveis ou são especificamente para este tipo de aplicação.

O capítulo 5 apresenta uma comparação das diversas tecnologias apresentadasrelacionando-as aos conceitos e paradigmas apresentados no capítulo 2.

40

5 Análise Comparativa das Tecnologias que Supor tamMobili dade

Este capítulo apresenta uma análise comparativa das tecnologias apresentadas noCapítulo 4, tendo como base a proposta de organização da área de mobili dadeapresentada no texto [FUG 98], descrita no capítulo 2.

A análise será dividida em duas tabelas que comparam aspectos de mobili dade. Aprimeira (Tabela 1), compara algumas ferramentas que permitem implementarambientes para explorar mobili dade. A segunda, Tabela 2, faz comparações ambientesque permitem desenvolver aplicações com mobili dade.

5.1 Análise comparativa das ferramentas

TABELA 1 - Ferramentas para suporte à mobili dade

Ferramentas

Características Java Obliq OZ dist. CORBA

Entidade computacional base objeto X X X X

Entidade computacional base agente

Permite Objetos Distribuídos X X X X

Permite implementar mobili dade X X X

Mobili dade através de objetos móveis X X X

Mobili dade através de agentes móveis

Explora mobili dade forte X X

Explora mobili dade fraca X

Paradigma de Avaliação Remota X X X

Paradigma de Código em Demanda X

Paradigma de Agentes Móveis

Possui ambiente computacional X X X

Mecanismos de serialização de objetos X

Mecanismos de segurança X X X X

41

Com relação a Tabela 1, observa-se que todas as ferramentas tem como entidadecomputacional base o objeto. Mesmo que permitam implementar agentes, a concepçãobase é o objeto.

Todas as ferramentas permitem o desenvolvimento de aplicações usando objetosdistribuídos, mas somente Java, Obliq e Oz Distribuído permitem implementar algumtipo de mobili dade, através de objetos móveis. CORBA não suporta em sua essênciamobili dade, embora tenha servido de inspiração para várias outras tecnologias quesuportam mobili dade. Um exemplo disto é o fato de Voyager suportar integração comCORBA, além de ter em sua implementação uma base ORB.

Quanto ao tipo de mobili dade, Java explora mobili dade fraca, do tipo autônoma, poispermite que os programas sejam carregados dinâmicamente pela rede, através doClassLoader. Já Obliq e OZ Distribuído permitem mobili dade forte. Obliq suportamobili dade forte, tanto através de migração quanto através de clone remoto. Noprimeiro caso o gerenciamento do espaço de dados se dá através da remoção dasligações e no segundo através de referências na rede e por cópia. Por outro lado, OZsuporta mobili dade forte através da migração do tipo proativa, onde a unidade migrantedetermina quando migrar. CORBA, como "não permite" mobili dade, não pode serclassificada.

Quanto aos paradigmas suportados, Java suporta Código em Demanda, sendo queObliq, OZ Distribuído e CORBA suportam o paradigma de Avaliação Remota. Umexemplo de Código em Demanda na linguagem Java é o Applet, pois este é buscado emum site remoto para ser executado localmente. Em Obliq, o conhecimento vai para ondeestá o recurso e depois retorna ao site requisitante. Já em OZ, a construção do grafo dalinguagem e do grafo de distribuição permitem ligações dinâmicas com o proxy, ogerenciador e o content-edge.

Para explorar mobili dade, uma ferramenta deve possuir um ambiente computacional quede suporte para que as entidades possam executar, além de permitir segurança. Javapossui uma estrutura computacional própria, que consiste em seu ambientecomputacional, isto é, a máquina virtual Java. Através desta, Java provê suporte aosmecanismos da linguagem que permitem implementar mobili dade. O ambientecomputacional de Obliq é representado na sua máquina de execução. Já em OZ, seuambiente computacional é a Oz Virtual Machine que, como em Java, é portável,podendo executar tanto em Unix como em Windows.

Todas as ferramentas oferecem algum tipo de segurança. Em Java, a segurança foipreocupação desde a sua criação, garantindo que regras de acesso sejam semprerespeitadas. Muitos recursos que requerem controle de acesso dinâmico são controladospor um monitor chamado Secur ityManager. Em Obliq, a segurança é garantida peloescopo léxico da linguagem que oculta valores chamados externamente. Além disso, osistema de execução assegura que o escopo seja cumprido. OZ tem um modelo simplespara tolerância a falhas, suportando somente falha no site, não suportando falha na rede.

42

TABELA 2 - Ambientes para explorar mobili dade

Ambientes

Características Voyager Aglet Concordia

Entidade computacional base objeto X

Entidade computacional base agente X X X

Possui ambiente computacional X X X

Suporta desenvolvimento em Java X X X

Permite implementar mobili dade X X X

Mobili dade através de objetos móveis X

Mobili dade através de agentes móveis X X X

Explora mobili dade forte X X

Explora mobili dade fraca X X

Paradigma de Avaliação Remota X

Paradigma de Código em Demanda X

Paradigma de Agentes Móveis X X X

Mecanismos de serialização de objetos X X X

Mecanismos de transporte e interação de agentes X X X

Mecanismos para controle de prioridade X

Permite implementar persistência X X

Mecanismos de segurança X X X

A Tabela 2 compara ambientes que permitem o desenvolvimento de aplicações quesuportam mobili dade. Observando a Tabela, nota-se que Voyager tem um ambiente bemmais completo que Aglet e Concordia.

Quanto a entidade computacional base, somente Voyager suporta objetos e agentesmóveis, pois neste ambiente, um agente é considerado um objeto, mas com autonomia.Aglet e Concordia suportam somente agentes móveis.

Todos os ambientes possuem um ambiente computacional. Este fato é natural, pois paradar suporte a execução das entidades computacionais distribuídas, mesmo que nãosuporte mobili dade, cada máquina envolvida na distribuição deve suportar o ambientecomputacional necessário para que as entidades possam ser executadas. Um exemplo é amáquina virtual Java. Para que um programa Java execute, é necessário que a máquinavirtual esteja presente. A questão do ambiente computacional é essencial para permitir

43

mobili dade. O que pode ser uma limitação, pois a entidade computacional só podemover-se para uma máquina onde o ambiente esteja presente ou que possa serinicializado.

Uma questão interessante, é que todos os ambientes suportam desenvolvimento em Java(até porque são desenvolvidos em Java). Isto vem destacar o papel de Java comolinguagem principal para implementar mobili dade. O artigo [THO 97] destaca que Javaé a linguagem mais importante para desenvolvimento de aplicações que suportemmobili dade, por ser portável e segura. Neste artigo encontra-se a descrição de algumaslinguagens para comparações quanto à mobili dade. Java é a linguagem que mereceumaior atenção quanto a descrição e comparação.

Todos os ambientes permitem implementar mobili dade. Voyager suporta mobili dadefraca e forte. A primeira é caracterizada, assim como Java, pela capacidade de carregarclasses para dentro de uma máquina virtual em tempo de execução. Sendo assim, ocódigo para uma determinada tarefa pode ser carregado a medida que for necessário paraa computação. À mobili dade forte é caracterizada pelo suporte a agentes móveis, poiseles devem levar consigo sua “ consciência” , isto é, ocorre uma espécie de migração,embora eles possam construir esta “ consciência” durante seu tempo de vida carregandoclasses em tempo de execução. Aglet suporta mobili dade forte através de migração, poiso envio de um Aglet tira ele de um contexto e o coloca em outro. Já Concordia permiteuma mobili dade fraca do tipo autônoma, semelhante a Java, pois permite que osprogramas sejam carregados dinâmicamente pela rede, isto é, durante a viagem de umagente através da rede, seu byte code e byte code de alguns objetos são carregadosatravés da classe ClassLoader.

Quanto aos paradigmas, Voyager suporta todos os tipos de paradigmas estudados, istoé, Código em Demanda, Avaliação Remota e Agentes Móveis. O primeiro paradigma écaracterizado pelo fato de Voyager permitir criar instâncias remotas de uma classe,sendo que se o código original da classe para a instância remota não existir no programadestino, Voyager carrega automaticamente o código da classe original para este. AAvaliação Remota é caracterizada em Voyager porque este permite que os objetosmovam-se para onde está o recurso. O paradigma de Agentes Móveis é caracterizadopelo fato de Voyager suportar agentes móveis. Como Aglet e Concordia suportamsomente agentes móveis, permitem desenvolver aplicações através do paradigma deAgentes Móveis.

Voyager, Aglet e Concordia contém mecanismos de segurança. Como todos sãobaseados em Java, herdam as características de segurança e portabili dade de Java, alémde mecanismos específicos de cada ambiente. Em Voyager a segurança é mantidaatravés do Voyager Security Manager, que restringe as operações de objetos estranhosdentro do ambiente. Em Aglet, a segurança é mantida através do modelo de segurançaJava, isto é, através do interpretador e da máquina virtual Java. Em Concordia, existe oGerenciador de Segurança que gerencia os recursos de proteção.

44

5.2 Conclusões

Este capítulo apresentou uma análise comparativa das tecnologias apresentadas nestetexto (Capítulo 4). Esta análise foi feita tendo como base a taxonomia apresentada notexto [FUG 98], descrita no capítulo 2. A análise foi dividida em duas tabelas. A Tabela1 procurou comparar aspectos de mobili dade em ferramentas que serviram como basepara implementação de ambientes que permitem explorar mobili dade. A Tabela 2comparou aspectos de mobili dade nestes ambientes.

Na Tabela 1, foram comparadas as ferramentas Java, Obliq e Oz distribuído, que sãolinguagens de programação, e CORBA. Procurou-se nestas estudar aspectos referentes aentidade computacional base da ferramenta, suporte a objetos distribuídos, suporte aimplementação de mobili dade através de objetos e/ou agentes móveis, tipo demobili dade explorada (forte ou fraca), paradigma suportado (Avaliação Remota, Códigoem Demanda e Agentes Móveis), ambiente computacional para suporte à computação emecanismos de segurança.

Na Tabela 2 foram comparados os ambientas Voyager, Aglet e Concordia. Comparou-seaspectos considerados importantes (alguns semelhantes aos analisados quanto asferramentas) com relação a ambientes que suportam mobili dade, tais como entidadecomputacional base, presença de ambiente computacional, suporte a desenvolvimentoem Java, mobili dade através de objetos e/ou agentes móveis, tipo de mobili dade,paradigma suportado e mecanismos de segurança.

É importante observar que a exploração da mobili dade envolve muito a questão dalocalização. Uma premissa básica é que o usuário não necessita saber onde a suacomputação está sendo desenvolvida, pois a aplicação deve abstrair aspectos delocalização do usuário. Como a computação é distribuída através da rede, a integridadedesta computação deve ser preservada, portanto a segurança é um fator muitoimportante.

Todos os aspectos, em cada Tabela, foram comentados e observados como ocorre nasferramentas/ambientes analisados. Pode-se concluir que entidade computacional base,ambiente computacional, tipo de mobili dade e paradigma suportado são aspectosimportantes a serem levados em consideração na necessidade de escolha daferramenta/ambiente para desenvolvimento de aplicações que suportam mobili dade.

O capítulo 6 apresenta as conclusões do trabalho.

45

6 Conclusão

Este trabalho apresentou um estudo sobre mobili dade em sistemas distribuídos. Foiapresentado que os estudos sobre mobili dade intensificaram-se com o uso cada vezmaior de aplicações que utili zam a Internet, podendo-se assim explorar mobili dadeatravés de redes heterogêneas, conectadas por diferentes links de comunicação edistantes uma das outras. Estas aplicações, geralmente são construídas utili zando-seobjetos e/ou agentes. Sendo assim, no âmbito deste trabalho, um dos fatores principaisno desenvolvimento destas aplicações diz respeito à mobili dade destas entidades.

O Capítulo 2 apresentou os fundamentos que envolvem os estudos em mobili dade,necessários para compreender o universo que envolve as aplicações que utili zammobili dade. O conceito de mobili dade ainda não é consenso entre a comunidadecientífica, embora sejam unânimes em que a entidade envolvida na computação deve tero potencial de deslocar-se entre o sistema distribuído, podendo mover-se de umambiente computacional para outro. Além disso, o Capítulo apresentou uma taxionomiaproposta em [FUG 98], envolvendo conceitos e paradigmas, buscando a compreensãodas abordagens baseadas em código móvel.

O Capítulo 3 apresentou aspectos de mobili dade em sistemas distribuídos, orientação aobjetos, orientação a gentes e agentes móveis. Como a maioria das aplicaçõesdistribuídas que suportam mobili dade são construídas a partir do paradigma orientado aagente e algumas aplicações consideram o agente um objeto especial, os conceitos daorientação a objetos são amplamente utili zados por tecnologias que suportammobili dade. Sendo assim, a conclusão mais importante deste Capítulo é que não hádiferença entre objetos e agentes móveis que justifiquem um estudo separado destasduas entidades. A filosofia da orientação a objetos é absorvida pela orientação a agentes,portanto, um agente pode ser considerado um objeto, mas com autonomia.

No Capítulo 4 foi apresentada algumas tecnologias usadas para desenvolver sistemasque suportem mobili dade, procurando sempre destacar aspectos que permitissemclassificá-las bem como as aplicações que podem ser desenvolvidas. Foramapresentadas as linguagens Java, Obliq e Oz Distribuído como ferramentas quepermitem implementar mobili dade. Além disso, foi apresentado CORBA destacandoseu aspecto de contribuição para área de mobili dade, onde vários de seus conceitos sãousados em outros middleware para o desenvolvimento de aplicações. Também foramapresentados alguns exemplos de aplicações onde à mobili dade pode ser aplicada.

A maior contribuição do Capítulo 4 foi a identificação das várias vantagens nodesenvolvimento de sistemas que permitem mobili dade, tais como: possibili dade deoperações desconectadas; diminuição do tráfego da rede, aproximando a entidadecomputacional do recurso; possibili dade de coleta de estatísticas e dados sobre a redee/ou funcionamento de aplicações distribuídas; personificação de uma transação oucliente, permitindo que informações específicas sejam coletadas. Através destasvantagens, observou-se que elas podem ser alcançadas usando agentes móveis,podendo-se concluir então a grande importância da mobili dade dos agentes, pois muitastecnologias que permitem mobili dade suportam o desenvolvimento de aplicaçõesatravés de agentes móveis ou são especificamente para este tipo de aplicação.

46

Finalmente, o Capítulo 5 apresentou uma análise comparativa das tecnologiasapresentadas no Capítulo 4. Esta análise foi feita tendo como base a taxonomiaapresentada no texto [FUG 98], descrita no capítulo 2. A análise foi dividida em duastabelas. A Tabela 1 procurou comparar aspectos de mobili dade em ferramentas queserviram como base para implementação de ambientes que permitem explorarmobili dade. Foram comparadas as ferramentas Java, Obliq e Oz Distribuído, que sãolinguagens de programação, e CORBA. Na Tabela 2, foram comparados os ambientasVoyager, Aglet e Concordia. Comparou-se aspectos considerados importantes (algunssemelhantes aos analisados quanto as ferramentas) com relação a ambientes quesuportam mobili dade, tais como entidade computacional base, presença de ambientecomputacional, suporte a desenvolvimento em Java, mobili dade através de objetos e/ouagentes móveis, tipo de mobili dade, paradigma suportado e mecanismos de segurança.A principal contribuição deste capítulo foi a observação de características semelhantesem ferramentas/ambientes que exploram mobili dade.

Pode-se concluir com este trabalho:

• os estudos em mobili dade são promissores e necessários, uma vez que as aplicaçõesdistribuídas utili zam cada vez mais a Internet;

• o texto [FUG 98] procurou organizar a área de mobili dade, sendo que a taxonomiaapresentada não é dita como “ completamente correta” , necessitando ainda muitosestudos e revisões;

• a linguagem Java pode ser considerada como a principal li nguagem para suporte àmobili dade, uma vez que vários ambientes computacionais são baseados em Java,como foi visto neste texto;

• para ser considerada uma ferramenta ou ambiente que permite implementarmobili dade, a entidade computacional base deve ter o potencial de deslocar-seatravés dos sistemas distribuídos;

• entre os ambientes Voyager, Aglet e Concordia, o primeiro é o mais completo detodos, pois suporta todas as características analisados no Capítulo5, Tabela 2;

• características como suporte à mobili dade através de objetos e agentes móveis,presença de ambiente computacional e mecanismos de segurança parecem sercaracterísticas desejadas em ambientes que permitem explorar mobili dade.

• para explorar mobili dade, é desejável que a tecnologia apresente características comoambiente computacional, suporte a objetos e agentes, suporte a Java, suporte amobili dade forte e fraca, mecanismos de serialização de objetos, mecanismos desegurança, mecanismos de transporte e interação das entidades base, mecanismospara controle de prioridade e persistência.

Trabalhos futuros poderão aperfeiçoar os estudos referentes a ambientes que permitammobili dade, como a identificação de características que devem estar presentes nestesambientes para que à mobili dade possa ser aplicada de forma genérica, isto é, que oambiente suporte mobili dade independentemente do paradigma computacionalutili zado. Na verdade, o Oz Distribuído seria um precursor desta forma de exploraçãode mobili dade.

47

Bibliografia

[AMA 97] AMANDI, Anília. Programação de Agentes or ientada a Objetos.Porto Alegre: CPGCC da UFRGS, 1997. 208p. Tese deDoutorado.

[BAR 98] BARBOSA, Jorge L. V. Paradigmas de desenvolvimento deSistemas Computacionais. Porto Alegre: CPGCC - II - UFRGS,1998. 49p. Trabalho Individual II .

[BAU 97] BAUMANN, J.; HOHL, F.; et al. Communication concepts formobile agent systems. First International Workshop on MobileAgents. Proceedings... Berlin, Germany, April , 1997.

[CAS 98] CASTILLO, A.; KAWAGUCHI, M. et al. Concordia as Enablingtechnology for cooperative Information Gathering.Mitsubishi Eletric ITA, USA, 1998.

[CAR 97] CARZANIGA, A.; PICCO, G.; VIGNA, G. Designing distributedapplications with a mobile code paradigm. 19th InternationalConference on Software Engineering. Proceedings... Boston,may 1997.

[CAR 95] CARDELLI, L. A Language with Distributed Scope. Proceedings...pág. 286-297. ACM Press, 1997. Disponível emhttp://www.research.digital.com/SRC/personal/luca_cardelli/ obliq/

[CUG 96] CUGOLA, G.; GHEZZI, C.; PICCO, G. P.;VIGNA, G. AnalyzingMobile Code Languagens. Mobile Object Systems. SecondInternationa Workshop, MOS’96. Proceedings... Linz, Austria,july 1996. Lecture Notes.

[CHE 96] CHESS, D.; HARRISON, C.; KERSHENBAUM, A. Mobile agents:are they a good idea? Mobile Object Systems. SecondInternationa Workshop, MOS’96. Proceedings... Linz, Austria,july 1996. Lecture Notes.

[DÖM 97] DÖMEL, P.; LINGNAU, A.; DROBNIK, O. Mobile AgentInteraction in Heterogeneous Environments. Mobile ObjectSystems. Second Internationa Workshop, MOS’96.Proceedings... Linz, Austria, july 1996. Lecture Notes.

[FIN 94] FININ, T.; FRITZON, R.; et al. KQML as na AgenteCommunication Language. Third International Conference onInformation and Knowledge Managemente (CIKM’94).Proceedings... ACM Press, November, 1994.

[FLE 98] FLEISCHHAUER, L. Agentes. agosto, 1998. Disponível emhttp://www.eps.ufsc.br/disserta97/amaral/cap3.htm

48

[FUG 98] FUGGETTA, A.; PICCO, G. P.; VIGNA, G. Understanding CodeMobily. IEEE Transactions on Software Engineering. Vol.24,num. 5, May 1998.

[GLA 98] GLASS, Graham. ObjectSpace Voyager - The Agente ORB for Java.Worldwide Computing and its Applications (WWCA’98).Second International Conference. Proceedings... Tsukuba,Japan, march, 1998.

[IBM 98] Industrial and Business Machine corp. The Aglet Homepage.Disponível em http://www.trl.ibm.co.jp/aglets/

[KNA 96] KNABE, F.; Na Overview of mobile agente programming. FifthLOMAPS workshop on Analysis and Verification of MultipleAgent Languages. Proceedings... Stockholm, Sweden, june1996. Lecture Notes

[LAN 97] LANGE, Danny; OSHIMA, Mitsuru; et al. Aglets: programmingMobile Agents in Java. Worldwide Computing and itsApplications (WWCA’97). International Conference.Proceedings... Tsukuba, Japan, march, 1997.

[OBJ 98] ObjectSpace Voyager Core Tecnology 2.0 Disponível emhttp://www.objectspace.com

[OBJ 97] ObjectSpace Voyager Core Tecnology 1.0. Disponível emhttp://www.objectspace.com

[OMG 95] Object Management Group. Disponível emhttp://www.omg.org/corba/

[ORF 96] R. Orfali , D. Hankey, J. Edwards, The Essential Distr ibutedsObjects Survival Guide, John Wiley & Sons, Inc.1996.

[OSH 98] OSHIMA, M. ; LANGE, D. Mobile Agentes with Java: The AgletAPI . Disponível em

[ROY 97] ROY, Peter et al. Mobile Objects in Distributed Oz. ACMTransactions on Programming Languages and Systems.Proceedings... New York, v.19, n.5, p.804-851, september1997.

[ROY 98] ROY, Peter. et al. Three moves are not as bad as fire. January,1998. Tecnical Report.

[RUM 96] RUMBAUGH, James; et al.; Modelagem e Projetos baseados emObjetos. Editora Campus, Rio de Janeiro, 1996.

[SUN 96] Sun Microsystems. The Source for Java tecnology. Disponível emhttp://java.sun.com/

[THO 97] THORN, T. Programming Languages for M obile Code. INRIATecnical Report 3134, France, Mar 1997

49

[WON 97] WONG, D.; PACIOREK, N.; WALSH, T.; et al. Concordia: naInfrastructure for Collaborating Mobile Agents. FirstInternational Workshop on Mobile Agents. Proceedings...Berlin, Germany, April , 1997.