Descoberta de Serviços em Redes de Computadores

Transcrição

1 Capítulo 3: Descoberta de Serviços em Redes de Computadores 113 Capítulo 3 Descoberta de Serviços em Redes de Computadores Luciana dos S. Lima, Antônio Tadeu A. Gomes, Artur Ziviani e Markus Endler Abstract The paradigm of service discovery is a fundamental element of self-organizing information systems. In this context, a service in a network can be any software or hardware resource that a user wishes to use. Service discovery mechanisms allow for the automatic detection of these entities in computer networks. In this chapter, the basic concepts underlying service discovery and the main protocol proposals found in the literature are presented and discussed. The evaluated proposals span a wide range of network types wired networks, infrastructure wireless networks, and ad hoc wireless networks. The service discovery protocols are evaluated comparatively on the basis of a set of criteria, such as their architecture, techniques for service description, service request and advertisement mechanisms, among others. Resumo O paradigma de descoberta de serviços é um elemento fundamental em sistemas de informação auto-organizáveis. Nesse contexto, um serviço em uma rede pode ser qualquer entidade de software ou hardware que um usuário deseje utilizar. Mecanismos de descoberta de serviços permitem a detecção automática dessas entidades em redes de computadores. Neste minicurso, os conceitos básicos relacionados à descoberta de serviços e as principais propostas de protocolos encontradas na literatura são apresentadas e discutidas. As propostas analisadas abrangem diferentes tipos de redes, como redes cabeadas, redes sem fio infra-estruturadas e redes sem fio ad hoc. Os protocolos de descoberta de serviços são avaliados comparativamente, com base em um conjunto de características, como sua arquitetura, técnicas de descrição de serviço, mecanismos de requisição e anúncio de serviços, entre outros.

2 114 Minicursos: 25º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos 3.1. Introdução Dois aspectos importantes podem ser identificados no processo de expansão contínua dos ambientes computacionais em nossa vida cotidiana. O primeiro aspecto é a proliferação de diferentes periféricos, como impressoras, scanners, projetores e câmeras digitais (para citar alguns dos mais comuns), e a possibilidade de interconexão direta dos mesmos por exemplo, impressoras que permitem a impressão de fotos obtidas diretamente de câmeras digitais. O segundo aspecto é a adoção de tecnologias sem fio, que viabilizam a oferta de computadores e dispositivos móveis, como notebooks, tablets, PDAs e telefones celulares, e permitem simplificar o arranjo físico de interconexão dos equipamentos presentes em um ambiente computacional. Particularmente em PDAs e telefones celulares, à medida que a tecnologia sem fio se popularizou, novas funcionalidades foram sendo acrescentadas a esses dispositivos, aproximando os seus usuários das aplicações utilizadas tradicionalmente em computadores fixos. Isso só foi possível graças ao desenvolvimento de componentes de hardware (chips, processadores) com dimensões cada vez mais reduzidas, permitindo assim a adição de mais recursos a esses dispositivos. Entretanto, essa evolução tecnológica esbarra em algumas restrições relativas à miniaturização desses dispositivos, em particular na sua capacidade de processamento, memória, armazenamento e comunicação, além de limitações típicas da interface desses dispositivos com o usuário, como dimensões de tela e ausência (ou pouca facilidade no uso) de teclado. Adicionalmente, a mobilidade inerente a esses dispositivos acarreta outra restrição, relativa à quantidade de energia disponível para o funcionamento dos dispositivos, quantidade essa que tem relação direta com as dimensões das baterias. Restrições como as descritas acima demandam dos dispositivos móveis a capacidade de comunicação com ou sem fio com serviços providos por outros equipamentos presentes no seu ambiente computacional, tais como armazenamento, visualização de imagens em alta definição e acesso à Internet, por exemplo. Como resultado, o usuário desse ambiente é obrigado a lidar com aspectos referentes ao gerenciamento dessa comunicação. Disso resultam ambientes computacionais altamente intrusivos, que requisitam constantemente a atenção e intervenção dos usuários para o seu ajuste e configuração. É relativamente comum nos dias atuais um usuário ficar frustrado ao lidar com a configuração de tantos equipamentos e serviços diferentes. O cenário exposto acima requer dos ambientes computacionais a capacidade de interoperabilidade casual, ou seja, a capacidade de seus equipamentos interoperarem sem conhecimento prévio do restante do ambiente, o que exige que os equipamentos desse ambiente (bem como os serviços que eles hospedam) possam descobrir uns aos outros sob demanda, atendendo às necessidades dos usuários. Os protocolos de descoberta de serviço foram desenvolvidos com o intuito de minimizar a sobrecarga administrativa dos usuários, aumentando a usabilidade e possibilitando que serviços sejam descobertos, configurados e usados em um ambiente computacional com um mínimo de esforço por parte do usuário [Zhu et al. 2005]. Em outras palavras, os protocolos de descoberta têm, como principal objetivo de projeto, a automatização do mecanismo de descoberta. Por automatização entende-se a organização e entrega de informação sobre os serviços disponíveis em um ambiente computacional sem intervenção humana. Por descoberta entende-se a capacidade de encontrar um

3 Capítulo 3: Descoberta de Serviços em Redes de Computadores 115 provedor de um determinado serviço se esse serviço existe no ambiente com as propriedades descritas na sua requisição [Marin-Perianu et al. 2005] Objetivos Descoberta de serviços é um tópico que sempre despertou muito interesse de pesquisa e desenvolvimento nas áreas de sistemas distribuídos e redes de computadores, originando propostas nos mais diversos cenários, tanto para redes cabeadas quanto redes sem fio [McGrath 2000, Richard 2000, Marin-Perianu et al. 2005, Cho & Lee 2005, Zhu et al. 2005, Edwards 2006, Mian et al. 2006]. O propósito deste capítulo é apresentar e avaliar os diversos mecanismos de descoberta de serviço propostos na literatura, incluindo padrões de mercado e resultados de projetos de pesquisa. Alguns dos protocolos apresentados neste capítulo, como Jini [Sun 1999], DEAPspace [Nidd 2001] e UPnP [UPnP 2000], oferecem suporte à descoberta de serviços para ambientes mais estáveis, como as redes domésticas e empresariais [Zhu et al. 2005]. Outros protocolos apresentados, como Konark [Lee et al. 2003], GSD [Chakraborty et al. 2006] e P2PDP [Lima et al. 2005], estão relacionados a ambientes computacionais espontâneos, e constituem-se no foco principal deste capítulo. O termo ambiente espontâneo é aqui utilizado para referenciar a maneira como grupos de periféricos, dispositivos e computadores são formados, especialmente os que têm capacidade de comunicação sem fio. Nos ambientes espontâneos essa formação se dá de uma maneira dinâmica: os membros de um grupo apresentam um tempo de permanência variável no grupo, o que impacta diretamente na disponibilidade de serviços. Além disso, consideramos ambientes espontâneos como sendo potencialmente compostos por vários usuários que atuam de forma colaborativa. Em um cenário extremo, esses usuários podem inclusive não apresentar vínculos pessoais ou institucionais em comum que permitam o estabelecimento prévio de relações de confiança (com fins de segurança). Nesses ambientes, os usuários colaboram entre si de forma consciente, permitindo que dispositivos com menos recursos possam se beneficiar do ambiente do qual participam, motivados não somente pelas suas próprias necessidades, mas pela noção de bem comum. 1 Serviços de resgate a vítimas de catástrofes naturais (terremotos, maremotos, entre outros) ou provocadas (atentados terroristas), serviços de segurança pessoal, aplicações associadas ao lazer, são todos exemplos de ambientes computacionais originados de forma espontânea Conceitos Básicos O mecanismo de descoberta de serviços é um elemento fundamental em ambientes computacionais auto-organizáveis, tendo surgido na área de sistemas de informação [Marin-Perianu et al. 2005]. Nesse contexto, um serviço pode ser qualquer entidade de software ou hardware que um usuário deseje utilizar. A partir do momento em que a localização do serviço solicitado é obtida tipicamente o endereço de rede do provedor do serviço (no caso das redes IP, endereço IP, protocolo de transporte e porta) o usuário pode ter acesso ao mesmo para sua utilização. Serviços podem ser hospedados 1 Do inglês, common good. Termo aqui utilizado inspirado no contexto do livro Smart Mobs: The Next Social Revolution [Rheingold 2003] significando bem comum, bem público.

4 116 Minicursos: 25º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos em periféricos, dispositivos, computadores e outros equipamentos. Muitas vezes esses equipamentos podem oferecer mais de um serviço; por exemplo, uma impressora pode oferecer simultaneamente serviços de impressão e fax. Os protocolos de descoberta de serviços definem entidades que atuam em cada etapa do processo de descoberta. Pelo menos duas entidades básicas são definidas: o cliente ou usuário do serviço e o servidor ou provedor do serviço. A entidade cliente está interessada em descobrir e utilizar um serviço. O servidor é a entidade que oferece o serviço. Os protocolos podem ainda utilizar repositórios de serviços para facilitar o mapeamento entre as requisições, os serviços e a localização dos provedores. É comum encontrar ainda uma quarta entidade nos protocolos de descoberta: o serviço de diretório ou negociador (broker). Essa entidade hospeda (parcial ou inteiramente) as informações de descrição de serviço bem como a sua localização. É possível encontrar na literatura referências a mecanismos de descoberta de serviços e descoberta de recursos, embora o primeiro termo seja certamente o mais usado dentro da temática proposta para o presente capítulo. De qualquer modo, julgamos necessário definir com mais precisão os conceitos de recursos e serviços, de acordo com o significado desejado para este capítulo. De acordo com [Colouris et al. 2005], um recurso é algo que pode ser concretizado pela alocação de uma quantidade em função da necessidade de utilização. Nesse contexto, recurso significa algo de suprimento limitado que as entidades de software possam utilizar mediante reserva prévia. A reserva de um recurso pode ser feita, por exemplo, quando uma aplicação aloca memória para a execução de alguma operação; nesse caso, o que está sendo reservado é uma instância do recurso a quantidade de memória. Devem existir entidades que gerenciem a utilização dos recursos para evitar a sua degradação. Um serviço deve ser compreendido, no contexto de descoberta, como algo disponibilizado por um provedor. Por exemplo, um servidor de banco de dados provê um serviço de armazenamento e recuperação de informações. Um serviço somente pode ser utilizado através da sua instanciação. Uma aplicação reserva recursos para a sua execução e utiliza as instâncias desses recursos quando ela é iniciada, tornado-se um serviço. A partir desse momento esse serviço pode ser utilizado. Existem aplicações cuja finalidade é disponibilizar o compartilhamento de recursos, possibilitando a sua utilização por outros em um ambiente distribuído; como acontece, por exemplo, quando uma impressora é acessível por meio de um serviço de impressão Organização do Capítulo O restante deste capítulo está organizado da seguinte forma. A próxima seção apresenta uma classificação para os protocolos de descoberta de serviços em redes de computadores. A Seção 3.3 descreve os principais protocolos de descoberta de serviços propostos na literatura para redes fixas. Na Seção 3.4, os protocolos propostos para a descoberta de serviços em redes ad hoc de salto único são apresentados. A Seção 3.5 merece um destaque especial por ser dedicada aos protocolos de descoberta projetados para as redes ad hoc de saltos múltiplos, ambiente que tem despertado recentemente um crescente interesse no desenvolvimento de pesquisas nessa área. A Seção 3.6 promove uma análise comparativa dos protocolos apresentados nas Seções 3.3, 3.4 e 3.5,

