• Nenhum resultado encontrado

SOA-RSSF: UMA ARQUITETURA ORIENTADA A SERVIÇOS (SOA) PARA APLICAÇÕES DE REDE DE SENSORES SEM FIO (RSSF)

N/A
N/A
Protected

Academic year: 2021

Share "SOA-RSSF: UMA ARQUITETURA ORIENTADA A SERVIÇOS (SOA) PARA APLICAÇÕES DE REDE DE SENSORES SEM FIO (RSSF)"

Copied!
11
0
0

Texto

(1)

SOA-RSSF: UMA ARQUITETURA ORIENTADA A SERVIÇOS

(SOA) PARA APLICAÇÕES DE REDE DE SENSORES SEM FIO

(RSSF)

Cristina Orthmann da Silva* Mario A. R. Dantas** R E S U M O

Aplicações utilizando Redes de Sensores Sem Fio (RSSF) têm crescido consideravel-mente, despertando o interesse de pesquisadores, e como consequência, muitos tra-balhos interessantes resultam de pesquisas realizadas nesses ambientes. Contudo, aplicações desenvolvidas para essas redes são geralmente fortemente acopladas às configurações do sensor, impedindo outras aplicações acessarem facilmente as infor-mações criadas dentro de uma RSSF. No sentido de resolver a limitação ao acesso às informações geradas e uma RSSF, neste artigo apresentamos uma proposta chamada SOA-RSSF. A proposta foi concebida baseada no paradigma Service Oriented Archi-tecture (SOA) que provê a aplicações, independente de plataforma e linguagem de programação, acessar os dados de uma RSSF. A fim de verificar o ambiente proposto, alguns casos de estudo foram desenvolvidos e esses indicam que os objetivos foram alcançados com sucesso.

Palavras-chave: SOA. Web Services. Rede de sensores sem fio. Introdução

Redes de Sensores Sem Fio (RSSF) são redes móveis Ad-hoc compostas por sensores distribuídos randomicamente, ou de acordo com alguma estratégia de im-plantação, que tem como objetivo monitorar um determinado ambiente. As RSSFs são caracterizadas por possuírem um grande número de nodos, limitações de processa-mento e de energia e por não possuírem uma identificação global. Apesar das suas limitações, quando executam tarefas colaborativamente são muito eficientes. Contu-do, a heterogeneidade entre redes e o alto acoplamento das aplicações fazem com que o acesso às informações seja uma tarefa difícil.

* Graduada em Sistemas de Informação (UFSC), Gerente de Projetos na EDM Tecnologia Ltda., Florianópolis – SC, crisorth@gmail.com

** Doutor em Ciência da Computação (University of Southampton), professor no Departamento de Informática e Estatística (INE/UFSC) e no Programa de Pós-Graduação em Engenharia e Gestão do Conhecimento (EGC/UFSC), Florianópolis-SC, mario@inf.ufsc.br

(2)

Este trabalho apresenta uma proposta no sentido de promover a flexibilidade e a interoperabilidade entre aplicações de redes de sensores sem fio, utilizando a arquitetura orientada a serviços (SOA). Com a arquitetura proposta, denominada Service Oriented Architecture - Redes de Sensores Sem Fio (SOA-RSSF), os dados gerados por uma determinada rede serão disponibilizados para qualquer aplicação da organização 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.

Este artigo está organizado da seguinte forma. Na seção seguinte apresenta-mos uma breve revisão teórica sobre as redes de sensores sem fio. Em seguida, apre-sentamos, respectivamente, o paradigma SOA, trabalhos correlatos e o detalhamento da proposta SOA-RSSF. Finalmente, apresentamos os resultados experimentais, con-clusões e trabalhos futuros.

Rede de sensores sem fio

Com o avanço de tecnologias, tais como de microssensores, comunicação sem fio, redes Ad-hoc e processamento embarcado, 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 caracterizados por seu baixo custo, poder de processamento e comunicação, além do consumo de energia da que se comunicam utilizando um canal de rádio frequência. Apesar dessas limita-ções apresentadas por Akyildiz et al. (2002), quando os sensores trabalham coope-rativamente em uma rede são muito eficientes. As características básicas de uma RSSF são:

- Capacidade de auto-organização;

- Comunicação broadcast e roteamento por múltiplos saltos; - Agregação de dados;

- Mobilidade dos nodos sensores;

- Implantação densa e esforço cooperativo dos nodos sensores; - Frequente 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.

Arquitetura de rede de sensores sem fio

Conforme ilustra a figura 1, uma rede de sensores sem fio é composta basicamen-te de sensores, agregadores, sink e gabasicamen-teways. Os sensores capturam dados de uma região de interesse, os agregadores são representantes lógicos de uma região que agre-gam/sumarizam os dados desta região. Os sinks coletam os dados de todos os sensores e/ou agregadores, e interagem 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., 2007a).

(3)

Figura 1: Arquitetura RSSF convencional. Fonte: Othman et al. (2007a, p. 865). SOA - Service Oriented Architecture

A Arquitetura Orientada a Serviços (SOA) possui uma interessante abordagem para construção de sistemas distribuídos e vem para atender a nova tendência de um mercado ágil e flexível. O paradigma SOA vem resolver a lacuna existente entre o negócio e a tecnologia de informação (TI), principalmente no sentido semântico, onde as pessoas de negócio e de TI aparentemente falam e pensam em linguagens totalmen-te diferentotalmen-tes. O objetivo do SOA é estruturar grandes sistotalmen-temas distribuídos baseados nas abstrações de regras e funções de negócios. A proposta SOA aceita, de uma forma única, manter a flexibilidade em grandes sistemas distribuídos, suportar a heterogenei-dade, a descentralização e a tolerância à falha. A arquitetura orientada a serviços é um paradigma, é uma nova forma de pensar e desenvolver sistemas (JOSUTTIS, 2007).

Conforme Oasis (2006), SOA é definido como sendo “Um paradigma para orga-nização e utilização de competências distribuídas que estão sob controle de diferentes domínios proprietários”. Para que seja possível a interação entre os serviços que implementam as competências e necessidades das entidades é necessária a colabora-ção, conforme apresentamos na figura 2.

Figura 2: Arquitetura de colaboração SOA. Fonte: Endrei et al. (2004, p. 26).

(4)

Nesta arquitetura observamos três serviços: 1) consumidor: aplicação ou outro serviço que necessita de um serviço e o executa de acordo com o contrato de interface; 2) provedor: entidade que aceita e executa as requisições dos consumidores, publica seus serviços e os registram por meio de um contrato de interface; e 3) registro: contém um repositório de serviço no qual permite a procura por eles.

A colaboração entre esses serviços segue o paradigma de encontrar, conectar

e invocar. Neste o consumidor realiza uma localização dinâmica do serviço

requisita-do, publicado anteriormente por um provedor. Essa localização é realizada por meio de consulta no serviço de registro e, depois de encontrado, o consumidor conecta e invoca o serviço solicitado (ENDREI et al., 2004).

Enterprise Service Bus (ESB)

Serviço Web é uma das bases fundamentais para a implementação de um siste-ma baseado no paradigsiste-ma SOA. Todavia, para utilizar esse recurso existem importan-tes considerações que afetam a flexibilidade e a manutenção de uma solução SOA. Primeira, a natureza básica de conexão ponto-a-ponto dos serviços Web, significa que o consumidor do serviço terá que ser alterado quando a interface do serviço provedor houver mudança. Segunda, a arquitetura pode se tornar frágil e inflexível quando um grande número de consumidores e provedores se conectarem ponto-a-ponto. Tercei-ra, o consumidor, que necessitar de um adaptador de protocolo apropriado de cada provedor de serviço, trará como consequência a necessidade de publicar múltiplos adaptadores de protocolo, através de muitas aplicações clientes, incrementando os custos e a manutenção do sistema. Pelas razões expostas, é que o ESB é uma aborda-gem utilizada em soluções SOA para resolver essas questões (ENDREI et al., 2004). Suas principais responsabilidades são:

- Prover conectividade entre o consumidor e o provedor;

- Transformar, quando necessário, os formatos das mensagens entre o consu-midor e o provedor;

- Converter protocolos de transporte entre o consumidor e o provedor; - Realizar o correto roteamento da requisição do consumidor ao provedor do serviço.

Como observamos, ESB não é um produto, mas uma boa prática para implemen-tar arquiteturas orientadas a serviços. A figura 3 ilustra a arquitetura ESB (JOSUTTIS, 2007) que possibilita a interoperabilidade e o baixo acoplamento entre os serviços.

Neste esquema, os interceptores possuem a responsabilidade de conectar di-namicamente o consumidor e o provedor do serviço, consultando o serviço no servi-dor Universal Description, Discovery and Integration (UDDI).

(5)

Figura 3: Enterprise Service Bus (JOSUTTIS, 2007, p. 53).

Trabalhos correlatos

Nesta seção, apresentamos alguns trabalhos relacionados que serviram como base para a implementação da arquitetura do SOA-RSSF. Observamos que a proposta SOA-RSSF contribui para deixar esses projetos mais flexíveis com a inclusão da cama-da ESB-RSSF.

Os trabalhos de Delicato et al. (2003) e Othman et al. (2007b) propõem uma arquitetura flexível baseada em serviços Web na RSSF. Em ambos, a comunicação entre os sensores é realizada por meio do protocolo SOAP. A principal diferença entre esses trabalhos é que Delicato et al. (2003) propõe a utilização do nodo sink para disponibilizar os serviços Web. Por outro lado, a proposta encontrada em Othman et al. (2007b) indica que a comunicação do serviço Web é realizada diretamente em cada nó da rede, nesta proposta não existe o papel do nodo sink.

No trabalho desenvolvido por Ferreira et al. (2007) foi implementado uma apli-cação MAD-RSSF, que trabalha diretamente com uma rede de sensores. O trabalho de pesquisa de Ferreira et al. (2007) utiliza um cluster para processar o grande volume de dados gerados pela rede e um sistema de alerta para PDA, caso receba algum valor fora de uma faixa de valores pré-determinada.

Abordagem proposta e resultados experimentais

Redes de sensores sem fio disponibilizam inúmeros dados sobre o ambiente que estão monitorando e desses dados podemos extrair informações por meio de

(6)

aplicações dedicadas, isto é, aplicações que foram desenvolvidas especificamente para aquela rede de sensores. Esta é uma descrição de um ambiente fortemente acopla-do, pois para que outras aplicações tenham acesso aos dados, será necessário o desenvolvimento de um software para capturar os dados da rede para cada diferente aplicação.

Para que todas as aplicações, independentes de plataforma e linguagem de programação, possam ter acesso a esses dados de forma flexível, podemos desenvol-ver um ambiente de software, onde os dados da rede são disponibilizados por meio de serviços Web. Serviços Web são implementados baseados em padrões da Internet e são aceitos por qualquer linguagem e/ou plataforma. A utilização do paradigma

Servi-ce Oriented Arquitecture (SOA) neste trabalho é uma boa contribuição para

aplica-ções direcionadas às redes de sensores (DELICATO et al., 2003). Arquitetura SOA-RSSF

A contribuição deste trabalho está na proposta de desenvolver uma solução utilizando o paradigma SOA para tornar transparente e flexível a comunicação entre os consumidores dos serviços e os dados disponíveis pela RSSF. Na figura 4 apresenta-mos a arquitetura SOA-RSSF proposta, composta por quatro módulos/aplicações, descritas a seguir.

(7)

- TinyOS RSSF: responsável pelas aplicações instaladas na rede. As aplica-ções instaladas nos nodos sensores tem como objetivo capturar os dados solicitados e enviá-los para o nó base sink, e a aplicação do nó sink possui a responsabilidade de disponibilizar os dados ao terminal/computador via serial ou USB.

