segunda-feira, 15 de setembro de 2008
Matéria no Jornal do Comércio
Nesta segunda, o Jornal do Comércio de Porto Alegre publicou matéria sobre o nosso grupo de pesquisa. Segue abaixo a imagem em alta-definição.
sábado, 30 de agosto de 2008
Entrevista do Prof. Crespo na Rádio Unisinos
Na última quinta-feira (28/08), o Prof. Sérgio Crespo concedeu uma entrevista na rádio Unisinos FM 103,3.
Na entrevista o professor explica com maiores detalhes os projetos de pesquisa que estão sendo desenvolvidos pelos alunos de mestrado e graduação para o Android da Google.
O áudio tem duração de 27 minutos e pode ser baixado diretamente aqui.
Na entrevista o professor explica com maiores detalhes os projetos de pesquisa que estão sendo desenvolvidos pelos alunos de mestrado e graduação para o Android da Google.
O áudio tem duração de 27 minutos e pode ser baixado diretamente aqui.
segunda-feira, 25 de agosto de 2008
Grupo de Pesquisa na Imprensa
O nosso trabalho está começando a aparecer na imprensa especializada. As matérias que estão nos links a seguir explicam em maiores detalhes o que está sendo feito atualmente pelo grupo (foto abaixo).
Brasileiros desenvolvem aplicação para o Android, do Google (Convergência Digital)
Unisinos: aplicação para Android (Baguete)
Unisinos desenvolve aplicação para Android (SEM Brasil)
Unisinos desenvolve aplicação para Google (J.U Online)
UNISINOS desenvolve aplicação para Google (Universia)
Unisinos desenvolve aplicação para Google (Coletiva.net)
Unisinos desenvolve aplicação para Google (Viva São Leopoldo)
Unisinos desenvolve aplicação para Google (FNDC)
Unisinos desenvolve aplicação para Google (Planetauniversitario.com)
Talento brasileiro no celular do Google (Capital Digital)
Se alguém quiser conhecer melhor o trabalho que está sendo desenvolvido, é só entrar em contato.
Brasileiros desenvolvem aplicação para o Android, do Google (Convergência Digital)
Unisinos: aplicação para Android (Baguete)
Unisinos desenvolve aplicação para Android (SEM Brasil)
Unisinos desenvolve aplicação para Google (J.U Online)
UNISINOS desenvolve aplicação para Google (Universia)
Unisinos desenvolve aplicação para Google (Coletiva.net)
Unisinos desenvolve aplicação para Google (Viva São Leopoldo)
Unisinos desenvolve aplicação para Google (FNDC)
Unisinos desenvolve aplicação para Google (Planetauniversitario.com)
Talento brasileiro no celular do Google (Capital Digital)
Se alguém quiser conhecer melhor o trabalho que está sendo desenvolvido, é só entrar em contato.
quinta-feira, 31 de janeiro de 2008
Peer-to-Peer Web Services
Em sistemas ad-hoc sem qualquer infraestrutura, o paradigma Peer-to-Peer (P2P) é atrativo. Assim, uma arquitetura de Web Services utilizando o paradigma P2P [1] apresenta-se como uma solução interessante de infraestrutura para esse tipo de sistema, sendo mais um passo em direção à computação ubíqua ou pervasiva.
A figura abaixo ilustra uma arquitetura típica de Web Services (SOA). Nessa arquitetura existem 3 principais atores.
A figura abaixo ilustra um cenário de SOA onde diversos fornecedores de serviços (P) publicam seus serviços no respositório (B), os quais são encontrados pelos requisitores (R) através de consultas a B e, finalmente, acessam os serviços de P.
Em uma arquitetura de serviços P2P, cada nodo deve ser capaz de publicar e consumir serviços, como ilustra a figura abaixo (cenário 1 - infraestrutura fixa: DHCP, DNS e servidor UDDI). Embora pareça simples, em um cenário móvel real, composto por rede ad-hoc, existem algumas dificuldades [1]:
A figura abaixo ilustra um segundo cenário P2P SOA, que é uma rede ad-hoc pura, sem nenhuma infraestrutura, com nodos entrando e saindo da rede constantemente. Neste cenário não existe um único B centralizado. Maiores explicações podem ser encontradas em [1].
Para suportar essa arquitetura, foi criado um framework de aplicação P2P que possibilita Web Services em nodos P2P. Diversos componentes fazem parte desse framework, sendo que o principal deles é o Servidor SOAP [2], ilustrado na figura abaixo. O framework foi implementado em J2ME.
De forma simplificada, o funcionamento do servidor é o seguinte:
[1] G. Gehlen e L. Pham, "Mobile Web Services for Peer-to-Peer Applications", In Proceedings of the Consumer Communications and Networking Conference 2005, p. 7, Las Vegas, USA.
[2] L. Pham e G. Gehlen, "Realization and Performance Analysis of a SOAP Server for Mobile Devices", In Proceedings of the 11th European Wireless Conference 2005, Vol. 2, p.p. 791-797, Nicosia, Cyprus,VDE Verlag
A figura abaixo ilustra uma arquitetura típica de Web Services (SOA). Nessa arquitetura existem 3 principais atores.
- Provedor de Serviços (P) ;
- Requisitor de Serviços (R);
- Broker de Serviços (B): repositório com informações sobre serviços (UDDI); contém informações sobre o provedor de serviços (white pages), categorias que caracterizam os serviços (yellow pages) e a interface dos serviços (green pages).
A figura abaixo ilustra um cenário de SOA onde diversos fornecedores de serviços (P) publicam seus serviços no respositório (B), os quais são encontrados pelos requisitores (R) através de consultas a B e, finalmente, acessam os serviços de P.
Em uma arquitetura de serviços P2P, cada nodo deve ser capaz de publicar e consumir serviços, como ilustra a figura abaixo (cenário 1 - infraestrutura fixa: DHCP, DNS e servidor UDDI). Embora pareça simples, em um cenário móvel real, composto por rede ad-hoc, existem algumas dificuldades [1]:
- Como e onde o serviço deve ser publicado e descoberto (centralizado ou descentralizado)?
- Os nodos devem ser endereçáveis, mas na maioria das redes móveis atuais como GSM/GPRS o endereço IP fica escondido através de um NAT (Network Address Translation).
- O limitado poder de processamento e a pouca memória dos dispositivos móveis atuais causam dificuldados no fornecimento de funcionalidades de servidor.
- A comunicação móvel não é confiável não oferece QoS contínuo.
A figura abaixo ilustra um segundo cenário P2P SOA, que é uma rede ad-hoc pura, sem nenhuma infraestrutura, com nodos entrando e saindo da rede constantemente. Neste cenário não existe um único B centralizado. Maiores explicações podem ser encontradas em [1].
Para suportar essa arquitetura, foi criado um framework de aplicação P2P que possibilita Web Services em nodos P2P. Diversos componentes fazem parte desse framework, sendo que o principal deles é o Servidor SOAP [2], ilustrado na figura abaixo. O framework foi implementado em J2ME.
De forma simplificada, o funcionamento do servidor é o seguinte:
- O Servidor SOAP torna os serviços disponíveis através de uma interface HTTP.
- Quando um cliente conecta ao servidor enviando uma requisição HTTP POST/GET, o socket do servidor aceita a conexão cliente e retorna um socket contendo os o stream dos dados de entrada.
- O Request Handler usa kSOAP e kXML para processar a mensagem, desserializando o XML em objetos Java.
- ...
[1] G. Gehlen e L. Pham, "Mobile Web Services for Peer-to-Peer Applications", In Proceedings of the Consumer Communications and Networking Conference 2005, p. 7, Las Vegas, USA.
[2] L. Pham e G. Gehlen, "Realization and Performance Analysis of a SOAP Server for Mobile Devices", In Proceedings of the 11th European Wireless Conference 2005, Vol. 2, p.p. 791-797, Nicosia, Cyprus,VDE Verlag
quinta-feira, 24 de janeiro de 2008
Descobrindo serviços dinamicamente em uma rede Ad Hoc
Uma abordagem apresentada por [1] propõe a combinação entre as arquiteturas de serviços Jini [2][3] e Web Services, para permitir a descoberta dinâmica de serviços em redes, como tecnologias de apoio à computação pervasiva ou ubíqua.
A utilização de Jini deve-se à necessidade de existência de descoberta de serviços também em redes Ad Hoc. "A tecnologia Jini é usada atualmente para habilitar inicialização espontânea de uma rede de serviços decorrente de uma abordagem Ad Hoc. Implantadores atuais estão usando essa capacidade para criarem soluções numa série de novos mercados de rede ad-hoc, incluindo redes caseiras, sistemas telemáticos e redes de sensores, entre outros" [1]. A arquitetura Jini é apresentada na figura abaixo.
Como pode ser facilmente percebido, a arquitetura de serviços Jini é muito similar a de Web Services, apresentada na figura abaixo. Porém, a descrição de serviço e a composição de Web Service não é suportada pelo sistema Jini padrão. Jini necessita que os serviços estejam expressados sob a forma de descrições de interfaces Java. Além disso, a busca por serviços Jini é feita através do mecanismo de pesquisa baseada em tipo, que requer que todas as partes envolvidas primeiramente concordem com um conjunto comum de interfaces de descrição de serviços conhecidas que ofereçam as mesmas funcionalidades de alto-nível. Assim, é difícil para Jini descobrir e interoperar com Web Services.
É aí que entra a solução proposta por [1]. Resumidamente, eles melhoram o mecanismo de descobrimento do Jini reimplementando ou extendendo o seu processo de registro e busca existentes. A solução é ilustrada pela figura abaixo.
Portanto, soluções para o suporte de descobrimento dinânico de serviços em redes Ad Hoc existem. No caso de [1], foi feita uma adaptação/alteração de tecnologia já existente. Dessa forma, embora já existam, nada impede que novas e melhores soluções sejam apresentadas, inclusive podendo ser o tema de um trabalho futuro.
[1] B. Xu, Q. Gao e X. Yang, "Extensions to Jini Service Architecture for Pervasive Computing", 2006 1st International Symposium on Pervasive Computing and Applications.
[2] http://www.sun.com/jini/.
[3] http://www.jini.org/.
A utilização de Jini deve-se à necessidade de existência de descoberta de serviços também em redes Ad Hoc. "A tecnologia Jini é usada atualmente para habilitar inicialização espontânea de uma rede de serviços decorrente de uma abordagem Ad Hoc. Implantadores atuais estão usando essa capacidade para criarem soluções numa série de novos mercados de rede ad-hoc, incluindo redes caseiras, sistemas telemáticos e redes de sensores, entre outros" [1]. A arquitetura Jini é apresentada na figura abaixo.
Como pode ser facilmente percebido, a arquitetura de serviços Jini é muito similar a de Web Services, apresentada na figura abaixo. Porém, a descrição de serviço e a composição de Web Service não é suportada pelo sistema Jini padrão. Jini necessita que os serviços estejam expressados sob a forma de descrições de interfaces Java. Além disso, a busca por serviços Jini é feita através do mecanismo de pesquisa baseada em tipo, que requer que todas as partes envolvidas primeiramente concordem com um conjunto comum de interfaces de descrição de serviços conhecidas que ofereçam as mesmas funcionalidades de alto-nível. Assim, é difícil para Jini descobrir e interoperar com Web Services.
É aí que entra a solução proposta por [1]. Resumidamente, eles melhoram o mecanismo de descobrimento do Jini reimplementando ou extendendo o seu processo de registro e busca existentes. A solução é ilustrada pela figura abaixo.
Portanto, soluções para o suporte de descobrimento dinânico de serviços em redes Ad Hoc existem. No caso de [1], foi feita uma adaptação/alteração de tecnologia já existente. Dessa forma, embora já existam, nada impede que novas e melhores soluções sejam apresentadas, inclusive podendo ser o tema de um trabalho futuro.
[1] B. Xu, Q. Gao e X. Yang, "Extensions to Jini Service Architecture for Pervasive Computing", 2006 1st International Symposium on Pervasive Computing and Applications.
[2] http://www.sun.com/jini/.
[3] http://www.jini.org/.
terça-feira, 22 de janeiro de 2008
Ainda sobre SOA em redes Ad Hoc
Particularmente, acredito muito nas redes Ad Hoc e na sua utilização em ambientes colaborativos. Como também estava estudando o artigo [1] que o Alex comentou no post anteiror, vou colocar mais alguns comentários sobre essa questão de SOA em redes Ad Hoc.
O objetivo de [1] foi fornecer SOA em uma MANET (Mobile Ad Hoc Network). A implementação baseou-se no protocolo de roteamento OLSR (Optimized Link State Routing), que é um protocolo pró-ativo, guiado por tabela e que utiliza uma técnica chamada de multipoint relaying for message flooding [2].
Como ilustra a figura acima, a diferença entre a abordagem tradicional (a) e Ad Hoc ou Mesh (b), sem um servidor central, o protocolo de roteamento, no caso OLSR, é de extrema importância.
A implementação OLSR utilizada pelos autores foi o componente open source OLSR daemon (olsrd) versão 0.4.10 [2]. A figura abaixo ilustra o framework fornecido pelo olsrd.
O framework olsrd fornece a possibilidade de executar módulos de software, que pode implemenar funcionalidades customizadas em associação com o roteamento. Seguindo essa idéia, a implementação da camada de SOA foi feita como um plugin olsrd, que fornece a descoberta de serviços SOA.
Portanto, fica comprovado por esse artigo que é possível utilizar SOA em redes Ad Hoc. Ainda, mais um possível componente de nossa arquitetura SOA para dispositivos móveis foi apresentado: OLSR.
[1] T. Halonen e T. Ojala, Cross-Layer Design for Providing Service Oriented Architecture in a Mobile Ad hoc Network, MUM’06, December 4-6, 2006, Stanford, CA, USA.
[2] OLSR daemon http://www.olsr.org/.
O objetivo de [1] foi fornecer SOA em uma MANET (Mobile Ad Hoc Network). A implementação baseou-se no protocolo de roteamento OLSR (Optimized Link State Routing), que é um protocolo pró-ativo, guiado por tabela e que utiliza uma técnica chamada de multipoint relaying for message flooding [2].
Como ilustra a figura acima, a diferença entre a abordagem tradicional (a) e Ad Hoc ou Mesh (b), sem um servidor central, o protocolo de roteamento, no caso OLSR, é de extrema importância.
A implementação OLSR utilizada pelos autores foi o componente open source OLSR daemon (olsrd) versão 0.4.10 [2]. A figura abaixo ilustra o framework fornecido pelo olsrd.
O framework olsrd fornece a possibilidade de executar módulos de software, que pode implemenar funcionalidades customizadas em associação com o roteamento. Seguindo essa idéia, a implementação da camada de SOA foi feita como um plugin olsrd, que fornece a descoberta de serviços SOA.
Portanto, fica comprovado por esse artigo que é possível utilizar SOA em redes Ad Hoc. Ainda, mais um possível componente de nossa arquitetura SOA para dispositivos móveis foi apresentado: OLSR.
[1] T. Halonen e T. Ojala, Cross-Layer Design for Providing Service Oriented Architecture in a Mobile Ad hoc Network, MUM’06, December 4-6, 2006, Stanford, CA, USA.
[2] OLSR daemon http://www.olsr.org/.
segunda-feira, 21 de janeiro de 2008
Disponibilização de SOA em uma rede Ad hoc para Dispositivos Móveis
Cross-Layer Design for Providing Service Oriented Architecture in a Mobile Ad hoc Network
Conforme haviamos conversado algumas vezes sobre os computadores de $ 100 que podem formar redes ad hoc, achei interessante comentar um artigo que descreve uma proposta para a disponibilização de serviços em uma rede deste tipo.
Neste artigo os autores apresentam um modelo para prover serviços em uma rede ad hoc para dispositivos móveis. SOA é integrada a um protocolo de roteamento chamado OLSR para a sua disponibilização e com isso foi implementado um protótipo para validação do modelo. A Figura 1 apresenta uma ilustração de uma rede com diversos serviços disponibilizados e como eles podem ser acessados por diferentes caminhos.
Conforme haviamos conversado algumas vezes sobre os computadores de $ 100 que podem formar redes ad hoc, achei interessante comentar um artigo que descreve uma proposta para a disponibilização de serviços em uma rede deste tipo.
Neste artigo os autores apresentam um modelo para prover serviços em uma rede ad hoc para dispositivos móveis. SOA é integrada a um protocolo de roteamento chamado OLSR para a sua disponibilização e com isso foi implementado um protótipo para validação do modelo. A Figura 1 apresenta uma ilustração de uma rede com diversos serviços disponibilizados e como eles podem ser acessados por diferentes caminhos.
Figura 1. Rede Ad hoc com Serviços Disponíveis
Figura 2. Protocolo utilizado na implementação do protótipo
[1] Halonem, Tommi; Ojala, Timo. “Cross-Layer Design for Providing Service Oriented Architecture in a Mobile Ad hoc Network”. Após projetado o modelo para suportar essa execução, a Figura 2 apresenta os 3 componentes mais relevantes ao projeto. O protocolo de roteamento, a camada SOA e os Serviços.
Figura 2. Protocolo utilizado na implementação do protótipo
Assinar:
Postagens (Atom)