5 Capítulo 3: Descoberta de Serviços em Redes de Computadores 117 apontando diferentes perspectivas e tendências atuais de pesquisa relacionadas à área de descoberta de serviços em redes de computadores Principais Aspectos Relacionados aos Protocolos de Descoberta de Serviços Os protocolos de descoberta de serviços existentes geralmente empregam terminologias específicas com o propósito de ressaltar as características positivas dos mesmos, identificadas como aspectos singulares da proposta em relação ao estado da arte. A utilização de uma terminologia comum e de um mecanismo de classificação auxilia a análise das vantagens e desvantagens das diferentes abordagens, revelando-se um mecanismo de comparação eficiente. A seguir, será apresentada uma classificação obtida a partir da avaliação de diferentes protocolos de descoberta encontrados na literatura, bem como da convergência das classificações propostas para esses trabalhos por diferentes autores [McGrath 2000; Marin-Perianu et al. 2005; Cho & Lee 2005; Zhu et al. 2005; Edwards 2006; Mian et al. 2006]. Essa classificação foi elaborada levandose em consideração um conjunto de critérios que se constituem em uma base de comparação, a saber: a arquitetura de descoberta de serviços; o escopo da descoberta de serviços; as técnicas de descrição de serviços; o mecanismo de consulta às informações de serviços; os mecanismos de requisição e anúncio de serviços; o armazenamento das informações de serviços; os mecanismos de seleção e invocação de serviços; os mecanismos para oferecer suporte à mobilidade e segurança Arquiteturas de Descoberta de Serviços De um modo geral, uma arquitetura especifica a organização de qualquer sistema e o modo como os seus principais componentes estão conectados entre si. As arquiteturas de descoberta de serviços são definidas, principalmente, pela utilização, ou não, de um diretório, como ilustrado na Figura 1. Um diretório é uma entidade que gerencia as informações dos serviços disponíveis na rede. Os protocolos de descoberta podem adotar uma abordagem centralizada, baseada em diretórios, os quais são responsáveis pelo processamento de anúncios e consultas em nome de todos os dispositivos da rede, ou distribuída, onde cada dispositivo é responsável por manter as informações sobre os serviços que disponibiliza ou conhece. As arquiteturas centralizadas podem utilizar um ou mais diretórios para tratar o registro das informações de serviços e as solicitações dos clientes, subdividindo-se 2 em estruturas hierárquicas e planas. No modelo hierárquico, os diretórios estão 2 Alguns autores consideram que essa subdivisão caracteriza uma arquitetura híbrida, denominada distribuída estruturada [Marin-Perianu et al. 2005].

6 118 Minicursos: 25º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos organizados em uma estrutura em árvore, similar à estrutura adotada pelo DNS; já no modelo plano, os diretórios trocam informações entre si sobre os serviços que cada um gerencia. Figura 1 Classificação das arquiteturas de um protocolo de descoberta. As arquiteturas distribuídas baseiam-se na interação direta entre clientes e provedores de serviços, não existindo a sobrecarga de administração do diretório, como no caso das arquiteturas distribuídas. Entretanto, nas arquiteturas distribuídas, as entidades produzem um maior volume de tráfego de mensagens de controle e o processamento das requisições é transferido dos elementos centrais (diretórios) para os clientes do sistema. Alguns protocolos oferecem suporte tanto à arquitetura centralizada quanto à distribuída. Em redes sem fio ad hoc, não há infra-estrutura fixa: a topologia da rede é alterada freqüentemente devido à instabilidade causada pela mobilidade dos dispositivos e por falhas no enlace, o que inviabiliza a utilização de elementos centralizados para efetuar o gerenciamento das informações dos serviços da rede Escopo da Descoberta de Serviços O escopo da descoberta corresponde ao conjunto de serviços que podem ser descobertos por um dado cliente. A determinação do escopo de um protocolo de descoberta permite o controle dos mecanismos que são utilizados para obter informações sobre os serviços na rede. O conceito de escopo possibilita que os serviços disponíveis em uma rede possam ser observados sob diferentes perspectivas. Por exemplo, em sua requisição de serviço, um cliente pode especificar a necessidade por uma impressora laser colorida, localizada no mesmo andar em que fica a sua sala de trabalho; respostas provenientes de dispositivos em outros prédios ou até mesmo em outros andares não interessam ao cliente, constituindo-se em informações desnecessárias. Como representado na Figura 2, a definição do escopo da descoberta pode ser feita com base na topologia da rede, nas permissões de acesso embutidas nos diferentes papéis de usuário em um domínio administrativo e nas informações de contexto de alto nível tais como as informações temporais (como data, hora e fuso horário), espaciais (como latitude, longitude e posição relativa) e àquelas relacionadas às atividades desempenhadas pelos usuários dos dispositivos no seu dia-a-dia.

7 Capítulo 3: Descoberta de Serviços em Redes de Computadores 119 Figura 2 Escopo dos mecanismos de descoberta de serviços. Em protocolos de descoberta distribuídos, o escopo é geralmente definido em função da topologia da rede e o alcance do mecanismo de descoberta é determinado, em parte, pelas regras de roteamento em vigência. Nesses protocolos de descoberta, a requisição de serviço pode ser encaminhada apenas aos dispositivos que constituem a rede local do dispositivo que a originou, ou alcançar dispositivos em outras redes físicas, a vários saltos de distância de onde a requisição foi originada. No primeiro caso, as requisições de serviço são encaminhadas através de multicast ou broadcast local. No segundo caso, o encaminhamento das requisições de serviço pode ser feito utilizando-se mecanismos de transmissão como broadcast limitado, grupos multicast ou encaminhamento seletivo. Em protocolos de descoberta centralizados, baseados na estrutura de diretórios, o escopo pode ser expandido interconectando-se diretórios em diferentes domínios administrativos com relações de confiança previamente estabelecidas. Nesses sistemas, pode-se empregar políticas de controle de acesso aos serviços com base na autenticação dos papéis dos usuários dos dispositivos. Nesses protocolos, o escopo da descoberta pode ser definido ainda em função da informação de contexto a localização física do serviço pode ser definida como um atributo de consulta em uma requisição de serviço Técnicas de Descrição de Serviços Descrição de serviço é uma abstração das características e facilidades inerentes a um serviço. Essa abstração torna-se necessária em diferentes etapas do processo de descoberta: Quando um serviço, na arquitetura centralizada, é registrado pelo seu provedor junto ao diretório; Quando um provedor, na arquitetura distribuída, divulga na rede, através de mensagens de anúncios, a disponibilidade dos serviços que oferece; e Quando o serviço é requisitado por outros dispositivos ou mesmo por outros serviços. Em um protocolo de descoberta, os clientes procuram por um serviço específico consultando as descrições de serviços anunciadas pelos provedores ou enviando uma requisição à rede contendo a descrição do serviço que desejam. Caso um serviço não seja descrito de forma apropriada ou, ainda, que as entidades envolvidas no processo de descoberta não compartilhem de uma semântica comum, que favoreça a negociação entre as partes, o serviço pode permanecer completamente desconhecido para os demais dispositivos da rede, o que inviabiliza a sua descoberta e utilização. Por esse motivo, os protocolos de descoberta geralmente incorporam também diretivas para a descrição dos serviços, podendo mesmo utilizar linguagens de propósito específico. Como podemos

8 120 Minicursos: 25º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos observar na Figura 3, existem duas abordagens empregadas com maior freqüência: pares atributo-valor e linguagens de descrição. Figura 3 Classificação da descrição de serviços em protocolos de descoberta. Pares atributo-valor são os mais comumente utilizados na descrição de serviços em protocolos de descoberta. Nessa abordagem, o serviço é representado através de um nome e de um conjunto de atributos. Esse formato de descrição dificulta a filtragem, nos provedores de serviço e diretórios, dos serviços que melhor atendem a uma requisição específica, já que a filtragem é feita pela comparação direta de um único campo, nesse caso, entre pares atributo-valor. Em uma rede com um grande número de serviços, esse esquema pode causar uma implosão de mensagens de resposta na rede [Thompson & Midkiff 2005], quando uma consulta é realizada a um serviço comum, como, por exemplo, uma consulta a um serviço de impressão em um prédio-sede de uma grande empresa. Caso o cliente não seja suficientemente específico ao definir a sua requisição, utilizando um conjunto de pares atributo-valor que restrinjam a sua busca, ele receberá um grande número de respostas desnecessárias, já que a maioria dos serviços de impressão não devem estar acessíveis ao usuário a impressora pode estar geograficamente distante ou ainda estar desligada ou mesmo ser desejáveis uma impressora preto e branco não atende às necessidades de um usuário que deseja imprimir um material colorido. Em adição à utilização de pares atributo-valor, classificada como uma abordagem básica, alguns protocolos adotam a utilização de templates e de elementos pré-definidos, o que caracteriza uma abordagem de descrição intermediária. Os templates definem uma representação padrão para os serviços, com os atributos sendo especificados em um documento legível, tanto para humanos quanto para máquinas, o que garante expressividade à descrição de serviços bem conhecidos e a possibilidade de expansão, à medida que forem surgindo novos serviços. Complementando a utilização de templates, alguns protocolos oferecem um conjunto comum de elementos pré-definidos, que estipulam o nome e os atributos dos serviços que são mais freqüentemente utilizados. Essa prática oferece uma representação única para serviços bem conhecidos, o que elimina a ambigüidade quando as entidades cliente, provedor de serviço e diretório interagem, garantindo que todos estão se referindo ao mesmo serviço. Linguagens de descrição permitem a representação de serviços através de convenções sintáticas, normalmente expressas por meio de esquemas XML e, em um

