ARQUITETURA DE UMA REDE DISTRIBUÍDA FUNDAMENTADA NA TECNOLOGIA JINI

Ana Cristina Barreiras Kochem, Dulte José de Barros Centro Federal de Educação Tecnológica do Paraná, CEFET-PR / CPGEI

Av. Sete de Setembro 3165, Curitiba-PR, 80230-901 criskochem@openbsd.org.br, barros@daeln.cefetpr.br

Resumo O objetivo desse trabalho é realizar um estudo sobre a arquitetura de uma rede distribuída fundamentada na tecnologia Jini [1,2,3,4,5]. Construída sobre a linguagem de programação Java [6], a tecnologia Jini permite interconectar vários dispositivos em uma rede, utilizando um sistema plug-and-play, o qual dispensará a necessidade de drivers de dispositivos. Assim, os serviços podem se unir dinamicamente à rede, sendo descobertos e utilizados pelos clientes posteriormente. Como aplicativo para esta rede, desenvolve-se um serviço de comunicação distribuído utilizando JavaSpaces [7], correspondente a um serviço Jini que fornece um armazenamento persistente para os objetos Java. Através do uso dessa tecnologia pode-se obter uma solução mais automatizada de fazer com que computadores, dispositivos e softwares se comuniquem de forma inteligente, removendo as tradicionais barreiras de compatibilidade, confiabilidade e administração que dificultam a implementação de redes heterogêneas.

Palavras-chave: Sistemas Distribuídos, Redes de Computadores, Protocolos, Jini, Java, JavaSpaces, Invocação de Métodos Remotos (RMI)

Abstract

The aim of this work is to accomplish a study on the architecture of a distributed network based on the Jini technology [1,2,3,4,5]. Built on the Java programming language [6], the Jini technology allows to interconnect several devices in a network, using a plug-and-play system, which will spare the need of devices drivers. Thus, the services can dynamically join the network, being discovered and used by the clients later. As application for this network, it develops a distributed communication service using JavaSpaces [7], corresponding to a Jini service that supplies a persistent storage for the Java objects. Through the use of that technology it can be obtained a more automated solution of making computers, devices and softwares communicate each other in an intelligent way, removing the traditional compatibility, reliability and administration barriers that hinder the implementation of heterogeneous networks.

Keywords : Distributed Systems, Computer Networks, Protocols, Jini, Java, JavaSpaces, Remote Method Invocation (RMI)

Introdução

A tecnologia Jini, utilizada para possibilitar a comunicação entre objetos remotos em uma rede distribuída, vem sendo desenvolvida desde 1994 nos laboratórios de pesquisa da Sun Microsystems em Aspen, Colorado [8].

Como essa tecnologia, correspondente a uma interface de rede inteligente, é

fundamentada na linguagem de programação Java, ela é independente da plataforma, podendo ser executada em uma grande variedade de hardwares e sistemas operacionais. Além disso, ela possui um mecanismo de gerenciamento automático, impedindo que ocorram “estouros” de pilhas ou alocação desnecessária de memória.

Uma rede distribuída Jini permite que seus usuários compartilhem serviços e recursos da rede, formando uma comunidade improvisada sem planejamento, instalação ou intervenção humana. Para isso, impressoras, scanners, máquinas fotográficas digitais e outros periféricos devem incluir um pequeno chip capaz de rodar programas Java para permitirem a comunicação direta entre um periférico e outro.

As Forças Armadas dos Estados Unidos estão empregando a tecnologia Jini como uma

solução para interconectar vários equipamentos sofisticados em uma rede implementada nos seus postos de comandos de batalha, conhecidos como Centros de Operação Tática (Tactical Operation Centers – TOCs) [9].

Esses TOCs são usados para monitorar, executar e planejar um campo de batalha. A tecnologia Jini possibilita a interconexão de várias plataformas de hardware e software em uma configuração TOC, reduzindo o custo e a complexidade na administração do sistema, e permite que os serviços disponíveis em um TOC obtenham informações de várias aplicações e se conectem dinamicamente à rede, anunciando suas disponibilidades aos outros serviços. A tecnologia Jini se adapta facilmente a um campo de batalha, permitindo que os TOCs mantenham a mobilidade, a estabilidade e a segurança em uma rede.

Nas próximas seções são descritos os protocolos de comunicação discovery, join e lookup, os serviços de lease, eventos remotos, armazenamento persistente e transações.

