• 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 e Mario A.R. Dantas

Departamento de Informática e Estatística – Universidade Federal de Santa Catarina Trindade - 88040-970 - Florianópolis - SC - Brazil

{crisorth,mario}@inf.ufsc.br

Abstract. It has been verified that applications utilizing wireless sensors

networks (WSN) have grown considerably, therefore many interesting results arise 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. As a result, in this paper we present a proposal called as SOA-RSSF. The proposal was conceived based on the SOA (Service Oriented Architecture) paradigm to provide to applications, from independent platforms or programming language, access to data from a WSN. In order to verify the proposed environment, some case studies were developed and these indicate that goals have been achieved successfully.

Resumo.Tem-se verificado que aplicações utilizando redes de sensores sem fio

(RSSF) têm crescido consideravelmente, por isso muitos resultados interessantes resultam desses ambientes. Contudo, aplicações desenvolvidas para estas redes, são geralmente fortemente acopladas às configurações do sensor, impedindo outras aplicações acessarem facilmente as informações criadas dentro de uma RSSF. Como resultado, neste artigo apresentamos uma proposta chamada SOA-RSSF. A proposta foi concebida baseada no paradima SOA (Service Oriented Architecture) que provê à 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.

1. 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 implantação, que tem como objetivo monitorar um determinado ambiente. As RSSFs são caracterizadas por possuem um grande número de nodos, limitações de processamento e de energia e não possuir uma identificação global. Apesar das suas limitações, quando executam tarefas colaborativamente são muito eficientes.

(2)

Contudo, a heterogeneidade entre redes e o alto acoplamento das aplicações fazem com que o acesso às informações seja uma tarefa difícil. Desta forma, este trabalho se propõe a apresentar uma proposta no sentido da promoção da flexibilidade e a interoperabilidade entre aplicações de redes de sensores sem fio, utilizando a arquitetura orientada a serviços (SOA). Com a proposta desta arquitetura, denominada de SOA-RSSF (Service Oriented Architecture- Redes de Sensores Sem Fio), 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 maneira. Na seção 2 apresentamos uma breve revisão teórica sobre as redes de sensores sem fio. O paradigma SOA é apresentado na seção 3. Na seção 4 abordamos os trabalhos relacionados a esta pesquisa. O detalhamento da proposta SOA-RSSF é efetuado na seção 5, aonde também são apresentados os resultados experimentais. Finalizando esse artigo, a seção 6 apresenta conclusões sobre a proposta e sugestões para trabalhos futuros.

2. Rede de Sensores sem Fio

Com o avanço de tecnologias tais como de micro sensores, 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 limitada que se comunicam utilizando um canal de rádio freqüência. Apesar das conhecidas limitações, quando os sensores trabalham cooperativamente 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;  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.

(3)

2.1. Arquitetura de Rede de Sensores sem Fio

Uma rede de sensores sem fio é composta basicamente de sensores, agregadores, sink e gateways. Os sensores capturam dados de uma região de interesse, os agregadores são representantes lógicos de uma região que agregam/sumarizam os dados desta região. Os 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. 2007a], conforme apresentamos na figura 1.

Figura 1: Arquitetura RSSF convencional [Othman et al. 2007a]

3. 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 totalmente diferentes. O objetivo do SOA é estruturar grandes sistemas 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 heterogeneidade, 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].

Em [OASIS 2006] existe uma definição de SOA como sendo:

"Um paradigma para organizaçã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ário a colaboração, conforme apresentamos na figura 2. 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, este publica seus serviços e os registra por meio de um contrato de interface; e 3) registro: contém um repositório de serviço no qual permite a procura destes. A colaboração entre

(4)

estes serviços segue o paradigma de encontrar, conectar e invocar. Neste o consumidor realiza uma localização dinâmica do serviço requisitado, publicado anteriormente por um provedor. Esta 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].

(5)

3.1. Enterprise Service Bus - (ESB)

Serviço Web é uma das bases fundamentais para a implementação de um sistema baseado no paradigma SOA. Todavia, para utilizar este recurso existem importantes considerações que afetam a flexibilidade e a manutenção de uma solução SOA. Primeiro, 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. A próxima observação é que a arquitetura pode se tornar frágil e inflexível quando um grande número de consumidores e provedores se conectam ponto-a-ponto. Finalmente, o consumidor que necessitar de um adaptador de protocolo apropriado de cada provedor de serviço, trará como conseqüê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. Pela razões expostas, é que o ESB é uma abordagem utilizada em soluções SOA para resolver estas 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 consumidor 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 implementar arquiteturas orientadas à serviços. Na figura 3 apresentamos a arquitetura ESB que possibilita a interoperabilidade e o baixo acoplamento entre os serviços. Neste esquema, os interceptores possuem a responsabilidade de conectar dinamicamente o consumidor e o provedor do serviço, consultando o serviço no servidor UDDI.

(6)

4. Trabalhos Relacionados