9 Capítulo 3: Descoberta de Serviços em Redes de Computadores 121 caso particular desse tipo de descrição, por meio do uso de ontologias. 3 Para representar a adoção de ontologias nos protocolos de descoberta, são usadas tipicamente linguagens como DAML [DAML 2001], OWL [W3C 2004] e extensões às mesmas. A utilização desse formato de descrição proporciona, através dos metadados herdados dos esquemas XML, que um maior número de informações seja incorporado à descrição do serviço, que passa a ter uma representação semântica. Graças aos mecanismos de restrições e propriedades adicionados a essas descrições, as consultas ganham poder de inferência, o que torna a filtragem das informações de serviços mais rica, oferecendo, conseqüentemente, resultados mais precisos e reduzindo o número de respostas incompatíveis com uma dada requisição [Thompson & Midkiff 2005]. Em alguns protocolos que utilizam essa abordagem os serviços são organizados através de uma estrutura hierárquica, em árvore, onde, conforme exemplificado na Figura 4, o nó-raiz oferece o nível mais genérico ( serviço ) e os nós-folhas o nível mais específico (InkJet e LaserJet) de representação do serviço. Figura 4 Estrutura hierárquica de representação dos serviços. Em alguns protocolos de descoberta, a implementação da descrição de serviços é realizada através de módulos adaptáveis, o que garante uma independência da técnica de descrição utilizada. Nesses protocolos, qualquer método de descrição pode ser adotado Gerenciamento da Informação de Serviço O método de consulta utilizado em um protocolo de descoberta de serviços pode ser entendido como um processo de busca atrelado a um casamento (matching) entre as requisições de descoberta (demandas) e as descrições de serviços locais e remotos (ofertas), estas últimas divulgadas através de anúncios ou registradas em diretórios. O algoritmo de matching utilizado pelo mecanismo de consulta representa uma função que aceita, como entrada, a demanda e um conjunto de descrições de ofertas, provendo, como resultado, o subconjunto das ofertas que satisfazem a demanda especificada. Segundo [Gonzalez-Castillo et al. 2001], pode-se alcançar uma melhoria do processo quando o algoritmo retorna uma lista ordenada das k melhores ofertas, para cada demanda. Uma vez que o processo de matching é baseado em comparações, linguagens que permitam, de forma natural, especificar tipos, restrições e relações entre conceitos agregam valor semântico ao protocolo de descoberta de serviços, como ocorre com as 3 Em ciência da computação, uma ontologia é um modelo de dados que representa um domínio específico. Ontologias permitem que se façam inferências sobre os objetos em um dado domínio e sobre as relações entre eles.

10 122 Minicursos: 25º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos linguagens de descrição baseadas em XML [W3C 2000; DAML 2001; W3C 2001; Chakraborty et al. 2001; W3C 2004]. Os algoritmos de matching são independentes da arquitetura dos protocolos de descoberta, mas apresentam uma forte dependência em relação ao mecanismo de descrição de serviços utilizado (ver Subseção 3.2.3). O algoritmo de matching pode empregar diferentes funções de comparação, conforme representado na Figura 5: uma função simples, baseada na comparação de atributos (influenciada pela descrição baseada em pares atributo-valor), uma função semântica (influenciada pela uso de linguagens de descrição) ou uma função dependente de linguagem de programação. Figura 5 Algoritmos de matching para consulta das informações de serviços. Algoritmos de matching baseados na comparação sintática de atributos podem ser implementados através da comparação de um único atributo, geralmente o identificador ou o tipo do serviço, ou de vários atributos. Algoritmos de matching baseados na função de comparação semântica beneficiam-se dos mecanismos de consulta embutidos nas linguagens de descrição, provenientes da utilização de padrões relacionados ao XML, os quais oferecem mecanismos para se representar a forma como os recursos se relacionam, incluindo propriedades como domínio e cardinalidade, e restrições de integridade, o que garante consultas mais poderosas. A representação semântica dos serviços consiste de um conjunto de informações que abrangem, mas não se limitam, a descrição de suas capacidades, funcionalidades, portabilidade e requisitos do sistema como largura de banda, sistema operacional e processador. Uma função de matching semântico introduz a possibilidade de se obter resultados aproximados em resposta a uma requisição de serviço. Nesse caso, dependendo dos requisitos definidos na consulta, o resultado da função de matching pode ser satisfatório mesmo se uma, ou mais, características do serviço não sejam satisfeitas integralmente. Por exemplo, se uma requisição especifica um serviço que possa ser executado em sistemas baseados em um processador de uma determinada família (por exemplo, Intel Pentium) e uma instância desse serviço, compatível com sistemas baseados nessa família, for descoberta, um resultado aproximado é encontrado. Por fim, existem abordagens que atrelam a função de comparação à linguagem de programação utilizada. Este é o caso de Jini (vide Subseção 3.3.1), que apresenta um forte acoplamento à linguagem de programação Java. Como resultado do processamento da requisição de descoberta pelo algoritmo de matching, são obtidas informações sobre o serviço requisitado, as quais permitirão a sua invocação e utilização. Essas informações são encaminhadas ao dispositivo que originou a requisição, encapsuladas em uma mensagem de resposta à solicitação do serviço. Em

11 Capítulo 3: Descoberta de Serviços em Redes de Computadores 123 um protocolo de descoberta, uma mensagem de resposta geralmente contém a descrição e a localização do serviço requisitado. Em alguns casos, a mensagem de resposta contém outras informações, como o mecanismo de comunicação que deve ser utilizado para invocar o serviço, bem como as operações e os parâmetros associados ao serviço Mecanismos de Requisição e Anúncio de Serviços O mecanismo de descoberta pode ser utilizado para localizar o dispositivo que hospeda o diretório responsável por armazenar as informações sobre os serviços da rede ou para localizar diretamente os dispositivos provedores de serviços. A abordagem adotada no processo de descoberta depende da arquitetura do protocolo de descoberta e de como os serviços são registrados. Basicamente, existem duas formas para se consultar informações sobre os serviços disponíveis na rede (Figura 6): a descoberta passiva, onde os provedores anunciam periodicamente os seus serviços para toda a rede, e a descoberta ativa, onde o cliente envia mensagens de descoberta para provedores ou diretórios com o intuito de obter informações sobre um serviço específico ou sobre todos os serviços disponíveis. Essas abordagens também são conhecidas, na literatura, como proativa e reativa, respectivamente, em uma alusão à classificação utilizada com os protocolos de roteamento planos para redes sem fio ad hoc de saltos múltiplos (vide Subseção 3.5). Grande parte dos protocolos de descoberta implementa ambas as abordagens. Figura 6 Mecanismos de descoberta de serviços. Na abordagem de descoberta passiva, as partes interessadas escutam um canal de mensagens. Quando um serviço anuncia as suas características e a sua disponibilidade, todas as partes envolvidas recebem essa informação. Na arquitetura centralizada, os provedores registram as informações sobre os serviços que disponibilizam junto aos diretórios e esses fazem anúncios periódicos divulgando os serviços que gerenciam. Na arquitetura distribuída, os clientes mantêm atualizado o seu conhecimento sobre os serviços disponíveis através dos anúncios de serviços que são difundidos, periodicamente, na rede, pelos provedores de serviços. Um dispositivo pode emitir anúncios contendo apenas informações sobre os serviços que disponibiliza, ou incluir também informações sobre os serviços oferecidos por outros dispositivos do sistema a respeito dos quais tenha conhecimento. Geralmente, as informações sobre os serviços remotos se restringem àquelas referentes aos dispositivos conectados diretamente ao emissor do anúncio. Entretanto, existem abordagens que defendem a replicação das informações sobre os serviços da rede em todos os dispositivos, criando uma visão global do sistema em cada dispositivo. Em muitas propostas relacionadas a redes ad hoc de saltos múltiplos, é definido um parâmetro configurável denominado diâmetro do anúncio, responsável por delimitar o alcance dos anúncios em termos do número de saltos que eles irão percorrer.

12 124 Minicursos: 25º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos Na abordagem de descoberta ativa, o cliente envia mensagens de descoberta para obter informações sobre os serviços ou diretórios da rede. Na arquitetura centralizada, inicialmente, os clientes usam multicast ou broadcast para descobrir o diretório que gerencia as informações de serviços. Feito isso, as requisições passam a ser enviadas em unicast ao diretório que responde, também em unicast, informando as características e a localização do serviço. Posteriormente, o cliente se conecta diretamente ao provedor para ter acesso ao serviço. Na arquitetura distribuída, as mensagens de descoberta são transmitidas por difusão diretamente a todos os dispositivos na rede, através de multicast ou broadcast. Quando o encaminhamento de pacotes em saltos múltiplos é tratado, o alcance da mensagem (número de saltos pelos quais ela irá trafegar) é geralmente definido, assim como acontece com os anúncios de serviço na descoberta ativa, por um parâmetro configurável, denominado diâmetro da requisição. Ao receber uma requisição, cada nó a processa. Se a descrição corresponder a um serviço que ele disponibiliza, uma resposta é gerada e enviada ao cliente. Caso contrário, a requisição é encaminhada aos demais dispositivos da rede, respeitando o alcance máximo permitido para a mensagem. Alguns protocolos implementam mecanismos diferenciados de encaminhamento de requisições. Nessas propostas, as requisições são difundidas, de forma seletiva, na direção dos nós que têm a maior probabilidade de oferecer o serviço, o que é feito com base em critérios, tais como o grupo ao qual o serviço pertence [Chakraborty et al. 2002; Chakraborty et al. 2006], as políticas definidas pelo usuário [Ratsimor et al. 2004] ou o potencial do dispositivo em prover o serviço [Lenders et al. 2005] Armazenamento das Informações de Serviço Informações de serviço são divulgadas pelo provedor do serviço (ou diretório) através de mecanismos de anúncio ou em resposta a mensagens de requisição. A informação de um serviço é utilizada para descrever, identificar e selecionar o serviço na rede. A informação pode incluir o nome do serviço, o seu identificador, o endereço do provedor do serviço, o protocolo que o cliente e o provedor devem utilizar para invocar o serviço, o período no qual a informação é válida, entre outros itens. As informações sobre os serviços devem ser armazenadas em repositórios, de modo que os demais dispositivos possam recuperá-las e contactar o provedor de um serviço particular. De acordo com o modo como esses repositórios são organizados, eles são classificados como centralizados ou distribuídos (Figura 7). Na primeira abordagem, as informações sobre todos os serviços disponíveis na rede são armazenadas em diretórios. Na segunda abordagem, todos os dispositivos da rede possuem o seu próprio repositório local, onde armazenam informações sobre os serviços que disponibilizam, assim como sobre os serviços divulgados na rede. A abordagem distribuída pode ainda ser subdividida em cooperativa, quando os nós mantêm informações parciais sobre os serviços da rede, que se complementam, e não cooperativa, quando os dispositivos armazenam as informações sobre todos os serviços da rede, mantendo uma visão global do sistema. As propostas que adotam a abordagem cooperativa costumam restringir o armazenamento das informações de serviços em função de critérios pré-definidos, limitando o tamanho do repositório local de informações de serviços, em função de parâmetros configuráveis. Um exemplo dessa prática é a utilização do número máximo de saltos na rede que os anúncios devem percorrer ou da quantidade disponível de