Os protocolos discovery [10] são utilizados para encontrar servidores lookup [11] na rede.

Encontrado um servidor, o serviço utiliza o protocolo join [10] para se registrar nesse servidor. Após realizado o registro, o servidor retornará um lease [12] para o serviço, que determinará o tempo em que esse serviço permanecerá disponível no servidor. O protocolo lookup [13] é utilizado pelos clientes para procurarem os serviços disponíveis na rede que possam auxilia-los na realização de suas metas.

Os eventos remotos [14] são utilizados para emitir notificações aos serviços da rede quando mudanças de estado ocorrem em outros objetos.

Os serviços Jini e os clientes podem obter um armazenamento persistente para os objetos

distribuídos Java, através de um serviço JavaSpaces [7], e ainda pesquisar tais objetos armazenados e removê-los do JavaSpaces quando não forem mais necessários.

Também são vistas questões relativas às transações [15], que garantem a unicidade de

operações em um sistema distribuído. Ao final é apresentado um exemplo de um aplicativo que demonstra todos os recursos que podem ser viabilizados através da tecnologia Jini.

1 Protocolos de Comunicação

1.1 Protocolos Discovery

Os protocolos discovery [10] são utilizados pelos serviços para encontrarem um servidor lookup [11], cujo objetivo é referenciar ou armazenar o serviço, que suporte as comunidades das quais eles desejam participar. Os protocolos discovery são responsáveis pela construção instantânea de comunidades no sistema.

Cada comunidade corresponde a um conjunto de serviços que estão disponíveis na rede,

sendo que cada serviço pode representar dispositivos de hardware, software (como aplicações ou utilitários) ou informações (como base de dados e arquivos).

Um serviço pode ser representado por um ou mais objetos que residem dentro de um provedor. A primeira tarefa do provedor é registrar o serviço em um servidor lookup que representa os serviços disponíveis em uma determinada comunidade Jini e fornece facilidades para pesquisar e encontrar tais serviços.

Para que o provedor de serviços possa encontrar um servidor lookup ou para que um

servidor possa anunciar a sua presença na rede, eles devem utilizar uma família de protocolos discovery, representada pelos protocolo de pedido multicast, protocolo de anunciamento multicast e protocolo discovery unicast.

1.1.1 Protocolo de Pedido Multicast

Quando um novo serviço é iniciado e ele deseja se unir a uma comunidade Jini, ele utiliza o protocolo de pedido multicast. Este protocolo é utilizado para encontrar todos os servidores lookup que estejam em execução na rede e obter o proxy [16] (objeto que implementa as interfaces de um serviço, ditando o que esse serviço é capaz de oferecer) desses servidores.

O serviço enviará uma mensagem de pedido para um endereço multicast conhecido e para

uma porta padrão, onde todos os servidores lookup Jini estarão escutando (ver Figura 1). Nessa mensagem, enviada através do Protocolo de Datagrama do Usuário (User Datagram Protocol - UDP) [17], o serviço especifica a comunidade a qual ele deseja se unir.

Uma vez que um servidor lookup, que suporte a comunidade especificada na mensagem,

tenha recebido o pedido, ele estabelecerá uma conexão com o serviço e lhe enviará uma mensagem unicast contendo o seu proxy para que o serviço possa se comunicar diretamente com ele através da invocação de métodos nesse proxy.

O serviço terá que criar dois sockets, um para enviar mensagens UDP multicast e o outro

para receber mensagens do Protocolo de Controle de Transmissão (Transmission Control Protocol - TCP) [17] unicast. O servidor lookup, que participa do protocolo de pedido multicast, também terá que estabelecer dois sockets, um para receber mensagens UDP multicast do serviço e o outro para enviar mensagens TCP unicast.

SSEERRVVIIÇÇOO SSEERRVVIIDDOORR LLOOOOKKUUPP Mensagem de Pedido (enviada através do UDP Multicast) Mensagem de Resposta (enviada através do TCP Unicast)

FIGURA 1 – Protocolo de Pedido Multicast

1.1.2 Protocolo de Anunciamento Multicast

O protocolo de anunciamento multicast é utilizado durante toda a vida útil de um servidor lookup para anunciar sua presença na rede aos serviços interessados.

No anunciamento multicast, os serviços da rede escutam os anúncios sobre a existência

