1

2

Jini™ TechnologyTutorialBruno Ferreira de SouzaJava TechnologistSun Microsystems, Inc.

Simply connect.

TECHNOLOGYSHOULD NOTREQUIRE ALEARNER’S

PERMIT.You scratch your head. Bite your nails. Technology was supposed to make things easy. So why is figuring out how to use itso difficult? We see things from a different perspective. (And always have.) It’s called network computing. And that’s led usto break-through like our Java ™ technologies. Taking away the hurdles. Making computing more seamless, moretransparent. So you can do exactly what you want to do. Without having to spend your life figuring out how. THE NETWORKIS 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 trouxemudanç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 deprocessadores

– sistema para interligar essas máquinas virtuais para suportaruma 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, BobScheifler

A Visão Jini

• A arquitetura Jini foi desenhada para permitir adisponibilizaçã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 sistemaslocais (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 softwaretrabalhando juntos, facilmente e imediatamenteutilizá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 dedevices são também problemas dos grandes sistemascorporativos - 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 sistemasdistribuí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 tratara 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, independentedo contexto de rede

– questões de falha e performance estão ligados àimplementação dos componentes e portanto devem estar forado design inicial

– a interface de um objeto é independente do contexto de rede

• A parte difícil de um sistema distribuído não é o enviode dados e a chamada de procedimentos remotos

• A parte difícil é lidar com falha parcial, falta de umgerenciador central de recursos, performanceadequada e concorrência

Diferenças entre Sistemas Locais eDistribuidos: Performance e Latencia

• Esse é o problema mais perceptível• Mas ignorar as diferencas entre o acesso local e o

remoto é basicamente garantir que haverá problemasde performance

• Mas ainda que fosse resolvido, não é a diferençafundamental

Diferenças entre Sistemas Locais eDistribuidos: 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 funcionandocorretamente

• Além disso, não existe um agente central capaz deavisar da falha. Uma falha no link da rede éindistinguivel de uma falha na aplicação ou de umafalha 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 programadorespodem ignorá-las...

Diferenças entre Sistemas Locais eDistribuidos

• No fundo, problemas de falhas parciais, concorrência econsitência, possuem soluções diversas paraaplicações diversas

• Devem ser tratados conscientemente pelo programadorem 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 tentaresolver com outros sistemas distribuídos

• Solução centrada em uma linguagem: todo o sistemaassume objetos Java, o que simplifica diversosaspectos– 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 javapromove 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çãoremota:

public interface RemoteServer extends Remote {public int getLenth(String s) throws RemoteException;

}

• O tipo Java é o protocolo, e portanto, podemosmanipular o tipo (extender, modificar) e estaremosalterando o protocolo

• Todo o poder da orientação a objetos em um mundodistribuido

• Polimorfismo poderoso. Por exemplo:public interface MatrixSolver extends Remote {

public Matrix crossProduct (Matrix m1, Matrix m2)throws RemoteException;

}

Natureza distribuida do Objeto está naInterface

• 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 sistemasdistribuidos desapareçam, nem fazer sistemasdistribuidos tão fáceis de serem desenvolvidos comosistemas locais

• Faz uma distinção clara entre objetos distribuidos elocais (mas usando a mesma tipagem Java)

• Obriga o desenvolvedor a tratar as falhas que podemocorrer em um sistema distribuido

Sistemas Distribuidos Dinâmicos

• As facilidades de Java (codigo e data móveis e tipagemforte) possibilitam uma mudança para sistemasdistribuídos dinâmicos

• Sistema composto de várias componentes, ao contráriode sistemas atuais onde temos váriso sistemasconectados 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 parasuportar a criação de sistemas distribuidosverdadeiramente dinâmicos

Jini Design

• Java tem muito a agregar a sitemas distrbuidos, e Jinitem muito a agregar a Java.

• A visão de Jini é voce ser capaz de conectar qualquerdevice “Jini enabled”, conectá-lo a uma rede, and serautomaticamente capaz de ver e utilizar outros devicese serviços existentes na rede.

• Como se o seu device tivesse sido programado parausar esses outros servicos e devices

Jini™ Architecture

Java VMRMIJava SecurityModel

Java APIsJavaBeans...

JNDIEnterprise BeansJTS

Extended RMIDiscoveryDistributedSecurityLookup

LeasingTwo PhaseCommitEvents

JavaSpaceTwo PhaseCommit Manager

BaseJava

Java+

Jini

ProgrammingModelInfrastructure Services

Let objects find eachother, and...

… add simple APIs forRemote Objects andBasic DistributedComputing, and...

… then everything else isa service.

Jini Design

• Jini foi desenvolvido procurando atender a um conjuntode prioridades:

• Simplicidade• Confiabilidade• Escalabilidade• Independência de aparelhos

Simplicidade

• Bill Joy: “large sucessfull systems start out as smallsuccessfull systems”

• Jim Waldo: “passei os ultimos 9 anos tentando fazeresse 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 deforma fácil

• Tudo são serviços: software, hardware

Confiabilidade

• Jini suporta interações entre serviços de forma apermitir que serviços apareçam e desapareçamfacilmente

• Partes interessadas podem ser notificadas quando oconjunto de serviços muda

• Não requer nenhuma configuração estática ouadministração: “spontaneous networking”

• Comunidades Jini são basicamente “auto-reparaveis” -Jini não assume que as redes são perfeitas ou quesoftware não falha. Dado o devido tempo, o sistema seauto-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, masquão escalável são essas comunidades?

• Comunidades são do tamanho de um workgroup, ouseja, todos os devices e serviços para grupos de cercade 10 e 100 pessoas

• Em geral, pessoas tendem a colaborar com as queestão perto

• Comunidades são formadas automaticamente dentrodos 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 gamade entidades

• É indiferente se entidades são hardware, software ouuma combinação

• Em geral, um usuário de um serviço não tem comosaber (e nem se importa)

• Jini é flexível para trabalhar com devices mesmo comlimitadas 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 facilidadesque Jini oferece estão baseadas em apenas 5conceitos. 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

Lookup

Discovery / Join

JavaSpaces™ Other Services

Jini

NetworkServices

{{

JAVA JAVA JAVA

Solaris

SPARC

Mac

PPC

Windows

X86

Discovery solves the problem offinding the place to start in anunknown network.

The lookup service binds thefederation together.

Leasing provides a method ofmanaging resources in anenvironment where network failurescan occur.

Events deal with the peculiarities ofmessages in the networkedenvironment, such as latency andnetwork failure.

Transactions allow distributedentities to cooperate in such a waythat the changes to the group occuratomically or not at all.

A space may be used to implementa large number of distributedcomputing patterns.

leasing

discovery

events

transactions

lookup

JavaSpace

Jini, como funciona?

Java Interface Code

�

�

�

�

Jini Lookup Service

Image Service Java Interface Code �

Service Request

Java Interface Code

Discovery

• Serviços precisam se juntar a uma comunidade parapoder ter acesso a serviços

• Para isso, uma entidade procura os lookup servicesmantém a lista de recursos disponíveis

• o processo de procurar e se registrar a um lookupservice é chamado de discovery

• o protocolo de discovery é usado para encontrarcomunidades, e o protoloco join é usado para seregistrar

• lookup services podem prover serviço para uma oumais comunidades, e cada comunidade pode ter um oumais 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 narede 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 lookupservice, o processo de lookup é o que podemos fazercom ele

• o Lookup Service é uma espécie de name service - éum processo que mantém registros de todos osserviços que se juntaram a uma comunidade

• as buscas em um lookup são feitas baseadas em tiposJava (normalmente interfaces)

• depois que o discovery encontrou um Lookup Service,retorna uma referência a um objeto que implementa ainterface de lookup ServiceRegistrar

• Os detalhes da implemtação do lookup service sãoescondidos

Publicando um Serviço

• Cada lookup service mantém uma lista de “serviceitens”. Cada item contém um objeto (proxy) que podeser usado para acessar o serviço, e uma lista deatributos que descrevem o serviço

• O método ServiceRegistrar.register() é usadopara 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ávelarbitrário que será recebid por qualquer serviço ouaplicação que queira tirar proveito do seu serviço

• o service proxy é que dá ao Jini a característica de seutilizar serviços sem nenhuma instalação de drivers ouconfiguração

Service Proxy

• pode ser considerado um device driver seguro e que écarregado sob demanda por clientes que precisaremutilizar o serviço

• um cliente não precisa entender a forma como o serviceproxy é 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çoatravés do lookup service

• a busca pode ser feita pelo tipo do proxy, peloidentificador 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çãode interfaces que está sendo realizado pela indústrianesse momento

• O lookup utiliza esse mecanismo durante o processo dedicovery/join

Leasing

• O esquema de leasing permite que um sitema Jini sejaestá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 delonga duração (meses e ate mesmo anos)

• Baseado na idéia de ao invés de se alocar recursos porperíodos ilimitados, “empresta-se” o recurso por umperiodo fixo de tempo

• podem ser negadas, renovadas, canceladas, ou podemexpirar normalmente, e podem ser negociadas

• leases são usadas em todo o sistema Jini para garantirque o sistema se auto-recupere, e tambem que se tornebasicamente 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 umalease 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 auto-recuperação de um sistema Jini, portanto, quanto maioro tempo de lease, mais demorará para o sistema serecuperar

Remote Events

• Servicos Jini precisam ser ocasionalmente notificadosde acontecimentos e mudanças de estado de outrosserviços

• Jini utiliza eventos distribuidos para fazer notificaçõesassíncronas. Um evento é um objeto que contéminformação sobre uma mudança de estado

• Eventos Jini são diferentes de eventos Java, porqueprecisam 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 requerimentosem 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, maspossuem 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” paraeventos (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 deum trasaction manager e um conjunto de classes einterfaces

• mas ao contrário de um banco de dados, Jini não definenenhuma semântica para a transação, apenas oprocesso é definido

• cada serviço decide o que significa participar em umatransação para esse serviço em particular

• qualquer número de serviços podem participar de umadeterminada transação

O que significa ser um serviço Jini

• As necessidades de um device para participar de umarede Jini são bastantes pequenas

• o device - ou algum compoente de software em favordo 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ãonecessariamente) 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 conjuntode devices

• Para incluir Jini nos seus devices, é importanteentender 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 deprocessamento

Jini em um computador de uso genérico

• A maior parte da mídia fala em Jini para pequenosdevices, mas Jini é perfeitamente utilizável noscomputadores 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çase 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 esã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 significarum problema, em especial para serviços que requeremtoda a capacidade da plataforma Java para executarem

Jini para controlar um device sem JVM

• Esse é o caminho que deve ser seguido pela maioriados aparelhos

• Nesse caso, uma máquina capaz de rodar uma JVMestá de alguma forma conectada ao device, e faz opapel de Jini proxy para o device

• O Jini proxy participa do processo de discovery elookup, registra the service proxy, gerencia leases, tudoem prol do device

• A conexão com o device acontece geralmente viaRS232, USB, firewire, X10, ou outro meio físicoqualquer (inclusive em alguns caso, a própria rede)

• Esse Jini proxy poderia ser um computador genérico,ou algum device especializado para conectar algum tipode aparelho

Quando Jini é apropriado?

• se existem ou irão existir servicos Jini que seu deviceou aplicação poderão utilizar para ser mais efetivo

• se seu device ou serviço puder fornecer valor paraoutros serviços ou devices

• se seu device já possui uma JVM, ou é normalmenteutilizado conectado a um computador genérico

• se seu software está rodando em um computadorcapaz de rodar uma JVM

• se seu software for facilmente separado emcomponentes, então talvez faça sentido separar cadaum em um serviço Jini

• se você está criando um device que será conectado aoutros 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 deuso genérico, são poucos os cenários onde Jini não seencaixa

• 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:Bruno.Souza@JavaMan.com.br

http://javaman.com.br

SouJavahttp://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 asCommunity 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