13 Capítulo 3: Descoberta de Serviços em Redes de Computadores 125 recursos em cada dispositivo como critérios para limitar o tamanho do repositório. Uma variação desse procedimento é a restrição do armazenamento de informações de serviço a um conjunto bem definido de dispositivos. Figura 7 Armazenamento das informações de serviços. O gerenciamento das informações de serviços inclui aspectos como: onde armazenar a informação, o período de tempo durante o qual a informação é válida, o tamanho do repositório, a política de remoção de registros, o escopo da visão dos serviços (somente local ou global), entre outros. Além disso, existem aspectos indiretos que influenciam a escolha do mecanismo de gerenciamento, como a distância, em número de saltos, que anúncios e requisições devem percorrer, caracterizado como o diâmetro de conhecimento. Em redes sem fio ad hoc, o mecanismo de armazenamento pode ser completamente descentralizado ou mesmo inexistente, o que se deve a alta mobilidade dos dispositivos, não justificando o registro desse tipo de informação. Por outro lado, em redes fixas ou redes sem fio infra-estruturadas, é natural a adoção de um mecanismo de armazenamento centralizado, com a adoção de uma estrutura de diretório, embora essa política crie um ponto único de falha, problema que é amenizado pela utilização de mecanismos de replicação de dados. Independente da abordagem adotada, centralizada ou distribuída, o mecanismo utilizado para determinar a validade das informações de um serviço, o que recai na disponibilidade do serviço, define se essas informações estão armazenadas como soft state ou hard state (Figura 8). Quando as informações sobre o serviço são mantidas na forma soft state abordagem comumente empregada em armazenamento distribuído, a sua validade é especificada na mensagem de anúncio e precisa ser atualizada, periodicamente, pelo seu provedor, antes que expire, o que tornaria o serviço inalcançável. Clientes ou diretórios podem se cadastrar junto ao provedor do serviço para receber notificações sobre mudanças em características específicas do serviço, como a sua disponibilidade. Quando as informações sobre o serviço são mantidas como hard state, elas só são removidas se o provedor do serviço solicitar, explicitamente, a sua remoção ou for constatada a indisponibilidade do serviço, ao se tentar utilizá-lo. Em algumas abordagens, clientes ou diretórios podem fazer consultas periódicas diretamente ao provedor do serviço para verificar se as suas informações permanecem atualizadas. Figura 8 Estado das informações de serviços.

14 126 Minicursos: 25º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos Para se definir o estado em que as informações de serviço serão armazenadas, é necessário o ajuste de dois parâmetros: nível de tolerância a falhas e utilização de largura de banda. O soft state oferece uma maior tolerância a falhas, mas, em contrapartida, provoca um maior consumo de largura de banda, devido a troca periódica de anúncios de serviços na rede. O hard state, por sua vez, consome menos largura de banda, entretanto, é menos tolerante a falhas Métodos de Seleção e Invocação de Serviços Embora o escopo do mecanismo de descoberta restrinja o número de respostas recebidas pelo cliente, o resultado de uma requisição para um determinado serviço pode conter não só informações de um, mas de vários provedores do mesmo serviço. Neste caso, o ideal é que o melhor provedor seja selecionado, sem que haja a necessidade de interferência do usuário. Como ilustrado na Figura 9, os protocolos de descoberta podem oferecer opções de seleção manual, com a intervenção direta do usuário da aplicação, ou automática, através de um algoritmo implementado no lado cliente, selecionando a melhor opção em função das características da aplicação. Nos protocolos de descoberta que utilizam repositórios centralizados, o algoritmo de seleção pode ser implementado no próprio diretório, que se encarrega de fazer a seleção do melhor serviço, em nome do cliente, de acordo com critérios especificados na requisição. Quando a abordagem de seleção automática é implementada, deve-se considerar as métricas que irão definir qual é a melhor oferta. Uma métrica possível é a menor distância, em número de saltos, entre o dispositivo que originou a requisição e o provedor do serviço. Podem ser usadas ainda outras métricas específicas, associadas ao serviço, às condições do provedor como, por exemplo, a sua carga de processamento, que está diretamente relacionada ao número de requisições sendo atendidas ou mesmo às condições da rede. Figura 9 Critérios de seleção de serviços. Embora seja um tópico à parte, muitos protocolos de descoberta de serviços tratam também a questão da invocação do serviço. Depois que a seleção é processada, o protocolo de descoberta pode oferecer mecanismos para que o cliente utilize o serviço, a partir das informações contidas na resposta selecionada. Como é possível observar na Figura 10, os protocolos de descoberta dão suporte à invocação de serviços em três níveis diferentes, que podem ser oferecidos conjuntamente. No primeiro nível, o cliente obtém a localização do serviço, através do mecanismo de descoberta, e se conecta diretamente ao provedor que o oferece através do seu endereço de rede; as aplicações que utilizam o protocolo de descoberta são responsáveis por definir o mecanismo de comunicação entre clientes e servidores e o conjunto de operações disponíveis no serviço. Em um segundo nível, o protocolo de descoberta especifica os mecanismos de comunicação entre os clientes e os serviços. Nessa categoria, enquadram-se os protocolos que utilizam RPC e suas variações. Em um terceiro nível, os protocolos de

15 Capítulo 3: Descoberta de Serviços em Redes de Computadores 127 descoberta definem operações específicas para um domínio de aplicação, em adição à localização do serviço e ao mecanismo de comunicação. Figura 10 Mecanismos de invocação de serviços Provisão de Suporte à Mobilidade Em uma rede sem fio, os dispositivos se movimentam constantemente, o que torna obsoletas as rotas através das quais eles eram alcançáveis. Nesse tipo de cenário, o problema de se manter, mediante a presença da mobilidade, as informações sobre os serviços atualizadas é contornado através da descoberta ativa. Nesse caso, pode-se realizar uma atualização implícita das informações sobre os serviços. São realizadas consultas aos serviços disponíveis na rede, sob demanda, através do envio de mensagens de requisição a endereços de multicast ou broadcast. O suporte à mobilidade implica que a informação sobre os serviços disponíveis na rede, quer seja armazenada nos diretórios (centralizada) ou em cada dispositivo da rede (distribuída), deva ser atualizada em função das modificações na topologia da rede, provocadas pela mobilidade dos dispositivos. Se, em um dado grupo, um dispositivo armazena informações sobre os serviços dos demais dispositivos, espera-se que ele mantenha informações corretas, na medida do possível. Se o dispositivo altera a sua posição em relação ao grupo, ou se algum membro do grupo se desloca, as informações de serviços devem ser atualizadas o mais rapidamente possível. Somente dessa forma, pode-se esperar, com uma certa probabilidade, que um protocolo de descoberta consiga descobrir serviços em tempo hábil. Caso as informações mantidas por um dispositivo sobre os serviços da rede sejam obsoletas, há uma grande chance desse dispositivo responder a uma requisição de serviço com informações desatualizadas. Ao receber a resposta a sua solicitação, o cliente tentará acessar o serviço e, só então, irá detectar a sua indisponibilidade, pois o provedor do serviço pode ter se deslocado ou se tornado inalcançável. Existem dois métodos principais para solucionar esse problema (Figura 11): proativos e reativos. No método proativo, os dispositivos mantêm uma visão atualizada das informações sobre os serviços disponíveis na rede com a troca periódica de mensagens de anúncio contendo dados mais recentes sobre o serviço. No método reativo, a informação é atualizada em razão da ocorrência de eventos na rede, como, por exemplo, a indisponibilidade de uma rota para um provedor ou a detecção de mudanças de estado informadas pelo próprio serviço. Nesse método, a disponibilidade do serviço pode ser consultada pelos clientes, junto a provedores (ou diretórios), de forma direta, sob demanda, ou através de notificações. Figura 11 Métodos de provisão de suporte à mobilidade.

16 128 Minicursos: 25º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos Em alguns protocolos de descoberta para redes móveis, o tráfego referente ao mecanismo de descoberta mensagens de anúncios, requisições e respostas de serviços é interceptado e processado, pelos nós intermediários, de modo que se obtenham informações adicionais sobre serviços. Outra prática comum nessas redes é a manutenção das informações sobre os serviços na forma soft state, como foi mencionado na Subseção 3.2.6: o período de validade da informação é especificado nas mensagens de anúncio, o que caracteriza o método proativo de provisão de suporte à mobilidade. Antes que o período de validade associado ao serviço expire, o seu provedor deve encaminhar um novo anúncio para revalidar as informações sobre o serviço. Alguns protocolos de descoberta que implementam o método proativo usam a limitação do número de saltos da propagação dos anúncios, para restringir o alcance da transmissão das informações sobre os serviços da rede. Essa abordagem tem como intuito facilitar a manutenção das informações sobre os serviços, limitando a sua divulgação aos dispositivos mais próximos geograficamente, que constituem uma vizinhança física, aumentando, com isso, as chances de se localizar um serviço dentro da vizinhança do dispositivo Mecanismos de Segurança A questão da segurança apresenta vários desafios no projeto de protocolos de descoberta, especialmente em ambientes espontâneos. A necessidade de se atender a requisitos de usabilidade, como configuração automática, implementação leve e redução do tráfego de mensagens de controle na rede, implica na adoção de esquemas de segurança muito simples. Uma grande parte dos protocolos de descoberta de serviços encontrados na literatura não tratam a questão da segurança ou simplesmente embutem em suas propostas soluções tradicionais, implementadas nas tecnologias sobre as quais elas se baseiam, como autenticação de usuários por meio de identificação e senha, autorização através de listas de controle de acesso e criptografia da comunicação. Além de restringir a usabilidade, em ambientes espontâneos, a implementação de mecanismos de segurança tradicionais adiciona também um alto custo computacional ao projeto de um protocolo de descoberta. Entretanto, essa medida pode se mostrar necessária em ambientes colaborativos onde usuários que não possuem uma relação de confiança préestabelecida se comunicam livremente, constituindo comunidades virtuais. A Subseção comenta alguns dos desafios de pesquisa relacionados à área de segurança em protocolos de descoberta de serviços Protocolos de Descoberta em Redes Fixas Durante muito tempo, os protocolos de descoberta de serviços seguiram o modelo clássico de aplicações cliente-servidor. Nessa visão, servidores centralizados atuam como diretórios, armazenando um índice global dos serviços disponíveis na rede e gerenciando todo o processo de descoberta. Devido a essas características, esses protocolos são mais adequados a redes fixas. Dentre os protocolos que fazem parte desse modelo, destacam-se Jini [Sun 1999] da Sun, Salutation [Salutation 1999] da IBM e SLP (Service Location Protocol) [Guttman 1999] do IETF.

