ads:
SEMSUS: MIDDLEWARE PARA REDES DE SENSORES SEM FIO BASEADO EM
SERVIÇOS SEMÂNTICOS
Mossoró (RN), janeiro de 2010.
Universidade do Estado do Rio Grande do Norte
Universidade Federal Rural do Semi-Árido
Curso de Mestrado em Ciência da Computação
ads:
Livros Grátis
http://www.livrosgratis.com.br
Milhares de livros grátis para download.
Francisco Cassimiro Neto
SEMSUS: MIDDLEWARE PARA REDES DE SENSORES SEM FIO BASEADO EM
SERVIÇOS SEMÂNTICOS
Mossoró (RN), janeiro de 2010.
Dissertação apresentada ao Mestrado de
Ciência da Computação da Universidade
do Estado do Rio Grande do Norte em
parceria com a Universidade Federal
Rural do Semi-Árido, como requisito
parcial à obtenção do título de Mestre em
Ciência da Computação.
Orientadora: Profª. Drª. Cláudia Maria
Fernandes Araújo Ribeiro.
ads:
Francisco Cassimiro Neto
SEMSUS: MIDDLEWARE PARA REDES DE SENSORES SEM FIO BASEADO EM
SERVIÇOS SEMÂNTICOS
Data de aprovação: ____/____/______.
Profª. Cláudia Maria Fernandes Araújo Ribeiro, Drª., Orientadora.
_____________________________________________________.
Universidade do Estado do Rio Grande do Norte (UERN).
Profº. Pedro Fernandes Ribeiro Neto, Drº., Avaliador.
_____________________________________________________.
Universidade do Estado do Rio Grande do Norte (UERN).
Profº. Nelson Souto Rosa, Drº., Avaliador.
Universidade Federal de Pernambuco (UFPE).
Dissertação apresentada ao Mestrado de
Ciência da Computação da Universidade
do Estado do Rio Grande do Norte em
parceria com a Universidade Federal
Rural do Semi-Árido, como requisito
parcial à obtenção do título de Mestre em
Ciência da Computação.
“Para onde me irei do teu Espírito, ou para onde fugirei da tua face?... Até ali a tua mão me
guiará e a tua destra me susterá.” [BÍBLIA, A.T. Sl 139:7-10].
AGRADECIMENTOS
Primeiramente agradeço a Deus. Muitos falam da sua onipresença, mas chegando ao
trabalho final do mestrado tenho experimentado esta verdade nesta jornada acadêmica. Seja
em Natal, em Mossoró ou em Campina Grande, este trabalho é prova da tua fidelidade e amor
para comigo. Já tenho lido muito sobre isto, mas nada melhor que experimentar. Muito
obrigado Senhor.
Aos meus pais, Ivan de Oliveira Neves, Ione Cassimiro Neves, e meu irmão Ivan
Junior. Neste período me casei e formei outra família, sei que será abençoada pela que me
gerou.
A minha esposa Andréia Simone S. de Melo CASSIMIRO. Aquele que ler a minha
monografia vai ver seu nome nos agradecimentos, mas sem o CASSIMIRO. Sou feliz por
podê-lo colocar nesta dissertação. Tenho dúvidas quanto se irei fazer uma tese, mas desejo
que ele continue presente em minhas batalhas e vitórias. Quando lhe foi dito “na alegria ou na
tristeza”, você disse sim. Muito obrigado por me esperar e acima de tudo me amar.
A minha tia Doraline Cassimiro, e meus primos Fernando e David. Dois anos atrás
vocês me trouxeram no início da viagem com choro, nada mais justo de compartilhar esta
alegria.
A minha orientadora, Cláudia Ribeiro. Sei da sua preocupação e frequente pressão
pelo êxito dos trabalhos, mas muitas vezes o que me movia a fazê-los era o sentimento de
gratidão pelo que você me fez.
Aos meus colegas de curso. Tenho compartilhado momentos bons e ruins com vocês.
Saibam que nenhuma fonte de aprendizado foi melhor que a vivência com vocês.
A Roney Meziart e Edsongley Varela de Almeida. Faz certo tempo que meu irmão
está distante de mim. Obrigado por terem encurtado esta distância.
Aos irmãos da Igreja de Cristo. Outra certeza tenho: uma família a mais posso contar
na minha jornada. São laços de sangue que nos une, de sangue puro!
Aos professores e mestres do curso do Mestrado em Ciência da Computação. A
sabedoria que vocês me passaram foi especialmente diluída em conhecimento. Sou grato pelo
crescimento, como pessoa e como estudante que vocês me proporcionaram.
Aos demais que estiveram perto de mim no mestrado. São muitos a agradecer. Vocês
também fazem parte desta conquista.
v
SUMÁRIO
LISTA DE FIGURAS ............................................................................................................. viii
LISTA DE TABELAS ............................................................................................................... x
LISTA DE ABREVIATURAS .................................................................................................. xi
RESUMO ................................................................................................................................. xii
ABSTRACT ............................................................................................................................ xiii
Capítulo 1. Introdução ....................................................................................................... 14
1.1. Contexto ..................................................................................................................... 14
1.2. Motivação .................................................................................................................. 15
1.3. Descrição do Problema .............................................................................................. 15
1.4. Objetivos .................................................................................................................... 17
1.5. Estrutura do trabalho .................................................................................................. 18
Capítulo 2. Tópicos essenciais sobre RSSF e Web semântica .......................................... 19
2.1. Redes de Sensores Sem Fio ....................................................................................... 19
2.1.1. Fatores que influenciam os projetos em RSSF ................................................... 22
2.1.2. Sistema operacional e linguagem para as RSSF ................................................. 23
2.2. Middleware para RSSF .............................................................................................. 26
2.3. Arquitetura orientada a serviços (SOA) ..................................................................... 29
2.4. Serviços Web ............................................................................................................. 33
2.5. Ontologias .................................................................................................................. 35
2.6. Serviços Semânticos .................................................................................................. 36
2.6.1. OWL-S ............................................................................................................... 38
Capítulo 3. Trabalhos relacionados ................................................................................... 40
3.1. Principais middleware para RSSF ............................................................................. 40
3.1.1. Impala ................................................................................................................. 41
3.1.2. TinyDB ............................................................................................................... 42
3.1.3. Mires ................................................................................................................... 43
3.1.4. Mate .................................................................................................................... 45
3.1.5. TeenyLIME ........................................................................................................ 45
3.2. Trabalhos que usam SOA no contexto das RSSF ...................................................... 46
3.3. Trabalhos que usam tecnologias da web semântica no contexto das RSSF .............. 50
Capítulo 4. Middleware SEMSUS ..................................................................................... 52
vi
4.1. Arquitetura do middleware ........................................................................................ 52
4.1.1. Cliente ................................................................................................................. 53
4.1.2. O provedor de serviços ....................................................................................... 54
4.1.3. Arquitetura do SEMSUS .................................................................................... 59
4.1.4. Propriedades da arquitetura do middleware ....................................................... 62
4.2. Interações entre componentes nas principais atividades ............................................ 65
4.3. Detalhes e ferramentas utilizadas nas interações ....................................................... 66
Capítulo 5. Implementação da arquitetura e estudo de caso ................................................. 68
5.1. Implementação do Registro ....................................................................................... 68
5.2. Implementação das interações com o registro ........................................................... 68
5.3. Implementação do Cliente ......................................................................................... 71
5.4. Implementação do Provedor ...................................................................................... 72
5.5. Estudo de caso ........................................................................................................... 75
5.5.1. Cenário de invocação de serviços distintos ........................................................ 75
5.5.2. Resultados da invocação dos serviços distintos ................................................. 81
5.5.3. Cenário de utilização da semântica na pesquisa de serviços .............................. 82
Capítulo 6. Considerações Finais e Trabalhos Futuros ......................................................... 87
6.1. Conclusão ................................................................................................................... 87
6.2. Limitações e trabalhos futuros ................................................................................... 89
REFERÊNCIAS BIBLIOGRÁFICAS ..................................................................................... 90
APÊNDICE A – API de pesquisa de serviços semânticos ....................................................... 94
APÊNDICE B – API de invocação de serviços semânticos ..................................................... 96
APÊNDICE C – Profile do serviço de roteamento................................................................... 97
APÊNDICE D – Process do serviço de roteamento ................................................................. 99
APÊNDICE E – WSDL do serviço de roteamento ................................................................ 100
APÊNDICE F – Código NesC da Implementação do SEMSUS ........................................... 101
F.1. Código de Messages.h (Mensagens) ........................................................................... 101
F.2. Código da configuração MiddlewareC ....................................................................... 101
F.3. Código da interface SplitFase...................................................................................... 102
F.4. Código do componente Manager ................................................................................ 102
F.5. Código da configuração DispatcherC ......................................................................... 103
F.6. Código do componente ServiçosM ............................................................................. 104
F.7. Código do serviço de disseminação residente no Sink................................................ 105
vii
F.8. Código do serviço de disseminação residente nos nós ................................................ 106
F.9. Código do serviço de roteamento residente no Sink ................................................... 107
F.10. Código do serviço de roteamento residente nos nós ................................................. 109
APÊNDICE G - Ontologia usada na busca semântica ........................................................... 111
viii
LISTA DE FIGURAS
Figura 2.1. Arquitetura de uma RSSF.. .................................................................................... 20
Figura 2.2. Pilhas de protocolos para RSSF.. ........................................................................... 20
Figura 2.3. Representação gráfica do componente TimerComponent. .................................... 24
Figura 2.4. Código NesC do TimerComponent. ....................................................................... 24
Figura 2.5. Representação gráfica da configuração CompleteTimer. ...................................... 25
Figura 2.6. Código NesC da configuração CompleteTimer. .................................................... 25
Figura 2.7. Sistema distribuído organizado como middleware. ............................................... 26
Figura 2.8. Distribuição de middleware em uma RSSF.. ......................................................... 27
Figura 2.9. Modelo de referência de um middleware para RSSF............................................. 27
Figura 2.10. Componentes e interações da arquitetura orientada a serviços. ........................... 31
Figura 2.11. Interação entre os componentes para busca sintática de serviços. ....................... 34
Figura 2.12. Interação entre os componentes para busca semântica de serviços. .................... 37
Figura 2.13. Ontologia na linguagem OWL-S. ........................................................................ 39
Figura 3.1. Exemplo de consulta para o TinyDB. .................................................................... 43
Figura 3.2. Arquitetura do Mires. ............................................................................................. 44
Figura 4.1. Composição interna do Cliente. ............................................................................. 54
Figura 4.2. Interações do Cliente com o Registro e com o Provedor. ...................................... 54
Figura 4.3. Provedor composto pelo Web Server e RSSF........................................................ 55
Figura 4.4. Visão do Provedor a partir da constituição da RSSF e do Web Server. ................ 56
Figura 4.5. Composição interna do componente RSSF. ........................................................... 57
Figura 4.6. Visão geral da interação entre componentes do middleware SEMSUS. ............... 60
Figura 4.7. Arquitetura do SEMSUS. ....................................................................................... 61
Figura 4.8. Interação entre os principais componentes do sistema. ......................................... 65
Figura 4.9. Interações e ferramentas utilizadas na publicação dos serviços............................. 66
Figura 4.10. Interações e ferramentas utilizadas na invocação dos serviços. ........................... 67
Figura 5.1. Arquitetura do Matchmaker. .................................................................................. 69
Figura 5.2. Exemplo de código para registro de um serviço usando o Matchmaker Client. .... 70
Figura 5.3. Exemplo de código de uso do Matchmaker Client na busca. ................................ 70
Figura 5.4. Exemplo do código de busca de serviços pela especificação de suas características.
.................................................................................................................................................. 71
ix
Figura 5.5. Estrutura interna do Cliente. .................................................................................. 72
Figura 5.6. Estrutura interna do Gateway. ................................................................................ 73
Figura 5.7. Estrutura interna na RSSF em NesC. ..................................................................... 74
Figura 5.8. Exemplo de código de uma aplicação cliente ........................................................ 77
Figura 5.9. Código do serviço de roteamento. .......................................................................... 78
Figura 5.10. Parte do código do objeto Bind. ........................................................................... 79
Figura 5.11. Código do componente MiddlewareC. ................................................................ 79
Figura 5.12. Parte do código do Dispatcher. ............................................................................ 80
Figura 5.13. Código da interface SplitFase. ............................................................................. 81
Figura 5.14. Arquivo de mensagens da execução do serviço de roteamento. .......................... 82
Figura 5.15. Arquivo de mensagens da execução do serviço de disseminação........................ 82
Figura 5.16. Ontologia que expressa às relações entre tipos. ................................................... 83
Figura 5.17. Parte do profile do serviço de roteamento considerando a ontologia. ................. 84
Figura 5.19. Resultado da busca semântica. ............................................................................. 85
Figura 5.18. Exemplo de código da busca considerando uma ontologia. ................................ 85
xi
LISTA DE ABREVIATURAS
API
Application Programming Interface
ADL
Architecture Description Language
CORBA
Common Object Request Broker Architecture
DCOM
Distributed Component Object Model
DPWS
Device Profile for Web Services
Dymo
Dynamic MANET On-demand
HTTP
Hypertext Transfer Protocol
J2ME
Java Micro Edition
JavaRMI
Java Remote Method Invocation
MAC
Medium Access Control
MANETs
Mobile ad hoc network
Mig
Message Interface Generator
OGC
Open Geospatial Consortium
OSWA
Open Sensor Web Architecture
OWL
OWL Web Ontology Language
PDA
Personal Digital Assistant
REST
Representational State Transfer
RSSF
Redes de Sensores Sem Fio
SEMSUS
Semantic Middleware for Service-oriented Sensor network
SOA
Service-oriented Architecture
SOAP
Simple Object Access Protocol
SWE
Sensor Web Enablement
UDDI
Universal Description, Discovery, and Integration
URL
Uniform Resource Locator
WSDL
Web Service Definition Language
WSMO
Web Service Modeling Ontology
xADL
Extensible Architecture Description Language
XML
Extensible Markup Language
xii
RESUMO
Middleware para Redes de Sensores sem Fio tem sido objeto de vários projetos de pesquisas
nos últimos anos. Isto se deve, principalmente, a evolução das tecnologias associadas a tais
redes, que conduziram ao surgimento de um amplo número de novas aplicações. Embora,
soluções de middleware já tenham se consolidado em plataformas tradicionais, em Redes de
Sensores Sem Fio (RSSF), os desafios originários da limitação de recursos desafiam a adoção
deste tipo de solução. Desenvolver aplicações para sensores, atualmente, exige do
desenvolvedor o gerenciamento de baixo nível, envolvendo, por exemplo, questões de
hardware e de comunicação. Neste contexto, este trabalho apresenta o middleware SEMSUS,
que utiliza um conjunto de tecnologias e conceitos, dentre os quais se destacam os serviços
semânticos. Serviços semânticos são assim denominados por incorporarem tecnologias da
Web Semântica, notadamente ontologias. Assim, para o SEMSUS a rede é a provedora de
serviços semânticos e a aplicação é considerada um cliente que consome tais serviços. São
apresentados em detalhes, os componentes arquiteturais do SEMSUS, a interação entre os
mesmos, bem como detalhes de implementação e cenários de utilização.
Palavras-chave: Redes de Sensores Sem Fio, Middleware, Arquitetura Orientada a Serviços,
Serviços Semânticos.
xiii
ABSTRACT
Middleware for Wireless Sensor Networks has been the subject of several research projects in
recent years. This is due mainly to changing technology associated with such networks, which
led to the emergence of a large number of new applications. The middleware is a solution for
applications support of various platforms of traditional distributed systems, but for Wireless
Sensor Networks still in flux and consolidation, since they need to meet the particular
requirements of such networks, such as low resource consumption. Develop applications for
sensors, demand the developer to manage low-level, controlling issues of hardware and
network, and not just stick to logic programming. So, this dissertation presents the SEMSUS
middleware that handles this problem by adding another layer of software and providing a
high level interface. For this it uses a set of technologies and concepts, among which stand out
the semantic services. Thus, for the SEMSUS, the network is a provider of semantic services
and the application is a customer. Also are shown the SEMSUS architecture, implementation
and use in a case study in which two services are used by an application.
Keywords: Wireless Sensor Network, Middleware, Service-oriented Architecture, Semantic
Services.
14
Capítulo 1. Introdução
1.1. Contexto
Redes de sensores sem fio (RSSF) consistem no agrupamento de vários pequenos
equipamentos, denominados nós ou nodos, com poder computacional, comunicação sem fio e
capacidade de sensoriamento [AKYILDIZ et al, 2002]. Os nós sensores são espalhados em
um ambiente de observação para extração, processamento e envio de dados. Assim, as RSSF
estão intimamente relacionadas aos fenômenos que ocorrem no ambiente, por meio dos nós,
que possuem interfaces para sensoriar (sensores) e/ou atuar (atuadores).
Nas RSSF os nós podem possuir papéis diferentes de acordo com suas funções na
rede, como sensores
1
ou sorvedouros (sink). Os nós sensores são os que captam as
características ambientais e as transformam em dados a serem enviados pela rede. O sink é o
sorvedouro de dados e funciona como gateway da rede, de forma que qualquer comunicação
com o ambiente externo acontece por meio dele.
Algumas das principais características das RSSF é a limitação de recurso, seja no
poder computacional, na quantidade de energia disponível, ou na capacidade de comunicação
[WANG et al, 2008]. Assim, o aumento do custo energético de qualquer solução para RSSF
deve ser considerado, visando prolongar o tempo de vida da rede. Por esta característica, em
geral, o sorvedouro possui mais recursos que os nós sensores.
Outra característica das soluções para as RSSF refere-se às diferentes possibilidades
de combinações de sensores, processamento de informações e tecnologias de comunicação,
resultando em muitos cenários de aplicações [HOLGER; WILLIG, 2005]. Isto torna difícil a
existência de uma única solução que possa abranger todos os cenários.
Assim, RSSF são sistemas distribuídos semelhantes às Mobile Ad hoc NETwork
(MANETs) no tocante a auto-organização e forma de comunicação, mas diferem em questões
como quantidade de recursos disponíveis nos hosts, proximidade com o ambiente e soluções
para problemas particulares.
1
Alguns autores chamam os nós que têm a função de monitorar o ambiente de “nós fonte”. No contexto deste
trabalho, os mesmos são denominados nós sensores ou simplesmente nós e os termos “nós” e “nodos” são
considerados sinônimos.
15
1.2. Motivação
Aplicações em RSSF têm atraído atenção de pesquisadores e da indústria [WANG et
al, 2008], que buscam atender diversas áreas, tais como monitoramento ambiental, agricultura
de precisão, “transporte inteligente”, “prédios inteligentes”, dentre outros [AKYILDIZ et al,
2002]. Este fenômeno está associado ao surgimento e consolidação da computação ubíqua e
pervasiva [KHAN et al, 2006].
A perspectiva de várias aplicações sendo executadas em uma mesma plataforma é
comum em ambientes computacionais distribuídos tradicionais, o que explicita a necessidade
de reutilizar serviços e funcionalidades que são comuns a um conjunto de aplicações. Esta é
precisamente a função do middleware. Um desafio a ser considerado está relacionado à
dificuldade em atender os requisitos das aplicações, sem aumentar significativamente a
complexidade das operações de baixo nível, tais como o controle sobre hardware e infra-
estrutura de rede. Os requisitos das aplicações incluem flexibilidade, reusabilidade e
tolerância a falhas. Enquanto que a complexidade de uma RSSF é caracterizada pela limitação
de recursos disponíveis, topologia dinâmica da rede e APIs (Application Programming
Interface) de baixo nível [WANG et al, 2008]. É pretensão do middleware, mediar tais
aspectos, de forma a facilitar o desenvolvimento das aplicações.
1.3. Descrição do Problema
Sistemas tradicionais de middleware, como Java Remote Method Invocation (Java
RMI), Enterprise JavaBeans (EJB) e Common Object Request Broker Architecture (CORBA),
não são adequados ao cenário das RSSF devido ao consumo de recursos de memória e de
processamento [KHAN et al, 2006]. As particularidades das RSSF trazem, portanto, novos
desafios e diversas soluções têm sido propostas. Middleware para RSSF, em geral, têm sido
desenvolvidos segundo uma estratégia de delimitação de foco, produzindo soluções para
domínios específicos.
A classificação dos principais middleware para RSSF apresentada em [WANG et al,
2008], segundo o paradigma de implementação, apresenta trabalhos que usam agentes de
software, eventos, modelos de “base de dados”. Outras abordagens fazem uso da arquitetura
orientada a serviços (SOA), como em [DELICATO, 2005]. De fato, em RSSF, a
funcionalidade de uma aplicação pode ser considerada um serviço de mais alto nível quando
16
comparada com as redes tradicionais, a fim de atender uma determinada tarefa. “Pessoas
querem respostas, não números” [HOLGER; WILLIG, 2005].
Neste contexto, é proposto um middleware, que utiliza tecnologias da Web
Semântica, para fornecer serviços mais inteligentes, no qual RSSF são consideradas
essencialmente, fornecedoras de serviços. Tal perspectiva objetiva esconder do desenvolvedor
de aplicações, primitivas de baixo nível associadas a uma linguagem de programação
específica e características da plataforma de execução, por meio do uso de APIs. De forma
prática, é feito o mapeamento entre as requisições de alto nível na Web, para chamadas
específicas ao código que é invocado nos sensores.
É importante considerar que, dada as especificidades das RSSF, o reuso de soluções
é limitado. Uma arquitetura orientada a serviços (SOA) permite disciplinar as relações entre
provedor e cliente por meio de um contrato, bem como o uso de serviços providos por
diferentes RSSF. Estes aspectos motivaram e orientaram a definição da arquitetura do
Middleware descrito neste trabalho.
A arquitetura SOA preconiza a necessidade de publicação das descrições dos
serviços, em um formato que possibilite ser entendido e processado pelas aplicações clientes.
A publicação é fundamental para a garantia do fraco acoplamento, característica essencial à
distribuição. Em geral, a descrição de serviços consiste em documento que caracteriza
sintaticamente os serviços, por meio de atributos ou metadados, que são utilizados como
argumento nas buscas, de forma semelhante às tradicionais ferramentas de busca de
documentos na Web.
Serviços descritos de forma diferente podem guardar similaridades entre si, e
serviços descritos de forma similar, podem representar funcionalidades absolutamente
distintas. Por exemplo, durante uma busca sintática de serviços de monitoramento térmico de
determinada área, um cliente pode obter serviços cujos parâmetros de entrada façam
referência a “temperatura”, mas não consiga obter serviços cujos parâmetros referem-se a
“calor”. A associação de significado às descrições dos serviços tenciona resolver problemas
desta natureza, ampliando qualitativamente o espaço de busca. Importante considerar que a
adição de semântica influencia não apenas a descoberta de serviços, mas também a
composição, execução e monitoramento, promovendo maior automação em cada um destes
mecanismos [CARY et al, 2007].
17
1.4. Objetivos
Este trabalho tem como principal objetivo a proposição de um middleware para
RSSF baseado em serviços semânticos. São considerados serviços semânticos aqueles que
incorporam em sua criação e manipulação, tecnologias da Web Semântica. O middleware
proposto, denominado SEMSUS
2
visa fornecer facilidades para o desenvolvimento de
aplicações baseadas no paradigma orientado a serviços. Tais facilidades incluem tarefas
tipicamente relacionadas a serviços, tais como a busca, invocação e monitoramento de
serviços fornecidos por RSSF.
Considerando que RSSF são tipicamente provedoras de serviços e as aplicações são
os clientes desses serviços, a escolha do uso de serviços Web permite às RSSF expor
funcionalidades em um meio amplamente utilizado e tido como plataforma de
desenvolvimento para diversas aplicações. A utilização de semântica por sua vez, promove
melhorias na comunicação entre aplicação e rede provedora de serviço, de modo que a
comunicação entre eles esteja baseada na definição do significado das informações trocadas e
não apenas em sua forma sintática.
As discussões deste trabalho não se limitam apenas ao domínio das RSSF e suas
características, uma vez que são abordadas questões como SOA, serviços Web e semânticos,
além de padrões de projeto utilizados. Assim a concepção do SEMSUS aborda também o uso
de ferramentas para comunicação entre os componentes segundo especificações dos serviços
semânticos, possibilitando a validação de tais ferramentas, bem como a aplicação dos padrões
de projeto e das interações segundo SOA em uma solução de middleware.
Embora o cenário de utilização do SEMSUS inclua potencialmente diversas
aplicações, existe um interesse especial em aplicações voltadas à agricultura de precisão e o
monitoramento de processos. Estas atividades são fundamentais para a economia da região de
Mossoró, no estado do Rio Grande do Norte, onde se destacam a fruticultura irrigada e a
exploração de petróleo. Pretende-se desta forma, transformar os resultados desta pesquisa em
fator inovador a ser aplicado na dinamização da economia local, além de colaborar, na
perspectiva científica, com as pesquisas relacionadas ao desenvolvimento de middleware para
RSSF associados à utilização da Web semântica.
2
SEMSUS é um acrônimo para SEmantic Middleware for Service-oriented Sensor network, onde o “u” foi
acrescido para dar sonoridade ao nome.
18
1.5. Estrutura do trabalho
Esta dissertação está divida da seguinte forma: no Capítulo 2 são apresentados os
principais tópicos sobre questões conceituais e práticas das RSSF, dos middleware, dos
middleware para RSSF, de SOA, de serviços e de serviços semânticos. Tais abordagens são
necessárias para compreensão dos capítulos seguintes. O Capítulo 3 trata dos trabalhos
relacionados, mostrando alguns exemplos de middleware para RSSF existentes, alguns
trabalhos utilizam SOA e tecnologias da Web semântica no contexto de soluções para RSSF.
O Capítulo 4 apresenta uma visão geral e elementos arquiteturais do SEMSUS. No Capítulo 5
são discutidos detalhes de implementação do SEMSUS, mostrando as especificidades da
utilização das ferramentas, da constituição interna de cada componente principal e da API
fornecida pelo middleware. Associada a exploração da implementação, o Capítulo 5 aborda
um estudo de caso em que são implementados dois serviços para validação da execução do
SEMSUS, bem como uma busca que considera a semântica das informações. Finalmente, no
Capítulo 6 encontrar-se a conclusão, as limitações e os trabalhos futuros relacionados a este.
19
Capítulo 2. Tópicos essenciais sobre RSSF e Web semântica
Neste capítulo são descritos os principais conceitos relativos às RSSF, middleware
para RSSF, SOA, serviços Web e serviços semânticos. Tais fundamentos são necessários para
entendimento do SEMSUS, bem como o da sua utilização nos cenários propostos neste
trabalho.
2.1. Redes de Sensores Sem Fio
O avanço da tecnologia dos sistemas microeletrônicos, das redes sem fio e da
eletrônica digital têm permitido aprimorar o desenvolvimento de sensores de baixo custo,
baixo consumo, multifuncionais e de tamanhos cada vez menores que permitem a
comunicação em curtas distâncias [AKYILDIZ et al, 2002].
Existe uma variedade de aplicações para RSSF. Em [AKYILDIZ et al, 2002] é
possível encontrar um conjunto de aplicações e cenários que são comumente utilizados nas
RSSF. Alguns delas são aplicações militares, aplicações ambientais, aplicações na área de
saúde, aplicações de automação industrial, predial e doméstica, agricultura de precisão, dentre
outras.
Nas RSSF os nós sensores trabalham colaborativamente para realizarem uma
determinada tarefa, visto que cada nodo possui um processador. Em vez de mandar somente
os dados coletados do meio ambiente, os nós podem realizar processamento local sobre os
dados de forma a enviarem as informações requeridas e já pré-processadas, desde que
possuam um algoritmo de processamento de dados.
Para melhor assimilação das características das RSSF, na Figura 2.1 é mostrada uma
arquitetura típica de uma rede, na qual se destacam os nós e suas respectivas funções.
20
Figura 2.1. Arquitetura de uma RSSF. Fonte: adaptado de [LIMA, 2008].
A Figura 2.1 apresenta dois contextos de execução distintos que são conectados pelo
sorvedouro. O campo de sensoriamento, onde se localizam os nós sensores que interagem
com o ambiente em que foram implantados, e um que é externo a este ambiente, no qual
podem existir equipamentos com menores restrições de recursos. Toda comunicação entre
eles devem ocorrer por meio do sorvedouro, que na Figura é único, mas em uma RSSF pode
possuir mais de um sorvedouro, dependendo do projeto da rede.
Para comunicação entre os nós da rede é necessária a utilização de uma pilha de
protocolos. Esta pilha é representada na Figura 2.2.
Figura 2.2. Pilhas de protocolos para RSSF. Fonte [AKYILDIZ et al, 2002].
Dependendo da solução, diferentes aplicações podem ser construídas na camada de
aplicação. Suas principais funcionalidades são a de abstrair a topologia física da RSSF para as
aplicações e providenciar as interfaces para interação com o ambiente físico por meio da rede
[AKYILDIZ et al, 2002].
21
A camada de transporte ajuda a manter o fluxo de dados, caso seja requerido pela
aplicação. Para colaboração entre os diversos nós da rede, torna-se necessário que nesta
camada existam mecanismos para aumentar a confiabilidade e eficiência da comunicação
entre as aplicações residentes nos nós e no sorvedouro [AKYILDIZ et al, 2002].
A camada de rede preocupa-se como roteamento dos dados pedidos pela de
transporte. Vários protocolos de redes têm sido propostos e uma breve classificação dos
mesmos pode ser encontrada em [AKYILDIZ et al, 2002].
As aplicações em RSSF dependem das informações providas de múltiplos sensores
para poder interagir com o ambiente sensoriado. Para tal interação é necessário que a camada
de enlace de dados realize atividades para controle de acesso ao meio de comunicação,
multiplexação/demultiplexação de dados, detecção de quadros e controle de erros. Devido às
dificuldades existentes na comunicação relativas às características das RSSF já serem uma
realidade, como a possibilidade dos nós estarem inseridos em ambiente ruidoso e possuírem
mobilidade, o protocolo de controle de acesso ao meio (MAC) deve fornecer meios para que
os problemas de colisão de dados sejam minimizados de forma a melhorar a comunicação no
tocante à colisão.
A camada física é responsável pela conversão do fluxo de bits em sinais que são mais
adequados para a comunicação sem fio. Mais especificamente trata-se da seleção de
frequências, geração da portadora, detecção e modulação de sinais, e criptografia de dados. A
qualidade da comunicação também depende de algumas propriedades de hardware como a
sensibilidade da antena e do circuito transceptor. Assim, a camada física engloba técnicas
simples, mais robustas, de modulação, transmissão e recepção.
Além das camadas, devem existir os planos gerenciamentos de energia, de
mobilidade e de distribuição de tarefas. O primeiro gerencia a forma como os nós utilizam a
energia. Por exemplo, um sensor pode desligar o transceptor depois de ter recebido uma
mensagem. O segundo gerencia a mobilidade dos sensores permitindo que um sensor possa
saber da movimentação dos seus vizinhos. E o terceiro gerencia a distribuição de tarefas entre
os sensores. Estes planos de gerenciamento são fundamentais para que os sensores cooperem
entre si e, assim, devem estar presentes em todas as camadas.
As características intrínsecas das RSSF conduzem a um conjunto de fatores que
influenciam os projetos das soluções para tais redes. Na Seção 2.1.1 estes fatores são
apresentados.
22
2.1.1. Fatores que influenciam os projetos em RSSF
Um projeto para RSSF é influenciado por muitos fatores, os quais incluem tolerância
à falhas, custo de produção, restrições de hardware, topologia da RSSF, escalabilidade,
ambiente de operação, mídia de transmissão, e consumo de energia [WANG et al, 2008].
A tolerância a falhas é necessária devido a falhas nos nós que podem ocorrer pela
falta de energia, ou por danos causados por alguma intempérie. A tolerância permite que as
funcionalidades da rede continuem funcionando apesar da falha de alguns nós sensores, e
estão associadas ao tipo de aplicação. Por exemplo, a tolerância deve ser maior em um cenário
de monitoramento de campo de batalha quando comparado com o de automação residencial.
A escalabilidade é uma característica importante, porque em uma RSSF podem
existir dezenas, ou centenas, ou milhares de nós sensores como plataforma de execução de
uma aplicação. Assim as soluções devem estar preparadas para trabalharem com esta
quantidade de nós, bem como com a alta densidade dos mesmos.
O custo de produção está associado ao custo de cada nodo, visto a possibilidade de
utilização de uma grande quantidade de nós em uma única solução. Se o custo de implantar
uma RSSF for maior que a utilização de sensores tradicionais, o custo não justifica a escolha
de uma RSSF [WANG et al, 2008].
A limitação de hardware é outra característica que deve ser considerada. Existem
restrições que limitam o tamanho do nodo, que dependendo da aplicação pode exigir ser de
centímetros para permitir a sua flutuação, em uma aplicação de monitoramento das correntes
marítimas na qual o nodo deve ser conduzido por elas. Além da limitação de tamanho, outras
limitações são comuns: pouca quantidade de energia disponível, pois existem sensores em
áreas de difícil acesso para recarregamento de energia; operar em alta densidade volumétrica;
os nós devem ser baratos e descartáveis; autonomia para operar sem intervenção humana; e
adaptação às alterações ambientais.
As possibilidades de falhas dos nós e da comunicação, bem como a mobilidade dos
hosts fazem com que manutenção da topologia seja um desafio ainda maior, quando
comparado às redes tradicionais. Trabalhos como em [WU et al, 2008] mostram a
preocupação em manter a topologia de uma RSSF de modo que a energia dos nós seja
consumida de forma igualitária.
Como a rede está intimamente relacionada com o ambiente, é necessário que o
projeto considere as especificidades deste. Por exemplo, se a intenção for projetar um sistema
23
para monitoramento no fundo do oceano os nós sensores devem ser projetados para
suportarem alta pressão.
Numa RSSF a comunicação entre os sensores ocorre por um meio sem fio, mais
especificamente pode ser por meio de infravermelho, rádio frequência, ou óptica. A forma de
comunicação deve considerar várias outras características como a aplicação a ser produzida, o
meio que a rede utiliza, a quantidade de energia dispensada para a comunicação entre os nós,
dentre outras.
Uma das características que recebem maior atenção quando do projeto de uma
solução para uma RSSF é a de consumo de energia. Visto que os nós estão equipados com
limitados recursos de energia, que o recarregamento dos recursos energéticos é impossível na
maioria das aplicações, o tempo de vida de um sensor está comumente ligado a quantidade de
energia que ele possui, e que o nodo executa uma funcionalidade dupla de gerador e roteador
de dados, a economia de energia torna-se a característica primordial quando dos projetos para
RSSF. Todas as camadas da pilha de protocolos devem ser projetadas para diminuírem o
máximo possível o consumo de energia.
As camadas que também devem obedecer as essas características é do sistema
operacional e a do middleware. A Seção 2.1.2 objetiva mostrar o sistema operacional mais
utilizado para nós das RSSF e a Seção 2.2 os principais conceitos e aplicações dos
middleware associados às especificidades das RSSF.
2.1.2. Sistema operacional e linguagem para as RSSF
TinyOS [LEVIS et al, 2004] é um sistema operacional para as RSSF. Seu projeto
visa à reação a eventos externos e baixo consumo de energia nas operações. Ele é constituído
por um conjunto de componentes adicionados as aplicações de acordo com as necessidades da
mesma. Assim, ele não é um sistema operacional monolítico, o que poderia gerar um
dispêndio de recursos que as plataformas de hardware limitadas não podem disponibilizar.
NesC [LEVIS et al, 2003], a linguagem de implementação do TinyOS, possui
características semelhantes a do sistema operacional. Ela é baseada em componentes,
permitindo uma programação modular, e possui um modelo baseado em eventos. Sua sintaxe
é baseada na da linguagem C.
Os componentes em NesC possuem similaridades com objetos das linguagens
orientadas a objetos: eles encapsulam estados e interagem por meio de interfaces bem
24
definidas [LEVIS et al, 2003]. As interações entre componentes são definidas por interfaces
que possuem comandos e eventos. Uma interface pode ser provida ou usada por componentes.
Os componentes que usam uma interface devem implementar os eventos da interface,
enquanto os que provêm devem implementar os comandos que ela define. A Figura 2.3
apresenta uma representação gráfica do componente TimerComponent e a 2.4 o código NesC
referente à representação.
Figura 2.3. Representação gráfica do componente TimerComponent.
Figura 2.4. Código NesC do TimerComponent.
Na representação da Figura 2.3, os comandos são representados pelos triângulos
preenchidos e os eventos pelos vazados. O TimerComponent providencia duas interfaces, a
StdCtrol e a Timer, e consequentemente deve implementar os comandos que elas definem. Por
outro lado, o componente usa uma interface, a Clock, e deve implementar os eventos que ela
define.
O NesC também define outra estrutura chamada de configuração, que é um conjunto
de componentes ligados. A Figura 2.5 apresenta uma configuração chamada de
25
CompleteTimer, a qual é uma combinação do componente TimerComponent com o HWClock.
O código referente à configuração é apresentado na Figura 2.6.
Figura 2.5. Representação gráfica da configuração CompleteTimer.
Figura 2.6. Código NesC da configuração CompleteTimer.
A configuração apresentada na Figura 2.6 externaliza duas interfaces do
TimerComponent por meio da definição das interfaces providas por ele: a StdCtrl e a Timer.
Estas duas interfaces recebem os valores das respectivas interfaces do TimerComponent pela
utilização do caractere “=”. A ligação entre os dois componentes é realizada pelo uso do
símbolo da seta "->", o qual indica do seu lado esquerdo, o componente que está usando a
interface e do direito o que está provendo-a.
Uma característica interessante decorrente da utilização de comandos e eventos na
interação entre componentes é a ligação assíncrona entre eles. A chamada de um comando
não bloqueia o componente que o invoca, uma vez que o componente que chama é avisado
por um evento quando do término da execução. Então, a chamada é dividida em duas partes: a
26
primeira que chama a execução e a segunda que avisa o término da execução. Esta forma de
interação recebe o nome split-fase.
2.2. Middleware para RSSF
Uma das primícias para sistemas distribuídos é que apesar do mesmo estar espalhado
por “um conjunto de computadores independentes, ele deve se apresentar aos seus usuários
como um sistema único e coerente” [TANENBAUM; STEEN, 2007]. Assim, para aplicação
deve ser fornecida transparência de distribuição de modo que abstraia as diferenças de
plataformas, de localização, de acesso aos recursos, às falhas, ao sistema operacional, a
linguagem de programação, dentre outras.
Para fornecer a transparência, o sistema distribuído geralmente fica organizado em
uma camada de software situada entre o sistema operacional e as aplicações. Devido a sua
localização intermediária tal camada recebe o nome de middleware. A representação do
middleware pode ser vista na Figura 2.7.
Figura 2.7. Sistema distribuído organizado como middleware. Fonte [TANENBAUM; STEEN, 2007].
Além de fornecer transparência, o middleware providencia interfaces padronizadas,
abstrações e um conjunto de serviços que dependem das aplicações. As aplicações para RSSF
e suas características intrínsecas (seus requisitos) devem ser consideradas ao se projetar um
conjunto de serviços que o middleware se propõe a oferecer, de modo que a utilização do
mesmo esteja de acordo com o contexto e as necessidades das tais redes.
No contexto das RSSF uma definição mais específica pode ser dada para middleware
como a encontrada em [HADIM; MOHAMED, 2006], que resumidamente afirma que ele
deve fornecer suporte para desenvolvimento, manutenção, implantação e execução de
aplicações para RSSF. O mesmo trabalho também afirma que a distribuição do middleware
para RSSF não está limitado apenas os nós componentes da rede, mas também se estende aos
equipamentos que estão conectados a rede, como representa a Figura 2.8.
27
Figura 2.8. Distribuição de middleware em uma RSSF. Fonte [WANG et al, 2008].
Segundo [WANG et al, 2008], para atender as especificidades das RSSF um
middleware deve ser constituído de quatro componentes principais. Um componente de
abstração de programação, um de serviços do sistema, um de suporte a execução de
aplicações e outro de mecanismos de qualidade de serviço (QoS). A abstração de
programação define a interface do middleware para os desenvolvedores de aplicações. Os
serviços do sistema são as implementações que fornecem tais abstrações. O suporte a
execução é uma extensão do sistema operacional para dar suporte aos serviços do middleware.
Os mecanismos de QoS definem um conjunto de especificações de QoS para o sistema. A
Figura 2.9 mostra as especificidades de cada um destes componentes.
Figura 2.9. Modelo de referência de um middleware para RSSF. Fonte [WANG et al, 2008].
28
A camada de middleware é constituída principalmente por um conjunto de serviços
que são divididos em dois grupos: os serviços comuns e os de domínio. Os comuns são os que
dão suporte a todas as aplicações que são executadas nas RSSF, enquanto os de domínio são
particulares a um conjunto de aplicações, como a de monitoramento de saúde por exemplo.
Estes serviços fazem uso do “componente de suporte à execução” e fornecem a “abstração da
programação” às aplicações por meio de uma interface definida. O componente de “suporte à
execução” faz uso dos serviços fornecidos pela plataforma de execução e da pilha de
protocolos.
Todos os serviços implementados pelo middleware devem ser projetados para se
adequarem a um conjunto de desafios postos para um middleware de uma RSSF. Dentre os
principais desafios que um projeto de middleware para RSSF destaca-se o gerenciamento
eficiente dos recursos, por causa da escassez dos mesmos nos nós da rede. Assim, um
middleware deve ter mecanismos de uso eficiente de memória e processamento, permitindo
uma comunicação com baixo consumo de energia. Um nodo sensor deve, então, realizar três
operações básicas – sensoriar, processar dados e comunicar – de modo a economizar o
máximo possível seus recursos [HADIM; MOHAMED, 2006].
Outra característica importante é o fato da RSSF conseguir manter seu desempenho
mesmo diante do crescimento da complexidade de uma aplicação e/ou da quantidade de nós
que constituem a rede. Assim, o middleware deve possuir mecanismos de escalabilidade que
permitam tais crescimentos. Associados à escalabilidade e à mobilidade dos nós da rede, o
controle de topologia é um fator importante a ser considerado, uma vez que os fatores que
proporcionam mudanças topológicas são variados. A robustez do middleware permite que
apesar das falhas e dinamicidade da rede, o suporte a execução de aplicações não seja afetado.
Uma característica presente nos middleware para RSSF é o conhecimento na
aplicação. O middleware permite que as aplicações tenham conhecimento das condições da
infraestrutura da rede. Isto possibilita, em uma solução, o mapeamento entre os requisitos da
aplicação em parâmetros de controle da rede [HADIM; MOHAMED, 2006].
Outro aspecto comum a ser abordado pelos middleware são os mecanismos de
agregação de dados. Eles permitem o processamento na rede ou para a redução na
redundância dos dados gerados pelos nós sensores, ou para fornecimento de informações a
partir de manipulações dos dados. Alguns dados gerados por diferentes nós são idênticos, de
forma que a eliminação da informação repetida não ocasiona problemas ao funcionamento do
sistema. Outros dados podem ser conjuntamente manipulados na rede para gerar informações
29
necessárias às aplicações. Por exemplo, em uma aplicação para monitoramento da média de
temperatura, um nó intermediário que recebe os dados de um conjunto de nós que monitoram
uma região específica, pode calcular a média dos valores recebidos e passa-la adiante. Assim,
a agregação possibilita a redução do número de mensagens a serem enviadas e recebidas, o
que minimiza o gasto de energia de uma forma geral.
Os mecanismos para gerenciamento da qualidade de serviço são uma preocupação
comum aos middleware. Nas RSSF pode-se abordar QoS a partir de duas perspectivas:
específicas para aplicações e para comunicação na rede [HADIM; MOHAMED, 2006]. O
primeiro se refere aos parâmetros de QoS que são específicos para aplicação como, por
exemplo, área de cobertura de um nodo, número de nós ativos, nível de precisão dos dados,
dentre outros. O segundo está relacionado como a comunicação em rede pode atender as
necessidades da aplicação usando os recursos da rede. Assim o middleware deve manter a
qualidade de serviço por longos períodos ou mesmo ajustá-la de acordo com alterações dos
requisitos da aplicação. O projeto de middleware também deve considerar o custo-benefício
entre as métricas de desempenho, como capacidade da rede ou taxa de transferência, atraso na
entrega de dados, e o consumo de energia.
A segurança é outra característica importante quando do projeto de middleware para
RSSF, visto que algumas de suas aplicações, como as militares, manipulam dados sigilosos e
importantes. Outro fato é que a implantação das redes de sensores em ambientes agressivos
aumenta sua exposição a ataques maliciosos. Além disto, a comunicação sem fio facilita as
possibilidades de escuta e injeção de pacotes que comprometem o funcionamento da rede
[HADIM; MOHAMED, 2006]. Associada a necessidade de mecanismos de segurança, existe
a de economizar os recursos da rede. Assim, o middleware deve fornecer meios de garantir os
requisitos de segurança de modo que não comprometam o desempenho e funcionamento da
rede.
2.3. Arquitetura orientada a serviços (SOA)
A interoperabilidade é uma característica cada vez mais requisitada nas soluções de
sistemas de software distribuído. A necessidade de possuir um sistema que possa ser
funcional e distribuído em máquinas, independente de linguagem de programação, do sistema
operacional, da plataforma de hardware, ou das soluções de protocolos específicos, é a
30
consequência natural da utilização do compartilhamento de recursos na Web por empresas e
pessoas. A Web como plataforma de desenvolvimento fez com que os limites das soluções
ultrapassassem os da rede de uma corporação para permitir que diferentes sistemas de
empresas distintas possam interagir para realização de uma tarefa. O sistema de uma empresa
de vendas, por exemplo, necessita interagir com o do fornecedor de produtos, de modo a
promover maior grau de automação no processo de compra e vendas.
A arquitetura orientada a serviços (SOA) tem surgido nesse contexto como meio para
promover interoperabilidade entre as soluções por definir um método de projetar, desenvolver,
implantar e gerenciar discretos pedaços de lógica de computação na Web [CARY et al, 2007].
SOA é um conjunto de componentes que podem ser invocados, e as descrições de
suas interfaces publicadas e descobertas. Os componentes são disponíveis como serviços
independentes que são acessados de forma padronizada [CARY et al, 2007].
Algumas características de SOA são fundamentais para obtenção de êxito na
integração entre aplicações. O uso de protocolos de comunicação padronizados, por exemplo,
amplia a interoperabilidade entre sistemas de instituições diferentes. Outra característica é que
os contratos devem definir explicitamente o que pode ser modificado em uma aplicação sem
comprometer a interação. Além disto, o uso de padrões é a base para a seleção e execução
interoperável de contratos.
SOA também considera a escalabilidade, uma vez que foi projetada para ser utilizada
em contextos diferentes desde dentro de uma organização, entre parceiros de negócios, ou
mesmo tendo a Web como plataforma.
O fraco acoplamento é outra característica. Em SOA os remetentes e os destinatários
de mensagens devem ser independentes um do outro. O forte acoplamento não é viável por
conduzir a sistemas monolíticos, nos quais uma pequena modificação em um dos
componentes conduz à inutilização das funcionalidades do sistema.
A abstração de tecnologia deve ser fornecida de modo que os desenvolvedores se
concentrem na produção de serviços para os usuários, e não em meios para conectar sistemas
e aplicações.
Por última característica, os serviços em SOA também precisam ser dinamicamente
descobertos para serem utilizados. Uma parte deve estar habilitada para se comunicar com a
outra, que foi selecionada entre os diferentes candidatos. Isto é conseguido por meio de
serviços, como o diretório de descrições de serviços.
31
Ao se comparar SOA com outras abordagens de integração, como sistemas de
objetos distribuídos, existem algumas diferenças. Tais mecanismos de integração são
geralmente baseados no paradigma cliente-servidor, têm um modelo de interação assimétrica,
são baseados em protocolos síncronos, implementam uma interface pública para acessar
objetos remotos, e suportam uma descoberta baseada em nomes. Enquanto que em SOA, o
paradigma é baseado numa interação peer-to-peer, tem modelos simétricos de interação, pode
usar tanto protocolos síncronos como assíncronos, seguem um contrato público para acessar
recursos remotos, e suportam descoberta baseada nas capacidades dos serviços [CARY et al,
2007].
Especificamente, existem três ações associadas a serviços que são comumente
executadas em SOA: a publicação, a descoberta, e a invocação. A publicação é o processo
para anunciar um serviço oferecido. A descoberta é o processo realizado para encontrar o
serviço que provê a funcionalidade requisitada. A invocação é interação entre quem está
precisando do serviço e quem o oferece. Para suportar tais ações são necessários três
componentes principais na arquitetura: o cliente, o provedor e o registro. A Figura 2.10
representa a arquitetura SOA com os componentes de software (em azul) e suas interações
(em amarelo).
Figura 2.10. Componentes e interações da arquitetura orientada a serviços.
A representação da Figura 2.10 está de acordo com os elementos usados em
[TAYLOR et al, 2009] para modelagem de arquiteturas de software. Tal modelagem é
realizada principalmente por dois elementos arquiteturais: os componentes de software e os
conectores. Os componentes são entidades arquiteturais que encapsulam um subconjunto de
funcionalidades e/ou dados do sistema, restringe o acesso para este subconjunto via uma
interface definida, e tem dependências explicitamente definidas relativas ao seu contexto de
execução [TAYLOR et al, 2009]. Enquanto que um conector é um elemento responsável pela
efetivação e regulação das interações entre os componentes [TAYLOR et al, 2009].
Resumidamente, as interações em SOA ocorrem de forma semelhante ao processo de
contratação de um serviço real. Começam com o objetivo de tornarem conhecidos o cliente e
32
o provedor entre si. Após o conhecimento mútuo das características necessárias para
contratação, deve haver a aceitação do contrato que rege o fornecimento do serviço. Seguida
da contratação, ocorre a troca de informações, de modo que o cliente forneça os “insumos”
necessários a execução do serviço e o provedor retorne o resultado da realização do mesmo.
Mais especificamente, na Figura 2.10 as interações são: 1) Publicar - o provedor realiza a
publicação da descrição do serviço que ele fornece em um lugar conhecido pelos clientes (o
registro); 2) Buscar – O cliente realiza perguntas sobre os serviços publicados no registro, que
podem atender suas necessidades, de forma a obter informações sobre os mesmos, inclusive
seus endereços; 3) Ligar/Invocar – Com posse do endereço do serviço que atende suas
necessidades, o cliente interage o provedor do serviço para o seu fornecimento.
É importante observar que a arquitetura da Figura 2.10 também especifica as
interfaces. Tais interfaces controlam a forma de interação entre componentes distintos. Por
exemplo, na interação de “Publicar” entre o “Provedor” e o “Registro”, está especificado que
o fluxo de controle e/ou das informações ocorre no sentido do “Provedor” para o “Cliente”,
enquanto que na interação de “Ligar/Invocar” entre o “Cliente” e o “Provedor” ocorre nos
dois sentidos, pois em uma invocação o cliente passa as entradas e recebe as saídas do
processamento.
Um provedor pode disponibilizar um ou mais serviços. Cada serviço deve ter no
mínimo uma operação, as quais são as partes dos serviços que realizam o processamento.
O fato é que SOA não é uma tecnologia específica, mas um estilo arquitetural para
interações definidas entre os componentes determinados. Assim são necessárias tecnologias
que realizem SOA gerando uma solução implementada. Diferentes possibilidades
tecnológicas para desenvolver obedecendo SOA são possíveis, tais como JavaRMI, DCOM
(Distributed Component Object Model) e CORBA. A tecnologia mais popular e desejável, no
entanto, é a de serviços Web (do Inglês Web Services) [CARY et al, 2007], uma vez que ela
elimina muitos problemas de interoperabilidade entre as aplicações e os serviços, por usar um
conjunto de padrões definidos e difundidos. Os serviços Web são fontes de estudo da Seção
2.4.
33
2.4. Serviços Web
Os serviços Web são aplicações modulares, auto-descritivas, auto-contidas que são
acessadas por meio da Web [CARY et al, 2007]. Eles são a realização de SOA mais usada,
mas a sua utilização não necessariamente implica no uso de SOA.
A invocação dos serviços Web ocorre por meio de mensagens XML (Extensible
Markup Language) que seguem o padrão SOAP (Simple Object Access Protocol). As
operações fornecidas em um serviço Web, bem como os formatos das mensagens de entrada e
saída, são descritas no padrão WSDL (Web Service Definition Language). Ou seja, um
provedor publica o WSDL de seus serviços em um registro chamado de UDDI (Universal
Description, Discovery, and Integration), o qual é consultado pelos clientes que buscam
serviços. O uso destes padrões torna os serviços Web interoperáveis, e a descrição dos
serviços em uma linguagem neutra promove sua ampla utilização.
O WSDL permite a descrição por providenciar uma linguagem que apresenta os
detalhes dos serviços de forma a viabilizar a invocação de suas operações. Isto possibilita os
requisitantes de serviços a buscarem e acharem no UDDI o serviço que atendem suas
necessidades. O UDDI permite a criação de registros que são acessíveis pela Web. Cada
registro contém informações sobre o provedor do serviço bem como a respeito do WSDL. Os
clientes podem usar um ou mais registros para descobrirem serviços relevantes [CARY et al,
2007].
Mais especificamente no processo de busca, que é representado na Figura 2.11, é
realizada uma comparação sintática entre a requisição do cliente, que representa as
necessidades, e as descrições dos serviços registrados, as quais representam as ofertas
disponíveis. Quem executa a comparação é um algoritmo de comparação localizado no
registro. Caso este algoritmo consiga associar a requisição do cliente como alguma descrição,
ele retorna um identificador do serviço para o cliente. É importante observar que o
desempenho do algoritmo está intimamente relacionado com a expressividade da linguagem
em que é realizada a requisição do cliente e a descrição do serviço.
34
Figura 2.11. Interação entre os componentes para busca sintática de serviços.
Existe uma adição nas cores usadas para representar os componentes e conectores da
Figura 2.11 em relação às da Figura 2.10. Os elementos arquiteturais daquela são
representados por duas cores diferentes, enquanto que desta, a cor azul escura é também usada
totalizando três cores. A azul mais escura está relacionada ao ponto de vista (do inglês
viewpoint) dos equipamentos, ou seja, frequentemente definem a distribuição de
funcionalidades entre as entidades de hardware do sistema. Enquanto que a azul clara se
refere ao ponto de vista lógico que captura os elementos lógicos, geralmente as entidades de
software. Assim, por exemplo, na máquina (hardware) que tem a função de registro existem
os componentes de software: o de “Comparação Sintática” e o de “Descrição Sintática” que
estão ligados pelo conector que permite o acesso aos dados da descrição, chamado de “Acesso
a dados”. Então, a arquitetura apresenta como as entidades lógicas de software estão
armazenadas nas físicas de hardware, ou seja, mostra a arquitetura a partir do ponto de vista
de implantação (do inglês deployment).
A realidade encontrada quando do uso de serviços Web tradicionais é que os padrões
usados especificam somente a sintaxe dos serviços, esquecendo-se da semântica de suas
operações. Este fato também limita a automação dos processos de descoberta, invocação,
negociação, monitoramento e composição dos serviços. Para superação de tais limitações é
proposto o uso de tecnologias da Web semântica para adicionar significado à sintaxe. Assim,
na Seção 2.6 é apresentada uma solução provida da adição de semântica neste contexto: os
serviços semânticos. Mas para o entendimento de tais serviços se faz necessário, antes,
conhecer as ontologias, as quais são explicadas na Seção 2.5.
35
2.5. Ontologias
Na filosofia, ontologia está relacionada à natureza do ser, da realidade, da existência
dos entes e das questões metafísicas em geral. Ela trata do “ser enquanto ser”, isto é, do ser
concebido como tendo uma natureza comum que é inerente a todos e a cada um dos seres.
Enquanto que a utilização do termo na computação e em inteligência artificial tem
conotações diferentes. De acordo com [GRUBER, 2005], uma ontologia é uma especificação
explícita de uma conceitualização, na qual apresenta definições associadas aos nomes de
entidades no domínio no qual se insere. Essas definições estão relacionadas, por exemplo, a
classes, relações, funções e axiomas formais que restringem a interpretação.
Já para [BORST, 2006] uma ontologia “é uma especificação formal e explícita de
uma conceitualização compartilhada”. Considerando que “formal significa legível para
computadores; especificação explícita diz respeito a conceitos, propriedades, relações,
funções, restrições, axiomas explicitamente definidos; compartilhado quer dizer
conhecimento consensual; e conceitualização diz respeito a um modelo abstrato de algum
fenômeno do mundo real” [ALMEIDA; BAX, 2003]. Então a ontologia refere-se a um nível
para a representação do conhecimento que tem por principais características:
a) Fornecem um vocabulário para representação do conhecimento. Esse vocabulário
tem por base uma conceitualização que o sustenta, evitando assim interpretações ambíguas do
mesmo;
b) Permitem o compartilhamento de conhecimento. Caso exista uma ontologia
que modele adequadamente certo domínio de conhecimento, essa pode ser compartilhada e
usada por pessoas que desenvolvam aplicações dentro desse domínio;
c) Fornecem uma descrição exata do conhecimento. Diferentemente da
linguagem natural na qual as palavras podem ter semântica totalmente diferente conforme o
seu contexto, a ontologia por ser escrita em linguagem formal não permite a existência para o
“gap semântico”. Por exemplo, quando uma pessoa fala para outra a palavra “Manga” ela
pode estar querendo falar a respeito de uma fruta, ou de uma parte de uma camisa. A
interpretação da palavra pode ser atribuída a um conceito ou outro conforme o estado mental
do indivíduo. Porém, se há uma conceitualização comum entre essas duas pessoas à
possibilidade de mal entendido diminui muito;
36
d) É possível fazer o mapeamento da linguagem da ontologia sem que com isso
altere a sua conceitualização, ou seja, uma mesma conceitualização pode ser expressa em
várias línguas;
e) Pode ser possível estender o uso de uma ontologia genérica de forma a que ela
se adeqúe a um domínio específico. Por exemplo, se alguém precisa de uma ontologia sobre
bicicletas para construir uma aplicação é só encontrar uma ontologia sobre o domínio
genérico de veículos. Assim pode utilizar essa ontologia estendendo-a para o domínio
específico da aplicação, que no caso é de bicicletas.
Assim as ontologias possuem um papel fundamental na comparação ou combinação
de informações que possuem diferentes identificações para o mesmo conceito, ou seja, dois
termos sendo usados com o mesmo significado. Por exemplo, uma aplicação “X” referencia
uma ontologia sobre uma loja de carros, mas outra aplicação “Y” faz referencia a outra
ontologia sobre loja de veículos, então essas ontologias podem ter relação de equivalência,
sendo, então, consideradas iguais.
Quando o cliente e o provedor de serviço se comunicam com a utilização de
informações semanticamente estruturada, eles combinam o significado dos dados que são
trocados permitindo uma melhor interpretação dos mesmos.
2.6. Serviços Semânticos
Promover mecanismos que permitam que componentes de software sejam acessados
por meio de serviços Web, concede a interoperabilidade por providenciar um framework
baseado em padrões para troca de informações. Tais padrões para os serviços Web são
projetados para representar as interfaces dos serviços, como eles são distribuídos e como são
invocados, mas com a limitação em expressar o que eles fazem. A integração automática fica
comprometida por ser baseada unicamente na sintaxe e não na descrição semântica do serviço
[CARY et al, 2007].
Os serviços semânticos são concebidos pela adição das tecnologias semânticas aos
padrões dos serviços Web, promovendo o enriquecimento semântico dos mesmos. A Figura
2.12 mostra os possíveis componentes e interações que expressam o funcionamento dos
serviços semânticos.
37
Figura 2.12. Interação entre os componentes para busca semântica de serviços.
A arquitetura da Figura 2.12 difere da Figura 2.11 pela adição do componente
“Servidor Semântico”, no qual reside o algoritmo de comparação semântica. Quando da busca,
caso a pesquisa sintática (comparação sintática) não produza resultado satisfatório, o registro
invoca o algoritmo que implementa a comparação semântica, como forma de estender a
funcionalidade da busca para uma baseada na descrição semântica do serviço.
No “Servidor Semântico” além do componente “Comparação Semântica” existe o de
“Composição” o qual tem a incumbência de implementar os mecanismos necessários para a
composição dos serviços baseado em suas descrições semânticas, quando necessário. O
componente de composição se liga ao de comparação para auxiliá-lo a encontrar um serviço
composto que atende as necessidades do cliente quando não existe um serviço simples que
satisfaça a requisição.
Não apenas no processo de busca, a adição de semântica pode influenciar. A
invocação, que representa como o serviço deve ser executado, pode se beneficiar do uso de
semântica. A invocação inclui os fatos de o cliente conhecer onde o serviço reside, quais
entradas são requisitadas e quais saídas ele retorna. No entanto, um serviço pode requerer que
uma série de operações seja executada ao invés de apenas uma única chamada de método.
Cada etapa pode ser guardada para interpretação automática, como também incluir semântica
para determinar quando cada uma deve ser chamada, como interpretar suas saídas e como
tratar dados irregulares, por exemplo.
Na negociação, pode haver o ajuste de vários parâmetros como o acerto de custo, da
qualidade de serviço, dentre outros. No caso dos serviços semânticos, é possível ter serviços
atuando de acordo com o interesse do consumidor. Por exemplo, um serviço de
monitoramento de queimadas na floresta, pode realizar o levantamento de estado a cada dez
38
minutos, mas em uma situação de risco maior, tal parâmetro pode ser reduzido para dois
minutos. É possível associar semântica para capturar as informações e avaliar quais serviços
podem satisfazer a mudança de requisito.
No monitoramento pode-se usar semântica para enriquecer as informações de
indicadores como a quantidade de falhas e de sucessos da chamada do serviço, questões de
desempenho, dentre outros. Tais indicadores podem ser usados para avaliar e,
consequentemente, melhorar o fornecimento de serviços.
A composição de serviços é um dos fatores mais explorados para justificar a
utilização de serviços semânticos. Para compor diversos serviços como um único é preciso
organizá-los em um workflow. A tarefa da compra de um produto, por exemplo, pode ser
constituído por vários serviços: o provedor deve encontrar e reservar o item, receber o
pagamento, embrulhá-lo e enviá-lo. Compor serviços sem o auxílio da semântica, atualmente,
requer intervenção de profissionais especializados. O adendo de semântica pode permitir a
composição seja realizada por agentes de software, com uma menor intervenção humana.
Uma questão é que para que o sistema possa fazer uso das anotações semânticas das
descrições dos serviços e das requisições dos clientes são necessários mecanismos para
produzi-las. Os arquivos de publicação das descrições são realizados de acordo com uma
ontologia: os termos usados para a publicação do serviço são expressos por meio de
vocabulário compartilhado definido pelas ontologias de domínio [CARY et al, 2007]. As
ontologias podem ser escritas em várias linguagens (OWL [OWL, 2009], DAML+OIL
[DAML, 2010]) e os documentos de descrição dos serviços também (OWL-S [OWL-S, 2009],
WSDL-S [WSDL-S, 2010], WSMO [WSMO, 2010]). As requisições dos clientes podem ser
de formato variado, mas devem conter informações relevantes segundo a ontologia de
domínio [CARY et al, 2007] para comparação com a descrição dos serviços (realização da
comparação semântica). Na Seção 2.6.1 são mostradas as principais características da
publicação por meio de arquivos que obedecem ao padrão OWL-S.
2.6.1. OWL-S
Para fazer uso de um serviço Web, um agente de software precisa de uma descrição
do serviço formalmente compreendida por computadores, e os meios pelos quais ela é
acessada. Uma meta importante para linguagens de marcação para a Web semântica, então, é
estabelecer um framework no qual estas descrições são produzidas e compartilhadas. Os
39
serviços semânticos devem ser capazes de empregar um conjunto de classes básicas e
propriedades para sua declaração e descrição, e a estruturação de mecanismos de ontologia
fornece o meio adequado para tanto.
A estruturação da ontologia de serviços é motivada pela necessidade de fornecer três
tipos essenciais de conhecimento sobre o serviço, cada qual caracterizado pelas seguintes
perguntas:
O que o serviço exige do usuário, e o que fornece para ele? A resposta a esta
pergunta é realizada no profile. Assim, a classe serviço apresenta uma classe
SERVICEPROFILE;
Como o serviço funciona? A resposta a esta pergunta é fornecida no model. Assim,
a classe de serviço é descrita por um SERVICEMODEL;
Como o serviço é usado? A resposta a esta pergunta é fornecida no grounding.
Então a classe de serviço suporta um SERVICEGROUNDING.
A Figura 2.13 representa como estas classes estão organizadas para gerar uma
ontologia que define o serviço para sua publicação.
Figura 2.13. Ontologia na linguagem OWL-S.
A Figura 2.13 apresenta as principais classes da publicação de um serviço quando se
utiliza OWL-S. Cada classe está relacionada com a pergunta que responde e com qual
processo de automação está envolvido. Assim, por exemplo, a classe profile é utilizada para
saber o que o serviço faz e ajuda na automação do processo de descoberta do serviço. A
model visa à automação da composição de serviços, enquanto que a grounding a invocação
automática do mesmo.
40
Capítulo 3. Trabalhos relacionados
Este capítulo mostra alguns trabalhos relacionados com o objetivo de contextualizar
o SEMSUS com os demais middleware e soluções para RSSF, mostrando as características
comuns e as particularidades de cada. Primeiramente são abordados middleware baseados em
diferentes paradigmas, para em seguida as propostas semelhantes com a do SEMSUS ou por
usar SOA, ou serviços web, ou tecnologias da Web semântica, ou uma associação destes para
uso no contexto de uma solução para RSSF.
3.1. Principais middleware para RSSF
Como mostrado em [WANG et al, 2008], a abstração da programação é a base de
middleware para RSSF. A abstração promove um alto nível de programação por meio de um
conjunto de interfaces que separam o desenvolvimento de aplicações das operações de
controle da infraestrutura da rede. Três aspectos estão envolvidos quando da implementação
da abstração: o nível da abstração, o tipo de interface providenciada e o paradigma de
programação [WANG et al, 2008].
O nível de programação refere-se à perspectiva que o programador da aplicação
possui quando do desenvolvimento. Uma abstração no nível de um nodo mostra uma RSSF
como o sistema distribuído, constituído de uma coleção de nós sensores, e providencia ao
programador o suporte ao controle de cada nó. A abstração no nível do sistema promove a
perspectiva da RSSF como um único sistema, e permite ao programador implementar um
único programa constituído de subprogramas que podem ser executados nos nós. Geralmente,
a abstração no nível do nodo promove a possibilidade de desenvolvimento de aplicações com
maior flexibilidade e economia de energia, menor consumo da capacidade de processamento e
de largura de banda. Entretanto, o nível de abstração do sistema é mais fácil de uso, uma vez
que o comportamento de cada nodo pode ser automaticamente gerado.
O tipo de interface está ligado ao estilo da interface de programação provida pelo
middleware, considerando que a abstração da programação é expressa como interface.
Interfaces descritivas providenciam linguagens baseadas na SQL (Structured Query
Language) para requisição de dados, linguagens declarativas baseada em regras para
execução de comandos, ou especificações baseadas em arquivos XML para configuração. Por
41
outro lado, interfaces imperativas providenciam linguagens imperativas para escrever códigos
que interagem com a RSSF [WANG et al, 2008].
O paradigma de programação se refere ao modelo de programação das aplicações. As
aplicações para RSSF podem ser classificadas em dois aspectos: pela coleção de dados ou
dinamicidade [WANG et al, 2008]. A coleção de dado pode ser contínua, orientada a eventos
e baseada em consultas (do inglês query). A aplicação pode ser estática, mas pode possuir
algumas características móveis, como o sorvedouro ou o corpo que é objeto de
monitoramento. Para aplicações diferentes, o middleware pode usar diferentes paradigmas de
programação, como base de dados, agentes móveis e publicar/subscrever (publish/subscribe).
Por exemplo, o paradigma publicar/subscrever pode ser uma boa escolha para uma aplicação
orientada a eventos, visto sua natureza assíncrona de comunicação.
Nas próximas seções são abordados os principais middleware para RSSF que
implementam este conjunto de características.
3.1.1. Impala
O Impala [WYCKOFF et al, 1998] é um middleware para RSSF construído como
parte do projeto ZebraNet, que tem por objetivo monitorar a vida selvagem. Pela característica
das aplicações, o Impala prioriza a autonomia e mecanismos para aumento de vida da rede.
O Impala propõe um middleware assíncrono baseado em eventos, que usa módulos
de programas de modo a alocar os módulos para um menor consumo energético. Suas
principais características são a adaptabilidade e atualização de aplicações, tolerância à falhas e
o uso eficiente de energia. Referente ao requisito de adaptação, novos protocolos podem ser
incluídos e permutados durante a execução do middleware.
A arquitetura do Impala é separada em duas camadas principais. Na camada mais
alta encontram-se as aplicações e um conjunto de protocolos. Estas aplicações usam várias
estratégias para executarem a tarefa de recolherem informações do ambiente e enviá-las ao
sorvedouro. Enquanto que na camada mais baixa encontram-se três componentes: o adaptador
de aplicação, o atualizador de aplicação e o filtro de eventos.
O adaptador de aplicação adapta os protocolos de acordo com as condições de
execução de forma a promover economia de energia, robustez e melhoria no desempenho. O
atualizador de aplicação recebe e propaga atualização de softwares por meio da comunicação
sem fio e as instala nos nós sensores. O filtro de eventos captura e envia os eventos para o
42
adaptador de aplicação e para o atualizador de aplicação. No Impala cinco tipos de eventos
são possíveis: eventos de tempo, os quais indicam que o um tempo determinado acabou;
eventos de pacotes os quais indicam que o um pacote chegou pela rede; eventos de envio
realizado, os quais indicam que um pacote foi enviado ou que ouve falha no seu envio;
eventos de dados, os quais indicam que um dado sensoriado está pronto para ser processado; e
os eventos de dispositivos, que sinalizam que um dispositivo de hardware falhou.
Para economizar os recursos, o Impala adota um sistema baseado em módulos que
possuem versões associadas a números, e cada aplicação como um todo também possui um
número de versão. Antes de trocarem os módulos de software, são comunicados as versões de
modo a serem transmitidas apenas as partes que estejam realmente desatualizadas. Antes de
ser enviado pela rede, o módulo é compilado em instruções binárias. Um módulo só se torna
parte de um programa se ele for inteiramente recebido.
Embora o Impala possua meios para enviar os dados para o sorvedouro, ele não tem
suporte para fusão de dados na rede. Seu modelo de abstração não promove a
interoperabilidade de plataformas e o domínio de aplicações a serem suportadas é restrito.
3.1.2. TinyDB
O TinyDB [TINYDB, 2009] é um middleware para RSSF construído com base no
sistema operacional TinyOS que utiliza a abordagem de base dados para processar consultas.
Tal abordagem promove às aplicações a perspectiva da RSSF como um sistema de base de
dados. Apesar de ser desenvolvido usando o TinyOS, para o desenvolvedor de aplicações não
é necessário ter conhecimento da linguagem de programação deste sistema (a NesC) para
conseguir extrair os dados da rede [HADIM; MOHAMED, 2006]. O TinyDB diminui a
complexidade de interação por providenciar uma interface baseada na SQL.
O middleware providencia mecanismos que visam à diminuição do consumo
energético na coleta de dados, a partir dos nós sensores, por meio da redução do número de
mensagens a serem enviadas. Ele possui dois tipos de mensagens para processamento das
consultas, as mensagens de consulta e as de resultados, além de possuir um tipo de mensagem
para enviar comandos para os nós, chamada de mensagens de comando.
As consultas manipulam os dados de modo a permitir a indicação do tipo de leitura a
ser realizada, como temperatura ou luminosidade, além da possibilidade da definição do
grupo de interesse de nós. Para tanto o TinyDB mantém uma tabela virtual, chamada de
43
SENSORS, na qual as linhas contêm informações sobre os tipos dos sensores, identificadores
dos sensores, e a quantidade de energia restante. Por exemplo, um usuário necessita de um
alerta quando a média da temperatura ultrapassar os 80º F em qualquer sala de um andar de
um prédio. O usuário pode definir a consultas SQL semelhante à representada na Figura 3.1.
Figura 3.1. Exemplo de consulta para o TinyDB. Fonte [HADIM; MOHAMED, 2006].
As consultas são enviadas de acordo com uma árvore de roteamento mantida pelo
sistema. Então é uma abordagem descentralizada, pois cada nodo possui seu próprio
processador de consulta, e agrega os dados, e mantém as informações de roteamento.
Considerando a árvore, o nodo pai mais próximo do raiz acerta com seus filhos o intervalo de
tempo para receber os dados deles. O processo se repete a cada período definido na consulta.
3.1.3. Mires
Ao considerar as características das RSSF especialmente o fato de que a
comunicação entre as aplicações são essencialmente baseadas em eventos, o que sugere que a
tradicional abordagem de requisição/resposta (do inglês request/response) não é apropriada, o
Mires [SOUTO et al, 2006] propõe uma comunicação assíncrona de acordo com o paradigma
de publicar/subscrever, no qual os publicadores tornam disponíveis as informações para o
subscritos.
Os nós sensores, que possuem os dados coletados do ambiente, são os publicadores e
as aplicações se subscrevem para receberem o conjunto de informações que os nós podem
oferecer e que são dos seus interesses. Por exemplo, se os nós sensores podem fornecer
informações sobre a temperatura ambiental e a aplicação necessita destes dados, ela pode se
subscrever para receber os dados destes nós. Neste processo, uma mensagem de subscrição é
enviada via broadcast através da rede até alcançar os nós sensores. Depois que as mensagens
chegam aos nós, os mesmos começam a monitorar, processar, e transmitir as variáveis
ambientais de interesse da aplicação.
No Mires, a comunicação consiste em três fases principais: inicialmente os nós
informam os possíveis tópicos que podem ter subscritos (como temperatura, luminosidade)
44
coletados a partir dos nós locais. Em seguida, estas mensagens são enviadas ao sorvedouro
utilizando o algoritmo de roteamento. Uma aplicação conectada ao sorvedouro pode se
subscrever aos diversos tópicos disponibilizados pela rede. Quando uma aplicação se
subscreve, mensagens de subscrição são enviadas para rede. Após receber os tópicos de
interesse, os nós estão habilitados para publicar os dados coletados da rede de acordo com os
tópicos requisitados.
A Figura 3.2 apresenta a arquitetura de um sistema com o Mires. Como já exposto, a
camada de middleware reside sobre a do sistema operacional. O middleware é composto por
um componente de roteamento, um serviço de agregação e demais serviços. Um serviço
adicional pode ser facilmente integrado com o serviço de publicar/subscrever desde que
obedeça a interface definida.
Figura 3.2. Arquitetura do Mires. Fonte [SOUTO et al, 2006].
O principal componente da arquitetura do Mires é o serviço de publicar/subscrever.
Ele possui as funções de intermediar as comunicações entre os demais serviços, além de ser
responsável pela publicação dos tópicos de interesse, manter a lista de tópicos que a aplicação
se subscreveu e de publicar as mensagens contendo os dados relacionados aos tópicos de
interesse da aplicação.
Somente as mensagens relacionadas aos tópicos subscritos são enviadas, fato que
minimiza o dispêndio de energia pela troca de mensagens. Para a transmissão de dados, o
Mires se utiliza de um algoritmo de roteamento multi-hop.
Quando da adição de um novo serviço, o de publicar/subscrever notifica os serviços
que possuem interesse na mensagem, acerca das mensagens vindas da rede ou da aplicação.
45
Se um serviço tem o interesse de ser notificado de um determinado evento, é necessário que
ele implemente um código para tratar este evento.
3.1.4. Mate
Mate [LEVIS; CULLER, 2009] é um middleware para RSSF implementado sobre o
TinyOS que usa a abordagem de máquina virtual para promover a abstração às aplicações. Ele
torna transparente a condição assíncrona de execução do sistema operacional.
Mate propõe uma variedade de opções de reprogramação, a partir de ajustes de um
conjunto de parâmetros que realizam a atualização dos programas por meio da máquina
virtual.
A interpretação de código é a principal função do Mate. Ele divide o programa e o
encapsula em vinte e quatro instruções, cada uma com o tamanho de um byte. A divisão de
um programa em unidades torna mais fácil sua inserção na rede. Usando um modelo síncrono
que começa a execução quando em reposta a um evento, como a transmissão de um pacote,
ele evita que grandes quantidades de mensagens fiquem no buffer. O sincronismo torna o
desenvolvimento de aplicações mais simples, uma vez que o desenvolvedor não vai ter que
tratar a notificação de eventos assíncronos. Outra característica é que no Mate a atualização de
códigos usa um esquema de versões para modificar e enviar somente os dados desatualizados,
diminuindo a quantidade de comunicação e, consequentemente, o gasto de energia.
A máquina virtual proposta pelo Mate promove aumento da segurança, por tratar as
cápsulas tidas como maliciosas. Mas mesmo que o Mate seja conciso, resiliente e possua um
modelo de programação simples, seu consumo de energia é considerado alto para aplicações
que são executadas por longos períodos [MOLLA; AHAMED, 2006]. O consumo se deve
pelo gasto do processamento quando da interpretação.
3.1.5. TeenyLIME
TeenyLIME [MOLLA; AHAMED, 2006] é implementado sobre o TinyOS e é uma
extensão do LIME [MOLLA; AHAMED, 2006], o qual foi construído para MANETs . Ele
usa a abordagem de espaço de tuplas que armazenam dados.
O TeenyLIME opera distribuindo os espaços de tuplas entre os componentes da rede,
compartilhando o conteúdo do espaço e introduzindo operações reativas quando é lançado um
46
evento o qual indica que alguma informação é igual a um template. Ou seja, no middleware
existe um mecanismo de reação, no qual um código é colocado em execução se uma
determinada tupla é encontrada a partir da especificação de um modelo que descreve as
condições para o lançamento do código.
O espaço é compartilhado apenas com os vizinhos mais próximos, o vizinho a um
pulo (one-hop) na comunicação. Assim um nodo consegue ter acesso aos dados que estão em
seu espaço de tuplas como também os dos seus vizinhos. As tuplas são utilizadas para a
coordenação, armazenando não apenas os dados sensoriados, mas também as tarefas e as
requisições pendentes, descrições dos serviços disponíveis de um nodo para outro e
informações dos sistemas, como a localização e o nível de bateria restante.
Basicamente podem ocorrer três tipos de operação no espaço de tuplas: a inserção, a
leitura ou a remoção de uma tupla. Devido ser construído usando da linguagem NesC, o
middleware herda algumas características da mesma, como a execução assíncrona e a forma
split-fase das operações. O mecanismo de split-fase ocorre no TeenyLIME permitindo que
uma operação seja lançada e, somente após do tratamento da operação, seja notificado para o
lançador que a operação foi realizada ou que ocorreu algum erro na sua execução.
O TeenyLIME, entretanto, não oferece nenhum suporte interno à segurança. Seu
modelo de programação não providencia bom suporte para adaptabilidade e escalabilidade
[MOLLA; AHAMED, 2006].
3.2. Trabalhos que usam SOA no contexto das RSSF
Além dos principais middleware para RSSF, como os citados na Seção 3.1, existem
alguns trabalhos que fazem uso de SOA em soluções nestas redes, como se pode encontrar em
[DELICATO, 2005], [CHU; BUYYA, 2007], [BOTTS et al, 2006], [LUCKENBACH et al,
2005], [MALATRAS et al, 2008], e [LEGUAY et al, 2008].
A abordagem baseada em SOA proposta neste trabalho visa permitir flexibilidade na
adição de novos serviços que venham suprir os diversos requisitos das aplicações de forma
semelhante ao realizado em [DELICATO, 2005]. O middleware apresentado em [DELICATO,
2005] deixa clara a relação das RSSF e sua natureza como provedora de serviços que são
essenciais a todas as aplicações a serem executas sobre ela, como também os específicos a um
determinado domínio de aplicações, ou mesmo a uma única aplicação. Os serviços comuns
47
são os que atendem requisitos vindos, geralmente, da utilização da plataforma de aplicações,
como o gerenciamento dos recursos escassos. Os específicos estão relacionados a
características de cada aplicação ou domínio de aplicações, como as de vigilância que
necessitam de mecanismos de segurança. No referido trabalho, são apresentadas diversas
arquiteturas do sistema a partir de diferentes pontos de vista como o de lógica, que mostra a
distribuição dos componentes de software. Outro ponto de vista é mais relevante em relação a
adoção de SOA: a de implantação, que identifica dentre os componentes da RSSF as funções
específicas relacionadas a cada componente condizente com SOA. A aplicação é o cliente do
serviço, o sorvedouro é o fornecedor de serviços para aplicação e cliente dos serviços dos nós
sensores. Ainda existe um registro para permitir a aplicação encontrar os serviços.
O fato é que o middleware proposto em [DELICATO, 2005] é uma solução que
possui como plataforma de execução a J2ME (Java micro edition) [JAVAME, 2010] em sua
concepção. Estas plataformas são menos restritas que as das baseadas em Mica motes [MICA,
2010], as quais são os usados no SEMSUS. Assim, existe maior capacidade para realização
do middleware nos nós como, por exemplo, a possibilidade de tratar arquivos XML o que
ainda não pode ser realizado em nós Mica. Outro fator divergente no middleware proposto em
[DELICATO, 2005] é que sua implementação está restrita aos nós, enquanto que no
SEMSUS o middleware se encontra distribuído por um conjunto de dispositivos que
ultrapassam os limites da RSSF, como um servidor web, permitindo a distribuição da carga de
processamento, de modo que possam ser usados nós Mica na rede.
Outros esforços que utilizam os fundamentos de SOA são realizados como o
principal objetivo de conceber “sensor web” como em [CHU; BUYYA, 2007]. No referido
trabalho é mostrada a atuação do Open Geospatial Consortium (OGC) [BOTTS et al, 2006]
em tornar “sensor web” uma realidade a partir de definições de padrões chamados de Sensor
Web Enablement (SWE). Estes padrões englobam especificações de interfaces, de protocolos,
e de codificações para permitir a descoberta, o acesso e a obtenção de dados, como também
de serviços providos por sensores [CHU; BUYYA, 2007]. Destacam-se as definições de
linguagens de marcação, como a SensorML, e de vários serviços que juntos formam uma
arquitetura básica para a promoção da “sensor web”.
Uma arquitetura denominada Open Sensor Web Architecture (OSWA) é definida
pela OGC para permitir a interação baseada em serviços com a rede de sensores. OSWA é um
padrão compatível com SOA, a qual define a forma de interação e os “roles” dos diversos
serviços identificados. A implementação da arquitetura é realizada por meio do uso de
48
serviços Web, que definem um conjunto de tecnologias, bem como o consumo dos serviços
quando da interação dos serviços arquiteturais com os clientes via Web.
Algumas características que diferenciam o trabalho apresentado em [CHU; BUYYA,
2007] do SEMSUS estão basicamente relacionadas ao seu objetivo. Pois aquele foi projetado
para tornar uma RSSF acessível via Web e, portanto, define um conjunto de serviços que
tornam o acesso viável e confiável, enquanto que o SEMSUS permite que variados tipos de
serviços estejam acessíveis desde que incorporados ao middleware.
Relativo aos sensores com acesso a Web ou “sensor web”, pode-se também destacar
o trabalho em [LUCKENBACH et al, 2005], cujo objetivo é integrar uma RSSF com a Web e
promover seu uso por aplicações baseadas no protocolo de internet (IP) com a utilização de
REST [FIELDING, 2000] (The Representational State Transfer). O mapeamento entre as
requisições HTTP (Hypertext Transfer Protocol) e mensagens na RSSF é realizado pelo
HTTP-2-TinyRest, que atua de forma semelhante ao Gateway da arquitetura proposta pelo
SEMSUS.
No referido trabalho é mostrada a arquitetura da solução composta de quatro
camadas principais, que numa abordagem de baixo para cima são: os nós sensores; o Device
Control Protocol (DCP), que permite a comunicação entre diferentes protocolos de rede; a
Home Service Framework, que engloba os serviços essenciais que são dispostos as aplicações;
e a Services e Applications na qual se encontram serviços que utilizam dos nós, e as
aplicações clientes. Outra característica do projeto é o de seu desenvolvimento para ser
executado sobre uma RSSF que possui nós que usam o TinyOS (Mica), e a solução visa
fornecer serviços para o domínio de aplicações para automação residencial.
Um fator que diferencia o trabalho apresentado em [LUCKENBACH et al, 2005] do
SEMSUS é a utilização de REST como meio de interação entre a aplicação e a RSSF. Outro
fator é o proveniente da aplicação da solução, que determina um conjunto de serviços
preestabelecidos para automação residencial, não esclarecendo a possibilidade da utilização
da arquitetura para adição de novos serviços que não utilizem os que já são determinados na
solução. Outro ponto divergente, é que o foco da solução reside, basicamente, no gateway que
mapeia as requisições para mensagens das RSSF.
Mais um trabalho que utiliza SOA é o [MALATRAS et al, 2008], mas com objetivo
de integrar diversos sistemas do domínio de aplicações de “construções (prédios) inteligentes”,
fornecendo acesso aos sistemas por meio da Web e facilitando, assim, seu gerenciamento. Um
dos sistemas componentes é o de monitoramento do ambiente, realizado por uma RSSF.
49
Diversas arquiteturas com visualizações diferentes são mostradas: a de implantação que
mostra as funcionalidades dos nós sensores e do gateway separadamente, bem como outra
mais abrangente mostra que a RSSF se comunica com os demais sistemas componentes por
meio da implementação de serviços Web REST.
De forma semelhante, a [LUCKENBACH et al, 2005] existem gateways que
permitem o acesso à RSSF. Um gateway para RSSF é tido como ponto de acesso à rede, mas
existem outras redes e outros gateways. Para o gerenciamento de todos os gateways de cada
rede, é implantado outro gateway, formando uma hierarquia de gateways. Este último é o
responsável por implementar a parte para tratamento das requisições, ou seja, o que habilita as
RSSF interagir com os demais sistemas da arquitetura.
Existem diferenças entre o trabalho apresentado em [MALATRAS et al, 2008] e o
SEMSUS devido à restrição na utilização da RSSF como apenas uma fornecedora de um
único serviço para coleta de dados do ambiente, sendo então a rede um constituinte com
função definida dentro do sistema para gerenciamento de prédios inteligentes. Assim, não é
possível ter vários serviços em execução na RSSF, ao contrário ao que ocorre no SEMSUS
que permite vários serviços na rede, promovendo uma maior aplicabilidade da mesma.
Em [LEGUAY et al, 2008] também se encontra a utilização de SOA para um sistema
que utiliza as RSSF, mas seu principal objetivo é estender as características de SOA para
dispositivos com recursos escassos, como os de uma RSSF.
O trabalho tem como domínio, aplicações de configuração automática da rede e dos
serviços encontrados nela. O estilo arquitetural utilizado para descrever a arquitetura do
sistema é em camadas, mais especificamente em três: a de rede, constituída de nós de baixa
capacidade, como os das RSSF; a intermediária, constituída de nós de capacidade limitada,
como PDA (Personal Digital Assistant); e os de inteira capacidade, como os servidores web.
O sistema faz o uso de SOA nos três níveis, de modo que para implementar SOA nos
dispositivos de inteira capacidade são utilizados serviços Web, para os de capacidade
intermediária é usada a especificação Device Profile for Web Services (DPWS) [LEGUAY et
al, 2008], e para os nós sensores é proposta uma aplicação a ser executada sobre a plataforma
Mica com TinyOS, chamada de “WSN-SOA”. A interoperabilidade entre os serviços Web e o
“WSN-SOA” é realizada por meio de um gateway bidirecional de hardware Crossbow
Stargate, que possui mais recursos que um nodo Mica. Outra arquitetura em camadas
apresentada e detalhada é a da “WSN-SOA”, que mostra como os sensores abrigam os
serviços, bem como suas descobertas, seus anúncios e suas invocações.
50
Uma das diferenças entre o trabalho apresentado em [LEGUAY et al, 2008] e o
SEMSUS está no fato de que aquele se detém em reproduzir a forma de interação proposta
por SOA nos vários níveis da arquitetura, desde equipamentos que possuem uma maior
quantidade de recursos aos nós sensores. Tal abordagem não é a mesma do SEMSUS, que
coloca a RSSF unicamente como fornecedora de serviços da arquitetura. Assim, não existe
necessidade de mapear os componentes e a mesma interação do nível superior aos inferiores,
e vice-versa, da arquitetura.
De todos os trabalhos relacionados mostrados nenhum faz uso de tecnologias da Web
semântica associadas a SOA. O que é outra diferença marcante, uma vez que serviços
fornecidos pela RSSF, no SEMSUS, são semânticos. Assim, nenhum deles usa os benefícios
da adição de semântica a descrição dos serviços. A Seção 3.3 mostra alguns trabalhos em
RSSF que fazem o uso destas tecnologias.
3.3. Trabalhos que usam tecnologias da web semântica no contexto
das RSSF
Um trabalho que faz uso do termo “serviço semântico” é o [LIU; ZHAO, 2005]. O
mesmo apresenta uma arquitetura com visão de implantação da sua solução. Nela são
apresentadas quatro camadas de tipos de dispositivos diferentes, na qual a rede de sensores é a
de mais baixo nível e utilizada apenas como fornecedoras de dados coletados do ambiente.
Nas duas camadas intermediárias estão os “serviços semânticos”, que são serviços que
processam os dados providos da rede e adicionam significado a estes dados de acordo com
uma ontologia definida. Também é explorada a arquitetura lógica da solução, com análise do
comportamento de cada componente de software quando da interação com o cliente.
De forma resumida, existem três principais diferenças do trabalho apresentado em
[LIU; ZHAO, 2005] em relação ao SEMSUS. Primeiramente, naquele o termo “serviços
semânticos” se refere aos componentes de software que trabalham com os dados originados
nas RSSF adicionando semântica aos mesmos, enquanto que no SEMSUS são serviços que
utilizam as tecnologias da Web semântica para aumentar o nível de automação das tarefas
relacionadas aos serviços web. Outra questão é a rede utilizada em [LIU; ZHAO, 2005] que
pode ser uma rede de diversos tipos de sensores com comunicação sem fio ou não como, por
exemplo, um conjunto de câmeras que captam as imagens de um ambiente. Esta rede é usada
como fornecedora de uma única funcionalidade: a de gerar dados para as camadas de mais
51
alto nível. Enquanto que no SEMSUS a rede é especificamente formada por nós sensores sem
fio, como os do tipo Mica, os quais realizam processamento in-network das informações
coletadas, de modo a fornecer um conjunto de funcionalidades que são expostos como
serviços semânticos.
Outro trabalho que faz uso de serviços semânticos é [IQBAL et al, 2009], que utiliza
ontologias para representar os dados dos nós sensores, como também seus serviços, além de
permitir que tais serviços possuam anotações semânticas na publicação e descoberta. No
trabalho é apresentado um modelo em três camadas, assim definidas: Plataforma, que está
relacionada ao hardware e ao sistema operacional, Software que permite tornar transparente a
heterogeneidade da plataforma, e Semântica que torna transparente a heterogeneidade
semântica da de Software. Um fato interessante do trabalho é a proposta de fazer o uso das
ontologias que descrevem os dados e os serviços na RSSF. Ou seja, cada nodo pode
representar suas capacidades e seus dados por meio das ontologias de domínio, as quais são
apresentadas e analisadas no trabalho. O uso de ontologias permite que nós de diferentes
plataformas e que usam diferentes representações de dados possam se comunicar entre si
tornando, assim, a rede mais flexível.
A diferença entre o trabalho em [IQBAL et al, 2009] e o SEMSUS está no fato que
os mecanismos de descrição dos dados e dos serviços fornecidos, que utilizam as ontologias,
são realizados no ambiente da RSSF pelos nós sensores. No SEMSUS a publicação ocorre em
um nível mais elevado da arquitetura devido à limitação dos sensores que não permitem a
utilização e processamento de arquivos como os OWL (Web Ontology Language). Outro fator
é que na proposta em [IQBAL et al, 2009] é realizada a descrição das capacidades de cada
nodo de uma RSSF, enquanto que no SEMSUS é realizada a descrição dos serviços de uma
RSSF.
É importante observar que dos trabalhos já levantados, nenhum se utiliza de uma
Linguagem para Descrição de Arquitetura (ADL) para formalizar suas arquiteturas, como foi
feito pelo SEMSUS, o que permitiu o uso de um conjunto de ferramentas como as de
validação e testes arquiteturais, mesmo antes da concepção dos códigos que realizam o
sistema.
52
Capítulo 4. Middleware SEMSUS
Este capítulo apresenta o middleware SEMSUS, começando pela sua arquitetura,
mostrando sua organização e a interação entre seus componentes. Em seguida são
apresentados os principais pontos que promovem a realização da arquitetura em um sistema,
como os padrões utilizados e as tecnologias. Após a exposição inicial do middleware, a
execução do mesmo é o foco de discussão, explorando as etapas de publicação, busca, seleção
e invocação dos serviços semânticos fornecidos por uma RSSF.
4.1. Arquitetura do middleware
A arquitetura de software em sistemas de middleware desempenha um papel
importante, visto que tais sistemas geralmente se apresentam de forma complexa em que seus
componentes se encontram espalhados em várias máquinas distintas. Assim a arquitetura
permite uma visão macro do sistema e sua organização. A arquitetura mostra como os
componentes estão distribuídos e como eles interagem entre si, para alcançar os objetivos do
sistema.
Por questões didáticas, as arquiteturas podem ser organizadas em diferentes pontos
de vistas que destacam características específicas do modelo arquitetural. Por exemplo, a
separação em componentes de software possibilita uma visão lógica do sistema. Entretanto,
um ponto de vista importante para sistemas de middleware é o que apresenta a perspectiva de
separação dos componentes de software segundo sua locação em máquinas reais. Este ponto
de vista é chamado de implantação (do inglês deployment).
A arquitetura do SEMSUS considera não apenas a divisão lógica do sistema em
componentes de software, mas também sua organização em diferentes dispositivos,
oferecendo uma visão de implantação da solução. Outro fato é que sua arquitetura está de
acordo com as organizações de SOA, representada na Figura 2.10, e de serviços semânticos,
mostrada na Figura 2.12. Visto que o SEMSUS utiliza SOA e faz uso das vantagens dos
serviços semânticos.
Mais especificamente, o uso de SOA ocorre de forma semelhante ao apresentado em
[DELICATO, 2005], no qual uma RSSF pode ser vista pela perspectiva de fornecedora de
serviços que atendem as necessidades das aplicações. O fato é que tal abordagem propicia a
53
adoção de SOA para a solução de middleware em RSSF além de considerar o middleware
como um fornecedor de serviços para aplicações.
Quanto ao uso dos serviços semânticos, a RSSF possui o papel de Provedor de
serviços e a aplicação é quem consome os serviços. Assim, a aplicação que funciona
utilizando-se do SEMSUS, tem a perspectiva da rede como fornecedora de serviços acessados
por meio da Web via uma API definida. Ou seja, tem-se conforme a Figura 2.12, a realização
do componente Provedor pela rede e Cliente pela aplicação, enquanto o Registro é realizado
por uma terceira máquina, responsável por executar os mecanismos de comparação sintáticos
e semânticos na busca de serviços. O uso das tecnologias da Web semântica permite maior
automação nos mecanismos envolvidos na busca, invocação, composição e monitoramento
dos serviços quando da interação da aplicação com registro e com a rede.
Assim, as próximas seções visam analisar cada um destes componentes de software,
bem como suas interações. Os detalhes da relação da aplicação com os demais componentes
do SEMSUS são mostrados na Seção 4.1.1 pela análise da constituição interna do
componente Cliente, no qual reside a aplicação que usa os serviços do SEMSUS. Enquanto
que na Seção 4.1.2 é detalhada a composição do componente Provedor. Uma vez que RSSF
está como provedora de serviços, esta seção fornece a visão do SEMSUS quando da sua
organização na RSSF.
4.1.1. Cliente
Como o objetivo do middleware é de fornecer um conjunto de serviços para
aplicação, torna-se necessário especificar como a aplicação se relaciona com os demais
elementos arquiteturais, bem como mostrar em qual componente de hardware ela se encontra.
Uma vez que aplicação utiliza-se dos serviços Web fornecidos pelo componente
Provedor, ela se encontra no componente Cliente. Outro fato, é que ela faz uso da abstração
de programação fornecida pela API do middleware SEMSUS. A Figura 4.1 apresenta a
composição interna do componente Cliente.
54
Figura 4.1. Composição interna do Cliente.
É por intermédio da abstração da programação que a aplicação interage com os
mecanismos que o SEMSUS fornece. Estes mecanismos, mais especificamente são dois: o de
busca no Registro por serviços que atendam as necessidades da aplicação, e o de invocação do
serviço encontrado na busca, o qual é fornecido pelo Provedor. Na Figura 4.2 encontra-se uma
evolução a partir da organização dos serviços semânticos, apresentada na Figura 2.12, pela
especificação interna do Cliente. Nela evidenciam-se as interações do Cliente com o Registro
e com o Provedor.
Figura 4.2. Interações do Cliente com o Registro e com o Provedor.
4.1.2. O provedor de serviços
Ao ter a RSSF como fornecedora de serviços semânticos, torna-se necessário
detalhar quais são as suas funcionalidades dentro da arquitetura, sua constituição e como ela
interage com os demais componentes arquiteturais a fim de executar as diversas atividades do
middleware.
Por questões didáticas, a abordagem adotada para apresentar a composição interna do
componente Provedor é a de mostrar primeiramente seus principais componentes, para em
55
seguida especificar cada um destes pelos componentes que os constituem em nível menor de
abstração. Assim, são analisados primeiramente os componentes mais complexos para em
seguida mostrar como ocorrem suas constituições.
Considerando a organização interna do componente Provedor, há o componente
RSSF (Rede de Sensores Sem Fio), o qual tem como cliente uma aplicação que invoca os
serviços por ele fornecidos por meio dos serviços semânticos. A Figura 4.3 apresenta o
provedor e os seus principais componentes, em especial a RSSF.
Figura 4.3. Visão dos Componentes internos do Provedor.
A Figura 4.3 mostra que a constituição básica (de maior nível de abstração) do
Provedor são dois componentes básicos: o Web Server e a RSSF. Tal distinção se deve
principalmente a implantação física do sistema, a qual mostra que o Web Server e a RSSF
estão em ambientes computacionais distintos. O servidor possui, quando da publicação, a
funcionalidade de publicar o serviço no registro e, quando da invocação, a de ser o primeiro a
receber e tratar as requisições dos clientes. O mesmo permite maior escalabilidade da parte do
Provedor por possuir mecanismos para tratamento de requisições de vários clientes distintos.
A RSSF é um ambiente formado pelos nós sensores e sorvedouro. É fato que o contexto e as
soluções usadas pelos dois componentes são diferentes: o Web Server é um ambiente sem
muitas restrições de recursos, ao contrário da RSSF. Assim, para realizar a comunicação entre
os dois é necessário um conector que possua a funcionalidade de adaptar os dois contextos
distintos: o adaptador [TAYLOR et al, 2009]. Por exemplo, o Web Server pode ter soluções
baseadas em uma linguagem que não tem como um dos principais objetivos a economia de
recursos, como a Java; enquanto que na RSSF é necessária uma linguagem que permita o
controle dos escassos recursos dos nós, como a NesC.
Mais especificamente, em um nível menor de abstração, existem componentes
lógicos que estão no Web Server e na RSSF, como mostra a Figura 4.4.
56
Figura 4.4. Visão do Provedor a partir da constituição da RSSF e do Web Server.
No Web Server existe o “Gateway” que implementa as principais funcionalidades do
Web Server para o sistema. Dentre elas podem se destacar a recepção das requisições dos
clientes, e a partir delas, gerar e enviar as mensagens para as RSSF. Como o próprio nome
sugere, ele é o componente pelo qual o Provedor realiza as interações com os demais (Cliente
e Registro) externos a ele. Tais interações se traduzem em publicar o serviço no Registro e a
Ligação/Invocação com o Cliente.
Devido à possibilidade de uma mesma RSSF fornecer vários serviços, cada serviço
precisa de identificador associado para poder ser invocado, em tempo de execução, por meio
de mecanismos que mapeiam tal identificador com o código que implementa o serviço
determinado. Assim, quando da interação com o Cliente, o Gateway fica responsável por
informar um identificador referente à requisição de forma que a mesma seja, posteriormente,
mapeada para uma chamada ao serviço específico dentro da RSSF. Caso exista alguma
resposta a ser retornada aos componentes externos, o Gateway apenas encaminha as respostas
sem realizar nenhuma modificação na mesma.
Na RSSF existem dois componentes importantes: o Sorvedouro e o Nodo Sensor. O
Sorvedouro funciona como gateway da mesma, de forma que qualquer comunicação da rede
com o ambiente externo acontece através dele. Assim, o Gateway e o Sorvedouro possuem
funções semelhantes, visto que ambos são os meios pelos quais ocorre a interação com o meio
externo, o Gateway referente ao Provedor e o Sorvedouro à RSSF.
57
Os nós têm a principal função de interagir com o ambiente no qual está inserido,
realizar o processamento de dados dentro da rede (in-network) e enviá-los para o Sorvedouro.
Dentre todos os componentes os que possuem maior restrição de recursos são os nós.
A interação entre os componentes Sorvedouro e Nodos Sensores, se dá via
comunicação sem fio por rádio. Mais especificamente, o conector “Roteador de mensagens”
representa esta comunicação baseada em trocas de mensagens, que ocorre também entre os
demais nós da rede. Não necessariamente deve existir um protocolo de roteamento para tal
comunicação, a qual pode ocorrer, por exemplo, para todos os nós da rede via broadcast. O
componente que representa a RSSF numa perspectiva mais detalhada é ilustrado na Figura 4.5.
Figura 4.5. Visão da Composição interna do componente RSSF.
Na Figura 4.5 pode-se observar que no Sink (Sorvedouro) existem dois componentes
lógicos: o Gerenciador e o Dispatcher. O primeiro possui a funcionalidade de gerenciar os
identificadores de cada serviço implementados nos nós sensores. A gerência se refere em
controlar um valor apropriado que identifica um serviço de modo que o Dispatcher possa,
posteriormente, fazer a escolha correta do algoritmo que implementa o serviço chamando-o
em tempo de execução. O componente recebe este nome por obedecer ao padrão Dispatcher
[GAY et al, 2007]. Este objetiva tornar o sistema flexível permitindo a escolha de
funcionalidades distintas em tempo de execução. Outra consequência do uso do Dispatcher é
a abertura do middleware pela possibilidade de manutenção do sistema em componentes
específicos quando da adição ou remoção de serviços.
Para que os serviços façam parte do sistema, eles necessitam implementar uma
interface definida pelo Dispatcher. Assim, na adição de um novo serviço, o código que o
58
implementa deve obedecer à interface especificada, bem como é necessário destinar um
identificador para o serviço, de modo que o Gerenciador possa passá-lo ao Dispatcher e este
selecionar o serviço correto. Na remoção de um serviço é necessário que seja removido seu
identificador para que não seja mais invocado.
É importante observar que o Gerenciador e o Dispatcher empregam a técnica de
ligação tardia [TANENBAUM; STEEN, 2007], que pode ser usada para selecionar uma
implementação de um serviço de acordo com a capacidade atual da rede. Por exemplo,
existem dois códigos que implementam o mesmo serviço de envio de mensagens na rede, mas
um é mais rápido que outro em detrimento do aumento do consumo de recursos dos nós. Caso
a rede tenha recursos suficientes, pode-se escolher o algoritmo que responde mais rápido.
Caso contrário, deve ser selecionado o outro. O SEMSUS não possui implementado nenhum
mecanismo automático de escolha baseado nas informações dos recursos da rede, ou seja,
usando um mecanismo reflexivo. A escolha do serviço é determinada pelo identificador do
serviço, mas existe a possibilidade de adicionar a característica reflexiva ao middleware de
forma a trabalhar junto ao Dispatcher para escolha do serviço apropriado de acordo com as
condições da rede.
A escolha do código que implementa o serviço, sem que haja problemas na forma de
interação com a aplicação (no Cliente) é possível devido à utilização de interfaces pelos
padrões dos serviços Web. Como a comunicação é baseada na interface exposta, é
transparente para o Cliente os “por menores” da implementação, desde que sejam obedecidos
os contratos.
Nos nós sensores encontram-se os códigos que implementam as funcionalidades que
são expostas como serviços aos clientes. Então a requisição é passada por um conjunto de
componentes que fazem parte do provedor até serem tratadas pela implementação adequada
do serviço que residem nos nós. Ou seja, a requisição vinda do Cliente é recebida
primeiramente pelo Gateway no Web Server, passa pelo Gerenciador e pelo Dispatcher no
Sink, até chegar as implementações nos nós sensores. É importante observar que as
implementações nos nós simplesmente fornecem funcionalidades, tidas neste nível como
serviços no sentido genérico do termo e não referente à complexidade imposta por um serviço
Web, como o uso de SOAP, o que seria inviável no ambiente restrito da RSSF. No Web
Server, o Gateway é quem realmente realiza as complexidades dos serviços Web, recebendo,
por exemplo, as requisições das aplicações via Web e mapeando-as em estruturas e chamadas
de procedimentos típicas ao ambiente das RSSF.
59
Por possuírem restrições, apenas a implementações dos serviços encontram-se nos
nós, mas não necessariamente todos os nós precisam implementar todos os serviços. O que
define quais serviços cada nodo implementa é projeto de cada serviço que define sua
abrangência no ambiente. O fato é que toda a arquitetura foi projetada visando diminuir a
carga sobre a RSSF (o sink e, principalmente, os nós sensores). A arquitetura fornece, então,
uma forma de se distribuir a carga do middleware por diversos dispositivos distintos desde
servidores web a nós sensores.
4.1.3. Arquitetura do SEMSUS
Considerando as composições internas do Cliente e do Provedor tratadas nas seções
anteriores, a organização do SEMSUS fica conforme mostra a Figura 4.6.
60
Figura 4.6. Visão geral da interação entre componentes do middleware SEMSUS.
A Figura 4.6 apresenta uma visão a partir da perspectiva de implantação dos
componentes de software nos componentes de hardware. Além de apresentar os componentes,
a arquitetura mostra a semântica de interação entre eles por meio dos conectores. Caso sejam
desconsiderados os conectores e a distribuição dos componentes de software em máquinas
reais, e colocados os elementos arquiteturais organizados em camadas, a arquitetura fica como
apresenta a Figura 4.7.
61
Figura 4.7. Arquitetura do SEMSUS.
Como a arquitetura da Figura 4.7 mostra, O SEMSUS fornece os mecanismos de
busca e invocação de serviços. O primeiro é dividido em busca semântica e sintática. A busca
sintática ocorre por meio do “Comparador Sintático”, enquanto que a semântica pelo
“Comparador Semântico”. Para a comparação sintática é necessário o acesso à base de
“Descrição Sintática” dos serviços, onde ser encontram os arquivos WSDL proveniente da
publicação. De forma semelhante, para a comparação semântica é necessário o acesso às
descrições enriquecidas com informações semânticas no repositório de “Descrições
Semânticas” dos serviços. O enriquecimento semântico da descrição é derivado das
ontologias de domínio que definem os significados dos termos usados.
A invocação do serviço é executada após a aplicação buscar e encontrar o serviço
que atende suas necessidades. Especificamente, é pela invocação que a aplicação faz uso das
diversas funcionalidades que a RSSF pode oferecer. Estas funcionalidades estão representadas,
no bloco de invocação, como serviços que são escolhidos pelo Manager e Dispatcher. O
Gateway é componente que recebe as requisições Web e as mapeia para mensagens a serem
trocadas na RSSF.
Outra função do Gateway é a publicação dos serviços nas bases de descrições. A
publicação não está representada na arquitetura da Figura 4.7 porque não é um serviço
fornecido as aplicações. Ela é utilizada quando um provedor de serviços, por intermédio do
Gateway, publica as descrições dos seus serviços no registro. Ou seja, trata-se de uma
62
interação entre o provedor e o registro, sem a participação da aplicação que é o cliente do
serviço. A aplicação apenas busca e faz uso dos serviços que tiveram suas descrições
previamente publicadas nas bases.
Como a arquitetura da Figura 4.7 não apresenta o ponto de vista de implantação é
importante observar que nem todos os componentes estão na RSSF. No bloco de invocação,
por exemplo, existe outro ambiente, o Web Server que mantém apenas o Gateway, enquanto
que o Manager, o Dispatcher e os serviços se encontram na RSSF. Assim, requisições
chegam primeiramente ao Gateway, no Web Server, o qual encaminha para os componentes
localizados na RSSF, até alcançar as implementações das funcionalidades dos serviços.
4.1.4. Propriedades da arquitetura do middleware
A organização do SEMSUS, apresentada na Figura 4.6, foi concebida com a
utilização de um conjunto de ferramentas chamado ArchStudio [ARCHSTUDIO, 2010]. O
ArchStudio usa a xADL[XADL, 2010] como linguagem para descrição da arquitetura e
algumas de suas características são derivadas das características da linguagem. A xADL
possui mecanismos para extensão que visa suportar domínios e aplicações específicas pela
adição de novos esquemas XML. Outra característica da xADL é a de permitir testar algumas
propriedades arquiteturais, antes da implementação da mesma.
O ArchStudio é constituído por um conjunto de ferramentas como a Archipelago, que
permite a edição e visualização gráfica da arquitetura. O modelo da Figura 4.6, por exemplo,
foi gerada utilizando-o. Além deste editor ainda existe outro, que não permite a visualização
gráfica da arquitetura, chamado de ArchEdit, mas que possui mais opções de edição que o
Achipelago.
Como já explorado, o xADL permite expressar componentes, conectores, e os links
que os ligam. Outro aspecto do xADL está ligado ao tipo dos elementos arquiteturais. Dois
componentes do mesmo tipo, por exemplo, devem possuir a mesma organização interna
(estrutura) e o mesmo comportamento, e uma interface deve-se ligar a outra do mesmo tipo.
Além disto, outra característica que não é visível pelo Archipelago, mas que faz parte da
descrição arquitetural é tipo de serviço dos elementos arquiteturais. Ele expressa se um
componente, fornece, requer, ou fornece e requer um serviço. Se um componente fornece um
serviço e está ligado a outro, este outro deve requerer tal serviço.
63
Outra ferramenta que faz parte do ArchStudio é o ArchLight, a qual serve para
realizar a análise arquitetural. Aos usuários é fornecida uma interface para escolha e execução
de testes que verificam propriedades das descrições arquiteturais.
As verificações executadas sobre o arquivo xADL da arquitetura do SEMSUS são
apresentadas na Tabela 4.1. Ela apresenta o nome do teste, sobre qual objeto do modelo ele
atua e o que ele verifica.
Tabela 4.1. Conjunto de testes sobre o modelo arquitetural.
Nome
Sobre
Significado
No Duplicate Id
Todo modelo
Verifica se há identificadores duplicados na
arquitetura
Description Non-
Empty
Estrutura
Checa a presença de descrições não vazias nas
estruturas
Description Presence
Estrutura
Checa a presença de descrições nas estruturas
Id Present
Estrutura
Checa a presença de identificadores nas
estruturas
Description Non-
Empty
Componente**
Checa a presença de descrições não vazias nos
componentes
Description Presence
Componente
Checa a presença de descrições nos
componentes
Id Present
Componente
Checa a presença de identificadores nos
componentes
Description Non-
Empty
Interface*
Checa a presença de descrições não vazias nas
interfaces
Description Presence
Interface
Checa a presença de descrições nas interfaces
Direction Non-
Empty
Interface
Checa a presença de direções não vazias nas
interfaces
Direction Valid
Interface
Checa a presença de direções válidas nas
interfaces
Id Present
Interface
Checa a presença de identificadores nas
interfaces
Anchors connect to
Interface
Links
Checa se as pontas dos links estão conectadas
em interfaces
Anchors Present
Links
Checa a presença de uma conexão no final do
link
Anchors Valid
Links
Checa a validade dos links para uma ligação
Description Non-
Empty
Links
Checa a presença de descrições não vazias nos
links
Description Presence
Links
Checa a presença de descrições nos links
Id Present
Links
Checa a presença de identificadores nos links
Interface Directions
Compatible
Links
Checa se duas interfaces ligadas possuem
direções compatíveis
Interfaces Types
Identical
Links
Checa se duas interfaces ligadas possuem o
mesmo tipo
Signature Service
Types Compatible
Links
Checa se as assinaturas de objetos ligados são
compatíveis
64
Two Points
Links
Checa a presença de apenas duas extremidades
nos links
ArchTypes Present
Elementos
arquiteturais
Checa a presença de tipagem nos elementos
arquiteturais
No Multiple
ArchTypes
Elementos
arquiteturais
Checa a presença de apenas um tipo nos
elementos arquiteturais
Signature link->
Signature
Interface
Checa se os tipos das interfaces estão ligados
aos tipos definidos de interfaces
Signature Link
Present
Interface
Checa se as interfaces possuem um tipo
associado
Signature Link Valid
Interface
Checa a validade do tipo da interface
Type link ->
ComponentType
Componentes
Checa se os tipos de componentes estão
ligados a tipos definidos de componentes
Type Link Present
Componentes
Checa se o componente está associado a um
tipo
Type Link Valid
Componentes
Checa a validade do tipo do componente
Description Non-
Empty
Tipos de
componente
Checa a presença de descrições não vazias nos
tipo de componente
Description Present
Tipos de
componente
Checa a presença de descrições nos tipos de
componente
Id Present
Tipos de
componente
Checa a presença de identificadores nos tipos
de componente
Description Non-
Empty
Tipos de
interface
Checa a presença de descrições não vazias nos
tipo de interface
Description Present
Tipos de
interface
Checa a presença de descrições nos tipos de
interface
Id Present
Tipos de
interface
Checa a presença de identificadores nos tipos
de interface
Direction Non-
Empty
Tipos de
interface
Checa a presença de direções não vazias nos
tipo de interface
Direction Present
Tipos de
interface
Checa a presença de direções nos tipos de
interface
Direction Valid
Tipos de
interface
Checa a validade da direção do tipo da
interface
Service Type Non-
Empty
Tipos de
interface
Checa a presença de tipos de serviços não
vazios nos tipos de interface
Service Type
Present
Tipos de
interface
Checa a presença de tipos de serviços nos
tipos de interface
Service Type Valid
Tipos de
interface
Checa a validade do tipo de serviço do tipo da
interface
ArchStructure link->
ArchStructure
Estruturas
Checa se os tipos de estruturas estão ligados a
tipos definidos de estruturas
ArchStructure Link
Present
Estruturas
Checa se as estruturas possuem um tipo
associado
ArchStructure Link
Valid
Estruturas
Checa a validade do tipo estrutura
* As validações sobre as interfaces ocorrem tanto nas dos componentes como nas dos conectores.
65
** Todas as validações que ocorrem nos componentes também foram realizadas sobre os conectores.
Outros testes também foram executados, mas por exigir conhecimentos detalhados de
elementos específicos da xADL, foram suprimidos por entendermos que foge do escopo do
trabalho detalhar elementos arquiteturais complexos e específicos, como por exemplo, o
elemento de Mapeamento entre Interfaces e Assinaturas. No total, cerca de cem testes
distintos foram executados para validação da arquitetura do SEMSUS.
4.2. Interações entre componentes nas principais atividades
Obedecendo a forma de interação e os componentes que SOA propõe, o SEMSUS
está distribuído em três principais componentes - o Cliente, o Provedor e o Registro - e três
principais interações – Publicar, Buscar, Ligar/Invocar. O Registro é estendido em mais um
componente para permitir a adição dos mecanismos que utilizam as tecnologias da Web
Semântica: o Servidor Semântico. Primeiramente, o provedor do serviço, no qual reside a
RSSF, deve publicar em um registro as descrições dos serviços que ele pode oferecer. São
realizadas a publicação da descrição sintática do serviço no Registro e a semântica no
Servidor Semântico. Assim, existem duas descrições, uma que permite uma interação baseada
nas descrições sintáticas dos serviços e outra nas descrições semânticas. O diagrama de
interação da Figura 4.8 apresenta como ocorrem as interações entre estes componentes.
Figura 4.8. Interação entre os principais componentes do sistema.
Na publicação é necessário passar informações do serviço, que pode ser uma
interface para comunicação com o mesmo, de modo que identifique as suas especificidades,
66
como seu endereço na Web, suas operações e parâmetros, dentre outros. Depois de publicado,
o serviço está disponível para ser localizado e invocado pela aplicação no Cliente.
Para aplicação, o SEMSUS fornece uma API de forma que ela possa buscar e invocar
os serviços que atendam suas necessidades. A busca pode se basear em mecanismos sintáticos,
nos quais a aplicação especifica em suas requisições algumas características de interesse e
estas são comparadas sintaticamente com as descrições sintáticas dos serviços localizadas no
Registro; ou em mecanismos semânticos, nos quais as características de interesse, passadas na
requisição, são semanticamente anotadas para uma comparação semântica com as descrições
semânticas dos serviços no Servidor Semântico. Por exemplo, a aplicação pode especificar o
tipo de entradas que ela deseja de um serviço. Na busca sintática são comparados se os tipos
são escritos de forma idêntica, enquanto que na semântica se eles representam o mesmo
significado. Este significado é definido em uma ontologia compartilhada entre o cliente
requisitante e o servidor semântico que executa a comparação semântica.
Depois de o serviço ser encontrado, ele é invocado pelo Cliente que interage
trocando dados necessários e provenientes da sua execução, ou seja, as entradas e as saídas.
Cada interação apresentada (publicar, buscar, invocar/ligar) é formada por um
conjunto mais específico de interações. A Seção 4.3 apresenta estas especificidades
associadas ao conjunto de ferramentas e tecnologias que permitem a concretização da
dinâmica do sistema.
4.3. Detalhes e ferramentas utilizadas nas interações
Na ação de publicar, o provedor anuncia seus serviços tanto com a descrição sintática
como a semântica. A Figura 4.9 mostra os detalhes de tal processo e as tecnologias usadas
para tanto.
Figura 4.9. Interações e ferramentas utilizadas na publicação dos serviços.
67
É importante observar que para a publicação sintática é usada a ferramenta
Java2WSDL [AXIS, 2010], enquanto que para a semântica a WSDL2OWL-S[WSDL2OWL-
S, 2010]. A primeira transforma arquivos de código fonte Java em WSDL, e a segunda o
WSDL gerado em OWL-S. O WSDL é usado na comparação sintática, no jUDDI [JUDDI,
2010], enquanto que o OWL-S na comparação semântica no Matchmaker [MATCHMAKER,
2010].
Outra atividade a ser executada é a invocação do serviço pela aplicação. As
interações entre os componentes envolvidos e as ferramentas utilizadas no processo são
apresentadas na Figura 4.10.
Figura 4.10. Interações e ferramentas utilizadas na invocação dos serviços.
Pela Figura 4.10, pode-se observar que o processo se inicia com a aplicação
realizando a invocação ao provedor do serviço. O primeiro componente do provedor que
recebe as requisições é o Gateway, que está em um servidor web Apache Tomcat [TOMCAT,
2010]. No Gateway, as requisições são transformadas em mensagens a serem enviadas para o
ambiente onde estão as RSSF. As redes se caracterizam pela utilização do sistema operacional
TinyOS e da sua linguagem de programação NesC. A utilização dos dois se deve a diversas
características, como a suas amplas utilizações nas RSSF, bem como em suas adequações aos
requisitos necessários em uma RSSF.
Na RSSF, o Gerenciador que recebe a mensagem do Gateway repassa a requisição
com o identificador (id) do código que implementa o serviço requisitado pelo Cliente. É
baseado neste identificador que o Dispatcher chama, em tempo de execução, o componente
que implementa o serviço específico. Os resultados da execução do serviço são retornados no
caminho inverso até chegar ao Cliente. Assim, todo o processo permite a invocação do código
em uma RSSF como um serviço semântico.
68
Capítulo 5. Implementação da arquitetura e estudo de caso
Este capítulo mostra a implementação da arquitetura apresentada no capítulo 4 e os
detalhes para tanto. As tecnologias utilizadas, a API fornecida à aplicação, bem como o uso
de ferramentas é analisado. Com o objetivo de validar a implementação, também é mostrado
um cenário de utilização dos serviços e outro para uso das tecnologias da web semântica no
SEMSUS.
Para melhor compreensão, a abordagem ocorre seguindo a perspectiva dos elementos
arquiteturais já conhecidos a partir de uma análise de estruturas mais complexas para os
componentes mais simples, ou seja, de um maior nível de abstração para um menor. Assim,
primeiramente são abordados os três principais componentes arquiteturais (o Registro, o
Cliente e o Provedor) para em seguida as especificidades de cada um ser analisado.
5.1. Implementação do Registro
A implementação do registro basicamente se dá pela utilização de ferramentas de
terceiros, mais especificamente o Matchmaker. Ele é uma extensão do jUDDI , uma
implementação Java de UDDI, e utiliza para descrição semântica dos serviços arquivos que
seguem a especificação OWL-S. Assim alguns se referem ao Matchmaker como OWL-
S/UDDI Matchmaker. Mais especificamente o jUDDI implementa o componente Registro da
arquitetura e o Matchmaker implementa o Servidor Semântico.
O Matchmaker é um engenho de pesquisa para serviços Web baseado no algoritmo
LARKS [SYCARA et al, 2002], como também usa algumas ideias do algoritmo de
comparação DAML-S [PAOLUCCI et al, 2002]. A escolha do Matchmaker se deve ao
conjunto de ferramentas que podem ser usadas em conjunto com ele, como a Matchmaker
Client [MATCHMAKER, 2010], usada no lado cliente, a qual é detalhada na Seção 5.2.
5.2. Implementação das interações com o registro
Para interação com o registro, implementado pelo Matchmaker, é necessário que haja
no cliente e no provedor a utilização do Matchmaker Client quando da pesquisa e publicação
dos serviços semânticos.
69
Especificamente, o Matchmaker Client é uma classe Java que permite, por meio de
seus métodos e propriedades, a interação com o Matchmaker de forma a publicar, pesquisar e
remover publicações de serviços semânticos. Internamente, a classe usa a API fornecida pelo
jUDDI. A Figura 5.1 apresenta a arquitetura básica do Matchmaker, junto com o Matchmaker
Client.
Figura 5.1. Arquitetura do Matchmaker.
Como mostra a Figura 5.1 para conseguir publicar um serviço é necessário fornecer
os arquivos OWL-S que especificam suas características. Para gerar esses arquivos a partir de
um código Java deve-se primeiramente usar a ferramenta Java2WSDL, encontrada no Apache
Axis, que transforma o arquivo Java em um WSDL, e depois a WSDL2OWL-S transforma o
WSDL em uma especificação OWL-S do serviço. Contudo, existe o problema que nem todas
as informações necessárias para gerar a especificação OWL-S de um serviço se encontram em
um arquivo WSDL, então se faz necessário à utilização de outra ferramenta para editar
manualmente os arquivos gerados pelo WSDL2OWL-S e adicionar tais informações. A
ferramenta que facilita este trabalho de edição é a OWL-S editor [OWL-SIDE, 2010].
Após a especificação OWL-S ter sido terminada, o profile dela deve ser fornecido ao
Matchmaker Client para publicação do serviço. O processo de exclusão de um anúncio é
semelhante, devendo-se passar o profile para tanto. A Figura 5.2 apresenta um código Java
70
para adição de uma publicação. A utilização de “//” são comentários utilizados para explicar o
código que vem abaixo na linha seguinte.
Para realizar a pesquisa semântica dos serviços no registro, devem-se passar os
parâmetros da busca. Tais parâmetros podem ser a URL (Uniform Resource Locator) do
profile, ou características definidas por meio de um objeto chamado de CapabilitySearch,
para serem comparados com as publicações que existem no registro. Estas características
podem ser, por exemplo, os conceitos que definem as entradas e saídas da execução do
serviço. A Figura 5.3 apresenta uma busca que utiliza o profile e a Figura 5.4 que usa as
características das publicações, mais especificamente as ontologias que definem as entradas e
saídas dos serviços.
Figura 5.2. Exemplo de código para registro de um serviço usando o Matchmaker Client.
//Criação um novo Matchmaker Client
OWLSMatchmakerClient mc = new OWLSMatchmakerClient();
//Registro o profile a partir de sua URL
BusinessDetail bd =
mc.register("http://www.daml.ri.cmu.edu/iswcdemo/navn/BravoAirProfile.owl");
//Criação do Matchmaker Client
OWLSMatchmakerClient mc = new OWLSMatchmakerClient();
//Busca que retorna uma lista de serviços encontrados para o objeto
MatchmakerResultList
MatchmakerResultList mrl =
mc.query("http://www.daml.ri.cmu.edu/iswcdemo/navn/BravoAirProfile.owl");
Figura 5.3. Exemplo de código de uso do Matchmaker Client na busca.
71
É importante observar que as pesquisas realizadas não retornam necessariamente
apenas uma única publicação de serviço, mas um conjunto delas. Este conjunto é formado
pelos anúncios encontrados que podem satisfazer os requisitos da busca. Eles recebem uma
classificação de acordo com a proximidade do parâmetro passado para realização da pesquisa.
O primeiro elemento do conjunto se refere ao anúncio que mais se aproxima do parâmetro e o
último o mais distante.
5.3. Implementação do Cliente
O componente Cliente da arquitetura deve interagir com Registro para a busca de
serviços, e com o Provedor para a invocação dos serviços. Na busca, ele utiliza-se do
Matchmaker Client e na invocação do OWL-S Virtual Machine (OWL-S VM) [OWL-SVM,
2010].
O uso do Matcthmaker Client na busca já foi tratado na Seção 5.2. Com o objetivo
que para a aplicação seja fornecida uma API de mais alto nível, sem que haja o tratamento das
especificidades do objeto do Matchmaker Client (OWLSMatchmakerClient), uma nova classe
//Criação do objeto CapabilitySearch
CapabilitySearch capabilitySearch = new CapabilitySearch();
//Adição das ontologias que são usadas na pesquisa (Ex. as que definem as entradas e
//saídas)
capabilitySearch.addImportURL("http://www.daml.ri.cmu.edu/iswcdemo/navn/BravoAir
Profile.owl");
//Adição do conceito da ontologia que representa a entrada
capabilitySearch.addInput("http://www.daml.ri.cmu.edu/iswcdemo/navn/BravoAirConce
pt.owl#Airport");
//Adição do conceito da ontologia que representa a saída
capabilitySearch.addOutput("http://www.daml.ri.cmu.edu/iswcdemo/navn/BravoAirConc
ept.owl#ETicket");
//Criação do Matchmaker Client
OWLSMatchmakerClient mc = new OWLSMatchmakerClient();
//Uso do objeto de características para realizar a busca
MatchmakerResultList mrl = mc.query(capabilitySearch);
Figura 5.4. Exemplo do código de busca de serviços pela especificação de suas características.
72
foi definida para fornecer esta API, seu nome é SearchService e deve ser utilizada pelas
aplicações que desejam utilizar o SEMSUS.
A classe SearchService utiliza o Matchmaker Client para poder interagir com o
Matchmaker do servidor semântico. A API fornecida pode ser visualizada no Apêndice A.
Basicamente, ela fornece os métodos para definir as propriedades do sistema, como senha e
usuário, e para realizar as buscas.
Outra interação que o Cliente participa é a de invocação do serviço com o uso do
OWL-S VM, após ter encontrado o serviço que deseja. De forma semelhante ao Matchmaker
Client a aplicação não interage diretamente com a ferramenta, mas existe uma classe que
fornece uma API de mais alto nível para aplicação poder invocar os serviços. Tal classe
chama-se InvokeService. A API completa para invocar o Provedor encontra-se no Apêndice B.
A Figura 5.5 apresenta as classes que constituem o Cliente.
Figura 5.5. Estrutura interna do Cliente.
5.4. Implementação do Provedor
Para a implementação do Web Server, no Provedor, foi utilizado o Apache Axis no
Tomcat. O Axis é uma implementação do SOAP. Ele é amplamente usado para implementar
serviços Web na linguagem Java.
No servidor existe o componente de software Gateway. Resumidamente, ele é o
responsável por realizar a publicação do serviço, quando da interação do Provedor com o
Registro, e receber as requisições e retornar as saídas quando da invocação pelo Cliente. Para
implementação do Gateway existem dois principais grupos de classes, um responsável por
externalizar os serviços e receber as requisições, e outro para preparar as mensagens a serem
enviadas para a RSSF via o conector Adaptador.
73
O grupo de classes que externaliza está ligado ao tipo de serviço a ser fornecido pelo
Provedor, uma vez que cada serviço possui seus próprios métodos, saídas e entradas,
condições, etc. São estes arquivos que devem ser transformados em WSDL que especificam a
interface com os serviços.
A classe que prepara as mensagens tem a função de colocar os valores nos campos
das mensagens que irão ser propagadas na RSSF. As mensagens a serem tratadas são geradas
automaticamente pelo utilitário do TinyOS chamado de mig (Message Interface Generator).
O mig gera uma classe Java a partir da estrutura de dados referente a uma mensagem NesC.
Tal classe possui as propriedades referentes aos campos da mensagem NesC, além de
métodos para modificar e acessar as propriedades.
Além de preparar as mensagens é necessário enviá-las e recebê-las. Fisicamente, o
meio que permite a comunicação entre o Web Server e a RSSF é uma mídia que conecta uma
interface do sorvedouro com uma do servidor, as quais podem ser portas serial. Existe uma
abstração deste meio de comunicação chamada de packet source.
O packet source é quem exerce a função do conector Adaptador. Ele é uma
ferramenta disponibilizada pelo próprio sistema operacional TinyOS, não precisando ser
implementado. Especificamente na implementação do SEMSUS, o mesmo conecta o
ambiente da RSSF, que possui a linguagem NesC, com o do Web Server que tem programas
na linguagem Java. A interação é a troca de mensagens entre os dois ambientes, na qual as
mensagens Java são transformadas em mensagens NesC e vice-versa. A Figura 5.6 mostra a
relação entre o packet source e os demais componentes que fazem parte do componente
Gateway.
Figura 5.6. Estrutura interna do Gateway.
A Figura 5.6 mostra o serviço que é exposto. Ele é o primeiro do Gateway a receber
a requisição vinda do Cliente. Após receber a requisição, ele chama a classe responsável por
montar e enviar as mensagens para a RSSF. Na Figura 5.6 esta classe está representada como
Ligação. A Ligação utiliza a MoteIF para poder enviar e receber mensagens (MensagemJava)
pelo packet source. A MoteIF é uma classe disponibilizada pelo próprio TinyOS como uma
das ferramentas para a comunicação via packet source.
74
Na implementação do SEMSUS na RSSF foi utilizada a linguagem NesC. A Figura
5.7 apresenta os componentes internos da RSSF com os detalhes relativos à linguagem. A
arquitetura que ela apresenta foi automaticamente gerada a partir do código fonte, pela
ferramenta Yeti 2 [YETI, 2010].
Figura 5.7. Estrutura interna na RSSF em NesC.
A Figura 5.7 não apresenta a divisão física entre sorvedouro e Nós Sensores, mas já
foi mostrado que no sorvedouro estão o Gerenciador e o Dispatcher, e nos Nós as
implementações dos serviços. Como o sorvedouro interage com o Web Server, ele deve
possuir componentes capazes de tratar a comunicação via packet source. Tais componentes
são o SerialAMReceiverC, o SerialAMSenderC e o SerialActiveMessageC. O primeiro para
tratar as mensagens que chegam à rede, o segundo para enviar mensagens para o Web Server
e o terceiro para ter controle sobre o dispositivo de hardware responsável pela comunicação.
Eles estão conectados ao Gerenciador, o qual é o componente de software na RSSF que
recebe os dados externos a rede.
O Gerenciador envia para o Dispatcher a requisição chegada até ele com a
identificação do serviço. Com conhecimento deste identificador o Dispatcher realiza a seleção,
em tempo de execução, do código que implementa o serviço requisitado.
Para validar a implementação foram implementados dois serviços, apresentados na
Figura 5.7 como serviços de disseminação e de roteamento. Os serviços são analisados na
Seção 5.5 que trata de um estudo de caso do SEMSUS. Os arquivos em NesC da
implementação do SEMSUS na RSSF podem ser visualizados no Apêndice F.
75
5.5. Estudo de caso
O estudo de caso tem por principal objetivo mostrar a viabilidade do SEMSUS como
solução de middleware para RSSF. Para tanto, foram concebidos dois cenários de uso. O
primeiro tem como objetivo mostrar a utilização dos mecanismos de publicação, de busca e de
invocação dos serviços semânticos. Na invocação, é testado se o serviço que é invocado pela
aplicação é mapeado corretamente na implementação da funcionalidade nos nós sensores da
RSSF. Mais especificamente, dois serviços são implementados para serem registrados,
buscados e invocados por uma simples aplicação. Tais serviços possuem suas funcionalidades
implementadas na RSSF e são invocados separadamente para testar se o código
correspondente a cada um foi executado.
O segundo cenário visa explorar as vantagens do uso dos serviços semânticos quando
da busca por serviços. Os serviços são publicados e pesquisados, e usam uma ontologia para
definir as relações entre os tipos das entradas especificadas na descrição do serviço e dos tipos
das entradas definidas na requisição de busca.
5.5.1. Cenário de invocação de serviços distintos
Para validação das principais funcionalidades do SEMSUS foram implementados
duas funcionalidades. Elas são executadas no ambiente do sistema operacional TinyOS,
simulado pelo TOSSIM [TOSSIM, 2010]. O TOSSIM é um simulador para RSSF
amplamente utilizado e desenvolvido pela equipe de desenvolvimento do TinyOS, para
simulação de aplicações NesC na falta de plataformas de hardware dos nós.
Um dos serviços é o de disseminação que é baseado no protocolo de disseminação
[DISSEMINATION, 2010] para enviar dados para todos os nós componentes da rede. Ele
trabalha inundando a rede com dados. Sua importância ocorre quando da utilização de
serviços que necessitam que todos os nós sejam alcançados quando necessário como, por
exemplo, para reconfigurar a rede ou para realizar uma “query” sobre a mesma. Ele deve ser
usado com cuidado uma vez que não é desejável uma grande quantidade de comunicação
entre os nós, visto que demanda energia para enviar e receber dados. O código completo da
disseminação encontra-se nos Apêndices F.7 e F.8.
O outro serviço é o de roteamento que utiliza Tymo [TYMO, 2010] para realizar a
troca de mensagens na rede. Por ser um protocolo de roteamento baseado no Dymo (Dynamic
76
MANET On-demand) para TinyOs, o Tymo herda as principais características do Dymo,
como a comunicação ponto-a-ponto e encontra dinamicamente as rotas para hosts na rede.
Para tanto, mensagens para reconhecimento dos caminhos são disseminados na rede somente
quando um nodo necessita se comunicar com outro, assim o nodo não armazena grande
quantidade de informações das rotas, visto que o processo de encontrar uma rota desejada só
se realiza quando da necessidade de comunicação. Tais mecanismos economizam memória,
pela pequena quantidade de dados armazenados, e energia devido à comunicação “sob
demanda”. O código completo do Tymo encontra-se nos Apêndices F.9 e F.10.
O protocolo de roteamento possui a vantagem de economizar mais os recursos da
rede, quando comparado ao de disseminação, uma vez que diminui em média a quantidade de
mensagens que são trocadas, economizando banda das conexões e energia dos nós. Por outro
lado, a disseminação permite um menor tempo de resposta, visto que não é necessário trocar
mensagens para o conhecimento prévio da rota.
A execução destes serviços, a partir da perspectiva da aplicação, começa pela
utilização da API fornecida pelo SEMSUS. A Figura 5.8 apresenta o código de uma simples
aplicação de testes usando a abstração para busca e seleção do serviço de roteamento.
77
O código da Figura 5.8 está dividido em duas partes principais: a de busca e a de
invocação do serviço. Na busca é passado como parâmetro o local do profile da definição da
publicação do serviço, mas não é a única forma de encontrar o serviço. Podem-se passar
características do serviço, como os tipos semânticos que definem suas entradas e/ou saídas. O
Apêndice A apresenta a API para busca de serviços e o Apêndice C o profile utilizado para
publicar semanticamente o serviço de roteamento.
public class Client {
//definição do objeto para busca do serviço no Registro (Matchmaker)
private static SearchService search;
//definição do objeto para invocar o serviço
private static InvokeService invoke;
…
//BUSCA DO SERVIÇO
//Instanciação do objeto de busca com os dados sobre os locais de publicação,
//usuário e senha do registro
search = new
SearchService("http://localhost:8080/juddi/inquiry","http://localhost:8080/juddi/publis
h","juddi","password");
//Realização da pesquisa a partir da URL do profile do serviço. Como retorno a
//lista de serviços encontrados
MatchmakerResultList mrl =
search.query("http://localhost:8080/ontologias/RoutingProfile.owl");
// pega o serviço com melhor classificação entre os selecionados
MatchmakerResult result = mrl.get(0);
//pega a URL do profile do serviço
profileURL = result.getOwlsURL();
//INVOCAÇAO DO SERVIÇO ENCONTRADO ANTERIORMENTE
invoke = new InvokeService();
//Definição dos tipos semânticos das entradas do serviço
Vector <String> inputTypes = new Vector();
inputTypes.add("#RoutingService_Routing_value_IN");
inputTypes.add("#RoutingService_Routing_Destination_IN");
//Definição do valor da entrada do serviço
Vector <String> inputs = new Vector();
inputs.add("3");
inputs.add("5");
//execução do serviço a partir da definição dos tipos semânticos das entradas e
//dos valores destas entradas
invoke.executeService( inputTypes, inputs);
}
Figura 5.8. Exemplo de código de uma aplicação cliente
78
Como mostra a Figura 5.8, a invocação do serviço é feita pelo método executeService
do objeto InvokeService e é necessário passar a definição dos tipos das entradas e os valores
destas entradas, respectivamente.
O uso da API torna transparente a execução dos engenhos de mais baixo nível. Estes
engenhos se traduzem em interagir com os componentes do Registro e do Provedor. Como as
interações com registro são implementadas pelas ferramentas de terceiros, é dado foco na
interação com o Provedor, mais especialmente relativo à RSSF.
O primeiro componente do Provedor que recebe a requisição vinda da aplicação no
Cliente é o Gateway no Web Server. Uma das funções do Gateway é expor a interface do
serviço para ser invocado via Web. A Figura 5.9 apresenta parte do código referente à
exposição do serviço de roteamento na Web.
O código da Figura 5.9 mostra a interface definida para interação com o serviço de
roteamento, a qual especifica como entradas dois parâmetros inteiros, um para definir o nodo
destino do dado a ser enviado e outro o valor deste dado. Este código é usado pela ferramenta
Java2WSDL para gerar o WSDL do serviço. Ele chama o objeto Bind, o qual insere os
valores na mensagem a ser enviada para a RSSF, e a envia pelo objeto MoteIF. A interação
entre as classes no Gateway é semelhante quando do uso do serviço de disseminação. A
Figura 5.10 apresenta parte do código do Bind.
public class RoutingService {
public Bind ponte;
public RoutingService(){
ponte= new Bind();
}
public String Routing( int value, int Destination) {
ponte.prepararRotearPacote(Destination, value);
ponte.enviarPacoteRede();
return null;
}
}
Figura 5.9. Código do serviço de roteamento.
79
Quando a mensagem é enviada, ela chega a RSSF. Na rede, a maior configuração em
Nesc é chamada de MiddlewareC, a qual é constituída pelo Dispatcher, pelo Manager
(gerenciador), e os componentes que abstraem os elementos de hardware. A Figura 5.11
apresenta estes componentes e como ocorre a conexão entre eles no middleware.
Figura 5.11. Código do componente MiddlewareC.
configuration MiddlewareC {
}
implementation{
components DispatcherC , Manager;
components new SerialAMReceiverC(AM_BLINKTOSERIALMSG);
components new SerialAMSenderC(AM_BLINKTOSERIALMSG);
components SerialActiveMessageC;
//Para controle do Dispatcher
Manager.ControlDispatcher-> DispatcherC.ControlDispatcher;
//módulos de abstração de hardware (serial) para o Manager
Manager.SerialSend -> SerialAMSenderC;
Manager.SerialReceive -> SerialAMReceiverC;
Manager.SerialAMControl -> SerialActiveMessageC;
Manager.Packet -> SerialAMSenderC;
}
public class Bind {
...
// Método para preparar a mensagem a ser enviada para RSSF
public void prepararRotearPacote(int destino, int valor ){
mensagem.amTypeSet(6);
mensagem.set_destino(destino);
mensagem.set_counter(valor);
mensagem.set_origem(1);
}
// Método que envia a mensagem previamente preparada
public void enviarPacoteRede(){
sf = new MoteIF ( );
try {
sf.send(1,mensagem);
} catch (IOException ex) {
ex.printStackTrace();
}
}
}
Figura 5.10. Parte do código do objeto Bind.
80
Como Gerenciador apenas gerencia um valor associado a uma variável e a passa para
o Dispatcher selecionar a implementação do serviço segundo este valor, apenas é abordado o
código do Dispatcher que permite a funcionalidade de selecionar implementações distintas. A
Figura 5.12 apresenta parte do código do Dispatcher.
Como mostra a Figura 5.12, o código começa com o Dispatcher providenciando uma
interface chamada de ControlDispatcher. Esta interface é a utilizada pela configuração
MiddlewareC para conectar o Gerenciador ao Dispatcher. É importante observar que a
interface parametrizada cria uma instância para cada valor diferente do parâmetro, no caso o
id. Esta é a forma que o Dispatcher recebe o valor do serviço passado pelo Gerenciador.
Outro componente foi necessário para abstrair os distintos serviços em um única
forma para acessá-los, seu nome é ServicosM. Mais especificamente, a interface
ControlDispatcher providenciada pelo Dispatcher é uma externalização ao MiddlewareC da
interface do ServicosM, ou seja, do meio para acessar os serviços.
Cada serviço está associado a uma instância da interface parametrizada do ServicosM.
O serviço de roteamento, por exemplo, está ligado a instância da interface que possui o id
com valor de 1, enquanto que o de disseminação com a que possui o valor de 2. Então, se
existir a necessidade de adicionar um novo serviço ao sistema, o mesmo deve providenciar
uma interface do mesmo tipo da ControlService, ou seja do tipo SplitFase, e ter um id
Figura 5.12. Parte do código do Dispatcher.
configuration DispatcherC {
provides interface SplitFase as ControlDispatcher [uint16_t id];
}
implementation {
components ServicosM as ServicesM, RoutingM, DisseminationM;
components DisseminationC;
components new DisseminatorC (uint32_t, 0x1234) as Diss16C;
...
//externaliza "ControlServices" para os usuários
ControlDispatcher = ServicesM.ControlServices;
...
//liga ao servico de roteamento
ServicesM.ControlService[AKYILDIZ et al, 2002]-> RoutingM.ControlRouting;
//liga ao servico de disseminacao
ServicesM.ControlService[2]-> DisseminationM.ControlDissimination;
...
}
81
associado a uma instância da interface. A Figura 5.13 apresenta o código da interface
SplitFase.
A interface SplitFase obedece o princípio split-fase. Pois um componente que usa a
interface e chama o comando (command) init, não precisa ficar esperando pelo retorno da
chamada, mas o evento finish é lançado informando-o de que o processamento terminou.
Os serviços que são adicionados ao SEMSUS devem implementar os códigos
referentes aos comandos, enquanto que o componente SevicosM deve implementar o evento
da interface. A semântica de interação é sempre a mesma: o ServicosM chama o comando
boot para que o serviço inicialize o que é necessário para sua execução; em seguida é
chamado o evento init, passando os dados por meio de estruturas de dados representadas
como mensagens; quando a execução do serviço é terminada, ele lança o evento finish para
ser tratado pelo ServicosM. No evento estão os resultados da execução do serviço como
parâmetros estruturados em mensagens.
5.5.2. Resultados da invocação dos serviços distintos
O cenário de invocação dos dois serviços obteve resultado satisfatório, quando a
partir de uma simples aplicação de teste, os dois serviços foram invocados e utilizados. Assim,
todo o processo de publicação, busca e invocação semântica dos serviços obteve sucesso, bem
como os engenhos que fazem parte destas interações.
A utilização das ferramentas que fazem parte do Registro, a publicação semântica
das descrições e a escolha das implementações das funcionalidades na RSSF por parte dos
componentes Gerenciador e Dispatcher foram realizadas de forma a não comprometer a
funcionalidade do sistema. Assim, ficou comprovada a eficácia do conjunto de ferramentas
usadas na publicação, pesquisa e invocação dos serviços semânticos.
Como a pesquisa e invocação dos serviços se deram a partir da API, ela se mostrou
satisfatória em esconder as particularidades da implementação dos engenhos do sistema para
Figura 5.13. Código da interface SplitFase.
interface SplitFase {
command error_t boot ();
command void init (message_t * msg, void * payload);
event void finish (message_t * msg, MiddlewareMsg * payload);
}
82
o desenvolvedor. Especificamente na invocação, o caminho que a requisição percorre no
provedor foi validado, uma vez que o serviço escolhido pela aplicação foi realmente o
executado no ambiente de simulação da RSSF, além de permitir a permuta entre os dois
serviços sem grandes problemas para o funcionamento do middleware, mostrando que os
serviços são componentes com interfaces bem definidas.
Primeiramente, a aplicação pesquisou e invocou a serviço de roteamento. Na
pesquisa foi passado como parâmetro para o SEMSUS a URL do profile do serviço, e na
invocação foram definidas os tipos de entradas e seus valores, conforme o código da Figura
5.8. Com a invocação, comprovou-se que o a funcionalidade correspondente ao serviço de
roteamento foi chamada, uma vez que as mensagens de debug, impressas em um arquivo,
foram as da sua execução. Fato semelhante ocorre quando da invocação do serviço de
disseminação, comprovando que as requisições que chegam ao Gateway são mapeadas
corretamente nas funcionalidades que estão nos nós da RSSF. A Figura 5.14 apresenta o
arquivo que recebe as mensagens provenientes da execução do serviço de roteamento, e a
Figura 5.15 as mensagens da execução do serviço de disseminação.
Figura 5.14. Arquivo de mensagens da execução do serviço de roteamento.
Figura 5.15. Arquivo de mensagens da execução do serviço de disseminação.
5.5.3. Cenário de utilização da semântica na pesquisa de serviços
Para explorar as vantagens do uso da semântica na descrição dos serviços, foi
realizada a pesquisa do serviço de roteamento usando uma ontologia. Esta ontologia define as
83
relações entre os tipos de entradas, especificadas na descrição semântica do serviço, e os tipos
de entradas na requisição de busca pelo serviço. Assim, primeiramente foi definida uma
ontologia para especificar as relações semânticas entre estes tipos. A Figura 5.16 apresenta as
relações semânticas usadas e o Apêndice G apresenta o código completo da ontologia.
Figura 5.16. Ontologia que expressa às relações entre tipos.
Como mostra a Figura 5.16, são definidas na ontologia as relações entre as classes
“Address” e “Destination”. A primeira é superclasse da segunda. Da mesma forma, é
especificada a relação entre “Value” e “Information”. Assim, para validação das vantagens do
uso da semântica, é publicada a descrição do serviço de roteamento segundo seu profile. Parte
deste profile que define as entradas e saída está representado na Figura 5.17.
84
Como mostra a Figura 5.17, existem duas entradas para o serviço: uma do tipo
Destination (http://localhost:8080/ontologias/rdfxml.owl#Destination) e outra do tipo
Information (http://localhost:8080/ontologias/rdfxml.owl#Information), e uma saída do tipo
string (http://www.w3.org/2001/XMLSchema#string). Esta descrição é registrada no
Matchmaker para ser considera pela comparação semântica em pesquisas posteriores.
Para realizar a busca que considere a relação ontológica, é definida uma busca cujos
parâmetros são de tipos das superclasses dos tipos usados no profile do serviço de roteamento.
A Figura 5.18 apresenta o código que definem estes parâmetros a partir da API fornecida pelo
SEMSUS.
<profile:hasInput>
<process:Input
rdf:about="http://localhost:8080/ontologias/RoutingProfile.owl#RoutingService_Routing
_value_IN">
<process:parameterType rdf:datatype="http://www.w3.org/2001/XMLSchema#anyURI">
http://localhost:8080/ontologias/rdfxml.owl#Destination
</process:parameterType>
</process:Input>
</profile:hasInput>
<profile:hasOutput>
<process:Output
rdf:about="http://localhost:8080/ontologias/RoutingProfile.owl#RoutingService_Routing
_RoutingReturn_OUT">
<process:parameterType rdf:datatype="http://www.w3.org/2001/XMLSchema#anyURI">
http://www.w3.org/2001/XMLSchema#string
</process:parameterType>
</process:Output>
</profile:hasOutput>
<profile:hasInput>
<process:Input
rdf:about="http://localhost:8080/ontologias/RoutingProfile.owl#RoutingService_Routing
_Destination_IN">
<process:parameterType rdf:datatype="http://www.w3.org/2001/XMLSchema#anyURI">
http://localhost:8080/ontologias/rdfxml.owl#Information
</process:parameterType>
</process:Input>
</profile:hasInput>
Figura 5.17. Parte do profile do serviço de roteamento considerando a ontologia.
85
Com a realização da busca conforme mostra o código da Figura 5.18, o Servidor
Semântico, implementado pelo Matchmaker, retorna uma pontuação para pesquisa com o
valor de sete pontos para a descrição do serviço de roteamento. Considerando que existem três
parâmetros definidos e a pontuação máxima que pode ser alcançada por esta pesquisa é de
nove, três para cada parâmetro, o Matchmaker considera a pontuação de três para o parâmetro
de saída, uma vez que são do mesmo tipo tanto na descrição do serviço quanto no parâmetro
de busca, e de dois para cada parâmetro de entrada, visto que eles não são iguais, mas
possuem um relacionamento de superclasse entre si. A Figura 5.19 apresenta o resultado
fornecido pelo Matchmaker ao executar esta busca.
Figura 5.19. Resultado da busca semântica.
search = new
SearchService("http://localhost:8080/juddi/inquiry","http://localhost:8080/juddi/publish
","juddi","password");
//Especificação da URL da ontologia que define os relacionamentos semânticos
Collection <String> urlOntology = new ArrayList <String>();
urlOntology.add("http://localhost:8080/ontologias/rdfxml.owl");
//Especificação dos tipos de entradas a serem consideradas segundo a ontologia
Collection <String> conceptInput = new ArrayList <String>();
conceptInput.add("http://localhost:8080/ontologias/rdfxml.owl#Address");
conceptInput.add("http://localhost:8080/ontologias/rdfxml.owl#Value");
//Especificação do tipo de saída do serviço
Collection <String> conceptOutput = new ArrayList <String>();
conceptOutput.add("http://www.w3.org/2001/XMLSchema#string");
//Realização da busca segundo os parâmetros previamente definidos
MatchmakerResultList mrl =
search.queryCapability(urlOntology,conceptInput,conceptOutput);
Figura 5.18. Exemplo de código da busca considerando uma ontologia.
86
Como mostra a Figura 5.19, as relações semânticas foram consideradas quando o
conceito Address (http://localhost:8080/ontologias/rdfxml.owl#Address) usado na busca, foi
mapeado para Destination (http://localhost:8080/ontologias/rdfxml.owl#Destination) utilizado
na publicação do serviço de roteamento. O mesmo aconteceu com a entrada Value mapeada
para Information. Assim ficou comprovada que a ontologia influenciou no resultado da busca
quando os parâmetros são sintaticamente diferentes, mas possuem relações semânticas.
O cenário apenas demonstrou o uso da ontologia na busca de um serviço pelo
mapeamento de quatro tipos de entradas e saídas, mas outros cenários de maior complexidade
podem ser vislumbrados a partir deste apresentado. Por exemplo, o caso em que existe um
serviço de monitoramento da temperatura que abrange diversas regiões, e que recebe como
entrada um parâmetro das coordenadas geográficas formadas pela longitude e latitude da
região a ser observada. Entretanto, existe um cliente que necessita deste serviço e em sua
pesquisa fornece como parâmetro as coordenadas UTM (Universal Transverso de Mercator).
Então, caso seja definido em uma ontologia que tanto as coordenadas geográficas como as
UTM são coordenadas de posicionamento global, o serviço pode ser retornado como resultado
da pesquisa.
Além do resultado positivo da pesquisa semântica, existe também a possibilidade de
compor automaticamente os serviços de acordo com as descrições semânticas dos requisitos e
das capacidades dos serviços disponíveis [CARY et al, 2007]. Assim, um serviço de
transformação de coordenadas geográficas, por exemplo, pode ser usado para transformar as
coordenadas, de forma que o cliente as forneça em UTM e o serviço as receba expressas em
latitude e longitude.
87
Capítulo 6. Considerações Finais e Trabalhos Futuros
Este capítulo aborda um resumo das principais contribuições deste trabalho, além das
limitações e os trabalhos futuros que podem ser realizados para evolução da solução.
6.1. Conclusão
Esta dissertação abordou primeiramente que as RSSF estão progressivamente
ganhando importância e atenção da academia e do mercado, pela sua ampla variedade de
aplicações. Tais redes possuem seus desafios particulares inerentes à sua natureza e de seus
nós componentes, como a escassez de recursos de hardware e de energia. Por se tratar de um
sistema distribuído, a solução de middleware pode ser aplicada com o objetivo de esconder a
distribuição neste ambiente. Assim, existe um conjunto de problemas que o middleware visa
solucionar e outro conjunto de desafios referente ao desenvolvimento de aplicações para
RSSF.
O desenvolvimento de um middleware para RSSF deve cumprir seu objetivo,
considerando em implantar mecanismos que atendam os requisitos das aplicações associados
às características da rede. Quando analisada a arquitetura e a implementação do SEMSUS,
fica claro que esta foi uma constante preocupação durante todo processo de desenvolvimento.
Na arquitetura apresentada, houve a preocupação em deixar para os nós a menor carga
computacional do sistema, fazendo que eles executassem apenas os códigos referentes aos
serviços. A utilização de um conjunto heterogêneo de componentes de hardware, desde
servidores Web a nós sensores, mostra que processamentos que demandam capacidade
computacional superior a que uma RSSF pode oferecer são implementados fora desta rede,
como por exemplo, o tratamento de requisições de diversos clientes e o processamento do
conjunto de padrões e linguagens dos serviços semânticos realizados no servidor e no registro.
Tanto a arquitetura apresentada como a implementação decorrente dela mostrou que
o SEMSUS conseguiu transparência para aplicação. A transparência ocorreu, sobretudo pelo
uso dos padrões dos serviços semânticos permitindo que os clientes acessem os recursos
como serviços. Isto também permitiu a interoperabilidade de plataforma de forma que APIs
para diferentes linguagens possam ser disponibilizadas, desde que implementem as
ferramentas para interagirem com os padrões dos serviços semânticos.
88
O SEMSUS oferece uma API simples que permite a interação das aplicações com a
RSSF por meio de um conjunto operações definidas basicamente por SOA. Assim para
aplicação todo o processo se passa como busca de serviço seguida da invocação do serviço
escolhido.
Outra vantagem do uso de serviços é, em última análise, a exposição da RSSF na
Web. Trabalhos neste sentido já têm sido desenvolvidos. A tentativa é de realizar os
chamados “sensor Web” que permitem o acesso a RSSF a partir da Internet.
Uma melhora nos mecanismos relacionados aos serviços também foi almejada com a
adição de tecnologias da Web semântica aos padrões dos serviços Web, formando os serviços
semânticos. Isto possibilitou a comunicação entre a aplicação cliente e rede provedora, a partir
da troca de informações que tinham seus significados compreendidos por ambas, e não
considerando apenas a sintaxe. Assim, foi possível realizar uma busca semântica aos serviços
que preenchessem os requisitos da aplicação.
Não somente definições de interfaces de alto nível foram realizadas, as que são
expostas a aplicação, mas também houve a definição de interfaces com partes internas do
sistema, que proporcionaram a organização do SEMSUS como um conjunto de componentes
que permitem a fácil substituição, adaptação e adição das implementações dos serviços nas
RSSF. Esta facilidade também se deve a uso de padrões de projeto, como o Dispatcher, e da
natureza modular do sistema operacional orientado a componentes, como o TinyOS.
O SEMSUS também contribui pela exploração, utilização e validação de um
conjunto de ferramentas que permitem a realização dos serviços semânticos. Uma vez que tais
ferramentas foram utilizadas com sucesso na publicação, busca e invocação de serviços e que
frameworks para tanto ainda estão em processo de desenvolvimento e são objetos de pesquisa
de vários trabalhos. Ou seja, ainda está em fase de consolidação.
Assim, o SEMSUS é a realização da união de um conjunto de tecnologias, ambientes
computacionais distintos, padrões, ferramentas, linguagens, etc. Na mesma solução podem-se
tratar temas como SOA, serviços Web, serviços semânticos, middleware, middleware
reflexivos, RSSF, arquitetura de software, padrões de projeto, adaptação à execução, dentre
outros. Trata-se, portanto, de uma solução complexa que teve, antes de ser implementada,
analisada cuidadosamente por meio de sua arquitetura, e por último que obteve êxito na sua
execução.
89
6.2. Limitações e trabalhos futuros
O trabalho aborda um middleware para RSSF baseado em serviços semânticos.
Apesar do fato de englobar um conjunto de diferentes tecnologias, e de algumas delas ainda
estarem em desenvolvimento, foi almejado o alcance de uma solução de middleware que
permita o acesso a RSSF por meio de serviços semânticos. Disto resultou uma complexidade
e, consequentemente, oportunidades que não foram esgotadas neste trabalho, permitindo
extensões em vários aspectos teóricos e práticos.
Uma possibilidade de extensão é fornecer APIS para diferentes linguagens, desde
que sejam implementados os componentes do componente Cliente, de modo a interagir com o
Registro e com o Provedor e fornecer a API para a linguagem específica. Esta possibilidade é
devida a interoperabilidade da interação entre os componentes de SOA.
Outro ponto que pode ser melhorado está no uso dos serviços semânticos. Devido ser
uma área que está em desenvolvimento, a implementação da composição de serviços
semânticos e do monitoramento da sua execução, não foram implementados, o que pode ser
realizado com a evolução de ferramentas e padrões para os serviços semânticos.
A seleção da implementação dos serviços realizada na RSSF pelo Dispatcher, pode
ser realizada de forma mais elaborada. Como a que permite a adaptação do middleware a
partir de mecanismos reflexivos, de modo que implementações distintas de um mesmo
serviço possam ser selecionadas de acordo com as capacidades atuais da rede.
Mais limitações decorreram do não uso de plataformas de hardware de nós sensores.
A utilização do TOSSIM com o TinyOS 2.1 limitou a execução de testes, como os que
monitoram e indicam o dispêndio de energia durante o processamento de um serviço. Assim é
necessário que a execução do SEMSUS se realize em plataformas de hardware de nós
sensores.
Finalmente, deve-se realizar a execução de outros testes que venham validar e
consolidar ainda mais a implementação, de forma avaliar questões que não foram possíveis
em uma implementação para validação de uma situação específica de pequena quantidade de
serviços e de poucos acessos ao provedor (como os testes para checagem de desempenho).
Outros cenários além deste podem ser utilizados para posterior evolução do SEMSUS como,
por exemplo, os que incluem de várias redes distintas oferecendo serviços semelhantes.
90
REFERÊNCIAS BIBLIOGRÁFICAS
[AKYILDIZ et al, 2002] AKYILDIZ, I.F. et al. A Survey on Sensor Networks. IEEE
Communications Magazine, 2002, 40(8). p 102–114.
[ALMEIDA; BAX, 2003] ALMEIDA, M.B. ; BAX, M.P. Uma visão geral sobre
ontologias: pesquisa sobre definições, tipos, aplicações, métodos de avaliação e de
construção. Ciência da Informação, Brasília, v.32, n.3, p.7-20, set./dez. 2003.
[ARCHSTUDIO, 2010] ArchStudio 4 - Software and Systems Architecture Development
Environment. Disponível em: <http://www.isr.uci.edu/projects/archstudio/>. Acesso em: 10
Jan. 2010.
[AXIS, 2010] Apache Axis. Disponível em: <http://ws.apache.org/axis/>. Acesso em: 10 Jan.
2010.
[BORST, 2006] BORST, W. N. Construction of engineering ontologies. 1997. 243 f. Tese
(Doutorado). – University of Twente, Enschede, 1997. Disponível em:
<http://doc.utwente.nl/fid/1392>. Acesso em: abril 2006.
[BOTTS et al, 2006] BOTTS, M. et al. OGC Sensor Web Enablement: Overview and High
Level Architecture. Open Geospatial Consortium. OGC White Paper. v.2. 19 Jun. 2006.
[CARY et al, 2007] CARY, P. et al. Semantic Web Services: Theory, Tools and
Applications. J. Cardoso, Editor, Hershey, Pennsylvania: IGI Global, Mar. 2007.
[CHU; BUYYA, 2007] CHU, X., BUYYA, R. Service Oriented Sensor Web. In: N. P.
Mahalik. Sensor Networks and Configuration: Fundamentals, Standards, Platforms and
Applications. Springer-Verlag, 2007, pp. 51-74.
[DAML, 2010] The DARPA Agent Markup Language Homepage. Disponível em:
<http://www.daml.org/> Acesso em: 10 Jan. 2010.
[DELICATO, 2005] DELICATO, F. Middleware Baseado em Serviços Para Redes de
Sensores Sem Fio. (Tese de Doutorado em Ciências em Engenharia Elétrica) - Universidade
Federal do Rio de Janeiro, Jun. 2005.
[DISSEMINATION, 2010] Dissemination - TinyOS Documentation Wiki. Disponível em:
<http://docs.tinyos.net/index.php/Dissemination>. Acesso em: 10 Jan 2010.
[FIELDING, 2000] FIELDING, R. T. Architectural Styles and the Design of Network-
Based Software Architectures. (Tese de doutorado) - University of California, Irvine. 2000.
[GAY et al, 2007] GAY, D. et al. Software design patterns for TinyOS. In: ACM
Transactions on Embedded Computing Systems (TECS), v.6 n.4, p.22-es, Set. 2007,
doi:10.1145/1274858.1274860.
[GRUBER, 2005] GRUBER, T. What is an ontology?.1996. Disponível em:
<http://ksl.stanford.edu/kst/what-is-an-ontology.html>. Acesso em: abril 2005.
91
[HADIM; MOHAMED, 2006] HADIM, S.; MOHAMED, N. Middleware: middleware
challenges and approaches for wireless sensor networks. Distributed Systems Online, IEEE
In Distributed Systems Online, IEEE, Vol. 7, No. 3. 2006.
[HOLGER; WILLIG, 2005] HOLGER, K.; WILLIG, A. Protocols and Architectures for
Wireless Sensor Networks. John Wiley and Sons. Jun. 2005.
[IQBAL et al, 2009] IQBAL, M. et al. A service-oriented model for semantics-based data
management in wireless sensor networks. In: 5th IEEE International Workshop on
Heterogeneous Wireless Networks (HWISE 2009). Maio 2009.
[JAVAME, 2010] Java ME: the Most Ubiquitous Application Platform for Mobile
Devices. Disponível em: < http://java.sun.com/javame/index.jsp>. Acesso em: 10 Jan. 2010.
[JUDDI, 2010] Apache jUDDI - Welcome to jUDDI. Disponível em:
<http://ws.apache.org/juddi/>. Acesso em: 10 Jan. 2010.
[KHAN et al, 2006] KHAN, M.T. et al. Integrating Context-aware Pervasive Environments.
In: International Conference on Emerging Technologies, 2006 (ICET 2006). 13-14 Nov.
2006. p 683 – 688.
[LEGUAY et al, 2008] LEGUAY, J. et al. An efficient service oriented architecture for
heterogeneous and dynamic wireless sensor networks. 2008. p. 740-747.
[LEVIS et al, 2003] LEVIS, P. et al. “The nesC Language: A Holistic Approach to
Networked Embedded Systems”. In: Programming Language Design and Implementation
(PLDI), Jun. 2003.
[LEVIS et al, 2004] LEVIS, P. et al. TinyOS: An operating system for wireless sensor
networks. In Ambient Intelligence. Springer-Verlag, 2004.
[LEVIS; CULLER, 2009] LEVIS, P.; CULLER, D. E. Maté: a Tiny Virtual Machine For
Sensor Networks. Architectural Support for Programming Languages and Operating Systems.
2002. Disponível em: < http://www.cs.berkeley.edu/~pal/pubs/mate.pdf > Acesso em: 29 out.
2009.
[LIMA, 2008] LIMA, R. C. A. Middeware para Rede de Sensores Sem Fio Baseado em
Espaço de Tuplas. Dissertação (Mestrado em Ciências da Computação) - Universidade
Federal de Pernambuco. 2008.
[LIU; ZHAO, 2005] LIU, J.; ZHAO, F. Towards Semantic Services for Sensor-Rich
Information Systems. In: 2nd IEEE/CreateNet International Workshop on Broadband
Advanced Sensor Networks (Basenets 2005), Boston, MA, Out. 2005.
[LUCKENBACH et al, 2005] LUCKENBACH, T. et al. TinyREST: A Protocol for
Integrating Sensor Networks into the Internet. In: REALWSN, 2005.
[MALATRAS et al, 2008] MALATRAS, A. et al. Web Enabled Wireless Sensor Networks
for Facilities Management. IEEE Systems Journal, vol. 2, no. 4 Dez. 2008.
92
[MATCHMAKER, 2010] OWL-S / UDDI Matchmaker. Disponível em:
<http://www.daml.ri.cmu.edu/matchmaker>. Acesso em: 10 Jan. 2010.
[MICA, 2010] Low-power Wireless Mote Solutions Overview - Crossbow Technology.
Disponível em: < http://www.xbow.com/Products/wproductsoverview.aspx >. Acesso em: 10
Jan. 2010.
[MOLLA; AHAMED, 2006] MOLLA, M. M.; AHAMED, S. I. A survey of middleware for
sensor network and challenges. Parallel Processing Workshops, 2006 (ICPP 2006
Workshops). 11 ago. 2006.
[OWL, 2009] OWL Web Ontology Language. Disponível em: <http://www.w3.org/TR/owl-
features/>. Acesso em: 29 out. 2009.
[OWL-S, 2009] OWL-S: Semantic Markup for Web Services. Disponível em:
<http://www.w3.org/Submission/OWL-S/>. Acesso em: 29 out. 2009.
[OWL-SIDE, 2010] SemWebCentral: OWL-S IDE: Project Info. Disponível em:
<http://projects.semwebcentral.org/projects/owl-s-ide/>. Acesso em: 10 Jan. 2010.
[OWL-SVM, 2010] SemWebCentral: OWL-S VM: Project Info. Disponível em:
<http://projects.semwebcentral.org/projects/owl-s-vm/>. Acesso em: 10 Jan 2010.
[PAOLUCCI et al, 2002] PAOLUCCI, M. et al. Semantic Matching of Web Services
Capabilities. In: First International Semantic Web Conference (ISWC 2002). p. 333-347.
2002.
[SOUTO et al, 2006] SOUTO, E. et al. Mires: a publish/subscribe middleware for sensor
networks. Personal and Ubiquitous Computing. Springer Verlag, v. 10, n. 1, p. 37-44, 2006.
[SYCARA et al, 2002] SYCARA, K. et al. LARKS: Dynamic Matchmaking Among
Heterogeneous Software Agents in Cyberspace. In: Autonomous Agents and Multi-Agent
Systems. v.5. p.173-203, 2002.
[TANENBAUM; STEEN, 2007] TANENBAUM, A. S.; STEEN M. van. Distributed
systems: principles and paradigms, ed. 2, Brazil, São Paulo: Pearson Prentice Hall, 2007, p.
3.
[TAYLOR et al, 2009] TAYLOR, R. N. et al. Software Architecture: Foundations, Theory,
and Practice. John Wiley & Sons, Jan. 2009, pp. 170-171.
[TINYDB, 2009] TinyDB: A Declarative Database for Sensor Network. Disponível em:
<http://telegraph.cs.berkeley.edu/tinydb> Acesso em: 29 out. 2009.
[TOMCAT, 2010] Apache Tomcat - Welcome!. Disponível em: < http://tomcat.apache.org/>.
Acesso em: 10 Jan. 2010.
[TOSSIM, 2010] TOSSIM - TinyOS Documentation Wiki. Disponível em:
<http://docs.tinyos.net/index.php/TOSSIM >. Acesso em: 10 Jan 2010.
93
[TYMO, 2010] Tymo - TinyOS Documentation Wiki. Disponível em:
<http://docs.tinyos.net/index.php/Tymo>. Acesso em: 10 Jan 2010.
[WANG et al, 2008] WANG, M. et al. Middleware for Wireless Sensor Networks: A
Survey. J. Comput. Sci. Technol. 2008, pp. 305-326.
[WSDL2OWL-S, 2010] WSDL2OWL-S. Disponível em:
<http://www.daml.ri.cmu.edu/wsdl2owls/>. Acesso em: 10 Jan. 2010.
[WSDL-S, 2010] Web Service Semantics - WSDL-S. Disponível em:
<http://www.w3.org/Submission/WSDL-S/>. Acesso em: 10 Jan. 2010.
[WSMO, 2010] Web Service Modeling Ontology. Disponível em: <http://www.wsmo.org/>.
Acesso em: 10 Jan. 2010.
[WU et al, 2008] WU, X. et al. Avoiding Energy Holes in Wireless Sensor Networks with
Nonuniform Node Distribution. IEEE Transactions on Parallel and Distributed Systems,
vol. 19, no. 5, pp. 710-720, Maio 2008, doi:10.1109/TPDS.2007.70770.
[WYCKOFF et al, 1998] WYCKOFF, P. et al. T Spaces. IBM Systems Journal. 1998. pp.
454–474.
[XADL, 2010] xADL 2.0 - A Highly Extensible Architecture Description Language for
Software and Systems. Disponível em: <http://www.isr.uci.edu/projects/xarchuci/>. Acesso
em: 10 Jan. 2010.
[YETI, 2010] Yeti 2 - TinyOS 2 Plugin for Eclipse. Disponível em: <http://tos-
ide.ethz.ch/wiki/index.php>. Acesso em: 10 Jan 2010.
94
APÊNDICE A – API de pesquisa de serviços semânticos
95
96
APÊNDICE B – API de invocação de serviços semânticos
97
APÊNDICE C – Profile do serviço de roteamento
<rdf:RDF xml:base="">
<owl:Ontology rdf:about="http://localhost:8080/ontologias/RoutingProfile.owl">
<owl:imports rdf:resource="http://www.daml.org/services/owl-s/1.1/ActorDefault.owl"/>
<owl:imports rdf:resource="http://www.daml.org/services/owl-s/1.1/Profile.owl"/>
<owl:imports rdf:resource="http://www.daml.org/services/owl-s/1.1/Service.owl"/>
<owl:versionInfo>
$Id: OWLSServiceProfileEmitter.java,v 1.1 naveen
</owl:versionInfo>
<owl:imports rdf:resource="http://www.daml.org/services/owl-s/1.1/Process.owl"/>
<owl:imports rdf:resource="http://localhost:8080/ontologias/RoutingService.owl"/>
<rdfs:comment>
Add Comment
</rdfs:comment>
</owl:Ontology>
<profile:Actor
rdf:about="http://localhost:8080/ontologias/RoutingProfile.owl#AddActorName">
<actor:phone>888888</actor:phone>
<actor:title>Mr.</actor:title>
<actor:fax>888888</actor:fax>
<actor:email>[email protected]</actor:email>
<actor:name>Francisco Cassimiro Neto</actor:name>
<actor:physicalAddress>rua pirapo</actor:physicalAddress>
</profile:Actor>
<profile:Profile
rdf:about="http://localhost:8080/ontologias/RoutingProfile.owl#AddServiceName">
<service:presentedBy
rdf:resource="http://localhost:8080/ontologias/RoutingService.owl#Routing"/>
<profile:hasInput>
<process:Input
rdf:about="http://localhost:8080/ontologias/RoutingProfile.owl#RoutingService_Routing_val
ue_IN">
<process:parameterType rdf:datatype="http://www.w3.org/2001/XMLSchema#anyURI">
http://www.w3.org/2001/XMLSchema#int
</process:parameterType>
</process:Input>
</profile:hasInput>
<profile:textDescription>
Add text Description
</profile:textDescription>
<profile:hasOutput>
<process:Output
rdf:about="http://localhost:8080/ontologias/RoutingProfile.owl#RoutingService_Routing_Ro
utingReturn_OUT">
<process:parameterType rdf:datatype="http://www.w3.org/2001/XMLSchema#anyURI">
http://www.w3.org/2001/XMLSchema#string
98
</process:parameterType>
</process:Output>
</profile:hasOutput>
<profile:serviceName>
Add Service Name
</profile:serviceName>
<profile:contactInformation
rdf:resource="http://localhost:8080/ontologias/RoutingProfile.owl#AddActorName"/>
<profile:hasInput>
<process:Input
rdf:about="http://localhost:8080/ontologias/RoutingProfile.owl#RoutingService_Routing_De
stination_IN">
<process:parameterType rdf:datatype="http://www.w3.org/2001/XMLSchema#anyURI">
http://www.w3.org/2001/XMLSchema#int
</process:parameterType>
</process:Input>
</profile:hasInput>
</profile:Profile>
</rdf:RDF>
99
APÊNDICE D – Process do serviço de roteamento
<rdf:RDF xml:base="http://localhost:8080/ontologias/RoutingProcess.owl">
<owl:Ontology about="">
<owl:versionInfo>
$Id: OWLSProcessModelEmitter.java,v 1.1 naveen
</owl:versionInfo>
<rdfs:comment>
Add Comment
</rdfs:comment>
<owl:imports rdf:resource="http://www.daml.org/services/owl-s/1.1/Service.owl"/>
<owl:imports rdf:resource="http://www.daml.org/services/owl-s/1.1/Process.owl"/>
<owl:imports rdf:resource="http://www.daml.org/services/owl-s/1.1/Profile.owl"/>
<!-- WSDL2OWL-S :: Add More Imports If needed -->
</owl:Ontology>
<!-- WSDL2DAML-S_was_here -->
<!-- WSDL2OWL-S :: Add composite processes if needed-->
<!--WSDL 2 OWL-S Generated code-->
<!--**List of Atomic Processes**-->
<!--ProcessName :RoutingService_Routing-->
Definitions for Atomic Process : RoutingService_Routing
-->
<!--Inputs-->
<process:Input rdf:ID="RoutingService_Routing_value_IN">
<process:parameterType rdf:datatype="http://www.w3.org/2001/XMLSchema#anyURI">
http://www.w3.org/2001/XMLSchema#int
</process:parameterType>
</process:Input>
<process:Input rdf:ID="RoutingService_Routing_Destination_IN">
<process:parameterType rdf:datatype="http://www.w3.org/2001/XMLSchema#anyURI">
http://www.w3.org/2001/XMLSchema#int
</process:parameterType>
</process:Input>
<!--Outputs-->
<process:Output rdf:ID="RoutingService_Routing_RoutingReturn_OUT">
<process:parameterType rdf:datatype="http://www.w3.org/2001/XMLSchema#anyURI">
http://www.w3.org/2001/XMLSchema#string
</process:parameterType>
</process:Output>
<!--Process-->
<process:AtomicProcess rdf:ID="RoutingService_Routing">
<process:hasInput rdf:resource="#RoutingService_Routing_value_IN"/>
<process:hasInput rdf:resource="#RoutingService_Routing_Destination_IN"/>
<process:hasOutput rdf:resource="#RoutingService_Routing_RoutingReturn_OUT"/>
</process:AtomicProcess>
</rdf:RDF>
100
APÊNDICE E – WSDL do serviço de roteamento
wsdl:definitions targetNamespace="http://localhost:8080/axis/RoutingService.jws">
<!--
WSDL created by Apache Axis version: 1.4
Built on Apr 22, 2006 (06:55:48 PDT)
-->
<wsdl:message name="RoutingRequest">
<wsdl:part name="value" type="xsd:int"/>
<wsdl:part name="Destination" type="xsd:int"/>
</wsdl:message>
<wsdl:message name="RoutingResponse">
<wsdl:part name="RoutingReturn" type="xsd:string"/>
</wsdl:message>
<wsdl:portType name="RoutingService">
<wsdl:operation name="Routing" parameterOrder="value Destination">
<wsdl:input message="impl:RoutingRequest" name="RoutingRequest"/>
<wsdl:output message="impl:RoutingResponse" name="RoutingResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="RoutingServiceSoapBinding" type="impl:RoutingService">
<wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="Routing">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="RoutingRequest">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://DefaultNamespace" use="encoded"/>
</wsdl:input>
<wsdl:output name="RoutingResponse">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://localhost:8080/axis/RoutingService.jws" use="encoded"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="RoutingServiceService">
<wsdl:port binding="impl:RoutingServiceSoapBinding" name="RoutingService">
<wsdlsoap:address location="http://localhost:8080/axis/RoutingService.jws"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
101
APÊNDICE F – Código NesC da Implementação do SEMSUS
F.1. Código de Messages.h (Mensagens)
#ifndef MESSAGES_H
#define MESSAGES_H
enum {
AM_BLINKTOSERIALMSG = 6,
TIMER_PERIOD_MILLI = 25
};
typedef nx_struct RoutingMsg {
nx_uint16_t destino;
nx_uint16_t origem;
nx_uint16_t nodeid;
nx_uint16_t dados;
} RoutingMsg;
typedef nx_struct DissiminationMsg {
nx_uint16_t dados;
} DissiminationMsg;
typedef nx_struct MiddlewareMsg {
nx_uint16_t servico;
nx_uint16_t destino;
nx_uint16_t origem;
nx_uint16_t nodeid;
nx_uint16_t dados;
} MiddlewareMsg;
#endif /* MESSAGES_H */
F.2. Código da configuração MiddlewareC
#include "Messages.h"
configuration MiddlewareC {
}
implementation{
components DispatcherC , Manager;
components new SerialAMReceiverC(AM_BLINKTOSERIALMSG);
components new SerialAMSenderC(AM_BLINKTOSERIALMSG);
components SerialActiveMessageC;
//Para conrole do Dispatcher
Manager.ControlDispatcher-> DispatcherC.ControlDispatcher;
102
//modulos de abstracao de hardware (serial) para Manager
Manager.SerialSend -> SerialAMSenderC;
Manager.SerialReceive -> SerialAMReceiverC;
Manager.SerialAMControl -> SerialActiveMessageC;
Manager.Packet -> SerialAMSenderC;
}
F.3. Código da interface SplitFase
#include "Messages.h"
#include "message.h"
interface SplitFase {
command error_t boot ();
command void init (message_t * msg, void * payload);
event void finish (message_t * msg, MiddlewareMsg * payload);
}
F.4. Código do componente Manager
#include "Messages.h"
module Manager{
uses {
interface SplitFase as ControlDispatcher [uint16_t type];
interface Receive as SerialReceive;
interface AMSend as SerialSend;
interface SplitControl as SerialAMControl;
interface Packet;
}
}
implementation{
MiddlewareMsg* btrpkt;
uint16_t id = 0;
bool busy = FALSE;
message_t pkt;
event void ControlDispatcher.finish [uint16_t type](message_t *msg, MiddlewareMsg
*payload){
btrpkt = (MiddlewareMsg*)payload;
if (! busy){
MiddlewareMsg* btrpkt1 = (MiddlewareMsg*)(call Packet.getPayload(&pkt, 2));
btrpkt1 = btrpkt;
if (call SerialSend.send(AM_BROADCAST_ADDR, &pkt, sizeof(MiddlewareMsg)) ==
SUCCESS) {
103
dbg("messages", "Valor de dados enviados para o sink via serial: %hhu \n", btrpkt1-
>dados);
busy = TRUE;
} else {
dbg("messages", "Nao foi possivel enviar mensagem para o sink \n" );
}
}
}
event message_t* SerialReceive.receive(message_t* msg, void* payload, uint8_t len) {
if (len == sizeof(MiddlewareMsg)) {
btrpkt = (MiddlewareMsg*)payload;
id = btrpkt->servico;
dbg("messages", "O servico %hhu foi chamado. Valor da mensagem Recebida: de %hhu
eh %hhu \n", btrpkt->servico, btrpkt->nodeid, btrpkt->dados);
if (call ControlDispatcher.boot[id]() == FAIL){
call ControlDispatcher.boot[id]();
}
call ControlDispatcher.init[id](msg, payload);
}
return msg;
}
event void SerialSend.sendDone(message_t *msg, error_t error){
if (&pkt == msg) {
busy = FALSE;
}
}
event void SerialAMControl.startDone(error_t error){
if (error == SUCCESS) { }
else {
call SerialAMControl.start();
}
}
event void SerialAMControl.stopDone(error_t error){
}
}
F.5. Código da configuração DispatcherC
#define MAX_TABLE_SIZE 10
#include "routing_table.h"
#include "Messages.h"
configuration DispatcherC {
104
provides interface SplitFase as ControlDispatcher [uint16_t id];
}
implementation {
components ServicosM as ServicesM, RoutingM, DisseminationM;
//para disseminação
components ActiveMessageC;
components DisseminationC;
components new DisseminatorC (uint32_t, 0x1234) as Diss16C;
components new AMSenderC(AM_BLINKTOSERIALMSG);
components new AMReceiverC(AM_BLINKTOSERIALMSG);
//externaliza "ControlServices" para os usuários
ControlDispatcher = ServicesM.ControlServices;
//para poder compilar
ServicesM.ControlService->RoutingM.Control;
//liga ao serviço de roteamento
ServicesM.ControlService[1]-> RoutingM.ControlRouting;
//liga ao serviço de disseminação
ServicesM.ControlService[2]-> DisseminationM.ControlDissimination;
//abstrações dos componentes de hardware necessários
//para o roteamento
RoutingM.AMControl -> ActiveMessageC;
RoutingM.AMSend -> AMSenderC;
RoutingM.Packet -> AMSenderC;
RoutingM.Receive -> AMReceiverC;
//para a disseminação
DisseminationM.PacketDissemination-> ActiveMessageC;
DisseminationM.DisseminationControl -> DisseminationC;
DisseminationM.Value -> Diss16C;
DisseminationM.Update -> Diss16C;
DisseminationM.RadioControl -> ActiveMessageC;
}
F.6. Código do componente ServiçosM
#include "Messages.h"
module ServicosM {
provides interface SplitFase as ControlServices [uint16_t id];
//interface para controle de cada serviço em especifico
uses {
105
interface SplitFase as ControlService[uint16_t idService];
}
}
implementation{
command error_t ControlServices.boot[uint16_t id](){
//a partir de servicos generico chama um especifico
return call ControlService.boot[id]();
}
command void ControlServices.init[uint16_t id](message_t *msg, void * payloaP){
//chama os comandos do servico especifico
call ControlService.init[id](msg, payloaP);
}
event void ControlService.finish[uint16_t idService](message_t *msg, MiddlewareMsg *
payload){
//quando receber o evento o passa adiante para a camada superior (Dispatcher)
signal ControlServices.finish[idService](msg, payload);
}
}
F.7. Código do serviço de disseminação residente no Sink
#include "Messages.h"
module DisseminationMSink{
provides interface SplitFase as ControlDissimination;
uses {
interface Packet as PacketDissemination;
//interfaces para comunicação sem fio na disseminação
interface StdControl as DisseminationControl;
interface DisseminationValue<uint32_t> as Value;
interface DisseminationUpdate<uint32_t> as Update;
interface SplitControl as RadioControl;
}
}
implementation{
MiddlewareMsg* payload;
uint32_t dados = 0;
command error_t ControlDissimination.boot(){
return call RadioControl.start();
}
event void RadioControl.startDone(error_t error){
if (error == FAIL) {
call RadioControl.start();
} else {
106
call DisseminationControl.start();
}
}
command void ControlDissimination.init(message_t *msg, void * payloadP){
dbg("messages", "Eu o Sink vou Disseminar \n");
payload = (MiddlewareMsg*) payloadP;
dados = payload->dados;
call Update.change(&dados);
dbg("messages", "Enviando mensagem com contador igual a : %u \n", dados);
}
//evento dos receptores na disseminação
event void Value.changed() {
const uint32_t* newVal = call Value.get();
dados = *newVal;
dbg("messages", "Recebida mensagem com contador igual a : %u \n", dados);
}
event void RadioControl.stopDone(error_t error){ }
}
F.8. Código do serviço de disseminação residente nos nós
#include "Messages.h"
module DisseminationMSource{
uses {
interface Packet as PacketDissemination;
//interfaces para comunicação sem fio na disseminação
interface StdControl as DisseminationControl;
interface DisseminationValue<uint32_t> as Value;
interface SplitControl as RadioControl;
interface Boot;
}
}
implementation{
DissiminationMsg* payload;
uint32_t dados = 0;
event void Boot.booted(){
call RadioControl.start();
call DisseminationControl.start();
}
event void RadioControl.startDone(error_t error){
if (error == FAIL) {
call RadioControl.start();
107
} else {
call DisseminationControl.start();
}
}
//evento dos receptores na disseminação
event void Value.changed() {
const uint32_t* newVal = call Value.get();
dados = *newVal;
dbg("messages", "Recebida mensagem com contador igual a : %u \n", dados);
}
event void RadioControl.stopDone(error_t error){ }
}
F.9. Código do serviço de roteamento residente no Sink
#include "Messages.h"
#include "routing_table.h"
module RoutingMSink{
provides interface SplitFase as ControlRouting;
provides interface SplitFase as Control [uint16_t id];
uses {
interface SplitControl as DymoSplitControl;
interface AMPacket as MHPacket;
interface Packet;
//para enviar via radio
interface AMSend;
//para receber via radio
interface Receive;
interface Intercept;
}
}
implementation{
bool busy = FALSE;
message_t pkt;
MiddlewareMsg* btrpktM;
uint16_t destino = 0;
uint16_t origem = 1;
RoutingMsg* payload;
command error_t ControlRouting.boot(){
//inicialização hardware de radio
return call DymoSplitControl.start();
}
108
event void DymoSplitControl.startDone(error_t error){
if (error == FAIL){
call DymoSplitControl.start();
}
}
command void ControlRouting.init(message_t * msg, void *payload1){
//inicializa os serviços
dbg("messages", "Eu o Sink vou rotear \n");
//enviar os dados via rádio para os sources
if(call MHPacket.address() == origem){
btrpktM = (MiddlewareMsg*)payload1;
payload = call Packet.getPayload(&pkt, NULL);
payload->dados = btrpktM->dados;
payload->destino = btrpktM->destino;
payload->origem = 1;
dbg("messages", "Enviando mensagem de valor %u com destino : %u \n",payload-
>dados ,payload-> destino);
if (call AMSend.send(payload-> destino, &pkt, sizeof(*payload)) == SUCCESS) {
dbg("messages", "Enviando mensagem com destino : %u \n", payload-> destino);
busy = TRUE;
}else {
dbg("messages", "Inabilitado para enviar mensagem \n");
}
}
}
event void AMSend.sendDone(message_t *msg, error_t e){
if((e == SUCCESS) && (msg == &pkt) && (call MHPacket.address()== origem)){
dbg("messages", "Mensagem enviada com Sucesso. \n");
busy = FALSE;
} else if (e == FAIL) {
dbg("messages", "A mensagem não foi enviada corretamente! \n");
} else {
dbg("messages", "O que aconteceu!?");
}
}
event message_t * Receive.receive(message_t * msg, void * payload, uint8_t len){
//Se tiver chegado no destino
if(call MHPacket.address() == call MHPacket.destination(msg)){
dbg("messages", "Eu, o destino, tenho recebido mensagem de: %u \n", call
MHPacket.source(msg));
} else {
dbg("messages", "O que é esta mensagem recebida? \n");
}
return msg;
}
109
command error_t Control.boot[uint16_t id](){
return FAIL;
}
command void Control.init[uint16_t id](message_t *msg, void * payload4){ }
event void DymoSplitControl.stopDone(error_t error){ }
event bool Intercept.forward(message_t *msg, void *payload, uint16_t len){
dbg("messages", "Eu, interceptor, tenho recebido mensagem de: %u \n", call
MHPacket.source(msg));
return TRUE;
}
}
F.10. Código do serviço de roteamento residente nos nós
#include "Messages.h"
#include "routing_table.h"
module RoutingMSource{
uses {
interface SplitControl as DymoSplitControl;
interface Boot;
interface AMPacket as MHPacket;
interface Packet;
interface Receive;
interface Intercept;
}
}
implementation{
bool busy = FALSE;
message_t pkt;
MiddlewareMsg* btrpktM;
uint16_t destino = 0;
uint16_t origem = 0;
event void Boot.booted(){
call DymoSplitControl.start();
}
event void DymoSplitControl.startDone(error_t error){
if (error == FAIL){
call DymoSplitControl.start();
}
}
event message_t * Receive.receive(message_t * msg, void * payload, uint8_t len){
110
//Se tiver chegado no destino
if(call MHPacket.address() == call MHPacket.destination(msg)){
dbg("messages", "Eu, o destino, tenho recebido mensagem de: %u \n", call
MHPacket.source(msg));
} else {
dbg("messages", "O que é esta mensagem recebida? \n");
}
return msg;
}
event void DymoSplitControl.stopDone(error_t error){ }
event bool Intercept.forward(message_t *msg, void *payload, uint16_t len){
dbg("messages", "Eu, interceptor, tenho recebido mensagem de: %u \n", call
MHPacket.source(msg));
return TRUE;
}
}
111
APÊNDICE G - Ontologia usada na busca semântica
<?xml version="1.0"?>
<!DOCTYPE rdf:RDF [
<!ENTITY owl "http://www.w3.org/2002/07/owl#" >
<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#" >
<!ENTITY owl2xml "http://www.w3.org/2006/12/owl2-xml#" >
<!ENTITY rdfs "http://www.w3.org/2000/01/rdf-schema#" >
<!ENTITY rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#" >
<!ENTITY rdfxml "http://localhost:8080/ontologias/rdfxml.owl#" >
]>
<rdf:RDF xmlns="http://localhost:8080/ontologias/rdfxml.owl#"
xml:base="http://localhost:8080/ontologias/rdfxml.owl"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:owl2xml="http://www.w3.org/2006/12/owl2-xml#"
xmlns:rdfxml="http://localhost:8080/ontologias/rdfxml.owl#"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<owl:Ontology rdf:about=""/>
<!-- Classes -->
<!-- http://localhost:8080/ontologias/ontologia_igual.owl#Address -->
<owl:Class rdf:about="#Address"/>
<!-- http://localhost:8080/ontologias/ontologia_igual.owl#Destination -->
<owl:Class rdf:about="#Destination">
<rdfs:subClassOf rdf:resource="#Address"/>
</owl:Class>
<!-- http://localhost:8080/ontologias/ontologia_igual.owl#Information -->
<owl:Class rdf:about="#Information">
<rdfs:subClassOf rdf:resource="#Value"/>
</owl:Class>
<!-- http://localhost:8080/ontologias/ontologia_igual.owl#Value -->
<owl:Class rdf:about="#Value"/>
</rdf:RDF>
Livros Grátis
( http://www.livrosgratis.com.br )
Milhares de Livros para Download:
Baixar livros de Administração
Baixar livros de Agronomia
Baixar livros de Arquitetura
Baixar livros de Artes
Baixar livros de Astronomia
Baixar livros de Biologia Geral
Baixar livros de Ciência da Computação
Baixar livros de Ciência da Informação
Baixar livros de Ciência Política
Baixar livros de Ciências da Saúde
Baixar livros de Comunicação
Baixar livros do Conselho Nacional de Educação - CNE
Baixar livros de Defesa civil
Baixar livros de Direito
Baixar livros de Direitos humanos
Baixar livros de Economia
Baixar livros de Economia Doméstica
Baixar livros de Educação
Baixar livros de Educação - Trânsito
Baixar livros de Educação Física
Baixar livros de Engenharia Aeroespacial
Baixar livros de Farmácia
Baixar livros de Filosofia
Baixar livros de Física
Baixar livros de Geociências
Baixar livros de Geografia
Baixar livros de História
Baixar livros de Línguas
Baixar livros de Literatura
Baixar livros de Literatura de Cordel
Baixar livros de Literatura Infantil
Baixar livros de Matemática
Baixar livros de Medicina
Baixar livros de Medicina Veterinária
Baixar livros de Meio Ambiente
Baixar livros de Meteorologia
Baixar Monografias e TCC
Baixar livros Multidisciplinar
Baixar livros de Música
Baixar livros de Psicologia
Baixar livros de Química
Baixar livros de Saúde Coletiva
Baixar livros de Serviço Social
Baixar livros de Sociologia
Baixar livros de Teologia
Baixar livros de Trabalho
Baixar livros de Turismo
