Exame de Qualifica¸cão do Mestrado - ime.usp.brlmap/mestrado/quali.pdfExame de Qualifica¸cão...

Exame de Qualificacao do Mestrado

(IME - USP)

Tecnologias de Localizacao Dinamica

de Servicos

Leonardo Marques Alves de [email protected]

Alfredo Goldman Vel Lejbman(orientador)

[email protected]

– Sao Paulo – Janeiro de 2003 –

Conteudo

Lista de Figuras i

Lista de Tabelas ii

Lista de Codigos Fonte iii

1 Introducao 1

1.1 Motivacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Tecnologias 4

2.1 Modelo com SM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Fase de Inicializacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.2 Fase de Consulta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.3 Fase de Selecao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.4 Fase de Configuracao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Modelo sem SM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.1 Fase de Consulta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.2 Fase de Selecao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.3 Fase de Configuracao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 Analise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Service Location Protocol (SLP) 8

3.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2 Modelos de interacao e operacoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2.1 Localizacao do DA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2.2 Registro de um SA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2.3 Consultas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1

3.3 Analise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4 Jini Network Technology 14

4.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.2 Funcionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.2.1 Localizacao do LS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.2.2 Publicacao do Servico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.2.3 Consultas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.3 Analise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5 Outras Arquiteturas 20

5.1 Salutation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.2 Microsoft Universal Plug and Play (UPnP) . . . . . . . . . . . . . . . . . . . . . . . . 20

5.3 Bluetooth Service Discovery Protocol (SDP) . . . . . . . . . . . . . . . . . . . . . . . . 21

6 Proposta 22

6.1 Localizacao de UMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6.2 Atividades atuais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6.2.1 Implementacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6.2.2 Proximos passos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Referencias Bibliograficas 24

i

Lista de Figuras

1.1 Empresas que desenvolvem sistemas de localizacao . . . . . . . . . . . . . . . . . . . . . 2

3.1 Cabecalho binario de uma mensagem no SLP . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2 Fase de inicializacao no SLP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.3 Fase de consulta no SLP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.1 Representacao da arquitetura do Jini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

ii

Lista de Tabelas

3.1 Campos do cabecalho de uma mensagem no SLP . . . . . . . . . . . . . . . . . . . . . . 9

3.2 Mensagens do SLP e suas descricoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

6.1 Cronograma de atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

iii

Lista de Codigos Fonte

4.1 Localizacao do Lookup Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.2 Registro do Service Provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.3 Consulta um Service Provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

0

Capıtulo 1

Introducao

1.1 Motivacao

Uma rede de computadores, em particular a Internet, e um conjunto de outras redes e/ou com-putadores interligados. Ela oferece aos seus usuarios um enorme potencial para compartilhamentode recursos, tais como documentos, programas, dados e principalmente servicos.

Definiremos servico como uma colecao de componentes distribuıdos colaborando entre si, a fimde disponibilizar um recurso ao cliente, seja ele fısico, como uma impressora, ou logico, como umenvio de e-mail. Alem desses servicos basicos, como impressao e envio de e-mail, estao surgindonovos servicos a cada dia.

Nesse ambiente, mecanismos para descoberta de servicos se tornam extremamente importantes.Sem eles, os usuarios utilizam uma fracao muita pequena dos benefıcios de uma rede, devido a faltade conhecimento dos servicos disponıveis.

Outro fator importante para a utilizacao dos servicos de uma rede e a forma de acesso a estes.Idealmente, os usuarios gostariam de acessar os servicos automaticamente, sem a necessidade dereconfigurar o seu sistema, como instalar drivers manualmente, ou procurar o endereco (por exemplo:IP) do servidor. Assim, e importante que os servicos sejam acessados com o mınimo de esforco, ouseja, com a menor reconfiguracao possıvel no dispositivo do cliente, que deseja utilizar o servico.

Esse cenario se torna mais problematico quando analisamos as redes sem fio e suas respecti-vas unidades moveis1 (UMs). Nesse tipo de rede, muito comum ultimamente, os clientes mudamfrequentemente, aumentando assim a tarefa do administrador, que precisa reconfigurar cada novoelemento da rede, para que este tenha acesso aos recursos da mesma. Alem disso, como as unidadessao moveis, em cada local (subrede) que o usuario estiver, sera necessario realizar novamente essetrabalho de configuracao.

Um exemplo tıpico e uma pessoa que deseja imprimir um arquivo do seu dispositivo movel(Palm, IPaq, etc) conectado a uma rede sem fio de um predio comercial. Na maioria das vezes, ousuario precisa contactar o administrador para descobrir o endereco da impressora mais proxima,suas caracterısticas e a forma de acesso. O usuario gostaria de utilizar um sistema em que elesimplesmente informe o interesse pelo servico de impressao e a aplicacao automaticamente encontre

1Chamaremos de unidade movel um usuario acompanhado de um dispositivo conectado a uma rede sem fio nopadrao IEEE 802.11.

1

CAPITULO 1. INTRODUCAO 2

a impressora mais proxima de acordo com a sua localizacao, e reconfigure o seu dispositivo para queseja possıvel a utilizacao da mesma.

O cenario ideal e uma rede que se gerencie sozinha, onde novos dispositivos e servicos sejamadicionados e recursos sejam utilizados, sem nenhuma intervencao administrativa, de forma analogaa tecnologia plug and play. Para isso, as aplicacoes precisam ser sensıveis ao contexto (context-aware),reconfigurando-se automaticamente conforme o local em que se encontram.

Portanto, e necessario um protocolo de localizacao de servicos, que descubra dinamicamente osservicos disponıveis em uma rede, e permita o acesso transparente a eles. Atualmente existem nomercado varias tecnologias que visam resolver esse problema (ver figura 1.1).

O Jini [11] e uma tecnologia desenvolvida pela Sun Microsystems, utilizando a linguagem Javae fortemente a sua camada para objetos distribuıdos: RMI - Remote Method Invocation; o ServiceLocation Protocol (SLP) [19] foi desenvolvido pelo IETF SrvLoc working group e foi projetado pararodar em redes locais sobre TCP/IP; o Universal Plug and Play [3] e uma arquitetura proprietariadesenvolvida pela Microsoft; o Salutation [3], por sua vez, esta sendo desenvolvido por um consorcioaberto, chamado Salutation Consortium; assim como o Bluetooth Service Discovery Protocol [21] quefoi criado por um consorcio de empresas de telecomunicacoes.

Hitachi

Fujitsu

Adaptive Networks

Bull Dallas

Gateway Dell

Sega Casio Sanyo

National Semiconductor

Minolta

Texas Instruments

Thomson

Mitsubishi

AOL

Metroworks

Nokia Inprise

FunaiPhilips

Tatung

SUNKinkos