- Gerenciador de dados RSSF: acessa as informações disponibilizadas pela rede de sensores e grava cada dado em um banco de dados para futura análise; - Provedor de serviços RSSF: possui todas as regras de negócio necessárias

para a transformação dos dados gravados no banco de dados em informa-ções. Neste mesmo módulo, estas informações serão disponibilizadas na for-ma de serviços para a aplicação ESB-RSSF;

- Enterprise Service Bus (ESB-RSSF): esta aplicação é responsável pelo link entre a requisição da aplicação cliente, consumidor do serviço, e o provedor do serviço, que neste caso é representado pelo módulo “Provedor de servi-ços RSSF”.

Resultados experimentais

Os experimentos realizados com o protótipo da arquitetura SOA-RSSF foram divididos em três fases. Na primeira fase realizamos experimentos com os módulos TinyOs RSSF e o Gerenciador de Dados RSSF. Todas as leituras recebidas da RSSF e capturadas pela aplicação Gerenciador de Dados RSSF foram armazenadas no banco de dados PostgreSQL. A figura 5 ilustra a aplicação Gerenciador de Dados RSSF que recebe as leituras da RSSF, e a figura 6 apresenta os dados gravados no banco de dados.

(8)

Figura 6. Leituras RSSF gravadas no banco de dados.

Na segunda fase dos experimentos, os dados recebidos e gravados na base de dados foram convertidos em informação pela aplicação Provedor de Serviços RSSF. Toda a aplicação foi publicada no servidor Web Apache TomCat e o processador SOAP Axis ficou encarregado de disponibilizar os serviços Web. O WSDL, apresenta-do na figura 7, é o resultaapresenta-do dessa segunda fase. De posse apresenta-do WSDL, qualquer aplicação pode consumir os serviços e ter acesso às informações geradas pela RSSF.

(9)

Nesta terceira e última fase registramos o WSDL do serviço ServiçosRSSF no servidor jUDDI, por meio do console disponibilizado pela ferramenta jUDDI, conforme figura 8. Após o registro dos serviços da aplicação Provedor de Serviços RSSF, publi-camos os serviços da aplicação ESB-RSSF, da mesma forma como foi apresentada anteriormente. A aplicação ESB-RSSF, por intermédio da biblioteca UDDI4J da IBM, acessou os serviços da aplicação Provedor de Serviços RSSF dinamicamente, captu-rando o endereço do WSDL dos serviços no servidor UDDI.

Para verificarmos o funcionamento do protótipo da arquitetura SOA-RSSF, desenvolvemos a aplicação denominada “Teste Cliente”, apresentada na figura 9. A aplicação acessa os serviços Web da aplicação Provedor de Serviços RSSF através da aplicação ESB-RSSF.

Figura 8: Console jUDDI para registro de serviços.

(10)

Conclusões e trabalhos futuros

Aplicações que utilizam dados providos por uma RSSF possuem a limitação de serem altamente acopladas a essas redes. Assim, neste trabalho, apresentamos uma arquitetura orientada a serviços (SOA) para redes de sensores sem fio (SOA-RSSF) e desenvolvemos um protótipo para essa arquitetura. O principal objetivo da SOA-RSSF é a integração de serviços relacionados à SOA-RSSF a aplicações através de serviços Web.

Após o completo desenvolvimento do protótipo da arquitetura SOA-RSSF proposta, foram realizados diversos experimentos com sucesso, onde podemos con-cluir que apesar de ser um grande desafio integrar um ambiente SOA a uma rede de sensores sem fio, a solução SOA-RSSF mostrou-se bastante interessante para tornar mais flexíveis as aplicações em RSSF.

Como pesquisas futuras, estamos trabalhando nas seguintes linhas: o desen-volvimento de um framework para facilitar a integração dos provedores de serviços Web na camada ESB; uma interface para publicação de serviços no servidor UDDI, pois neste projeto utilizamos o console disponível pela aplicação jUDDI; uma ontolo-gia para descrever os serviços Web relativos à rede de sensores para a consulta de serviços no servidor UDDI; disponibilizar serviços que interajam direto com a rede de sensores, por meio de uma aplicação ESB.

