Avalia¸c˜ao

Figura 4.7: Modelo de descoberta de servi¸co Splendor [Zhu, Mutka e Ni 2003].

A comunica¸c˜ao inicial entre clientes, servi¸cos e diret´orios ´e feita atrav´es de endere¸cos multicast, conhecidos antecipadamente por todas as entidades. Os an´uncios e a busca s˜ao feitos utilizando comunica¸c˜ao unicast entre clientes, provedores de servi¸cos, proxies e diret´orios, envolvendo apenas as partes interessadas, o que diminui a possibilidade de congestionamento do meio de comunica¸c˜ao.

Para ilustrar o funcionamento do protocolo, foi explorado um exemplo onde h´a dois m´edicos de um mesmo hospital em um shopping center. Um usu´ario solicita a descoberta de um servi¸co de atendimento m´edico e o protocolo encontra a descri¸c˜ao dos dois m´edi- cos. O protocolo, ao receber uma requisi¸c˜ao de descoberta, escolhe um dos servi¸cos de atendimento e envia sua descri¸c˜ao ao usu´ario. A escolha ´e feita atrav´es da agrega¸c˜ao, que agrupa os dois servi¸cos de atendimento, e da filtragem, que escolhe um dos dois servi¸cos, para enviar ao usu´ario.

Os proxies s˜ao os respons´aveis por gerenciar toda negocia¸c˜ao para registro, autentica- ¸c˜ao, autoriza¸c˜ao e gerenciamento de chaves de criptografia. No exemplo dado, o servi¸co m´ovel do m´edico, o proxy negocia com o cliente e informa os servi¸cos m´oveis de emergˆen- cia dispon´ıveis. Os servi¸cos m´oveis possuem seu registro no proxy durante o tempo que estiverem dispon´ıveis no ambiente coberto por ele.

4.5

Avalia¸c˜ao

As propostas apresentadas neste cap´ıtulo procuram atender `as quest˜oes mais essenciais de um protocolo de descoberta de servi¸co, como dinamismo atrav´es da descoberta espon- tˆanea e configura¸c˜ao autom´atica, sele¸c˜ao com possibilidade de utiliza¸c˜ao de semˆantica, baixa intera¸c˜ao humana, adapta¸c˜ao autom´atica `a disponibilidade m´ovel e interoperabili- dade entre fabricantes e plataformas. Entretanto, se conseguem ser espontˆaneos, n˜ao d˜ao suporte a uma sele¸c˜ao utilizando informa¸c˜ao semˆantica; se tˆem baixa intera¸c˜ao humana, n˜ao conseguem suportar adapta¸c˜ao autom´atica; e a interoperabilidade entre fabricantes e plataformas ´e outro ponto n˜ao muito explorado. Al´em disso, poucos se preocupam com a seguran¸ca de dados e autentica¸c˜ao de usu´arios. Com rela¸c˜ao `a sensibilidade ao contexto

o m´aximo que fazem ´e utilizar a localiza¸c˜ao para identificar o contexto.

Nesta se¸c˜ao ´e feita uma avalia¸c˜ao das propostas apresentadas anteriormente, procu- rando destacar os requisitos principais de um protocolo de descoberta servi¸co seguro e sens´ıvel ao contexto: descri¸c˜ao de servi¸co, suporte de um servi¸co de diret´orio, sele¸c˜ao de servi¸co, seguran¸ca, autentica¸c˜ao e suporte a manipula¸c˜ao de informa¸c˜oes sens´ıveis ao contexto.

Dependendo da configura¸c˜ao adotada, os mecanismos de descoberta que n˜ao utilizam um servi¸co de diret´orio, como JINI, SSDP, SPDP e Splendor podem ficar restritos a uma rede local, ou mesmo a um dom´ınio administrativo. Essa situa¸c˜ao ´e t´ıpica das redes dom´esticas, das redes de pequenos escrit´orios, das redes de sensores, ou mesmo das redes ad hoc. Nessa abordagem, os servi¸cos est˜ao descritos nos pr´oprios provedores e as aplica¸c˜oes utilizam um mecanismo de descoberta para verificar a existˆencia de um servi¸co e acess´a-lo. Os servi¸cos s˜ao anunciados por difus˜ao. Os provedores de servi¸co podem ser vistos como uma esp´ecie de diret´orio e por isso, no ambiente descrito, pode-se dizer que h´a um diret´orio distribu´ıdo, embora n˜ao possa ser chamado de um servi¸co de diret´orio, pois n˜ao h´a uma classifica¸c˜ao, armazenagem das descri¸c˜oes dos servi¸cos, nem m´etodos bem definidos para gerenciamento e consulta dessas descri¸c˜oes.

A arquitetura Salutation se prop˜oe a operar em qualquer ambiente computacional atrav´es dos Transport Managers, que abstraem os detalhes operacionais para os desenvol- vedores de aplica¸c˜ao. Al´em disso, pode operar com ou sem um servi¸co de diret´orio. No caso de n˜ao ser implementada com servi¸co de diret´orio, as entidades de rede tˆem condi¸c˜oes de se localizarem atrav´es de consultas feitas utilizando broadcast. No caso de haver um n´umero muito grande de entidades, esse m´etodo pode causar um tr´afego intenso na rede, podendo degradar todo o ambiente. ´E utilizada uma compara¸c˜ao nominal de tipos de servi¸cos procurados com os existentes para encontrar servi¸cos. Seguran¸ca e autentica¸c˜ao n˜ao s˜ao tratadas no trabalho.

O SLP utiliza uma descri¸c˜ao simples para os servi¸cos, limitada a uma pesquisa do tipo atributo-valor, por isso n˜ao possui um mecanismo de compara¸c˜ao muito eficiente. Pode atuar com ou sem um servi¸co de diret´orio. Utiliza unicast e multicast para descoberta de servi¸co, o que ´e muito importante, pois direciona as mensagens apenas para as entidades interessadas. A seguran¸ca provida ´e m´ınima, pois ´e apenas garantida a integridade das mensagens e s˜ao deixadas de lado outras quest˜oes como confidencialidade e n˜ao-rep´udio. A autentica¸c˜ao das mensagens ´e feita atrav´es da verifica¸c˜ao da assinatura digital da entidade. Um aspecto interessante a ser investigado ´e h´a possibilidade da utiliza¸c˜ao de descri¸c˜oes feitas em XML, RDF, ou OWL para enriquecer a descri¸c˜ao dos servi¸cos, j´a que a resposta do protocolo a uma solicita¸c˜ao de descoberta ´e uma URL.

JINI ´e um protocolo dinˆamico de descoberta de servi¸cos, pois utiliza uma t´ecnica chamada leasing para garantir que todos os servi¸cos registrados na base de dados estejam dispon´ıveis. Quando o tempo limite ´e alcan¸cado, o protocolo remove as informa¸c˜oes do servi¸co da base, inserindo-as novamente apenas no pr´oximo an´uncio. ´E utilizada uma base de dados de servi¸cos, definidos como proxies de objetos, que s˜ao carregados nos clientes e utilizados por estes para acessarem os servi¸cos.

O SSDP utiliza HTTP sobre UDP para descobrir servi¸cos. Tem a limita¸c˜ao de prover descoberta apenas para redes locais. Possui a caracter´ıstica importante de prover maior descri¸c˜ao dos servi¸cos atrav´es de XML. Al´em disso, h´a um campo na mensagem do protocolo onde ´e poss´ıvel inserir uma URL para qualquer informa¸c˜ao mais detalhada, inclusive em outras linguagens como RDF ou OWL.