Jini

IETFHP

UPnPIntelMicrosoft

QualcommCompaq

NECLexmarkLucent

Micron

ELSA

AMD

HP

Toshiba

SharpAxisOki

Canon

Seiko

Epson

Xerox

Salutation

IBM

Matsushita

Granite Systems

MurataFuji

Mita

Ricoh

Konica

Samsung

Quantum

3Com

Sony

Cisco

MotorolaEchelon

KodakAT&T

Siemens

Seagate

Symbian

Ericsson

Novell Creative Design

Phoenix

Semiconductors

BEA Systems

SUN Axis

Madison River TechIBM

LexmarkAppleNovell

SLP

Figura 1.1: Empresas que participam do desenvolvimento do Jini, SLP, UPnP e Salutation.

No proximo capıtulo descreveremos de forma generica o funcionamento de um sistema paralocalizacao de servicos. Nos capıtulos 3, 4 e 5, detalharemos algumas das principais tecnologias

2

CAPITULO 1. INTRODUCAO 3

existentes, citadas acima. No capıtulo 6 descreveremos com detalhes a proposta de projeto e orespectivo cronograma.

3

Capıtulo 2

Tecnologias

As tecnologias para descoberta de servicos foram desenvolvidas visando reduzir a complexidadeda utilizacao dos servicos, e assim, simplificar o uso de dispositivos moveis em uma rede.

Para isso, essas tecnologias proveem uma localizacao dinamica (“on the fly”) dos servicos dis-ponıveis. Alguns sistemas tambem ofecerem mecanismos de divulgacao de novos servicos e acessotransparente aos mesmos, atuando como uma “ponte” (middleware) entre o usuario e o provedordo servico. Sistemas mais avancados fornecem ainda um “esqueleto” para a implementacao de umservico, servindo como um arcabouco na criacao dos mesmos.

Para entendermos melhor esses sistemas, descreveremos a seguir um modelo generico para proto-colos de localizacao de servicos, que pretende abranger algumas caracterısticas comuns dos sistemasexistentes.

Todas as tecnologias de descoberta de servicos possuem um sistema de catalogo, equivalente auma lista de classificados ou “paginas amarelas”, para que o cliente tenha conhecimento dos servicosdisponıveis na rede ou procure por algum servico especıfico, atraves do seu tipo ou propriedade1.

Essa forma centralizada de armazenar os servicos estimula a intregacao dos mesmos, criandocomunidades espontaneas. Por exemplo, uma camera ligada a rede envia uma foto para uma impres-sora.

Por seguranca, os sistemas oferecem mecanismos de tolerancia a falhas e exclusao automatica deservicos inacessıveis, mantendo sua lista de servicos disponıveis sempre atualizada.

Em todos os cenarios descritos existem pelo menos dois elementos: o usuario do servico e o pro-vedor do servico. Em alguns sistemas, ha um elemento intermediario entre as requisicoes dos clientese as respostas dos provedores, geralmente chamado de gerenciador de servicos. Para referenciaresses elementos utilizaremos a seguinte abreviacao: C - Cliente, SP - Provedor do Servico e SM -Gerenciador de Servicos.

Conforme o numero de participantes, com ou sem SM, temos que considerar duas arquiteturasou modelos de interacao. Para cada caso, teremos diferentes fases do protocolo, que descrevemos aseguir:

• Fase de Inicializacao2;1Esse tipo de busca so esta disponıvel em alguns sistemas.2Essa fase existe apenas no modelo com SM.

4

CAPITULO 2. TECNOLOGIAS 5

• Fase de Consulta;

• Fase de Selecao;

• Fase de Configuracao.

2.1 Modelo com SM

Como dissemos anteriormente, a principal funcao do SM e atender as requisicoes do cliente, eencontrar os servicos disponıveis de acordo com o tipo requisitado, ou atraves das caracterısticas doservico descritas pelo cliente (modo opcional).

2.1.1 Fase de Inicializacao

• Localizacao do SM

Inicialmente e necessario que o cliente, de alguma forma, tenha a informacao (endereco) decomo acessar um SM da rede em que ele esta conectado. Para isso existem quatro possibilidades:

– static: o endereco de um SM e atribuıdo manualmente;

– active: os clientes e SPs requisitivam a localizacao de um SM (por exemplo atraves demulti/broadcast);

– passive: o SM anuncia periodicamente sua localizacao (por exemplo atraves de mul-ti/broadcast);

– dhcp: pode-se adaptar o DHCP [18], para que este forneca um SM responsavel por aquelarede.

Uma observacao importante: o modo passive pode aumentar bastante o trafego na rede,dependendo do perıodo escolhido, assim como o modo active, considerando-se o numero deelementos no sistema. Assim, os tres ultimos modos sao recomendados para redes locais (LAN)e o primeiro para redes globais (WAN), como a Internet.

• Registro dos SPs

Cada provedor de servico, apos localizar um SM, deve registrar-se no mesmo, fornecendoas informacoes necessarias para o seu acesso, e em alguns casos, a lista de atributos (carac-terısticas) que descrevem o servico. Geralmente existe um mecanismo para a atualizacao daspropriedades do servico do SP, apos o seu registro.

Os registros podem ser persistentes, ou seja o SM armazena fisicamente as informacoes dosSPs disponıveis. Caso ocorra uma interrupcao no funcionamento do mesmo, os servidores naoprecisarao se registrar novamente, mas isso provoca um custo adicional no processo de registro.

2.1.2 Fase de Consulta

O objetivo dessa fase e informar ao SM sobre o interesse do cliente por algum tipo de servico.Alguns protocolos tambem permitem a requisicao por um servico com certas caracterısticas, porexemplo: um servico de impressao colorida.

5


2.1.3 Fase de Selecao

Nesta fase desejamos selecionar o SP correspondente ao pedido do cliente (C). Vamos dividı-laem duas subfases:

• Subfase de comparacao

Desejamos encontrar o subconjunto de SPs da lista de servicos disponıveis (registrados noSM) que atendem a requisicao do cliente.

• Subfase de decisao

Depois de encontrado o subconjunto, decidiremos como sera a resposta ao cliente, se iremossimplesmente retornar a lista de todos os SPs que atendem o seu pedido, se iremos escolheraleatoriamente um SP, ou, o mais apropriado, utilizaremos algum criterio para a decisao, porexemplo, o SP mais proximo ao cliente. Infelizmente, nenhum sistema prove essa funcionali-dade. A maioria dos sistemas permite apenas que o cliente especifique se deseja receber a listade todos os servidores ou apenas um servidor que atenda o seu pedido.

2.1.4 Fase de Configuracao

Nesta ultima fase e modificada a configuracao do cliente, para que este possa acessar o servicodesejado.

2.2 Modelo sem SM

