PDF - Life, the Universe and Everything…

1
Simply connect.
Jini™ Technology
Tutorial
Bruno Ferreira de Souza
Java Technologist
Sun Microsystems, Inc.
2
TECHNOLOGY
SHOULD NOT
REQUIRE A
LEARNER’S
PERMIT.
You scratch your head. Bite your nails. Technology was supposed to make things easy. So why is figuring out how to use it
so difficult? We see things from a different perspective. (And always have.) It’s called network computing. And that’s led us
to break-through like our Java ™ technologies. Taking away the hurdles. Making computing more seamless, more
transparent. So you can do exactly what you want to do. Without having to spend your life figuring out how. THE NETWORK
IS THE COMPUTER™ .
O Paradigma Atual
• A indústria da informática evoluiu de forma inacreditável
• Mas a estrutura dos computadores é a mesma…
– CPU, memória, disco
– instalar, executar aplicações, gerenciar recursos…
– atividades que um administrador dos anos 50 entende bem…
• Mudança em tamanho e velocidade não trouxe
mudança significativa em como instalamos,
administramos e utilizamos os computadores
A História de Jini
• Se mistura com a história de Java
– Originalmente criada para desenvolver software para pequenos
devices
– em 94/95 - uso na web (HotJava)
– Mas o uso original não foi esquecido…
• Bill Joy - pre-95
– linguagem robusta para desenvolvimento de aplicações
– “máquina virtual”para executar programas em qualquer
processador para tirar proveito do novo mercado de
processadores
– sistema para interligar essas máquinas virtuais para suportar
uma nova forma de sistema distribuido
– Computadores continuarão existindo, mas o futuro esta nas
“smart appliances”
– Java, JVM, Jini
• Bill Joy, Jim Waldo, Ann Wollrath, Ken Arnold, Bob
Scheifler
A Visão Jini
• A arquitetura Jini foi desenhada para permitir a
disponibilização e o uso de serviços na rede
• Redes são dinamicas por natureza:
–
–
–
–
novos sistemas são adcionados
sistemas antigos são removidos
sistemas existentes são atualizados
partes da rede falham e são consertadas
• Possuem problemas que não exsitem em sistemas
locais (mesmo os multiprocessados)
• Essas diferenças precisam ser tomadas em conta
• Um sistema distribuido precisa se adaptar a essas
modificações, porque a rede vai mudar
• Jini foi desenhado para ser adaptável e flexível
A Visão Jini
• “unbiquitous computing” Mark Weiser (Xerox PARC) grandes quantidades de devices e serviços de software
trabalhando juntos, facilmente e imediatamente
utilizáveis
• Essa visão traz problemas particulares
– a infraestrutura de software precisa ser extremamente robusta
– os devices precisam suportar verdadeiro “plug & work”
- fáceis de usar
- fáceis de administrar
– software precisa ser capaz de evoluir
– precisam formar comunidades espontâneas
• Os mesmos problemas com grandes quantidades de
devices são também problemas dos grandes sistemas
corporativos - Jini não é só para pequenos devices...
Sistemas Distribuidos
• Todos nós conhecemos as mensagens:
– NFS server not responding
– unable to locate server
– no route to host
• Nossos sitemas são frágeis, mas parece que sistemas
distribuídos são ainda mais frágeis
• Desenvolver sistemas distribuídos é difícil
Sitemas Distribuidos Tradicionais
• Tentativas de fazer a rede “sumir”
• Programadores aprenderam como desenvolver
sistemas locais - incluir modelos específicos para tratar
a rede causa problemas
• Temas comuns:
– Como mover dados para serem processados
– O que fazer com os dados uma vez que foram movidos
• Como mover dados para serem processados
– não podemos assumir que o código necessário estará em
todos os locais, então é mais fácil mover os dados
– mover os dados também tem suas dificuldades...
• O que fazer com os dados uma vez que foram movidos
– Basicamente: RPC
– CORBA e DCOM: RPC para objetos
• Tudo isso para fazer a rede “sumir”...
Mas a rede não é transparente…
• Simplificar o problema dessa forma é supersimplificar…
• Baseado na idéia de que a corretude de um programa
não é afetada pela rede, apenas a performance
• Centrado nos seguintes principios:
– existe um modelo de objetos para a aplicação, independente
do contexto de rede
– questões de falha e performance estão ligados à
implementação dos componentes e portanto devem estar fora
do design inicial
– a interface de um objeto é independente do contexto de rede
• A parte difícil de um sistema distribuído não é o envio
de dados e a chamada de procedimentos remotos
• A parte difícil é lidar com falha parcial, falta de um
gerenciador central de recursos, performance
adequada e concorrência
Diferenças entre Sistemas Locais e
Distribuidos: Performance e Latencia
• Esse é o problema mais perceptível
• Mas ignorar as diferencas entre o acesso local e o
remoto é basicamente garantir que haverá problemas
de performance
• Mas ainda que fosse resolvido, não é a diferença
fundamental
Diferenças entre Sistemas Locais e
Distribuidos: Falha Parcial
• Problema fundamental e menos óbvio
• Tanto sistemas locais como sistemas distribuidos
possuem componentes sujeitos a falhas
• No sistema local: ou o sistema inteiro falha, ou o SO
consegue detectar a causa da falha
• No caso do sistema distribuido, um componente pode
falhar enquanto outros continuam funcionando
corretamente
• Além disso, não existe um agente central capaz de
avisar da falha. Uma falha no link da rede é
indistinguivel de uma falha na aplicação ou de uma
falha no processador, ou ainda de uma aplicação lenta
• Se esses tipos de falhas não fazem parte do “contrato”
(a interface) do componente, então os programadores
podem ignorá-las...
Diferenças entre Sistemas Locais e
Distribuidos
• No fundo, problemas de falhas parciais, concorrência e
consitência, possuem soluções diversas para
aplicações diversas
• Devem ser tratados conscientemente pelo programador
em um sistema distribuido
• Não podem ser “escondidos”
• É um engano tentar fazer o desenvolvimento distribuído
como se fosse local (“sumir” com a rede)
Java não tem alguns desses problemas...
• Java não apresenta alguns dos problemas que se tenta
resolver com outros sistemas distribuídos
• Solução centrada em uma linguagem: todo o sistema
assume objetos Java, o que simplifica diversos
aspectos
–
–
–
–
mover dados não é mais problema
mover dados pode não ser nem mesmo necessário
mobilidade de código
segurança
• Mas e os problemas fundamentais? Como java
promove a distinção entre objetos locais e remotos?
Java e Sistemas Distribuidos
• Strong typing - no RMI os tipos Java (interfaces)
são usadas para definir a interface para comunicação
remota:
public interface RemoteServer extends Remote {
public int getLenth(String s) throws RemoteException;
}
• O tipo Java é o protocolo, e portanto, podemos
manipular o tipo (extender, modificar) e estaremos
alterando o protocolo
• Todo o poder da orientação a objetos em um mundo
distribuido
• Polimorfismo poderoso. Por exemplo:
public interface MatrixSolver extends Remote {
public Matrix crossProduct (Matrix m1, Matrix m2)
throws RemoteException;
}
Natureza distribuida do Objeto está na
Interface
• Diferença sutil, mas com grandes ramificações
• Obriga ao desenvolvedor a considerar a distribuição
desde o início, ao invés de pensar depois
• java.rmi.Remote
• java.rmi.RemoteException
• Não vai fazer com que os problemas de sistemas
distribuidos desapareçam, nem fazer sistemas
distribuidos tão fáceis de serem desenvolvidos como
sistemas locais
• Faz uma distinção clara entre objetos distribuidos e
locais (mas usando a mesma tipagem Java)
• Obriga o desenvolvedor a tratar as falhas que podem
ocorrer em um sistema distribuido
Sistemas Distribuidos Dinâmicos
• As facilidades de Java (codigo e data móveis e tipagem
forte) possibilitam uma mudança para sistemas
distribuídos dinâmicos
• Sistema composto de várias componentes, ao contrário
de sistemas atuais onde temos váriso sistemas
conectados de forma relativamente estática
• Características de sistemas dinâmicos:
– precisam escalar para ptencialmente grande número de máquinas
– para isso, código tem que estar disponível em todos os lugares, e
para isso, precisa ser fácil de instalar
– uma vez rodando, pode precisar ficar rodando por longos períodos, e
portanto, precisa ser robusto e ser capaz de se auto-reparar
– como terá que rodar por longos períodos, precisa ser capaz de evoluir
• Jini é um sistema especificamente desenhado para
suportar a criação de sistemas distribuidos
verdadeiramente dinâmicos
Jini Design
• Java tem muito a agregar a sitemas distrbuidos, e Jini
tem muito a agregar a Java.
• A visão de Jini é voce ser capaz de conectar qualquer
device “Jini enabled”, conectá-lo a uma rede, and ser
automaticamente capaz de ver e utilizar outros devices
e serviços existentes na rede.
• Como se o seu device tivesse sido programado para
usar esses outros servicos e devices
Jini™ Architecture
Infrastructure
Java
+
Jini
Base
Java
Programming
Model
Services
Extended RMI
Discovery
Distributed
Security
Lookup
Leasing
Two Phase
Commit
Events
JavaSpace
Two Phase
Commit Manager
Java VM
RMI
Java Security
Model
Java APIs
JavaBeans
...
JNDI
Enterprise Beans
JTS
Let objects find each
other, and...
… add simple APIs for
Remote Objects and
Basic Distributed
Computing, and...
… then everything else is
a service.
Jini Design
• Jini foi desenvolvido procurando atender a um conjunto
de prioridades:
• Simplicidade
• Confiabilidade
• Escalabilidade
• Independência de aparelhos
Simplicidade
• Bill Joy: “large sucessfull systems start out as small
successfull systems”
• Jim Waldo: “passei os ultimos 9 anos tentando fazer
esse sistema simples”
• Se você conhece Java, quase que já conhece Jini
• Construido em sima dos conceitos de Java
• Adciona apenas a camada necessária para permitir que
devices e serviços trabalhem uns com os outros de
forma fácil
• Tudo são serviços: software, hardware
Confiabilidade
• Jini suporta interações entre serviços de forma a
permitir que serviços apareçam e desapareçam
facilmente
• Partes interessadas podem ser notificadas quando o
conjunto de serviços muda
• Não requer nenhuma configuração estática ou
administração: “spontaneous networking”
• Comunidades Jini são basicamente “auto-reparaveis” Jini não assume que as redes são perfeitas ou que
software não falha. Dado o devido tempo, o sistema se
auto-repara
• Suporte a redundância de forma natural
• Essas propriedades garentem que um sistema Jini é
basicamente livre de necessidade de administração
Escalabilidade
• Serviços Jini se agrupam e formam cominidades, mas
quão escalável são essas comunidades?
• Comunidades são do tamanho de um workgroup, ou
seja, todos os devices e serviços para grupos de cerca
de 10 e 100 pessoas
• Em geral, pessoas tendem a colaborar com as que
estão perto
• Comunidades são formadas automaticamente dentro
dos limites da rede
• Jini permite juntar comunidades em “federações”
• Federações são contruidas através da ligação dos
“lookup services”
• Permite uma topologia bastante dinâmica
Independência de Aparelhos
• Jini foi desenhado para suportar uma gigantesca gama
de entidades
• É indiferente se entidades são hardware, software ou
uma combinação
• Em geral, um usuário de um serviço não tem como
saber (e nem se importa)
• Jini é flexível para trabalhar com devices mesmo com
limitadas capacidades
• Não precisa nem mesmo ser capaz de processamento
• Nem mesmo requer que entenda ou seja escrito em
Java!
O que Jini não é
• Jini não é um servidor de nomes
• Jini não é JavaBeans
• Jini não é Enterprise JavaBeans
• Jini não é RMI
• Jini não é um sistema operacional distribuido
Os 5 conceitos fundamentais
• Simplicidade é um dos objetivos, e todas as facilidades
que Jini oferece estão baseadas em apenas 5
conceitos. Se você souber os 5, sabe tudo sobre Jini
• Discovery
– encontrar e se juntar a comunidades - spontaneous comunity
building
• Lookup
– procurar e encontrar serviços
• Leasing
– fornece a capacidade de auto-reparo
• Remote Events
– notificações de mudança de estado dos serviços
• Transactions
– `permite corrdenar ações entre multiplos serviços
Architecture of Jini™ Technology
discovery
Network
Services
Jini
{ JavaSpaces™
{
Other Services
lookup
The lookup service binds the
federation together.
Lookup
leasing
Leasing provides a method of
managing resources in an
environment where network failures
can occur.
Discovery / Join
JAVA
Discovery solves the problem of
finding the place to start in an
unknown network.
JAVA
events
JAVA
Events deal with the peculiarities of
messages in the networked
environment, such as latency and
network failure.
transactions
Solaris
Mac
Windows
SPARC
PPC
X86
Transactions allow distributed
entities to cooperate in such a way
that the changes to the group occur
atomically or not at all.
JavaSpace
A space may be used to implement
a large number of distributed
computing patterns.
Jini, como funciona?
Service Request Ž
Œ
• Java Interface Code •
Image Service
• Java Interface Code
Java Interface Code
Jini Lookup Service
Discovery
• Serviços precisam se juntar a uma comunidade para
poder ter acesso a serviços
• Para isso, uma entidade procura os lookup services
mantém a lista de recursos disponíveis
• o processo de procurar e se registrar a um lookup
service é chamado de discovery
• o protocolo de discovery é usado para encontrar
comunidades, e o protoloco join é usado para se
registrar
• lookup services podem prover serviço para uma ou
mais comunidades, e cada comunidade pode ter um ou
mais lookup services
Protocolos de Discovery
• Multicast Request Protocol
– buscar lookup services ativos
• Multicast Announcement Protocol
– anunciar um lookup service
• Unicast Discovery Protocol
– acessar diretamente um lookup service
– jini://jini.javaman.com.br
• Alem desses, serviços que queiram se disponibilizar na
rede utilizam o Join protocol para fazer isso
• Comunidade e Grupos
• Com o uso desses protocolos, a topologia de uma
comunidade Jini é extremamente flexivel
Lookup
• uma vez usado discovery para encontrar um lookup
service, o processo de lookup é o que podemos fazer
com ele
• o Lookup Service é uma espécie de name service - é
um processo que mantém registros de todos os
serviços que se juntaram a uma comunidade
• as buscas em um lookup são feitas baseadas em tipos
Java (normalmente interfaces)
• depois que o discovery encontrou um Lookup Service,
retorna uma referência a um objeto que implementa a
interface de lookup ServiceRegistrar
• Os detalhes da implemtação do lookup service são
escondidos
Publicando um Serviço
• Cada lookup service mantém uma lista de “service
itens”. Cada item contém um objeto (proxy) que pode
ser usado para acessar o serviço, e uma lista de
atributos que descrevem o serviço
• O método ServiceRegistrar.register() é usado
para registrar um serviço no lookup service encontrado,
passando um “proxy”e uma série de parâmetros
• O proxy (ou service proxy) é um objeto serializável
arbitrário que será recebid por qualquer serviço ou
aplicação que queira tirar proveito do seu serviço
• o service proxy é que dá ao Jini a característica de se
utilizar serviços sem nenhuma instalação de drivers ou
configuração
Service Proxy
• pode ser considerado um device driver seguro e que é
carregado sob demanda por clientes que precisarem
utilizar o serviço
• um cliente não precisa entender a forma como o service
proxy é implementado e como ele se comunica (se é
que se comunica) com o serviço
• Pode ser implementado de diversas formas:
– é o próprio serviço
– apenas o RMI stub do serviço
– é um proxy capaz de falar um protocolo específico
- usado para serviços legados por exemplo
Encontrando um Serviço
• uma aplicação cliente pode procurar por um serviço
através do lookup service
• a busca pode ser feita pelo tipo do proxy, pelo
identificador do serviço ou pelos atributos
• ServiceRegistrar.lookup()
• O valor retornado é um ou mais objetos proxy
• Para se usar o proxy programaticamente, é necessário
conhecer a interface, por isso o processo de definição
de interfaces que está sendo realizado pela indústria
nesse momento
• O lookup utiliza esse mecanismo durante o processo de
dicovery/join
Leasing
• O esquema de leasing permite que um sitema Jini seja
estável, auto-reparável e resistente a falhas de rede,
crash de máquinas e erros de software
• Especialmente importante quando os sistemas são de
longa duração (meses e ate mesmo anos)
• Baseado na idéia de ao invés de se alocar recursos por
períodos ilimitados, “empresta-se” o recurso por um
periodo fixo de tempo
• podem ser negadas, renovadas, canceladas, ou podem
expirar normalmente, e podem ser negociadas
• leases são usadas em todo o sistema Jini para garantir
que o sistema se auto-recupere, e tambem que se torne
basicamente livre de necessidade de administração
• Leases podem também ser negociadas por terceiros
Leasing
• leases são fornecidas por um certa duração (1 minuto,
10 minutos) e o fornecedor pode decidir só garantir uma
lease por um tempo menor do que o solicitado
• quem receber a lease, se pretender renová-la, deverá
manter a referência ao objeto recebido
• leases são usadas para fornecer a capacidade de autorecuperação de um sistema Jini, portanto, quanto maior
o tempo de lease, mais demorará para o sistema se
recuperar
Remote Events
• Servicos Jini precisam ser ocasionalmente notificados
de acontecimentos e mudanças de estado de outros
serviços
• Jini utiliza eventos distribuidos para fazer notificações
assíncronas. Um evento é um objeto que contém
informação sobre uma mudança de estado
• Eventos Jini são diferentes de eventos Java, porque
precisam levar em conta o fato de serem distribuidos
– eventos não possuem ordem garantida
– eventos pode não chegar ao destino devido a falhas parciais
– envio de eventos é muito mais custoso (e portanto, menos
eventos serão gerados)
– o receptor do evento pode estar temporariamente
desconectado ou incapz de receber o evento
• Cada aplicação vai possuir seus próprios requerimentos
em relação a seus eventos
Remote Events
• Exemplos:
– lookup service gera eventos quando servicos aparecem,
mudam ou desaparecem
– um serviço de impressão poderia informar que um trabalho
acabou de ser impresso
• Eventos Jini são similares a eventos Java normais, mas
possuem algumas diferencas:
– existe um único tipo de evento RemoteEvent, e um único
listener RemoteEventListener
– isso permite se “delegar” o recebimento de eventos para
terceiros
– permite criar “chains” de filtros de eventos. Isso permite incluir
objetos especializados em garantir “qualidade de serviço”para
eventos (por exemplo, ordenar, garantir o recebimento, etc)
– o interesse em um evento também utiliza leases
Transactions
• Jini transactions suportam 2-phase commit através de
um trasaction manager e um conjunto de classes e
interfaces
• mas ao contrário de um banco de dados, Jini não define
nenhuma semântica para a transação, apenas o
processo é definido
• cada serviço decide o que significa participar em uma
transação para esse serviço em particular
• qualquer número de serviços podem participar de uma
determinada transação
O que significa ser um serviço Jini
• As necessidades de um device para participar de uma
rede Jini são bastantes pequenas
• o device - ou algum compoente de software em favor
do device - precisa:
– ser capaz de conectar em uma rede TCP/IP
– participar no processo de discovery para encontrar pelo menos
um lookup service
– registrar junto ao lookup service, fornecendo um objeto proxy
– garantir que os leases serão renovados durante todo o período
de atividade do serviço
• Outras possibilidades (não obrigatórias)
– gerenciar os diversos lookup services
– gerenciar leases e eventos
O que significa ser um cliente Jini
• Um cliente (que pode ser um serviço também, mas não
necessariamente) precisa ser capaz de:
– usar o protocolo de discovery para encontrar um ou mais
lookup services
– receber o proxy do serviço desejado
– (opcional mas importante) registrar junto ao lookup para
receber notificações sobre serviços registrados
Jini em seus devices e serviços
• Jini é desenhado para suportar o mais variado conjunto
de devices
• Para incluir Jini nos seus devices, é importante
entender as possibilidades
• Usar Jini em um computador de uso genérico
– possui conexão com a rede (em geral por longos períodos)
– capaz de rodar uma JVM
• Usar Jini em um device com uma JVM embutida
– menor poder de processamento
– menor largura de banda na rede
• Usar Jini para controlar um device sem JVM
– nesse caso algum outro computador é usado para controlar
esse devices que muitas vezes não tem nem poder de
processamento
Jini em um computador de uso genérico
• A maior parte da mídia fala em Jini para pequenos
devices, mas Jini é perfeitamente utilizável nos
computadores atuais
• Em casa
– um PC possui um disco rígido, porque não diponibilizar esse
disco para
- cameras
- telefones celulares
- secretárias eletrônicas
• Nas empresas
– Jini pode rodar em grandes servidores, tornando redes
corporativas extremamente robustas e resistentes a mudanças
e problemas
– facilitar o processo de administracão das redes corporativas
Jini em um device com uma JVM embutida
• Cada vez mais devices possuem uma JVM embutida e
são capazes de executar aplicações Java
• Similar ao caso anterior com as seguintes diferenças:
– pequenos devices podem estar executando as edições mais
simples da plataforma Java (J2ME por exemplo)
– podem estar conectados de forma intermitente à rede
– possuem menor poder de processamento
• A limitação em relação a edição de Java pode significar
um problema, em especial para serviços que requerem
toda a capacidade da plataforma Java para executarem
Jini para controlar um device sem JVM
• Esse é o caminho que deve ser seguido pela maioria
dos aparelhos
• Nesse caso, uma máquina capaz de rodar uma JVM
está de alguma forma conectada ao device, e faz o
papel de Jini proxy para o device
• O Jini proxy participa do processo de discovery e
lookup, registra the service proxy, gerencia leases, tudo
em prol do device
• A conexão com o device acontece geralmente via
RS232, USB, firewire, X10, ou outro meio físico
qualquer (inclusive em alguns caso, a própria rede)
• Esse Jini proxy poderia ser um computador genérico,
ou algum device especializado para conectar algum tipo
de aparelho
Quando Jini é apropriado?
• se existem ou irão existir servicos Jini que seu device
ou aplicação poderão utilizar para ser mais efetivo
• se seu device ou serviço puder fornecer valor para
outros serviços ou devices
• se seu device já possui uma JVM, ou é normalmente
utilizado conectado a um computador genérico
• se seu software está rodando em um computador
capaz de rodar uma JVM
• se seu software for facilmente separado em
componentes, então talvez faça sentido separar cada
um em um serviço Jini
• se você está criando um device que será conectado a
outros devices
• se seu device puder tirar proveito de ser programável
Quando Jini não é apropriado?
• Dado que Jini foi desenhado para ser uma solução de
uso genérico, são poucos os cenários onde Jini não se
encaixa
• se seu device é totalmente isolado
• se seu device não possui, e não estará em nenhum
lugar perto de um que possua, uma JVM
Recursos:
Jini:
http://www.jini.net
http://www.sun.com/jini
Bruno Souza:
[email protected]
http://javaman.com.br
SouJava
http://soujava.org.br
8
Outras coisas a serem colocadas...
• Licencimento SCSL
• Empresas
• Jini Comunity
The Jini Community
• Sun Community Source License (SCSL) model
• Any Jini SCSL licensee is in the Jini community
• Programs available for training, support, and marketing
Sun Community Source License (SCSL)
• New technology license ideas
–
–
–
–
–
“Open Source” flavor: Modifications given back to community
Fewer restrictions: Compatibility through testing
Easy access: Zero cost for non-commercial use
Coexists with existing licenses
Made generally available to licensee community
• Compatibility
– Technology Compatibility Kit
– Upgrade tracking requirement for commercial products
• No fee associated with the SCSL
• Trademark license required for commercialization
Jini Technology Available as
Community Source
• Research and education
– Freely available, no restrictions
• Internal use
– Freely available, just pass compatibility test
• Commercial use
– Available with Jini Trademark/Branding Fee
– Fee based license for commercial products sold for fee
• Details
– http://www.sun.com/jini