ABSTRACT

RSSF-SOA: A SERVICE ORIENTED ARCHITECTURE (SOA) FOR WIRELESS SENSOR NETWORKS APPLICATIONS (RSSF)

It has been verified that applications using the wireless sensor networks (WSN) have grown considerably, therefore many interesting results come from these environments. However, applications developed for these networks, are usually highly coupled to sensor configurations, preventing other applications to access easily information created inside a WSN. To solve the limitation to access the information generated and a RSSF, we present a proposal on this paper called as SOA-RSSF. The proposal was conceived based on the SOA (Service Oriented Architecture) paradigm which provides the applications, independent of platforms and programming language to access the data from a RSSF. In order to verify the proposed environment, some case studies were developed and then indicate that goals have been achieved successfully.

Keywords: SOA. Web Services. Wireless sensor network. REFERÊNCIAS

AKYILDIZ, I. F. et al. A survey on sensor networks, IEEE Communication

(11)

DELICATO, F. C. et al. A flexible web service based architecture for wireless sensor networks. In: INTERNATIONAL CONFERENCE ON DISTRIBUTED COMPUTING SYSTEMS WORKSHOPS, 23., 2003, Rhode Island. Analls… Rhode Island: [s.n.], 2003. p. 730–735.

ENDREI, M. et al. Patterns: Service-Oriented Architecture and Web Services, 2004. Disponível em: <http://www.redbooks.ibm.com>. Acesso em: 23 dez. 2009.

FERREIRA, D. J. et al. A middleware for oscar and wireless sensor network environments. In: INTERNATIONAL SYMPOSIUM ON HIGH PERFORMANCE COMPUTING SYSTEMS AND APPLICATIONS, 21., 2007, Saskatoon. Proceedings

of a meeting… Saskatoon: [s. n.], 2007. p. 24.

JOSUTTIS, N. M. SOA in Practice, O’Reilly. [S.l.:s.n], 2007.

OASIS, C. Reference model for service oriented architecture 1.0. [S.l.: s.n], 2006. Technical Report.

OTHMAN, N. Y. et al. A web services-based architecture for the interactions between end-user applications and sink-less wireless sensor networks. In: IEEE CONSUMER COMMUNICATIONS AND NETWORKING CONFERENCE, 4., 2007.

Analls… [S.l.: s.n.], 2007a. p. 865–869.

OTHMAN, N. Y. et al. The design and implementation of a web service framework for individual nodes in sink-less wireless sensor networks. IEEE Symposium on

Referências

Documentos relacionados

Para tanto se buscou um processo que possibilitasse de forma ordenada um diálogo entre os diferentes métodos de análise do objeto de estudo, estando entre eles às

O índice da quantidade de dias úmidos por ano (R1mm) mostrou uma tendência com significância estatística para redução apenas nas regiões 2 (norte da BA e Estado de SE) e 4;

Ou seja, no caso de Florianópolis como também mostra a Figura 53, todas essas áreas de bacias cicloviárias correspondem a integração da malha urbana, assim é possível propor

O ambiente em estudo foi parte do LAVSI, que possuía dois aparelhos de ar condicionado, dois módulos MeshBean atuando como sensores de tempertatura, dois módulos MeshBean

expansão do sistema ou para o pro jeto de um iruito de ontrole de potênia om até 64 níveis. A seleção do anal de omuniação é feita através de um registrador de 8 bits

A resposta é que neste modelo de regressão será levado em conta o componente espacial, pois todos os cálculos tomarão como referencia a área sem floresta dos

Caso os nós sensores sugeridos pelo ADRIX sejam compostos por módulos não comerciais, o projetista terá a opção de implementá-los seguindo o fluxo de projeto ASIC com as

-técnicos da administração ambiental -soluções mistas SELECÇÃO DE ACÇÕES DEFINIÇÃO DO ÂMBITO PREPARAÇÃO DO EIA APRECIAÇÃO TÉCNICA DECISÃO PÓS-AVALIAÇÃO I