Nessa arquitetura temos apenas dois participantes: clientes (C) e provedores de servicos (SP).Por isso o processo e um pouco mais simples, com apenas tres fases, como nao existe SM, nao temosa fase de inicializacao.

2.2.1 Fase de Consulta

Ao inves do cliente se comunicar diretamente com o SM (por exemplo via UDP unicast), ele secomunica com os SPs indiretamente utilizando a rede (por exemplo por UDP multicast), enviando asua requisicao. Os provedores de servicos que estiverem disponıveis, irao processar a requisicao.

2.2.2 Fase de Selecao

Nesse modelo temos apenas a subfase de comparacao, que sera executada localmente por cadaagente de servico. Caso ele atenda o pedido do cliente, o SP se comunica diretamente com o cliente(por exemplo via unicast) dando-lhe as informacoes de como acessa-lo.

2.2.3 Fase de Configuracao

Identica a fase do modelo com SM, a configuracao do cliente e modificada para que este acesse oservico desejado.

6


2.3 Analise

A arquitetura sem SM e mais simples, nao contempla um repositorio de servicos, toda comu-nicacao e feita diretamente entre o cliente e os provedores de servicos. Devido a isso, o trafego demensagens de multicast aumenta consideravelmente na rede, prejudicando o desempenho do sistema.

Alem disso, devido a falta de um gerenciador de servicos perderemos algumas funcionalidadesdo sistema: nao existira uma lista de servicos disponıvel na rede, buscas avancadas de servicos naopoderao ser utilizadas, qualquer modificacao no protocolo em relacao a essa fase de selecao deveraser realizada em todos os SPs, pois essa fase e executada em cada SP da rede.

Assim, o modelo sem SM e indicado para redes pequenas, onde o desempenho nao e tao importantee as funcionalidades mais complexas de busca de servicos nao serao utilizadas. A arquitetura comSM, por sua vez, e indica para redes maiores, em que o desempenho e essencial, e o aumento donumero de troca de mensagens poderia ser prejudicial a rede.

7

Capıtulo 3

Service Location Protocol (SLP)

Service Location Protocol foi desenvolvido pelo IETF (Internet Engineering Task Force) parapossibilitar que uma aplicacao descubra automaticamente a localizacao de um servico desejado,incluindo o endereco (ou domınio) e outras informacoes de acesso. Como todos os protocolos doIETF, o SLP e especificado com muitos detalhes em documentos denominados Request For Comments(RFC).

Em 1997, o Srvloc working group do IETF publicou um RFC [12] com a primeira versao do SLPque continha algumas inconsistencias. Entretanto, em junho de 1999, o Internet Engineering TaskForce anunciou a segunda versao do protocolo, adicionando novas funcionalidades, aumentando aseguranca e eliminando as inconsistencias.

3.1 Arquitetura

Sua nova arquitetura e composta por tres agentes, que interagem entre si:

• User Agent (UA)1, o usuario do servico, que procura pela localizacao de um servico;

• Service Agente (SA), o provedor do servico, responsavel por oferecer um servico a rede;

• Directory Agent (DA)2, o repositorio de servicos, que atua como uma central de informacaosobre a localizacao dos servicos existentes na rede.

A comunicacao entre os agentes e feita utilizando 11 tipos de mensagens (descritas na tabela 3.2)enviadas atraves do protocolo de comunicacao TCP/IP ou do protocolo UDP. A mensagem pode serenviada para um agente especıfico (unicast) ou para todos os agentes interessados (multicast). Deve-mos esclarecer que multicast nao e o mesmo que broadcast, pois mensagens de broadcast teoricamentesao recebidas por todos os nos da rede, enquanto que mensagens de multicast sao recebidas apenaspelos nos interessados nelas, que fazem parte do grupo do multicast.

Alem disso, a maioria dos roteadores filtram mensagem de broadcast a fim de reduzir o trafego narede. Assim, mensagens desse tipo que forem geradas em uma subrede nao serao redirecionadas para

1Frequentemente utilizaremos essa sigla para fazer referencia a este.2Para melhorar o desempenho do sistema, podera existir mais de um DA na rede. Para simplicar o texto, descre-

veremos uma rede em que existe apenas um DA.

8

CAPITULO 3. SERVICE LOCATION PROTOCOL (SLP) 9

outras subredes conectadas ao roteador. Mensagens de multicast, por sua vez, sao redirecionadaspelos roteadores se a subrede de destino que tem pelo menos um no interessado na mensagem. Devidoa essas razoes, o SLP foi especificado para ser um protocolo unicast e multicast.

Todas as mensagens transmitidas sao alfa-numericas mas precedidas de um cabecalho binario,como mostra a figura 3.1. O conteudo da mensagem e composto por UTF-8 strings precedidos deum campo informando o tamanho da serie de caracteres. (Veja na tabela 3.1 a descricao de cadacampo do cabecalho.)

XID

Language tag length Language tag

Next extension continued

Next extensionFlagsLength cont.

Version Func. ID Length00

04

08

0C

Figura 3.1: Cabecalho binario de uma mensagem no SLP.

Campo do cabecalho DescricaoVersion Versao do protocolo SLP: 1 ou 2.Length Tamanho total da mensagem.Function ID Tipo da mensagem enviada (ver tabela 3.2).Flags Indica forma de envio da mensagem: uni/multicast.Next extension offset Offset, em bytes, da primeira extensao SLP.XID Identificador unico para cada requisicao.Language tag Indica a linguagem das strings incluıdas na mensagem.Language tag length Tamanho da string de linguagem.

Tabela 3.1: Campos do cabecalho de uma mensagem no SLP.

Como podemos ver na tabela 3.2, a comunicacao entre os componentes do sistema e feita atravesde pares de mensagens, por exemplo: Service Request (SrvRqst) - Service Reply (SrvRply),Attribute Request (AtrReq) - Attribute Reply (AtrRply), entre outros.

3.2 Modelos de interacao e operacoes

O sistema oferece dois modos de operacao: quando o DA esta presente, ele e responsavel porregistrar os servicos de um SA e atender as requisicoes de um UA; no outro modo, em que o DAnao esta presente, nao ha registro do servico e as requisicoes do UA sao feitas diretamente aos SAs,atraves de multicast.

9


Mensagem SLP ID DescricaoService Request (SrvRqst) 1 UAs requisitam um servicoService Reply (SrvRqst) 2 DA (ou SA) retorna sua URL para o cliente.Service Register (SrvReg) 3 SA registra URL e atributos.Service Deregister (SrvDeReg) 4 SA pede ao DA a exclusao do seu registro.Service Acknowledgment (SrvAck) 5 DA confirma o registro ou exclusao de um servico.Attribute Request (AttrRqst) 6 UAs requisitam a lista de atributos de um servico.Attribute Reply (AttrRply) 7 DA (ou SA) retorna a lista dos atributos pedida.Directory Advertisement (DAAdvert) 8 DA envia sua localizacao (URL).Service Type Request (SrvTypeRqst) 9 UAs pedem a lista dos tipos de servico.Service Type Reply (SrvTypeRply) 10 DA (ou SA) retornam a lista de tipos cadastrados.Service Advertisement (SAAdvert) 11 SA envia sua URL e atributos para o UA.