dos servidores lookup em um endereço multicast conhecido. Periodicamente, todos os servidores lookup conectados a rede enviam uma mensagem multicast, contendo a sua localização, para este endereço (ver Figura 2).

Quando um serviço receber uma mensagem de anunciamento da existência de um

servidor que seja do seu interesse, ele poderá se conectar a esse servidor através do TCP unicast e obter o proxy desse servidor.

SSEERRVVIIÇÇOO SSEERRVVIIDDOORR LLOOOOKKUUPP Mensagem de Anunciamento (enviada através do UDP Multicast)

Mensagem de Resposta (enviada através do TCP Unicast) Mensagem de Resposta (enviada através do TCP Unicast)

FIGURA 2 – Protocolo de Anunciamento Multicast

A razão pela qual o servidor lookup não envia de uma vez o seu proxy, na mensagem de

anunciamento multicast, é porque o protocolo multicast dita um tamanho máximo de datagrama que é extremamente pequeno (512 bytes) [2]. Devido aos objetos proxy serem arbitrariamente grandes, não há nenhuma garantia de que eles caberão dentro dos limites de uma mensagem multicast.

PPrrooxxyy ddoo SSeerrvviiddoorr

PPrrooxxyy ddoo SSeerrvviiddoorr

1.1.3 Protocolo Discovery Unicast

Esse protocolo é utilizado durante o curso dos dois protocolos multicast (protocolo de pedido multicast e protocolo de anunciamento multicast) e também pode ser usado para estabelecer comunicações com um servidor lookup específico em uma Rede de Longa Distância (WAN). Para isso, o protocolo unicast requer informações específicas sobre a localização do servidor lookup, incluindo o nome do host no qual o servidor lookup está sendo executado e o número da porta na qual ele está escutando as mensagens de pedidos enviadas pelos serviços.

1.2 Protocolo Join

Uma vez obtido o proxy de um servidor lookup através de um dos protocolos discovery, o serviço estará pronto para executar o protocolo join [10], tornando-se parte da comunidade de serviços que estão registrados nesse servidor.

Para se registrar com o servidor lookup, o serviço invocará o método register() declarado

na interface ServiceRegistrar [11] implementada pelo proxy do servidor recebido, passando como argumento um item do serviço (ver Figura 3).

Esse item, exclusivo para um determinado serviço, é armazenado no servidor lookup.

Cada item conterá atributos [18] que descrevem o serviço (tais como: nome e localização do serviço), uma identificação de 128 bits para esse serviço e um objeto proxy, que poderá ser carregado por um cliente para que o mesmo possa interagir com o serviço.

SSEERRVVIIÇÇOO SSEERRVVIIDDOORR LLOOOOKKUUPP

Lease

FIGURA 3 – Serviço se registrando através do Protocolo Join

Quando um serviço já estiver registrado com o servidor lookup, ele receberá um lease que determinará o tempo em que ficará registrado nesse servidor. Enquanto o serviço estiver ativo, seu lease deverá ser renovado. Caso contrário, o lease irá expirar e o serviço será excluído do servidor lookup, liberando todos os recursos que estavam alocados para manter o registro deste serviço.

Itens do Serviço

IItteemm ddoo SSeerrvviiççoo PPrrooxxyy ddoo SSeerrvviiddoorr

PPrrooxxyy ddoo SSeerrvviiççoo

PPrrooxxyy

AAttrriibbuuttooss

1.3 Protocolo Lookup

Após um servidor lookup ter sido encontrado através de um dos protocolos discovery e uma vez que um serviço tenha se registrado com este servidor através do protocolo join, este serviço estará disponível para ser utilizado pelos clientes quando necessário.

O protocolo lookup [13] permite que um cliente procure, nos servidores lookup, os serviços que possam auxiliá-lo na realização de suas metas.

Quando um cliente desejar utilizar um serviço, ele precisará encontrar o item desse

serviço, depois o objeto proxy do serviço será copiado para a sua Máquina Virtual Java (Java Virtual Machine - JVM) [6] para que ele possa interagir com o serviço. Para isso, primeiro o cliente precisará obter o proxy do servidor lookup, através de um dos protocolos discovery. Após obtido esse proxy, o cliente poderá executar o protocolo lookup, invocando o método lookup() declarado na interface ServiceRegistrar implementada pelo objeto proxy do servidor recebido quando o cliente se registrou na rede.

Como argumento na chamada a esse método, o cliente passará um template que será

