Sing Li - PUC-Rio

Jini e Redes Espontâneas
PUC-Rio
Introdução à Computação Móvel - 2001.2
Marcus Amorim Leal
Índice
1.INTRODUÇÃO .................................................................................................................. 2
2.A TECNOLOGIA JINI ...................................................................................................... 3
2.1.PROTOCOLOS DE DESCOBERTA E AGREGAÇÃO ......................................................... 5
2.2.SERVIÇO DE BUSCA ..................................................................................................... 8
2.3.INTERFACE DE LEASING ............................................................................................. 10
2.4.EVENTOS DISTRIBUÍDOS ............................................................................................ 10
2.5.TRANSAÇÕES ............................................................................................................. 11
2.6.SERVIÇOS................................................................................................................... 12
3.REDES ESPONTÂNEAS ............................................................................................. 15
3.1.TOLERÂNCIA A FALHAS .............................................................................................. 15
3.2.MODELO DE SEGURANÇA .......................................................................................... 16
3.3.FLEXIBILIDADE ............................................................................................................ 18
3.4 EXEMPLOS .................................................................................................................. 18
4.CONCLUSÃO ................................................................................................................. 20
BIBLIOGRAFIA ................................................................................................................. 22
1
1.Introdução
A evolução na tecnologia de fabricação de semicondutores, sobretudo ao longo da última
década, está viabilizando o desenvolvimento de uma gama crescente de aplicações em
diferentes segmentos industriais. Diante de preços em contínua queda, microprocessadores
vem sendo incorporados a equipamentos tradicionais, de automóveis a geladeiras, bem
como dando vida a inovações singulares como PDAs e aparelhos de DVD. Paralelamente a
isso, a venda e a utilização de microcomputadores ampliam-se em um ritmo acelerado,
impulsionando uma verdadeira revolução em nossa sociedade.
Esta ubiquidade de recursos computacionais gerou novos e importantes desafios para a área
de computação. Equipamentos cada vez mais heterogêneos precisam ser integrados de
forma dinâmica, quase sempre transparente, e muitas vezes de forma imprevisível,
compondo sistemas robustos e persistentes. Mobilidade e adaptabilidade tornaram-se uma
importante demanda de usuários, constituíndo também um tema central no projeto de
sistemas distribuídos.
Jini é uma tecnologia concebida para suportar os inúmeros requisitos deste novo ambiente
computacional populado por equipamentos inteligentes, possibilitando a construção de
redes dinâmicas, constituídas por componentes heterogêneos, adaptáveis e autoconfiguráveis. Jini não é um sistema operacional distribuído no sentido clássico do termo,
mas apenas um conjunto de classes e interfaces que definem um modelo funcional para
sistemas distribuídos, facilitando sobremaneira a construção de redes dinamicamente
configuráveis, e estendendo a plataforma Java para este contexto (ver figura 2.1).
Uma rede Jini é constituída apenas por dois tipos de entidades: clientes e serviços. Serviços
são abstrações que podem representar qualquer tipo de componente, software ou hardware,
que ofereça uma ou mais funcionalidades através da rede. Exemplos incluem impressoras,
dispositivos de armazenamento, bibliotecas de funções, etc. Clientes representam as
entidades que consomem os serviços da rede, podendo incluir desde dispositivos com
interfaces gráficas até as próprias entidades que implementam os serviços da rede.
2
Serviços e clientes em uma rede Jini são agrupados em clusters denominados federações. A
comunicação entre membros de uma federação obedece a um conjunto de protocolos que
possibilita:
-
A habilidade de adicionar um serviço ou cliente a qualquer momento sem afetar a
operação da rede.
-
A habilidade de remover um serviço a qualquer momento, de forma controlada ou
abrupta, sem acarretar falhas críticas na operação da rede.
-
A habilidade para clientes ou serviços se moverem fisicamente dentro de uma
mesma rede.
2.A Tecnologia Jini
O conjunto de classes e interfaces que compõe a arquitetura Jini é implementado em Java,
utilizando-se particularmente das facilidades disponibilizadas por Java RMI (Remote
Method Invocation), notadamente a habilidade de dinamicamente transferir e executar
trechos de código. Mas apesar do papel central de Java nesta arquitetura a implementação
de um serviço em uma rede Jini pode ser efetuada através de qualquer combinação de
hardware e software, sem restrições a linguagens de programação, conforme veremos mais
adiante. É necessário apenas que cada serviço da rede implemente uma interface Java
através da qual suas funcionalidades tornam-se acessíveis a clientes.
3
Figura 2.1 - A Arquitetura Jini
Os componentes da arquitetura Jini podem ser agrupados seguindo a classificação
apresentada na tabela 2.1. A infraestrutura define as regras básicas de operação de uma rede
Jini. O modelo de programação define APIs que estabelecem uma semântica que deve ser
observada na implementação de serviços e aplicações. Por fim, serviços são as entidades
genéricas que compõe uma rede Jini e disponibilizam funcionalidades para clientes. Nas
seções seguintes detalhamos cada um destes componentes básicos.
Infraestrutura
Modelo de
Serviços
Programação
Java
Java + Jini
-Java VM
-Java APIs
-Enterprise Beans
-RMI
-JavaBeans
-JNDI
-Modelo de Segurança
-...
-...
-Protocolos de Descoberta -Leasing
-Impressão
e Agregação
-Eventos Distribuídos
-JavaSpaces
-Serviço de Busca
-Transações
-...
Tabela 2.1 - Arquitetura Jini x Java
4
2.1.Protocolos de Descoberta e Agregação
Um serviço torna-se acessível a clientes de uma rede Jini somente após registrar-se junto a
uma entidade ou tipo especial de serviço denominado serviço de busca1 (look-up service).
Clientes por sua vez podem acessar serviços genéricos da rede apenas através de um
serviço de busca. Para que um serviço de busca possa ser encontrado, e novos serviços
eventualmente registrem-se junto ao mesmo, Jini define um conjunto de protocolos
denominados descoberta e agregação (discovery and join protocols). Três diferentes
protocolos de descoberta são implementados:
-
Multicast Request Protocol - Utilizado quando um serviço ou cliente se conecta a
rede pela primeira vez e precisa descobrir o serviço de busca mais próximo.
-
Multicast Announcement Protocol - Utilizado pelos serviços de busca para anunciar
a sua presença. Sempre que um serviço de busca se conecta a rede ele utiliza este
protocolo.
-
Unicast Discovery Protocol - É utilizado quando um serviço ou cliente já conhece o
endereço do serviço de busca com o qual deseja se comunicar.
Os dois primeiros protocolos utilizam-se dos serviços de multicast do protocolo IP. A
implementação do IP multicast emprega uma classe especial de endereços IP (classe D) que
define os grupos multicast. Datagramas UDP (não confiáveis) com endereço de multicast
são roteados através de algoritmos especiais (baseados em árvores geradoras mínimas) e
entregues a todos os membros do grupo definido pelo endereço.
Quando um serviço se conecta a rede Jini ele envia uma mensagem para um endereço IP
multicast conhecido, ao qual estão associados os serviços de busca. Ao receber esta
mensagem o serviço de busca verifica o endereço IP do remetente e estabelece com ele uma
conexão TCP. Através dessa conexão o serviço de busca envia então um proxy2 que deverá
1
2
Toda federação possui ao menos um serviço de busca.
Um proxy é um objeto que representa localmente um objeto remoto.
5
ser executado no contexto do cliente, tornando-se responsável por gerenciar as solicitações
deste associadas ao serviço de busca.
Cabe aqui uma observação quanto ao tamanho ou abrangência de uma rede Jini. Por
questões de eficiência uma federação Jini geralmente abrange apenas o ambiente de uma
rede local, ou seja, algumas centenas de entidades. Entretanto uma rede Jini pode ser
composta por dezenas de federações, e serviços de uma federação podem ser acessados por
outras federações através de mecanismos que discutiremos mais adiante. Para minimizar a
interferência entre federações preservando a localidade das redes, os protocolos de
descoberta utilizam-se de um parâmetro especial dos datagramas IP denominado TTL (time
to live). Este parâmetro especifica o número de saltos (hops) que um pacote pode dar na
medida em que viaja pela rede. Ao atingir este limite de vida, o pacote é simplesmente
descartado pelo roteador.
Periodicamente os serviços de busca enviam mensagens multicast para todos os serviços da
federação anunciando sua presença. Qualquer serviço que por ventura não tenha
conseguido conectar-se ainda ao serviço de busca pode então estabelecer um conexão TCP
e iniciar o processo de registro.
O processo através do qual um serviço publica suas funcionalidades na federeção é
chamado agregação ou ingresso na comunidade. O proxy enviado pelo serviço de busca por
ocasião de uma descoberta implementa uma interface Java denominada ServiceRegister,
que inclui como método principal register(). Através da execução de register() o serviço
genérico envia para o serviço de busca o seu próprio proxy, juntamento com atributos que
descrevem as suas funcionalidades. O serviço de busca armazena este proxy, bem como os
atributos associados ao novo serviço, tornando-o assim acessível aos demais membros da
federação.
Um dos parâmetros que deve ser enviado pelo serviço genérico para o serviço de busca é o
seu número de identificação (ID). Este número é global, persistente e único para cada
serviço Jini, sendo atribuído por uma aplicação especial (método) dos serviços de busca por
6
ocasião da primeira vez em que cada serviço registra-se numa rede Jini. Como este ID é
único para cada serviço, e persistente durante toda a sua existência (independentemente do
serviço estar ou não conectado a uma rede Jini), ele permite que entidades sejam
identificadas individualmente, evitando duplicidade nas tabelas dos serviços de busca, e
permitindo que clientes mantenham uma memória de entidades com as quais desejam
comunicar-se.
Figura 2.2 - Serviço C envia uma mensagem multicast para a sub-rede
Figura 2.3 - Serviço de busca responde ao multicast estabelecendo
uma conexão e enviando o seu proxy
7
Figura 2.4 - Serviço C registra-se enviando o seu proxy para o serviço de busca
Figura 2.5 - Proxy do serviço C é armazenado pelo serviço de busca
tornando-se disponível para clientes
2.2.Serviço de Busca
Qualquer federação em Jini possui ao menos um serviço de busca. Estes mapeam interfaces
que indicam as funcionalidades disponibilizadas pelos serviços membros da federação e os
objetos (proxies) que implementam estas interfaces (e portanto, disponibilizam os serviços).
O serviço de busca reflete a composição atual da federação e funciona como um mercado
central para a oferta e busca de serviços.
8
Um cliente que deseja acessar os serviços de uma rede Jini, conforme descrevemos na
seção anterior, envia uma mensagem multicast para uma porta conhecida solicitando que os
serviços de busca presentes na rede identifiquem-se. Ao receber a mensagem o serviço de
busca responde enviando ao solicitante o seu proxy. Através de métodos deste proxy o
cliente pode então pesquisar os serviços disponíveis na rede que implementam uma
determinada interface. O serviço de busca irá enviar para o cliente todos os proxies de
serviços que atendam aos critérios de uma busca particular, cabendo ao cliente selecionar
aquele mais adequado às suas necessidades.
Naturalmente para facilitar o processo de busca por serviços estes de forma geral
implementam interfaces conhecidas. Uma impressora a laser por exemplo deve
implementar uma interface do tipo Printer. Um cliente que desejar acessar um serviço de
impressão a laser irá solicitar ao serviço de busca objetos que implementem a interface
Printer, recebendo provavelmente vários proxies, dentre os quais aquele correspondente a
impressora laser.
Caso um serviço ofereça funcionalidades não definidas por uma determinada interface,
estas podem ser disponibilizadas através da inclusão de métodos adicionais que estendam
uma interface padrão. Uma impressora a laser capaz de encadernar folhas pode
implementar o método encadernar(). Para identificar estas funcionalidades adicionais o
cliente deve utilizar-se das propriedades reflexivas de Java, que permitem que todas os
métodos públicos de uma classe sejam mapeados e descobertos dinamicamente.
Por fim, os serviços de busca armazenam opcionalmente atributos associados aos diferentes
serviços registrados, possibilitando que clientes refinem ainda mais as suas buscas. De
forma análoga às interfaces, diversos atributos são padronizados, como por exemplo:
Location, que especifica a localização física do serviço (edifício, andar, sala, etc); Name,
que especifica um nome legível para o serviço; e Status, que especifica o estado corrente do
serviço (disponível, sem papel, etc). Uma impressora a laser poderá ser identificada pela
sua interface, Printer, e por uma atributo específico como ServiceInfo.
9
2.3.Interface de Leasing
Em um sistema local recursos computacionais são alocados a um cliente ou processo e
tornam-se novamente disponíveis apenas quando explicitamente liberados. Em um sistema
distribuído tal política pode fazer com que alguns recursos fiquem eternamente bloqueados
por ocasião de falhas de componentes ou dificuldades de comunicação. Como forma de
evitar problemas desta natureza, Jini utiliza o conceito de leasing.
Um leasing é uma permissão de acesso a um recurso garantida por um determinado período
de tempo. Se um cliente desejar ter acesso a um serviço, ele deve primeiramente negociar
um leasing. Quando o período do leasing termina, o serviço é encerrado e o recurso
correspondente é liberado. O cliente pode encerrar um leasing antes do seu vencimento,
bem como solicitar a sua renovação a qualquer tempo. Não existe porém nenhuma
obrigação por parte do serviço em atender as exigências de um cliente quanto aos prazos do
leasing.
Um leasing pode ser exclusivo ou não exclusivo. Em leasings não exclusivos o serviço
pode ser compartilhado entre vários clientes. Por outro lado serviços mono-tarefas
disponibilizam apenas leasings exlusivos, podendo atender a apenas um cliente por vez
(uma impressora por exemplo).
Todos os proxies de serviços em Jini implementam a interface Leasing, inclusive aqueles
armazenados pelos serviços de busca. Isto impõe a necessidade de que, periodicamente,
todos os serviços disponíveis na rede renovem os seus registros (os leasings) junto aos
serviços de busca. Serviços não renovados por qualquer razão são automaticamente
exluídos da federação, tornando-se invisíveis.
2.4.Eventos Distribuídos
Os mecanismos tradicionais de RPC que utilizam-se de comunicação síncrona não podem
ser adequadamente estendidos para sistemas distribuídos genéricos. Como a latência de
10
uma rede nem sempre é conhecida ou mesmo bem comportada, e componentes geralmente
estão sujeitos a falhas, a comunicação síncrona pode fazer com que processos fiquem
bloqueados por períodos longos de tempo, impactando negativamente ou mesmo
impedindo por completo a operação eficiente do sistema. A adoção da comunicação
assíncrona, conjuntamente a um modelo de programação orientado a eventos, possibilita
uma operação mais eficiente de sistemas distribuídos, minimizando problemas decorrentes
de falhas de comunicação e componentes.
Jini define duas classes que suportam o desenvolvimento de aplicações orientadas a
eventos3. A primeira destas classes, RemoteEvent, especifica as características de um
evento e a sequência temporal em que são gerados (o que possibilita a implementação de
relógios lógicos). A segunda classe, EventRegistration, permite que geradores de eventos
registrem objetos interessados em seus eventos. Por fim, a interface RemoteEventListner
especifica o handler responsável por tratar os eventos recebidos por um objeto.
Uma aplicação comum de eventos em Jini é o registro por clientes de interesse em eventos
relacionados a serviços, como a disponibilização de uma nova funcionalidade,
modificações em seus atributos (Status por exemplo), ou o ingresso de um serviço
específico na federação.
2.5.Transações
Uma transação é um conjunto de operações que são sempre executadas atomicamente:
todas as operações conseguem ser completadas com sucesso, ou nenhuma delas é executada
mesmo que parcialmente4. Como bem ilustra o exemplo clássico da transferência monetária
3
Não existe porém nenhuma exigência quanto a utilização destas classes, que servem apenas para facilitar o
trabalho de programadores.
4
Transações possuem as propriedades conhecidas como Acid:
- Atomicidade - Todas as operações são bem sucedidas ou todas falham, executando portanto como
uma única transação.
Consistência - Após a execução de uma transação o sistema deve apresentar um estado interno
consistente.
Isolamento - Transações não afetam outras transações enquanto não forem executadas
completamente. Operações intermediárias de uma transação não podem afetar outras transações.
11
entre agências bancárias5, a implementação de transações é fundamental para que sistemas
distribuídos possam manter uma consistência interna de estados. Jini fornece uma série de
interfaces que definem uma semântica para a implementação de transações, utilizando o
protocolo conhecido como two-phase commit.
Para que uma transação possa ser implementada é necessário que defina-se inicialmente
quais operações de quais serviços irão compor a transação, e que um objeto fique
responsável por gerenciar a transação. Na primeira fase do protocolo two-phase commit o
gerente solicita que todos os participantes da transação executem suas operações, mas de
uma forma que as mesmas possam ser revertidas em caso de falha. Ao final desta fase o
gerente verifica se todos os participantes foram capazes de completar suas operações. Em
caso negativo ele comunica-se novamente com os participantes e solicita que as operações
realizadas sejam revertidas, recuperando o estado inicial do sistema. Em caso positivo ele
também comunica-se com os participantes solicitando que as operações sejam efetivadas
(commited).
Para implementar este modelo transacional os serviços em Jini devem implementar a
interface TransactionParticipant e os métodos prepare(), commit() e abort(). Tais
implementações entretanto ficam totalmente a critério do programador, já que Jini não
define qualquer regra ou facilidade adicional para a execução desta tarefa.
2.6.Serviços
Serviços são abstrações que representam qualquer entidade capaz de disponibilizar
funcionalidades para clientes em uma rede Jini. Um serviço pode ser qualquer coisa desde
um dispositivo de hardware (memória, impressora, etc) até um módulo de um software.
- Durabilidade - Após o término da transação as mudanças de estado efetuadas são permanentes.
Um cliente solicita a transferência de $X de uma conta A para uma conta B. É efetuado um débito na conta
A, mas a operação de crédito correspondente na conta B não é executada por alguma razão. O estado final do
sistema (débito em A, nenhuma modificação em B) é inconsistente, e não poderia ter ocorrido.
5
12
A execução de serviços em Jini é efetuada através de proxies que são transferidos dos
serviços de busca para os clientes como resultado de uma busca específica. Tais
transferências consistem no envio de um trecho de código executável, capaz de gerenciar
localmente a execução remota do serviço6. Cabe observar que no caso em que uma entidade
remota é responsável pela efetiva execução de um serviço, a comunicação entre esta e seus
proxies pode seguir qualquer formato/implementação suportado pela rede, não tendo que
obedecer a qualquer protocolo ou padrão imposto por Jini ou Java.
O download do proxy de um serviço pelo cliente é uma das características que possibilitam
a configuração dinâmica das redes Jini. Os proxies encapsulam caracterísitcas específicas
de cada serviço, oferecendo ao cliente uma interface através da qual poderão ser solicitadas
tarefas. Em um certo sentido o download de um proxy funciona quase que como a
instalação de um device driver, fornecendo uma interface padronizada para acesso às
funcionalidades do serviço.
Figura 2.6 - O cliente faz uma busca por um serviço de fax
6
Em alguns casos o proxy pode ser o próprio responsável pela execução do serviço, dispensando o suporte e
a comunicação com outras entidades remotas.
13
Figura 2.7 - O serviço de busca envia para o cliente um proxy do serviço desejado
Figura 2.8 - Através do proxy o cliente acessa o serviço desejado
As entidades que implementam serviços em Jini não precisam necessariamente ter a
capacidade de executar uma JVM, ou mesmo qualquer tipo de microprocessamento. Basta
que a elas possa ser acoplado algum mecanismo de controle microprocessado capaz de
implementar uma interface Java. Como ilustração podemos considerar um switch mecânico
de um ar-condicionado com a única função de ligar e desligar o equipamento. O arcondionado pode tornar-se um serviço de uma rede Jini acoplando-se a ele uma control-box
capaz de acionar o switch mediante um comando de uma interface programável. Esta
interface deve ser então encapsulado em uma classe Java, que irá disponilizar proxies
14
através dos quais clientes da rede Jini poderão acessar o serviço ar-condicionado
(ligar/desligar).
Um ponto importante em relação aos serviços de busca é que como estes implementam as
mesmas interfaces de serviços genéricos, eles também podem se registrar em outros
serviços de busca. Este mecanismo permite que membros de uma federação possam acessar
o serviço de busca de uma outra federação, acessando por conseguinte, também os serviços
disponíveis nesta.
3.Redes Espontâneas
Redes espontâneas permitem a integração de entidades e serviços de forma automática,
transparente e sem a necessidade de intervenções manuais para a atualização de
configurações. Por apresentarem maior flexibilidade, autonomia, e tolerância a falhas em
relação as arquiteturas de rede tradicionais, as redes espontâneas vem adquirindo uma
importância crescente em inúmeros segmentos de aplicação, sobretudo naqueles associados
a sistemas que incluem entidades móveis em sua composição.
Jini foi desenvolvido para atender os requisitos principais da arquitetura de redes
espontâneas, sendo utilizado comercialmente sobretudo em sistemas desta natureza. Redes
Jini apresentam grande tolerância a falhas, implementam mecanismos que possibilitam a
manutenção de níveis adequados de segurança e são relativamente flexíveis. Nas seções
seguintes discutiremos estas características. Encerraremos o capítulo com dois exemplos
reais de sistemas que utilizam Jini.
3.1.Tolerância a Falhas
A capacidade de continuar operando adequadamente mesmo diante de falhas críticas em
componentes é uma das características mais importantes das redes Jini. Esta qualidade
decorre da forma descentralizada como a sua estrutura é organizada, e da imposição do
15
conceito de leasing para todos os relacionamentos entre entidades da rede. Conforme já
descrevemos, qualquer equipamento que queira oferecer um serviço deve registrar-se em
um serviço de busca. Como todos os registros são mantidos apenas por um determinado
período de tempo (até o vencimento do leasing), qualquer falha de comunicação, hardware
ou software que impeça um serviço de renovar o seu registro, fará com que o mesmo seja
automaticamente excluído da federação.
Um segunda caracterísitca importante relacionada à robustez de redes Jini é que a exceção
de serviços de busca, as demais entidades de uma federação não desempenham nenhuma
função especial no funcionamento operacional da rede. E mesmo falhas nas entidade que
implementam um serviço de busca não impedem que a rede continue operacional, já que
clientes que tenham feito o download de proxies de serviços continuam tendo acesso às
suas funcionalidades.
Por último serviços cuja falha podem acarretar estados inconsistentes do sistema,
implicando em algum tipo de prejuízo, devem implementar o modelo de transação descrito
na seção 2.5, evitando assim quaisquer problemas dessa natureza.
3.2.Modelo de Segurança
O aspecto de segurança é particularmente importante face às vulnerabilidades associadas ao
modelo operacional de redes Jini, que impõe a necessidade de execução de trechos de
código carregados remotamente, e permite a adição frequente e de forma dinâmica de
novos serviços às federações. Por ser implementado utilizando Java e RMI, Jini conta com
todos os inúmeros recursos de segurança incorporados por estas tecnologias, dentre os
quais podemos destacar:
-
A forte tipagem da linguagem Java - Java não utiliza ponteiros, mas apenas
referências, e uma JVM não permite que um código tenha acesso a áreas de
memória não reservadas para as variáveis de programa (em C por exemplo é
possível “derrubar” um servidor através do acesso a áreas críticas de memória).
16
-
Tratamento de exceções - Em Java exceções fazem parte da assinatura de métodos,
devendo ser tratadas explicitamente pelo programador. Isso impede que um
programa apresente comportamentos anômalos como consequência da ocorrência de
exceções.
-
Assinatura digital de classes - Em Java classes podem ser assinadas digitalmente.
Portanto, através deste mecanismo é possível identificar a autoria e a origem de um
trecho de código.
-
Java Authentication and Authorization Service (JAAS) - Este serviço permite que
usuários sejam autenticados, e que a execução de trechos de código passem a estar
associadas a usuários específicos.
-
Security Manager -
Java permite a definição de políticas de segurança
estabelecendo permissões para o acesso a recursos baseadas em qualquer
combinação da autoria e origem do código a ser executado, bem como do usuário
associado a esta execução (figura 3.1).
Figura 3.1 - Security Manager
-
Verificador de bytecode - Java RMI incorpora um verificador de bytecode que
examina qualquer pedaço de código carregado remotamente, garantindo a formação
correta do mesmo7.
7
O código deve estar de acordo com a especificação da classe que implementa.
17
O modelo de segurança incorporado por Jini além de ser relativamente robusto, é bastante
flexível, ajustando-se adequadamente a uma ampla variedade de contextos. Uma
configuração comumente adotada é aquele que permite a utilização dos serviços da rede por
qualquer cliente que tenha acesso a uma interface, mas restringe a inclusão de serviços
àqueles explicitamente autorizados.
3.3.Flexibilidade
Uma rede Jini é composta por uma camada intermediária (middleware) implementada em
Java que define uma semântica e media as transações/comunicações entre os diferentes
componentes da rede. Em função das características de portabilidade/inter-operabilidade do
ambiente Java, e de sua própria arquitetura, Jini não estabelece restrições quanto a forma
como serviços são implementados, nem tão pouco em relação à infraestrutura e
implementação da(s) subrede(s). Isto viabiliza a estruturação de sistemas distribuídos multiplataforma, possibilitando a inter-operabilidade de componentes e tecnologias altamente
heterogêneas.
Paralelamente, a habilidade de adicionar e remover componentes dinamicamente confere
uma ampla liberdade quanto à arquitetura organizacional das redes Jini. A rede torna-se um
organismo dinâmico, adaptável e com grande escalabilidade.
3.4 Exemplos
Um exemplo interessante da utilização da tecnologia Jini pode ser encontrado no sistema
Infotronic do Chrysler Cruiser disponibilizado em alguns modelos deste automóvel
lançados a partir de 2000 nos EUA. Através de uma interface no painel do veículo (ver
figura 3.2) o sistema permite que passageiros e motoristas tenham acesso a inúmeros
serviços enquanto em trânsito, como localização de posição e auxílio a navegação do
veículo, acesso à Internet, download de mídia, e controle remoto de equipamentos.
18
Figura 3.2 - Interface do IT Cruiser Infotronic
Os serviços disponibilizados pelo sistema dependem da localização do veículo e de sua
conexão a rede. O usuário pode por exemplo instalar em sua residência uma rede sem fio
padrão IEEE 802.11. Neste caso ao aproximar-se da residência o sistema do veículo acessa
o serviço de busca da rede doméstica passando então a controlar e comunicar-se com todos
os equipamentos conectados (aquecedores, luzes, alarmes, computadores, etc). Em trânsito
o veículo através de um modem acessa uma rede sem fio de baixa capacidade, geralmente
um provedor de Internet, identificando automaticamente os serviços Jini acessíveis através
da mesma e informando os passageiros.
Figura 3.3 - Conexão do Sistema
19
Outro exemplo de aplicação que incorpora a tecnologia Jini foi desenvolvido recentemente
para o exército americano para a integração de equipamentos de monitoria e comunicação.
Durante uma batalha o exército usualmente estabelece postos avançados onde são
instalados centros de comando (TOC - Tactical Operation Center). Estes centros são
responsáveis por monitorar, planejar e executar ações de guerra, e contam para isso com o
apoio de uma diversidade de equipamentos eletrônicos interligados. O tipo de equipamento
empregado, bem como a arquitetura de rede utilizada para as conexões, não são
padronizadas e variam conforme a natureza da operação e a disponibilidade de
componentes
Utilizando redes Jini o exército desenvolveu uma forma eficaz de conectar equipamentos
heterogêneos de maneira rápida e sem a necessidade de intervenção humana para efetuar
configurações. Ao serem conectados a rede os equipamentos são identificados por uma
estação de controle (workstation) que disponibiliza os serviços destes através de um serviço
de busca. Equipamentos que não tem a capacidade de implementar interfaces Java são
controlados através da workstation, numa arquitetura típica de três camadas, enquanto
equipamentos mais inteligentes registram-se automaticamente junto ao serviço de busca,
interagindo diretamente com os clientes através de um proxy.
Os equipamentos podem ser adicionados ou removidos do TOC a qualquer tempo sem
desestabilizar o funcionamento do sistema, e sustentando um alto padrão de confiabilidade
compatível com operações de combate.
4.Conclusão
A demanda por mobilidade e a importância crescente do modelo de rede em um ambiente
em que os recursos computacionais são cada vez mais ubíquos e heterogêneos, geram
novos desafios e atraentes oportunidades. Segmentos de aplicação não tradicionais como
eletrodomésticos, telefones celulares, veículos e equipamentos medicinais tornaram-se
recentemente foco de uma extensa gama de soluções, criando necessidades tecnológicas
específicas e incomuns. Percebe-se também uma dificuldade maior para prever as
20
diferentes maneiras em que as tecnologias serão empregadas, valorizando portanto
características fundamentais como flexibilidade e escalabilidade.
Dentro deste contexto Jini apresenta-se como uma interessante opção para o
desenvolvimento de aplicações. Sua arquitetura possibilita a implementação de redes
configuráveis dinamicamente, compostas por diferentes plataformas, tecnologias e
componentes, inter-operando de forma transparente e com alta tolerância a falhas. Redes
em que a necessidade de intervenção humana é portanto limitada, mas que não obstante
mantém a capacidade de operar de maneira robusta, em um ambiente cada vez mais
dinâmico, heterogêneo e imprevisível.
21
Bibliografia
Arnold, Ken. The Jini Architecture: Dynamic Services in a Flexible Network; Proceedings
of the 36th ACM/IEEE Conference on Design Automation, pp.157 - 162, 1999.
Couloris, George; Dollimore, Jean; Kindberg, Tim. Distributed Systems: Concepts and
Design. Addison-Wesley, agosto 2001.
DaimlerChrysler Corp. IT DaimlerChrysler IT Cruiser Telematics Concept uses Jini
Technology, Technical Report, janeiro 2001.
Edwards, W. Keith. Core Jini. Prentice Hall PTR , setembro 1999.
Li, Sing. Professional Jini. Wrox Press, agosto 2000.
Sun Microsystems. Jini Architectural Overview, Technical White Paper, janeiro 1999.
Sun Microsystems. Why Jini Technology now?, Technical White Paper, janeiro 1999.
Sun Microsystems. Jini Technology Core Platform Specification, outubro 2000.
Sun Microsystems. U.S. Army - Reliable Battlefield Communication Using Jini
Connection Technology, Sucess Story, 2000.
Waldo, Jim. The Jini Architecture for Network-Centric Computing; Communications of
the ACM 42, 7, pp. 76 - 82, 1999.
22