Tabela 3.2: Tipos de Mensagens do SLP e suas descricoes.

3.2.1 Localizacao do DA

Inicialmente, para que seja feita qualquer acao neste modelo, por parte do SA ou do UA, enecessario descobrir quem e o DA da rede. A figura 3.2 ilustra os dois diferentes metodos para alocalizacao de um DA: ativo ou passivo.

No modo ativo, os agentes UAs e SAs solicitam a localizacao de um DA atraves do envio (viamulticast) de uma mensagem de requisicao do servico (SrvRqst), procurando por um tipo especialde servico: service:directory-agent (pre-definido pelo protocolo). Quando um DA recebe estamensagem, ele envia (via unicast) para o UA, ou SA, uma mensagem DAAdvert com o seu endereco(IP) atual.

No modo passivo, por sua vez, o DA envia periodicamente uma mensagem DAAdvert (multicast)informando sua localizacao a todos.

Existem outros dois modos que nao sao muito utilizados: dhcp [18], em que o servico de DHCPe configurado para informar a localizacao do DA; e o estatico, utilizado quando o agente ja temconhecimento previo do endereco do DA.

3.2.2 Registro de um SA

No SLP, a localizacao de um servico e descrita atraves de uma Service URL3, que e compostapor: endereco IP, numero da porta e, dependendo do tipo do servico, o caminho (path). Os clientes(UAs) que obtem essa URL, tambem chamada de SAP (Service Access Point), tem toda informacaonecessaria para se conectar a este servico.

As caracterısiticas de um tipo de servico, por sua vez, sao descritas atraves de uma lista deatributos, definidos pelo par nome/valor. Para os tipos de servicos conhecidos existe um documentochamado Service Templates [4], registrado na IANA (Internet Assigned Numbers Authority), queespecifica os atributos e seus valores-padrao para um determinado tipo de servico. Os SAs utilizamos atributos especificados para descrever o seu servico, e os UAs os utilizam para procurar um servicocom determinadas caracterısticas. Isso assegura que os agentes utilizarao o mesmo vocabulario

3URL e abreveicao de Universal Resource Locators.

10


durante essas operacoes.

Como podemos ver na figura 3.2, para um SA publicar um servico, apos conhecer o endereco deum DA (executando o protocolo descrito na secao anterior), ele envia uma mensagem SrvReg comas informacoes descritas anteriormente: tipo de servico, URL e lista de atributos.

Alem dessas informacoes, o SA tambem fornece o tempo (lifetime) que deve durar o cadastro,que nao pode ultrapassar 18 horas. Assim, para o SA estar sempre disponıvel, ele deve se registrarnovamente antes que esse tempo expire. Esse procedimento estabelece um mecanismo de toleranciaa falhas a fim de assegurar que os servicos publicados estejam sempre acessıveis, pois se um SA temuma falha, o seu cadastro nao sera renovado, logo, seu registro sera excluıdo quando o lifetime expirar.Esse mecanismo sera mais eficiente quanto menor for o lifetime. Mas aqui temos um compromisso,pois, quanto menor for o tempo, maior sera o trafego de mensagens SrvReg na rede.

A operacao termina quando o DA recebe a mensagem SrvReg ıntegra e envia ao SA uma men-sagem de confirmacao SrvAck do registro do servico. O SA tem a possibilidade de pedir a exclusaodo seu registro a qualquer momento atraves da mensagem SrvDeReg.

User Agent Directory Agent Service Agent

Localiza DA

DAAdvert

SrvAck

SrvReg

Registra SA

SrvRqst SrvRqst

DAAdvert

Figura 3.2: Simulacao da troca de mensagens na fase de inicializacao.

11


3.2.3 Consultas

No SLP, o usuario nao precisa conhecer os nomes ou enderecos dos agentes de servico, ele apenasprecisa informar a descricao do servico em que ele esta interessado e, baseado nessa descricao, o SLPretornara o SAP que contem todas as informacoes de acesso ao respectivo servico.

Nesta operacao, nos teremos diferentes acoes de acordo com o modelo adotado: com ou semDA (ver figura 3.3). No modelo com DA, o cliente (UA), que ja obteve o endereco do DA na fasede inicializacao, envia a este uma mensagem (unicast) de SrvRqst, informando o tipo de servicoprocurado e, opcionalmente, as caracterısticas (atributos) que o servico deve ter.

Quando o DA recebe uma mensagem de SrvRqst, que nao seja do tipo especial (pre-definido peloprotocolo): service:directory-agent (ver secao 3.2.1), ele realiza uma busca no seu repositoriopor servicos que atendam a requisicao. Em seguida, o DA envia uma mensagem (unicast) SrvRplycontendo todas as URLs dos SAs que atendem ao pedido, ou uma mensagem com conteudo vazio,caso nao encontre nenhum SA para a requisicao realizada.

No modelo sem DA, por sua vez, um UA envia a mensagem SrvRqst (via UDP multicast) paraos SPs da rede, que analisam a requisicao. Caso satisfaca o pedido o SP respondera enviando umamensagem (unicast) SAAdvert contendo a sua URL de acesso.

No momento em que o UA recebe as URLs dos SAs, ele obtem a informacao necessaria parase conectar ao servidor. Entretanto, o protocolo utilizado entre o cliente e o servidor esta fora doescopo da especificacao do SLP.

Alem dessa operacao principal de consulta, o cliente ainda pode realizar duas consultas se-cundarias: tipos de servicos e atributos de um servico ou tipo de servico.

A consulta dos tipos de servicos e bem simples: o UA envia uma mensagem de SrvTypeRqst parao DA, que responde atraves de uma mensagem SrvTypeRply contendo a lista dos tipos de servicosdisponıveis. Na consulta de atributos, por sua vez, o cliente especifica qual servico ou tipo de servicode seu interesse, enviando uma mensagem AttrRqst ao DA, que atendera a solicitacao atraves doenvio de uma mensagem AttrRply contendo a lista de atributos encontrados.

3.3 Analise

O SLP e um protocolo leve, totalmente baseado na troca de mensagens via TCP/IP ou UDP.Ele oferece um sistema de localizacao de servicos bem completo em relacao ao registro e consulta deservicos, prove uma descricao detalhada do servico e diferentes tipos de busca.