utilizado para realizar a procura por um serviço em um servidor lookup (ver Figura 4).

SSEERRVVIIDDOORR LLOOOOKKUUPP

FIGURA 4 – Protocolo Lookup

Template

PPrrooxxyy ddoo SSeerrvv iiççoo

CCLLIIEENNTTEE SSEERRVVIIÇÇOO

PPrrooxxyy

Item do Serviço

PPrrooxxyy AAttrriibbuuttoo

AAttrriibbuuttoo

Um template pode ser utilizado para procurar um proxy do serviço que implementa uma determinada interface. A procura também pode ser efetuada pela identificação do serviço ou pelos atributos que o descrevem.

Por exemplo, se um cliente desejar encontrar um serviço de impressão, ele pode procurar por um proxy que implementa a interface Printer que é uma interface padrão para todas as impressoras Jini. Um cliente também pode desejar encontrar um serviço de impressão que esteja em um determinado andar de um edifício, realizando assim a procura pelo valor do atributo location (localização) do serviço.

Se um serviço for encontrado no servidor lookup, o cliente receberá um proxy desse

serviço. Uma vez que o cliente tenha carregado esse proxy em sua máquina, ele poderá interagir com o serviço (sem intervenção do servidor lookup) através da Invocação de Métodos Remotos (Remote Method Invocation – RMI) [19] na(s) interface(s), escrita(s) na linguagem de programação Java e implementada(s) pelo objeto proxy obtido.

A idéia de carregar proxies do serviço é a chave que dá ao Jini sua habilidade para usar

serviços e dispositivos sem precisar instalar qualquer driver ou software.

2 Lease

O lease [12] é um recurso Jini que permite a concessão de recursos e serviços por certos períodos de tempo, evitando o uso ilimitado dos mesmos. Um lease é negociado por dois objetos: um concessionário do lease (objeto que concede o acesso a um recurso por um determinado período) e o portador do lease (objeto que solicita o recurso).

Quando um recurso for solicitado por um portador, o concessionário retornará a esse

portador um objeto Lease (ver Figura 5). A invocação de métodos nesse objeto fará com que mensagens trafeguem entre o portador e o concessionário para atualizar o estado do lease no concessionário.

CCOONNCCEESSSSIIOONNÁÁRRIIOO DDOO LLEEAASSEE PPOORRTTAADDOORR DDOO LLEEAASSEE

Protocolo Privado

FIGURA 5 – Negociação entre o concessionário do lease e o portador do lease

RReeccuurrssooss

IInnffoorrmmaaççõõeess ssoobbrree oo

eess ttaaddoo ddoo lleeaassee

LLeeaassee

Um lease pode ser solicitado por um objeto para obter acesso a um recurso, para receber notificações de eventos ocorridos, para utilizar um serviço de armazenamento persistente como o serviço JavaSpaces ou para anunciar sua disponibilidade nos servidores lookup.

O período de tempo de um lease pode ser determinado exclusivamente pelo

concessionário do lease ou pode ser negociado entre o concessionário e o portador do lease. A negociação permite que o objeto que for solicitar o lease indique o tempo desejado e o concessionário retorne um lease que não tenha um tempo de duração maior do que o solicitado, porém, ele poderá retornar um lease com um período de tempo menor.

Durante o tempo de um lease, ele pode ser cancelado pelo objeto que mantém o lease,

quando o mesmo não for mais necessário. Tal cancelamento permite que o concessionário do lease libere quaisquer recursos que estejam associados a esse lease.

O portador do lease pode solicitar que um lease seja renovado antes que ele expire. O

período de renovação pode ser diferente do tempo do lease original e também é negociado com o concessionário do lease, que poderá renovar o lease com o período de tempo solicitado, com um período menor ou até recusar a renovação do lease.

Porém, se o lease não for renovado, ele irá expirar e todos os recursos associados a ele

serão liberados pelo concessionário do lease. A expiração de um lease é similar ao seu cancelamento, exceto pelo fato de que não há necessidade de comunicação entre o portador e o concessionário do lease.

3 Eventos Remotos

Um evento [14] é algo que acontece em um objeto, correspondendo a alguma mudança no estado abstrato desse objeto.

A arquitetura Jini suporta eventos remotos (distribuídos). O propósito das interfaces de