Nas pesquisas realizadas para o desenvolvimento deste projeto encontramos alguns trabalhos relacionados que serão discutidos nesta seção, sendo que todos foram utilizados como base para a implementação da arquitetura do RSSF. Observamos que a proposta SOA-RSSF contribui para deixar estes projetos mais flexíveis com a inclusão da camada 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 este 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.

O trabalho MAD-RSSF, desenvolvido por [D. J. Ferreira et al. 2007], é outro trabalho relacionado, onde foi implementado uma aplicação que trabalha diretamente com uma rede de sensores. Este trabalho de pesquisa 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.

5. Abordagem Proposta e Resultados Experi mentais

Redes de sensores sem fio disponibilizam inúmeros dados sobre o ambiente que estão monitorando e destes dados podemos extrair informações por meio de aplicações dedicadas, isto é, aplicações que foram desenvolvidas especificamente para aquela rede de sensores. Esta é uma descrição de um ambiente fortemente acoplado, 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 estes dados de forma flexível, podemos desenvolver 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 SOA (Service Oriented Arquitecture) neste trabalho é uma boa contribuição para aplicações direcionadas às redes de sensores [Delicato et al. 2003].

5.1. SOA-RSSF Arquitetura

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.

(7)

Na figura 4 apresentamos a arquitetura SOA-RSSF, sendo composta por quatro módulos/aplicações, que são descritas a seguir:

 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 forma de serviços para a aplicação ESB-RSSF;

 ESB-RSSF (Enterprise Service Bus): 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".

(8)

5.2. 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, sendo que todas as leituras recebidas da RSSF e capturadas pela aplicação Gerenciador de Dados RSSF foram armazenadas no banco de dados PostgreSQL.

Figura 5. Leituras da RSSF recebidas pelo Gerenciador de Dados RSSF

Apresentamos na figura 5, a aplicação Gerenciador de Dados RSSF que recebe as leituras da RSSF e na figura 6 os dados gravados no banco de dados.

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 apresentado na figura 7 é o resultado desta segunda fase, de posse deste WSDL qualquer aplicação pode consumir os serviços e ter acesso as informações geradas pela RSSF.

(9)

Figura 7. WSDL ServicosRSSF

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, publicamos 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, capturando o endereço do WSDL dos serviços no servidor UDDI.

(10)

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

Figura 9. Aplicação teste para acessar ESB-RSSF

6. Conclusões e Trabalhos Futuros

Aplicações que se utilizam dos dados providos por uma RSSF possuem a limitação de serem altamente acopladas à estas redes. Desta forma, neste trabalho apresentamos uma arquitetura orientada a serviços (SOA) para redes de sensores sem fio (SOA-RSSF) e desenvolvemos um protótipo para esta arquitetura. O principal objetivo da SOA-RSSF é a integração de serviços relacionados à RSSF à 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 concluir que apesar de ser um grande desafio integrar um ambiente SOA à 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 trabalhos futuros, estamos trabalhando nas seguintes linhas: o desenvolvimento 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 ontologia 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.

(11)

Referências

Ferreira, D. J., Dantas, M.A.R. Pinto, A. R., Montez, C. and Rodriguez, M. (2007). A middleware for oscar and wireless sensor network environments. 21st International Symposium on High Performance Computing Systems and Applications, pages 24–24. HPCS 2007.

Delicato, F. C., Pires, P. F., Pirmez, L., and da Costa Carmo, L. F. R. (2003). A flexible web service based architecture for wireless sensor networks. 23rd International Conference on Distributed Computing Systems Workshops, pages 730–735.

Endrei, M., Ang, J., Arsanjani, A., Chua, S., Comte, P., Krogdahl, P., Luo, M., and Newling, T. (2004). Patterns: Service-Oriented Architecture and Web Services. ibm.com/redbooks. Josuttis, N. M. (2007). SOA in Practice. O’Reilly.

OASIS, C. (2006). Reference model for service oriented architecture 1.0. Technical report. Othman, N. Y., Chebbine, S., Khendek, F., and Glitho, R. (2007a). A web services-based architecture for the interactions between end-user applications and sink-less wireless sensor networks. 4th IEEE Consumer Communications and Networking Conference, pages 865– 869. CCNC 2007.

Othman, N. Y., Glitho, R. H., and Khendek, F. (2007b). The design and implementation of a web service framework for individual nodes in sink-less wireless sensor networks. IEEE Symposium on Computers and Communications. ISCC’07.

Referências

Documentos relacionados

Um estudo realizado com a combinação de paracetamol, maleato de carbinoxamina e cloridrato de fenilefrina, que comparou sua eficácia com outras duas formas de associação

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;

• Esteiras/bikes/Elipticon/Escada disponíveis para utilização com a distância sugerida de 1,5m; • Recomenda-se não não Utilizar o Vestiário, exceto de maneira pontual e

Do Povoado de Cabeceira Grande, Ilha II, José Nobre, Ilha do Vitor e Almas à Sede, com estudantes Universitários no turno noturno.. Do Povoado de Batalha,

-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

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

•   O  material  a  seguir  consiste  de  adaptações  e  extensões  dos  originais  gentilmente  cedidos  pelo 

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