17 Capítulo 3: Descoberta de Serviços em Redes de Computadores Jini Jini [Sun 1999] é um sistema de descoberta e anúncio de serviços desenvolvido pela Sun Microsystems, com base na tecnologia Java. O Jini requer que cada dispositivo participante de uma instância do sistema (uma community) execute uma máquina virtual Java (JVM) ou, caso esse dispositivo não tenha capacidade computacional para tal (uma impressora, por exemplo), que ele esteja associado a um dispositivo que execute a JVM em seu favor. A restrição quanto ao uso de Java traz, como contrapartida, maior flexibilidade na definição do serviço. Por exemplo, um serviço implementado completamente como software (um algoritmo de renderização específico, por exemplo) pode, após sua descoberta, ser trazido do provedor e executado inteiramente no cliente. A arquitetura de descoberta no Jini é centralizada em servidores de diretório chamados de LookUp Servers LUSs. Nesse sistema não é prevista a utilização de estruturas de múltiplos diretórios geridas pelos próprios LUSs, isto é, clientes são diretamente responsáveis pela localização de LUSs específicos. O início de uma interação entre clientes, LUS e serviços começa quando o cliente/serviço transmite na rede uma mensagem de pré-descoberta via multicast ou broadcast, a fim de localizar um certo LUS. Alternativamente, o LUS pode se anunciar na rede transmitindo, também via multicast ou broadcast, uma mensagem de anúncio. Esse esquema de localização dos LUSs limita o escopo de descoberta do Jini a redes locais ou departamentais. Após a identificação do LUS, a comunicação entre cliente/serviço e o LUS ocorre via unicast. O sistema Jini foi projetado pensando-se em sua aplicação de modo independente de protocolo de transporte. Na prática, a implantação de Jini tem sido primordialmente em redes IP, portanto, os protocolos de transporte utilizados na comunicação entre clientes, serviços e LUSs são basicamente o TCP e o UDP. O mecanismo de descoberta utilizado pelo Jini é ativo, com clientes Jini enviando requisições aos LUSs. Porém, clientes também podem se cadastrar junto a um serviço de notificação no LUS para receber passivamente informações sobre a disponibilidade de um ou mais serviços de interesse. No sistema Jini, serviços podem ser descritos em uma requisição como atributos de consulta representados por meio de objetos Java. Desse modo, atributos de consulta podem ter comportamento associado, o que é um diferencial em relação aos esquemas de representação comumente adotados, que se baseiam puramente em pares atributovalor ou linguagens de descrição (vide Subseção 3.2.3). Esses objetos implementam a classe Java ServiceTemplate, ilustrada na Figura 12. Figura 12 Estrutura da classe ServiceTemplate utilizada nas operações de matching por Jini.

18 130 Minicursos: 25º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos Uma descrição de serviço, registrada no LUS, inclui a identificação do serviço, os atributos que descrevem esse serviço e um objeto Java chamado remote control. Esse objeto pode implementar completamente o serviço (como um algoritmo) ou atuar como proxy para o mesmo, provendo operações que permitam o seu acesso na rede (como uma impressora). O algoritmo de matching do Jini executa no LUS, sendo responsável pela comparação de objetos da classe ServiceTemplate, transportados nas requisições, com as descrições de serviço registradas nesse servidor. O matching pode retornar como resultado da consulta um ou mais objetos remote control nas mensagens de resposta. A seleção dos serviços de interesse, dentre aqueles retornados na resposta, é feita manualmente pelo usuário ou pela aplicação que utiliza o sistema. O mecanismo de invocação de serviços, acionado após a fase de descoberta, também é definido pelo Jini; é utilizado o Java RMI (Remote Method Invocation) para estabelecer a comunicação entre clientes e serviços. O uso de RMI permite não somente a troca de dados entre clientes e serviços, como também a troca de objetos, o que propicia, por exemplo, a migração de serviços entre dispositivos. Além disso, o sistema Jini oferece também serviços de notificação de eventos e serviços transacionais que facilitam a tarefa dos programadores no que se refere ao desenvolvimento de aplicações distribuídas. O Jini mantém informações sobre os serviços na forma soft state, usando o conceito de leases; um lease determina um tempo de validade para o registro de um serviço no LUS e, portanto, o provedor desse serviço deve continuamente renovar o lease para manter seu serviço acessível para clientes Jini. O Jini depende do modelo de segurança embutido na plataforma Java, a qual provê ferramentas como certificação digital e criptografia. Além disso, a plataforma Java implementa mecanismos de autorização através de listas de controle de acesso, que permitem limitar as atividades exercidas pelos serviços, em especial por aqueles serviços passíveis de migração entre dispositivos Salutation Salutation [Salutation 1999] é uma arquitetura para descoberta de serviços desenvolvida por um consórcio envolvendo membros das comunidades de pesquisa e industrial. O objetivo desse consórcio é construir uma arquitetura aberta, livre de royalties e independente de protocolos de transporte específicos. A arquitetura de descoberta do Salutation é centralizada em servidores de diretório chamados de Salutation Managers SLMs. Nessa arquitetura é possível implementar a coordenação de múltiplos SLMs em um mesmo sistema de descoberta, configurando uma estrutura plana ou hierárquica. A configuração de uma estrutura plana no Salutation é definida, durante a inicialização de um SLM, por meio da localização de outros SLMs no sistema, utilizando para isso multicast ou configuração estática. A configuração de uma estrutura hierárquica é baseada na definição de um SLM centralizado. A arquitetura Salutation permite ainda a descentralização parcial ou completa dos diretórios por meio da configuração de SLM locais junto aos dispositivos dos clientes e aos equipamentos hospedeiros dos serviços. A arquitetura Salutation utiliza pares atributo-valor na descrição de serviços (especificados segundo o padrão ASN.1 [ISO 1990]), sendo esses pares agrupados em

19 Capítulo 3: Descoberta de Serviços em Redes de Computadores 131 estruturas denominadas de unidades funcionais. Essas unidades funcionais formam um conjunto de parâmetros pré-definidos que descrevem serviços freqüentemente utilizados; a arquitetura, contudo, permite a definição de novas unidades funcionais por parte de usuários e fabricantes de dispositivos. Uma coleção de unidades funcionais define um registro de serviço. Assim, por exemplo, um serviço de fax pode ser definido a partir das unidades funcionais {Print}, {Scan} e {Fax Data Send}, cada uma delas com atributos e valores específicos. O algoritmo de matching empregado na arquitetura Salutation é baseado fundamentalmente na comparação de atributos (e seus valores) presentes nessas unidades funcionais. O mecanismo de descoberta definido na arquitetura Salutation é ativo, com clientes fazendo requisições a um SLM específico seja ele um SLM local ou próximo aos dispositivos dos clientes por meio de chamadas remotas (via RPC) às operações slmsearchcapability() e slmquerycapability() nesses servidores. A operação slmsearchcapability() permite ao cliente determinar se há registros de unidades funcionais específicas em algum SLM do sistema nesse caso, o retorno dessa operação é uma lista de SLMs que atendem à consulta. A operação slmquerycapability() é usada para obter detalhes de uma unidade funcional registrada em um SLM específico, identificado por meio de um parâmetro da operação. Desse modo, a seleção dos serviços de interesse, dentre aqueles retornados por slmsearchcapability(), é feita manualmente pelo usuário ou pela aplicação que utiliza o sistema. Durante o processo de descoberta descrito acima, os vários SLMs envolvidos na coordenação podem trocar informações entre si, também por meio de RPC, para responder à requisição. A troca de informações é necessária, em primeiro lugar, pois os serviços se registram e só são conhecidos a princípio em um SLM uma alternativa possível de implementação, prevista na arquitetura, é o cache de resultados de consultas anteriores nos outros SLMs do sistema. Em segundo lugar, os clientes só se associam tipicamente a um único SLM e enviam somente para esse servidor as suas requisições. As informações de serviço registradas nos SLMs são armazenadas como hard state: SLMs oferecem uma dupla de operações slmregistercapabilities() e slmunregistercapabilities() para o registro e de-registro de serviços. Como a arquitetura Salutation é baseada em requisições (abordagem reativa), é oferecido aos clientes a possibilidade de requisitar aos SLMs, aos quais estão associados a verificação periódica, junto aos outros SLMs, acerca da disponibilidade de serviços específicos. A arquitetura Salutation trata não só da descoberta, mas também da invocação de serviços. 4 Os SLM são centrais nesse processo, gerenciando a comunicação entre clientes e serviços. Uma das características principais da arquitetura Salutation é a independência em relação aos protocolos de transporte usados na comunicação entre clientes, serviços e SLMs durante a fase de invocação. Essa independência é provida por uma entidade à parte na arquitetura, denominada Transport Manager. Há atualmente 4 Há uma versão simplificada da arquitetura Salutation, denominada Salutation-Lite, desenvolvida especificamente para dispositivos com recursos limitados. Essa versão foca primordialmente na descoberta de serviços.