eventos remotos é permitir que um objeto em uma JVM registre interesse na ocorrência de algum evento que esteja ocorrendo em um outro objeto em alguma outra JVM (provavelmente em um host diferente) e receba uma notificação da ocorrência de tal evento (ver Figura 6).

Um objeto pode solicitar a um servidor lookup que lhe envie notificações de eventos quando, por exemplo, um novo serviço se tornar disponível na rede, quando estes não estiverem mais disponíveis ou quando o conjunto de atributos que descrevem o serviço for modificado.

Os objetos concretos envolvidos em um sistema de eventos remotos são:

a) gerador de eventos: objeto no qual ocorrem os eventos que podem ser de interesse

para outros objetos, permitindo a estes objetos registrarem interesse nesses eventos. O gerador de eventos é quem irá gerar as notificações quando os eventos solicitados ocorrerem, enviando essas notificações para os ouvintes de eventos que foram indicados no registro de interesse nesse tipo de evento;

b) ouvinte de eventos remotos: objeto que está interessado na ocorrência de alguns tipos

de eventos em um outro objeto. Sua função principal é receber notificações da ocorrência de um evento.

FIGURA 6 – Registro e notificação da ocorrência de um evento remoto

4 Serviço JavaSpaces

O JavaSpaces [7] é um serviço Jini através do qual serviços e clientes podem adquirir um

armazenamento para os objetos distribuídos Java, por um determinado intervalo de tempo, pesquisar tais objetos armazenados e removê-los do espaço quando não forem mais necessários.

O modelo de programação do JavaSpaces é bem simples e pode ser usado como base para

a construção de aplicações distribuídas. Um conjunto de aplicações pode compartilhar o uso de um JavaSpaces para depositar e restaurar objetos. Os objetos que são armazenados em um espaço podem representar um trabalho a ser realizado e assim ser usado para construir aplicações distribuídas estilo produtor/consumidor ou simples parcelas de dados.

O serviço JavaSpaces pode ser encontrado através do protocolo lookup e usado através de seu proxy, assim como qualquer outro serviço Jini. O JavaSpaces é o único serviço Jini que utiliza e suporta transações, fornecendo assim uma forma de lidar com as falhas parciais ocorridas em sistemas distribuídos.

5 Transações

As transações [15] solucionam o principal problema ocorrido nos sistemas distribuídos – as falhas parciais, pois elas agrupam um conjunto de operações e as executam simultaneamente de modo que todas sejam executadas com sucesso ou que todas falhem.

Os componentes de uma transação são:

a) Cliente da transação: objeto que pede ao gerente da transação para criar uma transação;

b) Gerente da transação: objeto que atende ao pedido do cliente, criando uma transação, e

gerencia toda essa transação enviando a cada participante uma mensagem indicando para qual estado esse participante deve mudar;

c) Participante da transação: objeto que executa as operações em uma transação e

interage com o gerente para completar a transação corretamente.

Registro de interesse em um tipo particular de evento

Objeto indicando que um evento do tipo solicitado ocorreu

GGeerraaddoorr

ddee EEvveennttooss

EEvveennttoo RReemmoottoo

OOuuvviinnttee ddee

EEvveennttooss RReemmoottooss

6 Implementação

Como um exemplo de um aplicativo para uma rede fundamentada na tecnologia Jini, foi

implementado um serviço interativo de mensagens, tomando como base um exemplo de [7], que possibilita que um usuário mantenha uma lista de amigos online e se comunique com eles.

Na construção desse serviço, utilizou-se todos os recursos oferecidos pela tecnologia Jini, incluindo eventos remotos, lease, transações e as operações disponíveis em um serviço JavaSpaces.

Foram utilizados eventos remotos para notificar um usuário quando uma mensagem de um amigo for enviada para ele, possibilitando que esse usuário leia sua mensagem. O lease foi usado para assegurar que um serviço de mensagens não mais existirá quando o seu usuário tiver sido desconectado dele. No caso de transações, elas foram responsáveis por garantir a robustez de um ambiente distribuído, mesmo em frente de uma falha parcial ocorrida na rede.

Para construir esse serviço, foram usados três componentes: uma janela de login do usuário, uma janela contendo uma lista de amigos online e uma janela de mensagens.

A janela de login do usuário (ver Figura 7), aparecerá quando o serviço de mensagens for

iniciado. Nessa janela são solicitados: o nome e a senha do usuário. Quando um usuário se registra no serviço pela primeira vez, a interface de mensagens cria

