Cristina Orthmann da Silva
SOA-RSSF: Arquitetura Orientada a Serviços
(SOA) em Aplicações de Rede de Sensores sem
Fio (RSSF)
Florianópolis – SC Junho / 2008
Cristina Orthmann da Silva
SOA-RSSF: Arquitetura Orientada a Serviços
(SOA) em Aplicações de Rede de Sensores sem
Fio (RSSF)
Trabalho de conclusão de curso apresentado como parte dos requisitos para obtenção do grau Bacharel em Sistemas de Informação.
Orientador:
Prof. Dr. Mário Antônio Ribeiro Dantas
UNIVERSIDADE FEDERAL DE SANTA CATARINA DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA
BACHARELADO EM SISTEMAS DE INFORMAÇÃO
Florianópolis – SC
Monografia de Projeto Final de Graduação sob o título “SOA-RSSF: Arquitetura Ori-entada a Serviços (SOA) em Aplicações de Rede de Sensores sem Fio (RSSF)”, defendida por Cristina Orthmann da Silva e aprovada em Junho / 2008, em Florianópolis, Estado de Santa Catarina, pela banca examinadora constituída pelos professores:
Prof. Ph.D. Mario Antonio Ribeiro Dantas Orientador
Prof. Dr. Antônio Augusto Medeiros Fröhlich
Universidade Federal de Santa Catarina
Prof. Ph.D. Carlos Barros Montez Universidade Federal de Santa Catarina
Prof. Dr. João Bosco Mangueira Sobral Universidade Federal de Santa Catarina
Dedicatória
Dedico este trabalho ao meu pai (in memoriam) e à minha mãe, pelo apoio e incentivo aos estudos, e ao meu marido (Mozão), pela sua compreensão nos momentos de ausência em função deste trabalho.
Agradecimentos
Meus sinceros agradecimentos vão para o meu marido (Mozão) por sua paciência, compreensão e apoio durante toda esta jornada; para os meus amigos Luciano Antonio Costa e Luiz Rogério Batista De Pieri, pela ajuda dispensada nos momentos de dificuldade no desenvolvimento deste projeto; para o grupo Nerds-SIN pelas amizades adquiridas e a troca de conhecimento; para o laboratório LaPeSD que disponibilizou o ambiente para a execução dos experimentos; e em particular ao professor Mário Antônio Ribeiro Dantas, pela sua orientação, motivação e incentivo.
Sumário
Lista de Figuras Lista de Tabelas Resumo 1 Introdução p. 13 1.1 Motivação . . . p. 14 1.2 Objetivo Geral . . . p. 14 1.3 Objetivos Específicos . . . p. 14 1.4 Justificativa . . . p. 14 1.5 Delimitação do Escopo . . . p. 15 1.6 Organização do Trabalho . . . p. 15 2 Computação Móvel p. 16 2.1 Taxonomia . . . p. 162.2 Protocolos de Comunicação sem Fio . . . p. 17
2.2.1 IEEE 802.11 . . . p. 17
2.2.2 Bluetooth . . . p. 18
2.3 Protocolos IP . . . p. 19
2.3.1 Mobile Internet Protocol (Mobile-IP) . . . p. 19
2.3.2 Cellular Digital Packet Data (CDPD) . . . p. 20
2.4 Redes Móveis Infra-estruturadas . . . p. 20
2.4.1 Arquitetura de Redes Móveis Infra-estruturadas . . . p. 20
2.5 Redes Móveis Ad-Hoc . . . p. 21
2.5.1 Arquitetura de Redes Móveis Ad-Hoc . . . p. 22
2.5.2 Protocolos de Roteamento . . . p. 23
2.5.2.1 Protocolos Proativos (table-driven) . . . p. 24
2.5.2.2 Protocolos Reativos (on-demand ) . . . p. 24
2.5.2.3 Protocolos Híbridos . . . p. 25
2.6 Redes de Sensores sem Fio - (RSSF) . . . p. 25
2.6.1 Arquitetura de Rede de Sensores sem Fio . . . p. 26
2.6.2 Protocolos de Comunicação . . . p. 28
2.6.2.1 Protocolo S-MAC . . . p. 29
2.6.2.2 IEEE 802.15.4 e ZigBee . . . p. 30
2.6.3 Protocolos de Roteamento . . . p. 31
2.6.3.1 Roteamento Plano . . . p. 31
Sequential Assignment Routing (SAR) . . . p. 31
Directed Diffusion (DD) . . . p. 31
Minimum Cost Forwarding Algorithm (MCFA) . . . p. 32
2.6.3.2 Roteamento Hierárquico . . . p. 32
Low-Energy Adaptive Clustering Hierarchy (LEACH) . . p. 32
Power-Efficient Gathering in Sensor Information Systems
(PEGASIS) . . . p. 32
Threshold-Sensitive Energy-Efficient Protocols (TEEN and
APTEEN) . . . p. 33
2.6.3.3 Roteamento Adaptativo . . . p. 34
3 Sistemas Distribuídos p. 35 3.1 Arquiteturas Computacionais . . . p. 36 3.1.1 Arquiteturas MIMD . . . p. 37 3.1.1.1 Multiprocessadores . . . p. 37 3.1.1.2 Multicomputadores . . . p. 37 Clusters . . . p. 38 Grids Computacionais . . . p. 39 3.2 Ambientes de Software . . . p. 39 3.2.1 Ambientes de Programação . . . p. 39 3.2.1.1 Serviços Web . . . p. 39
XML - eXtensible Markup Language . . . p. 40
SOAP - Simple Object Access Protocol . . . p. 41
WSDL - Web Service Description Language . . . p. 44
UDDI - Universal Description, Discovery, and Integration p. 46
3.2.1.2 PVM (Parallel Virtual Machine) . . . p. 47
3.2.1.3 MPI (Message Passing Interface) . . . p. 47
3.2.2 Ferramentas . . . p. 48
3.2.3 Ambientes de Middleware . . . p. 48
3.3 SOA - Service Oriented Arquitecture . . . p. 48
3.3.1 Conceitos . . . p. 50
3.3.1.1 Serviço . . . p. 50
3.3.1.2 Interoperabilidade . . . p. 51
3.3.1.3 Baixo Acoplamento . . . p. 51
3.3.2 Enterprise Service Bus - (ESB) . . . p. 52
4 SOA-RSSF e Trabalhos Relacionados p. 54
4.1.1 Arquitetura . . . p. 55 4.1.1.1 TinyOS RSSF . . . p. 55 4.1.1.2 Gerenciador de Dados RSSF . . . p. 57 4.1.1.3 Provedor de Serviços RSSF . . . p. 58 4.1.1.4 ESB-RSSF . . . p. 59 4.2 Trabalhos Relacionados . . . p. 60
5 Ambiente e Resultados Experimentais p. 62
5.1 Ambiente . . . p. 62
5.1.1 Hardware . . . p. 63
5.1.2 Software . . . p. 64
5.2 Resultados . . . p. 65
6 Conclusões e Trabalhos Futuros p. 69
6.1 Conclusões . . . p. 69
6.2 Trabalhos Futuros . . . p. 70
Anexo A -- Documento WSDL 1.1 p. 71
Lista de Figuras
1 Redes infra-estruturadas e Ad-Hoc(ZENG et al., 2002) . . . p. 18
2 Arquitetura de redes Bluetooth (ZENG et al., 2002) . . . p. 19
3 Ambiente de computação móvel (HELAL et al., 2002) . . . p. 21
4 Arquitetura de Redes Móveis Ad-Hoc (COMMUNICATIONS. . ., ) . . . p. 23
5 Arquitetura RSSF convencional(OTHMAN et al., 2007) . . . p. 27
6 Arquitetura RSSF sinkless(OTHMAN et al., 2007) . . . p. 27
7 Módulos de um nó sensor(DELICATO, 2005) . . . p. 28
8 Especificação ZigBee (ZIGBEE. . ., ) . . . p. 30
9 Classificação das arquiteturas MIMD (DANTAS, 2005) . . . p. 37
10 Exemplos de configurações genéricas de multiprocessadores (DANTAS, 2005) p. 38
11 Exemplos de configurações genéricas de multicomputadores (DANTAS,
2005) . . . p. 38
12 Arquitetura de Serviços Web (ENDREI et al., 2004) . . . p. 41
13 Exemplo XML . . . p. 41
14 Exemplo de esquema XML . . . p. 42
15 Composição da mensagem SOAP (NEWCOMER, 2002) . . . p. 43
16 Mensagem SOAP (CERAMI, 2002) . . . p. 43
17 Mensagem de requisição SOAP (CERAMI, 2002) . . . p. 44
18 Mensagem de resposta SOAP (CERAMI, 2002) . . . p. 44
19 Estrutura UDDI - Provedor, consumidor e intermediador (JOSUTTIS, 2007) p. 46
20 Arquitetura de colaboração SOA (ENDREI et al., 2004) . . . p. 50
22 Exemplo de interface bem definida alinhada ao negócio(JOSUTTIS, 2007) p. 51
23 Enterprise Service Bus (JOSUTTIS, 2007) . . . p. 53
24 Arquitetura SOA-RSSF . . . p. 56
25 Diagrama da aplicação OscilloscopeAppC . . . p. 57
26 Diagrama da aplicação BaseStationP . . . p. 57
27 Diagrama de Classes da aplicação GerenciadorDadosRSSF . . . p. 58
28 Diagrama de Classes da aplicação Provedor de Serviços RSSF . . . p. 59
29 Diagrama de Classes da aplicação ESB-RSSF . . . p. 60
30 Ambiente utilizado nos experimentos . . . p. 62
31 Sensor tMote Sky . . . p. 63
32 Leituras obtidas pela rede de sensores . . . p. 65
33 Leituras RSSF armazenadas no banco de dados . . . p. 66
34 WSDL do ServicosRSSF . . . p. 67
35 Console para publicar serviços jUDDI . . . p. 68
Lista de Tabelas
1 Formas de acoplamento em SOA . . . p. 52
2 Estrutura da mensagem do nó sensor . . . p. 56
3 Características entre os trabalhos relacionados . . . p. 61
4 Características técnicas tMote Sky . . . p. 63
Resumo
Com as melhorias desenvolvidas em tecnologia de microsensores, comunicação sem fio, redes Ad-Hoc, processamento embarcado, etc. as aplicações com redes de sensores sem fio (RSSF) tem crescido consideravelmente, apresentando facilidades na sua configuração. Todavia as aplicações desenvolvidas para estas redes, são projetadas levando em conside-ração somente os dados, fazendo com que as aplicações tornem-se altamente acoplada à rede de sensores, impossibilitando o acesso a informação da RSSF por outras aplicações. Para que aplicações, independentes de plataforma e linguagem de programação, pos-sam ter acesso a estes dados de forma flexível, propomos a utilização do paradigma SOA (Service Oriented Arquitecture) nas aplicações direcionadas às redes de sensores, propor-cionando o baixo acoplamento entre as aplicações e a RSSF.
Com o objetivo de verificar a proposta, foi realizado o desenvolvimento da arquitetura SOA-RSSF e realizados testes que demonstram a interoperabilidade entre aplicações RSSF distintas. Desta forma, pode-se concluir que os objetivos foram alcançados com sucesso, posto que a solução SOA-RSSF mostrou-se bastante interessante para tornar mais flexíveis as aplicações em RSSF, pelo fato de não haver conexão direta entre a aplicação e a rede de sensores.
13
1
Introdução
Devido ao avanço da tecnologia e o padrão 802.11 da IEEE, a computação móvel tornou-se possível, promovendo conectividade não somente para áreas limitadas, mas também para grandes áreas de uma cidade por meio de redes sem fio infra-estruturada e Ad-Hoc.
As redes móveis infra-estruturadas possuem uma certa limitação no contexto da com-putação móvel, porque existe a necessidade de uma infra-estrutura como roteadores e estações de transmissão para manter a conectividade da rede. Todavia, redes móveis Ad-Hoc resolvem este problema, pois a conectividade é mantida por meio de protocolos específicos, onde todos os terminais da rede funcionam como roteadores, encaminhando de forma comunitária as mensagens aos seus vizinhos, possibilitando assim a computação em movimento. Contudo, estes dois tipos de redes ainda sofrem com alguns problemas que são itens de estudos, como: largura de banda limitada, qualidade de transmissão, segurança as informações trasmitidas, taxas de perdas de pacotes elevadas, tempos de atraso e jitter, etc.
Outro modelo de rede móvel Ad-Hoc são as redes de sensores sem fio (RSSF), que são compostas por sensores distribuídos randomicamente ou de acordo com alguma estratégia de implantação, que tem como objetivo monitorar um determinado ambiente. Estas redes diferenciam das MANETs (Mobile Ad hoc Network ) pelo fato dos nós da rede executarem tarefas colaborativamente, enquanto as MANETs possuem elementos computacionais que individualmente executam tarefas distintas. Podemos observar outras diferenças, como: o número superior de nós em uma RSSF, a ausência de identificação global, limitações de processamento e de fornecimento de energia, etc.
Contudo, a heterogeneidade entre redes e o alto acoplamento das aplicações que se utilizam destas redes fazem com que o acesso as informações seja uma tarefa difícil. Desta forma, serviços Web se propõem a manter a interoperabilidade e a flexibilidade entre aplicações de diferentes redes de forma eficiente e barata. Neste cenário as aplicações
1.1 Motivação 14
utilizam padrões de desenvolvimento Web aceitos por toda a comunidade da Tecnologia de Informação, possibilitando o desenvolvimento de soluções baseadas em arquiteturas orientadas à serviço (SOA).
1.1
Motivação
O grande interesse no funcionamento de redes de sensores sem fio, devido à minha qualificação técnica, e a crescente utilização de serviços Web em soluções na área da Tecnologia da Informação, foram fatores que me motivaram a desenvolver este trabalho.
1.2
Objetivo Geral
Propor uma arquitetura orientada à serviços para facilitar o acesso aos serviços dis-poníveis em uma rede de sensores.
1.3
Objetivos Específicos
O objetivo deste trabalho é promover a flexibilidade e a interoperabilidade entre apli-cações de redes de sensores sem fio, utilizando a arquitetura orientada à serviços (SOA). Utilizando-se desta arquitetura, os dados gerados por uma determinada rede, serão dispo-nibilizados para qualquer aplicação e para qualquer empresa que esteja interessada nestes dados. Os dados capturados da rede serão transformados em informações e estas serão disponibilizadas por meio de serviços Web.
1.4
Justificativa
Observamos que as aplicações que se utilizam das redes de sensores sem fio para captu-rar dados sobre o monitoramento de um determinado ambiente, são altamente acoplada à rede. A utilização do paradigma SOA possibilita o baixo acoplamento e conseqüentemente proporcionando a interoperabilidade entre as aplicações.
1.5 Delimitação do Escopo 15
1.5
Delimitação do Escopo
O escopo deste trabalho limita-se em apresentar uma arquitetura de orientada à ser-viços em aplicações RSSF, não abordamos problemas como: segurança dos serser-viços Web e dos dados transmitidos pela RSSF, conservação de energia em RSSF, descoberta dos serviços, que são pontos importantes que devem ser levados em consideração no projeto da arquitetura SOA-RSSF.
1.6
Organização do Trabalho
Este trabalho está organizado em seis capítulos. No capítulo dois, apresentamos um breve estudo sobre a computação móvel. Abordamos sua taxonomia, descrevemos carac-terísticas importantes sobre as redes sem fio infra-estruturada, Ad-Hoc e redes de sensores sem fio. Também são apresentados alguns protocolos de comunicação, IP e roteamento. A computação distribuída é discutida no terceiro capítulo, onde apresentamos a clas-sificação das arquiteturas computacionais, os ambientes de programação, como os Web Services, e apresentamos o paradigma SOA. No quarto capítulo, detalhamos sobre o pro-jeto SOA-RSSF e os trabalhos relacionados. O ambiente e os resultados dos experimentos são apresentados no quinto capítulo. O sexto capítulo é o último e nele finalizamos este trabalho com as conclusões realizadas e sugestões para trabalhos futuros.
16
2
Computação Móvel
O grande avanço da tecnologia possibilitou o desenvolvimento de dispositivos cada vez menores e com mais poder de processamento. A união destes dispositivos portáteis às redes com ou sem fio, apoiaram a tendência de computar em movimento, conhecida como computação móvel, computação nômade ou computação Anywhere and AnyTime. Um dos acontecimentos mais importantes para o surgimento da Computação Móvel foi a implementação das redes locais sem fio (WLAN) padronizadas pela IEEE 802.11, provendo a conectividade não somente à áreas limitadas, mas em porções substanciais de uma cidade. Hoje milhares de pessoas trocam informações todos os dias usando seus laptops, telefones celulares, assistentes digitais pessoais (PDA) entre outros dispositivos portáteis com comunicação sem fio.
Existem várias aplicações que se utilizam da computação móvel, como por exemplo: acesso à internet sem fio, monitoramento de ambientes remotos ou perigosos, cuidado médico emergencial, monitoramento de transporte de produtos, monitoramento do movi-mento de tropas do exército pela defesa nacional, etc. Muitas destas aplicações podem ser classificadas de acordo com o tipo de rede móvel utilizada, onde a rede pode ser infra-estruturada (sessão 2.4) ou Ad-Hoc ( sessão 2.5).
2.1
Taxonomia
Apesar de alguns autores (PORTA; SABNANI; GITLIN, 1996) e (ZENG et al., 2002) des-creverem de forma igual a computação móvel e a nômade, outros autores (HELAL et al., 2002) apresentam uma certa diferença entre estes dois tipos de computação. Tanto a com-putação móvel quanto a nômade utilizarem dispositivos portáteis com comunicação sem fio, mas o tipo de rede usada na computação nômade permite mobilidade limitada den-tro de um edifício, como por exemplo, uma pessoa que utiliza seu notebook com modem Dial-Up para acessar a internet. A computação móvel requer redes sem fios que suportem mobilidade fora de um ambiente limitado, onde exista a passagem de uma rede para uma
2.2 Protocolos de Comunicação sem Fio 17
outra enquanto o usuário se movimenta, como por exemplo, uma pessoa viajando em um ônibus com seu notebook conectado a um telefone GSM. Resumindo, a computação nômade utiliza redes locais com ou sem fio e a computação móvel utiliza redes sem fio que permitem mobilidade entre outras redes sem fio. Outro termo utilizado nesta área é a Computação Ubíqua que pode ser considerada como a agregação da computação móvel e a nômade.
Para fins de padronização e entendimento estaremos utilizando o termo Computação Móvel de acordo com a descrição de (HELAL et al., 2002), apresentada anteriormente.
2.2
Protocolos de Comunicação sem Fio
Nesta sessão serão apresentadas duas tecnologias de comunicação sem fio que podem ser usadas na construção de redes móveis: o padrão IEEE 802.11 para redes locais sem fio (Wireless Local Area Network (WLAN)) e a tecnologia Bluetooth que é padrão de fato para redes sem fio pessoais (Wireless Personal Area Network (WPAN)). A WLAN é uma rede local sem fio caracterizada por uma pequena área, enquanto um WPAN é um rede constituída para conectar dispositivos localizados dentro de um círculo de 10 metros.
2.2.1
IEEE 802.11
IEEE 802.11 é um padrão de transmissão digital de dados sem fio que utiliza uma banda de 2.4GHz ISM e tem como objetivo prover conexão em uma rede local sem fio entre computadores portáteis, e entre computadores portáteis e uma rede infra-estrutura fixa. Este padrão define as camadas Física e MAC. Três diferentes tecnologias são usadas como uma interface aérea da camada física: infravermelho, frequency hopping e direct sequence spread spectrum. A tecnologia mais popular é a direct sequence spread spectrum, na qual consegue oferecer um taxa acima de 11Mbps.
O padrão 802.11 pode ser usado para implementar tanto uma arquitetura W-LAN infra-estruturada, como uma arquitetura W-LAN Ad-Hoc, como apresentado na figura 1. Na rede infra-estruturada, existe um controlador central para cada célula, oferecendo um ponto de acesso à rede. O ponto de acesso é normalmente conectado a uma rede com fios, mesmo que forneça acesso à dispositivos móveis. Todo o trafego da rede é realizado através do ponto de acesso, até mesmo dentro da própria célula.
2.2 Protocolos de Comunicação sem Fio 18
dispositivos da mesma célula podem comunicar-se diretamente entre si através de uma freqüência pré-definida, sem a intervenção de uma entidade centralizadora ou de uma infra-estrutura. Cada célula é identificada com um número de identificação (IBSSID), na qual é gerenciada localmente. Devido a flexibilidade do algoritmo CSMA/CA, esta iden-tificação é suficiente para sincronizar dispositivos em um clock comum para em seguida receber/transmitir os dados corretamente. A solicitação de sincronização é um procedi-mento de varredura usado por um dispositivo que queira ligar-se à um IBSS existente. Se o resultado da varredura não encontrar nenhum IBSS então a estação inicializará um novo IBSS.
Figura 1: Redes infra-estruturadas e Ad-Hoc(ZENG et al., 2002)
2.2.2
Bluetooth
Bluetooth é um padrão de transmissão sem fio de dados que opera em uma banda de 2.4GHz e provê um link sem fio de curta distância entre notebooks, telefones celulares e outros dispositivos. Nesta banda, são definidos 79 canais de diferentes freqüências de rádio com 1MHz. A camada física utiliza a técnica de transmissão frequency hopping spread spectrum (FHSS). O principal objetivo da especificação Bluetooth é garantir a interoperabilidade entre diferentes aplicações que rodam em cima de diferentes protocolos.
Em uma rede Bluetooth, uma estação tem o papel de mestre e todas as outras possuem o papel de escravas. O mestre decide qual escravo é o único a ter acesso ao canal, isto é, um escravo é autorizado a entregar um pacote para o mestre, somente se ele recebeu uma mensagem de autorização do mestre. Um ou mais dispositivos que dividem o mesmo
2.3 Protocolos IP 19
canal formam um piconet. Uma unidade pode estar dentro de mais de um piconet, mas somente um pode ser mestre, conforme apresentado na figura 2.
Figura 2: Arquitetura de redes Bluetooth (ZENG et al., 2002)
2.3
Protocolos IP
A comunicação entre os dispositivos móveis com IP fixo deve ser transparente inde-pendente do ponto onde ele está acessando a rede. O protocolo de comunicação deve também ser transparente para os hosts e roteadores. Desta forma os roteadores devem ser capazes de rotear pacotes para destinos móveis como pacotes de dados normais. A seguir apresentaremos alguns protocolos de comunicação móvel.
2.3.1
Mobile Internet Protocol (Mobile-IP)
O Mobile-IP é um melhoramento do protocolo IP padrão, na qual possibilita o ro-teamento dos pacotes IP entre os nós móveis na Internet. Para que o protocolo IPv4 padrão funcione corretamente em um ambiente móvel seria necessário que o dispositivo móvel determinasse um novo IP a cada vez que fosse alterado o seu ponto de conexão. O Mobile-IP descreve um mecanismo na qual permite que os nós móveis possam mudar o ponto de conexão na rede sem alterar o seu IP.
2.4 Redes Móveis Infra-estruturadas 20
2.3.2
Cellular Digital Packet Data
(CDPD)
CDPD é um protocolo multirede sem conexão, baseado no Mobile-IP, onde a idéia principal é utilizar canais não utilizados existentes no Advanced Mobile Phone Systems (AMPS) para prover um canal de dados de 19.2Kbps. Apesar do CDPD e o Mobile-IP serem similares, as terminologias de seus componentes são diferentes.
A principal semelhança entre os protocolos CDPD e Mobile-IP é a triangulação entre o nó móvel, os agentes de origem e estrangeiro. As suas principais diferenças são:
• O endereço IP deve ser determinado pelo provedor de serviço CDPD;
• A mobilidade de tunelamento é baseada no protocolo de rede sem conexão (Connec-tionless Network Protocol (CLNP)) e no Mobile-IP é baseada no protocolo IP-in-IP;
• O Mobile-IP opera completamente acima da camada de enlace e no CDPD trabalha em maior parte na camada de enlace.
2.3.3
GSM General Packet Radio Service
(GPRS)
GPRS é um serviço de dados do pacote GSM, seu objetivo foi suportar taxas de transmissão de dados acima de 9.6kbps alcançados pela tecnologia GSM. Diferentemente do Mobile-IP, GPRS não limita os protocolos IP, oferecendo conexão com protocolos padrões como TCP/IP, X.25 e CLNP, contudo o protocolo Mobile-IP influenciou bastante o projeto do gerenciamento de mobilidade no GPRS.
2.4
Redes Móveis Infra-estruturadas
2.4.1
Arquitetura de Redes Móveis Infra-estruturadas
A arquitetura de um ambiente de computação móvel, apresentada na figura 3 é com-posta por estações com interface para comunicação sem fio, hosts fixos, dispositivos móveis e uma rede fixa de alta velocidade (Mbps a Gbps), onde as estações e hosts estão conec-tados. O principal objetivo das estações é ser o ponto de acesso entre os dispositivos móveis e a rede fixa. Assim toda a comunicação móvel desta rede é realizada por estes pontos, mesmo se os dispositivos móveis estejam próximos uns dos outros, a comunicação será realizada através do ponto de acesso, nesta arquitetura a comunicação direta não é possível.
2.5 Redes Móveis Ad-Hoc 21
Figura 3: Ambiente de computação móvel (HELAL et al., 2002)
As limitações e particularidades das redes móveis fazem parte das principais pesquisas e desenvolvimentos da computação móvel. Dentre as limitações existentes, podemos citar:
• Freqüente desconexão;
• Largura de banda de comunicação limita;
• Qualidade de transmissão;
• Infra-estrutura das redes sem fio heterogêneas;
• Segurança e anonimato;
• Controle de energia dos dispositivos móveis.
2.5
Redes Móveis
Ad-Hoc
Redes móveis infra-estruturadas, como as redes de celulares, ainda estão de alguma forma limitadas pela necessidade de infra-estrutura (roteadores e estações de transmissão).
2.5 Redes Móveis Ad-Hoc 22
Para redes móveis Ad-Hoc esta limitação não existe. Os usuários podem se mover enquanto ao mesmo tempo ainda estão conectados com o resto do mundo, tornando o sonho da comunicação “anytime and anywhere” possível (ZENG et al., 2002).
Redes Ad-Hoc são uma evolução das redes móveis infra-estruturadas e são compostas por nós que se comunicam sem um controle central, mas que herdam os mesmos pro-blemas da comunicação móvel infra-estruturada, como por exemplo: largura de banda, controle de energia, qualidade de transmissão, etc. Além disso, por ser uma rede que realiza múltiplos saltos (multihop) e por não possuir uma infra-estrutura fixa, novos pro-blemas são encontrados, como por exemplo: publicação, descoberta e manutenção de nós, endereçamento e o seu próprio roteamento.
Em redes móveis Ad-Hoc a topologia é altamente dinâmica e randômica, além disso a distribuição de seus nós e a auto-organização, são importantes papéis desta rede. As redes móveis Ad-Hoc utilizam na sua comunicação links sem fio, resultando em uma significativa baixa da sua capacidade de transmissão em relação as redes móveis tradicionais. Redes móveis Ad-Hoc são afetadas por grandes taxas de perdas de pacotes, tempos de atraso e jitter altos além de segurança física limitada. Os nós da rede dependem de baterias ou de outros suprimentos de energia esgotáveis, por isso a economia de energia é um importante critério no projeto de sistemas utilizando redes móveis Ad-Hoc.
O aspecto chave da transmissão sem fio é a propagação do sinal de rádio, mas canais adjacentes acabam interferindo nos sinais entre os usuários da rede. Um melhor aprovei-tamento do ambiente e controle da localização dos usuários do sinal de rádio, pode até minimizar a interferência, mas esta não é uma realidade em sistemas sem fio que dividem o mesmo espectro do sinal de rádio. Para redes Ad-Hoc que dividem o mesmo espectro, novos métodos de cooperação são requeridos para permitir a sua coexistência.
Segurança em redes, incluindo redes Ad-Hoc, envolvem principalmente confidenciali-dade e integriconfidenciali-dade da informação, bem como a legitimiconfidenciali-dade do usuário e a disponibiliconfidenciali-dade dos serviços. Em aplicações militares, a confidencialidade é considerada o objeto de segu-rança mais importante, já para aplicações civis a disponibilidade do serviço, dependendo da aplicação, é o que mais importa (ZENG et al., 2002).
2.5.1
Arquitetura de Redes Móveis Ad-Hoc
Uma MANET (Mobile Ad Hoc NETworks) consiste de um conjunto de hosts móveis operando sem a ajuda de infra-estrutura estabelecida ou administração central, como por
2.5 Redes Móveis Ad-Hoc 23
exemplo estações base ou pontos de acesso. A comunicação é realizada através de links sem fio entre hosts móveis através de suas antenas, conforme apresentada na figura 4 .
Figura 4: Arquitetura de Redes Móveis Ad-Hoc (COMMUNICATIONS. . ., )
Um bom projeto de redes móveis Ad-Hoc, envolve todas as camadas de comunicação, desde a camada física até a camada de aplicação. A camada MAC (Medium Access Con-trol ) especificada na norma IEEE 802.11 é geralmente a mais estudada em projetos de redes Ad-Hoc. Atualmente pesquisas trabalham nas camadas mais baixas nas questões de modulação e codificação dos sinais, múltiplos acessos, protocolos móveis sem fio e pro-tocolos de localização. Nos Estados Unidos, a maioria das pesquisas trabalham sobre as redes de sensores sem fio e são patrocionados pelo NSF (Advanced Networking Infrastruc-ture and Research Division and Computer–Communications Research Division) e pelo DARPA (Microelectromechanical Systems and Global Mobile Information Systems).
O grupo de trabalho da IETF (Internet Engineering Task Force) em redes móveis está padronizando o roteamento de redes Ad-Hoc. O grupo estuda especificações de roteamento, com o objetivo de que uma rede possa suportar mais de 100 roteadores. O trabalho da MANET apoia-se em outras padrões existentes da IETF como o mobile-IP e endereçamento IP.
2.5.2
Protocolos de Roteamento
Os protocolos de roteamento possuem um papel importante na comunicação de redes móveis Ad-Hoc devido as limitações de potência do sinal de rádio e da utilização do canal, um host móvel se comunica com outros hosts móveis em um cenário com múltiplos saltos,
2.5 Redes Móveis Ad-Hoc 24
onde um pacote enviado por um host de origem pode ser retransmitido por vários host intermediários até que o pacote alcance o host destino.
Os protocolos de roteamento são geralmente categorizados de acordo com os seus métodos de descobrimento e de manutenção de roteadores, como os protocolos Proativos e Reativos.
2.5.2.1 Protocolos Proativos (table-driven )
Protocolos proativos tentam manter rotas constantemente, assim uma rota está sem-pre disponível quando é necessário a remessa de um pacote. Nesses protocolos, tabelas de roteamento são trocadas entre os nós vizinhos cada vez que uma mudança ocorre na topologia da rede. A manutenção consistente e atualizada dos roteadores entre cada par origem-destino requer a propagação de grande quantidade de informação de roteamento, sendo necessário ou não. Desta forma, um roteador entre qualquer par origem-destino está sempre disponível para transmitir, mas esses protocolos não conseguem ser eficientes quando a taxa de mobilidade da rede é alta ou quando há um grande número de nós na rede. Na realidade, o controle de overhead, em termos de tráfego e consumo de energia, é uma séria limitação em redes móveis Ad-Hoc, no que a largura de banda e a energia são recursos escassos. Exemplos de protocolos proativos são Wireless Routing Protocol (WRP) e o destination sequenced distance vector (DSDV).
2.5.2.2 Protocolos Reativos (on-demand )
Ao contrário do protocolo proativo, os protocolos reativos enviam uma mensagem de controle para descobrir um roteador entre o par origem-destino somente quando é necessário, isto é, quando solicitado pela origem. Um protocolo de roteamento para redes móveis Ad-Hoc necessita trabalhar três questões: descobrimento do roteador, remessa dos dados e manutenção do roteador. Quando o nó origem deseja enviar um dado para um nó destino, este protocolo procura o roteador primeiro e depois envia o pacote de dados. Portanto, os protocolos reativos reduzem drasticamente o controle de overhead. No entanto, similar as comunicações orientadas a conexão, um roteador não está inicialmente disponível e isto gera um período de latência devido ao procedimento de descoberta do roteador.
Muitos protocolos reativos tem sido propostos como por exemplo os protocolos such as dynamic source routing (DSR), signal stability-based adaptive routing (SSA), ad hoc
on-2.6 Redes de Sensores sem Fio - (RSSF) 25
demand distance vector routing (AODV), e temporally ordered routing algorithm (TORA).
2.5.2.3 Protocolos Híbridos
Este protocolo reúne características de ambos os protocolos para beneficiar o tempo de resposta rápido da abordagem proativa e limitar o overhead como nos protocolos reativos. A vantagem desta abordagem é manter proativamente todos os roteadores mais freqüentemente usados e trabalhar sob demanda os outros roteadores. Para alcançar o correto balanço entre as operações proativas e reativas em uma abordagem híbrida é necessário o conhecimento prévio do ambiente de rede ou um mecanismo adicional para controlar adaptavelmente os modos de operação.
Um exemplo de protocolo híbrido é o Zone Routing Protocol (ZRP) (BEIJAR, 1998), onde basicamente define-se um conjunto de nós dentro de r saltos, chamado de zona, sendo que o valor de r é pré-definido. Para cada host a informação de roteamento dentro da zona é constantemente coletada de forma proativa, desta forma sempre que o estado do link de um nó é alterado, um aviso é enviado para todos os r saltos de acordo com o protocolo DSDV. Portanto, um nó sempre sabe como alcançar um outro nó dentro da sua própria zona. Por outro lado o roteamento entre zonas é realizado segundo a abordagem reativa utilizando o protocolo DSR.
2.6
Redes de Sensores sem Fio - (RSSF)
Com o avanço da tecnologia de microsensores, comunicação sem fio, redes Ad-Hoc, processamento embarcado, etc. as aplicações com redes de sensores sem fio (RSSF) tem crescido consideravelmente. RSSFs são redes Ad-Hoc compostas por sensores distribuí-dos randomicamente ou de acordo com alguma estratégia de implantação. Sensores são dispositivos de baixo custo, processamento, comunicação e consumo de energia limitados, que se comunicam entre si utilizando um canal de rádio freqüência. Apesar das suas limi-tações, quando trabalham cooperativamente em uma rede são muito eficientes. Uma rede de sensores pode possuir centenas de sensores com aplicações diversas como: monitora-ção de fenômenos da natureza, vigilância de tráfego, monitoramonitora-ção de habitats selvagens, automação de produção, vigilância em segurança militar, entre outras aplicações.
Os características básicas de um RSSF são:
2.6 Redes de Sensores sem Fio - (RSSF) 26
• Comunicação broadcast e roteamento múltiplos saltos;
• Agregação de dados;
• Mobilidade dos nós sensores;
• Implantação densa e esforço cooperativo dos nós sensores;
• Freqüente mudança na topologia por causa de falhas de sensores;
• Limitações de energia, de potência de transmissão, de capacidade de memória e de poder de computação.
Do ponto de vista de organização, RSSFs e MANETs (Mobile Ad hoc Network ) são idênticas, já que possuem elementos computacionais que comunicam diretamente entre si através de enlaces de comunicação sem fio (LOUREIRO et al., 2003). No entanto existem certas diferenças, MANETs possuem elementos computacionais que individualmente po-dem estar executando tarefas distintas e as RSSFs executam uma função colaborativa. Outras diferenças podem ser observadas como: o número superior de nós em uma RSSF, a ausência de identificação global por causa do grande número de nós, etc (AKYILDIZ; SU; SANKARASUBRAMANIAM, 2002).
Apesar de inúmeras aplicações em RSSF, estas redes possuem várias restrições que devem ser consideradas no projeto de qualquer protocolo (ABDELZAHER et al., 2005). Algumas limitações incluem:
• Limitação no fornecimento de energia: os protocolos de comunicação devem levar em consideração a conservação de energia;
• Limitado processamento: sensores possuem poder de computação restrita, onde não é possível executar protocolos de rede sofisticados;
• Comunicação: a largura de banda dos links sem fio que conectam os sensores é geralmente limitada, restringindo a comunicação entre sensores.
2.6.1
Arquitetura de Rede de Sensores sem Fio
Uma rede de sensores sem fio é composta basicamente de sensores, agregadores, sink e gateways, sendo que os sensores capturam dados de uma região de interesse, os agregadores são representantes lógicos de uma região e agregam/sumarizam os dados desta região. Os
2.6 Redes de Sensores sem Fio - (RSSF) 27
sinks coletam os dados de todos os sensores e/ou agregadores, e interage com a aplicação via um gateway. O gateway possui uma interface de comunicação entre a RSSF e o mundo externo (OTHMAN et al., 2007). Esta é a arquitetura mais comum em RSSF conforme apresentado na figura 5, onde a maioria das aplicações se baseiam neste modelo. Como apresentado por (OTHMAN et al., 2007), pode haver a necessidade de uma interação direta entre os sensores e agregadores com a aplicação, desta forma a RSSF não possui sinks e gateways, conforme apresentado na figura 6.
Figura 5: Arquitetura RSSF convencional(OTHMAN et al., 2007)
Figura 6: Arquitetura RSSF sinkless(OTHMAN et al., 2007)
O hardware de um nó sensor da rede, possui basicamente quatro módulos: de senso-riamento, de processamento, de comunicação e de energia como apresentada na figura 7, e outros módulos adicionais, como por exemplo, o de localização (para determinar com precisão a posição de um nó) e o de movimento (para mover o nó para um local que permita a realização de uma tarefa).
2.6 Redes de Sensores sem Fio - (RSSF) 28
Figura 7: Módulos de um nó sensor(DELICATO, 2005)
O módulo de sensoriamento são geralmente compostos por sensores e conversores analógico-digital (ADC). Os sensores capturam as condições ambientais, como: tempera-tura, umidade, movimento veicular, pressão, etc. Os sinais analógicos produzidos pelos sensores então são convertidos para sinais digitais pelo ADC e entregues para o módulo de processamento. O módulo de processamento, onde geralmente está associado a um módulo de armazenamento local, gerencia os procedimentos necessários para que os nós atuem de forma colaborativa. O módulo de comunicação conecta o nó à rede. Módulo de energia que é um dos componentes mais importantes do sensor, fornece energia constante para o sensor e o seu fator de eficiência determina o tempo de vida da bateria.
2.6.2
Protocolos de Comunicação
A comunicação entre os nós de uma RSSF utiliza links de rádio, sendo que cada nó se comunica com o seu vizinho imediato dentro de uma faixa de rádio. Dentro desta faixa de rádio a comunicação é realizada por broadcast, isto é, todos os nós escutam imediatamente o que um determinado nó transmite. A subcamada MAC (Medium Access Control ) gerencia o acesso ao meio físico da rede e seu fundamental objetivo é reduzir e evitar colisões de pacotes no meio de comunicação. As características de RSSFs descritas a seguir apontam para a necessidade de um protocolo MAC especializado (ZHAO; GUIBAS, 2004).
• RSSF são sistemas colaborativos, usualmente servem a um ou a um pequeno número de aplicações, o foco das melhorias devem estar direcionadas a rede inteira e não ao
2.6 Redes de Sensores sem Fio - (RSSF) 29
nível de um nó;
• Em muitas aplicações RSSF, a maioria dos nós sensores estão ociosos na maior parte do tempo. Quando eventos de interesse ocorrem e são detectados, existe uma atividade somente em algumas partes da rede. Por causa desta atividade esporádica, as aplicações devem estar preparadas para lidar com grandes tempos de latência;
• Questões como eficiência no consumo de energia, escalabilidade e robustez são gran-des influências em RSSFs, gran-desta forma podemos comprometer muitos objetivos de protocolo padrão para aumentar o prolongamento da vida da rede.
Existem muitos protocolos MAC que estão sendo desenvolvidos para comunicação de voz e dados em redes sem fio. Exemplos típicos são: TDMA, FDMA, CDMA e CSMA. Por enquanto, os trabalhos publicados mais significantes no desenvolvimento específico da sub-camada MAC para rede de sensores sem fio são os protocolos S-MAC da Universidade da California (YE; HEIDEMANN; ESTRIN, 2002) e o IEEE 802.15.4.
2.6.2.1 Protocolo S-MAC
O principal objetivo do protocolo S-MAC é reduzir o gasto de energia causada por escuta ociosa, colisões, escuta inútil, controle de overhead e mensagens transitórias.
Período de escuta e repouso é projetado para reduzir o consumo de energia durante longos períodos de tempos quando eventos de sensoriamento não ocorrem. Para reduzir a latência e o controle de overhead, S-MAC tenta coordenar e sincronizar períodos de repouso entre os nós vizinhos por periódicas trocas de horários de repouso de cada nó, então os tempos de repouso serão sincronizadas sempre que possível.
Impedir colisões em S-MAC é similar à função de coordenação distribuída (DCF) para IEEE 802.11 Ad-Hoc. Se um nó não consegue acesso ao meio, este irá repousar e irá acordar quando o destinatário estiver livre novamente. O nó sabe quanto tempo que precisa repousar, pois no pacote que o nó recebeu para a transmissão, existe um campo informando quanto tempo esta transmissão irá durar. Para evitar a escuta inútil overhearing os nós são colocados em repouso enquanto seus vizinhos conversam entre si.
As mensagens são tratadas como unidades lógicas de dados passados entre os nós sensores. Uma mensagem longa é fragmentada em pacotes e enviado em rajadas com RTS/CTS para reservar o meio de comunicação para o envio da mensagem completa. Curtas mensagens precisam aguardar um longo período de tempo enquanto uma longa
2.6 Redes de Sensores sem Fio - (RSSF) 30
mensagem é finalizada, mas como dito anteriormente melhorias ao nível do nó não é tão importante quanto ao nível da rede de sensores como um todo.
Para redes Ad-Hoc de sensores onde os nós permanecem longos períodos inativos, o protocolo S-MAC tem vantagens óbvias em relação ao MAC 802.11.
2.6.2.2 IEEE 802.15.4 e ZigBee
A ZigBee Alliance é um consórcio industrial com o objetivo de promover o padrão IEEE 802.15.4 e define os protocolos das camadas superiores, da camada de rede à ca-mada de aplicação, incluindo seus perfis. Já o padrão IEEE 802.15.4 define ambos os protocolos das camadas físicas e MAC para o controle e monitoramento remoto, conforme apresentada na figura 8.
Figura 8: Especificação ZigBee (ZIGBEE. . ., )
O padrão ZigBee/IEEE 802.15.4 foi concebido para aplicações que não necessitam de bandas largas, que precisam de baixo consumo de energia e preço baixo de equipa-mentos, se tornando ideal pra controladores e sensores, para a automação de prédios, processos industriais e demais aplicações relacionadas. Estas características possibilitam a implantação de RSSFs com duração de vida no ordem de anos com baterias comuns, para aplicações típicas de monitoramento. Esta otimização é dada pela baixa taxa de transferência de dados e com simples ou nenhum suporte a QoS (ZHAO; GUIBAS, 2004).
2.6 Redes de Sensores sem Fio - (RSSF) 31
2.6.3
Protocolos de Roteamento
Em RSSFs a conservação de energia está diretamente relacionada ao tempo de vida de rede, por isso este item é considerado relativamente mais importante que a performance da rede em termos de qualidade da informação enviada (ABDELZAHER et al., 2005). Portanto, os projetos de protocolos de roteamento devem levar em consideração o fator consumo de energia.
Protocolos de roteamento em RSSF podem ser divididos em Roteamento Plano, Ro-teamento Hierárquico e RoRo-teamento Adaptativo. No RoRo-teamento Plano todos os nós possuem o mesmo papel, já no Roteamento Hierárquico os nós podem ter papéis diferen-tes na rede. No Roteamento Adaptativo, certos parâmetros do sistema são controlados de forma a adaptar-se às condições atuais da rede e níveis de energia disponíveis. A seguir serão apresentados alguns protocolos de cada categoria de roteamento em RSSFs (ABDELZAHER et al., 2005).
2.6.3.1 Roteamento Plano
Sequential Assignment Routing (SAR) A decisão de roteamento em SAR depende de três fatores: recursos de energia, QoS em cada rota e o nível de prioridade de cada pacote. Para evitar falha de rota única, uma abordagem de múltiplos rotas e esquemas de restauração de caminho localizados são usados. Para criar múltiplas rotas para um nó origem, é construída uma árvore onde a raiz é o nó origem, os nós internos são os nós intermediários e as folhas são os nós destinos. Os caminhos da árvore são construídos evitando os nós com baixa energia ou QoS. Ao término do processo, cada nó sensor será parte de uma árvore com múltiplas rotas.
Directed Diffusion (DD) O roteamento DD é baseado em requisições de informação de interesse. Quando um nó possui uma informação que é de interesse de outro nó, o nó que possui a informação a envia para o nó requisitor. O DD é essencialmente um protocolo de disseminação de dados reativo, pois os dados são enviados a partir de uma requisição de um nó, geralmente o sink. Os nós intermediários podem agregar seus dados em um simples pacote para reduzir transmissões e o volume total de dados transmitidos. Por ser um protocolo centrado em dados, onde os nós são endereçados pelo par atributo/valor, não existe a necessidade de uma identificação global, sendo muito eficiente para redes com mobilidade.
2.6 Redes de Sensores sem Fio - (RSSF) 32
Minimum Cost Forwarding Algorithm (MCFA) O algoritmo MCFA leva em consideração que a direção do roteamento é sempre conhecida, por exemplo a direção para a estação base. Assim, um nó sensor não precisa ter um identificador único ou manter uma tabela de roteamento. Ao invés disso, cada nó mantém uma estimativa do caminho de menor custo entre ele e a estação base. Cada mensagem que é enviada por um sensor é distribuída para seus vizinhos. Quando o nó recebe esta mensagem, ele checa se o custo é menor que custo entre o nó sensor de origem e a estação base. Se for, ele redistribui a mensagem para os seus vizinhos. Este procedimento se repete até que a estação base é alcançada.
2.6.3.2 Roteamento Hierárquico
Low-Energy Adaptive Clustering Hierarchy (LEACH) LEACH é um protocolo baseado em agrupamento que minimiza a dissipação de energia na rede de sensores e aumenta o tempo de vida da rede, pois diminui a comunicação global da rede. A proposta do LEACH é selecionar nós sensores randomicamente e atribuí-lhes o papel de líder do agrupamento. Os líderes são responsáveis por reunir os dados enviados pelos nós do seu agrupamento, aplicar algum mecanismo de compressão de dados e enviar o resultado para o nó sink. Como os nós líderes consomem mais energia que os demais, o LEACH realiza uma rotação randômica periódica de líderes para distribuir de forma uniforme a utilização de energia entre os sensores da rede. Para isso, após algum tempo, cada sensor entra novamente na fase de formação de agrupamento e o ciclo é repetido até o completo esgotamento da energia dos sensores na rede.
Power-Efficient Gathering in Sensor Information Systems (PEGASIS) O protocolo PEGASIS propõe um melhoramento no protocolo LEACH. A idéia principal deste protocolo é que para extender o tempo de vida da rede, os nós comunicam-se somente com os seus vizinhos mais próximos e se revezam na transmissão para o estação base. Quando a rodada de todos os nós que se comunicaram com a estação base finaliza, uma nova rodada é iniciada e assim por diante. Esta abordagem reduz a energia requerida para transmitir os dados por rodada, porque a energia é espalhada uniformemente entre todos os nós. Assim, PEGASIS possui dois principais objetivos: (1) aumentar o tempo de vida de cada nó usando técnicas colaborativas e conseqüentemente aumentando o tempo de vida da rede; e (2) permitir somente coordenação local entre nós que estão próximos para que a largura de banda consumida na comunicação seja reduzida.
2.6 Redes de Sensores sem Fio - (RSSF) 33
No entanto, PEGASIS utiliza suposições que nem sempre são verdadeiras. Primeiro, PEGASIS assume que cada nó sensor está disponível para se comunicar com a estação base diretamente, em casos práticos, os nós sensores utilizam comunicação com múltiplos saltos para alcançar a estação base. Segundo, ele assume que todos os nós sensores mantém uma base de dados completa sobre a localização de todos os sensores da rede. Terceiro, ele assume que todos os nós sensores tem o mesmo nível de energia e provavelmente terão o esgotamento de energia ao mesmo tempo. Quarto, embora na maioria dos cenários os sensores são fixados ou imobilizados como assumido no PEGASIS, alguns sensores podem se mover e afetar a função deste protocolo.
Threshold-Sensitive Energy-Efficient Protocols (TEEN and APTEEN) No protocolo TEEN, os nós sensores sensoriam constantemente, mas a transmissão dos dados é feita com menos freqüência. Um sensor líder de agrupamento envia aos seus membros o limiar máximo do atributo sensoriado, e um outro limiar mínimo para a mudança de valor do atributo sensoriado que acionará o seu transmissor e transmitirá o dado capturado. Enquanto, o limiar máximo tenta reduzir o número de transmissões para permitir que os nós sensores transmitam somente dados dentro de valores de interesse, o limiar mínimo reduz o número de transmissões que poderiam ter acontecido quando pouco ou nenhuma mudança aconteceu no atributo sensoriado. Um valor menor para o limiar mínimo traz uma maior precisão à rede, às custas de um aumento no consumo de energia. A maior desvantagem deste protocolo é que se os limites não forem recebidos, os nós nunca irão se comunicar e os usuários nunca obterão nenhum dado da rede.
Já o APTEEN é um protocolo híbrido que muda a periodicidade do valor dos limiares usados no protocolo TEEN de acordo com a necessidade do usuário e o tipo da aplica-ção. No APTEEN, os líderes de agrupamento podem distribuir pela rede os seguintes parâmetros:
• Atributos: conjunto de atributos que o usuário tem interesse em obter informação;
• Limiares: valor máximo e mínimo;
• Escalonamento: escalonamento TDMA que determina um pedaço de tempo para cada nó;
• Contador de tempo: é o período de tempo máximo entre dois relatórios sucessivos enviados por um nó.
2.6 Redes de Sensores sem Fio - (RSSF) 34
A principal desvantagem deste esquema é a complexidade adicional requerida para implementar as funções de limiar e contador de tempo, porém através de simulações constatou-se que este protocolo teve uma performance melhor que o protocolo LEACH (ABDELZAHER et al., 2005).
2.6.3.3 Roteamento Adaptativo
Sensor Protocols for Information via Negotiation (SPIN) SPIN é uma família de protocolos adaptativos onde disseminam todas as informações de cada nó para todos os nós da rede, assumindo que todos são em potencial estações base. Esta abordagem permite ao usuário realizar consultas a qualquer nó e recuperar uma informação imediatamente. Estes protocolos fazem uso da propriedade que os nós próximos possuem dados similares e assim distribuem somente dados que outros nós não possuem. A família de protocolos SPIN usam algoritmos de negociação de dados e recursos adaptáveis.
Os nós que executam SPIN designam um nome de alto nível para descrever comple-tamente a sua coleção de dados (metadado) e realizam uma negociação de metadados antes de transmitirem os dados. Este protocolo assume que dados não redundantes são transmitidos por toda a rede. O formato do metadado é específico da aplicação e não é descrito no SPIN.
35
3
Sistemas Distribuídos
O aumento significativo de serviços Web, como: serviços de companhias aéreas, lo-cação de automóveis, serviços bancários, hospedagem em hotéis, sites de compras, etc. aliado ao crescente acesso a estes serviços por inúmeros usuários através da internet, sur-giu a necessidade de aumentar a capacidade de processamento para atender a demanda dos usuários, pois a capacidade de processamento pode impor restrições a muitos tipos de aplicações (DANTAS, 2005). Para resolver esta questão a idéia do processamento
dis-tribuído ou paralelo se tornou muito interessante, assumindo um papel muito importante no desempenho destas aplicações, onde a agregação de computadores locais (Clusters), ou geograficamente distribuídos (grid ) podem ser uma opção adequada para a melhoria no desempenho das aplicações distribuídas.
De acordo com a definição de (TANENBAUM; STEEN, 2002) "Um sistema distribuído é uma coleção de computadores independentes que se representa aos seus usuários como um sistema coerente único". Assim o seu principal objetivo, além de aumentar a capacidade de processamento para uma determinada aplicação, é facilitar o acesso remoto aos recursos e dividí-lo com outros usuários de uma forma controlada, como por exemplo: impressoras, arquivos, dados, computadores, páginas Web, etc.
Para (COULOURIS; DOLLIMORE; KINDBERG, 2001) dividir recursos é a principal moti-vação da construção de sistemas distribuídos, onde estes recursos podem ser gerenciados por servidores e acessados por diversos clientes em uma rede, mas as construções de siste-mas distribuídos resultam em desafios que devem ser superados como: heterogeneidade, flexibilidade, segurança, escalabilidade, tolerância à falha, concorrência e transparência.
• Heterogeneidade: os sistemas distribuídos são construídos em cima de diferentes redes e sistemas operacionais, hardware de computadores e linguagens de progra-mação;
• Flexibilidade: os sistemas distribuídos devem ser extensíveis para adição ou substi-tuição de componentes. A publicação de interfaces para estes componentes é uma
3.1 Arquiteturas Computacionais 36
boa prática para a sua integração, pois assim resolvemos a questão de componentes escritos por diferentes linguagens de programação;
• Segurança: encriptação pode ser usada para prover adequada proteção aos recursos compartilhados e manter informações secretas transmitidas pela rede;
• Escalabilidade: o sistema deve possuir a habilidade de aumentar a sua capacidade de atender as requisições de seus usuários;
• Tolerância à falha: habilidade do sistema em executar determinada tarefa solici-tada pelo usuário, independente de um computador de sua rede não estar operando apropriadamente;
• Concorrência: a presença de múltiplos usuários em um sistema distribuído é uma fonte de concorrência de requisições a estes recursos;
• Transparência: tornar invisíveis ao programador de aplicação certos detalhes do sistema distribuído para que eles tenham que se preocupar somente com a imple-mentação da sua aplicação.
3.1
Arquiteturas Computacionais
Atualmente a classificação de arquiteturas de computadores mais aceita é a taxonomia de Flynn, que classifica as arquiteturas de acordo com o número de instruções executadas em paralelo pelo conjunto de dados para os quais as instruções são submetidas (DANTAS, 2005). Esta taxonomia estabeleceu a seguinte classificação:
• SISD (Single Instruction Single Data): modelo tradicional de um único processador, cada instrução de um programa é executada uma por vez em cima de um único conjunto de dados.
• SIMD (Single Instruction Multiple Data): neste caso a instrução também é execu-tada uma por vez, mas ela é processada em cima de diferentes itens de dados, que são armazenadas por um hardware diferenciado do tipo vetor ou array.
• MISD (Multiple Instruction Single Data): múltiplas instruções sendo executadas em cima de um único conjunto de dados, não se tem conhecimento deste tipo de arquitetura.
3.1 Arquiteturas Computacionais 37
• MIMD (Multiple Instruction Multiple Data): múltiplas instruções sendo executadas em cima de múltiplos dados por meio de múltiplos processadores independentes. Esta arquitetura é apresentada com mais detalhes na subseção 3.1.1.
3.1.1
Arquiteturas MIMD
Todos os sistemas distribuídos consistem de múltiplos CPUs e dados (MIMD - Mul-tiple Instruction MulMul-tiple Data), sendo que existem diversas maneiras do hardware ser organizado, especialmente em termos de interconexão e como eles se comunicam. De uma forma geral, as arquiteturas MIMD podem ser classificas como multiprocessadores e multicomputadores, como apresentado na figura 9.
Figura 9: Classificação das arquiteturas MIMD (DANTAS, 2005)
3.1.1.1 Multiprocessadores
Esta arquitetura é considerada como uma arquitetura fortemente acoplada, pois os processadores e a memória são interligados por um sistema local de interconexão. Esta interconexão pode ser realizada através de um barramento compartilhado ou através de um equipamento de comutação, apresentando uma configuração compartilhada, conforme demonstrado na figura 10. Independente da forma de interconexão dos processadores e memória, a arquitetura multiprocessador é caracterizada pelo compartilhamento global da memória por todos os processadores.
3.1.1.2 Multicomputadores
Esta arquitetura por sua vez é fracamente acoplada, pois cada processador possui sua própria memória local. Não existe um compartilhamento forte, o que significa dizer
3.1 Arquiteturas Computacionais 38
Figura 10: Exemplos de configurações genéricas de multiprocessadores (DANTAS, 2005)
que a comunicação entre processos é realizada por meio de troca de mensagens. Os processadores podem estar conectados por um barramento ou um comutador conforme apresentado na figura 11.
Figura 11: Exemplos de configurações genéricas de multicomputadores (DANTAS, 2005)
São exemplos de arquiteturas MIMD com memória compartilhada Clusters e Grids Computacionais.
Clusters Esta arquitetura computacional pode ser entendida como uma agrega-ção/união de computadores de forma dedicada ou não, na execução de aplicações es-pecíficas de uma determinada organização. Os clusters ou agregados, são compostos em geral por computadores do tipo IBM-PC com disponibilidade de recursos (processadores,
3.2 Ambientes de Software 39
memórias e capacidade de armazenamento) pertencentes a uma única instituição (labora-tório, departamento, filial ou empresa). Os clusters devem possuir uma boa escalabilidade, pois a configuração pode crescer à medida que mais recursos são disponibilizados aos seus usuários.
Grids Computacionais A idéia dos Grids computacionais é a agregação massiva e disponibilização de recursos e serviços computacionais oriundos de inúmeros computado-res geograficamente distribuídos, os usuários fazem acesso ao ambiente através de uma interface única, sem a necessidade de conhecimento de onde os mesmos estão localizados.
3.2
Ambientes de Software
Para a correta execução de aplicações em sistemas computacionais distribuídos (clus-ters e grids), se faz necessário ambientes de software para o desenvolvimento destas aplicações. Como não existe uma taxonomia que seja amplamente reconhecida para a classificação dos ambientes de software, estaremos categorizando da seguinte maneira: Ambientes de programação, ferramentas e middlewares (DANTAS, 2005).
3.2.1
Ambientes de Programação
O desenvolvimento de aplicações em ambientes distribuídos e paralelos é mais com-plexo do que em ambientes centralizados, devido a utilização de recursos distribuídos. Esses ambientes devem levar em consideração aspectos como: acoplamento fraco entre computadores; possível diferença de largura de banda e o retardo de rede de comunicação entre o computador local e o remoto; a heterogeneidade em termos de hardware, sistemas operacionais e linguagens de programação; diferentes autoridades e políticas de segurança. Web Services, Parallel Virtual Machine (PVM) e Message Passing Interface (MPI) são exemplos de ambientes de programação representativos nas configurações distribuídas e paralelas.
3.2.1.1 Serviços Web
Serviços Web ou Web Services asseguram a interoperabilidade entre aplicações que estão executando sobre diferentes redes, plataformas de hardware e pacotes de software, transportando grande quantidade de dados entre distantes aplicações de forma eficiente e
3.2 Ambientes de Software 40
barata. Podemos dizer que o diferencial da abordagem de Serviços Web é a utilização de uma grande quantidade de padrões Web aceitos pela comunidade de tecnologia da infor-mação. Neste cenário, onde todas as aplicações são implementadas empregando técnicas padronizadas de desenvolvimento baseadas em componentes e padrões Web, permite um crescimento da tendência das arquiteturas orientadas a serviços (SOA - Service Oriented architecture), que será visto com mais detalhes na seção 3.3.
Os padrões de serviços Web definem o formato da mensagem, especificam a inter-face na qual a mensagem é enviada, descrevem as convenções para mapear os conteúdos da mensagem, e definem o mecanismo de publicação e descoberta de interfaces dos ser-viços Web (NEWCOMER, 2002). Serviços Web provem uma abordagem de computação distribuída porque conecta aplicações heterogêneas sobre a internet. As especificações dos serviços Web são independentes de linguagens de programação, sistemas operacionais e hardware promovendo baixo acoplamento entre provedores e consumidores de servi-ços (ENDREI et al., 2004). A comunicação de serviços Web entre aplicações é dada pelo envio/requisição de uma mensagem no formato XML através de uma rede, a aplicação destino por sua vez recebe a requisição e devolve a resposta também no formato XML, de acordo com o protocolo de comunicação SOAP.
Na figura 12 apresentamos a arquitetura de Serviços Web e observamos três importan-tes papéis: o provedor do serviço que implementa e disponibiliza o serviço na Internet, o consumidor do serviço que utiliza um serviço Web existente, abrindo uma conexão de rede e enviando um pedido no formato XML e o registro de serviço que fornece um lugar cen-tral onde desenvolvedores podem publicar novos serviços ou encontrar serviços existentes (CERAMI, 2002).
Serviços Web são baseados nos padrões abertos XML(Extensible Markup Language), SOAP(Simple Object Access Protocol ), UDDI(Universal Description, Discovery and In-tegration) e WSDL(Web Services Description Language), que serão descritos a seguir:
XML - eXtensible Markup Language O XML é representado por um conjunto de especificações publicadas pelo Consórcio de World Wide Web (http://www.w3.org/ XML), é similar ao HTML, possui elementos, atributos e valores, mas os seus objetivos são diferentes, o XML foi projetado para transportar e armazenar dados e o HTML foi projetado para mostrar dados. O HTML possui um conjunto finito de elementos e atributos e o XML permite a definição de qualquer número de elementos e atributos. De uma forma geral o HTML mostra a informação, enquanto do XML transporta a
3.2 Ambientes de Software 41
Figura 12: Arquitetura de Serviços Web (ENDREI et al., 2004)
informação.
O XML é usado em serviços Web para especificar genericamente a representação dos dados, a qualidade de serviço no qual os dados serão transmitidos, e os detalhes de como os serviços serão publicados e descobertos (NEWCOMER, 2002). O exemplo 13 demonstra como podemos representar os dados de um cliente utilizando a linguagem XML, no exemplo 14 apresentamos o esquema XML que será utilizado pela aplicação para a validação dos dados informados.
Figura 13: Exemplo XML
SOAP - Simple Object Access Protocol SOAP é um protocolo leve que permite a troca de mensagens XML sobre o protocolo HTTP, permitindo a transmissão de dados em serviços Web. A correta manipulação das mensagens trocadas é realizada por um servidor Web com um processador SOAP, como o Apache Axis ou o IIS da Microsoft.
3.2 Ambientes de Software 42
Figura 14: Exemplo de esquema XML
independente de plataforma e linguagem. Por exemplo, um cliente SOAP Java rodando em um computador Linux ou um cliente Perl rodando em um Solaris podem conectar em um servidor SOAP Microsoft rodando em Windows 2000. O protocolo SOAP é fundamental para a arquitetura de serviços Web, pois possibilita diversas aplicações trocarem de forma fácil e transparente dados e serviços (CERAMI, 2002).
A mensagem SOAP possui três partes principais, o envelope, o header e o body, con-forme apresentado na figura 15.
O envelope é obrigatório e marca o início e o fim da mensagem SOAP, nele definimos regras específicas de encapsulamento dos dados que serão transferidos entre computadores. O header é a parte opcional da mensagem, e pode conter um ou mais blocos de informações de como as mensagens devem ser processadas. No header pode ser transmitido atributos da mensagem como: tokens de segurança, identificadores de transação, etc. ou definições de qualidade de serviço das mensagens. O body também é obrigatório e contém um ou mais blocos que compreendem as mensagens transmitidas (NEWCOMER, 2002). Maiores detalhes sobre a especificação do protocolo SOAP podem ser encontrados em http:// www.w3.org/TR/soap.
A figura 16 nos mostra o fluxo de mensagens de uma aplicação cujo objetivo é informar a temperatura de um determinado local. XMethods.net fornece um serviço de tempo, disponibilizando a temperatura de um determinado lugar de acordo com o seu código
3.2 Ambientes de Software 43
Figura 15: Composição da mensagem SOAP (NEWCOMER, 2002)
postal. O método getTemp implementa o serviço, que por sua vez solicita um código postal como parâmetro e retorna um valor de ponto flutuante que corresponderá à temperatura do local.
Figura 16: Mensagem SOAP (CERAMI, 2002)
A mensagem de requisição do serviço é apresentada na figura 17.
No exemplo apresentado observamos o elemento obrigatório Envelope que contém o também elemento obrigatório Body. Neste exemplo de requisição SOAP, foi utili-zado namespaces XML para não haver ambigüidade de identificadores associados ao En-velope SOAP (http://schemas.xmlsoap.org/soap/enEn-velope/), à codificação dos da-dos via esquema XML (http://www.w3.org/2001/XMLSchema-instance e http://www. w3.org/2001/XMLSchema), e aos identificadores de aplicação XMethods
(urn:xmethods-3.2 Ambientes de Software 44
Figura 17: Mensagem de requisição SOAP (CERAMI, 2002)
Temperature).
O único elemento do elemento Body deste exemplo é o getTemp definido no namespace XMethods, e corresponde ao nome do método remoto. O parâmetro zip code aparece como um sub-elemento do método remoto definido no esquema XML como um tipo de dado xsd:string e lhe é atribuído o valor 10016.
A mensagem de resposta do método remoto getTemp é apresentada na figura 18.
Figura 18: Mensagem de resposta SOAP (CERAMI, 2002)
De acordo com a mensagem SOAP de requisição, a mensagem de resposta contém os mesmos elementos Envelope e Body e os mesmos namespaces XML. O elemento Body possui somente o elemento getTempResponse e possui um elemento de retorno do tipo de dado xsd:float. De acordo com o exemplo apresentado, a temperatura do código postal 10016 é 71 graus Fahrenheit.
WSDL - Web Service Description Language WSDL é uma linguagem de descrição extensível e foi desenvolvida inicialmente pela Microsoft e a IBM e depois submetida ao
3.2 Ambientes de Software 45
consórcio W3C por 25 empresas, tornando-se um padrão baseado em documentos XML para descrever interfaces de serviços Web. O WSDL pode ser visto como um contrato entre o consumidor e o provedor do serviço, pois ambos compartilham as mesmas regras de comunicação e acesso aos serviços disponibilizados. Como o remetente e o destinatário da mensagem podem dividir um mesmo arquivo WSDL e entendê-lo da mesma forma, então podemos afirmar que existe interoperabilidade entre as aplicações (NEWCOMER, 2002).
A especificação do WSDL 1.1 contém seis principais partes, que estão descritas a seguir:
• definitions: elemento raiz que deve estar presente em todos os documentos WSDL, aqui definimos o nome do serviço Web, os namespaces que serão utilizados ao longo do documento e a descrição de todos os elementos de serviços;
• types: descreve todos os tipos de dados usados entre as mensagens cliente e servidor;
• message: descreve a mensagem de requisição ou de resposta. Neste elemento infor-mamos o nome da mensagem e pode conter zero ou mais elementos que representam mensagens de parâmetro ou de valor de retorno;
• portType: é a combinação de elementos message de requisição e resposta dentro de uma única operação, nesta parte do documento descrevemos a interface dos serviços. Este elemento pode conter uma ou mais operações com os parâmetros de input e output ;
• binding: descreve a especificação, protocolo e formato, das operações dos serviços Web disponibilizados;
• service: define o endereço físico (URL, endereço) onde o serviço Web estará dispo-nível.
A especificação WSDL também define os elementos documentation e import. O ele-mento documentation pode estar dentro de cada eleele-mento e seu objetivo é descrever de forma clara os elementos que fazem parte do documento WSDL. O elemento import tem como objetivo importar outros documento WSDL ou esquemas XML, tornando possível a modularização do documento WSDL.
No anexo A apresentamos um exemplo de documento WSDL 1.1 que define um serviço chamado CustomerService, no qual fornece uma operação chamada getCustomerAddress(),
3.2 Ambientes de Software 46
um parâmetro de entrada customer ID do tipo long e uma estrutura de retorno com três atributos do tipo string: rua, cidade e codigoPostal.
Pelo fato do WSDL não conter informação semântica, podemos dizer que ele não está apto a gerenciar um contrato de serviço. WSDL simplesmente é um formato que especifica aspectos técnicos para requisitar serviços. WSDL também possui deficiências nos atributos dos serviços, como por exemplo, a inexistência de atributos não funcionais e atributos de acordo de nível de serviço. O WSDL não especifica por quanto tempo o serviço estará ativo, quem tem permissão para invocar o serviço, quanto custa a requisição do serviço, etc. Estes aspectos são muito importantes em um cenário SOA (Service Oriented Arquitecture), que serão disponibilizados nas versões futuras do WSDL, como por exemplo, o WSDL 2.0 que já possui a possibilidade de extender arquivos WSDL (JOSUTTIS, 2007).
UDDI - Universal Description, Discovery, and Integration UDDI é uma es-pecificação técnica utilizada para gerenciar serviços Web, que descreve, descobre e integra os serviços Web. O UDDI pode ser representado pela figura 19, que na maioria das vezes é utilizada para representar serviços Web. O UDDI especifica um modo de fornecer e recuperar informações sobre: os serviços Web, o provedor do serviços, e as interfaces dos serviços.
Figura 19: Estrutura UDDI - Provedor, consumidor e intermediador (JOSUTTIS, 2007)
UDDI não é a única opção para descoberta de serviços. A IBM e a Microsoft anun-ciaram em 2001 a WS-Inspection: Web Service Inspection Language, uma linguagem ba-seada em XML que fornece um índice de todos os serviços Web com sua localização Web (TIDWELL; SNELL; KULCHENKO, 2001). Como não faz parte do escopo deste trabalho detalhar sobre a descoberta de serviços, abordaremos somente a especificação UDDI.