20 132 Minicursos: 25º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos implementações dessa entidade para redes IP, IrDA (infravermelho) e Bluetooth. Durante a fase de invocação de serviços, a comunicação entre clientes e serviços pode ocorrer de diferentes formas, dependendo do modo de operação assumido pelos SLMs no sistema. A arquitetura Salutation define três modos de operação (chamados nessa arquitetura de personalities) para SLMs: Modo nativo: SLMs participam somente da descoberta. A transferência de dados entre clientes e serviços é feita diretamente, utilizando algum protocolo de transporte nativo em comum, sem envolvimento dos SLMs; Modo emulado: SLMs transmitem mensagens entre clientes e serviços encapsulando seus protocolos de transporte em um protocolo específico da arquitetura Salutation (Salutation Manager Protocol). Esse modo de operação permite que clientes e serviços que não compartilhem um mesmo protocolo de transporte em comum possam se comunicar; um SLM atua nesse caso como ponte entre clientes e serviços, não tendo ciência do significado dos dados transferidos entre esses elementos; Modo Salutation: A invocação de serviços é completamente intermediada pelos SLMs, usando o protocolo específico da arquitetura Salutation. A arquitetura Salutation oferece somente alguns poucos mecanismos básicos de segurança, como autenticação de usuários por meio de identificação e senha SLP O SLP (Service Location Protocol) [Guttman 1999] é um protocolo de descoberta e anúncio de serviços definido pelo IETF. Ao contrário de Jini e Salutation, que possuem em graus diferentes independência com relação aos protocolos de transporte, o SLP foi projetado especificamente para redes IP. A arquitetura de descoberta do SLP pode ser tanto centralizada quanto distribuída. Na abordagem distribuída há duas entidades principais, representando respectivamente clientes e serviços: User Agents (UAs) e Service Agents (SAs). Nessa abordagem, UAs enviam requisições por multicast diretamente aos SAs, que enviam respostas de volta aos UAs por unicast. SAs também podem anunciar por multicast seus serviços diretamente aos UAs. Na abordagem centralizada surge uma terceira entidade que atua como servidor de diretório: o Directory Agent (DA). Nessa abordagem UAs enviam consultas aos DAs, que, com base nas informações neles armazenadas sobre serviços disponíveis, enviam respostas de volta aos UAs. As informações armazenadas nos DAs são obtidas por meio do anúncio de SAs acerca de seus serviços. Em ambas as abordagens, centralizada ou distribuída, os anúncios de SAs são disponibilizados em soft state. Portanto, esses agentes precisam periodicamente renovar as informações de serviço armazenadas pelos UAs ou DAs. Um ou mais DAs podem estar presentes no mesmo sistema, e a comunicação entre eles e os outros agentes (UAs e SAs) pode ser via multicast ou unicast. No caso de comunicação unicast, os endereços IP dos DAs são obtidos por meio de configuração estática ou DHCP. DAs podem ainda, assim como SAs, se anunciar periodicamente na rede. Note que, pelo fato dos SAs poderem se anunciar simultaneamente para vários DAs, o SLP oferece um mecanismo implícito de replicação de diretórios, sem que seja

21 Capítulo 3: Descoberta de Serviços em Redes de Computadores 133 necessária a manutenção de algum tipo de sincronização entre os DAs, como ocorre em sistemas que adotam a arquitetura Salutation. Serviços são anunciados pelos SAs por meio de URLs que contêm as informações necessárias para o uso desse serviço, bem como conjuntos de atributos descritivos (chamados templates) para esses serviços. UAs usam essas URLs para se comunicar diretamente com o serviço. Por exemplo, um serviço de impressão pode ser descrito no SLP como Ao contrário do Jini e do Salutation, o SLP não provê mecanismos adicionais de invocação de serviços. Pressupõe-se no SLP que as URLs possuem informação suficiente sobre a forma como os serviços podem ser acessíveis a partir dos clientes. Embora descrições de serviço no SLP sejam baseadas em templates de serviço (pares atributo-valor), o algoritmo de matching desse protocolo permite consultas bem mais complexas que o Salutation, que é baseado somente em comparações diretas de valores de atributos. No SLP, consultas podem ser descritas em termos de predicados lógicos sobre os templates de serviço, predicados esses formados a partir de operadores relacionais, de pertinência em conjuntos e de comparação de substrings. Por exemplo, a solicitação de um serviço de impressão colorida ou em escalas de cinza no SLP pode ser descrita por A seleção dos serviços de interesse, dentre aqueles retornados pelo algoritmo de matching, é feita manualmente pelo usuário ou pela aplicação que utiliza o sistema. O modelo de segurança do SLP resume-se a prevenir a propagação errônea (intencional ou não) da localização de serviços. SAs podem associar assinaturas digitais a anúncios de serviços e UAs podem verificar a identidade desses serviços a partir dessas assinaturas. Assinaturas digitais também podem ser requisitadas quando DAs anunciam sua presença na rede, permitindo a UAs e SAs evitar falsos DAs UPnP UPnP (Universal Plug and Play) [UPnP 2000] é uma arquitetura proposta inicialmente pela Microsoft e que é mantida atualmente por um fórum do qual participam centenas de fabricantes. A idéia da arquitetura UPnP é estender o modelo PnP (Plug and Play) originalmente concebido para descoberta automática de dispositivos periféricos ligados a um mesmo equipamento para anúncio, descoberta e controle de dispositivos em rede. Essa arquitetura, assim como no caso do protocolo SLP, é baseada na pilha de protocolos TCP/IP, utilizando intensivamente tecnologias para a Web, como HTTP, SOAP (Simple Object Access Protocol) e XML. A arquitetura de descoberta do UPnP é baseada em três entidades principais: dispositivos, serviços e pontos de controle. Um dispositivo UPnP é um contêiner de serviços UPnP e outros dispositivos UPnP aninhados (nested). Por exemplo, uma impressora (dispositivo UPnP) pode consistir em um serviço de impressão e um dispositivo scanner aninhado, que por sua vez oferece um serviço de fotocópia. Um..

22 134 Minicursos: 25º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos serviço UPnP expõe ações que podem ser aplicadas ao mesmo durante sua invocação por meio de um servidor de controle residente no dispositivo que hospeda o serviço, bem como uma tabela que armazena um conjunto de variáveis de estado do serviço (tabela de estados). A tabela de estados do serviço UPnP pode ser monitorada por um servidor de eventos (também residente no dispositivo que hospeda o serviço), que tem como função publicar a outras entidades interessadas a modificação de variáveis de estado desse serviço. Finalmente, um ponto de controle UPnP atua, em parte, como um servidor de diretório, tendo como tarefa descobrir e controlar os dispositivos UPnP presentes na rede PDAs e dispositivos de controle remoto são exemplos de equipamentos típicos que podem hospedar pontos de controle. No caso de um dispositivo não compatível com a arquitetura UPnP, uma ponte UPnP é usada para mapear os protocolos definidos por essa arquitetura nos protocolos entendidos nativamente pelo dispositivo. Um sistema construído sobre a arquitetura UPnP pode trabalhar com ou sem pontos de controle, configurando desse modo estruturas centralizadas ou distribuídas, respectivamente. 5 A comunicação entre as entidades dessa arquitetura, durante a fase de descoberta, é efetuada por intermédio do protocolo SSDP (Simple Service Discovery Protocol). Mensagens SSDP são encapsuladas em mensagens HTTP, podendo ser transmitidas via unicast ou multicast através do protocolo de transporte UDP. 6 Dispositivos que queiram se ligar a um sistema UPnP enviam mensagens SSDP de anúncio (ssdp:alive) via multicast, notificando assim pontos de controle e outros dispositivos UPnP na rede. Quando novos pontos de controle se ligam a um sistema UPnP, essas entidades enviam pela rede mensagens SSDP de descoberta (ssdp:discover), também via multicast. Um dispositivo UPnP que receba uma dessas mensagens responde via unicast ao ponto de controle requisitante. O formato de descrição de serviços na arquitetura UPnP é totalmente baseado em XML. Contudo, o uso de XML na arquitetura UPnP é centrado na invocação de serviços, e não na descoberta dos mesmos; isso se deve provavelmente ao fato dessa arquitetura basear-se predominantemente em anúncios de serviço (abordagem passiva). Um anúncio de serviço por parte de um dispositivo UPnP transporta uma URL que aponta para um arquivo XML na rede. Esse arquivo descreve as características do dispositivo, incluindo informações de fabricante nome de modelo, número de série, uma lista de serviços e dispositivos aninhados nesse dispositivo, e URLs que apontam para os servidores de controle e de eventos presentes no mesmo. Esses servidores implementam objetos SOAP. No caso de um servidor de controle, as ações que podem ser aplicadas durante a invocação do serviço associado são implementadas como métodos SOAP nesse servidor de controle. Alguns dispositivos UPnP podem inserir uma terceira URL em seus anúncios de serviços, chamada de URL de apresentação. Em contraste com as URLs anteriores, que apontam para objetos SOAP representando 5 A arquitetura UPnP é comumente referenciada na literatura como sendo peer-to-peer, mas isso dependeria de todos os dispositivos UPnP implementarem internamente um ponto de controle próprio, o que não costuma ocorrer na prática. 6 Essas configurações de protocolo são referidas na literatura como HTTPU (HTTP sobre UDP unicast) e HTTPMU (HTTP sobre UDP multicast).

23 Capítulo 3: Descoberta de Serviços em Redes de Computadores 135 servidores de controle e de eventos, uma URL de apresentação aponta tipicamente para uma página Web diretamente acessível pelo usuário final. Se um dispositivo UPnP disponibiliza uma URL de apresentação, um usuário final pode recuperá-la, carregar a página em um navegador Web e, dependendo das funcionalidades disponíveis na página, permitir ao usuário controlar o dispositivo ou simplesmente visualizar o seu estado. O nível de controle associado a cada serviço depende de funcionalidades específicas da página de apresentação e de restrições implementadas no próprio dispositivo. Na arquitetura UPnP, as informações relativas a um serviço têm prazo de validade associado; dispositivos UPnP e pontos de controle podem se inscrever junto ao servidor de eventos do serviço para obter informações atualizadas sobre alterações na disponibilidade desse serviço. Além disso, quando um dispositivo deixa de participar da rede, voluntariamente, ele deve enviar, através de multicast, mensagens SSDP de notificação de indisponibilidade para cada serviço que ele tenha anunciado e cuja validade ainda não tenha expirado. No que concerne à segurança, a arquitetura UPnP oferece mecanismos de autenticação de usuários, além de suporte à criptografia das informações transmitidas entre dispositivos UPnP durante a fase de invocação, por meio do uso de SOAP sobre SSL (Secure Socket Layer) Protocolos para Redes Ad hoc de Salto Único Existem alguns protocolos, já consolidados, desenvolvidos especificamente para oferecer suporte às redes sem fio ad hoc de salto único, dentre os quais se destacam o Bluetooth SDP [Bluetooth 2001] e o DEAPSpace [Nidd 2001] Bluetooth SDP O padrão Bluetooth [Bluetooth 2001] define a especificação técnica para a comunicação entre dispositivos portáteis através de enlace de rádio sem fio de curto alcance, correspondendo ao padrão da indústria para as PANs (Personal Area Networks). Um de seus protocolos mais importantes, o protocolo de descoberta de serviços (Service Discovery Protocol SDP), fornece um mecanismo para a descoberta de serviços e de seus atributos. O mecanismo de descoberta do Bluetooth baseia-se em uma arquitetura cliente-servidor distribuída, não utilizando um diretório central para armazenar as informações sobre os serviços da rede. A Figura 13 exemplifica alguns cenários de uso típicos associados ao Bluetooth. No Bluetooth, devido ao alcance de transmissão restrito (aproximadamente 10 metros), o escopo é limitado à proximidade física dos dispositivos. Em [Nordbotten et al. 2004], foram desenvolvidas extensões ao Bluetooth SDP, aumentando o seu escopo para redes Bluetooth de saltos múltiplos, denominadas scatternets. 7 Um servidor SDP mantém um registro para cada serviço que ele disponibiliza, como hard state, consistindo de uma lista de atributos mapeada em pares chave-valor, 7 Uma scatternet é formada por um grupo de piconets, independentes e não sincronizáveis, com sobreposição de áreas de cobertura.