uma nova conta para esse usuário e escreve seu nome e sua senha em um serviço JavaSpaces. Isso serve para reservar um único nome para o usuário e permitir que ele seja autenticado, em logins futuros, através de sua senha.

Figura 7 – Janela de Login do Usuário

Se um usuário já existente tentar entrar com uma senha inválida, o mesmo receberá uma mensagem de advertência “Senha Inválida”. Assim, o usuário deverá digitar sua senha novamente e, quando esta estiver correta, ele será conectado e poderá utilizar o serviço de mensagens.

Uma vez que o usuário esteja conectado, lhe será apresentado uma janela contendo a lista

de seus amigos online (ver Figura 8). Essa janela possui um botão “Adicionar” e um campo de texto que permite ao usuário digitar o nome de um amigo e adicioná-lo à sua lista de amigos online.

Figura 8 – Janela contendo a lista de amigos online do usuário Quando o amigo, adicionado à lista, se registrar com o serviço de mensagens, seu nome

será exibido automaticamente na área de texto “Amigos Online” do usuário. Um usuário pode adicionar qualquer número de amigos à sua lista. Se um amigo do usuário, adicionado à lista, se desconectar do serviço, seu nome desaparecerá da lista dos amigos online desse usuário.

Quando o usuário quiser enviar uma mensagem para um amigo, basta clicar no nome

desse amigo contido na lista e uma janela de mensagens aparecerá (ver Figura 9). Nessa janela, o usuário poderá digitar a mensagem desejada no campo de texto “Mensagem” e clicar no botão “Enviar” para enviá-la. A mensagem digitada pelo usuário será mostrada na sua própria janela, juntamente com a hora atual do sistema, e enviada para o serviço de mensagens do amigo remoto com o qual o usuário está conversando.

Figura 9 – Janela de Mensagens do Usuário Uma janela de mensagens aparecerá automaticamente quando o amigo remoto receber a

mensagem. Da mesma forma, se o usuário receber uma mensagem de um amigo, uma nova janela será aberta automaticamente (se já não houver uma janela aberta para esse amigo). Cada conversa com um amigo diferente possui sua própria janela.

Quando um usuário terminar de usar o serviço de mensagens, ele pode fechar sua janela.

Assim, seu nome será retirado de todas as listas de amigos online, as quais ele foi adicionado, para possibilitar que seus amigos vejam que ele não está mais conectado.

Conclusão

A tecnologia Jini fornece grandes vantagens para a implementação de sistemas distribuídos, pois se pode diminuir a carga de administração da rede uma vez que não são necessários softwares de configuração de drivers de dispositivos.

O agente proxy necessário para a comunicação entre um cliente e um provedor de serviços

torna-se disponível através de download, a partir de um servidor lookup. Além do mais, como a tecnologia Jini é fundamentada na linguagem de programação Java, ela pode rodar em qualquer dispositivo microprocessado, desde eletrodomésticos como torradeiras, televisores, fornos de microondas, até computadores, servidores de banco de dados e equipamentos de automação industrial.

A infra-estrutura de rede Jini fornece um mecanismo de alocação de recursos da rede, o

qual permite que um recurso possa estar disponível para um cliente por um determinado intervalo de tempo (evitando a alocação de recursos não utilizados, o que implicaria em um alto consumo de memória), e um serviço de transação que garante a unicidade de operações envolvidas em bancos de dados distribuídos.

Devido a essas características, torna-se possível a interação entre serviços em sistemas heterogêneos distribuídos tanto a nível de hardware, quanto a nível de software.

Como proposta para um próximo artigo pretende-se realizar um estudo comparativo entre

as tecnologias Jini e Bluetooth [20,21,22]. O consórcio Bluetooth foi formado em 1998 pelas empresas Ericsson, Nokia, IBM, Intel e Toshiba, como um método de comunicação por rádio que faz celulares, televisões e computadores conversarem entre si.

Agradecimento

Os autores deste artigo gostariam de agradecer Susanne Hupfer pelo auxílio na geração das classes e interfaces necessárias para a implementação do serviço interativo de mensagens demonstrado na seção 6.

Referências Bibliográficas

[1] ARNOLD, Ken; O’SULLIVAN, Bryan; SCHEIFLER, Robert W.; WALDO, Jim;

WOLLRATH, Ann. The Jini Specification. Massachusetts: Addison-Wesley Pub Co., 1999.