Seu principal defeito e nao especificar uma forma de acesso do cliente ao servico, preocupando-seapenas em como encontrar o servico, mas nao contemplando a forma de utilizacao do mesmo.

Outro problema, que existe na maioria dos protocolos, e a falta de selecao do SA mais convenientepara o cliente. Por exemplo o mais proximo, pois um cliente que deseja imprimir um artigo, comcerteza nao gostaria que seu artigo fosse impresso muito longe de onde ele se encontra.

12


Service Agent

Consulta Srv(com DA)

ConsultasAuxiliares

SrvRqst

AttrRqst

SrvRqst

SrvTypeRqst

User Agent

SrvRply

Consulta Srv(sem DA)SAAdvert

Directory Agent

SrvTypeRply

AttrRply

Figura 3.3: Simulacao da troca de mensagens na fase de consulta.

13

Capıtulo 4

Jini Network Technology

O Jini[10] foi desenvolvido pela Sun Microsystems Inc. com o objetivo de possibilitar a criacaode um centro de servicos em uma rede. Atraves desse centro, os usuarios podem descobrir facilmenteos servicos existentes na rede.

Para ser possıvel a descoberta dinamica dos servicos, o Jini armazena uma lista dos servicos darede, e por isso, inicialmente ele pode ser comparado ao DNS (Domain Name Server), mas veremosque ele tem muitas outras vantagens, nao sendo apenas um servidor de nomes.

Alem de localizar o servico, o Jini tambem fornece uma forma de acesso transparente ao recursodesejado. Baseado na mobilidade de codigo do servico, ele substitui a necessidade de pre-instalacaode drivers no cliente, automatizando o processo de configuracao para acesso a um servico.

Ademais, no processo de consulta de servicos, a arquitetura fornece a busca pelo nome (ou tipo)do servico e/ou atraves dos atributos do mesmo. Por exemplo, um usuario que deseja encontraruma impressora na rede, mas necessita de impressora colorida ou laser. O Jini tambem prove ummecanismo para notificacao de eventos, logo, se o servico nao e encontrado, o sistema oferece apossibilidade ao cliente interessado no recurso de ser avisado automaticamente quando este estiverdisponıvel.

O sistema permite ainda falhas dos servidores, reajustando-se automaticamente a um novo cenarioe desabilitanto o servico oferecido por eles, evitando que o cliente tente acessar um servidor indis-ponıvel em um dado momento.

4.1 Arquitetura

O Jini foi desenvolvido sobre a linguagem Java, utilizando sua tecnologia para objetos distri-buıdos: RMI - Remote Method Invocation na comunicacao entre os elementos do sistema, por issoele depende tambem da camada de rede e obviamente, do sistema operacional. Sua implementacaoatual e baseada nos protocolos de comunicacao TCP/IP e UDP, mas implementacoes baseadas emoutros protocolos sao possıveis.

Portanto podemos traduzir sua arquitetura nas seguintes camadas:

14

CAPITULO 4. JINI NETWORK TECHNOLOGY 15

Cliente Servidor

Jini Network Technology

Java − RMI

Sistema Operacional

Transporte de rede

Figura 4.1: Camadas presente na arquitetura do Jini.

O Jini e composto por tres elementos: Lookup Service (LS), Service Provider (SP), Client (C).Os dois ultimos elementos sao os usuarios finais do sistema.

O Service Provider e o elemento que disponibiliza o servico e o Client e o elemento que desejautiliza-los. O Lookup Service e um elemento intermediario entre as requisicoes dos clientes e dosprovedores, geralmente chamado de localizador de servicos, ou gerenciador de servicos. Ele e oelemento principal do sistema, responsavel pelas funcionalidades principais do Jini: mantem a listados servicos registrados, gerencia acesso a um servico, notifica clientes sobre novos servicos, etc.

4.2 Funcionamento

O seu funcionamente e descrito atraves de micro-protocolos, que serao explicados abaixo:

4.2.1 Localizacao do LS

No Jini, todas operacoes sao realizadas atraves do LS. Portanto, para um cliente acessar umservico, ou um servidor publicar um servico, ele precisa inicialmente ter acesso ao LS da rede, emque ele esta conectado. Para isso existem tres possibilidades:

• Multicast Request: SPs e clientes realizam multicast, requisitando a localizacao do LS;

• Multicast Announcement: o LS realiza multicast periodicos com a sua localizacao;

• Unicast Discovery: Clientes e SPs se comunicam com um LS especıfico.

O protocolo Unicast Discovery culmina com a transferencia de um objeto remoto (stub RMI)referente ao LS especıfico. O objeto e uma instancia da classe ServiceRegistrar que possibilitatodas as operacoes sobre o LS encontrado, como a consulta e registro de servicos. Todas as interacoesentre o LS e os outros elementos sao feitas atraves do RMI.

No quadro 4.1, mostramos um trecho de codigo correspondente a execucao do Multicast RequestProtocol.

15