24 136 Minicursos: 25º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos que representam aspectos, como a classe a que o serviço pertence, seu nome, um identificador único do serviço (Universally Unique Identifier UUID), além da informação referente ao mecanismo de comunicação que deve ser utilizado para invocar o serviço. Cada servidor SDP registra somente as informações dos serviços que ele disponibiliza informações de serviços remotos não são armazenadas o que, de certo modo, caracteriza um mecanismo de armazenamento distribuído cooperativo. Figura 13 Cenários de uso do Bluetooth: em movimento, momentos de lazer, em casa e no trabalho (figura disponível em O Bluetooth SDP implementa um mecanismo de descoberta ativa, onde o cliente envia mensagens de descoberta para provedores com o intuito de obter informações sobre um serviço específico ou sobre todos os serviços disponíveis. Como no Bluetooth há uma distinção entre a descoberta de dispositivos e a descoberta de serviços, um cliente SDP deve primeiro fazer uma consulta dos servidores SDP ativos e só então realizar consultas sobre os serviços disponíveis em um dado servidor. Para dar início ao processo de descoberta, um cliente SDP envia uma mensagem através de broadcast buscando dispositivos Bluetooth que estejam no estado de descoberta. O uso de broadcast, no Bluetooth, é restrito ao mecanismo de descoberta de dispositivos. Dispositivos Bluetooth podem estar em um estado de não descoberta por motivos de segurança ou por resolução do módulo de gerenciamento de energia. Os dispositivos que estiverem no estado de descoberta, respondem a mensagem, enviando o seu endereço de dispositivo único (o SDP não é baseado no endereçamento IP). Depois que o cliente obtém esses endereços, ele pode estabelecer canais de comunicação peer-to-peer com os dispositivos, de modo a interagir com os mesmos, através do SDP, para descobrir suas funcionalidades [Edwards 2006]. O SDP não oferece a opção de seleção automática de serviços. Caso a consulta a um serviço ou aos seus atributos retorne mais de uma resposta, a seleção da melhor resposta irá requerer a intervenção direta do usuário da aplicação. O protocolo SDP oferece suporte a um mecanismo básico de invocação de serviços fornecendo apenas a localização do serviço. Como o SDP não inclui funções para acessar os serviços, se um cliente ou uma aplicação associada ao cliente decide

25 Capítulo 3: Descoberta de Serviços em Redes de Computadores 137 utilizar um serviço, é preciso estabelecer uma conexão, junto ao provedor, para invocálo. Assim, as aplicações que utilizam o protocolo de descoberta são responsáveis por definir o mecanismo de comunicação entre clientes e servidores e o conjunto de operações disponíveis no serviço. Como a descoberta é feita em função do modelo requisição-resposta, não há manutenção das informações de serviços, o que caracteriza uma atualização implícita. No projeto do Bluetooth SDP, são implementados mecanismos opcionais de criptografia da comunicação no nível de enlace DEAPSpace DEAPSpace [Nidd 2001] é um framework projetado com base nos conceitos de computação ubíqüa e ciente do contexto (context-aware) que provê, aos dispositivos móveis, a capacidade de detectar a presença de dispositivos em sua vizinhança, podendo compartilhar informações sobre configurações e serviços. O protocolo DEAPspace foi desenvolvido pelo núcleo de pesquisa da IBM, com APIs implementadas nas linguagens C e Java, porém não há registros de utilização comercial do protocolo. O protocolo implementa uma arquitetura distribuída com os dispositivos portáteis se comunicando de forma peer-to-peer, sem fazer uso da entidade diretório. O escopo do mecanismo de descoberta está associado à topologia da rede no caso as redes sem fio ad hoc de salto único, sendo restrito a transmissão em difusão por broadcast local. DEAPspace trata do problema de descoberta dinâmica de serviços utilizando apenas o mecanismo de descoberta passiva, através do envio periódico de anúncios de serviços. O protocolo apresenta uma boa adaptação a mudanças na rede, reduzindo o tempo de aprendizagem dos serviços disponíveis na mesma. Cada dispositivo mantém uma visão de todos os serviços presentes na rede, que é armazenada localmente, e, periodicamente, divulga a sua visão global (world view) a lista completa das entradas na sua base de dados de serviço aos seus vizinhos, através de broadcast. Esse comportamento caracteriza uma abordagem de armazenamento das informações de serviço distribuída não-cooperativa (vide Subseção 3.2.6). As transmissões periódicas de anúncios de serviços são agendadas de um modo proativo: 8 elas ocorrem em janelas de tempo associadas a um único dispositivo, ou seja, no período compreendido em uma janela, um único anúncio da visão global pode ser transmitido. Um anúncio pode ser suprimido quando sua visão global do sistema for idêntica a de outro anúncio previamente transmitido por um vizinho, diminuindo o número de mensagens transmitidas no meio sem fio. Os serviços são associados a um tempo de validade (soft state) e ao endereço do dispositivo que os disponibiliza. Antes da propagação de um anúncio, um dispositivo pode renovar a validade dos serviços que ele hospeda. Além disso, se um dispositivo percebe que o tempo de validade de um serviço que ele disponibiliza está perto de expirar, ele pode antecipar o envio de seu anúncio. Esse envio antecipado pode ocorrer também caso o dispositivo perceba que um serviço qualquer não consta na visão global divulgada pelos seus vizinhos. No caso de um serviço hospedado em outro dispositivo, o dispositivo anunciante pode atualizar o tempo de validade desse serviço, 8 A abordagem adotada foi inspirada nos protocolos de roteamento proativos para redes ad hoc.

26 138 Minicursos: 25º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos decrementando desse tempo o período decorrido desde o último anúncio desse serviço. Isso permite que dispositivos recém-ingressados na rede possam atualizar corretamente sua visão global do sistema. Os serviços são descritos através de pares atributo-valor, usando um formato hierárquico ad hoc que segue o padrão ASN.1 (vide forma geral na Figura 14). Todos os tipos de dados são alinhados a byte, para garantir que a sua codificação, com exceção dos booleanos, ocupe somente o espaço estritamente necessário. Essa preocupação se justifica devido ao tamanho das mensagens de anúncio, que, conforme o conhecimento das informações de serviço vai convergindo, tende a crescer consideravelmente, já que cada anúncio contém informações sobre todos os serviços disponíveis na rede. A seleção de serviços é manual, dado que cada dispositivo consulta localmente as informações sobre os serviços disponíveis na rede e escolhe então aquela que mais se adequa às suas necessidades; o protocolo não oferece suporte à invocação dos serviços. Aspectos relacionados às questões de segurança não são tratadas pelo DEAPspace. Figura 14 Forma geral de descrição de pares atributo-valor no DEAPspace [Hermann et al. 2001] Protocolos para Redes Ad hoc de Saltos Múltiplos As abordagens apresentadas nas subseções 3.3 e 3.4 não atendem às necessidades originadas por ambientes espontâneos de larga escala, que necessitam de um mecanismo completamente descentralizado, onde cada dispositivo deve se responsabilizar pelo gerenciamento de seus serviços de forma totalmente autônoma. Esses ambientes, de uma forma geral, são associados à formação de grupos de colaboração temporários (por exemplo, em situações de resgate em grandes áreas) ou ao estabelecimento de redes de sensores (por exemplo, em regiões inóspitas e vastas, como florestas densas), adequando-se a situações onde não existe uma infra-estrutura de comunicação ou a infra-estrutura existente não está disponível. Um dos aspectos complicadores nesses ambientes é a possibilidade de formação de redes sem fio ad hoc de saltos múltiplos (MANETs). Uma MANET consiste em um grupo de dispositivos portáteis, que se autoconfiguram para viabilizar a comunicação além do seu alcance de transmissão individual, pelo roteamento de pacotes, através de nós intermediários. A pesquisa na área de descoberta de serviços em MANETs de saltos múltiplos é relativamente nova, ainda não existindo um padrão consolidado que possa ser utilizado pela indústria. O principal motivo para a falta de maturidade dos protótipos produzidos, deve-se à mobilidade irrestrita dos dispositivos, os quais podem entrar e sair, espontaneamente, do sistema. Nesse cenário, tanto a demanda quanto a disponibilidade de serviços e recursos podem apresentar uma variabilidade sem par, em comparação aos cenários de redes fixas e redes sem fio ad hoc de salto único. Contudo, algumas características desejáveis para protocolos de descoberta em MANETs podem ser

27 Capítulo 3: Descoberta de Serviços em Redes de Computadores 139 apontadas de antemão. Primeiramente, a divulgação dos serviços deve ser realizada, preferencialmente, sob demanda, através de consultas à vizinhança, evitando que o enlace seja inundado com mensagens de divulgação periódica de informações de serviços, cujo tempo de validade é bastante instável, devido à instabilidade da própria topologia da rede. Nesse modelo, quando um dispositivo realiza uma requisição, os seus vizinhos o auxiliam a difundir o pedido e a receber a(s) resposta(s). Nessa etapa, os dispositivos podem armazenar, como soft state, as informações de serviço contidas nas mensagens de resposta que são encaminhadas, por seu intermédio, aos dispositivos que originaram as requisições. Em segundo lugar, os algoritmos de matching devem ser feitos no nível semântico, e não somente sintático, como ocorre nos protocolos de descoberta apresentados até o momento neste capítulo. Isto porque, em ambientes espontâneos, os provedores de serviço são autônomos, apresentando heterogeneidade nos dispositivos, enlaces de rede e, principalmente, na representação das interfaces associadas aos serviços. Se o mecanismo de matching se basear exclusivamente na sintaxe das interfaces, serão detectadas, muito freqüentemente, falhas no processo devido à existência de diferentes implementações para um mesmo serviço. Vários trabalhos vêm sendo desenvolvidos com o objetivo de oferecer uma solução para esse problema [W3C 2000; Chakraborty et al. 2001; DAML-S 2001; DAML 2001; W3C 2001; W3C 2004], sendo que a maioria se baseia no conceito de ontologias. Esses trabalhos propõem o desenvolvimento de linguagens específicas para a descrição de serviços, capazes de expressar requisições e facilitar o processo de descoberta, atuando no nível semântico, o que garante uma maior expressividade com uma maior precisão. Nesta subseção, são descritas algumas das principais propostas de protocolos de descoberta de serviços para MANETs: GSD [Chakraborty et al. 2002; Chakraborty et al. 2006], Allia [Ratsimor et al. 2002; Ratsimor et al. 2004], Konark Gossip [Helal et al. 2003; Lee et al. 2003], a arquitetura cross-layer proposta em [Varshavsky et al. 2005], FTA [Lenders et al. 2005], ORION [Klemm et al. 2003] e P2PDP [Lima et al. 2005] GSD GSD (Group-based Service Discovery) [Chakraborty et al. 2002; Chakraborty et al. 2006] é uma arquitetura de descoberta de serviços distribuída para ambientes computacionais pervasivos, como ilustrado na Figura 15. A visão de serviço abrange qualquer componente de software ou recurso de hardware em um dispositivo móvel acessível aos demais dispositivos. Nessa abordagem, o escopo da descoberta é definido em função da topologia de rede; o alcance das requisições de descoberta é definido pelo mecanismo de encaminhamento seletivo baseado em grupos de serviços, utilizando transmissão por broadcast. A descrição de serviços na arquitetura GSD é feita utilizando-se uma extensão à ontologia descrita pelo framework DReggie 9 [Chakraborty et al. 2001]. Essa abordagem de descrição permite a definição de regras semânticas que especificam como informações de recursos e serviços se relacionam, incluindo domínio, cardinalidade e 9 DReggie é um framework que utiliza a expressividade de linguagens de descrição de ontologias como DAML [DAML-S 2001] e OWL [W3C 2004] para descrever e recuperar informações de serviços no contexto das aplicações de comércio eletrônico, implementando um mecanismo de matching baseado na informação semântica extraída da descrição dos serviços.

28 140 Minicursos: 25º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos propriedades como transitividade, inversão, união, disjunção e simetria. Os serviços são representados pela classe genérica Service, distinguida, funcionalmente, nas subclasses Hardware e Software. Qualquer recurso ou serviço é descrito em termos de classes e propriedades. Figura 15 Ambientes pervasivos em GSD [Chakraborty et al. 2005]. No protocolo GSD, os nós efetuam anúncios periódicos (parâmetro ADV_TIME_INTERVAL) aos seus vizinhos, anúncios esses restritos a um número de saltos configurável (parâmetro ADV_DIAMETER). Ao receber uma mensagem de anúncio, as informações referentes aos serviços são extraídas e armazenadas localmente como soft state, até que a sua validade expire (parâmetro LIFETIME), quando elas são removidas do repositório de serviços do dispositivo. Esse comportamento caracteriza uma abordagem de armazenamento das informações de serviço distribuída cooperativa. As mensagens de anúncio de serviços carregam, de carona, informações sobre os grupos de serviços anunciados na vizinhança do nó. As informações sobre grupos de serviço viabilizam o mecanismo de matching aproximado, oferecendo resultados aproximados a uma consulta. Por exemplo, se a requisição especifica uma impressora InkJet, o mecanismo de matching faz uma consulta considerando o grupo ao qual o serviço pertence (Printer). Dessa forma, é possível descobrir uma impressora LaserJet presente na vizinhança; a resposta a essa requisição trará informações sobre os dois serviços, impressora InkJet e impressora LaserJet. Quando um dispositivo deseja utilizar um serviço, ele consulta as informações de serviços armazenadas localmente. Caso não exista referência ao serviço em questão, o dispositivo gera uma mensagem de requisição e a encaminha, adotando uma abordagem seletiva, orientada aos grupos de serviços presentes na sua vizinhança. A Figura 16 ilustra, de modo simplificado, a dinâmica do mecanismo de roteamento inteligente de requisições de serviços para uma MANET. A figura mostra uma seqüência de nós interconectados, onde os círculos tracejados delimitam a vizinhança dos nós. O dispositivo N 1 corresponde ao nó que originou a requisição e o dispositivo N 6 corresponde ao provedor do serviço requisitado (S 1 ). Quando a requisição {S 1 (G 1 )} é recebida pelos nós N 2 e N 3, eles verificam, nas suas bases de informações de serviços,

29 Capítulo 3: Descoberta de Serviços em Redes de Computadores 141 as entradas associadas ao grupo G 1 na sua vizinhança. Como o nó N 2 não possui nenhuma entrada associada ao grupo G 1, ele descarta a requisição. O nó N 3 encontra uma entrada para o grupo G 1 associada ao nó N 4 ; a requisição é, então, seletivamente, encaminhada a esse nó. O procedimento descrito se repete em todos os outros nós, até que a requisição alcance o nó N 6, onde é descoberta uma entrada direta para o serviço requisitado (S1). Quando o protocolo GSD falha na identificação do conjunto de nós para efetuar o encaminhamento seletivo, a requisição é, então, transmitida através de broadcast. Figura 16 Mecanismo de encaminhamento seletivo de requisições em GSD. No protocolo GSD, a atualização das informações armazenadas em cada dispositivo, referentes aos serviços da vizinhança, é garantida através de um mecanismo proativo de gerenciamento da mobilidade dos nós. Quando é detectado um aumento na taxa de mobilidade do dispositivo ou da sua vizinhança, tanto a periodicidade de envio quanto o número de saltos que o anúncio pode alcançar (diâmetro do anúncio) são reduzidos; o parâmetro que especifica a validade dos serviços também pode ser modificado. Além de armazenar localmente os serviços que disponibiliza e os anúncios de serviço de seus vizinhos informação utilizada no processo de descoberta pelo GSD, cada nó mantém uma tabela de roteamento reverso (RR Table). Os registros dessa tabela contêm o endereço de onde se originou a requisição, um identificador de broadcast e o endereço do nó que encaminhou a mensagem. Cada entrada da tabela é mantida por um período de tempo configurável (parâmetro REV_ROUTE_TIMEOUT), diretamente relacionado ao número de saltos que a requisição pode percorrer (parâmetro HOP_COUNT); quanto maior o HOP_COUNT, maior será o valor atribuído a REV_ROUTE_TIMEOUT. A tabela de roteamento reverso segue a abordagem node centric, sendo indexada pelo endereço do dispositivo que originou a requisição. Ao responder uma requisição, o nó consulta a sua RR Table para fazer o encaminhamento reverso da resposta. Em caso de falhas provocadas pela expiração do caminho ou pelo deslocamento de algum nó que o constitui, o protocolo de roteamento AODV (Ad hoc On-demand Distance Vector) [Perkins et al. 2003] é utilizado para encaminhar a resposta do ponto onde a falha ocorreu até o nó que originou a requisição. O GSD não trata a seleção de serviços, que é feita de forma manual com a intervenção direta do usuário da aplicação; o mecanismo de invocação de serviços e aspectos relacionados à segurança não são tratados.

30 142 Minicursos: 25º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos Allia Allia [Ratsimor et al. 2002; Ratsimor et al. 2004] é um framework que oferece suporte à descoberta de serviços em ambientes ad hoc para aplicações de m-commerce (mobile commerce), implementando uma arquitetura de descoberta de serviços distribuída. O framework foi projetado com base em dois conceitos centrais: (i) armazenamento peerto-peer de anúncios de serviços e (ii) agentes configuráveis por meio de políticas locais. O uso de agentes dá suporte à descoberta de serviços entre plataformas distintas. O uso de políticas locais garante a flexibilidade da plataforma de agentes e a sua adaptabilidade, em tempo de execução, às características do ambiente, à capacidade do dispositivo, às configurações específicas das aplicações hospedadas pelo dispositivo e às preferências do usuário. Nessa abordagem, o escopo da descoberta é definido em função da topologia de rede: o alcance de uma mensagem de descoberta é restrito à vizinhança do nó que a originou. O protocolo oferece suporte à descoberta de serviços sobre redes Bluetooth, TCP/IP, GSM e WLAN Cada dispositivo móvel deve executar o framework Allia, que é constituído pelos componentes ilustrados na Figura 17(a): (i) um repositório genérico, responsável pela hospedagem de agentes cada dispositivo deve hospedar, obrigatoriamente, pelo menos, um agente de descoberta; (ii) um serviço de páginas amarelas, responsável pelo registro de serviços no dispositivo local, que utiliza o DF (Directory Facilitator) da plataforma de agentes FIPA (Foundation for Intelligent Physical Agents) [Poslad et al. 2000]; (iii) um serviço de páginas brancas, que registra os agentes locais através do AMS (Agent Management System), também da plataforma FIPA; (iv) um gerente de políticas (Policy Manager), que controla o comportamento da plataforma; (v) um gerente de anúncios (Advertising Manager), responsável por anunciar os serviços oferecidos pelo dispositivo móvel; (vi) um gerente de armazenamento (Cache Manager), responsável pelo armazenamento dos anúncios de serviços recebidos dos dispositivos vizinhos; e (vii) um gerente de encaminhamento (Forwarding Manager), responsável por encaminhar mensagens de anúncios e requisições de serviços recebidas para os dispositivos vizinhos. ( a ) Arquitetura ( b ) Implementação Figura 17 Framework Allia [Ratsimor et al. 2004]. No Allia, anúncios podem ser de dois tipos: anúncio de serviço e anúncio de plataforma (ou dispositivo). Os anúncios de serviço transportam informações sobre os serviços disponibilizados pela plataforma local do dispositivo anunciante (serviços esses geridos pelo DF). Esses anúncios podem ser emitidos periodicamente ou em função de eventos específicos, como quando um agente no dispositivo recebe um novo anúncio ou detecta a presença de um novo dispositivo na vizinhança. Os anúncios de plataforma servem para um dispositivo notificar seus vizinhos sobre a presença da sua plataforma, e são emitidos periodicamente. Um anúncio de plataforma serve ainda para atualizar a