[2] EDWARDS, W. Keith. Core Jini. Upper Saddle River – NJ: Prentice Hall PTR, 1999. [3] KOCHEM, Ana Cristina Barreiras. Tecnologia Jini. Cianorte, 2000. Monografia (Gradução

em Ciência da Computação), UNIPAR – Universidade Paranaense. [4] KOCHEM, Ana Cristina Barreiras; SHIGUETA, Roni Francis. Implementação de uma Infra-

estrutura de Rede Distribuída Utilizando a Tecnologia Jini. In: I Congresso de Lógica Aplicada à Tecnologia, 2000. Anais LAPTEC’2000. São Paulo: SENAC.

[5] KOCHEM, Ana Cristina Barreiras; SHIGUETA, Roni Francis. Utilização da tecnologia Jini

como uma solução para a comunicação de objetos distribuídos em ambientes de redes heterogêneas. In: V Encontro Anual de Pesquisa e de Iniciação Científica (ENAPI). Anais ENAPI, 2000. Presidente Prudente - SP: UNOESTE.

[6] CORNELL, Gary; HORSTMANN, Cay S. Core Java. São Paulo MAKRON Books do Brasil

Editora Ltda, 1998. [7] FREEMAN, Eric; HUPFER, Susanne; ARNOLD, Ken. JavaSpaces Principles, Patterns, and

Practice: Tutorial and Reference Guide. Massachusetts: Addison-Wesley Pub Co., 1999. [8] SUN MICROSYSTEMS. Scott McNealy and Bill Joy Talk about Jini Connection Technology.

Consultado na INTERNET, em 30 de dezembro de 2000. http://www.sun.com/java/jini/ [9] SUN MICROSYSTEMS. Mission-Critical Deployment Sun’s Jini Tecnology Drafted for

Service in the U.S. Army. Consultado na INTERNET, em 01 de outubro de 2000. http://www.sun.com/dot-com/studies/jiniinthearmy.html.

[10] SUN MICROSYSTEMS. DJ - Discovery and Join. Consultado na INTERNET, em 10 de março de 2000. http://www.sun.com/jini/specs/jini1.1html/discovery-spec.html

[11] SUN MICROSYSTEMS. LU - Lookup Service. Consultado na INTERNET, em 15 de março

de 2000. http://www.sun.com/jini/specs/jini1.1html/lookup-spec.html [12] SUN MICROSYSTEMS. LE - Distributed Leasing. Consultado na INTERNET, em 01 de

abril de 2000. http://www.sun.com/jini/specs/jini1.1html/lease-spec.html [13] SUN MICROSYSTEMS. Jini Technology Architectural Overview. Consultado na

INTERNET, em 15 de fevereiro de 2000. http://www.sun.com/jini/whitepapers/ architecture.html

[14] SUN MICROSYSTEMS. EV - Distributed Event. Consultado na INTERNET, em 01 de abril

de 2000. http://www.sun.com/jini/specs/jini1.1html/event-spec.html [15] SUN MICROSYSTEMS. TX - Transaction. Consultado na INTERNET, em 01 de maio de

2000. http://www.sun.com/jini/specs/jini1.1html/txn-spec.html [16] SUN MICROSYSTEMS. Chapter 1: Overview of Jini. Consultado na INTERNET, em 10 de

maio de 2000. http://pandonia.canberra.edu.au/java/jini/tutorial/Overview.xml# Proxies [17] TANEMBAUM, Andrew S. Redes de Computadores. 3. ed. Rio de Janeiro: Campus, 1997. [18] SUN MICROSYSTEMS. LS - Jini Lookup Attribute Schema Specification. Consultado na

INTERNET, em 25 de março de 2000. http://www.sun.com/jini/specs/jini1.1html/ schema-spec.html

[19] DOWNING, Troy B. Java RMI: Remote Method Invocation. Foster City, CA: IDG Books

Worldwide, 1998. [20] Jennifer Bray, Charles Sturman. Bluetooth: Connect Without Cables. Upper Saddle River –

NJ: Prentice Hall PTR, 2000. [21] Bluetooth Special Interest Group. Specification of the Bluetooth System. Volume 1: Core,

v1.0B, December 1999 [22] Bluetooth Special Interest Group. Specification of the Bluetooth System. Volume 2: Profiles,

v1.0B, December 1999