1 public class FindLS implements DiscoveryListener {2

3 public FindLS() throws IOException {4 // Estabelece a security manager5 System.setSecurityManager(new RMISecurityManager());6

7 // Procura LS pertencente a um grupo, string vazia e o grupo padr~ao8 LookupDiscovery disco = new LookupDiscovery(new String[] { "" });9

10 // Registro o objeto que processara as respostas dos LSs encontrados11 disco.addDiscoveryListener(this);12 }13

14 // Metodo chamado quando um novo LS e encontrado15 public void discovered(DiscoveryEvent ev) {16 ServiceRegistrar[] newregs = ev.getRegistrars();17 for (int i = 0; i < newregs.length; i++) {18 // realiza operac~ao desejada19 ...20 }21 }22

23 // Metodo chamado quando um LS e finalizado24 public void discarded(DiscoveryEvent ev) {25 ...26 }27

28 ...29 }

Codigo 4.1: Implementacao para localizacao do Lookup Service.

4.2.2 Publicacao do Servico

Cada provedor de servico, depois de localizar o LS, deve se registrar ao mesmo com as informacoesrelevantes a sua descricao, como o tipo de servico oferecido e, opcionalmente, a lista de atributos quedescrevem o servico; alem das informacoes necessarias para o seu acesso.

No Jini, todas essas informacoes de acesso ao servico ficam armazenadas em um objeto denomi-nado service proxy, que encapsula a localizacao do servico e o protocolo necessario para opera-lo,permitindo um acesso transparente ao recurso. A definicao desse objeto e bem flexıvel, podendo sertotalmente implementado em software e, depois de descoberto, ser enviado e executado inteiramenteno cliente; pode ser um proxy que contem a informacao de conexao ao servidor, como o IP, porta deacesso e protocolo utilizado; ou um objeto remoto, por exemplo um stub RMI. A unica exigencia eque esse objeto seja serializavel para ser possıvel o seu envio ao cliente.

Para o registro efetivo do servico e utilizado um objeto da classe ServiceItem, que e instanciadorecebendo tres argumentos: o id do servico (opcional, pode ser null), utilizado somente quandoo servico ja foi registrado uma vez; service proxy, que e a implementacao do servico; e o ultimoargumento e um vetor de atributos que descrevem o servico a ser registrado.

Por ultimo, e preciso definir a polıtica de leasing, pois ao registrar o servico, este sera valido

16


somente pelo perıodo de tempo especificado durante o registro. Apos esse perıodo, o leasing precisaser renovado para o servidor continuar disponıvel. Portanto, para servidores permanentes e necessarioinicializar uma Thread, que mantenha sempre o leasing valido, renovando-o periodicamente. Atravesdisso, e possıvel ao Jini identificar os servidores inacessıveis, retirando-os da lista dos servidoresdisponıveis.

O servico e publicado atraves do metodo register() do objeto ServiceRegistrar, que recebecomo parametro uma instancia da classe ServiceItem e o tempo de expiracao desse registro (leasingtime), como mostra o quadro 4.2. O resultado da publicacao sera armazenado no objeto de retornoServiceRegistration, que contem um id identificando o seu registro, e podendo ser mais tardeutilizado para atualizar o codigo do service proxy, nao sendo necessario reinstalar em cada cliente anova versao da implementacao.

1 ...2 protected final int LEASE_TIME = 1000 * 60 * 1000;3 protected ServiceItem item;4

5 public PublicaSP() {6 // Descreve o servico7 ServiceID id = null8 Entry[] attributes = null;9 MyServiceProxy sp = new MyServiceProxy(...);

10

11 item = new ServiceItem(id, sp, attributes);12 ...13 }14

15 // Metodo chamado quando um novo LS e encontrado16 public void discovered(DiscoveryEvent ev) {17 ServiceRegistrar[] newregs = ev.getRegistrars();18 for (int i = 0; i < newregs.length; i++) {19 // realiza operac~ao desejada20 registerWithLookup(newregs[i]);21 }22 }23

24 // Metodo que realiza o registro do servico25 private void registerWithLookup(ServiceRegistrar registrar) {26 ServiceRegistration registration = null;27 try {28 registration = registrar.register(item, LEASE_TIME);29 if (item.serviceID == null) {30 item.serviceID = registration.getServiceID();31 }32 } catch (RemoteException ex) { }33 }34 ...

Codigo 4.2: Implementacao do registro de um Service Provider.

17


4.2.3 Consultas

O objetivo dessa fase e informar ao LS o interesse do cliente por um tipo de servico enviandouma requisicao de busca por tipo, ou por um servico com certas caracterısticas, por exemplo: umservico de impressao laser.

Assim e necessario instanciar um objeto que representara a consulta, no caso do Jini implemen-tado atraves da classe ServiceTemplate. Este objeto e instanciado recebendo tres argumentos: id,o identificador do servico, que e opcional e pode ser null; o vetor de atributos desejados, e o ultimoargumento, que representa o tipo do servico, identificado pelo nome de uma interface Java. Assim,o LS ira buscar o servico atraves do tipo, utilizando o “comando” instanceof do Java.

Para efetuar a busca, os clientes utilizam o metodo lookup() de uma instancia do Lookup Ser-vice (ServiceRegistrar), como mostra o quadro 4.3. Esse metodo recebe um objeto da classeServiceTemplate como parametro. O retorno do metodo, que representa o resultado da consulta,sera um objeto ServiceMatches, que contem um vetor de instancias ServiceItem, representandoos servicos encontrados.

Quando o cliente obtem o objeto ServiceItem, ele recupera a implementacao do servico (serviceproxy) atraves da propriedade service, e utiliza os metodos disponıveis para ter acesso ao mesmo.

1 ...2 protected ServiceTemplate template;3

4 public ConsultaSP() {5 // Descreve o servico6 ServiceID id = null7 Entry[] attributes = null;8 Class[] types = { MyServiceInterface.class };9

10 template = new ServiceTemplate(id, types, attributes);11 ...12 }13

14 // Metodo chamado quando um novo LS e encontrado15 public void discovered(DiscoveryEvent ev) {16 ServiceRegistrar[] newregs = ev.getRegistrars();17 for (int i = 0; i < newregs.length; i++) {18 lookForService(newregs[i]);19 }20 }21

22 // Metodo que o acesso ao servico23 private void lookForService(ServiceRegistrar lusvc) {24 try {25 Object o = lusvc.lookup(template);26 MyServiceInterface mySP = ((MyServiceInterface) o);27 mySP.execService();28 } catch (RemoteException ex) { }29 }30 ...

Codigo 4.3: Implementacao da consulta de um Service Provider.

18


4.3 Analise

O Jini e um sistema mais complexo e com maiores recursos que o SLP. Sua principal vantagem edisponibilizar ao cliente uma forma de acesso transparente aos servicos, pois em sua lista de cadastroe armazenada tambem a implementacao do servico, e nao apenas o endereco do servidor.

Um dos principais problemas do Jini, e a obrigatoriedade do cliente conhecer a interface do servicoem que ele esta interessado, os seus metodos e nome, para ser possıvel o acesso e a busca por tipo,respectivamente. Para amenizar esse problema, a Sun esta propondo uma padronizacao de interfacespara os servicos mais conhecidos, como de impressao, envio de emails, etc. E a partir dessa interface,cada fabricante implementara o seu servico.

Assim como o SLP, o Jini nao prove um metodo para selecao de servicos, depois de encontradoo conjunto de servidores que atendem a requisicao. O ideal seria que o sistema automaticamenteescolhesse o servidor mais apropriado para aquele cliente, como o servico mais proximo, ou o commenos demanda, podendo ser implementado um mecanismo de balaceamento de carga.

19

Capıtulo 5

Outras Arquiteturas

Nesse capıtulo descreveremos sistemas menos conhecidos, alguns ainda em fase de desenvolvi-mento, e que nao tem muitas referencias na literatura. Por esse motivo, faremos uma breve descricaode cada um deles.

5.1 Salutation

Essa arquitetura esta sendo desenvolvido por um consorcio aberto[3]. A principal diferenca entreesse sistema e os outros, e o seu elemento principal, o Salutation Manager (SLM), tambem chamadode service broker, pois e responsavel por todo o processo de operacao do sistema, inclusive intermediaro acesso do cliente ao servico.

Como nos outros protocolos, os servidores utilizam o SLM para registrar os servicos, e os clientespara requisitar um determinado servico. Quando o servico desejado e localizado, o acesso ao mesmoe feito inteiramente atraves do SLM.

Alem do SLM, o sistema contem um outro elemento, o Transport Manager, em uma camadaabaixo do SLM. Ele e responsavel por informar os clientes e servidores a localizacao do SLM, e pelaabstracao da camada de tranporte. Dessa forma, o Salutation se torna independente de protolocode transporte, mas no momento so existe implementacao sob IrDA e TCP/IP.

5.2 Microsoft Universal Plug and Play (UPnP)

Nesta arquitetura, ainda sendo desenvolvida pela Microsoft, nao existe o elemento SM, portantoele oferece apenas um modo de iteracao, baseado em requisicoes via UDP multi/broadcast ou HTTP.Seu protocolo de localizacao de servicos e chamado Simple Service Discovery Protocol (SSDP).

O cliente envia uma mensagem requisitando apenas o tipo de servico, pois a busca por atributosnao esta disponıvel, e os provedores de servicos que oferecem o servico requisitado, respondem viaunicast ao cliente.

20

CAPITULO 5. OUTRAS ARQUITETURAS 21

5.3 Bluetooth Service Discovery Protocol (SDP)

O SDP [21] suporta consultas por um determinado tipo de servico e tambem de acordo com osatributos do servico. Mas apos o servico ser encontrado, ele nao prove o acesso ao servico, que deveser feito atraves de um outro mecanismo.

Por esse motivo, ele pode ser usado em conjunto com outros protocolos de localizacao de servico,que contem essa funcionalidade, como o SLP ou Salutation, sendo o SDP apenas responsavel porlocalizar os servicos disponıveis, de acordo com a requisicao.

21

Capıtulo 6

Proposta

Neste documento foram descritos os principais sistemas para localizacao de servicos, alguns maisconhecidos como o Jini e o SLP, e outros em fase de desenvolvimento, como o UPnP. Nosso objetivoinicial e aprofundar o conhecimento nas arquiteturas citadas, descrevendo-as de forma precisa eelaborando uma analise comparativa entre as mesmas.

A analise comparativa pretende ser ampla, mostrando as diferencas estruturais entre os proto-colos escolhidos, seus requisitos, funcionalidades e desempenho de cada um. Para isso, decidimosimplementar, nos sistemas SLP, Jini, Salutation e/ou UPnP, um servico de impressao e os respectivosclientes, mostrando as diferencas de implementacao em cada caso. Infelizmente nao conseguiremosimplementar o servico no sistema SDP devido a necessidade de uma rede Bluetooth.

6.1 Localizacao de UMs

Como foi mencionado nos capıtulos anteriores, nenhum sistema possui a funcionalidade de es-colher o servico mais conveniente ao usuario, como o servidor mais proximo a ele. No servico deimpressao, essa funcionalidade seria extremamente util, pois, por razoes obvias, o cliente geralmentegostaria de utilizar a impressora mais proxima a ele. Isso e ainda mais importante em ambientesgrandes de rede sem fio, como o predio do IME, em que uma UM pode estar em qualquer andar oubloco.

Portanto, e necessario o estudo de solucoes para localizacao fısica de unidades moveis [6], taiscomo GPS, Active Badge Systems, Ekahau Positioning Engine, Microsoft Radar, Cricket, etc. Nonosso caso, pretendemos utilizar uma tecnologia para ambientes indoor, logo descartaremos sistemascomo o GPS. Ademais, gostariamos que o sistema utilizasse apenas a infraestrutura da rede sem fioIEEE 802.11, por isso utilizaremos tecnologias como o Microsoft Radar [1] ou Ekahau PositioningEngine [9].

Assim, e nossa intencao, tambem, integrar os sistemas de descoberta de servicos as tecnologiasde localizacao fısica de UMs, a fim de construir uma aplicacao sensıvel a localizacao (location-aware)[23], que utilize sempre a impressora mais proxima ao usuario, respeitando as opcoes de busca doservico.

22

CAPITULO 6. PROPOSTA 23

6.2 Atividades atuais

Durante o ano de 2001 e o primeiro semestre de 2002 foi realizado um estudo intensivo sobreos sistemas de localizacao, a fim de resolver o problema da impressora proposto acima. Com isso,obtivemos uma base consistente para desenvolver o nosso projeto de dissertacao.

Ademais, com a base ja formada, foi realizado um seminario1 em que o aluno pode expor a suapesquisa e uma pequena amostra da especificacao do projeto.

6.2.1 Implementacao

No momento estamos finalizando a implementacao do servico no Jini e no SLP. A implementacaodo SLP utilizada e da Universidade de Columbia, feita em Java, para facilitar a comparacao com aaplicacao criada no Jini.

Para implementar o sistema no SLP fizemos pequenas alteracoes na sua especificacao. Incluimosum novo tipo de mensagem: SrvRqstWithLocation, que contem os mesmos campos da mensagemSrvRqst mas com um campo adicional: User Location, que informa a localizacao atual da unidademovel. Assim, no momento da requisicao de um servico, no caso de impressao, o DA tera conheci-mento da localizacao do usuario e podera encontrar o servidor mais proximo ao cliente.

Para isso, o SA precisa se registrar com um atributo padrao SrvLocation que informa a localizacao,geralmente fixa, da impressora. Alem disso, modificamos o DA para receber mensagens do tipoSrvRqstWithLocation e ao recebe-la, realiza uma busca na sua lista de servicos considerando alocalizacao informada pelo usuario. Isso foi feito atraves da reescrita do metodo getMatchedURL,que apos a busca dos servicos, escolhe o servico mais proximo de acordo com a sua semantica deproximidade.

Apos a selecao do servico, o cliente tera a informacao da URL do servidor de impressao maisproximo. Entretanto, para ser possıvel a utilizacao da impressora, e necessario que o SA estejaesperando requisicoes em uma porta especıfica. Assim, construimos um SA que registra a sua URL(IP + porta) no DA e abre um socket na respectiva porta. O cliente pode entao se conectar nessaporta enviando o arquivo, que representaremos pelo objeto serializavel File, atraves do socket. Oservidor, ao receber o mesmo, pode reconstruir o objeto File, salva-lo temporariamente no disco eenvia-lo para a impressora.

No sistema feito em Jini, por sua vez, nao utilizamos sockets devido a sua arquitetura. O Ser-vice Provider simplesmente se registra no LS com um atributo de localizacao e a implementacaoda sua classe de acesso. O atributo de localizacao foi adicionado atraves da criacao de uma clas-se ServiceLocation que estende a classe AbstractEntry para que seja possivel sua inclusao novetor de atributos, representados no Jini pelo objeto Entry (reveja o quadro 4.2 para um melhorentendimento).

O Lookup Service foi modificado para receber a localizacao do cliente e, de acordo com esta,encontrar o SP mais proximo a ele. Para isso, estendemos a classe ServiceRegistrar (ver quadro4.3) sobrepopondo o metodo lookup e acrescentamos o parametro de localizacao do usuario. Essemetodo e responsavel por selecionar o servidor de impressao mais proximo ao cliente.

Apos a escolha do servidor, o cliente pode finalmente utilizar a impressora atraves do service1Seminars on Software Systems: http://www.ime.usp.br/∼rcastro/seminars/

23

CAPITULO 6. PROPOSTA 24

proxy enviando pelo LS.

6.2.2 Proximos passos

Realizaremos ainda, um estudo mais aprofundado das arquiteturas citadas no capıtulo 5, paraviabilizar a implementacao da aplicacao nesses sistemas. Em paralelo, estamos estudando as duastecnologias de localizacao de UMs, citadas anteriormente. Para isso, obtivemos uma versao dedesenvolvimento do Ekahau Positioning Engine.

No final da implementacao, realizaremos testes praticos utilizando laptops e/ou PDAs conectadosa rede sem fio do IME, disponibilizada pelo projeto SIDAM2.

Assim, nossas proximas etapas sao: implementar a aplicacao em outros sistemas, intensificar oestudo do Ekahau e Radar para realizar a integracao dos mesmos a aplicacao e assim, possibilitara realizacao de testes praticos com o prototipo construıdo. Por ultimo, descreveremos uma analisecomparativa dos protocolos utilizados com base na aplicacao construida.

Esperamos concluir a etapa de desenvolvimento nos meses de janeiro e fevereiro de 2003, emseguida realizaremos a etapa de analise comparativa entre os sistemas para a elaboracao da tese atejunho de 2003 (ver tabela 6.1).

Perıodo Atividade1o semestre/2001 MAC 5741 - Introducao a Algoritmos e Arquiteturas Paralelas

MAC 5747 - Geometria ComputacionalMAC 5744 - Introducao a Computacao Grafica

Definicacao do problema de estudo2o semestre/2001 MAC 5711 - Analise de Algoritmos

MAC 5764 - Topicos em Engenharia de SoftwareMAC 5767 - Introducao ao Processamento de Alto Desempenho

Levantamento bibliografico da area de estudo1o semestre/2002 MAC xxx - Topicos em Ciencia da Computacao

Apresentacao de um seminario: Proposta inicial do projeto2o semestre/2002 Definicao da especificacao do projeto

Inıcio da implementacao1o semestre/2003 Termino da implementacao do projeto

Analise dos resultados obtidosElaboracao da tese

Tabela 6.1: Cronograma de atividades.

2Maiores informacoes: http://www.ime.usp.br/∼sidam/

24

Bibliografia

[1] P. Bahl and V. N. Padmanabhan. Radar: An In-Bulding RF-based User Location andTracking System. Microsoft Research, March 2000. URL: <http://research.microsoft-.com/bahl/MS Projects/projects.html>.

[2] M. Barbeau. Service Discovery Protocols for Ad Hoc Networking. Carleton University Press,November 2000.

[3] M. Barbeau. Mobile, Distributed, and Pervasive computing. Carleton University Press, 2001.

[4] E. Guttman C. Perkins and J. Kempf. Service Templates and Service: Schemes. RFC 2165,June 1999.

[5] E. Guttman. Service Location Protocol: Automatic Discovery of IP Network Services. IEEEInternet Computing, August:71–80, 1999. URL: <http://computer.org/internet/>.

[6] J. Hightower and G. Borriello. Location Systems for Ubiquitous Computing. IEEE Computer,August:57–66, 2001. URL: <http://computer.org/computer/>.

[7] G. Richard III. Service Advertisement and Discovery: Enabling Universal Device Cooperati-on. IEEE Internet Computing, September/October:18–26, 2000. URL: <http://computer-.org/internet/>.

[8] Caldera Systems Inc. An Introduction to SLP. Whitepaper Caldera Systems, Inc., 2001. URL:<http://www.calderasystems.com>.

[9] Ekahau Inc. Ekahau Positioning Engine. Technical report, 2002. URL: <http://www.ekahau-.com>.

[10] Sun Microsystems Inc. Jini Architectural Overview. Technical report, 2001. URL: <http:-//www.sun.com/jini/>.

[11] Sun Microsystems Inc. Jini Network Technology. Technical report, 2001. URL: <http://www-.sun.com/jini>.

[12] E. Guttman J. Veizades, C. Perkins and S. Kaplan. Service Location Protocol. RFC 2615, June1997.

[13] A. Loureiro and G. Mateus. Introducao a Computacao Movel. Universidade Federal de MinasGerais - UFMG, 2000.

[14] S. Hodges M. Addlesee, R. Curwen and A. Hopper. Implementing a Sentient Computing System.IEEE Computer, August:50–56, 2001. URL: <http://computer.org/computer/>.

25

BIBLIOGRAFIA 26

[15] D. McCormack M. Barbeau, E. Hughes and F. Bordeleau. Service Recommendation usingSLP. IEEE International Conference on Telecommunications (ICT), April 2001. URL: <http:-//computer.org/internet/>.

[16] R. E. McGrath. Discovery Protocols for Ubiquitous Computing. University of Illinois Press,March 2000.

[17] V. N. Padmanabhan P. Bahl and A. Balachandran. Enhancements to the Radar User Locationand Tracking System. Technical report, Microsoft Research Technical Report, February 2000.URL: <http://research.microsoft.com/bahl/publications.aspx>.

[18] C. Perkins and E. Guttman. DHCP Options for Service Location Protocol. RFC 2610, June1999.

[19] C. Perkins and E. Guttman. Service Location Protocol, Version 2. RFC 2608, June 1999.

[20] C. E. Perkins. Service Location Protocol for Mobile Users. Sun Microsystems Inc. Press, 2000.

[21] C. Schwingenschlogl and A. Heigl. Development of a Service Discovery Architecture for theBluetooh Radio System. University of Munich Press, 2000.

[22] J. Waldo. Alive and Well: Jini Technology Today. IEEE Computer, June:107–111, 2000. URL:<http://computer.org/computer/>.

[23] R. Want and B. Schilit. Expanding the Horizons of Location-Aware Computing. IEEE Com-puter, August:31–34, 2001. URL: <http://computer.org/computer/>.

[24] W. Liao Y. Tseng, S. Wu and C. ChaoY. Location Awareness in Ad Hoc Wireless MobileNetworks. IEEE Computer, June:46–52, 2001. URL: <http://computer.org/computer/>.

26

Exame de Qualifica¸cão do Mestrado - ime.usp.brlmap/mestrado/quali.pdfExame de Qualifica¸cão...

Documents

Transcript of Exame de Qualifica¸cão do Mestrado - ime.usp.brlmap/mestrado/quali.pdfExame de Qualifica¸cão...